thankyou very much for the idea of vertex normals, i probably would not have thought that on my own and kept trying different flags and mabe even some shaders and stuff before giving up!

Here is a video of the new look thanks to modifying normals:
http://www.youtube.com/watch?v=6RvUfXQ8_ZA

an example code for how I implemented one of the edges (works for terrains with 33x33 vertexs)


notice how I commented this line:
//vec_set(c1.v.nx,mid_nml);
I forgot ent_setvetex uses dx coordinate system so z and y are swapped. I was getting really odd results till I realized and simply setting the parameters manually changing the axsis solved everything:
c1.v.nx=mid_nml.x;
c1.v.ny=mid_nml.z;
c1.v.nz=mid_nml.y;

The corners get more complicated though, here is an example of one of my corner functions:


Hope this helps and saves you headache and time for when you get to that part in your version.
You are not alone either

And thanks again for pointing me in the right direction!

Your LOD idea is pretty good though im not sure I will implement something like that. I am going for a cartoony/goofy look to my game. Mainly for 2 reasons, its more friendly for an indie's time budget, and because with simpler models I can load tons more. My trees will probably be a deformed low poly cylinder for the stump, and either a deformed low poly cone or sphere for the leaves. My trees will probably have less polygons than a low LOD tree normally has in one branch.


Uploaded with ImageShack.us
(and I'm considering lowering the poly count even more, LOL!)

Ive set this thread to watched, and I HOPE I will remember to come back here
when I reach this point. This code WILL be useful. Thank you.

And Im glad to have helped you out... The video looks MUCH better now.

And you think your code is tricky at corners? I cant wait to get to
trying to stich together entities of differing LOD levels...
One has half the vertices of the other...

And I need my LOD's because my view-range is like 25,000 to 50,000 quants,
depending on users available horsepower.
And Im aiming at NEAR-photo-realistic graphics. (terrain anyway)


I look forward to seeing your progression. So if you need help, or just
want to "show off" your progression, feel free to PM me.

Best of luck, and keep up the good work.

I see your problem there, but cannot think of a solution even for the first sewing/splicing step.





How are you going to achieve that if they have a different amount of vertex?


EDIT: I just came up with an idea that might help. Since we are not working with terrains but with models that look like them... You have an advantage over terrains, you don't need to make all the rows the same.



the vetex calculations for the middle terrain will be a pain, but it should be achievable this way.
The array (or whatever) holding the height data should be the same as any high detail terrain for all of them. on the high detail one loading is strightforward, on the low detail just skip x vertexses in the height data for each row, and also skip x rows in between. The tough part will be the middle terrain that is used to connect one LOD step to the other. The values to take and skip from the height array will probably have to be hardcoded (at least per row)

to make the coding simpler each LOD sep must be a multiple of the prevois one. and in the middle terrain each row must be a multiple of the previous rows... and you will special versions of these "middle terrains" for the corner terrains.
And if you plan on having several LOD steps, than that is just going to be h3ll to program and get working, but it should be possible (painfull, but possible)

I think Im just going to 'average' them, by sewing the points I have,
and ignoring the points I dont.

The LODS vertices-per-side is like so...
LOD_0=256(+1), LOD_1=128(+1), LOD_2=64(+1), LOD_3=32(+1)
So EVERY lod vertices line up with the higher lod vertices...
Like so.


Also, the 'border' between lod_0 and lod_1 is 4,000 quants MINIMUM away from the camera,
so I think its unlikely to be noticable to the player.

If it ends up that is IS noticable, I'll think of some way of hiding it.
For example, when stitching low-poly to higher-poly, the low-poly's vertices
get their z-height "halved" so ALL its edge is below the 'horizon' created by the
high-poly terrain.
Like so...



[EDIT]Hehe, you came up with a new idea, WHILE I was typing up how Im ALREADY doing it...

when I started with terrains (before i learned to splice them) i saw that no matter how far away a blue(or whatever sky texture you use) line (or even a tiny dot) in the middle of terrains is very noticable.

I think your idea of the border vertex z value halved to hide the seams is the best option. even if they are not sewn together it will look like it, and will be much less painfull than using those "mid terrains" i talked about to sew them perfectly. I would go with that, because your concept is much simpler to program and probably achieves a good result also

I'll see when I get there, thats my usual workflow...

One question though... how do you re-calculate the normals for the terrain/entity
once youve finished setting all the vertex heights?

You posted code of how you do the 'edges', but what about the main-body of the entity?

Im not working on this ATM, but small trials in the past using ent_fixnormals just
kept resetting all the new heights back to zero. (ie before re-heighting)
Was I using ent_fixnormal badly? Did I need a wait between the re-heighting and the fixnormal?

I know its do-able, cause Ive done it in the past, and I spent very little time on this test,
as the test was primarily to test setting heights in a second 'thread', which was a fail.

I cant show code, cause its gone... Deleted in order to streamline workflow, and
avoid re-hashing dead-end tests.

now I am running into another problem... Painting the terrains.

Since they are randomly generated during runtime there are no masks etc textures created beforehand for any shader to work with.

and i am thinking that if i have to create the masks at runtime and then pass them to the shaders... i would rather direclty generate the final bmaps myself and save a step!

the problem is I dont know how. I already have my separate textures i want to use (and they are the same size as each terrain).

My idea is this:

create at runtime empty bmap for each terrain, assign each one as skin to each terrain, and then for each bmap do the folowwing:

1. fill its full texture to the base texture (grass for example).
2. going through the bitmap comparing to the respective height data, set any part lower than (for example 16) to sand. (for beach, river lines, and uderwater terrain).
3. set any part of the bmap covering a part of the terrain with a height > 50 to my rocky texture.
4. set any part of the bmap covering terrain height > 100 to my snowy texture.
5 go through the whole terrain again and replace any part with a slope angle > 60º with my cliff texture.

The bmaps i want to use for my terrains are 512x512, my terrains are 33x33 vertixes with a spacing of 16q between each vertex (which also gives 512x512 size). That was planned beforehand to have the size of the terrains = the size of their texture and not nned any tiling of textures or anything.

My problem is the height data... I dont have 512x512 height data, i only have 33x33 height data. How do I know what to paint on the spaces in between my height data? and how do I detect what parts have an angle > 60º?

The first solution that came to my mind was using c_trace to detect heights of each pixel and also calculate angles with those c_trace... but it seems crazy... it will mean 252144 c_trace instructions per terrain just to get the data to draw the texture.

I thought of averaging out the diference between each point based on distance from any vertex, but i realized that the calculations would be wrong in most cases. as illustrated below the program would assume from A to B everything was the same height. i also thought of calculating the mid point but that does not work either. Any ideas would be greatly apreciated, I have hit a brick wall and cannot see around it!

have a look at vec_lerp for its height and vec_dot for its angle

Mabe when you fix the normals you forget the frame? Or are using the wrong frame? (use .frame to be sure you are editing normals for the frame the entity is at at this moment)

first I use my algorithm to load random height for each height-data array

for(x=0;x<32;x++)
{
for(y=0;y<32;y++)
{
diamond_square_fractals(x*32,y*32,random(200)+25);
}
}

then i load the hieght data to each terrain vertex:
for(x=0;x<32;x++)
{
for(y=0;y<32;y++)
{
load_to_terrain(Terrain[x][y],x*32,y*32);
}
}

after that is done I just set the normals with ent_fixnormals:
for(x=0;x<32;x++)
{
for(y=0;y<32;y++)
{
c_updatehull(Terrain[x][y],Terrain[x][y].frame);
ent_fixnormals(Terrain[x][y],Terrain[x][y].frame);//BODY NORMALS
}
}

(NOTE: code up to here is how i got the ugly shadows on the edges)

Then all I have to do is fix the corners and edges with my functions:
for(x=0;x<32;x++)
{
for(y=0;y<32;y++)
{
avg_normals_NE(x,y);//CORNER NORMALS
avg_normals_NW(x,y);//CORNER NORMALS
avg_normals_SE(x,y);//CORNER NORMALS
avg_normals_SW(x,y);//CORNER NORMALS
avg_normals_N(x,y);//SIDE NORMALS
avg_normals_E(x,y);//SIDE NORMALS
avg_normals_S(x,y);//SIDE NORMALS
avg_normals_W(x,y);(x,y);//SIDE NORMALS

}
}
NOTE: notice I dont have any wait calls in between my loops for function calls (and I dont have any wait() inside those functions either).

EDIT: after posting and seeing the result I have to say... WOW what a colorfull post!

Carlos: OK no waits or anything I get, and thanks for the code of your flow...
I think my problem boils down to the frame.

Which frame? Its an un-animated entity pretending to be a terrain.. so where
the hell does a frame number come from? Do you assign it one at some point or what?
I am really in-experienced with animations, so I always thought that ".frame"
was ONLY for animated entities... Obviously thats incorrect...

As for your current problem, I think MrGuest has got it for the heights, but I
have no idea how to get the normals using vec_dot... Im noob with normals...


I am watching with baited breath for more details from MrGuest about how to best
implement the vec_lerp because later I'll need to to similar.
My 256X256 terrains need building from 128x128 height-data...