• Advertisement

Archived

This topic is now archived and is closed to further replies.

From octree to rendering

This topic is 6059 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have a nicely working octree which feeds my visible objects into a list for rendering. My question is, what''s the best way to assure that I get the objects in groups of like textures to speed rendering? Currently, I feed all objects into one list and use a single texture. Obviously not very exciting :-) What is the recommended approach to feeding the objects in from an octree, but minimizing texture switching? Should I do something like a hash of lists with the key being the texture? This way, as I get each object from the octree, I can add it to the correct list in the hash for its texture. Then when I render, I would simply go through the hash and render each list sequentially. This seems a bit inefficient, but nothing else is immediately obvious. Can anyone provide any insight or great ideas. It''s obviously a fairly basic thing to do. thanks as always! Onnel

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
I use a suface ID for every polygon, (surface -> texture and diffuse, ambient and spec values etc)

Then in the culling I put each poly into the appropriate list, for example a poly with id 3 would go into render_lists[3]. And then the renderer does all state changes and renders all visible polys with each surface.

/Urbi

Share this post


Link to post
Share on other sites
Right, that's a bit simpler than doing it with a hash and lets you take unto account the other material features. Is it just as slow to swap those as it is to swap textures while rendering?

What happens if you have a large number of overall potential textures, though (say hundreds or even thousands) even if only a few of them are ever visible at once? Do you end up looping through an array that is 99% empty just to find the one object with material id 1056?

Thanks!
Onnel

Edited by - onnel on July 20, 2001 3:56:04 AM

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
True, but you test if (render_list.isEmpty()) for every list in the array. Yes it would be wasteful, but not very much so.

And considering that with thousands of textures you probably need to have a decent portal engine, you could (should) flush the textures that are not used in the current (or nearby) portals. I havent come around to that part yet.

I think changing glMaterialfv() is faster than texture binds and glTexEnv() changes. Sorry, no benchmarks I have.

I havent found a better way to do this yet. This in combination with a GeometryDataBase may prove to be nice ( I hope, havent gotten around to that part just yet)

/urbi

Share this post


Link to post
Share on other sites
Right, I think I slightly misunderstood something! Are your material ids assigned permenantly within your game engine or are they assigned at loading time?

If the latter, there is no problem. I was thinking more of a scheme where every texture in the game gets an id pernentaly in a resource file and these ids are not dynamically loaded.

I think you were talking about a dynamic id system which should work quite well and won''t suffer from too long an array. The only question is, when loading multiple objects with the same texture, how do you make sure they all have the same material id if the material id isn''t permenantly assigned?

I''m thinking if I allow a user to create a level with a level editor, how should I store/load the texture related data to make sure I end up with objects in my scene with the same material id when they have the same texture?

Thanks for answering these relatively simple (but not for me!) questions.

Onnel

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I separate a Texture Image and and texture attributes and surfaces:
Surface -> a texturehandler, and material properties
texturehandler -> pointers to texture images and properties for how this texture will be handled.
texture image -> a texture loaded from a file and stored in OpenGL (in my case)

I use Lightwave so all objects with the same surface name (thus same textures/ properties) will have a id for only one surface and will be stored in the same renderlist.

I think the lightwave approach is very good for these purposes. If you mean ''same texture'' as in exact same material props and texture this approach will work fine.

So I use Databases for textures, surfaces and geometries(soon). So they are only stored once, and ID''s for different polygons/ geometry sets can efficently be rendered.

Hope This makes sense.
/urbi

Share this post


Link to post
Share on other sites
I have been trying to figure out the most efficient way to handle octrees too. Currently my octree works fine but by the time I get everything out I''ve already wasted as much time as drawing every polygon anyways. Even if I eliminate half of the cubes with culling.

Currently I am keeping pointers to Triangle structures for each cube. Then I extract all of the triangle structures and pluck the indices out and copy them into an index array for each texture (which is specified with a texture id in the polygon structure).

However this really does seem inefficient to me. I am thinking that maybe having each cube keep its own index array for each texture. If it is a tree node then it will keep a master index/texture 2D array that contains all indices for all of it''s child nodes. Then each child node would also keep its own index/texture array, etc. This way if the entire cube is visible you don''t really need to query the child nodes you just take the master index array. If it is partially visible then you query the visible children.

I think keeping the index arrays in the cube instead of raw triangle data would be more efficient at render time because then you could copy all of the indices for each texture with a single memcpy call instead of index by index copying.

Then I am thinking of creating an octree compiler of sorts which will take a level which was for instance designed in 3DS Max. Maybe as part of my export filter so I can make use of the Max SDK utility classes . For each node in the tree it will perform PVS to keep a list of which nodes are possibly visible from the current node. Of course in most places alot of different nodes can be visible from any particular node depending on placement in that node or rotation. Maybe to speed things up we can keep several different versions of this list, one for each 5 or 10 degrees of rotation around the Y axis within that node. We would keep a list of node IDs for each set. Then in our master octree, we keep the heirarchal tree and also a linear array of OctreeNode pointers which correspond to these ID numbers for fast lookup.

Then since we have our master PVS sets for each node and Y rotation increment, we only need to do culling against 2 dimensions instead of 3. That might save some additional render time.

This would probably require alot of memory, but for my purposes I am writing a game which is targeted to be released around the middle to end of 2002 and am assuming end users with atleast 128MB of RAM. So it should be fine

Note that this is just theory right now, I don''t have a working model yet. Writing this post is actually helping me create my design for it. lol. If I get it working properly I will probably make the octree compiler and rendering code available free download. Gonna be my weekend project


Thoughts/comments/flames?

Seeya
Krippy

Share this post


Link to post
Share on other sites
Note also that this would probably require breaking up large polygons into smaller ones that do not cross large cube boundaries during octree compilation. Since we are keeping index arrays instead of triangle pointers we don''t have alot of flexibility to determine which triangles have already been drawn and too much overdraw would kill us.

We coule also keep another array of triangle IDs but I haven''t figured out a way to integrate this with my scheme yet that would keep our traversal efficiency. lol. I will be looking for a way though. Any ideas would be cool

Seeya
Krippy

Share this post


Link to post
Share on other sites

  • Advertisement