0
\$\begingroup\$

Ok, so It's a mesh of frames (high to low density) around the camera that adjusts the vertices Z by height-map values. But what happens, how does it work outside those frames? Its like the coarsest grid that somehave blends with the most outside clipmap (green in pic) frame? Or anything outside it, is not culled?

enter image description here

Edit: also how do collisions with terrain work, if the height values are calculated in vertex Shader?

\$\endgroup\$
4
  • 1
    \$\begingroup\$ I'm not sure I understand your question. Clipmaps are fractal: outside one frame, there's just another frame, until you decide you've drawn enough and choose to stop drawing further frames. Collisions typically occur on your CPU-side data structure, and often have nothing to do with the what the GPU is rendering, even outside of terrain cases. It's an elaborate magic trick we pull to make it look like the things you see on screen have solidity, even though there's no real relationship between the rendered polygon and the physics sim, just a carefully choreographed coincidence. \$\endgroup\$
    – DMGregory
    Dec 3, 2019 at 12:49
  • \$\begingroup\$ @DMGregory but that's my question! What happens outside the last (most out) frame is drawn? Even if there is a continuous large map, is not rendered? and often have nothing to do with the what the GPU is rendering > but if there is a wall it must be rendered as an wall as well I must bump against it. There is some thing I feel I don't get it about this technique. \$\endgroup\$ Dec 3, 2019 at 13:17
  • 1
    \$\begingroup\$ Nothing. The last clipmap frame (the outer dark blue region in your diagram) is the last thing you draw. There is nothing else drawn beyond it. "If there is a wall it must be rendered as a wall as well I must bump against it" yes, and those two statements have no relationship inside the computer. It's us the game developer putting a collision box at a position in physics space that corresponds to the position on the screen where we drew the wall's polygons. The rendered polygons have no physics. The collision box has no rendering. These are separate systems that don't depend on each other. \$\endgroup\$
    – DMGregory
    Dec 3, 2019 at 13:44
  • \$\begingroup\$ Ok. This helps a lot \$\endgroup\$ Dec 3, 2019 at 13:51

1 Answer 1

1
\$\begingroup\$

Since you mentioned the comments above were helpful, I'll try to elaborate on them as an answer.

Ok, so [a GeoClipmap is] a mesh of frames (high to low density) around the camera that adjusts the vertices Z by height-map values. But what happens, how does it work outside those frames?

There is no "outside those frames". If you hit the edge of frame 4 and you still have more depth to cover in your camera's frustum, then you draw a frame 5. If you hit the edge of that and you still have more, you draw a frame 6. Beyond each frame is just another frame, until you've filled the volume that your camera can see, at which point you stop drawing.

Note that each clipmap frame is not necessarily a full ring. Many implementations use the frames just as an organizing structure, where the geometry being rendered is actually a collection of quad chunks. You're free to cull individual chunks from a frame that are too far away/left/right/behind to be visible in your camera's frustum.

How do collisions with terrain work, if the height values are calculated in vertex Shader?

The height values used for drawing may be computed in the vertex shader in your case. The height values used for collision can be a completely separate set of data that you maintain and check on the CPU side.

For instance, you might want to render detail down to a granularity as fine as 5cm in the immediate neighbourhood of your camera, but you might be satisfied with a collision resolution of half a meter or more. You can use the same generator function to generate heights at your desired collision resolution, and use that data set to power your physics simulation, completely independent of what the GPU is drawing. This also lets you get a consistent physics resolution over your whole simulated area, rather than dealing with inconsistent physics between near & far objects due to different terrain resolution, or artifacts when transitioning from one resolution to another.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .