Occlusion culling for dts objects
by Scooby Brown · in Torque Game Engine · 11/30/2008 (5:42 pm) · 6 replies
How would one add this so that all dts objects can occlude another that is behind it. my scenes are riddled with unneeded polygons.
#2
but personally my framerate is fine on my machine its just when i use laptops and other low performance machines. currently i have my scene set up in a rather retarded way and i plan on redoing it but how i have it now is pure dts. the only reason i ave done this is because terrain doesnt work (for some strange reason) and i couldnt bake dts in an interior in 1.4. so when i do bake them later on it should help improve performance right?
my scene is a jungle environment and i use rock as the permanent ground. but when i go below them(or any object that obstrucs the view) they should not be rendered because its wasting resources, and since interiors have culling i was wondering how and were i should look to migrate that functionality over to dts shapes.
11/30/2008 (7:06 pm)
Well i just recently moved to tge 1.5.2 since i cant afford tgea at the moment...but personally my framerate is fine on my machine its just when i use laptops and other low performance machines. currently i have my scene set up in a rather retarded way and i plan on redoing it but how i have it now is pure dts. the only reason i ave done this is because terrain doesnt work (for some strange reason) and i couldnt bake dts in an interior in 1.4. so when i do bake them later on it should help improve performance right?
my scene is a jungle environment and i use rock as the permanent ground. but when i go below them(or any object that obstrucs the view) they should not be rendered because its wasting resources, and since interiors have culling i was wondering how and were i should look to migrate that functionality over to dts shapes.
#3
This is for two reasons.
First its usually faster to render everything in an efficient manner than to try to cull them. The problem with TGE is that often it doesn't render as efficiently as it could. TGE was designed back when culling polygons mattered... it doesn't anymore... at least not in the way it did.
Second optimizing for corner cases like "looking down" or "behind an object" is useless. No one cares if your game runs at 1000 fps when your looking into a wall... its the cases where they can see across large portions of the level that matter.
I would suggest you get the terrain working for you again... it should perform and look better than multiple DTSs in TGE.
"Jungle environment" sounds like it may be your problem here. I would suggest to tone down the density where you can... use things like the foliage replicator (which i think requires terrain to work) to fill out ground. Also look at Ben's TGEForest which should help performance alot with lots of DTS trees.
There is good reason why most games do not have dense jungle in them... its because its extremely difficult do well.
12/01/2008 (4:13 am)
It is normal for games to render more than can be seen. When you get behind a garbage can in GTA4 the rest of the world is still rendered.This is for two reasons.
First its usually faster to render everything in an efficient manner than to try to cull them. The problem with TGE is that often it doesn't render as efficiently as it could. TGE was designed back when culling polygons mattered... it doesn't anymore... at least not in the way it did.
Second optimizing for corner cases like "looking down" or "behind an object" is useless. No one cares if your game runs at 1000 fps when your looking into a wall... its the cases where they can see across large portions of the level that matter.
I would suggest you get the terrain working for you again... it should perform and look better than multiple DTSs in TGE.
"Jungle environment" sounds like it may be your problem here. I would suggest to tone down the density where you can... use things like the foliage replicator (which i think requires terrain to work) to fill out ground. Also look at Ben's TGEForest which should help performance alot with lots of DTS trees.
There is good reason why most games do not have dense jungle in them... its because its extremely difficult do well.
#4
12/01/2008 (12:28 pm)
Oh wow thank you i completely forgot about the tge forests..bout to drop that in right now..thanks for the help 
#5
A Q on number of objects though... Are you saying it's more efficient to make a table with the plates and cups as a single dts, rather than 3+ separate objects? What if the plate was being re-used many times, but the cup was only used on this table?
12/01/2008 (4:59 pm)
That's good info on culling, I can cross that off my 'someday' list :)A Q on number of objects though... Are you saying it's more efficient to make a table with the plates and cups as a single dts, rather than 3+ separate objects? What if the plate was being re-used many times, but the cup was only used on this table?
#6
In the end its all about the number of drawPrimitive calls. Each draw call has a certain about of CPU overhead in the driver... no matter how fast your GPU is there is still a CPU cost to the call. Some draw calls take up more performance than others depending on what render states may have changed between calls.
Also remember these CPU cycles are not free... if your extremely aggressive with tons of draw calls your not gonna have the space for sophisticated AI.
As an example around 2002/2003 Richard Huddy still recommended under 500 drawPrim calls per frame in shipping games. Crysis shipped in 2007 did nearly 2000 drawPrim calls... and it performed badly on machines with lower end CPUs. These are just examples... you need to measure what you can get away with in your particular game.
So back to combing DTSs...
You only save when DTSs share the same materials. Combining one table and one plate in a DTS is not a win if they use separate materials... you still have two draw calls. If your combining one table and 10 plates... you get two draw calls for 11 objects... which is a win.
If your biggest room never has more than one table in it then its doubtful that this optimization matters, but if you have a room with 100 tables each with 10 plates on them... then saving 900 draw calls on the plates is a win.
In the end it all depends on what your typical game scenes are like.
12/01/2008 (5:41 pm)
@Erik - Depends... In the end its all about the number of drawPrimitive calls. Each draw call has a certain about of CPU overhead in the driver... no matter how fast your GPU is there is still a CPU cost to the call. Some draw calls take up more performance than others depending on what render states may have changed between calls.
Also remember these CPU cycles are not free... if your extremely aggressive with tons of draw calls your not gonna have the space for sophisticated AI.
As an example around 2002/2003 Richard Huddy still recommended under 500 drawPrim calls per frame in shipping games. Crysis shipped in 2007 did nearly 2000 drawPrim calls... and it performed badly on machines with lower end CPUs. These are just examples... you need to measure what you can get away with in your particular game.
So back to combing DTSs...
You only save when DTSs share the same materials. Combining one table and one plate in a DTS is not a win if they use separate materials... you still have two draw calls. If your combining one table and 10 plates... you get two draw calls for 11 objects... which is a win.
If your biggest room never has more than one table in it then its doubtful that this optimization matters, but if you have a room with 100 tables each with 10 plates on them... then saving 900 draw calls on the plates is a win.
In the end it all depends on what your typical game scenes are like.
Associate Tom Spilman
Sickhead Games
Whats your scene like? Lots of large objects? Lots of small objects? Do you have alot of objects that cluster together? How about a screenshot?
You sould combine objects that use the same materials into a single DTS when possible. If you have alot of small objects use autobillboards and even use a NULL final LOD to make the small objects completely disappear at distance.
Also if possible... consider moving to TGEA. It performs better than TGE out of the box if your project is suited to it.
If none of this is enough then you can start considering occlusion testing. The biggest issue is not wasting more time calculating if something is visible than the rendering would have taken. DirectX has hardware queries which can be used to detect if an object has been occluded, but with TGE and OpenGL i'm not sure how difficult it would be to implement.