## There can be curious gaps, in what some people understand.

One of the concepts which once dominated CGI was, that textures assigned to 3D models needed to include a “Normal-Map”, so that even early in the days of 3D gaming, textured surfaces would seem to have ‘bumps’, and these normal-maps were more significant, than displacement-maps – i.e., height- or depth-maps – because shaders were actually able to compute lighting subtleties more easily, using the normal-maps. But additionally, it was always quite common that ordinary 8x8x8 (R,G,B) texel-formats needed to store the normal-maps, just because images could more-easily be prepared and loaded with that pixel-format. (:1)

The old-fashioned way to code that was, that the 8-bit integer (128) was taken to symbolize (0.0), that (255) was taken to symbolize a maximally positive value, and that the integer (0) was decoded to (-1.0). The reason for this, AFAIK, was the use by the old graphics cards, of the 8-bit integer, as a binary fraction.

In the spirit of recreating that, and, because it’s sometimes still necessary to store an approximation of a normal-vector, using only 32 bits, the code has been offered as follows:


Out.Pos_Normal.w = dot(floor(normal * 127.5 + 127.5), float3(1 / 256.0, 1.0, 256.0));

float3 normal = frac(Pos_Normal.w * float3(1.0, 1 / 256.0, 1 / 65536.0)) * 2.0 - 1.0;



There’s an obvious problem with this backwards-emulation: It can’t seem to reproduce the value (0.0) for any of the elements of the normal-vector. And then, what some people do is, to throw their arms in the air, and to say: ‘This problem just can’t be solved!’ Well, what about:


//  Assumed:
normal = normalize(normal);

Out.Pos_Normal.w = dot(floor(normal * 127.0 + 128.5), float3(1 / 256.0, 1.0, 256.0));



A side effect of this will definitely be, that no uncompressed value belonging to the interval [-1.0 .. +1.0] will lead to a compressed series of 8 zeros.

Mind you, because of the way the resulting value was now decoded again, the question of whether zero can actually result, is not as easy to address. And one reason is the fact that, for all the elements except the first, additional bits after the first 8 fractional bits, have not been removed. But that’s just a problem owing to the one-line decoding that was suggested. That could be changed to:


float3 normal = floor(Pos_Normal.w * float3(256.0, 1.0, 1 / 256.0));
normal = frac(normal * (1 / 256.0)) * (256.0 / 127.0) - (128.0 / 127.0);



Suddenly, the impossible has become possible.

N.B.  I would not use the customized decoder, unless I was also sure, that the input floating-point value, came from my customized encoder. It can easily happen that the shader needs to work with texture images prepared by an external program, and then, because of the way their channel-values get normalized today, I might use this as the decoder:


float3 normal = texel.rgb * (255.0 / 128.0) - 1.0;



However, if I did, a texel-value of (128) would still be required, to result in a floating-point value of (0.0)

(Updated 5/10/2020, 19h00… )

## Panda3D Compiled and Installed on ‘Klystron’

I have just completed a project, by which I downloaded, compiled and installed the 3D-game / 3D-application development software named Panda3D, on the powerful Linux laptop I name ‘Klystron’. That laptop is not to be confused with the less-powerful Web-server I name ‘Phoenix’.

This game-development kit started out years ago as a much-simpler project from Carnegie-Mellon University, which at the time I called a toy. But as it stands today, the level of sophistication and power available through Panda3D has grown tremendously. It is no longer a toy by any means, and is also one of the few game-dev platforms I know of, that can be scripted directly in Python.

One of the new features that make it interesting, is the ability to use Bullet Physics, especially since the simpler ODE (Open Dynamics Engine), game-physics engine, is broken on some platforms.

Another new feature is the support for a browser plug-in, that will allow games etc. to be deployed as Web-content, as long as the browser has the run-time plug-in installed. The actual embedded applet will then take the form of a ‘.p3d’ File.

One aspect of compiling this software that takes some getting used to, is that its python-based make-commands accept an ‘–everything’ parameter, which essentially tells the make-script to find all the relevant dependencies on the local computer, and then to configure the version of Panda3D we are compiling, to link only to the dependencies which were found, thereby either including some features or leaving them out.

I found that my only way to process that information, was to run the make command a first time as a dummy-run, and then to interrupt it. At the top of its build-log, it will show the power-user which libraries / dependencies it did not find, as if the intention was not to include those. After having interrupted this first run, I next went through my package-manager and installed all the packages named, which I felt might add some value to my build of Panda3D.

And so, after I checked out the GIT version of the software to a folder named ‘~/Programs/panda3d’ , and after ‘cd’ -ing to that directory, I felt that the following recipes were of use to me:

## Atomic Game Engine Installed – twice

One of the projects which I have recently undertaken, is to compile and install Atomic Game Engine, both on my Linux laptop ‘Klystron’, and on my Windows 7 machine ‘Mithral’. This was originally a closed platform, but has received renewed interest, because it is now available under the MIT license, which is a form of Open-Source licensing, more permissive than GPL v3 is.

This platform has the eventual capability, to deploy 3D applications and games, to Windows, OS/X, Linux, Android, iOS and WebGL recipient-platforms, while some forms of it will run under Windows and Linux, in my own experience.

I have to say though, that my ability to get the Linux version of this game-design platform working, was not due to my own prowess, but rather to the fact that the development team at Atomic Game Engine, provided dedicated and consistent technical support to me, every time I ran into a problem. I would guess they are rather tired of answering my many questions for the moment, so it is also good news, that both under Linux and Windows, my installations of this platform are complete – to my own satisfaction.

I have exported a 3D application to Android from my Windows platform, but have not reproduced this success under Linux, mainly because the platform requires that I specify where my Android SDK and where my Ant executable are located – sensibly – and I do not have any Android SDK presently, installed on ‘Klystron’. I do have the Android SDK installed on ‘Mithral’, which as I said is required, and so the export to Android worked there.

Installation under Windows was much more straightforward than it was under Linux, which is often the case, because the Windows version comes as an available binary SDK, while under Linux it still needs to be custom-compiled. And whenever we custom-compile anything, we can run into dependency issues.

One major issue I faced under Linux, was the fact that the Mono packages that are standard for my Debian distribution, are not adequate in what they provide, for development in C# to be enabled. And so what I needed to do, was to subscribe to another Mono repository, managed by Mono project, to upgrade my whole Mono installation, and after that, C# also worked.

So, Atomic Game Engine allows for 3D applications and games to be designed, using the languages C#, JavaScript, and TypeScript, according to my own experience… But, a C# Project cannot be exported for WebGL playing.

Also, I have discovered along the way, that We are no longer expected to install ‘Visual Studio 2015 Express’, but rather “Visual Studio 2015 Community Edition”, and in order to get C# support to work properly on my Windows 7 machine, I needed to do an in-place upgrade, from ‘VS Express’ to ‘VS Community’.

I am pleased that all the installation and upgrading seems to have gone well, and seems to have left me with no major reliability issues, either on ‘Klystron’ or on ‘Mithral’.

However, because the build of Mono now on ‘Klystron’ is non-standard, I cannot vouch for it in general. On my actual server-box ‘Phoenix’, I must choose to stick with the more conservative Mono packages, that are meant to go with Debian, because this box needs to run reliably 100% of the time. OTOH, on ‘Klystron’, I had nothing else depending on Mono, for which reason I was also willing to do the upgrade.

Dirk