Limiting Shapebase ghosting without reducing ViewDistance
by Vince Gee · 01/18/2012 (8:30 am) · 17 comments
****UPDATE 5/12/2012*****
-I found that if I adjusted how the ghosts are weighted using this new feature I could reduce the AI Jitter when the AI's are on the edge of the screen. Also, when spawning 300+ AI's the changes at the bottom cull the ghosts more effectively.
*************************
Ok,
Here is a little back story to this resource. Winterleaf Entertainment has been working on a MMo for over a year now. Finally, all of our preparation is starting to come together. So last night, we spawned 1000 AI's in our zone and watched the lag fest begin with our mission "visibleDistance" set to 5000. Mind you, the AI's were spawned all over the zone, but since our view distance was so large, the server was ghosting all the AI's to each client.
If we reduced the view distance down to 300, the lag went away, but our world also dropped off at 300. This was not acceptable.
So, after a little research we came up with this solution. A way to set the view distance to 1000 and the shapebase ghosting distance to 300.
So, the world continues in every direction for 1000 meters, but you only receive ghosts for shapebase objects within 300 meters.
LevelInfo.h
~line 40
After
Add
LevelInfo.cpp
~line 62
After
add
~line 102
After
Add
~line 291
After
add
SceneManager.h
~Line 113
After
Add
After
Add
SceneManager.cpp
~line 98
After
ShapeBase.Cpp
~line 1792
Replace
With
Lastly, open up your mission file and add
ENJOY!
****UPDATE 5/12/2012*****
gameBase.h
~Line 21
Add
After
gameBase.cpp
~Line 370
Replace
with
~Line 380
Replace
with
-I found that if I adjusted how the ghosts are weighted using this new feature I could reduce the AI Jitter when the AI's are on the edge of the screen. Also, when spawning 300+ AI's the changes at the bottom cull the ghosts more effectively.
*************************
Ok,
Here is a little back story to this resource. Winterleaf Entertainment has been working on a MMo for over a year now. Finally, all of our preparation is starting to come together. So last night, we spawned 1000 AI's in our zone and watched the lag fest begin with our mission "visibleDistance" set to 5000. Mind you, the AI's were spawned all over the zone, but since our view distance was so large, the server was ghosting all the AI's to each client.
If we reduced the view distance down to 300, the lag went away, but our world also dropped off at 300. This was not acceptable.
So, after a little research we came up with this solution. A way to set the view distance to 1000 and the shapebase ghosting distance to 300.
So, the world continues in every direction for 1000 meters, but you only receive ghosts for shapebase objects within 300 meters.
LevelInfo.h
~line 40
After
F32 mVisibleDistance;
Add
//Player Culling - Vince F32 mVisiblePlayers; //Player Culling - Vince
LevelInfo.cpp
~line 62
After
mVisibleDistance( 1000.0f ),
add
//Player Culling - Vince mVisiblePlayers(300.0f), //Player Culling Vince
~line 102
After
addField( "visibleDistance", TypeF32, Offset( mVisibleDistance, LevelInfo ), "Furthest distance fromt he camera's position to render the world." );
Add
//Player Culling - Vince addField( "visiblePlayers", TypeF32, Offset( mVisiblePlayers, LevelInfo ), "Furthest distance fromt he camera's position to render players." ); //Player Culling Vince
~line 291
After
scene->setVisibleDistance( mVisibleDistance );
add
//Player Culling - Vince scene->setVisiblePlayers(mVisiblePlayers); //Player Culling - Vince
SceneManager.h
~Line 113
After
F32 mVisibleDistance;
Add
//Player Culling - Vince F32 mVisiblePlayers; //Player Culling - Vince~line 290
After
void setVisibleDistance( F32 dist ) { mVisibleDistance = dist; }Add
//Player Culling - Vince
void setVisiblePlayers( F32 dist ) { mVisiblePlayers = dist; }
F32 getVisiblePlayers() { return mVisiblePlayers; }
//Player Culling VinceSceneManager.cpp
~line 98
After
mVisibleDistance( 500.f ),add
//Player Culling - Vince mVisiblePlayers(300.f), //Player Culling - Vince
ShapeBase.Cpp
~line 1792
Replace
// Get the visible distance. if (getSceneManager() != NULL) query->visibleDistance = getSceneManager()->getVisibleDistance();
With
// Get the visible distance. //if (getSceneManager() != NULL) // query->visibleDistance = getSceneManager()->getVisibleDistance(); if (getSceneManager() != NULL) query->visibleDistance = getSceneManager()->getVisiblePlayers();
Lastly, open up your mission file and add
visiblePlayers = "100";
ENJOY!
****UPDATE 5/12/2012*****
gameBase.h
~Line 21
Add
//Player Culling - Vince #include "scene/sceneManager.h" //Player Culling - Vince
After
#endif #ifndef _DYNAMIC_CONSOLETYPES_H_ #include "console/dynamicTypes.h" #endif
gameBase.cpp
~Line 370
Replace
// Weight based on linear distance, the basic stuff. F32 wDistance = (dist < camInfo->visibleDistance)? 1.0f - (dist / camInfo->visibleDistance): 0.0f;
with
// Weight based on linear distance, the basic stuff. F32 wDistance = (dist < camInfo->visibleDistance)? 1.0f - (dist / camInfo->visibleDistance): 0.0f; //Player Culling - Vince SceneManager* so = getSceneManager(); if (so != NULL) wDistance = (dist < so->getVisiblePlayers())? 1.0f - sqrt( (dist / so->getVisiblePlayers())): 0.0f;0.0f; //Player Culling - Vince
~Line 380
Replace
bool inFov = dot > camInfo->cosFov;
with
//Player Culling - Vince bool inFov = dot > (cos( (camInfo->fov + 40) >360?360:camInfo->fov + 40)/2); //bool inFov = dot > camInfo->cosFov; //Player Culling - Vince
About the author
www.winterleafentertainment.com
#2
I also found we can support more AI's and client connections since the server isn't busy ghosting information that clients don't need anymore. I'll be interested in seeing what our load testing results will be.
01/18/2012 (9:50 am)
Thank you!I also found we can support more AI's and client connections since the server isn't busy ghosting information that clients don't need anymore. I'll be interested in seeing what our load testing results will be.
#3
01/18/2012 (9:58 am)
Now that, that's just clever. 
#4
01/18/2012 (12:47 pm)
That is awesome, and should be integrated into the engine! 
#5
01/18/2012 (4:02 pm)
@Vince, what about zooming? An AI could be in the viewable distance but normally outside your visible player distance until someone zooms in.
#6
01/18/2012 (4:27 pm)
You would have to move the setting to the shapebase or player object and enhance the range when the player goes into "zoom" mode etc, you would have to leave him in "Zoom" mode until he took the scope off, so you would basicially expand and shrink the ghosting distance around the player. 
#7
01/19/2012 (12:48 am)
Pure <3 
#8
01/19/2012 (3:59 am)
Nice trick. 
#9
01/19/2012 (6:36 am)
Clever... I like it! 
#10
01/19/2012 (8:13 am)
just a blind question here because I have not gone over the scripts but love the idea. Does each player receive just their own ghosting info or does the server send the info to all that are connected just because it was triggered by someone?
#11
Not sure you understand what this change does, first it's not a script change it's a C++ change. So you would have to recompile the engine after making the changes.
Now, answer what I think your question is...
Stock T3d
When you set up your mission, you specify the viewdistance, this parameter is used to tell the client how much landscape to render. So if you tell it 100, then the client will only render 100 meters in all directions around the client. The client will also ONLY receive ghosts on object within that 100 meter radius.
The problem arises when your level designers want to show grand vista's. They have spent hours building mountain ranges etc and they want players to be able to see them.
So, they increase the viewdistance to 4000.
The result of this, is that each client now receives the ghost updates for damn near the whole zone, since it is using the perimeter of 4000 meters in all directions for culling of ghosts. This is fine, if say your player and ai base is a 100 or so. But when you plan on a user base of say, 500 per zone, the lag kills the server and client. This occurs regardless of whether the client can see the other objects. The occlusion happens in the rendering and not at the network level.
What this C++ modification allows you to do, is set the view distance at 4000 so the players can see the static objects and the grand vistas, but they are only relayed the ghosts around them say at 300 meters. Thus reducing lag and bandwidth between the server and clients. As they move around as monsters and other players move into their 300 meter "Awareness" perimeter the network level will start broadcasting the ghosts to them until they leave each others perimeter.
End result is a ton less of network traffic with the ability to show REAL large zones.
01/19/2012 (9:27 am)
@Greg,Not sure you understand what this change does, first it's not a script change it's a C++ change. So you would have to recompile the engine after making the changes.
Now, answer what I think your question is...
Stock T3d
When you set up your mission, you specify the viewdistance, this parameter is used to tell the client how much landscape to render. So if you tell it 100, then the client will only render 100 meters in all directions around the client. The client will also ONLY receive ghosts on object within that 100 meter radius.
The problem arises when your level designers want to show grand vista's. They have spent hours building mountain ranges etc and they want players to be able to see them.
So, they increase the viewdistance to 4000.
The result of this, is that each client now receives the ghost updates for damn near the whole zone, since it is using the perimeter of 4000 meters in all directions for culling of ghosts. This is fine, if say your player and ai base is a 100 or so. But when you plan on a user base of say, 500 per zone, the lag kills the server and client. This occurs regardless of whether the client can see the other objects. The occlusion happens in the rendering and not at the network level.
What this C++ modification allows you to do, is set the view distance at 4000 so the players can see the static objects and the grand vistas, but they are only relayed the ghosts around them say at 300 meters. Thus reducing lag and bandwidth between the server and clients. As they move around as monsters and other players move into their 300 meter "Awareness" perimeter the network level will start broadcasting the ghosts to them until they leave each others perimeter.
End result is a ton less of network traffic with the ability to show REAL large zones.
#12
01/20/2012 (6:08 am)
This is very very nifty. Cool trick =) 
#13
01/21/2012 (12:59 am)
Nice work. Do you think it'd be helpful to make the scoping logic even more fine-grained for these classes? For example, doing raycast occlusion checking so that characters out of sight are not ghosted? Or even just testing against the current viewing direction?
#14
Also, it might add load to the predictive player movement logic since ghosts would be popping in and out more. (a guess)
01/23/2012 (7:39 am)
hmmm, kinda torn on that. While agree on the surface it looks great, in implementation it would add cycles to the process (which the network level is already quite busy)Also, it might add load to the predictive player movement logic since ghosts would be popping in and out more. (a guess)
#15
Played with it on one of my 2km x 2km maps with little ole' AIs running all over the place ... worked so well I almost choked on my coffee.
Thanks for this and the hard work. 8-}
01/24/2012 (3:30 am)
"Flippin eck" ... damn nice resource ... damn nice trick ... and it works a charm.Played with it on one of my 2km x 2km maps with little ole' AIs running all over the place ... worked so well I almost choked on my coffee.
Thanks for this and the hard work. 8-}
#16
Your welcome! The most AI's I've been able to load up so far is about 250 on a old Pentium duo 2.66 quad core. If your following my blog, I'm working on hooking torque up to CLR, and I will be curious to see how many more ai's I can add once I can get their logic into a separate thread running on a separate core with their own memory management. I really want to hit 300-400 AI's, with the CSharp controlling them instead of Torque Script, since Torque is single threaded.
01/24/2012 (6:54 am)
@Quinton,Your welcome! The most AI's I've been able to load up so far is about 250 on a old Pentium duo 2.66 quad core. If your following my blog, I'm working on hooking torque up to CLR, and I will be curious to see how many more ai's I can add once I can get their logic into a separate thread running on a separate core with their own memory management. I really want to hit 300-400 AI's, with the CSharp controlling them instead of Torque Script, since Torque is single threaded.
#17
07/08/2013 (9:15 pm)
This is awesome Thanks. 
Associate Steve Acaster
[YorkshireRifles.com]