OpenSmash Project Design Doc

[Dr. Shadowborg]

[leileilol]

I wonder how hard it is to beat Engoo into having iqms and tags in software

Don't forget FTEQW deprecated its software renderer, which is still actually quite advanced

[taniwha]

[qbism]

I like that this is single-player, and the idea of civilians as more than scenery/ fodder.

Does IQM support tags?

[leileilol]

[taniwha]

[leileilol]

[Dr. Shadowborg]

[Spike]

the issue with using model rendering code for bsp objects is that you'll need to render lightmaps too. if you can precompute those, good for you.
you can convert-on-load an iqm to mdl format if you really want, just like fte's software renderer did with md3, but you'll loose support for bones, and I recommend you extend the precision... If you also retain the animation data, you can use it for attachment support, though there'll be a lot of bones which are simply not useful as tags. That said, if you're retaining all of the animation data anyway, it should be as easy to transform the verts as it is to interpolate the verts, just slightly higher cpu usage but no higher than would be needed for glsl-less iqm.

hexen2 bsps use 6 hulls (space for
0 0 0 0 0 0
-16 -16 -24 16 16 32
-24 -24 -20 24 24 20
-16 -16 -12 16 16 16
-8 -8 -8 8 8 8
-48 -48 -50 48 48 50

q2+ bsps support any size collisions. textures are all external.
q3 bsps provide support for triangle soup for correctly lit static meshes etc, but removes support for lightstyles (and good luck with software rendering). q3map2 provides more realistic lighting routines too.
rbsp re-adds support for lightstyles by using 4 lightmaps and scaling them by the lightstyle value on the gpu (mh was toying with this style of lightmap rendering on q1bsp).
fbsp just adds higher-res lightmaps.

[Dr. Shadowborg]

Okay, so basically the options are:

1. H2BSP = Theoretically very easy to add support for due to largely being based on Q1BSP. FTEQW supports this format.
2. Q2BSP = More difficult to add, but probably still doable. Superior to H2BSP. Don't know of any other engines aside from FTEQW that support it.
3. FBSP = Extremely difficult to impossible for software support. DP and FTEQW support this format.

I tried loading up some sample maps of H2BSP and Q2BSP. So far, all roads seem to be leading back to Q2BSP as being the best compromise of the three.

The only problem is that for some reason Q2BSP is not working properly in FTEQW, everything loads up properly and the maps look beautiful, but the player falls through the floor! (items and rockets fired against map geometry seem to work right though.)

I even tried making a quick box testmap with GTKRadiant, same thing happens. (stock id1 progs.dat) Is there some cvar or something that I need to turn on?

[Spike]

o.O
q2bsp is basically the same collision code as q3, just without patches. brushes are all the same code.
I'll be sure to check that tomorrow, all I can suggest in the mean time is that maybe sv_nomsec 1 can work around it by using different physics (although not collisions). that's a temporary hack-fix only, of course.
I've no idea why the same code would work for q2+q2bsp and qc+q3bsp but not qc+q2bsp. tomorrow is gonna be 'one of those days'.

[Dr. Shadowborg]

[Spike]

nomsec 0 should work now. turned out to be a missing model size value. any entity other than world would have been culled too. should now be fixed.

shrunk massively? o.O
I can't reproduce that myself, neither with nor without glsl.
so...
Are you using .wal files for your water, or just directly using a .tga (or other 24bit file)?
if I recall correctly, the surfaces specify texture coords, and texture sizes is in the wal (in order to generate 0-1 scale). If the qbsp and engine disagree on the size to use when there's no .wal file then you'll get messed up texture scales (and this is quite likely in all honesty). The solution is to stay true to q2 and always make .wal files available, even if the image inside is replaced.
What I don't understand is how that could affect q1 bsps with the same texture name.

transparent water surface textures don't warp, that's a known issue that I couldn't think of a clean fix for at the time. The shader system should make that a little easier to do now.
The missing underwater screen warp I hadn't noticed, its probably just not setting the contents flags.

[Dr. Shadowborg]

[leileilol]

Isn't that green/yellow/red texture supposed to be the waterwarp fragment shader effect? It's like the water texture shader and screen warp shader are conflicting up somewhere.