Server performance question
by Igor G · in Torque Game Engine · 04/15/2008 (10:04 am) · 6 replies
Hi,
I have an extremely dense mission, approximately 3000+ statics and interiors, and need to have around 175-200 players on the same server at once. While profiling the code, most of the time spent is in SceneGraph::scopeScene, specifically in the scopeCallback function. This makes sense, since there are so many objects in the world.
My question is why does scopeScene enumerate through everything in the world and do a scopeCallback for each object? I thought that would split the world up into zones and call scopeCallback only on the objects around the scope point. Am I correct in assuming this? or perhaps there's a setting that is incorrectly set somewhere? or am I completely wrong?
Thanks.
I have an extremely dense mission, approximately 3000+ statics and interiors, and need to have around 175-200 players on the same server at once. While profiling the code, most of the time spent is in SceneGraph::scopeScene, specifically in the scopeCallback function. This makes sense, since there are so many objects in the world.
My question is why does scopeScene enumerate through everything in the world and do a scopeCallback for each object? I thought that would split the world up into zones and call scopeCallback only on the objects around the scope point. Am I correct in assuming this? or perhaps there's a setting that is incorrectly set somewhere? or am I completely wrong?
Thanks.
#2
Thanks for the quick reply. We have already made huge modifications to Torque to make it playable in such a dense environment. The scoping distance is already set quite low, at 100, and since most of our objects are statics, I guess that's why Torque isn't leveraging any bsp information. It seems even with a scoping distance of 100, the scopeScene function still calls the callback function for statics that are beyond 100 meters (not sure why?)
I was hoping that there was a way to skip over static objects that aren't even close, or statics that have already been ghosted over since statics never change.
04/15/2008 (10:47 am)
Hi Stephen,Thanks for the quick reply. We have already made huge modifications to Torque to make it playable in such a dense environment. The scoping distance is already set quite low, at 100, and since most of our objects are statics, I guess that's why Torque isn't leveraging any bsp information. It seems even with a scoping distance of 100, the scopeScene function still calls the callback function for statics that are beyond 100 meters (not sure why?)
I was hoping that there was a way to skip over static objects that aren't even close, or statics that have already been ghosted over since statics never change.
#3
04/15/2008 (12:57 pm)
Perhaps to create fake zones, it would be possible to create static DTS shapes inside invisible DIFs. Would this approach work to help the scene graph divide the world up into small zones, so that during scopeScene, it won't be going through every static object in the world?
#4
In general, does Torque use any sort of partitioning system for the scene graph? It seems absurd for a scene graph to process every object in the world for a single user. Most engines at least use a quadtree to partition the world into smaller, manageable chunks of data. I know Torque uses a zoning system for interiors, but it seems like there isn't such a system for the world scene graph. Am I doing something wrong with the placement of objects or interiors in my mission file?
Any suggestions?
Thanks
04/15/2008 (5:46 pm)
It seems that there is only 1 zone, and ever object (statics and interior instances) are stuck into that one zone, so that scopeScene takes an insane amount of time in this function for each user.In general, does Torque use any sort of partitioning system for the scene graph? It seems absurd for a scene graph to process every object in the world for a single user. Most engines at least use a quadtree to partition the world into smaller, manageable chunks of data. I know Torque uses a zoning system for interiors, but it seems like there isn't such a system for the world scene graph. Am I doing something wrong with the placement of objects or interiors in my mission file?
Any suggestions?
Thanks
#5
by default, static shapes are set to ghostAlways, meaning they load down immediately as part of mission load. This is normally good because they don't change much (hence the "static"), and therefore a single burst shot of data during mission load is better than going in and out of scope. You could look at short circuiting out of scope checks if the object type is a StaticShape, but then of course you wouldn't ever be able to update them across the net.
There isn't a default scenegraph partition system in the way you are wanting, although it shouldn't be too difficult to leverage the container class (which is used primarily for collision broad phase optimization) to do some scoping optimization in your particular case.
Off the top of my head, it might be as simple as changing your scoping code to do a container radius search on your vis range (plus a threshold to avoid thrashing, and pre-load things that might be entering scope shortly). You'd have to play around with the parameters (and most probably adjust for player min/max velocities as well).
04/15/2008 (6:13 pm)
Two things: by default, static shapes are set to ghostAlways, meaning they load down immediately as part of mission load. This is normally good because they don't change much (hence the "static"), and therefore a single burst shot of data during mission load is better than going in and out of scope. You could look at short circuiting out of scope checks if the object type is a StaticShape, but then of course you wouldn't ever be able to update them across the net.
There isn't a default scenegraph partition system in the way you are wanting, although it shouldn't be too difficult to leverage the container class (which is used primarily for collision broad phase optimization) to do some scoping optimization in your particular case.
Off the top of my head, it might be as simple as changing your scoping code to do a container radius search on your vis range (plus a threshold to avoid thrashing, and pre-load things that might be entering scope shortly). You'd have to play around with the parameters (and most probably adjust for player min/max velocities as well).
#6
do ghostAlways objects not already short circuit scope checking ?
fwiw,
Clint Brewer implemented a "ZoneBox" object for us,
which lets artists explicitly partition network scope by hand,
but it took a fair amount of work,
and is only really usable for situations where your players will never walk across ZoneBox boundaries.
(in our case, we have discrete lil' islands floating in space each pretending to be its own world)
04/15/2008 (6:18 pm)
> You could look at short circuiting out of scope checks if the object type is a StaticShapedo ghostAlways objects not already short circuit scope checking ?
fwiw,
Clint Brewer implemented a "ZoneBox" object for us,
which lets artists explicitly partition network scope by hand,
but it took a fair amount of work,
and is only really usable for situations where your players will never walk across ZoneBox boundaries.
(in our case, we have discrete lil' islands floating in space each pretending to be its own world)
Torque 3D Owner Stephen Zepp
Also generally speaking, I would look seriously at your projected scene density--that's going to be almost unplayable in any kind of networked environment, as you've just seen the first glimpse of.