Goal

????I want to explore the posibility of making decent terrain in SDF modeling.In the early days, I tried some techs from i.q. , but had some flaws, never went deeper to fix the problems:

????

Develop

????At first I thought it was the SDF precision problem, because i.q.'s method looks like nohting from the actual SDF of the Terrain H(x,y). That's why I expored the method of Gradient Descent to final closest point of p in last article.

????After gone through the whole process,I found that i.q.'s method guarantees not only 100% accurate,but also the?a faster SDF Trace time than my shallow GD method.

????Finally, I found the real cause is still the 'precision', but not the precision of 'SDF height', but the precision of its 'normal estimation' on isosurface.Usually, this code would solve the normal problems of SDF objects:

????

It's really the?dispersed estimation of SDF-grad(normal) direction, you can go to i.q.'s personal page for further information.The important thing is that we can see from the code,that a good normal-estimation need?a much higher precision SDF than the SDF-estimation(Height-esitimation) itself, that becomes an?'egg need chicken' paradox,since we do the SDF-estimation first, to get to the surface point ,than do the normal-estimation.

The code is still useful, when the 'low' precision ?of normal can be accepted:that actually covers the most situation in SDF modelling.Infact, when we push the SDF-esimation precision up, the problem of picture 1 will be gone.However, this solution will consume a lot of GPU resource.Because before, we adjust the precision to a just perfect level,that our image would look good; now we have to push that level up , but player won't see anything better about the shape(ignore the normal issue).That's like an overdo tesselation.

Change

????I've been wondering,since i.q. can make terrain?so good-looking with just math:

why not we build terrain by formula,so we can get mathematical normal formula from it?Get normal from Height function is so easy: normalize(-Hx,-Hy,1).

????From my last article,I created a cosFBM tool.It can bake the HLSL code after user created the satisfied terrain from the editor.The baked code looks like this:

????

Now when we estimate the terrain normal, use this function instead of the original disperate-esimate-version:

perfect:

Faster

????Notice the terrain function and _Dxy function get more expensive when terrain gets more complicated.It's time to bake the height field and _Dxy data to an RGBAFloat texture:

????

Notice I baked Dxy but not normal,Because it's so easy to build local TBN from grad information:

T(0,1,Hy),B(1,0,Hx)

gradMap do more than normalMap.

End

????That'll be all.Futher optimize method can be applied.The thing is, no matter what tech we take, the problem'll come to use, but SDF terrain can work.

????I'll try more things like i.q., to get a nice picture in further works.?