Ossa Sepia

~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:

Besides the new mapping (it’s an option now available, not necessarily a replacement of the old mapping), I further experimented with making fractal textures ¹ 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:

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:

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):

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:

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 prng ² 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:

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):

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[↩]

The work on Eulora’s client during those past 10 days ¹ went mostly as planned, towards setting meshes on sticks (“bones” if you absolutely must) and therefore on cal3d sprites rather than just plain CS meshes. The main unplanned part included sorting out some additional wtf related to the way in which textures are set for Cal3d meshes ² and otherwise the more pleasant fact that I finally got to a point where I had enough of an idea of the whole pipeline so I could consolidate the scripts and the client into what is now a much quicker way of going from “try this” to “here’s how it looks in Eulora”: basically I can make changes to the surface generated directly and then run one single script that recompiles the code, runs the polygoniser, then the formatting for cs and cal3d, then the setting of meshes on a skeleton and then finally moves them to where the client expects them, launches the client and let’s you gaze at the horror -or beauty, whatever- shown. And to illustrate this, here’s Cyli N’Der, the rather cute robot-like set of same-mesh-on-various-bones that photo-bombed Cally one day:

While there are quite a few new bits and pieces done over those past 10 days, from a practical point of view it makes most sense to look first at the whole resulting pipeline instead of what happens to be new and where. So here’s what pipeline I have currently:

1. Surface definition and polygonization (C).
2. Formatting to CS and Cal3d mesh formats (.xml and .xmf, respectively; awk).
3. Setting of a mesh to a given bone, with some simplifying assumptions (awk).
4. A basic “skeleton” creation (and mesh setting on each bone) based on given width, depth and height of the bounding box for the creature (awk).
5. Loading and showing of a Cal3d sprite from Eulora’s client bypassing all the PS soup and based simply on *number of parts* and naming convention (aka sanely in a for loop instead of idiotically listing each, ffs) (C++).
6. A bash script calling in turn *all* the above, including running the client so that it’s enough to change the surface definition, decide on desired parameters for the polygonizer and then just run this script to have everything done and actually see the resulting sprite directly in Eulora ³.

Surface definition and polygonization

This is based on the original polygonizer to which I added however quite a few bits to try out and experiment with different surfaces and ways to define them. Essentially it turns out that the results are at any rate best for CS/Cal3d when the surfaces are indeed closed – while the polygonizer is perfectly fine with any open surface just as well, the resulting mesh & sprite trips CS every which way and it’s really quite annoying because it vanishes unexpectedly (bits and parts become invisible at various angles) and it generally ends up even difficult to have a proper look around.

Having read some more on the topic of implicit surfaces and modeling with them, I experimented with a few types (e.g. revolution surfaces and “charges”-based ones) but the one that seems most promising currently -as a base surface so to be messed with, not used straight as such- might in fact be the cylinder with rounded ends. There are ways to make branching cylinders (the name ends up misleading since the result really is supposedly looking like a trunk with branches growing out of it rather than a “cylinder” at all), to blend them reasonably well at joints and moreover, to make them even into generalised cylinders – meaning “cylinders” defined around an arbitrary surface rather than just around a segment of a line. The Cyli sprite shown above is the result of play a bit around with this rounded cylinder shap – all its parts are in fact the same mesh, only set on the various bones and the mesh itself is a cylinder but with the half-sphere at one end with a bigger radius than the cylinder itself and set the “wrong” way. For the “correct” plain cylinders (around line segments since those are the “bones”) and their mixing and setting about on various “bones”, here are some screenshots – the first 7 are of single-end bounded cylinders and some experimenting with slight bulge in that area, while the rest are of fully bounded cylinders with matching half-spheres on both ends:

Formatting to CS and Cal3d mesh formats (.xml and .xmf, respectively)

This takes the output of the polygonizer (which is plain text), assumes a fixed size for whatever texture may be used, goes through all the input data collecting everything needed, does the mapping of vertices to corresponding points in the texture and then spits out 2 files (one for CS non-moving mesh and one for Cal3d mesh that is part of a Cal3d sprite) that represent the same mesh and with the same texture mapping. At this point the mesh is still as obtained from the polygonizer so without any scaling/translation/rotation applied. Some additional screenshots for this:

Setting of a mesh to a given bone, with some simplifying assumptions.

The trouble addressed by this part is that Cal3d/CS expect the various meshes that make up a character to be set at the position (including rotated as needed) in which they are meant to “fit” as part of a whole. Basically Cal3d/CS do *not* provide any way to simply take a mesh and fit it to a bone/skeleton but expect instead to receive – yet again, as everywhere else – the mesh already set aka moved and rotated and scaled or whatever else exactly as it is to be shown on the screen as part of the character. So I wrote a mesh2bone.awk script ⁴ that takes as parameters the start+end of a bone and then scales+translates+rotates a mesh to match that bone. It’s still relatively crude but it does the job perfectly fine.

This script takes as input the Cal3d mesh file produced by the previous script and the two endings of a “bone”. It makes the assumption that the mesh is set in the origin and oriented “up” on the y axis – while this is a simplification, there’s no loss to it as far as I can see: for one thing my surface & polygonizer can generate the mesh exactly like that without any trouble and for the other thing, once this part is set, the mesh can *then* be moved wherever and however needed.

With the above assumption, the script simply calculates the length of the given bone and uses an assumed length of the mesh ⁵ to figure out the required scaling factor. It uses the start position of the bone to calculate the required translation (3D). It uses then the bone as a vector to calculate the rotation (3D) required to bring the mesh’s own assumed axis (aka 0,1,0 since it’s the y axis, positive direction) to that of the bone (the axis of rotation is given by the cross product of the bone & Y axis while the angle is obtained from the dot product). Scaling, translation and rotation are applied then to vertices and normals as read from the input file and the result is written as another Cal3d mesh file that can be read directly from Eulora’s client. To illustrate, here’s a screenshot of setting some sort of egg-shapes on a skeleton:

A basic “skeleton” creation

This is currently very basic indeed and will need to get expanded later on. It takes width, depth and height as inputs ⁶ and then it calculates the starts/ends of a 5 bones skeleton with 2 upper limbs, 2 lower limbs and a connecting vertical “spine”, just about as simple as it can possibly get. It then calls the mesh2bones script to set existing meshes on each of those “bones” but so far it does not write out the skeleton file itself (mainly because there’s no need for it yet – it will be required only at animation time and there’s still some wtf to be sorted about what calculations are needed to provide the data the exact way that cs/cal3d expect it).

A bash script calling in turn *all* the above

The title says it all really but the great thing is that now I have this in place, I can finally start properly experimenting and trying stuff out so we get to see what and how works or not. For starters, I added to the surface/polygonizer the simple Perlin noise (the 2012 updated version though as it fixes some issues) and two variants (exponential and polynomial) of the fbm ⁷ to see what they can do to a poor cylinder surface. Using the fbm to change -fractally, essentially- the radius of the cylinder certainly has a visible effect indeed although it seems that it’s in all cases almost too fine, basically a sort of effect that gets perceived more as texture than as shape changing. Anyways, here are some screenshots, to get an idea of what is going on with this particular approach (the spiky cubes are obtained if the “deformation” is way too big so that the result ends up more of a visualisation of perlin noise fractally composed than of anything else):

The most important next part seems to me currently the further exploration of shapes (branching cylinders and generalised cylinders are currently on the list to try out at least) and of better ways to apply fractal deformation/surface definition to get both textures and working character variations.

1. There is still quite a lot of reading required and so the write-up interval doesn’t quite stabilize that easily – I could make it every week and then end up with one week reporting mainly reading and very little concrete to show for it as I’m still digesting what went in; or I could go for 2 weeks and then at times I have a ton done and pending write-up and slowing me down. So ugh, so far I kept to the “report as you need”, hence the rather unpredictable intervals, sorry. If it does create a problem, let me know though and I’ll stick to a fixed interval one way or another. At the moment I’m going for at most 2 weeks but reporting it earlier if it accumulated and it requires the write-up.[↩]
2. Since it turns out that CS relies on Cal3d’s own format for the texture mapping although it does *not* use Cal3d’s format for materials. So if previously I had figured out how to write a CS mesh file including texture coordinates, now I got to further figure out also how to write the same texture coordinates in a way that the Cal3d code understands, from its own mesh format. The document describing the format is useful to some extent but not fully since it’s more an indication as to what you may find in a file of that type rather than the exact precise way to specify it, sigh. Anyways, reverse engineering for the win – basically I converted back to xml one of the existing mesh files and figure it out from there, what more can I say. It works.[↩]
3. It’s *such* a relief to even have this working as smoothly as it does.[↩]
4. Because fuck the c/cpp that is 10 times more cumbersome even for this while delivering only the great benefit that I also need to re-run gcc every time I make a change, such benefits that I can’t begin to wish for more of them, right?[↩]
5. This can be in principle calculated from the input data but so far I didn’t implement that – it would require again reading all data upfront just to calculate this; it probably will get done but it wasn’t absolutely needed just yet.[↩]
6. The idea being that the ratio height/width should even be enough to tell if the skeleton is meant to be biped or quadruped really.[↩]
7. Fractal Brownian Motion[↩]