Getting Rid Of An Artifact, When Using Shadow-Maps

When using the CGI methodology of Shadow-Mapping, one concern which can strike the power-user, is that his shadow-map doesn’t have a much-higher resolution, than his main picture-resolution. This concern seems valid, because while his camera-perspective is being mapped back to itself at whatever resolution it has been set to, a shadow-map is being rendered first, at whatever resolution, but there is no reason to assume that 1 pixel belonging to the shadow-map corresponds to 1 pixel belonging to the camera-perspective.

I.e., The pixels of the shadow-map could be mapping a 3D surface inclined much with respect to the shadow-map, but not inclined as much, with respect to the camera-perspective, which can magnify what the shadow-map did to that 3D perspective.

Hence, the following rendering-error can happen:

csg_demo_2_pattern

 

In my case, there was essentially an incorrect and a correct explanation, as to why this rendering artifact could have been happening:

Incorrect Explanation:

My shadow-map resolution is already at 2048×2048, and yet is still not high enough to win out, over the camera-resolution, of 800×600…

Correct Explanation:

The rendering of the 3D surface seems to be contingent on the shadow-map having been drawn, when in fact it should be contingent, on whether the closeness to the light-source of the object, is greater, than whatever closeness is recorded in the shadow-map. In other words, The distance in the shadow-map could be completely unknown, and the object in the foreground should result as being closer to the light-source by default.

The way to correct this problem in my case was, ‘Place an arbitrary surface in the BG of the scene, but within the Z-range of the light-source.’ Doing so caused the entire shadow-map to be rendered, which meant that any part of the 3D object which did not explicitly have anything between it and the camera, finally defaulted to being visible.

Dirk

 

Widening Our 3D Graphics Capabilities under FOSS

Just so that I can say that my 3D Graphics / Model Editing capabilities are not strictly limited to “Blender”, I have just installed the following Model Editors on the Linux computer I name ‘Klystron’, that are not available through my package-manager:

I felt that it might help others for me to note the URLs above, since correct and useful URLs can be hard to find.

In addition, I installed the following Ray-Tracing Software-Rendering Engines, which do not come with their own Model Editors:

Finally, the following was always available through my package manager:

  • Blender
  • K-3D
  • MeshLab
  • Wings3D

 

  • PovRay

 

In order to get ‘Ayam’ to run properly – i.e., be able to load its plugins and therefore load ‘Aqsis’ shaders, I needed to create a number of symlinks like so:

( Last Updated on 08/19/2017, 19h55 )

Continue reading Widening Our 3D Graphics Capabilities under FOSS