#### Archived

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

# Terrans again

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

## Recommended Posts

##### Share on other sites

Calculating each nodes neighbour is not very slow at all. It''s really quite fast the way I have done it. Besides it''s precalculated anyway ( you would store pointers to the left right up and down terrain "sectors" ), so whats the problem?

Death of one is a tragedy, death of a million is just a statistic.

##### Share on other sites
I came up with two algorithem, but they are both slow. Basicly I give every node unique ID. Then I search tree for node I'm looking for (I know how to calculate neighbours ID) for every node.... If you have any better idea just let me know

(When I say slow I'm thinking in terms of +20 seconds of precalculation for map with tree-depth of 8 or 9)

You should never let your fears become the boundaries of your dreams.

[edited by - _DarkWIng_ on September 15, 2002 12:52:56 PM]

##### Share on other sites
Well, what I did is create a "matrix" of pointers to leaf nodes. Basically an array of all the leaf nodes. When I''m generating the tree, I generate the ID of that leaf based on it''s spactial postion ( 2D terms ), and goto that entry in the leaf-node-array, and set that entries pointer to the this node of the leaf. I then walk through the array, setting ID''s for the adjecent leaf nodes [ for instance, for index "i", the left node would be i-1, the right node i+1, etc... ]. This added maybe... a second onto my loading time. Maybe a bit less. For a 1029x1029 terrain. For a 2049x2049... it was about 2 seconds. Not much. Besides, you could precalculate it all and save it in a file. Then you can just load the relationships between the nodes when you load the terrain ( the id''s that is ).

Death of one is a tragedy, death of a million is just a statistic.

##### Share on other sites
Nice idea. I'll try to code it tomorrow. But I don't know about saving this to file. How are you going to save memmory pointers? Now I have to get some sleep.

What about 1, 3 and 4? Any ideas... anyone?

[edited by - _DarkWIng_ on September 15, 2002 4:26:39 PM]

##### Share on other sites
Ah I never meant saving memory pointers, but rather the ID''s, so that all you have to do is just grab the pointer from the leaf-matrix-array-thingy.

Death of one is a tragedy, death of a million is just a statistic.

##### Share on other sites
For #1, I have not yet got that far, but one way I’m thinking to do it would be to render in two passes. The first pass traverses the quadtree/scenegraph in typical order and when it finds a node to render, it puts it into a separate display list. The display list can be arranged in order for fast rendering. That order can be based on front-to-back location, or other criteria like texture state. Then the second pass iterates through the display list and does the actual rendering to the graphics API. (These two passes might even be in two separate threads) As I said, I haven’t got this far myself, but that’s how I’m thinking about it.

Edit: After rereading this, I realized that you are already kind of doing what I said by sorting the nodes before rendering. So I guess I didn’t really add anything. But I wonder which sort order produces faster rendering, front-to-back order or texture order? I guess I’ll have to experiment later.

[edited by - JimH on September 17, 2002 1:25:50 PM]

1. 1
2. 2
Rutin
19
3. 3
khawk
18
4. 4
5. 5
A4L
11

• 9
• 12
• 16
• 26
• 10
• ### Forum Statistics

• Total Topics
633769
• Total Posts
3013754
×