.png)
Volume RayCasting or Volume RayMarching
category: general [glöplog]
I have this shadertoy https://www.shadertoy.com/view/4sVfz1 but I am missing how to have proper volumetrics due to lacking how to accumulate the colour according to the distance from the camera to the sdf. Here is my RayMarching loop where I think the problem is
Code:
any help will be much appreciated thanks!float ray( vec3 ro, vec3 rd, out float d, out float den )
{
float t = 0.0; d = EPS; den = 0.0;
for( int i = 0; i < STEPS; ++i )
{
vec3 p = ro + rd * t;
d = 0.3 * map( p, den ).x;
if( d < EPS || t > FAR ) break;
t += d;
den = fbm( p + TWA );
//den = den;
}
return t;
} 
I guess noone got what you are trying to achieve!
Do you want Soft-Shadows?
Do you want Global Illumination?
Or do you want Mist/Fog?
Or maybe you want Subsurface-Scattering? (wax-like materials)
Maybe explain a bit more what you need help with, so we can atleast try to help!
Do you want Soft-Shadows?
Do you want Global Illumination?
Or do you want Mist/Fog?
Or maybe you want Subsurface-Scattering? (wax-like materials)
Maybe explain a bit more what you need help with, so we can atleast try to help!
den += fbm( p + TWA ) * d;
I am willing to achieve fog like material, sort of a transparency where the volume has accumulated less density
I can't get my head around map( p, den ).x; ?
Is the .x component really used as distance instead of z? or is that some slope/gradient s**t, im just throwing something out in the air here now.
Is the .x component really used as distance instead of z? or is that some slope/gradient s**t, im just throwing something out in the air here now.
No it's a distance field, and 'distance' is of course a scalar. Clearly the map function returns a structure that contains the distance (in the first component) and some material data used in shading.
rudi: Yeah, it can get confusing, but .xyz doesn´t always mean dimensions!
You can store anything in a vec2,vec3,vec4 of course...in this case as noby said the distance is indeed stored in the .x-component!
You could even read it out like "map(p,den).r;", as .xyzw is the same as .rgba ! I most of the times read out texture.colors as .xyzw instead of .rgba, as it crunches away better with all the other occurences of .xyzw in the rest of my shaders!
felipunkerito:
what psonice suggested should work for fog! Keep in mind that it may look a bit strange, as you don´t have fixed-stepsize in sphere-marching, so you may have big holes in your fog. A way to counter this is to intermix sphere-marching with fixed-stepsize-marching by always only marching min(distance, 0.1) or sth alike on your ray...which actually makes it almost a standard (fixed stepsize) raymarcher again! But you could enlarge the "0.1"-part the further away from the camera your ray is, just to speed things up (and make use of the sphere-marcher-benefits) again, fog in the depth doesn´t need to be as accurate as closer to the camera anyway!
You can store anything in a vec2,vec3,vec4 of course...in this case as noby said the distance is indeed stored in the .x-component!
You could even read it out like "map(p,den).r;", as .xyzw is the same as .rgba ! I most of the times read out texture.colors as .xyzw instead of .rgba, as it crunches away better with all the other occurences of .xyzw in the rest of my shaders!
felipunkerito:
what psonice suggested should work for fog! Keep in mind that it may look a bit strange, as you don´t have fixed-stepsize in sphere-marching, so you may have big holes in your fog. A way to counter this is to intermix sphere-marching with fixed-stepsize-marching by always only marching min(distance, 0.1) or sth alike on your ray...which actually makes it almost a standard (fixed stepsize) raymarcher again! But you could enlarge the "0.1"-part the further away from the camera your ray is, just to speed things up (and make use of the sphere-marcher-benefits) again, fog in the depth doesn´t need to be as accurate as closer to the camera anyway!
What hardy said, and also if you just want an object made of fog material, only add the fog value if d < 0 (and of course don't exit the loop when you hit the object). This wouldn't be quite so bad, you could march normally outside the object but used fixed steps inside.
ok i see.