Jump to content
  • Advertisement

Archived

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

tcs

Display lists and Octrees

This topic is 6927 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

Just an idea. Would it be a good idea to compile every Octree node into a display list ? This would reduce the overhead to build the current frame, and reduce the overhead that occurs when passing all the faces from the Octree structure to the renderer...

Share this post


Link to post
Share on other sites
Advertisement
Be careful about your textures. I wouldn''t want to give up being able to render the pieces of geometry in texture order. For example, if you''ve got a room busted up into 8 sections by the octree and each section is using the same 4 textures you could swap textures 4 times or 32...

Share this post


Link to post
Share on other sites
State change don''t seem to be so expensive...
Do you think I should sort the textures inside a node, o should I quicksort all textures (every frame) before I render them ?

Is a quicksort and all polys passed separate faster than a few state changes, display lists and no quicksort ?

Share this post


Link to post
Share on other sites
Actually, to correct you, texture state changes kill. That''s all there is to it. If you could waste 3 ms per frame just figuring out which poly''s to draw with each texture, that would be a heck of a lot better than doing it on the fly. Basically, textures are loaded to the most optimal areas of memory - usually the processor''s on-die cache for smaller textures. Whenever you switch textures, it has to go there and swap the new texture into that memory, causing a pretty bad performance loss. Definitely go for the loss in sorting and you will gain tenfold in rendering. Also, display lists don''t make an incredible performance increase, but mostly make rendering easier on us hardcore coders. Anyway, good luck in your quest.

Pythius

Share this post


Link to post
Share on other sites
AHHHHH....

I have been wondering why a texture change with textures that have already been loaded into video card memory can still be expensive. Never understood.

Thanks =)

Share this post


Link to post
Share on other sites
You don''t need to quicksort the polys. In each node of the octree, collect all the polys that use a certain texture/material. Also have an array of structures for all the textures in the environment. When you traverse the octree and hit a node, for each collection of polys add it to a linked list hanging off the texture''s structure used by the collection. Once you''ve traversed all the nodes you''ll have a list of poly collections hanging off each texture. Loop through the textures and render each poly collection. This doesn''t require any sorting, the minimal work is done once per poly collection, not per poly, and you only need to loop through your list of textures in the end. It also guarantees using each texture only once.

Each one of the poly collections could be compiled into a display list.

Share this post


Link to post
Share on other sites
yes, this sounds like it works very easy, and it''s faster than the Octree. I can pass the liked list from node to node... yes, thanks!

I''m trying to get a demo up, but I still need a proper collision detection (better, a proper collision handling) and need to port my renderer to the Octree.

check http://glvelocity.demonews.com/ for the upcoming demo

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!