Something Discouraging, When Using ‘Ayam’

One of the subjects which I have written about, here and here, is that I seem to like the Open-Source application named ‘Ayam‘, as a potential way to create images, which are 2D perspective views of a virtual 3D scene. This program just might do for me, what the proprietary program ‘Bryce’ once did for me, under Windows.

But obviously it’s harder to use Ayam, to create any meaningful images. And one reason seems to be, that doing so requires we define explicit, simulated light-sources, and the fact that there are no defaults, that would set up these light-sources, with parameters, that lead to good images.

I.e., the program will compute per-pixel color-values, that are derived from the positions, geometries, and intensities of the light-sources, but with no advanced warning to the user, of what intensities he needs to give his light-sources, so that the pixel-brightness values are in-range.

Usually, if we begin by rendering a cube, and we find that it renders, but only as a black outline, against a transparent background, then we may have everything set up correctly, except for the intensity of the light-source. It might just take some trial-and-error, before we set that correctly. And what I have found is that on their arbitrary scale, an intensity of 16 or so, just works well, in experimental scenes I’ve created.

At the same time, ‘Ayam’ has a specific idiosyncrasy to its GUI, which I rather appreciate. Its many numeric parameter-widgets have an arrow to the right of them, and an arrow to their left, which respectively, increase or decrease the value in the numeric field. The way these little buttons work, is either to double or halve the value they alter.

I suppose this could confuse some first-time users, because the numeric value in the field defaults to zero. This means that to click on the buttons does not alter the value, because to double or halve zero, results in zero. But what we can do is type a (+1) or a (-1) into the numeric field, and then, if we find that the parameter in question isn’t even close to where it’s supposed to be, we can repeatedly use the buttons, until we either find that (+16) is approximately correct, or until we find that (+0.0625) is about correct… The users just need to remember that after choosing widget-settings, we must also click to ‘Apply’ those settings before moving on, or else ‘Ayam’ will tend to forget them.

Dirk

 

I’ve just custom-compiled ‘Aqsis’.

To give some context to this proclamation, I had written an earlier posting, about adapting the non-packaged software named ‘Ayam‘ to Debian / Stretch, that had worked just fine under Debian / Jessie. This is a GUI which constructs complex ‘Renderman‘-Compliant rendering instructions, in this case in the form of .RIB-Files, which in turn, ‘Aqsis’ can turn into 2D perspective views of 3D scenes, that have been software-rendered. OTOH, Ayam itself uses OpenGL and H/W rendering, for its GUI.

What I had found before, was that Ayam did not seem stable anymore under Debian / Stretch. I apologize for this assessment. Under close scrutiny, my computer has revealed, that it was really Aqsis giving the problems, not Ayam. Aqsis is a text-based tool in effect.

Ayam does not specifically need to be used with Aqsis to do its rendering. It can be set up to use other rendering-engines, most of which are quite expensive. Aqsis just happens to be the best Open-Source rendering-engine, whose language Ayam speaks. And at this point I’d say that Ayam is still quite stable, after all, under Debian / Stretch.

As is often the case with such troubles, I next sought to custom-compile Aqsis, to see whether doing so could get rid of its quirks. What were its quirks?

Finally, the only problem with Aqsis was and remains, that it cannot produce a real-time preview of the scene being edited, which it used to provide using a component-program named ‘piqsl’. And the reason why the packaged version of Aqsis does not have ‘piqsl’ under Debian / Stretch, is because this distribution of Linux has a very new ‘Boost’ library ( v1.62 ) , and the visual component to Aqsis, that could produce a display, still relies on the Qt4 libraries and their API, which have begun to bit-rot. The Qt4-specific code of Aqsis cannot parse the newest usage of the Boost libraries, and Debian maintainers have long since discovered this. They are shunning the use of ‘libqt4-dev’ and of ‘libqt4-opengl-dev’ to build any of their packages. So they were effectively forced to package a version of Aqsis, which was missing some important components.

(Updated 12/12/2017 … )

Continue reading I’ve just custom-compiled ‘Aqsis’.

An Observation about NURBS

Given that the reader probably understands more about the Math of NURBS than I do, the reader will also understand that in general, true NURBS Curves will not touch their control-points. My own earlier misperception of that subject came through the use of the (now-defunct) application ‘TrueSpace’, which arbitrarily labeled objects as NURBS, which were really not that.

It should also be understood, that classic cubic (Bézier) splines were not NURBS either. According to my own understanding, a classical, cubic Bézier spline had as basis-function:

 


v = ( 1 - u )
a = a30u3 + 3a21u2v + 3a12uv2 + a03v3


 

This is different from the basis-function of a NURBS Curve. But for certain types of 3D graphics, an exact curvature and therefore basis function, is not needed(, and the two ways of formulating this curve may even have the same result – which I could not prove).

Given this understanding, a question might arise as to why the actual application “Ayam” is capable of taking an arbitrary CSG-primitive, and converting that into a NURBS-Patch.

ayam_7

And there are really several separate cases, in which this is possible:

(Last Updated 12/02/2017, 13h10 : )

  1. The Order of the NURBS may only be 2, given that the application in question has fully-general Math to work with NURBS. In that case, by default, the position of 1 point along a curve will be determined by 2 adjacent Control-Points, and at one exact parameter-value, will be controlled by only 1 Control-Point. This is a simpler type of NURBS, which will show as straight lines between the CPs, and which touches each CP. It’s useful to convert a Cube.
  2. True NURBS have a Knot-Vector, which states possible repetitions (“Multiplicity”), and Which the application in question does implement. When the Knot has a Multiplicity equal to the Order of the NURBS Curve, it takes over the position of the Curve completely. However, a given set of three NURBS Control Points can form a linear, equidistant sequence, with one Knot having a Multiplicity equal to the Order minus one. The two NURBS CPs that form the endpoints (of this sequence) can correspond to the ICurve Handles, while the NURBS CP in the middle can correspond to the ICurve CP. What will happen is that the NURBS Curve will touch the CP in the middle, but not the ones at the ends. This is similar to how a circle is formed, with an Order of 3.
  3. As an example of the type of spline described in item (2) above, if the Order is 4 – implying a cubic spline – and if it has its minimum of 4 ICurve Control Points, then the corresponding NURBS Curve will have 10 Control Points, and a Knot-Vector of { 0, 0, 0, 0, 1, 1, 1, 2, 2, 2, 3, 3, 3, 3 } . Please bear in mind that in general, the Knot-Vector may be scalar-multiplied by an arbitrary constant, and have the same meaning. ‘Ayam’ tends to scale its -Vectors such, that their range is [ 0.0 … 1.0 ] . Either way, the range corresponds to the range, which the continuous parameter needs to traverse, until the entire Curve is drawn.
  4. A NURBS-Surface – i.e., a -Patch – is a special case derived from a Curve, that has the two parameters U and V, where a Curve only used to have one parameter. The CPs are sometimes conceived to form a grid with rectangular topology. It seems entirely plausible to me, that the Order along U may be different from the Order along V, and then having a linear Order along one parameter, may be the correct way to convert a Cylinder or a Cone. In that case, a Disk may simply be a special case of a Cone, where one parameter forms a circle, and the other, linear parameter defines either the radius or the height – with a single CP defining either the center or the vertex.
  5. Most plausibly, if the NURBS-Patch is to have a different Order along U from its Order along V, it should also have two separate Knot Vectors.
  6. It was a convention of certain software in the past, that a Control-Point which the curve is actually supposed to touch, simply continue to be named a ‘Control-Point’, but that the Control-Points which define the derivative with which the curve passes through these Control-Points, be named ‘Handles’. Certain other references define the CPs which the curve is supposed to touch, as the ‘End-Points’, even if they get reused by two segments of the Spline. In reality, when dealing with NURBS, all forms of such points are still ‘Control-Points’, but in this posting I’ve chosen to name the CPs which the curve is not supposed to touch, ‘Handles’, in keeping with software-conventions I’m familiar with.

‘Ayam’ is an application that will allow its users to edit the Knot-Vector manually, if we switch to the “Custom” Knot-Type. However, if we’re experimenting with this randomly, we may easily create Knot-Vectors which the Ayam can’t render, thereby resulting in some error messages. Finally, I was able to implement my above idea in full:

ayam_8

This screen-shot actually reveals that ‘Ayam’ is not always able to determine what the correct increment is, of its parameter, for the Curve always to appear smooth. However, because this application’s preview panels are just that, and because final rendering is meant to be performed by an external renderer, I don’t mind.

The WiKiPedia article explains, that in order for a 3rd-order NURBS Curve to form a circle, its Knot-Vector should be:

wiki_nurbs_1

But the same article also explains,

“For the purposes of representing shapes, however, only the ratios of the difference between the knot values matter; in that case, the knot vectors (0, 0, 1, 2, 3, 3) and (0, 0, 2, 4, 6, 6) produce the same curve.” (Both quotations from 08/29/2017. )

So while it may have been important to prove the above Knot-Vector, in ways that involve the constant π, according to the same reference, the entire Knot can be multiplied by ( 1 / 2π ), revealing a linear spacing between Knot-Values.

In my own example with 4th-order NURBS Curves, my only aim was that the handles around each control-point, that would have corresponded to a12 and a21 in the case of a Bézier spline above, and which I tend to denote with the character H, form working handles around each control point, which I tend to denote with the character P. I never aimed to prove that the resulting NURBS Curve forms an exact geometry.

Dirk

Continue reading An Observation about NURBS

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