DIFs not blocking bot rendering?
by Jason Gossiaux · in Torque Game Engine · 03/09/2008 (7:17 pm) · 12 replies
This is probably just how the engine was designed, but is it normal for DIFs to not block the rendering of bots? I find that if I have 100 bots on the screen I go from 60fps down to 20fps, which is pretty decent all things considered. But I was suprised to find that my framerate remained low even when walking behind a building. If I walk INTO a building my framerate jumps to 150fps as the portal stops the rendering of everything outside... so I know that much is working.
What would be the technical term for when a DIF would be stopping the rendering of the bots? DIF occlusion? Render culling? I'm prepared to try digging in the render engine to add this functionality (if that's even remotely possible) because it would seem like the easiest way to get my game to support 100s of bots on the map at once. Maybe I could just hack it in if someone had an idea of where to look, or maybe it has already been done before?
I always figured I could handle ~200 bots in my game at one time because the buildings the player would be placing would obscure enough of them at any one time to keep the framerates up. If that isn't going to be possible then I either need to greatly reduce the bot detail (which may be a possibility too, since I am only using the default Kork model and I'm not sure it has LOD support), or rework the bot code to be more lightweight.
I'd read that removing the check for Player collisions could help improve render speed, but it didn't. I also tried increasing the pref::Net::PacketSize - and that did help with some of the jumping around the bots in the group were doing. But the framerates remained ~20.
Any ideas or observations would be helpful. I was amazed to find that having 100 bots doing A* pathfinding on a 2000x2000 node map wasn't really causing any lag at all... it's just the engine can't actually render that many on screen at one time :P
What would be the technical term for when a DIF would be stopping the rendering of the bots? DIF occlusion? Render culling? I'm prepared to try digging in the render engine to add this functionality (if that's even remotely possible) because it would seem like the easiest way to get my game to support 100s of bots on the map at once. Maybe I could just hack it in if someone had an idea of where to look, or maybe it has already been done before?
I always figured I could handle ~200 bots in my game at one time because the buildings the player would be placing would obscure enough of them at any one time to keep the framerates up. If that isn't going to be possible then I either need to greatly reduce the bot detail (which may be a possibility too, since I am only using the default Kork model and I'm not sure it has LOD support), or rework the bot code to be more lightweight.
I'd read that removing the check for Player collisions could help improve render speed, but it didn't. I also tried increasing the pref::Net::PacketSize - and that did help with some of the jumping around the bots in the group were doing. But the framerates remained ~20.
Any ideas or observations would be helpful. I was amazed to find that having 100 bots doing A* pathfinding on a 2000x2000 node map wasn't really causing any lag at all... it's just the engine can't actually render that many on screen at one time :P
About the author
#2
I imagine the Kork model has some limited LOD settings within it. Atleast it did at one point in time. Rather it still does today I would have to look and see. Even so though LOD is only going to effect the characters that are a good distance from the player. If you have like 5-10 characters behind a building that a character is looking at your still going to get the full LOD of the model until they move away from the player enough distance to cause the LOD to kickin.
03/11/2008 (12:38 pm)
Its a interesting issue. Since you would think DIF's would occlude objects behind them. Makes me kinda wander if DIFs occlude other difs behind difs. Imagine a city where you have upwards of 100+ building all around. Where some of the buildings are being blocked by ones in front of them. I could see how it could easly becomes a big issue fast.I imagine the Kork model has some limited LOD settings within it. Atleast it did at one point in time. Rather it still does today I would have to look and see. Even so though LOD is only going to effect the characters that are a good distance from the player. If you have like 5-10 characters behind a building that a character is looking at your still going to get the full LOD of the model until they move away from the player enough distance to cause the LOD to kickin.
#3
I don't think DIFs occlude each other which is a problem as well. Maybe I can do a dynamic LOD where the range goes down in the city and up just outside.
I'm almost not sure if the slowdown to 20fps is from the bot rendering, or the packet updating going on behind the scenes. With 100 bots on the screen I seemed to notice some odd console errors getting displayed about textures not being found. They also jumped around a bit on the screen beyond what low fps would do.
Does TGEA occlude DIFs/DTS shapes behind one another? Will Torque 2? I am beginning to understand why nobody has made a game quite like I envision yet :P
03/11/2008 (2:40 pm)
It does look like DIFs occlude objects inside of them at least, just not behind them. I was getting 50fps with 100 bots standing just inside the portalized building in front of me, and 20fps once they walked out.I don't think DIFs occlude each other which is a problem as well. Maybe I can do a dynamic LOD where the range goes down in the city and up just outside.
I'm almost not sure if the slowdown to 20fps is from the bot rendering, or the packet updating going on behind the scenes. With 100 bots on the screen I seemed to notice some odd console errors getting displayed about textures not being found. They also jumped around a bit on the screen beyond what low fps would do.
Does TGEA occlude DIFs/DTS shapes behind one another? Will Torque 2? I am beginning to understand why nobody has made a game quite like I envision yet :P
#4
You might get some ideas on how to tweak stuff if other people knew.
03/12/2008 (7:36 pm)
What is the game you've envisioned like?You might get some ideas on how to tweak stuff if other people knew.
#5
I've already solved some of the more advanced problems... I should write a blog about it as its probably not anything I wish I post here. Suffice to say that end-game I am hoping to have 100-200 townsfolk living in the mission map, with the chance of another 40 or so invaders invading at any time.
The townsfolk will spend a lot of their times inside buildings. This alone will help the rendering overhead. I can't help but wonder if having 50 DIFs in town isn't going to cripple me though since they don't occlude each other, or themselves. I've unfortunately had to keep the town area relatively flat so building there is possible. There are no robust terrain editing solutions that I have seen, so for now that is out. I might port the game (or a sequel) to TGEA if it looks like support there will be easier.
From what I can tell it is one of two things that is causing the framerate drops...
Either the rendering of so many polys is killing my GPU. Or the update packet structure from having so many visible bots is clogging the pipe. I've seen MMOs that reduce the frequency of position/animation updates from players and npcs in the distance to help save on bandwidth, so many I could apply those principles here too.
I've not seen any games that utilize real time DIF placement. Almost every game has preplaced static DIFs, or uses placeable DTS shapes that cannot be entered. Pathfinding is one reason why. The lightmap generation is another. First person games generally tend to have higher quality models too, so that limits just what can be done compared to the simple models found in most RTS games.
I think Savage was the closest thing to doing what I am doing, but if featured entirely different gameplay. I should go play it again sometime to see just what techniques they used.
03/13/2008 (12:45 am)
I am designing a first person, real time rpg strategy game. A large part of the game will be spent out doors building and tending to your town. You'll start with a handful of townsfolk and be able to assign them job types, and they'll go and do those jobs as they become available. I've already solved some of the more advanced problems... I should write a blog about it as its probably not anything I wish I post here. Suffice to say that end-game I am hoping to have 100-200 townsfolk living in the mission map, with the chance of another 40 or so invaders invading at any time.
The townsfolk will spend a lot of their times inside buildings. This alone will help the rendering overhead. I can't help but wonder if having 50 DIFs in town isn't going to cripple me though since they don't occlude each other, or themselves. I've unfortunately had to keep the town area relatively flat so building there is possible. There are no robust terrain editing solutions that I have seen, so for now that is out. I might port the game (or a sequel) to TGEA if it looks like support there will be easier.
From what I can tell it is one of two things that is causing the framerate drops...
Either the rendering of so many polys is killing my GPU. Or the update packet structure from having so many visible bots is clogging the pipe. I've seen MMOs that reduce the frequency of position/animation updates from players and npcs in the distance to help save on bandwidth, so many I could apply those principles here too.
I've not seen any games that utilize real time DIF placement. Almost every game has preplaced static DIFs, or uses placeable DTS shapes that cannot be entered. Pathfinding is one reason why. The lightmap generation is another. First person games generally tend to have higher quality models too, so that limits just what can be done compared to the simple models found in most RTS games.
I think Savage was the closest thing to doing what I am doing, but if featured entirely different gameplay. I should go play it again sometime to see just what techniques they used.
#6
Also, since you haven't mentioned it here, remember that DIFs can have LODs too.
03/13/2008 (2:55 am)
If you want that many buildings and characters visible at once, I would guess working with the LODs is your top priority regarding framerate. Try putting in some very low poly characters and buildings to verify that this is the issue. Also, since you haven't mentioned it here, remember that DIFs can have LODs too.
#7
I'd implemented the Terrain Occlusion optimization I found on here and that gave me another 10fps, bumping me to 70fps or so with no bots on the screen and 25fps or so with 100. So that right there was a decent improvement.
Does debug mode offer a way to capture the triangle count? I'd be interested to see what kind of counts I am getting right now.
03/13/2008 (7:03 am)
That is a great idea. It's really hard to say but I don't think the Kork model has LOD. At least I see no obvious change in poly count when running really far away from it. That could easily give me another 50-60% rendering capacity :PI'd implemented the Terrain Occlusion optimization I found on here and that gave me another 10fps, bumping me to 70fps or so with no bots on the screen and 25fps or so with 100. So that right there was a decent improvement.
Does debug mode offer a way to capture the triangle count? I'd be interested to see what kind of counts I am getting right now.
#8
read up on Zones and Portals to get a notion of how DIFs and player rendering interact in stock TGE.
then, if you feel like stepping outside of stock TGE, you might consider implementing some raycasts to each player object to test for occlusion. i had a similar situation with hundreds of players who were often occluded by buildings, and occlusion testing by raycasting improved framerates in those situations very dramatically.
one gotcha w/ testing for visibility via raycasts is that you can get false negatives.
for example, say you choose as your ray target the player's feet. then if the player is standing behind say a tree stump w/ its feet hidden, the whole player will be hidden. you can alleviate this a bit by casting multiple rays. I think i cast five, one to each of the corners of the camera-aligned bounding rectangle, and one to the center of it.
to optimize a bit, you can do the raycasts only every N frames (or better every Nth of a second),
and if the occluding objects don't move, you can also skip the raycasts if the camera & rendered player haven't moved beyond some threshold since last time.
somewhere in the forums is a length thread about this type of optimization,
but unfortunately forum search is highly unreliable, so good luck finding it..
03/13/2008 (8:38 am)
Little late to the party here, but -read up on Zones and Portals to get a notion of how DIFs and player rendering interact in stock TGE.
then, if you feel like stepping outside of stock TGE, you might consider implementing some raycasts to each player object to test for occlusion. i had a similar situation with hundreds of players who were often occluded by buildings, and occlusion testing by raycasting improved framerates in those situations very dramatically.
one gotcha w/ testing for visibility via raycasts is that you can get false negatives.
for example, say you choose as your ray target the player's feet. then if the player is standing behind say a tree stump w/ its feet hidden, the whole player will be hidden. you can alleviate this a bit by casting multiple rays. I think i cast five, one to each of the corners of the camera-aligned bounding rectangle, and one to the center of it.
to optimize a bit, you can do the raycasts only every N frames (or better every Nth of a second),
and if the occluding objects don't move, you can also skip the raycasts if the camera & rendered player haven't moved beyond some threshold since last time.
somewhere in the forums is a length thread about this type of optimization,
but unfortunately forum search is highly unreliable, so good luck finding it..
#9
That way you could have hilly/uneven terrain in the town and take advantage of the terrain occluding without making building a pain.
To add some occlusion between outside and inside:
You could also surround the town area with hills to isolate the town area and the outside area from each other.
Or, surround the town with walls, place a gate setup so you can't see out of it and portal it, then top it with a transparent top, so the player can see out at the sky but the engine still thinks of it as a solid LOS blocker. Turn your entire town into a big room.
03/13/2008 (10:57 am)
What about adding in a terrain deformation resource? When building you could have it grab the height at the entrance area of the building and use that to flatten an appropriate area for the building. You could even implement an area leveling portion to construction and/or increase building costs by how much landscaping must be done.That way you could have hilly/uneven terrain in the town and take advantage of the terrain occluding without making building a pain.
To add some occlusion between outside and inside:
You could also surround the town area with hills to isolate the town area and the outside area from each other.
Or, surround the town with walls, place a gate setup so you can't see out of it and portal it, then top it with a transparent top, so the player can see out at the sky but the engine still thinks of it as a solid LOS blocker. Turn your entire town into a big room.
#10
I am actually working on such a thing right now :P I'm very glad you found some benefit from it!
- Andrew
Reading about the terrain deformation resource left me worried the solution wasn't a simple one. I was more interested in getting a working prototype up so I can ensure the concept is solid before I spend 2 months implementing a working terrain deformer.
Walls aren't going to come with the town, so folks will need to build them in pieces. That will make portalizing it difficult. Interesting idea though.
Thanks for the posts!
03/13/2008 (11:40 am)
- OrionI am actually working on such a thing right now :P I'm very glad you found some benefit from it!
- Andrew
Reading about the terrain deformation resource left me worried the solution wasn't a simple one. I was more interested in getting a working prototype up so I can ensure the concept is solid before I spend 2 months implementing a working terrain deformer.
Walls aren't going to come with the town, so folks will need to build them in pieces. That will make portalizing it difficult. Interesting idea though.
Thanks for the posts!
#11
Later, when you are working on the alpha, add in the terrain deformer and reap the rewards of more occlusion.
03/14/2008 (11:53 am)
If you're just looking to get a prototype up, then just portalize the hell out of your buildings and replace the korks with a low poly model.Later, when you are working on the alpha, add in the terrain deformer and reap the rewards of more occlusion.
#12
03/14/2008 (7:42 pm)
Oh yeah I wasn't planning on doing all my pre-work like this. But I needed to make sure the engine can handle what I have in mind before getting too far along :P
Torque Owner Jason Gossiaux
Indie Dev
I need to do some testing, but do DTS shapes inside of portalized buildings get rendered when standing outside of them? I might be OK if they aren't rendered because at any given time 25% of the villagers will be inside buildings, 25% will be out gathering resources, and the other 50% will be walking around town and/or patrolling for enemies...
Another option would be to make the terrain less flat because it look like terrain occludes rendering. My only concern here is that unven terrain will be difficult to build on, especially since the HideTerrain option on DIF objects doesn't seem to work. The uneven terrain just bubbles right up through the bottom of them.
Does the default Kork model have LOD, and approximately how many triangles is it composed of? Reducing the complexity of my models is another way to get performance improvements I guess.
Thanks for any help people can give me!