Not logged in, Join Here! or Log In Below:


Hi fellow flipcoders, 

You might want to ignore intersections when the ray hits the same object it started from, within a very short distance from the ray origin. That should fix up your silhouettes; you will get some false negatives on the backside of the sphere, but dotting the smoothed normal with the light vector will take care of these. 

As the size of the sphere increases (and the amount of polygons used for the approximation stays the same), that epsilon would need to become really big (the minimum distance required to be safe is something like 1/3 of the size of a face I guess, haven't tried calculating it yet). 

This seems to be a fundamental problem that stems from the mismatch between 'geometric' normals and 'smoothed' normals. Geometric normals are those perpendicular to the triangle surface. Smoothed normals are those interpolated from vertex normals. You can see there is a problem by considering a point on a tri near a vertex  the smoothed normal at this point will be similar to the vertex normal, which is not perpendicular to the triangle face! As a result you tend to get graphical mismatches between any two algorithms that use the two different types of normal. 

Thank you for this additional insight! 

Usually when you define a supposedly smooth surface, you define a normal for every vertex, instead of a normal for every poly. Usually these meshes are a descretization (triangularization) of a mathematical smooth surface. Off course you can approximate the real (mathematical) surface normal by averaging the triangles normals, but usually the real vertex normal should be given. 

Rui, as it is I don't have vertex normals defined (the editor doesn't support them yet) so I calculate them using the algorithm mentioned above, but wether or not I have vertex normals available does not affect my actual problem. Which is: how to do 'smooth' intersection tests with nearby faces to avoid "false" shadowcasting. Where false is defined as 'shadows that would not have been cast if the shape had exactly matched the one suggested by the smoothed normals'. 

Move the intersection point outwards, along the normal of the triangle, until the new shadow ray will just barely miss the edges of the shadowed triangle. This will introduce some shadow "stretching" artifacts in extreme cases of low tesselation, but it should not be noticeable in most cases. 

... The tip about cubic interpolation of my normals is very much appreciated, but what makes you think I am not already doing so? Looking at your second picture, the frontier between light and shadow always seems to be linear, i.e. a linear segment across each triangle. Also, I don't believe to be feasible (without a lot of strange tricks) to produce a smooth shadow that will NOT follow the geometry, but instead a virtually smoothed shape (geometry). Mainly because I'm assuming you are interpolating the edges which is not enough, you will have to interpolate on each pixel, and even so I'm not sure you will get what you want. An easier solution is to increase the tesselation of the surface. 

I just found out the Gile[s] also suffers from this issue. It is just that they introduce a nice little gradient in stead of my initial crisp normal test (step 1), so that the artifacts are mostly hidden. Turning on what they call 'toon rendering' made this very very clear. 

Sorry I wasn't clear. I guess my answer would be more understandable in the context of a traditional raytracer. 

Very sorry if I missed the point entirely (happens frequently) but shouldn't you dot product the the normal with the direction to the light source not just check if they face the same way? It won't entirely fix your self shadowing problem, but what you could do about that is only test rays against back facing triangles. That should theoretically work perfectly, as long as you don't do anything tricky with your geometry. 

I may be totally missing the point but are you not performing this lightmapping per vertex? Is this not your problem?? 

Victor: Aha, now I get what you mean. But I don't think it is the face that is selfshadowing (I already excluded it from the raytest), so I'll try if I can make 'skipping the neighbours' a feasible solution. No, my data structure is not exactly perfect for that :) 

Well, show some code. You shoot a ray at a triangle and get the point of intersection. 

maybe you could calculate the curvature of the face and calculate the exact point of collision (light/surface) using that. It would save you from the selfshadowing problems. 

juhnu wrote: 

Thanks for all the input on the forum and through emails guys, especially you Willem! 

Ok, if you don't want the geometry restrictions you could just record if the ray has intersected with a front facing triangle. Then if it doesn't intersect with a back facing one check whether the triangle you are generating the light map for is front facing or back facing. If it's front facing, shadow it, otherwise leave it up to the dot product to do it for you. That should work for any old triangle soup. 
