Doom 3 engine release and game code

[nbohr1more]

[mh]

[nbohr1more]

WOW

Thanks for the prompt reply.

I'll try to stir the pot over there some more. The (remaining) coding team has been nervous to touch renderer code save one developer who's been on hiatus awhile. He had apparently made a functional LATC parser and RGTC parser but hasn't patched them in yet because he wants to also include an on-the-fly converter to those formats. I was really hoping for high quality normal map compression in the next release but maybe this will sorta make up for that. (Load times will still suck though )

[revelator]

The CPU bottleneck is starting to be a real problem with higher quality assets :S
Shows the need for moving more functions gfx side but its a huge undertaking.

[mh]

[revelator]

nice

[frag.machine]

[revelator]

yup it uses rage format but those parts can be skipped still a lot of idtech4 in there but im interrested in seing what stuff they changed to better match todays PC's

[revelator]

Interresting example of opengl hardware tesselation sadly it needs a fully working glsl backend but if we get that far the example could even be used for hardware generated terrains.

Not sure if it could be done with the old ARB2 backend hmm ? might also need support engine side.

[Spike]

tessellation is overrated.

1: its faster to precompute it on the cpu than to spend gpu resources on generating new polygons (remember that modern gpus have a unified shader archetecture - time spent on a tessellation shader is time no longer spent on the vertex/fragment shader). Precompute it on an alternate cpu core instead for extra points.
2: knowing the exact position of the verticies is required anyway for things like decals. guarenteed no swimming, and physics impacts the actual geometry.
3: frustum culling is much easier using a divide-and-conquer algo on the cpu, instead of checking each vertex to see if its onscreen. if the gpu never sees it, the gpu will never waste time on it.
4: a 4096*4096 heightmap is huge. if you have that big a heightmap, your texture quality upon that heightmap is going to be rather lackluster.
5: if you're doing any shadows or anything that requires drawing the terrain multiple times a frame, doing it on the cpu means its only done once.
6: cpu is more efficient/better at branching.

imho.

for a flight sim with a huge view distance a geometry shader might be simpler, but in that case you're probably going to want more than 4096 sample points in each axis.

[revelator]

Just exploring possbilities it might not be faster as you point out but it could have its uses in case the hit is not to big.
Though im a bit puzzled about modern day CPU's being god awfull at stuff that the previous generations handled pretty well back when a lot of that stuff actually had to be done CPU side hmm ???.
One appaling example is that my old p4 actually runs doom3 better than my current i7 maybe related to something i heard carmack talking about that doom3 is actually multithreaded but that the code newer worked optimally ?. I have a weird feeling im onto something as the problem is also there with Q4 latest patch where you can turn of multithreading and when i do the game actually runs far far better.
Makes one wonder if theres a hint from PVS-studio when it warns about replacing the thread functions with beginThreadEx endThreadEx calls.

[mh]

If you're tesselating dynamically then you'd better do it on the GPU otherwise buffer uploads and GPU latency/synchronization are going to kill you. A point often forgotten, probably because it's not directly measurable in amount of code you write yourself (and because it looks like less code and it's nice safe CPU code rather than scary GPU code so maybe there's a comfort zone attached to it). Likewise if you're tesselating very fine then doing the extra work may be a better balance than spending so much more storage. The only rule is that there is no hard-and-fast rule and you need to adapt to your own use case.

Geometry shaders are definitely overrated; just having the GS stage enabled (even just for pass-through) will burn maybe 10% of your performance so you need to be certain that the gain you're getting back will exceed that. Even the simple classic case of expanding points to quads for a particle system is slower than sending all 4 verts (and if you use instancing you only need to send one vert per particle anyway; even then doing the billboarding calculations 4 times per particle in a VS is faster than doing them once per particle in a GS). What they are good for is generating new per-vertex data on the fly (such as normals for a triangle) but as a general rule using them to add extra verts/tris is a performance killer.

[mh]

Incidentally, here's what a frame of BFG Edition looks like: http://pastebin.com/pxKnZhLD

[revelator]

I did hear rumours that the BFG edition used GLSL seems they where right well that bodes well for those who wanted a GLSL backend.

[mh]

I'd guess it uses Cg - Rage certainly did, the shaders (example: ) look like auto-generated code (and similar in style to Rage's: ) and it would make sense as they could compile it down to HLSL/etc for the 360/etc too.

That would also make a D3D port viable too.