The Velvety Bloodsucker, the Twinheaded Dandy and Other Euloran Hopefuls

April 11th, 2020 by Diana Coman


~Born of Chaos and Havoc, madam. Originally they comprised a litter of five. [...] And, being at heart more a philantropist than a businessman, and deeply sentimental as well, I have even allowed you to retain Foolishness, who took a liking to you for some reason that I am entirely unable to fathom. For that, too, there is no charge.~

This past week has been quite some fun in my experimental laboratory of possible life forms for Eulora. Before getting on to skeletons and messing about with deformed meshes, I had another go at textures too since they are equally important really - in this trompe l'oeil game that computer graphics plays at all time, shape and variety is not always a matter of volume and surface but at times simply one of applied paint and light reflection, hence of textures. And since the base shape otherwise ended up so far to be this sort of rounded cylinder, I started by trying out a different sort of texture mapping too, to better fit this situation - instead of mapping the texture in that hap-hazard, geometrical-patterns inducing way I did before, I switched to a spherical mapping that works actually surprisingly well in that the texture's pattern seems to me to help the brain that tries rather desperately - as it always does - to find some meaning even in the weirdest of shapes. And here's for fun and giggles the long-nosed cylinder showing off its spherically mapped Mandelbrot texture:
multifractal_2_640.png

Besides the new mapping (it's an option now available, not necessarily a replacement of the old mapping), I further experimented with making fractal textures1 and I ended up literally making red velvet, my absolutely favourite texture of the bunch! It turns out the main bit I was missing earlier was the idea of multi-fractals really ie applying a fractal to a fractal pretty much. To see just what I mean, here's an image setting side to side the results of a single application of the fractal transformation compared to three successive applications - the difference seems striking to me and have in mind that this is literally just black and red in there, not even a complicated texture by any means:
multifractal_9_640.png

The velvet above (scroll down for its application to a creature if you are not convinced it's really velvety) can equally be made any colour really, with the pure green or blue on black being of course just as striking as the red above. Mixing in some fixed amount of any of the other two colours while messing about fractally with one yields quite a few variations too so velvety textures are essentially cheap in Eulora nowadays. Anyways, there's more to it, as bringing in colours and messing about further with various parameters yields also other sorts of textures even if the colours are similar, for example:
multifractal_11_640.png
multifractal_12_640.png

Having set my mind at rest that I am not forever stuck with only that yellow-blue mandelbrot texture for everything euloran, I switched afterwards to giving another go to skeleton and mesh creation. I started by implementing the skeleton generation as previously described aka through a pseudo-random selection of points and connections within a unit sphere. In practice, the approach seems to yield mostly overlapping bones but I can't even say if that's something all that undesirable or not - it's certainly different from what I'd normally have in mind when thinking "skeleton" but CS/Cal3d seems to handle it nevertheless at least so far ie while not trying to move the meshes around, so perhaps Eulora's skeletons will just be like that, a bunch of overlapping bones criss-crossing one another, why not. To be able to actually see the "bones", after a few attempts to use the previous cylinders, I gave in and made the meshes very thin before setting them on the skeleton, so the result is a sort of stick-insects life forms, like those (note that at times some of the "bones" can end up even inside or partially inside the mesh on another bone):
multifractal_3_640.png
multifractal_4_640.png
multifractal_5_640.png
multifractal_6_640.png
multifractal_15_640.png
multifractal_61_640.png

For what it's worth and because I had to try this and see the results for reals, I implemented also a slightly modified version of picking the points so as to reduce the amount of overlapping: I took first a set of points in the "core" of the sphere (ie using a smaller radius) and connected those to make a "trunk"; then picking at random some points in each of the four quadrants, I connected them pseudo-randomly but without crossing from one quadrant to another, to make "limbs" of sorts; each "limb" thus made was then connected to the closest point on the "trunk". For all the trouble of such careful avoidance of criss-crossing, the difference is not that huge though and so in practice I am not all that sure it's worth the trouble. I still left the generating code in there, commented out but ready to recover if it turns out perhaps at animation time that it really is better to have that sort of trunk & limbs rather than spaghetti-like skeleton, it may be. Here's a few illustrations of the results, too:
multifractal_21_640.png
multifractal_59_640.png
multifractal_60_640.png
multifractal_63_640.png
multifractal_64_640.png

Having thus a skeleton-generation mechanism all set and ready to fire, I turned back to my mesh generation -and deformation- scripts to try and find a better way to do it. I brought in the Mersenne Twister prng2 to give me a cheap and reproducible way to generate any number of meshes and then I experimented with fractals and multifractals - still based on the fbm of last week, but applying some domain distortion (aka messing about the x,y,z values *before* passing them to the fbm, as a known and cheap way to avoid alias AND get more interesting results) and going at it similarly to the textures earlier, the multi-fractal way. Combined with thicker meshes to give the fractal some space in which to do its job, the results turned out quite interesting I'd say - or at least way more interesting than those of last week. Note that in all cases so far, each "creature" is made out of just ONE mesh that is simply scaled, translated and rotated to match each of the bones in the underlying skeleton. This can be of course changed - so far I stuck with it just because it's easiest with the current scripts ie one single mesh generation and then out of that a whole creature is made and shown. The original yellow-blue mandelbrot texture works at times quite well too, I'd say, creating some sort of "eyes" or whatnots but I still like that red velvet most! Anyways, here's the parade of hopefuls, starting with the Velvety ones and the Twinheaded (or even triple-headed!) Dandy:
multifractal_45_640.png
multifractal_50_640.png
multifractal_14_640.png
multifractal_48_640.png
multifractal_1_640.png
multifractal_7_640.png
multifractal_8_640.png
multifractal_10_640.png
multifractal_13_640.png
multifractal_16_640.png
multifractal_17_640.png
multifractal_18_640.png
multifractal_19_640.png
multifractal_20_640.png
multifractal_24_640.png
multifractal_25_640.png
multifractal_26_640.png
multifractal_27_640.png
multifractal_30_640.png
multifractal_31_640.png
multifractal_32_640.png
multifractal_33_640.png
multifractal_34_640.png
multifractal_35_640.png
multifractal_36_640.png
multifractal_37_640.png
multifractal_38_640.png
multifractal_39_640.png
multifractal_40_640.png
multifractal_41_640.png
multifractal_42_640.png
multifractal_43_640.png
multifractal_44_640.png
multifractal_46_640.png
multifractal_49_640.png
multifractal_51_640.png
multifractal_52_640.png
multifractal_53_640.png
multifractal_54_640.png
multifractal_55_640.png
multifractal_56_640.png
multifractal_57_640.png
multifractal_58_640.png

As parameters, it turns out that there's quite a bunch that can be used. One that seems at first obvious but turns out in practice to have very limited useful range is the "noisiness" of the fractal itself - the higher the noisiness, the more "rugged" the mesh ends up as. Here's an example with this turned up a notch (more than this and the result ends up close to just noise really):
multifractal_28_640.png
multifractal_29_640.png
multifractal_47_640.png

More useful - if rather unexpected - parameters would be the length and thickness (basically the maximum radius of the cylinder) of the shape at generation time. While scaling it afterwards to match the bone means that any shape can be used on any bone without any trouble whatsoever, the original length and thickness matter quite a lot - too thin meshes don't leave much space for any meaningful deformation to effectively create anything interesting, while too wide meshes make for rather obese life forms (or otherwise very rough approximations by the polygoniser since the triangles need to be rather large to cover the whole thing and not leave it unfinished in parts). Besides those, there is also the seed used for the prng when picking up values to modulate the fractal application. Note that in all the above, I didn't even turn off entirely the fractal deformation anywhere - it's simply applied with a factor of magnitude given by the prng sequence. A few experiments trying to apply the fractal deformation only at pseudo-random places and leave the rest undisturbed didn't work that well in practice as there's just too sharp a difference between the two cases and the result is a broken shape that doesn't even render all that well in CS. By contrast, all the above fully closed shapes rendered quite fine - even though CS still complains at times about "corrupted faces" - possibly too narrow triangles or something.

Having looked during this past week a lot of many shapes similar (but not quite identical, ie statistically similar rather than identically similar, since this is exactly what fractal generation does) to those illustrated here, I think I probably need a break from them to be able to see them again with fresh eyes capable to say whether they are fit for purpose or to what extent so I'm quite curious how they seem to you, what you think of them so far and/or what directions would you like explored further on meshes, textures and skeleton - if any, so far (or perhaps at a later point after having some animation working too, to see for instance if the criss-cross of bones causes big trouble or not).

I can't even decide if this approach of making the whole creature of a single mesh is a problem in itself or not but I guess it can't hurt anything to do as the next step the changes required to generate creatures out of distinct shapes too - at least for variety if nothing else. At any rate, all the parts can be mixed and matched as desired really - so there can be variety from combining meshes, skeletons and even textures as desired. For instance, the fact that a creature uses now the same texture for all its meshes is just a matter of the test code in the client simply picking a "default texture" that it applies to everything - note though that the mesh itself contains simply a mapping that applies equally well to *any* texture of the same size, so swapping a texture or another is literally just a matter of loading one png or another, nothing more. And none of the images above bother with any shaders or more intricate anythings, it's all just a plain png as texture with the spherical mapping and that's that.

In addition to generating creatures out of distinct meshes for each bone, the next big chunk of unknown to start sorting out would be the animation. In principle, fractals can come in handy for defining animation too but in practice I have so far no clear idea on it at all, so I'd need to start looking at it and trying it out. Moreover, for any animation to show in the client, I really need to figure out and generate the full set of information required by cal3d on all bones as well as on animation itself so that's another big chunk on my to-do plate, too.


  1. All this reading and re-reading of fractal theory by the bucket seems to finally start paying off better, as it's all coming a bit more together in my head, so yes, play time got better too. As a side effect, I did get fed up with the cumbersome texture writing as png from within the client using the whole weight of libpng and so I made a separate tiny C code that doesn't bother with compression but can write nevertheless perfectly fine .png files and otherwise allows way faster experimentation with fractal generation. While I still think that the client should use the compressed .png texture files, the uncompressed ones do just well for this experimenting stage and there's no problem that I see in compressing them afterwards even, if needed. 

  2. pseudo random number generator