\$30

### Image of the Day Submit

IOTD | Top Screenshots

### The latest, straight to your Inbox.

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

5 replies to this topic

### #1gboxentertainment  Members

Posted 12 July 2013 - 09:39 AM

I have been able to simulate soft shadows using raymarching in my test scene, as shown below:

However, these artifacts occur when I move the light too close to the occluder:

Can anyone who has experience with raymarching help provide any clues as to why these artifacts occur and how they can be removed?

### #2deftware  Prime Members

Posted 12 July 2013 - 08:46 PM

it looks like your light source is intersecting the sphere, and that the light itself has an actual size (and isn't an infinitely small point) which is good, but you're not handling the intersection case properly - or aren't preventing intersections from occuring in the first place.

### #3gboxentertainment  Members

Posted 13 July 2013 - 08:14 AM

Okay, so I've figured out the cause. Here's my code for reference:

bool raymarch_shadows(vec3 ro, vec3 rd, float maxDist, vec3 lightPos, out float t, out vec3 p, out float light_intensity)
{
t = 0.0;
float minStep = 0.001;
light_intensity = 1.0;
for(int i = 0; i< 10; i++) {
p = ro + rd*t;
float mDist = rm_obj(p);

if(mDist < 0.0015) {
return true;
}

light_intensity = min(light_intensity, 5.0*mDist/clamp(t,0.0,5.0));

if(mDist < minStep) { mDist = minStep;}
t += mDist;
if(t >= maxDist) {break;}

}

return false;
}


Its to do with this function: if(t >= maxDist) {break;}

where maxDist is length of ray (t) from each surface point to the light. The reason why I have to stop the ray when it reaches the light is because if the ray is coming from behind the light, and the occluder is on the other side of the light, if I don't stop the ray, it will overshoot and still capture the occluder. Here is what happens when I remove the "break":

So the break function prevents this from happening; however, it creates another artifact, which is the sudden changes in lighting, like so:

I have now figured out what causes this. It only occurs at locations where the distance from the surface point to the occluder is equal to the distance from the surface point to the light (maxDist). On one side of these points, t < maxDist, thus this side is darker. On the other side, t >= maxDist so this side is lighter.

Now I just wish I could figure out how to get it to gradually fade between lighting intensities. Please provide any advice or thoughts if you have any.

Edited by gboxentertainment, 13 July 2013 - 08:16 AM.

### #4gboxentertainment  Members

Posted 16 July 2013 - 06:41 AM

I've seemed to have minimized the problem by reducing the softness of the penumbras via changing this formula:

5.0*mDist/clamp(t,0.0,5.0)

50.0*mDist/clamp(t,0.0,5.0);

The issue still exists but only when the light is right on the surface of an object.

Now what I'm trying to do is to attach the raymarched shadows to the rasterized objects in the scene. At the moment I'm just testing with a simple box and a sphere, later on I will raymarch more complex objects like the buddha through use of a volume texture.

Right now though, my problem is that the shadow-casting objects themselves are also occluded by their own shadows - i.e. incorrect self-shadowing:

Notice how both the sphere and box are both much darker when they should be lit directly by the light.

Any ideas on how to resolve this?

### #5gboxentertainment  Members

Posted 19 July 2013 - 03:52 AM

Problem solved

I've had to cheat a little bit though:

I had to slightly reduce the size of the signed distance version of the models so that the light-facing surface of the rasterized models were not shadowed by the signed distance objects.

Now all I have to do is to figure out a fast way of shadowing more complex objects like the buddha. I have heard that you can voxelize that model into a 3D texture and then raymarch. I have previously cone-traced this model to produce shadows but they were ugly due to the low-res 3d texture. If I increase the resolution then it becomes too expensive.

Alternatively, a volume rendering approach involves taking the difference between the front and back faces to get the ray-march directions, but for shadow ray-marching the direction is known because it is always in the direction of the light.

Can anyone suggest any other methods?

### #6gboxentertainment  Members

Posted 22 July 2013 - 07:26 AM

So I've tried to raymarch an sdf texture of the stanford bunny from this website:

http://www.postronic.org/h3/test/webgl/ds09/

This is what it comes out as (I haven't rendered the bunny itself, just the shadow effect from it - its actually near the centre):

float sdf(vec3 p) {
float res = 32;
float zFrame = floor(p.z*res);
float v1 = texture2D(volTex, vec2(p.x, (p.y*0.5+zFrame)/res)).r;
return v1;
}

float rm_bunny(in vec3 p)
{
vec3 p2 = p;
p2 += vec3(0,0,0); p2.z = -p2.z + 1.0;
p2.x = min(1.0,max(0.0,p2.x));
p2.y = min(1.0,max(0.0,p2.y));
p2.z = min(1.0,max(0.0,p2.z));
bunny = (0.5-sdf(p2))*0.3;

return bunny;
}


I admit that most of this code was copied from that website and modified slightly without my complete understanding of it.

I just want to figure out how to minimize the noise adjacent to the shadow - it is a symptom of the softness of the penumbra.

Also, I don't know what's causing the gap between the bunny shadow and the other object shadows - I'm using min(rm_bunny(p),min(cube, sphere));

Its not to do with the raymarching steps because the gaps are still there even when using 500 steps.

Edited by gboxentertainment, 22 July 2013 - 07:28 AM.

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.