五月天青色头像情侣网名,国产亚洲av片在线观看18女人,黑人巨茎大战俄罗斯美女,扒下她的小内裤打屁股

歡迎光臨散文網(wǎng) 會(huì)員登陸 & 注冊(cè)

SDF terrain (analysis or texture based)

2022-05-17 21:34 作者:DeadCyber  | 我要投稿

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:

Notice the discontinuous part of terrain,it get worse when camera is closer

i.q.'s%20TerrainSDFstep%3Ad%20%3D%200.5*abs(H(x%2Cy)-p)????

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:

????

heightMap-RGBAFloat
gradMap-RGBAFloat

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.?

SDF terrain (analysis or texture based)的評(píng)論 (共 條)

分享到微博請(qǐng)遵守國(guó)家法律
修武县| 达尔| 鄄城县| 临沭县| 文登市| 六安市| 措美县| 乐昌市| 若羌县| 庆云县| 鄱阳县| 抚顺县| 肃宁县| 巴塘县| 灵寿县| 新宁县| 望谟县| 长治县| 交口县| 合山市| 长阳| 宁夏| 富蕴县| 巴塘县| 南部县| 嘉鱼县| 浦县| 威宁| 苍梧县| 卢龙县| 太和县| 伊春市| 博野县| 百色市| 沧源| 新蔡县| 郸城县| 临夏县| 神木县| 黑山县| 定襄县|