Thread: [Algorithms] Heightmap terrains that don't suffer from texture stretch on cliff faces?
Brought to you by:
vexxed72
From: Megan F. <sha...@gm...> - 2005-01-31 18:12:32
|
What is out there in the way of workable algorithms for heightmaps that don't break down on cliff faces? I mean, I suppose I could treat the entire thing as one big mesh, but I can't imagine that would be a particularly great idea in terms of performence or LOD behavior? Our solution for the moment is to layer static meshes of rocks and craggy-looking surfaces over our ugly-textured cliff faces, but even that's not a great idea... if anyone ever happened to get a good camera angle and zoom in, they might see the LOD'ed terrain receding back from the rock face. -Megan Fox |
From: Jonathan B. <jo...@nu...> - 2005-01-31 18:22:45
|
Ideally, an LOD system takes your current camera FOV (or however you do zoom) into account. That can be hard to do in actuality, since it increases the load on your renderer when you zoom (= lower frame rate). What is it that you're worried about with cliffs, is it the texture stretching or is it geometry also? If just texture, then you could in the pixel shader blend between two texture mappings, one being the "standard" one and one being meant for vertical surfaces. The interpolation parameter can just be a function of fabs(normal.z). -J. Megan Fox wrote: >What is out there in the way of workable algorithms for heightmaps >that don't break down on cliff faces? I mean, I suppose I could treat >the entire thing as one big mesh, but I can't imagine that would be a >particularly great idea in terms of performence or LOD behavior? > >Our solution for the moment is to layer static meshes of rocks and >craggy-looking surfaces over our ugly-textured cliff faces, but even >that's not a great idea... if anyone ever happened to get a good >camera angle and zoom in, they might see the LOD'ed terrain receding >back from the rock face. > >-Megan Fox > > >------------------------------------------------------- >This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting >Tool for open source databases. Create drag-&-drop reports. Save time >by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. >Download a FREE copy at http://www.intelliview.com/go/osdn_nl >_______________________________________________ >GDAlgorithms-list mailing list >GDA...@li... >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > |
From: Megan F. <sha...@gm...> - 2005-01-31 18:29:55
|
The concern with the LOD system is that, if I build my cliffs up as essentially big piles of rock in front of a vertical terrain surface, the LOD system might get ahold of that vertical surface and try to "smooth it out" at distance. This would have the effect of making the surface less vertical and pulling away from the faked cliff mesh. If at all possible, I would much prefer a system where the texture properly tiles up verticals just as well as it tiles over the horizontal area of the terrain (then I'd ditch the faked cliff meshes and let the texture do most of the work)... I just don't know if any such system exists? -Megan Fox > Ideally, an LOD system takes your current camera FOV (or however you do > zoom) into account. That can be hard to do in actuality, since it > increases the load on your renderer when you zoom (= lower frame rate). > > What is it that you're worried about with cliffs, is it the texture > stretching or is it geometry also? If just texture, then you could in > the pixel shader blend between two texture mappings, one being the > "standard" one and one being meant for vertical surfaces. The > interpolation parameter can just be a function of fabs(normal.z). |
From: Jonathan B. <jo...@nu...> - 2005-01-31 18:39:14
|
>If at all possible, I would much prefer a system where the texture >properly tiles up verticals just as well as it tiles over the >horizontal area of the terrain (then I'd ditch the faked cliff meshes >and let the texture do most of the work)... I just don't know if any >such system exists? > > What I just mentioned will do that. For vertical surfaces, you have this cube map containing a rocky-cliffy-kind of texture. For all other surfaces, you have whatever 2D texture map you were going to put on the ground if it were flat. Interpolate between those per-pixel based on the current (pre-bump-mapped) interpolated vertex normal. Not the most elegant thing ever, but it works. |
From: Megan F. <sha...@gm...> - 2005-01-31 18:46:24
|
Yep, apologies, responded to the first half of your email before reading the second half. Thanks - will try that, and take a closer look at how ChunkLOD operates. > What I just mentioned will do that. For vertical surfaces, you have > this cube map containing a rocky-cliffy-kind of texture. For all other > surfaces, you have whatever 2D texture map you were going to put on the > ground if it were flat. Interpolate between those per-pixel based on > the current (pre-bump-mapped) interpolated vertex normal. > > Not the most elegant thing ever, but it works. |
From: Jonathan B. <jo...@nu...> - 2005-01-31 19:02:47
|
To give you some more direct links: Thatcher Ulrich did the chunklod system for terrain: http://www.tulrich.com/geekstuff/chunklod.html If you want to extend the same idea to generalized meshes, I have some articles about this, see: http://number-none.com/product/index.html And go to the 5-part series "Unified Rendering LOD". Megan Fox wrote: >Yep, apologies, responded to the first half of your email before >reading the second half. Thanks - will try that, and take a closer >look at how ChunkLOD operates. > > > >>What I just mentioned will do that. For vertical surfaces, you have >>this cube map containing a rocky-cliffy-kind of texture. For all other >>surfaces, you have whatever 2D texture map you were going to put on the >>ground if it were flat. Interpolate between those per-pixel based on >>the current (pre-bump-mapped) interpolated vertex normal. >> >>Not the most elegant thing ever, but it works. >> >> > > >------------------------------------------------------- >This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting >Tool for open source databases. Create drag-&-drop reports. Save time >by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. >Download a FREE copy at http://www.intelliview.com/go/osdn_nl >_______________________________________________ >GDAlgorithms-list mailing list >GDA...@li... >https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list >Archives: >http://sourceforge.net/mailarchive/forum.php?forum_id=6188 > > > |
From: Ben G. <be...@ga...> - 2005-01-31 18:29:07
|
Megan Fox wrote: >What is out there in the way of workable algorithms for heightmaps >that don't break down on cliff faces? I mean, I suppose I could treat >the entire thing as one big mesh, but I can't imagine that would be a >particularly great idea in terms of performence or LOD behavior? > > Acually, treating it as one big mesh can be very good for performance AND LOD - google for chunklod. Of course, then content creation becomes a bit hairy... Regards, Ben |
From: Jon W. <hp...@mi...> - 2005-01-31 19:41:54
|
What I've done for experiments, and it's worked out reasonably well, is to be somewhat smarter about generating U/V. For a given block of heightmap, I walk along the major axes (along X/U and along Z/V) starting at each vertex along the side, and measure the entire triangle side lengths for each slice. Then I divide the U/V range into the total length, and allocate U/V not based on the X projection, but based on the total distance traveled along the actual sides. For terrain that has drastic changes along diagonals, you will get shearing in the texturing, which is a trade-off from the extreme stretching you get with flat X/Z mapping. You can make it softer by making the actually assigned U/V coordinates a blend between what the flat X/Z mapping would give you, and what the edge length traversal would give you. Cheers, / h+ |
From: <ca...@gm...> - 2005-01-31 21:37:19
|
I guess that if you are doing that, you can also apply any of the existing parametrization methods. I tried with conformal and Desbrun's equiareal parametrization methods and it worked fairly well. However, best results would probably be achieved using a non linear optimization method, the nature of the heightfield geometry would make it very easy to apply a hierarchical solver. "Surface Parameterization: A tutorial and a survey" of Floater and Hormann provides a good overview of the existing parametrization methods. --=20 Ignacio Casta=F1o ca...@gm... Jon Watte <hp...@mi...> wrote: > What I've done for experiments, and it's worked out reasonably well, > is to be somewhat smarter about generating U/V. For a given block of > heightmap, I walk along the major axes (along X/U and along Z/V) > starting at each vertex along the side, and measure the entire > triangle side lengths for each slice. Then I divide the U/V range > into the total length, and allocate U/V not based on the X projection, > but based on the total distance traveled along the actual sides. >=20 > For terrain that has drastic changes along diagonals, you will get > shearing in the texturing, which is a trade-off from the extreme > stretching you get with flat X/Z mapping. You can make it softer by > making the actually assigned U/V coordinates a blend between what the > flat X/Z mapping would give you, and what the edge length traversal > would give you. |
From: Jon W. <hp...@mi...> - 2005-01-31 21:49:59
|
> I guess that if you are doing that, you can also apply any of the > existing parametrization methods. Heightfields are special, though, in that you want exact 0-1 range across each square chunk, and you want no UV discontinuities (except at the edges). Most general parameterization mechanisms don't lend themselves well to this kind of constraint, except for typical error metric relaxation methods where you can keep the edges pinned. However, this starts using more CPU, which might not be desirable if you're paging your heightfield (which I was doing at the time). I suppose if you run a general parameterization on the entire thing and then chop into blocks, you wouldn't have problems at the seams, but then it's more like a mesh than a height field, because you need to either store all of the data and page it like a mesh, or keep all of it loaded for dynamic computation. Cheers, / h+ |
From: <ca...@gm...> - 2005-01-31 22:49:57
|
What I did in my experiments was to fix the boundary vertices on a quad based on edge length, and used the mentioned methods to map the interiors, that way the boundaries of the blocks matched perfectly. With linear opt. methods to have fixed boundaries is very cheap, in fact, it makes it cheaper than with free boundaries. I mentioned non linear optimization methods, because In some cases, specially with the conformal map, I got undesiderable area distorsions in some places, for example, at the top of the mountains. I don't have too much experience with non linear opt. methods, but maybe fixed boundaries would mean additional constraints that as you say would make the optimization slower. I don't know for sure. --=20 Ignacio Casta=F1o ca...@gm... On Mon, 31 Jan 2005 13:50:26 -0800, Jon Watte <hp...@mi...> wrote= : > > I guess that if you are doing that, you can also apply any of the > > existing parametrization methods. >=20 > Heightfields are special, though, in that you want exact 0-1 range > across each square chunk, and you want no UV discontinuities (except > at the edges). Most general parameterization mechanisms don't lend > themselves well to this kind of constraint, except for typical > error metric relaxation methods where you can keep the edges pinned. > However, this starts using more CPU, which might not be desirable > if you're paging your heightfield (which I was doing at the time). >=20 > I suppose if you run a general parameterization on the entire thing > and then chop into blocks, you wouldn't have problems at the seams, > but then it's more like a mesh than a height field, because you > need to either store all of the data and page it like a mesh, or > keep all of it loaded for dynamic computation. |