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^^
cheers,
tasche
Terrain Stitching
Author
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^^
That will probably be the next thing on my "to do" list. I may try trilinear GeoMipMapping as de Boer suggests, but I haven't dug into the details too much yet. I'm assuming if you have a good interpolation system between mipmap changes you can crank up your threshhold to a higher value?
I'm assuming if you have a good interpolation system between mipmap changes you can crank up your threshhold to a higher value?
Not too much. Personally I find hills or spikes that suddenly grow out of nowhere over a few frames to be almost as irritating as having them just pop up. Considering the extra effort it takes I'd rather stick with a higher lod.
Author
I agree. The heightmap I'm using has a lot of small bumpy hills as well as larger hills. When using a terrain with a decent amount of detail, the lower LoD's look pretty crappy, even from a distance. I'd say that the terrain has to be designed to be smooth for it to look good, otherwise the threshold has to be such that even somewhat distant blocks are only 1 LoD below normal.
ultra smooth terrains are boring!
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.
the smooth rolling hills areas, they ignore because literally, there's nothing to see.
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.
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.
the smooth rolling hills areas, they ignore because literally, there's nothing to see.
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.
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.
Creating terrain like in MC would require a completely different approach. A heightmap as such simply doesn't allow overhangs, arches, caves or anything "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.[/quote]
? That's the whole point of calculating the (screen) error for each lod of each chunk. You calculate the max height difference for all points in the chunk compared to the highest lod, scale it (for example by camera distance) and select an lod where the scaled error is below x.
in conversation a good point was made about all these LOD systems.
What happens when a person uses binoculars or a view zoom in the game? We implement that as an FOV change.. which is more or less accurate, but I've now noticed that many engines fail to make the LOD of the area being zoomed into any higher, resulting in some really crappy looking stuff when you zoom in.
Do your terrain-camera systems accommodate this? I know I haven't implemented anything to deal with this yet.
What happens when a person uses binoculars or a view zoom in the game? We implement that as an FOV change.. which is more or less accurate, but I've now noticed that many engines fail to make the LOD of the area being zoomed into any higher, resulting in some really crappy looking stuff when you zoom in.
Do your terrain-camera systems accommodate this? I know I haven't implemented anything to deal with this yet.
Do your terrain-camera systems accommodate this? I know I haven't implemented anything to deal with this yet.
That's a good point, but easily fixed by considering the projection. My camera class is dealing with the frustum width/height for a lot of things like culling anyway, so assuming a simple case where your camera is always upright, you can just scale with the frustum height (else you'd have to take the cameras up vector, multiply with frustum width/height and use the length of the resulting vector for scaling).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
