Terrain Offset?

[pHySiQuE]

Have you considered adding another terrain data array for offset from the surface? I used this in a shader to add some horizontal noise. This forms small rocky crags and overhangs, and looks a lot more realistic than pure heightmap terrain. I just added these with some perlin noise and applied it to slopes over a certain angle, and it looks great.

This could be done with an array that is resolution * resolution * 3 bytes, and just use three unsigned bytes to indicate a vector offset for each point on the terrain. The vector could be multiplied by a max offset value for the terrain to control the strength of the effect.

This would be easy enough for anyone to implement in their own terrain systems, too.

screenshots_screenshot64.jpg (36.85 KiB) Viewed 6839 times

[pHySiQuE]

My users have been really positive about the look of this terrain. I'm just using some perlin noise at this point, but you can see the cliffs forming some overhangs in this image. I think we're going to add another tool for sculpting the offset from the terrain surface. Do you think it is possible to implement this in the heightfield collision?

screenshots_screenshot65.jpg (31.58 KiB) Viewed 6817 times

Implementation would be very easy. Something like this code can be used to modify the terrain points:

Code: Select all

//New members:
//void* m_offsetMap - array of unsigned bytes encoding a normal
//dgFloat32 m_offsetlength - maximum length of terrain offset
if (m_offsetMap != NULL)
{
   const dgUnsigned8* const elevation = (dgUnsigned8*)m_offsetMap;
   points[0 * 2 + 0] += dgVector(dgFloat32(elevation[base * 3 + 1] * 2 - 255) / dgFloat32(255.0), dgFloat32(elevation[base * 3 + 1] * 2 - 255) / dgFloat32(255.0), dgFloat32(elevation[base * 3 + 0] * 2 - 255) / dgFloat32(255.0), dgFloat32(0.0f)) * m_offsetlength;
   points[0 * 2 + 1] += dgVector(dgFloat32(elevation[base * 3 + 1] * 2 - 255) / dgFloat32(255.0), dgFloat32(elevation[base * 3 + 1] * 2 - 255) / dgFloat32(255.0), dgFloat32(elevation[base * 3 + 1] * 2 - 255) / dgFloat32(255.0), dgFloat32(0.0f)) * m_offsetlength;
   points[1 * 2 + 1] += dgVector(dgFloat32(elevation[base * 3 + 1] * 2 - 255) / dgFloat32(255.0), dgFloat32(elevation[base * 3 + 1] * 2 - 255) / dgFloat32(255.0), dgFloat32(elevation[(base + m_width) * 3 + 1] * 2 - 255) / dgFloat32(255.0), dgFloat32(0.0f)) * m_offsetlength;
   points[1 * 2 + 0] += dgVector(dgFloat32(elevation[base * 3 + 1] * 2 - 255) / dgFloat32(255.0), dgFloat32(elevation[base * 3 + 1] * 2 - 255) / dgFloat32(255.0), dgFloat32(elevation[(base + m_width) * 3 + 0] * 2 - 255) / dgFloat32(255.0), dgFloat32(0.0f)) * m_offsetlength;
}

You would also need to modify the raycast bounding box code by adding the m_offsetlength value to the AABB. I am not sure how to do that.

[pHySiQuE]

I've got the technique working in our editor now, and it's quite easy to use. What do you think of adding this in the physics code?

download.jpg (54.17 KiB) Viewed 6793 times

Full-res image here:
http://www.leadwerks.com/werkspace/page ... =480295546

[Julio Jerez]

that s the kind of functionality that is best left for the end user using the user static collision.
In fact the Terrain is just that. It is actually quite easy since there is already a user terrain by the is incomplete.

what I can do Is that I can copy the terrain code and make it sample these the same algorithm b as user terrain, there there you can edit it and add eh extra functionality you want.
does that world for you?

[pHySiQuE]

Thanks, I will try that. I tried modifying the existing heightfield code but could not figure it out.

[Julio Jerez]

I can make the first template in the demo sandbox, and them form there I can tell yo uteh places that you need to modify to make your own.

[Julio Jerez]

can I borrow some small sample terrain, and the Perlin layer?

[pHySiQuE]

Okay, thank you. I look forward to seeing this.

[pHySiQuE]

Here is a sample terrain. I am no longer using perlin noise. Now I have a tool that lets the user sculpt the offset amount.

The terrain heightmap is stored in a 16-bit raw file:
http://www.leadwerks.com/post/mountains2.r16

The terrain offset is stored in the alpha channel of the normal texture:
http://www.leadwerks.com/post/mountains2_dot3.png

In my vertex shader, I multiply the normal by the offset value, multiply by 8.0, and use that to move the vertex position. I discarded the y component of the normal and renormalized it, in order to get a stronger horizontal effect:

Code: Select all

vec4 GetVertexPosition(in vec2 pos, in float terrainheight)
{
   vec2 texcoords = pos / terrainsize + 0.5;
   vec4 position = vec4(pos.x,0.0,pos.y,1.0);
   position.y = texture(texture0,(pos + 0.5) / terrainsize + 0.5).r * terrainheight;   
   vec4 normalcolor = texture(texture8,texcoords);
   vec3 normal = normalize(normalcolor.xzy * 2.0 - 1.0);
   normal.y=0;
   normal=normalize(normal);
   vec3 offset = normal * normalcolor.a * 8.0;
   position += vec4(offset,0.0);
   return position;
}

screenshot226.jpg (137.78 KiB) Viewed 6708 times

[Julio Jerez]

Before doing this, let ne see if I understood you requires.
the terrain system works like this.

Code: Select all

-get the grids touching the aabb of the colliding shape.
 for each grid a pogigna mesh is made in wauch each point is calculate by the expression
point = Vector (grid_x * scale, heighAt (grid_x, grid_z),  grid_z * scale)

where the height is the heigh map
and want you wan is

Code: Select all

point = Vector (grid_x * scale, heighAt (grid_x, grid_z),  grid_z * scale) +
            Vector (displacement (grid_x), 0.0,  displacement (grid_z));
where displacement  store the displacement field


did I get that right?
if so, the I will add an new newton Terrain function, set Displacement map.
because it is no just eth high field, the aabb and ray cast, and everything that deal with the high field that has to be modified.
In the image you showed I do no se that much difference. but I guess that's an are thing

[Julio Jerez]

Btw the other day browsing the net I came across this
http://www.leadwerks.com/werkspace/topi ... e__st__100
It was quite depressing to see how so many people dream of the day that you use the Bullet engine
because for some reason they thon it will make their project better.
You like almost every one else seems to have three kind of users.

1-the one that wish they can make a game using a Game engine, but at are ignorant of how hard it actually it, and they believe they will get information by reading Internet propaganda.
2-The one that do not do anything at all, actual trolls, that believe they are jack of all trades and keep talking of their rear end.
3-The one that makes the propaganda like the last idiot who commented and said this.

Wchris said:
it depens on the size and mass of the cubes. Here we have no relative object like a truck or car to compare the size of the cube with, and we have no idea of the cubes mass.
if you take small objects with low mass like dices and try to stack them up like this in real life, it's more than likely they will collapse just like bullet.

This moron is presented with the evidence and his reaction is to dismissed saying the erroneous behavior is the real life behavior. Somehow he feels that he is an expert in physics and he knows what kind of cubes stack and which don't.
Me I am not an expect but I do truth the math. And the math tells me that two solid cubes of equal side will stack on top of each other regales size and mass.

maybe you can show then all three engines: Physx 3.3, Newton 3.13 and Bullet
running side by side on these NVidia tool.
http://www.newtondynamics.com/downloads/PEEL-master.rarhttp://newtondynamics.com/forum/viewtopic.php?f=9&t=8836

There was an NVidia Guy here, saying that he will integrated to their repository,
but just like they did 1 year ago, I do not think they do that, they can not let their target audience see the embarrassment that PhysX 3.3 an up is compered to Newton.
Maybe you user can see the different between Newton and Bullet doing the same thing side by side./
Although I do not think there is any amount of evidence that can convince a fanatic fundamentalist like Wchris.

[pHySiQuE]

Your description of the formula is correct. I would use two bytes for each point, which is plenty of resolution for this. The offset should have some adjustable scale value for the entire terrain, so the strength can be adjusted.

Code: Select all

point = Vector (grid_x * scale, heighAt (grid_x, grid_z),  grid_z * scale) +
            Vector (displacement (grid_x) * displacementscale, 0.0,  displacement (grid_z) * displacementscale);

Here is another screenshot of the effect:
http://images.akamai.steamusercontent.c ... sizedimage

I agree about what my users say about different physics libraries. If you just changed the captions on those videos, he would be claiming how it proves bullet is better. One thing I have learned in life is that few people actually come up with their own opinions. Most will just look around, see who's winning, and side with whoever they perceive the winner to be. When he sees that behavior, he KNOWS bullet is better, because he has seen articles about it and he knows the general consensus favors it. Therefore, his own eyes must be wrong. If he were to admit what he sees it could make him open to criticism, and no one wants to be wrong. People really do think that way. We have had a few people over the years who hang around the forum and constantly tell me why all my decisions are wrong, and it really is a drag.

However, we do get a lot of small games released, with about 12 in the last month. My job isn't to make the most advanced technology possible, but to give people what they REALLY need to make their game:
http://www.leadwerks.com/werkspace/page/steamgames

[Julio Jerez]

ok the function is :
void NewtonHeightFieldSetHorizontalDisplacement (const NewtonCollision* const heightfieldCollision, const unsigned short* const horizontalMap, dFloat scale);

you edit it the same way you it the elevation.
the displacement is assume to be small, if yo umake to too big it will malfuntion

[pHySiQuE]

Thanks, I am working to integrate this. We are in the middle of a new release, so there will be a delay.

[pHySiQuE]

I think you should remove this feature as it is not useful for most users. If I want to implement this I should create a custom collision like I did for the vegetation, as that will give the most control. Sorry.