eduwushu at December 1st, 2005 09:54 — #1
Hi there. I have a doubt because im a beginner in engine development and i cant imagine how can be put togueter spatial organization using an octree in an scene graph for example and jierarchical organization of the objects (some objects are linked to parent objects and transform themselves relative to their fathers)
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:
mattias_gustavsson at December 1st, 2005 12:35 — #2
Personally, I wouldn't split it up. If it is just one big mesh, using the same texture/material, then I would just send the whole lot to the graphicscard in one DrawPrimitive/DrawIndexedPrimitive call whenever a part of it is visible. Pushing those extra polygons through is not likely to affect performance. If it is using several different textures/materials, it is not just one mesh, but several ones, then you would use that already existing division of the model, to determine which node to put each mesh in. But I wouldn't split meshes.
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.
eduwushu at December 1st, 2005 14:01 — #3
so as i can understand of your reply (correct me if im wrong) you said that one entity could be composed of various meshes and thats the detail which i was missing. The castle coul be composed of many meshes (or submeshes) which use each one a single texture and what you are managing really are those submeshes at octree level. It makes sense to me mmmppfff. That would solve my problem.Fro this i deduce that you in part delegate the responsability of deciding how many polygons would have an entity (or which submeshes will have that entity and how many polygon will have each one) to the person who uses the graph, if he or she decide to create an entity which has a million polygons in one of his/her submeshes it's not our problem and if part of it is inside a cell of the octree which is visible will be rendered completely ,right?.
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:
mattias_gustavsson at December 1st, 2005 17:31 — #4
The thing with games today is that there are several different steps that need to be done for a frame to be rendered. The CPU needs to run the game logic and send triangles to the videocard, the GPU needs to transform, light, and raterize the triangles. Any of those things can be a bottleneck for your specific game, and the one that is the bottleneck will determine how fast your entire game runs. The games speed is "bound" by that part of the execution, so you can be CPU bound (your game logic or the time spent in directx or the videocard driver is what's limiting the speed) or transform bound (the number of transformations of vertices being done on the GPU is what's slowing things down) or fill bound (the rasterization of triangles is the bottleneck) to name a few.
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.
eduwushu at December 2nd, 2005 04:31 — #5
Thank you very much for your response now i have thing mora clear than after , God bless the forums ant their people!!!! XD