Quote: Original post by v71
Once, i posted a linked link source code for the comunity, i had a furious flame war about not using stl , of course i wasted my education and i am a very unfriendly and unhelpfull person.
YOU ARE A BUNCH OF KIDS,
now rate me noooooooooooooooooooooooooooobs

Lol.

woohoo it works! thanks alot shadowwz.
now its time to start lookin for STL tutorials lol. maybe a little further down the road.

actually would STL help me at all with building 8 way linked lists for octrees? or should it be 6?

Oooh, you're talking about trees now, they're a different kettle of fish all together. For an octree, you'd have 8 children per parent, hence the oct in there.

Linked list are not the best way to handle octree. Why would you want to use it there? You simply have array of 8 pointers to child nodes. And if you were thinking of putting all nodes in one big list then go with vector becouse you'll get O(1) element accces that you sometimes might need.

There are a couple of STL tutorials around the net. But if you don't know templates you might want to look at them for a bit, or STL will look a bit confusing at first.

edit: python_regious beat me to it.. agian :)

so _DarkWIng_ so what you are saying is make something like this:

struct child_node{   child_node*  _node[8];}

Yes. Or like this:

struct child_node{   child_node** _node;}

It saves a bit space... but has some negative "side effects".

A stylistic issue that you might wish to consider: Some names with leading underscores (i.e. names of the form _name) are reservered by the standard, so Herb Sutter recommends using trailing underscores instead (i.e. name_). That way you won't ever hit wierd naming problems when you accidentally use one of the reserved names.

<Advanced>_DarkWIng_: Just off the top of my head would it be any better for each octree node to simply store a pointer into a single contiguous array allocated for the octree as a whole, thus improving locality of reference? I.e:

Octree: [xxxxxxxxxxxxxxxxxxxxxxxx]         \      /\      /\      /          Node_1  Node_2  Node_3

Probably a premature optimisation, but just something that occured to me. I'd be interested to know your thoughts.</Advanced>

Enigma: I came up with same idea once. But it doesn't work as good as I tought at first. It's very usefull if you need to find neighbour nodes but thats about it. Speed increase in transeversing is zero to none. Simply becouse you don't transverse it in linear order. You can replace depth-first search with breadth-first search but memory overhead will negate all benifits. My best advice is to keep Node structure as small as you can so more of then can fit into cache.

one of my original ideas for the octree would be to put 6 pointers inside each node. each of those pointers would point to a neighboring node. when the player moves to another node there is a simple pointer to the neighboring node, or is that too much work?

Quote: Original post by adam17
im not too clear on what your saying

I apologise. What I was trying to say was wrong, so don't worry.

I guess I was too tired. Sorry.