I love cg,but I havnt studied systematicly,if you see my mistakes or even blunders,feel free to correct me.
1.tangent is better!
There are two key parameters about pom:HeightRatio(texture height relative to texturewidth) and precision(size of the biggest lump want to see clearly) ,precision is basically step size, step size means evey lumps that fall between can be consider linear,so we can compute accurate ray intersection,step size is computed from steps,so computing steps is important.
Unreal uses cosine and max/minsteps to emulate steps count,but the actual steps count is rising as a tangent curve,some cases it can causes waste of computing.
Here is a bad case for demostration:
You can see part2 is actually more accurate than part1,thats because the rising rate difference between cosine and tan,if you want to see part2 clearly then part1 will be feed more computing power than it needs,and part1 is the bigger area on screen.
No need to worry about tan() increases instuction count,we have a free sine and tan() can be reused in many cases later like pixel depth offset,in the end it actually reduces some instructins.
As you see on the gragh,reason we compute steps rather than use step size directly is that const step size causes steps to go sky high as camera looking at samll angle,
so the best solution is like this (performancewise):
and the material graph:
Here using tan to calculate pdo avoid a vec3 distance().but the result is weird,dont know why,just scale it down before use and youll be good,also I think use opacity mask work too if you dont need accurate intersection and cheaper.I havnt test position yet,its not vrey often used,I also dont think calculate shadow is very pratical,I see that we have contact shadow now,should be better.
2.Ideal about “RippleRayPOM”.
Pom is expensive because it takes loops or steps,but most steps just hit the air and go wasted,so I came up a ideal,imagine this,in texture space,for every pixel,grow a hemisphere from top trying to mask out as much empty space,until it collides with heighmap geometry,then store the radius in another channel,and when ray tracing,read the value in that channel,if ray is inside that hemisphere,it can jump toward whatever direction it heads until it leaves the sphere knowing that it wont miss anything,then again read another hemisphere,since we need to look up the texture anyway,why not use up the other channel?
So the whole idea is using simple geometry(ones have radius) to block out empty space to reduce steps that hit the air,cylinder is better,it takes two parameters or two channels to define a cylinder,but it adapted to different shape nicer,especially when using pom,texture space is narrow vertically.
I wrote a small programe to generate this kind of map,here is the result,it looks like shape,but clearly it isnt working as expected,I decide to give up,all this is just beyond my knowledge,if you were interested,please check out,tell me if I misundetand it, i ll upload detail later.
Mateial graph,codes in text editor cant complie,i inline the function mannually in custom node:
3.I want to cut out the part that is being looked at narrow angle and leave a sillouette using opacity mask,i try to clamp ray length and ray height but didnt work,dont know why. i ll upload detail later
.if its better to store tan() in texture?if so it can be easy to emulate steps more controllably,is there one dimension single channel texture?
.How much texture lookup cost generally speaking,dependant/indendent lookup,mip lookup,channel lookup,continuous lookup.
.would using many independant if statement in hlsl affect pefomance?dependent?
.what is causing twinkling when looking at pom at narrow angle?