Blending between multiple terrain textures
by Lukas Joergensen · 11/04/2014 (1:38 am) · 13 comments
Hey guys.
I don't know if you have ever noticed it, but T3D has always had several bugs when rendering terrain textures.
First of all, the most apparent bug is a hard-cutoff you get when blending more than 2 textures together. This will look like this:
When it should look like this:
Secondly, the colors are all wrong.. Basically it applies the base texture everywhere, and then blends the other textures into that base texture (and a few other things go wrong in this process as well). So you get a terrain that looks like this:
When it should look like this:
Now, Daniel just accepted my PullRequest that fixes these issues, but here is what you need to be aware of!
You see, my changes fixes the terrain blending so it works just as intended... However, it seems the whole terrain system was built up around not working as intended, so one of the issues I faced is that the .dds format, is not a very good format for terrain textures. The compression means that sometimes the colors are getting squashed a bit over several pixels. Which isn't an issue for most textures, but for terrain textures it becomes a huge issue!
So if you find that, in future versions of T3D, your terrain is having some bad colors some places, then you should be aware of this pullrequest, which enables you to change the cached basetexture's format. You can select .png .jpg or .dds
On another note, these changes seems to have fixed the "angel-pee" color on the sand texture it seems:
Not entirely sure why, but if it works...
Enjoy your new and nicer looking terrains! And I'll be looking at fixing my new terrain blending PR's asap, I just encountered some breaking issues when there are more than 3 textures, that I need to fix.
I don't know if you have ever noticed it, but T3D has always had several bugs when rendering terrain textures.
First of all, the most apparent bug is a hard-cutoff you get when blending more than 2 textures together. This will look like this:
When it should look like this:
Secondly, the colors are all wrong.. Basically it applies the base texture everywhere, and then blends the other textures into that base texture (and a few other things go wrong in this process as well). So you get a terrain that looks like this:
When it should look like this:
Now, Daniel just accepted my PullRequest that fixes these issues, but here is what you need to be aware of!
You see, my changes fixes the terrain blending so it works just as intended... However, it seems the whole terrain system was built up around not working as intended, so one of the issues I faced is that the .dds format, is not a very good format for terrain textures. The compression means that sometimes the colors are getting squashed a bit over several pixels. Which isn't an issue for most textures, but for terrain textures it becomes a huge issue!
So if you find that, in future versions of T3D, your terrain is having some bad colors some places, then you should be aware of this pullrequest, which enables you to change the cached basetexture's format. You can select .png .jpg or .dds
On another note, these changes seems to have fixed the "angel-pee" color on the sand texture it seems:
Not entirely sure why, but if it works...
Enjoy your new and nicer looking terrains! And I'll be looking at fixing my new terrain blending PR's asap, I just encountered some breaking issues when there are more than 3 textures, that I need to fix.
About the author
IPS Bundle available at: https://www.winterleafentertainment.com/Products/IPS.aspx
#2
It may have been that I used the swizzle stuff wrong, if you know more about it than me, then perhaps you might want to try some other formats yourself? (helpful link)
It'd be much nicer to have a dds format, we just need it to have a really precise compression, because just 1 pixel off means a lot to terrains where 1 pixel = 1 meter.
11/04/2014 (2:55 am)
It was DXT1, but I tried a number of other formats (DXT3 and 5) and one of them worked.It may have been that I used the swizzle stuff wrong, if you know more about it than me, then perhaps you might want to try some other formats yourself? (helpful link)
It'd be much nicer to have a dds format, we just need it to have a really precise compression, because just 1 pixel off means a lot to terrains where 1 pixel = 1 meter.
#3
github.com/lukaspj/Torque3D/blob/ef11b565bf17e49be99ac35e31ee54b80148af98/Engine...
try changing that to one of these (just for a test) highest quality is first:
11/04/2014 (3:24 am)
Just a stab in the dark here but github.com/lukaspj/Torque3D/blob/ef11b565bf17e49be99ac35e31ee54b80148af98/Engine...
try changing that to one of these (just for a test) highest quality is first:
kColourIterativeClusterFit kColourClusterFit
#4
Not acceptable :/
The Iterative one does well:
But it takes a pretty long time to generate it, since generating the cache is something you only have to do once, this might be acceptable.
11/04/2014 (4:07 am)
This is the second one:Not acceptable :/
The Iterative one does well:
But it takes a pretty long time to generate it, since generating the cache is something you only have to do once, this might be acceptable.
#5
Anyways I would tackle this problem like so:
That way by default it won't change any current default behaviour in T3D but in the terrain class you can pass through eDDSQualityMedium or eDDSQualityHigh if you so desire. Maybe even get trickier and make it a global from script land for the terrain dds saving so users can specify themselves. If you want high quality dds than unfortunately there is a trade off :/
11/04/2014 (4:17 am)
Unfortunately there is no getting around compression times :-( (multi-threading perhaps would)Anyways I would tackle this problem like so:
enum DDSSaveQuality
{
eDDSQualityLow;
eDDSQualityMedium;
eDDSQualityHigh;
};
bool squishDDS( DDSFile *srcDDS, const GFXFormat dxtFormat, DDSSaveQuality = eDDSQualityLow )That way by default it won't change any current default behaviour in T3D but in the terrain class you can pass through eDDSQualityMedium or eDDSQualityHigh if you so desire. Maybe even get trickier and make it a global from script land for the terrain dds saving so users can specify themselves. If you want high quality dds than unfortunately there is a trade off :/
#6
11/04/2014 (4:36 am)
I'll try and create a new branch with some more DDS formats. Thanks for your help Timmy :)
#7
I have used this before in another project
developer.nvidia.com/gpu-accelerated-texture-compression
It is actually based on libsquish but has a CUDA enabled dds compressor, bad part is NVidia only but it's a lot faster for NVidia users :) :) .. It will work for AMD users but obviously the CUDA part won't and i think it falls back to using the CPU which is pretty much libsquish anyway ;-)
11/04/2014 (4:46 am)
No probs mate :)I have used this before in another project
developer.nvidia.com/gpu-accelerated-texture-compression
It is actually based on libsquish but has a CUDA enabled dds compressor, bad part is NVidia only but it's a lot faster for NVidia users :) :) .. It will work for AMD users but obviously the CUDA part won't and i think it falls back to using the CPU which is pretty much libsquish anyway ;-)
#8
going to have a bit of free time off work coming up soon as im having surgery on my leg, and have recently been picking up torque again and playing around... Also, is this in omni ?
11/04/2014 (12:19 pm)
I started reading this, and i was like, what the hell Lukas, you broke terrain texturing ? Going to have to give this a whirl at some point... going to have a bit of free time off work coming up soon as im having surgery on my leg, and have recently been picking up torque again and playing around... Also, is this in omni ?
#9
11/04/2014 (11:59 pm)
Hey lukas, why don't you offload that squish call in the TerrainBlock to another thread? It's a perfect operation for it because it doesn't really matter how long it takes. That would alleviate the stalling of the main thread while the operation is going. 
#10
11/05/2014 (12:39 pm)
Finally! This has been needed for a long time, infact I had a HUGE argument about terrain blending with someone, and I showed them on an older post for the TGEA when I was writing shaders exactly what I meant. So Great job man!!
#11
@Andy, no I don't think it's in Omni yet.. I'm horrible at maintaining two engines, and at the time I started work on this, only T3D was stable. It'll make it's way into Omni at some point after I've fixed the other blending issues I have I think :)
@Bobby, yeah know how you feel haha. I've also always felt that there was something off about terrain textures, and that I never got the results I wanted. As I dug into the terrain system when implementing the height-based blending I kept finding a chain of issues with the rendering, and at every step along the way I kept thinking "wtf is going on" haha.
11/06/2014 (1:57 am)
@Timmy, I don't think it makes a lot of sense to multithread it, because the engine can't start untill the cache has been generated anyways (It happens automatically on start-up). Though it's not an issue, I'm just gonna add it as an option which you should only use when preparing for deployment.@Andy, no I don't think it's in Omni yet.. I'm horrible at maintaining two engines, and at the time I started work on this, only T3D was stable. It'll make it's way into Omni at some point after I've fixed the other blending issues I have I think :)
@Bobby, yeah know how you feel haha. I've also always felt that there was something off about terrain textures, and that I never got the results I wanted. As I dug into the terrain system when implementing the height-based blending I kept finding a chain of issues with the rendering, and at every step along the way I kept thinking "wtf is going on" haha.
#13
Glad you're still trying to improve T3D, thanks Lukas!
11/07/2014 (8:31 am)
The first 4 pics are dead with my connection; the 5th seems to work.Glad you're still trying to improve T3D, thanks Lukas!
Timmy01
What dds format where causing problems? Really uncompressed textures are nasty and will consume large amounts of precious memory.