A butterfly is being oppressed by 6 evil spheroids!

As this previous posting of mine chronicles, I have acquired an Open-Source Tool, which enables me to create 3D / CGI content, and to distribute that in the form of a WebGL Scene.

The following URL will therefore test the ability of the reader’s browser more, to render WebGL properly:


And this is a complete rundown of my source files:



(Updated 01/07/2020, 17h00 … )

(As of 01/04/2020, 22h35 : )

On one of my alternate computers, I also have Firefox ESR running under Linux, and that browser was reluctant to Initialize WebGL. There is a workaround, but I’d only try it if I’m sure that graphics hardware / GPU is strong on a given computer, and properly installed, meaning, stable…

Continue reading A butterfly is being oppressed by 6 evil spheroids!

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:



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.



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 10/31/2017, 7h55 )

Continue reading Widening Our 3D Graphics Capabilities under FOSS