Re: [Algorithms] Octree leaf neighbours

[<SHA...@ao...>]

In a message dated 16/07/00 19:19:50 !!!First Boot!!!, sa...@ip... writes:

<< John,
 
 I'm sure I mean six. Above,Below,Left,Right,Forward and Back. (Don't care
 about diagonals).
 
 Yes I am recursing through the tree, and yes each node is "in play" during
 the traversal. But I'm doing a "marching cubes" type of thing, I need to
 share vertices between nodes. To do that I need to look at my neighbours,
 see if they have been processed, and if so use their vertex instead of
 generating a new one.
 
 Yeah, If I store a pointer to parent I can traverse "up and round" to find
 my neighbour. But whether this will save me any time over just generating
 new vertices and not sharing. Time to suck it and see.
 
 Thanks,
 
 Sam.
  >>

Sorry about that, I obviously misunderstood your question.

Currently what I do is give every triangle an index number, I don't store the 
actual vertices in the octree.
I then create an array of boolean variables, one for each tri, and set them 
all to false.
When I do the visibility check, if a tri is in a visible node then I flag 
that boolean element to true.
This is done, what I will do next....
Finally when the visibility test is finished, for every tri that has a true 
flag it's 3 verts are copied to a vertex buffer.
The triangles are all random except for one important thing, they are in 
texture order.
This means I will be able to do the minumum amount of settexture renderstates 
since they will all be in order in the vertex buffer, and I will draw them 
with DIPVB.

that's when I get some spare time! :)

Regards,

John.