Jump to content
Posted 11 September 2011 - 09:06 PM
Posted 11 September 2011 - 10:26 PM
Posted 12 September 2011 - 12:50 AM
Posted 12 September 2011 - 02:03 AM
Posted 12 September 2011 - 10:19 AM
Posted 12 September 2011 - 10:55 AM
Posted 12 September 2011 - 12:33 PM
but if you put a restriction that neighboring blocks can only differ by 1 mipmap level (which is the typical case anyways, due to the spatial locality of the player and the blocks) then it will greatly reduce the number of index buffers.
You might find this Seamless Patches for GPU-Based Terrain Rendering paper interesting. It still uses square terrain chunks but renders them using four triangular patches with the LOD changes implemented by choosing different index buffers for the triangles.
Posted 12 September 2011 - 09:28 PM
Posted 13 September 2011 - 01:48 AM
Posted 13 September 2011 - 01:04 PM
There is a simpler work around that may work for you.. may not as well.
At the boundary between higher and lower res chunks, there is not real GAP from top down view, just gaps formed by T junctions of the different mesh densities. The gaps can only then be seen from sideways view.
One of the simplest solutions I've seen is to take the low res chunk's edge vertices and extrude them down below the high res chunk, towards the player. This forms an extra strip that will block any gaps where the high res mesh would be lower than the low res mesh from a side on view. In the case where the high res mesh is vetically higher than the low res mesh, there will be no gap to void to view through from the vantage point of the camera.
Granted in this old project (2003) I did over extrude them a bit too low.
Posted 13 September 2011 - 03:34 PM
Posted 14 September 2011 - 03:00 AM
using the 16 index buffer approach works pretty well, however i have still to figure out on how to do vertex morphing to hide the quite visible pops in my engine. if you go with this approach, and get vertex morphing done, write a tutorial fo me^^
Posted 14 September 2011 - 12:15 PM
I'm assuming if you have a good interpolation system between mipmap changes you can crank up your threshhold to a higher value?
Posted 14 September 2011 - 12:29 PM
Posted 14 September 2011 - 12:42 PM
Posted 14 September 2011 - 10:36 PM
granted stuff coded here looks mugh nicer, but go look at minecraft worlds. where the mountains are all jutting up and doing weird things. people travel all over the game to find these areas because they are interesting.
perhaps some pre-processing of the terrian mesh to determine areas of high rate of height change/sharp corners and allow those small portions of the mesh to always render in higher LOD than the smoother areas of the same distance from viewer.
Posted 15 September 2011 - 01:53 PM
Posted 15 September 2011 - 10:33 PM
Do your terrain-camera systems accommodate this? I know I haven't implemented anything to deal with this yet.