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:
Please log in or register to post a reply.
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.
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
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:
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
Thank you very much for your response now i have thing mora clear than
after , God bless the forums ant their people!!!! XD