## Cheating a little bit, and teasing a shaded surface, out of a Computer Algebra System.

One of the subjects which I posted about some time ago was, how easy it is for a Computer Algebra System – a CAS – to output a single variable, in order to colour an Iso-Surface, and how hard it is in contrast, to output a normal vector, from whatever Geometry Shader computes the Iso-Surface, such that this normal vector can be used to shade the surface, in a later Fragment Shader invocation.

What needs to be done in ‘3D Game Design’ and (other) ‘CGI’, is essentially that.

But, given that a CAS can be used both, to plot a 3D surface, as well as, to define what the colour-range of this surface is supposed to be, a bit of a trick can be used, to bypass the need actually to compute a normal vector, but to achieve an equivalent result. And this posting will begin with an example which is slightly simpler, than what my earlier posting had assumed. Iso-Surfaces tend to smack of ‘implicit’ functions, while this example is going to start with an ‘explicit’ plot, in which (X) and (Y) are parameters of the function, but where it was already easy to achieve, that a single (Z) value results, such that (X, Y, Z) are in fact the coordinates plotted.

Because we have a Computer Algebra System in the first place, for continuous functions, it’s easy to compute the derivative with respect to one of the parameters. That derivative can be used, just to modulate the brightness of the surface. The simplest example is shown blow:

(Updated 7/10/2020, 6h10… )

## 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… )

## How 3D-plotted, implicit functions are often inferior, to ISO-Surfaces rendered for 3D Gaming.

One of the subjects which I revisited in recent weeks has been, that either Computer Algebra Systems, or other numeric toolboxes, may plot functions. And a fact that should be pointed out is, that to plot a function, either as a 2D or a 3D plot, is always numeric, even if it’s being offered as part of what a ‘CAS’ can do (a “Computer Algebra System”). And so, a subcategory of what is sometimes offered, is a 3D plot, of an implicit function, kind of like this one:

This is a plot, of complementary hyperboloids, which are the 3D counterparts to 2D hyperbola.

What some people might just wonder is, how the refined toolbox works, that plots this type of implicit function. And one way in which this can be done, is by generating an ISO-Surface, which is a derived mesh, along which a Density that has been computed from X, Y and Z parameters, crosses a threshold-value, which can just be named (H) for the sake of this posting.

And, in turn, such an ISO-Surface can be computed, by using the ‘Marching cubes algorithm‘. If it gets used, this algorithm forms a geometry shader, which accepts one Point as input topology, and which outputs a number of triangles from (0) to (4).

The question which this posting poses is, whether the mesh which is output by such an algorithm, will always include vertex-normals. And the short answer is No. Applications exist, in which normals are computed, and applications exist where normals are not computed. And so, because some users are used to high-end gaming, and used to seeing shaded surfaces, which can only really be shaded if normals have been made available to a fragment shader, those users might find themselves asking, why Mathematical plotting algorithms might exist, which never compute real normals.

(Updated 5/07/2020, 16h15… )

## A little trick needed, to get Blender to smooth-shade an object.

I was recently working on a project in Blender, which I have little experience doing, and noticing that, after my project was completed, the exported results showed flat-shading of mesh-approximations of spheres. And my intent was, to use mesh-approximations of spheres, but to have them smooth-shaded, such as, Phong-Shaded.

Because I was exporting the results to WebGL, my next suspicion was, that the WebGL platform was somehow handicapped, into always flat-shading the surfaces of its models. But a problem with this very suspicion was, that according to something I had already posted, to convert a model which is designed to be smooth-shaded, into a model which is flat-shaded, is not only bad practice in modelling, but also difficult to do. Hence, whatever WebGL malfunction might have been taking place, would also need to be accomplishing something computationally difficult.

As it turns out, when one wants an object to be smooth-shaded in Blender, there is an extra setting one needs to select, to make it so:

Once that setting has been clicked on for every object to be smooth-shaded, they will turn out to be so. Not only that, but the exported file-size actually got smaller, once I had done this for my 6 spheroids, than it was, when they were to be flat-shaded. And this last observation reassures me that: