Archived

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

Acid-Chris

Octree improvements

Recommended Posts

Hi there! i have a question about improving an octree system. let''s assume we use a very detailed scene with many triangles. in scene-edit-mode, we set the camera position and the target point. after gathering this information, i create the octree. now my question. is it really necessary to calculate the octree again during runtime? i mean, i did it once why re-calculate? camera position does not change at all. is it possible to store the calculated octree values and just re-load them at startup? this will give a huge speed boost!! correct me if i''m wrong in my assumption! are there any informations about this? if so, please post a link! or if you have any other great ideas, please let me know! many thanks in advance, - Christoph -

Share this post


Link to post
Share on other sites
Generally you''d precalculate your octree and never really rebuild it during run time, except in special, weird cases!
Rebuilding the octree every frame kind of misses the point of having an octree. You want to cut down on the stuff you send to be drawn, but you''re doing loads of CPU calculation every frame!

So, Precalculate the octree and store it in a file, then load the file.
The octree shouldn''t change no matter where you are looking from and to.

Alex

Share this post


Link to post
Share on other sites
While I don''t have time for an in-depth explanation. The basic idea behind saving your octree is to make all structures/classes with the ability to save themselves. Thus if you ever use the structures in another area of your program, you do not have to rewrite the code to save them, all that then remains is to write a function in your class that goes through all the structures/member variables and calls their save function, passing in a file pointer (or a filename) specified upon calling the function. That''s how I go about it anyways, I''m not sure if it the best way, but it works for me. The way I worked on it was to write out the basic function, write all necessary data to file, free the class data, and test your save function by calling the load function and seeing if all goes to plan. If it does not, you can step through your code and check if any important data has been missed out in your save routines.

Some things to watch out for are ensuring your node structure is preserved when saving and reloading. Any NULL pointers in the node structure should be written to file as a delimiting character, otherwise the load routine will not pick up on the fact that a portion of the tree has been completely loaded (no character will be written to file when saving), and will continue to load nodes from other parts of the tree because it would never be told to recreate the null pointer. Also, when storing pointers to data, perhaps pointers to vertices, the memory location of the verticees will obviously change the next time the vertices are recreated, so instead you need to store the location of the vertices in your structure, or a unique ID or something similar.

Hope that helps,

Cheers,

Steve

Share this post


Link to post
Share on other sites
First of all, thanks for your replies.

Alex:
i do not re-calculate the octree every frame. i know an octree-system very well!!

I will post some notes for clarification:
- After i created the octree -> store it. (however, whatever...)
- at game-startup, load the octree values for intersection tests.
and i think this will give the speed boost!
why calculate the octree for every game scene (rooms)? this is a waste of CPU time because it never changes! calculating the octree can be done after the level has been created with the editor.

Does anybody have a source snippet what data has to be stored, cuz i''ve no idea!

thanks again!
- christoph -

Share this post


Link to post
Share on other sites