our dem data is 500*500
so i think ROAM &quadtree iare not good ideas for simulate 3d terrain
i prepare to use “progressive meshes”
,but rare resource could i find,who can help me ?
examples is perticular welcome 
Why would not ROAM be suitable???
I wrote a ROAM demo and I put a heightmap of 1024x1024 and I get it up 300 fps… I have not even done queue merging.
Miguel Castillo
Originally posted by ruixp:
our dem data is 500*500
so i think ROAM &quadtree iare not good ideas for simulate 3d terrain
i prepare to use “progressive meshes”
,but rare resource could i find,who can help me ?
examples is perticular welcome
but my data is not power(2,n)power(2,n)
my data is 750500,and there are about 1000 dem data file
i think roam can’t deal with those file
Well, I think you dont have clear what ROAM does for you. Roam only create the mesh. You are in charge of feeding the data and making ROAM deal with your data…
For example, I have my algorithm partition my terrain into chunks of size provided by me. I also connect the bordering chunks for infinite terrain generation. Either one is part of the ROAM algorithm… In the same way, you are in charge of letting ROAM know how to process your maps. If they are not square maps, you are in charge of providing the proper data to ROAM for processing.
Square maps are only for simplicity, but if you can make your engine process non-square maps, you are good to go.
Anyways, I think you might want to check my implementations out. http://cheo.resnet.wayne.edu/miguel/
Miguel Castillo
p.s. If you want to talk for a bit about ROAM, you can msn with me at mancha_c@hotmail.com
Originally posted by ruixp:
but my data is not power(2,n)power(2,n)
my data is 750500,and there are about 1000 dem data file
i think roam can’t deal with those file
[This message has been edited by mancha (edited 03-09-2003).]
thanks ,mancha
i hope i can get information about ROAM FROM YOU,i have some artilces about ROAM,i will study them firstly
i still think the dem data file should
be [power(2,n)+1][power(2,n)+1] even if we use roam to simulate terrain
who will explain for me how to deal with data file such as 750500
Ok, you have 750 rows and 500 columns.
The point is not how roam is going to deal with the data, but how you will deal with the data…
For simplicity, I am going to use a 2d array…
So, how would you access the heightmap buffer??? Well, you can have a nested for loop. One dealing with your rows, and one dealing with your columns…
for( int rows = 0; rows < 750; rows++ )
{
for( int col = 0; col < 500; col++)
{
heightmap[col][rows]; //However you want to access your data.
}
}
Right there you are dealing with a map that is not square…
Now you might ask how is ROAM going to create the triangles???
Remember that ROAM knows of no real world coordinates, so if you have a 250x300 or a 300x10000, ROAM will not know what those numbers represent or if they are different, as long as you provide the appropriate coordinates for the triangles to be split…
You can make your data floats, so that you get a better approximation when you split the triangles. So, how do you split the triangles???
Say you still have your 750x500… You can make a big square that has coordinates
v1 = (0,0); v2 = (0,750); v3 = (500, 750); v4 = (500, 0), which makes both of the parent triangles that conform your initial mesh to be split.
So, as you saw in my terrain engine, you will provide data as follow.
v2-----------v3
| ------------- |
|---|
| ------------- |
| ------------- |
| ------------- |
| ------------- |
| ------------- |
| v1------------v4 |
RecurseTessellate( &curr_patch->m_BaseLeft, v1, v2, v4, 1 );
RecurseTessellate( &curr_patch->m_BaseRight, v3, v4, v2, 1 );
Let my code take care of the splitting if you are using it. You only have to make minor changes to my code make it work with non-square maps.
Miguel Castillo
Originally posted by ruixp:
i still think the dem data file should
be [power(2,n)+1][power(2,n)+1] even if we use roam to simulate terrain
who will explain for me how to deal with data file such as 750500
[This message has been edited by mancha (edited 03-10-2003).]
as your idea
v2-----------v3
| ------------- |
|---|
| ------------- |
| ------------- |
| ------------- |
| ------------- |
| ------------- |
v1------------v4
RecurseTessellate( &curr_patch->m_BaseLeft, v1, v2, v4, 1 );
RecurseTessellate( &curr_patch->m_BaseRight, v3, v4, v2, 1 );
when we split,(v4+v2)/2.0 means ???
v2-----------v3
| ------------- |
|---|
| ------------- |
| ------------- |
| ------------- |
| ------------- |
| ------------- |
v1------------v4
RecurseTessellate( &curr_patch->m_BaseLeft, v1, v2, v4, 1 );
RecurseTessellate( &curr_patch->m_BaseRight, v3, v4, v2, 1 );
I think there must be some data not used forever!
Say (v4+v2)/2.0 = new_Apex. Let’s call it v5.
Well, when we have new_Apex, we are splitting the line from v4 to v2 in 2 to make two new triangles… So, from the quad that was made of two triangles (v1, v2, v4) and (v3, v4, v2), we will now have four triangles that are:
tri1 = (v5, v1, v2)
tri2 = (v5, v4, v1)
tri3 = (v5, v4, v3)
tri4 = (v5, v2, v3)
v2-------v3
|-------/-|
|–-—/–|
|—--/-- |
|----v5—|
|—/–-–|
|–/------|
|-/-------|
v1-------v4
The rescurse tessellation takes triangles independently so that we can keep on passing the vertex data of the new triangles recursively.
When do you stop splitting? When you have met the MIN_LOD (smallest triangle) or when your MAX_ERROR is small enough to stop the split.
You will have tons of recomputation every frame, but you deal with those issues with many approaches such as a merging function. Way too early for us get into this though.
Originally posted by ruixp:
[b]as your idea
v2-----------v3
------------- ------------- ------------- ------------- ------------- ------------- v1------------v4
RecurseTessellate( &curr_patch->m_BaseLeft, v1, v2, v4, 1 );
RecurseTessellate( &curr_patch->m_BaseRight, v3, v4, v2, 1 );
when we split,(v4+v2)/2.0 means ???
[/b]
[This message has been edited by mancha (edited 03-11-2003).]
if(v4+v2)/2.0 = new_Apex. then
it will gernerate a point that is not so accurate after every splitting,because
it will not be in the dem matrix in common condition ,let’s see
such dem data ,4*6
save as height[4][6]
when first splitt,just as you says
(v2+v4)/2.0 is not the data in height[4][6],do you think so?
hi, i am still waiting for your help:0
Since you are dividing distances that are not of a square map, you would expect error. But the reason why I would choose float for the partitioning is because the accumulated error is not going to be as big.
So you are right, you will be having some kind of innacuracy, but it is very small. So, how can you deal with the data??? Well, you can average two other surrounding pixels in the map that are along the splitting line. I would not bother with the whole innacuracy too much because it is not that big anyways. Unless if you have some extremely rough terrain and you have each pixel representing 20 meters in real life. Then you will have more problems.
I dont think that the case for you though.
Originally posted by ruixp:
hi, i am still waiting for your help:0
just a quick congrats. That roam Terrain of yours looks very tasty Was it in Flipcode a couple of weeks ago? I remember seeing one in the “Image Of The Day Gallery”.
Well, thank you very much… Positive feedbacks are always nice.
I have actually not put it up on flipcode yet. But I will try to make it to the front page when I finish my per pixel lighting.
Thanx
Originally posted by oliii:
just a quick congrats. That roam Terrain of yours looks very tasty
Hi ,mancha
i wrote a programe follow your prorgam about ROAM in your website,and there is some problem, i send my problem to you,wuold you like to help me to deal with this problem?
That is going to cost you a beer.
Send it right over man.
Miguel Castillo
Originally posted by ruixp:
[b]Hi ,mancha
i wrote a programe follow your prorgam about ROAM in your website,and there is some problem, i send my problem to you,wuold you like to help me to deal with this problem?
[/b]
if i can,i am pleased!!
Hey man, I am waiting for you program and my beer. Email me you program and tell me about the problem you are having. mancha_c@hotmail.com
We will save that beer for some other time.
Later,
Miguel Castillo
Originally posted by mancha:
[b]That is going to cost you a beer.
Send it right over man.
Miguel Castillo
[/b]
ok,do u recieve it?
Originally posted by mancha:
[b]Hey man, I am waiting for you program and my beer. Email me you program and tell me about the problem you are having. mancha_c@hotmail.com
We will save that beer for some other time.
Later,
Miguel Castillo
[/b]