Method to use trees
Author
Everywhere I read I see the use of octTree and quadTrees where the actual polygon data is stored in the nodes of the tree. Then culling the tree returns a list of actual polygons to render.
What if I employ a tree (octTree for instance) where the nodes store ONLY pointers to mesh objects.
Now, each individual mesh object has it''s own render function to draw itself with. Say I cull this tree against the frustum. Inside of the visible nodes are pointers to mesh objects that I return via the cull operation. Now I just traverse that returned list and render all of the items in it back to front to ensure proper translucency.
This as opposed to figuring out ALL of the polygons in a mesh clipping polygons to node boundaries, etc seems easier and more efficient. Now if I add a mesh manager that stores all polygon data in a static vertex and index buffer, each cMesh item can just register itself with a set of array indices to use when it calls render. This gives instant mesh management also.
Would something like this work? I''m writing up a test of it now to see how it would look but so far I can''t see anything wrong with doing it this way.
TIA
Webby
well, the goal behind an octree or quadtree is to reduce/eliminate overdraw. if i understand your idea correctly you are talking about storing a pointer to a mesh object that will contain a number of tris.
ill start by saying im no scenegraph expert so im just giving my educated opinion.
while your method is simpler and does reduce the computation requirements necessary for a decent scene manager, it also overlooks the most basic premise of scene management.
the entire scenegraph paradigm is about shifting the load from your graphics card and rendering pipeline to your CPU. Your method would be 100% or 200% better than just brute forcing all your geometry to your renderer, so implement this if nothing else. but ideally you want to create an efficient method that is computationally fast and at the same time approaches 0 overdraw. You''re looking to satisfy the old "the fastest triangle is the one that is not rendered" cliche''.
So yeah, any culling is better than no culling at all.(so long as the computation speed is decent)But ultimately your goal will be to balance the workload heavily in favor of your cpu(or GPU if you can figure it out), and have a well organized stream of pertinent data flowing down your rendering pipeline as fast as you can.
Dredd
________________________________________
"To die with your sword still in its sheath is most regrettable" -- Miyomoto Musashi
ill start by saying im no scenegraph expert so im just giving my educated opinion.
while your method is simpler and does reduce the computation requirements necessary for a decent scene manager, it also overlooks the most basic premise of scene management.
the entire scenegraph paradigm is about shifting the load from your graphics card and rendering pipeline to your CPU. Your method would be 100% or 200% better than just brute forcing all your geometry to your renderer, so implement this if nothing else. but ideally you want to create an efficient method that is computationally fast and at the same time approaches 0 overdraw. You''re looking to satisfy the old "the fastest triangle is the one that is not rendered" cliche''.
So yeah, any culling is better than no culling at all.(so long as the computation speed is decent)But ultimately your goal will be to balance the workload heavily in favor of your cpu(or GPU if you can figure it out), and have a well organized stream of pertinent data flowing down your rendering pipeline as fast as you can.
Dredd
________________________________________
"To die with your sword still in its sheath is most regrettable" -- Miyomoto Musashi
Author
That''s why my idea to separate by pointers instead of actual polygon data. A single pointer for a character can represent 10,000 on a character (maybe more or less). Lots of things can be stored inside of a single mesh object and culled simply by asking (Is my KEY vertice in view). This would save tons of cycles over just calculating for every polygon possible, splitting those polys that fall on a border (unless I implement YannLs tree).
I''m also thinking that I have very broad types of objects that will share similar textures. Trees, in a local area can often use the same texture. So the engine can return sets of object that share the same textures. Now, how I would go about rendering texture sets at a time and still hold the back to front ordering escapes me.
Someone mentioned that I could just draw the entire scene and use z-order to make sure objects are displayed back to front as normal and then make another pass for all of the transparent stuff. That is definitely an option I will look in to.
I''m angious to get this up and running to see how it works out.
Thanks,
Webby
I''m also thinking that I have very broad types of objects that will share similar textures. Trees, in a local area can often use the same texture. So the engine can return sets of object that share the same textures. Now, how I would go about rendering texture sets at a time and still hold the back to front ordering escapes me.
Someone mentioned that I could just draw the entire scene and use z-order to make sure objects are displayed back to front as normal and then make another pass for all of the transparent stuff. That is definitely an option I will look in to.
I''m angious to get this up and running to see how it works out.
Thanks,
Webby
Im currenty using the object-octree your talking about. This is mainly for a tile-type mesh that fits neatly into the nodes. The one thing is that if you want to a use an object in more than one place you have to use a tree of a custom type, that includes position/rotation ect.. I have a class called tile that is what the actual tree is made of and provides the pointer you were talking about, to the actual mesh object (list). It currently works well for me, as im trying to keep my design simple. Works well for me. Good luck, I would like to hear about your results.
Author
Results to come after finals (first week of December).
Last semester! Nice (shiny?) degree paper for me.
Hoping I can put it to use somewhere. Job market in my neighborhood is pretty slim...
Must study...code later
Thanks,
Webby
Last semester! Nice (shiny?) degree paper for me.
Hoping I can put it to use somewhere. Job market in my neighborhood is pretty slim...
Must study...code later
Thanks,
Webby
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
