Problem in understanding some scene graph issues
Posted 01 December 2005 - 02:54 PM
And i have other problem. Supose that we have a scene with an entity like a castle that is composed of many meshes and have a lt of geometry and occupies half of the scene. Imagine that we want to manage that with an octree. We have chosen to put in each cell of the octree the polygons of this big composed entity which are inside the cell so each cell maintains a lis of polygons that are inside it. Imagine that because we have LOD we have to change at a moment the model of one of the entities that are part of the composed 'castle entitie'. This entitie is loaded in the tree as individual polygons. Have we to eliminate the previous polygons of the entity and insert the new ones? Maybe im confusing terms in teh use of octrees?
I know that you can insert complete entities in the nodes of an octree. I f a cell of the octree is visible then the objects partially or totally inside it will be drawn, you can do that as well. But with a large complex entitie like the castle i described it almost always will be visible and you can render it completely because it will affect performance, you will have to render only the visible part of it so you will have to split it going to polygon level?
Am I wrong?
Please im meesing up myself with this issue and i will thank anyone who can answer me. Thanks:wallbash:
Posted 01 December 2005 - 05:35 PM
Also, note that you can have several scenegraphs that are used for different things, for example you might have an octree for rendering and a hierarchical structure for updating positions/animating and a bsp-tree for raytesting. It doesn't have to be one for all.
Posted 01 December 2005 - 07:01 PM
If i bring things to the limit i can ask: what happens if the entire entity is one big mesh?, for example a well detailed egyptian pyramid with a monstruous number of polygons. Maybe i a m saying things that have no sense in game development right?
I was only talking about rendering for the moment not updating geometry or testing collision detection. But in this case the updating wont be necessary as im only talking about static geometry , am i wrong? Have I understood what you said in other way?
Thanks for your reply. :lol:
Posted 01 December 2005 - 10:31 PM
When rendering a big mesh, like your example pyramid, several things can potentially be the limiting factor. For example, if you sent each triangle individually, with one DrawPrimitive call for each, you would quickly become CPU bound; you would spend more time in DirectX and the driver than actually rendering stuff. If there's loads of polygons, you might get transform bound, because of all the vertices that the GPU would have to deal with, especially on older cards.
My point is, that IF you are transform bound, your pyramid with millions of polys would cause a problem, and you could solve that by reducing the number of polys, cut it up to make better use of your octree, or using LODs). But if you're not transform bound, then it won't affect your framerate any more than rendering just one polygon. Because if you're not transform bound, but say CPU bound for example, it means that the transformation part of the pipeline is always waiting for more stuff to do, so throwing more triangles on it, without increasing the number of draw calls (each draw call uses up CPU power), will not affect framerate at all. It will just mean making better use of the available GPU power.
Posted 02 December 2005 - 09:31 AM
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users