PC polygon performance

Hyp-X said:
Also, there isn't a particularly good shadow map solution available (yet) for handling visible point lights.

Hmm, it seems that GF4Ti supports depth textures as cube textures...
(I haven't tried it yet.)
Both GF3 and GF4 support depth formats for cube textures, but the problem is performance.
 
Another thing to consider about Ut2k3 vrs doom3. Is that the new unreal engine is available now to licensee were as doom3 is not at that status yet. During the summit Tim S even stated that his new engine was not designed to have the IQ features of doom3. He chose a different path and I have to agree that for his market, its not a bad call.
 
In other words: anybody disappointed by DOOM3 screenshots should see the game in motion before judging.
I doubt there are many folks who have been disappointed with the various DOOM3 shots so far. But I agree - it looks incredible in motion.

Insofar as screenshots are concerned, per pixel lighting can't be seen. What impresses me the most when looking at screenshots are the colors and sharpness.
 
Actually, you can calculate shadow volumes with vertex programs, just project every back-face vertex at a finite fixed distance. This is not the exact silhouette (has mush more polygons) but works with closed shapes and on-board generated geometry (like N-Patches). Also, there are more robust techniques that work with “openâ€￾ shapes, but you have to change your geometry. I think I saw a couple of ATI/NVIDIA docs outlining the details.
Carmack said it was a bit slower on a GF3, but the CPU usage was low (about 10%).

As for shadow algorithms, I think the “Deep Shadow Mapsâ€￾ by Lokovic and Veach is currently the best practical algorithm. Ray casting is of course the most accurate and simple but is not yet practical if you don’t want just simple sharp opaque shadows.
 
Pavlos said:
Actually, you can calculate shadow volumes with vertex programs, just project every back-face vertex at a finite fixed distance. This is not the exact silhouette (has mush more polygons) but works with closed shapes and on-board generated geometry (like N-Patches).

This won't work on hard edges (where neighbouring faces are not in the same smoothing group). You can create a fully smoothed version of the object, but doubt it would look anywhere near correct.

(Of 'cos N-patches don't like hard edges, but thats a different story.)

Also, there are more robust techniques that work with “openâ€￾ shapes, but you have to change your geometry. I think I saw a couple of ATI/NVIDIA docs outlining the details.

Yeah, thats the right thing - but you cannot do them with vertex shaders.

Carmack said it was a bit slower on a GF3, but the CPU usage was low (about 10%).

He also said that 8x Aniso has less than 30% hit on the GF3 :D
 
This won't work on hard edges ...

You are correct, the simple algorithm (pushing back-facing vertices to “FARâ€￾) works only for closed, highly and smoothly tessellated objects, but the vertex program is short and the geometry of some games satisfies the conditions.

You can add a degenerate quad at every edge and the algorithm will work for everything, even for a single triangle.
 
Back
Top