TX3D 3.1.5 Beta - Rendering issue (culling?)
by Henry Shilling · in Torque X 3D · 07/04/2010 (2:53 pm) · 15 replies
Build: 3.1.5 Beta
Platform: Windows 7-64 (specs i7 920, nVidia GTS250 6GB ram)
Target: VS2008, Xbox
Issues: Terrain does not block rendering of objects hidden by terrain.
Steps to Repeat:
1) I created a "town" area inside of a terrain "bowl".
2) I created another outdoor dungeon area a "walled garden" about 50 terrain blocks away.
3) I place my player inside the dungeon area, and do a 360.
4) when the character faces the town area the framrate drops to about 1/3 of the framerate not facing the town. I will get 55-60+ FPS normally, but when facing the town I get 18-19, even though there are two full terrain walls 30+- units high between.
Suggested Fix:
Shouldn't the renderer see the wall and stop looking beyond? Especially so far beyond? Perhaps I have something set incorrectly? I first noticed this in the town area as it seemed shapes and terrain I set up as visual blocks had not effect on and sometimes worsened the framerate.
This is my terrain block:
This is on the PC the fps is usually over 110:
Platform: Windows 7-64 (specs i7 920, nVidia GTS250 6GB ram)
Target: VS2008, Xbox
Issues: Terrain does not block rendering of objects hidden by terrain.
Steps to Repeat:
1) I created a "town" area inside of a terrain "bowl".
2) I created another outdoor dungeon area a "walled garden" about 50 terrain blocks away.
3) I place my player inside the dungeon area, and do a 360.
4) when the character faces the town area the framrate drops to about 1/3 of the framerate not facing the town. I will get 55-60+ FPS normally, but when facing the town I get 18-19, even though there are two full terrain walls 30+- units high between.
Suggested Fix:
Shouldn't the renderer see the wall and stop looking beyond? Especially so far beyond? Perhaps I have something set incorrectly? I first noticed this in the town area as it seemed shapes and terrain I set up as visual blocks had not effect on and sometimes worsened the framerate.
This is my terrain block:
<Terrain type="GarageGames.Torque.T3D.XTerrain" name="Terrain">
<Position>
<X>1028</X>
<Y>1028</Y>
</Position>
<HorizontalScale>8</HorizontalScale>
<Data type="GarageGames.Torque.T3D.TGETerrainData">
<TerrainFilename>dataterrainsflat.ter</TerrainFilename>
<TexturePathSubstitution>dataterrains</TexturePathSubstitution>
<LightMapFilename>dataterrainsflat.png</LightMapFilename>
<IsLightingEnabled>true</IsLightingEnabled>
<DetailMaterial />
</Data>
<ViewError>4</ViewError>
<LODError>0.5</LODError>
<LevelZeroError>0</LevelZeroError>
<Components>
<T3DSceneComponent type="GarageGames.Torque.T3D.T3DSceneComponent">
<ObjectType>
<object objTypeRef="Terrain" />
</ObjectType>
</T3DSceneComponent>
<T3DRigidComponent type="GarageGames.Torque.T3D.T3DRigidComponent">
<CollisionShapes>
<XMLCollisionShape type="GarageGames.Torque.T3D.T3DRigidComponent+XMLCollisionShape">
<Shape type="GarageGames.Torque.T3D.RigidCollision.CollisionXTerrainShape" />
</XMLCollisionShape>
</CollisionShapes>
<GravityScale>0</GravityScale>
<Mass>0</Mass>
<Kinetic>true</Kinetic>
<Immovable>true</Immovable>
<RigidManager nameRef="RigidManager" />
<RigidMaterial type="GarageGames.Torque.T3D.RigidCollision.RigidMaterial">
<KineticFriction>0.9</KineticFriction>
<StaticFriction>1.5</StaticFriction>
</RigidMaterial>
</T3DRigidComponent>
</Components>
<ObjectType>
<object objTypeRef="Terrain" />
</ObjectType>
</Terrain>This is on the PC the fps is usually over 110:
About the author
http://twitter.com/theBigDaddio
#2
If we cannot get better rendering then we will have trivial games.
07/07/2010 (11:50 am)
There must be something that can be done no? Dropping below 20fps on the Xbox is not really something we can live with. The other choice is not have much stuff in games made with TX3D. If we cannot get better rendering then we will have trivial games.
#3
How many meshes are in your scene?
The big issue i've seen on Xbox is that the built in rigid body physics is crazy slow.
07/07/2010 (2:29 pm)
@HenryHow many meshes are in your scene?
The big issue i've seen on Xbox is that the built in rigid body physics is crazy slow.
#4
And this is inly one area: I want to have 4 or 5 more. I guess the trees do not need collision, or only a few do.
The static collision is like a house so you cannot walk through it. I will do some experimenting with Turning off collisions except where neccesary, as well as maybe replacing the collision mesh with a box or sphere.
Does anyone know if TX3D can use a collision mesh built into the DTS like T3D does?
80 objects is not really that much, The houses are under 300 poly's. The trees are from the sticks and twigs pack.
07/07/2010 (6:07 pm)
There are about 80 Static objects built like so:<TorqueObject_5560998 type="GarageGames.Torque.Core.TorqueObject" name="TorqueObject_5560998">
<Components>
<T3DStaticTSRenderComponent type="GarageGames.Torque.T3D.T3DStaticTSRenderComponent">
<ShapeName>datashapestownhousetallhouse.dts</ShapeName>
</T3DStaticTSRenderComponent>
<T3DStaticGeometryComponent type="GarageGames.Torque.T3D.T3DStaticGeometryComponent">
<ObjectType>
<object objTypeRef="StaticGeometry" />
</ObjectType>
<Position>
<X>962.5468</X>
<Y>1007.703</Y>
<Z>1.692179</Z>
</Position>
<Rotation>
<Z>-0.02185647</Z>
<W>-0.9997615</W>
</Rotation>
</T3DStaticGeometryComponent>
<T3DRigidComponent type="GarageGames.Torque.T3D.T3DRigidComponent">
<CollisionShapes />
<Mass>0</Mass>
<Kinetic>true</Kinetic>
<Immovable>true</Immovable>
<RigidManager nameRef="RigidManager" />
</T3DRigidComponent>
</Components>
<ObjectType>
<object objTypeRef="StaticGeometry" />
</ObjectType>
</TorqueObject_5560998>And this is inly one area: I want to have 4 or 5 more. I guess the trees do not need collision, or only a few do.
The static collision is like a house so you cannot walk through it. I will do some experimenting with Turning off collisions except where neccesary, as well as maybe replacing the collision mesh with a box or sphere.
Does anyone know if TX3D can use a collision mesh built into the DTS like T3D does?
80 objects is not really that much, The houses are under 300 poly's. The trees are from the sticks and twigs pack.
#5
http.developer.nvidia.com/GPUGems/gpugems_ch29.html
roecode.wordpress.com/2008/02/18/xna-framework-gameengine-development-part-13-oc...
This is why I bought and use the Torque Engine, it's supposed to do the heavy stuff for me to amplify my abilities. If I have to write my own culling stuff, then I am writing rendering, then I am getting into territory where I may as well not use the engine.
And yes I did lower the polys of all the objects that helped quite a bit. Removing the collision did nothing.
07/10/2010 (1:33 pm)
I have done some more research, while I do not think it would be trivial, I also do not think that its all that bad to do Occlusion Culling. Do a google on occlusion culling.http.developer.nvidia.com/GPUGems/gpugems_ch29.html
roecode.wordpress.com/2008/02/18/xna-framework-gameengine-development-part-13-oc...
This is why I bought and use the Torque Engine, it's supposed to do the heavy stuff for me to amplify my abilities. If I have to write my own culling stuff, then I am writing rendering, then I am getting into territory where I may as well not use the engine.
And yes I did lower the polys of all the objects that helped quite a bit. Removing the collision did nothing.
#6
I also should state that none of my experiments were executed under T3D(yet, but i know it works in T3D) or similar rendering systems. And I am 99% ignorant about TX3D.
My view Occlusion blocker. is quite raw and simple. You would need to find the most optimal stage in the rendering mechanics of TX3D, and do whatever TX3D's equivalence to gClientContainer.collideBox.
I often hear such as Matt Fairfax's comments about render occlusion being overly expensive, but i can not fine sufficient evidence from any/every experiment i have executed to test my ignorance, on the subject (something i would love to fully understand). Under every condition I have thought to test, my method proves itself to be better then NOT using Occlusion.
EDIT: unmuddy the English
07/10/2010 (2:22 pm)
I know this is not exactly pertinent to your problem, being its from TGEA days, it is not fully polished being one of my prototyping experiments.I also should state that none of my experiments were executed under T3D(yet, but i know it works in T3D) or similar rendering systems. And I am 99% ignorant about TX3D.
My view Occlusion blocker. is quite raw and simple. You would need to find the most optimal stage in the rendering mechanics of TX3D, and do whatever TX3D's equivalence to gClientContainer.collideBox.
I often hear such as Matt Fairfax's comments about render occlusion being overly expensive, but i can not fine sufficient evidence from any/every experiment i have executed to test my ignorance, on the subject (something i would love to fully understand). Under every condition I have thought to test, my method proves itself to be better then NOT using Occlusion.
EDIT: unmuddy the English
#7
This does not sit well. This means that everything in my scene is being rendered at all times as long as it is within the camera range. No matter if it is blocked or what.
That severely limits how complex any scene can be. Right now I feel like I couldn't make Quake 2 with the issues here.
I have had some success with using the camera, setting the FarDistance on the camera so that its not rendering everything in 1000 meters. However that means blocking all views always to less than whatever I set the FarDistance to.
07/10/2010 (5:02 pm)
@Caylo that was a good idea, however objects do not occlude either. Having an object block the entire view it still seems to render whatever is behind as well.This does not sit well. This means that everything in my scene is being rendered at all times as long as it is within the camera range. No matter if it is blocked or what.
That severely limits how complex any scene can be. Right now I feel like I couldn't make Quake 2 with the issues here.
I have had some success with using the camera, setting the FarDistance on the camera so that its not rendering everything in 1000 meters. However that means blocking all views always to less than whatever I set the FarDistance to.
#8
Try to locate if (aboveTerrain == false) within the source code. If you find that IF statement you should be in the method that checks shape object visibility occlusion from the terrain object. You may be able to splice a variation of my view Occlusion blocker into that system.
Sorry if my communication wording is difficult to comprehend. I am working under the cognitive occluding fog of a migraine (and having trouble comprehending my own train of thoughts).
07/10/2010 (6:04 pm)
By default Torque shape objects have never offered any view occlusion. The only Torque shape object occlusion considered is by nature of the Terrain object; this statement is based only in knowledge of TGE, TGEA, and T3D. Try to locate if (aboveTerrain == false) within the source code. If you find that IF statement you should be in the method that checks shape object visibility occlusion from the terrain object. You may be able to splice a variation of my view Occlusion blocker into that system.
Sorry if my communication wording is difficult to comprehend. I am working under the cognitive occluding fog of a migraine (and having trouble comprehending my own train of thoughts).
#9
Your communication is fine ;)
07/10/2010 (7:05 pm)
Right I get you, but the terrain in TX3D doesn't offer occlusion either. I'd be happy if the terrain would occlude, I can work with that.Your communication is fine ;)
#10
I can not form any hypothesis as to why TX3D would not have visibility occlusion from the terrain object, so I hope to see some type of explanation forthcoming in this thread. I am basing future purchasing options from what i may learn from Torque X 3D experiences as reported in the forums.
07/10/2010 (9:23 pm)
That is interesting. I can not form any hypothesis as to why TX3D would not have visibility occlusion from the terrain object, so I hope to see some type of explanation forthcoming in this thread. I am basing future purchasing options from what i may learn from Torque X 3D experiences as reported in the forums.
#11
I was working on a game engine for about 5 months before I bought TX3D. One of the things I implemented was a quadtree based terrain LOD system that used PVS (Potentially Visible Sets) for occlusion culling in XNA. It worked great, but it was daunting to create the PVS. I programmed an editor that imports a heightmap and lets you create a PVS from it. Anyway, it took a minute or two to process a 1k heightmap. That's not too bad for the payoff though. If you are interested here is a link explaining it and there is also a demo of it in action (it's not XNA, but it still gives you the principle). http://www.gamedev.net/reference/articles/article1936.asp You may want to note though that this does not occlude other objects; only the terrain. For other meshes you may want to try this: http://www.flipcode.com/archives/Simple_Terrain_Occlusion_Culling-Vystoc_VerY_Simple_Terrain_Occlusion_Culling.shtml I have not tried it, but it looks rather simple to implement and may just work.
I'm in the same boat as you though. I feel like I have to go back and add what should have been there already. I bought this so I could jump right into the project, but that's not going to happen sadly. I'm starting to think I should have just finished my engine... Working a full-time job, part-time job, and doing contract work is enough; I relied on this to take some of the load off.
07/23/2010 (7:51 pm)
@Henry - Any word on this? The project I am getting ready to work on relies heavily on the terrain (like many other games do).I was working on a game engine for about 5 months before I bought TX3D. One of the things I implemented was a quadtree based terrain LOD system that used PVS (Potentially Visible Sets) for occlusion culling in XNA. It worked great, but it was daunting to create the PVS. I programmed an editor that imports a heightmap and lets you create a PVS from it. Anyway, it took a minute or two to process a 1k heightmap. That's not too bad for the payoff though. If you are interested here is a link explaining it and there is also a demo of it in action (it's not XNA, but it still gives you the principle). http://www.gamedev.net/reference/articles/article1936.asp You may want to note though that this does not occlude other objects; only the terrain. For other meshes you may want to try this: http://www.flipcode.com/archives/Simple_Terrain_Occlusion_Culling-Vystoc_VerY_Simple_Terrain_Occlusion_Culling.shtml I have not tried it, but it looks rather simple to implement and may just work.
I'm in the same boat as you though. I feel like I have to go back and add what should have been there already. I bought this so I could jump right into the project, but that's not going to happen sadly. I'm starting to think I should have just finished my engine... Working a full-time job, part-time job, and doing contract work is enough; I relied on this to take some of the load off.
#12
However I agree we bought this so that we (well me at least) do not have to write a renderer, etc. I would expect IA/TP to get a rendering expert involved and make this the most robust rendering engine that can be for XNA. I am also certain that will happen.
07/23/2010 (8:03 pm)
I have not checked the new build for this, what I have done is limit the camera. I do not plan on having any sweeping vista's or anything like that so I just reduced the far distance of the camera, worked like a charm.However I agree we bought this so that we (well me at least) do not have to write a renderer, etc. I would expect IA/TP to get a rendering expert involved and make this the most robust rendering engine that can be for XNA. I am also certain that will happen.
#13
The least it could have is some sort of sectoring implementation for handling visibility, where you create boxes which are sectors and the areas that the sectors touch each other become visibility portals, so that way you sector your level in ways which choke off visibility as the player moves through them. For more open large environments you could sector your level and then have occluders, another object represented by a box, which simply just hide vis portals when they are fully occluded.
Performance wise you'd still end up having to use occluders wisely and sparingly, and also be wise about the max number of vis portals seen at one time, but that is how it is with developing games and level design, it just really sucks that none of these bare bone essential features are in TX3D.
08/01/2010 (7:01 am)
same mindset here, I early adopted TX3D and have found it lackluster with stuff like this, as far as being a game engine. The least it could have is some sort of sectoring implementation for handling visibility, where you create boxes which are sectors and the areas that the sectors touch each other become visibility portals, so that way you sector your level in ways which choke off visibility as the player moves through them. For more open large environments you could sector your level and then have occluders, another object represented by a box, which simply just hide vis portals when they are fully occluded.
Performance wise you'd still end up having to use occluders wisely and sparingly, and also be wise about the max number of vis portals seen at one time, but that is how it is with developing games and level design, it just really sucks that none of these bare bone essential features are in TX3D.
#14
I really don't know the motivations for building TX in the first place, I think MS probably approached GG to give XNA some credibility. It certainly took some time and new management for TX to get some serious attention.
As we can also all see there is no rush of builders making 3D or even 2D engines for XNA. I know there are a few alternatives in the free software world. They are definitely eccentric to say the least. Not at all well rounded.
08/01/2010 (12:33 pm)
I have seen that sort of culling business in other engines, maybe that would be easier to implement. I really don't know. If I were an expert on creating 3D rendering and such, I'd probably be writing something instead of asking... ;)I really don't know the motivations for building TX in the first place, I think MS probably approached GG to give XNA some credibility. It certainly took some time and new management for TX to get some serious attention.
As we can also all see there is no rush of builders making 3D or even 2D engines for XNA. I know there are a few alternatives in the free software world. They are definitely eccentric to say the least. Not at all well rounded.
#15
08/07/2010 (8:33 pm)
Logged for QA team (TQA-759) 
Associate Matt Fairfax
PopCap
A proper solution is far more complex and is unfortunately is outside of the scope of Torque X 3.1.5.