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:

Screenshot_20200104_124756c

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:

  • Flat-Shading does in fact work as I had expected, and
  • WebGL is not handicapped out of smooth-shading.

 

It should be pointed out that, while Blender allows Materials to be given different methods of applying Normal Vectors, one of which is “Lambert Shading”, it will not offer the user different methods of interpolating the normal vector, between vertex-normals, because this interpolation, if there is to be one, is usually defined by an external program, or, in many cases, by the GPU, if hardware accelerated graphics is to be applied.

Dirk

 

OGRE 1.11.5 Working on ‘Phosphene’

One of the open-source software projects which has often fascinated me, is called OGRE, which stands for Open-Source Graphics Rendering Engine. It’s a very powerful set of libraries, that allows good coders to design 3D graphics applications, which take full advantage of hardware-accelerated – i.e., GPU-based – rendering, of virtual 3D scenes designed by such users, into simulated 2D camera views, within the same scene. This is one of the most common modes in which 3D Graphics is operated.

One of the things that OGRE is not, is a full-fledged game engine unto itself. This is due to:

  • Lack of sound implementation (Additionally linking applications to the SDL Library may solve that),
  • Lack of scripting support, without some sort of add-on. I think I compiled it with Python support, which would supply scripting, if my coding was good enough.

Modern builds of OGRE break with the past, in that they no longer use ‘OIS’ as their input system. Instead, at least their Sample Browser uses the ‘SDL library’ to do the same.

One of the feats which I have now accomplished on the computer named ‘Phosphene’, which is a Debian / Stretch, Debian 9 system, was to compile version 1.11.5 of this engine because I’m curious about Game Design, which I have been for a long time. And one of the reasons I feel that this software is stable on Phosphene, is due to the information which I already provided in This past posting. The past posting announced observations which I made, when this same hardware was called the computer ‘Plato’, but already running Debian Stretch.

What my observation essentially suggests is, that running 3D, OpenGL applications can in fact break the compositor because they suspend it, but that there is a work-around.

(Updated 2/20/2019, 19h00 … )

Continue reading OGRE 1.11.5 Working on ‘Phosphene’

About how I won’t be doing any ‘ASL’ computing soon.

There exists an Open-Source code library named ‘ASL’, which stands for “Advanced Simulation Library“. Its purpose is to allow application-designers who don’t have to be deep experts at writing C++ code, to perform fluid simulations, but with the volume-based simulations running on the GPU of the computer, instead of on the CPU. This can also lead people to say, that ‘ASL’ is hardware-accelerated.

Last night I figured, that ‘ASL’ should run nicely on the Debian / Stretch computer I name ‘Plato’, because that computer has a GeForce GTX460 graphics card, which was considered state-of-the-art in 2011. But unfortunately for me, ‘ASL’ will only run its simulations correctly, if the GPU delivers ‘OpenCL’, version 1.2 or greater. The GeForce 460 graphics card is only capable of OpenCL 1.1, and is therefore no longer state-of-the-art by far.

Last night, I worked until exhausted, trying various solutions, in hopes that maybe the library had not been compiled correctly – I custom-compiled it, after finding out that the simulations were not running correctly. I also looked in to the possibility, that maybe I had just not been executing the sample experiments correctly. But alas, the problem was my ‘weak’ graphics card, that is nevertheless OpenGL 4 -capable.

As an alternative to using ‘ASL’, Linux users can use the Open-Source program-set called ‘Elmer‘. They run on the CPU.

Further, there is an associated GUI-application called ‘ParaView‘, the purpose of which is to take as input, volume-based geometries and arbitrary values – i.e., fluid states – and to render those with some amount of graphics finesse. I.e., ‘ParaView’ can be used to post-process the simulations that were created with ‘ASL’ or with ‘Elmer’, into a presentable visual. The version of ‘ParaView’ that installs from the package-manager under Debian / Stretch, ‘5.1.x’ , works fine. But for a while last night, I did not know whether problems that I was running in to were actually due to ‘ASL’ or to ‘ParaView’ misbehaving. And so what I also did, was to custom-compile ‘ParaView’, to version 5.5.2 . And if one does this, then the next problem one has, is that ParaView v5.5.2 requires VTK v7, while under Debian / Stretch, all we have is VTK v6.3 . And so on my platform, version 5.5.2 of ParaView encounters problems, in addition to ‘ASL’ encountering problems. And so for a while I had difficulty, identifying what the root causes of these bugs were.

Finally, the development branch, custom-compiled version of ‘Elmer’ and package-manager-installed ‘ParaView’ v5.1.x will serve me fine.

Dirk

 

The role that Materials and Textures play in CGI

I once had a friend, who had asked me what the difference was, between a Texture, and a Material, in CGI. And as it was then, it’s difficult to provide a definitive answer which is true in all cases, because each graphics application framework, has a slightly different definition of what a material is.

What I had told my friend, was that in general, a material is a kind of node, which we can attach texture-images to, but that usually, the material allows the content-designer, additionally, to specify certain parameters, with which the textures are to be rendered. My friend next wanted to know what then, the difference was, between a material and a shader. And basically, when we use material nodes, we usually don’t code any shaders. But, if we did code a shader, then the logical place to tell our graphics application to load it, is as another parameter of the material. In fact, the subtle details of what a material does, are often defined by a shader of some sort, which the content designer doesn’t see.

But, materials will sometimes have a more-powerful GUI, which allows the content-designer to connect apparent nodes, which are shown in front of him visually, in order to decide how his texture images are to be combined, into the final appearance of a 3D model, and this GUI can go so far as to display Nodes, visible to the content-designer, that make this work easier.

My friend was not happy with this answer, because I had not defined what a material is, in a way that applies to ALL Graphics Applications. And the reason I did not, was the fact that each graphics application is slightly different in this regard.

Dirk