Another terrain editing question
Author
Hi,
I'm currently implementing terrain editing and texture painting and I think I have the very basic stuff already.
While texture painting I want that textures are correctly projected to minimize texture stretching on steep sections.
Click
I'm wondering if it is possible to side project textures correctly while painting. How is this generally implemented?
Thanks
It is not possible to do a correct projection in the general case. This is because an image texture is always in a plane, and the terrain is generally not.
Using a top-down projection (I assume you do so) especially violates area preserving in steep regions, so that a single texel may have to cover a significantly greater pixel area on the screen in comparison to flat regions. If you don't want that, you need to manipulate the texture co-ordinate grid to use more texels per the same area in steep regions. Presumbly there are some different methods known to deal with this problem; the following is one I've thought of just know, so I will not say it is the best way.
E.g. start with the regular texture co-ordinate grid, then measure the steepness of the terrain along the local u and v axes, and use that measure to manipulate the u,v co-ordinates accordingly. Unfortunately, this is an optimization problem, because changing a particular u,v has an influence on all neighboured areas, too.
I think to overcome this problem, one can follow the pathes on the grid of the terrain one-by-one in u and v direction separately, and to summarize the segment lengthes along each path. The path has an equivalent on the texture, ranging from 0 to 1 in normalized texture co-ordinates. Then the texture co-ordinates at the ends of the segments along the current path are computed as the quotient of the current path length and the total path length.
Doing so distorts the entire texture (with the exceptions of the margins) to distribute its texels more homogeneously onto the area of the regions covered by the texture. (As said, I'm not sure how good this method is.)
Using a top-down projection (I assume you do so) especially violates area preserving in steep regions, so that a single texel may have to cover a significantly greater pixel area on the screen in comparison to flat regions. If you don't want that, you need to manipulate the texture co-ordinate grid to use more texels per the same area in steep regions. Presumbly there are some different methods known to deal with this problem; the following is one I've thought of just know, so I will not say it is the best way.
E.g. start with the regular texture co-ordinate grid, then measure the steepness of the terrain along the local u and v axes, and use that measure to manipulate the u,v co-ordinates accordingly. Unfortunately, this is an optimization problem, because changing a particular u,v has an influence on all neighboured areas, too.
I think to overcome this problem, one can follow the pathes on the grid of the terrain one-by-one in u and v direction separately, and to summarize the segment lengthes along each path. The path has an equivalent on the texture, ranging from 0 to 1 in normalized texture co-ordinates. Then the texture co-ordinates at the ends of the segments along the current path are computed as the quotient of the current path length and the total path length.
Doing so distorts the entire texture (with the exceptions of the margins) to distribute its texels more homogeneously onto the area of the regions covered by the texture. (As said, I'm not sure how good this method is.)
I think what haegarr described is similar to this (if I remember the details correctly) : Indirection Mapping for Quasi-Conformal Relief Texturing.
Unfortunately, I don't think this will solve the problem. The algorithm described in the above paper is about increasing the texture resolution on steep slopes. For relief/parallax/etc. mapping this is way better than not doing anything. But in the case of a heighmap terrain, increasing the resolution of those regions wont solve the problem. The textures will still be stretched.
To overcome stretching you might need a different set of texcoords for those problematic regions (e.g. like in tri-planar mapping).
On the other hand, maybe my understanding/implementation of the above paper wasn't correct after all.
HellRaiZer
Unfortunately, I don't think this will solve the problem. The algorithm described in the above paper is about increasing the texture resolution on steep slopes. For relief/parallax/etc. mapping this is way better than not doing anything. But in the case of a heighmap terrain, increasing the resolution of those regions wont solve the problem. The textures will still be stretched.
To overcome stretching you might need a different set of texcoords for those problematic regions (e.g. like in tri-planar mapping).
On the other hand, maybe my understanding/implementation of the above paper wasn't correct after all.
HellRaiZer
Author
Hi,
Okay, I have decided to look into triplanar texturing.
But at first I would like to known what are "contras" of this technique.
For example more texture fetches etc. Maybe I should use it only for cliff material etc.
Has anyone here implemented triplanar texturing for heightmap based terrain?
Thanks
Okay, I have decided to look into triplanar texturing.
But at first I would like to known what are "contras" of this technique.
For example more texture fetches etc. Maybe I should use it only for cliff material etc.
Has anyone here implemented triplanar texturing for heightmap based terrain?
Thanks
Triplanar mapping is the solution as people have mentioned, I have tried this on my terrain and it works fine. What you'll generally find in things like Crysis is that they have mappings for 3 types of slope; mostly flat which is normal texture mapping, and two vertical mappings, one for north/south, say, and one for east/west. You can see this in the editor (under x,y,z for the materials).
The point at which the terrain turns from east to north or south to west, etc, you'll need to switch the planar mapping at that point so the only 'contra' that I'm aware of is that you do still get a very small amount of stretching at points where the mapping changes but it really is barely noticeable (unless you've got a perfectly round area you're mapping (e.g., a cylinder). There aren't any extra texture fetches, you can use any material you like, you just need to tweak the mappings. You can do this by using blendmaps for different planes, or however you want to do it.
Hope that helps
The point at which the terrain turns from east to north or south to west, etc, you'll need to switch the planar mapping at that point so the only 'contra' that I'm aware of is that you do still get a very small amount of stretching at points where the mapping changes but it really is barely noticeable (unless you've got a perfectly round area you're mapping (e.g., a cylinder). There aren't any extra texture fetches, you can use any material you like, you just need to tweak the mappings. You can do this by using blendmaps for different planes, or however you want to do it.
Hope that helps
Author
I'm not sure if I understand it correctly. If I use blendmaps for different mappings, it reqiures alot of memory.
I thought triplanar texturing blends textures based on normalvector
Here is another article
Click
Nevermind, I will just try it and see how it works.
Thanks for answers.
I thought triplanar texturing blends textures based on normalvector
Here is another article
Click
Nevermind, I will just try it and see how it works.
Thanks for answers.
A very simple method we use in our terrain editor is to take a set of textures and assign a normal to each one (obviously this is also the direction of projection). As the artist paints the terrain, it detects the terrain normal at that vertex and chooses the closest matching texture. You get the benefit of eliminating stretching while also allowing the user to customize how many texture materials they wish to use in a particular area. Problematic mountain areas will use more textures than rolling hills.
I've implemented both the quasi-conformal, and tri-planar methods, and have to say that 'pound-per-dollar' that the tri-planar gets you as close as you need to be with frame buffer splatting.
That of course assumes that the final com posited mesh has access to unlimited screen space resolution which it usually has.
If, however, you're using a composite-cache technique (i.e. virtual texture / mega texture / svt ) Then the tri-planar gets more difficult due the limited amount of texture resolution that's available for your to apply to your terrain, which is where things like relief mapping / QCRM start looking like better options. But even then, you're always running into problems of how much resolution you can spit out into your cached texture page.
There is, of course, the obvious solution, which has been used in many games before, which is to NOT have gradients that allow UV's to stretch, and rather, insert a new mesh / modify the UVs in those areas with altered / non-conformal UV information to do your splatting algorithm.
~Main
That of course assumes that the final com posited mesh has access to unlimited screen space resolution which it usually has.
If, however, you're using a composite-cache technique (i.e. virtual texture / mega texture / svt ) Then the tri-planar gets more difficult due the limited amount of texture resolution that's available for your to apply to your terrain, which is where things like relief mapping / QCRM start looking like better options. But even then, you're always running into problems of how much resolution you can spit out into your cached texture page.
There is, of course, the obvious solution, which has been used in many games before, which is to NOT have gradients that allow UV's to stretch, and rather, insert a new mesh / modify the UVs in those areas with altered / non-conformal UV information to do your splatting algorithm.
~Main
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
