0
\$\begingroup\$

This is not about generating plane geometry and then applying a shader on it. Instead, I want a big single flat plane, then apply a shader on it.

The vertex shader has a uniform vec3 realPlanePosition and calls a height calculation function:

// Vertex shader code

uniform vec3 realPlanePosition;

varying vPosition;

float heightCalculation(vec2 verticePosition) {
    // Just for pseudo-code (more black magic append here).
    return magicNoise2D(verticePosition.x, verticePosition.y);
}

void main(void) {
    vec3 vPosition = position;
    vec2 verticePosition = vec2(vPosition.x + realPlanePosition.x,
                                vPosition.y - realPlanePosition.z);

    vPosition.z = heightCalculation(verticePosition);

    gl_Position = projectionMatrix * modelViewMatrix * vec4(vPosition, 1.0);
}

In my plane update code, I just change realPlanePosition with player position, for example. The plane moves on (x, z) (X rotation: -PI/2.0). The only thing the vertex shader updates is the z (due to plane rotation) value of gl_Position.

Is this good practice? Also, how do I detect collisions with it? And finally, how can I control other terrain objects' generation (rocks, trees, ...)

\$\endgroup\$
0
\$\begingroup\$

This is usually a bad idea if you want the terrain to be interactive. And even if you don't, rendering the noise to a texture first will save you a lot of noise sampling. Collisions and other stuff is usually done on the CPU, so you'd be generating the terrain twice.

So it's great for backdrop terrain (or "far" LOD version of the terrain, assuming you don't need the terrain for some other reason), but not so good when you want a terrain to walk on. Adding things like rocks and trees is basically just doing the same thing again - which is also a lot easier if you have the map in a texture.

Since you're generating a heightmap anyway, there's very little to gain from generating the terrain only on the GPU (note that it might be worth it to generate parts of the terrain only on the GPU, such as close-up detail geometry).

Now, if you generated a 3D terrain (not just a plain heightmap), that's a wholly different beast, but in the end, you'd probably pre-render it somehow anyway. Unless you're doing this for a demo, purely-GPU terrain probably isn't very useful.

|improve this answer|||||
\$\endgroup\$
2
\$\begingroup\$

You don't want todo this every frame. Use either transform feedback or the CPU to calculate it once, then store in a VBO. If you want a large world then divide it into chunks as needed.

Also since the grid is fixed, as the noise 'moves through' the grid, the terrain will wobble around, if using low poly count for the terrain then this would be very dramatic and nauseating.

I don't even see how this relates to collision detection.

|improve this answer|||||
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.