Vehicle Demo (Final)

[_Tux_]

if the shadows are stencil shadow volumes then they use the cpu so that explains the big slowdown

[Sascha Willems]

Unfortunately, the Controls seem to be Framerate based, so the faster the program, the better the physics appear because the more responsive the controls.

No, they should be independet of framerate (which means that you can drive as fast under low FPS as you would with high FPS). They get sluggish at lower FPS because the CPU can't cope up. And since they keys are checked in the main-VCL-Thread, they aren't updated as often when having low FPS as when having high FPS. But that's something hard to avoid, since even commercial games are having sluggish input at low FPS.

As even in the most active physics events the FPS didn't drop, I'd say what is slowing this down is mostly the rendering pipeline. Some things could do with some tweaking.

That's true. The demo is fairly heavy concerning rendering. The scene consists of about 60.000 triangles (maybe some more or less, don't remember right now), which are stored in two octrees (one for the normal surfaces, and one for the transparent surfaces that is drawn at last). This octree then is rendere using frustum culling. One optimization (especially for newer hardware) would be to use occlusion queries to only draw the octree nodes that are really visible, whereas frustum culling only prevents drawing nodes outside of the frustum. The octree nodes btw. are stored in to displaylists and each node by itself is arranged by textures, to minimize the expensive change of texture state.
And the fact that FPS don't go down when there is much physics activity is something that you have to thank Julio for Newton is very well optimized and can even handle many collisions at a time without taking much time to get it's calculations done.

Not to mention the Shadows appear to have ZDepth issues.

That's something happening on NVidia-Hardware. I've noticed that glPolyonOffset makes problems there (maybe because of newer drivers), whereas it works for ATI (on ATI-cards there's almost no depth issue with the shadows). But since I haven't had the time to test the demo on Nvidia-Hardware, that bug is still in there. I'll maybe fix it in the future.

As for the physics themselves, when using Front/Rear Wheel Drive the brakes didn't work quite right, you'd slow down and stop using them but let go and it'll continue as if you were still accelerating. In 4wd this was never an issue though. Overall is a cool demo though.

I know that. I've never implemented a gearbox, so the gearbox in the demo has some problems/limitations like the self-accelerating you've mentioned. But since I'm no physics guru, I just couldn't fix it.

if the shadows are stencil shadow volumes then they use the cpu so that explains the big slowdown

Yes, they are stencil shadows. But I only recalculate the shadow volumes of dynamic objects if they are active (which you can query from newton), so the calculation of stencil shadows isn't that heavy on the system. But stencil shadows have one big drawback, especially for outdoor scenes (like in the demo) : They burn much fillrate. The more stencil shadows are in your viewport, the mor fillrate gets burned. Especially lower-end cards have very limited fillrate (cause of slower memory, and smaller memory-bus connection), so stencil shadows slow down very much. But that's also why Doom3 is so demanding on the hardware
But yes, the stencil shadows in my demo are not totally optimized. I now use always ZFail, but you normally would (I was too lazy and I wanted to finish the demo one day) check if the camera is in a shadow volume and only then draw it ZFail, otherwise ZPass. That would save you some fillrate, as ZPass doesn't require you to cap the shadow volumes.


P.S. : Thanks for feedack!