Although – or possibly exactly due to the fact that – the previous parade of Euloran hopefuls was rejected wholesale as too cancerous-looking, word seems to have spread out in the vast lands of Chaos and Havoc about this unique opportunity for all the twisted creatures out there to come to light and have a career annoying human players and other annoyable ones. As a result, here I find myself swamped with pics of hopeful-talent begging for a place in this article. So scroll down for the images or keep reading for all the details how they came to be as they are.

The delay of 11 days since last parade is due mainly to the work required to sort out first all the more serious troubles of this invading talent: disjointed bones, stacked up piles of required transformations and otherwise additional calculations and headaches to figure out and finally fit – or so it’s hoped ¹ – that annoying straitjacket that goes by the name of cal3d’s skeleton format ². Once all bones were thus helped to fall more or less graciously somehow in place, the rest consisted mainly in bashing and awk-ing a few over the head of the otherwise uncooperative client code ³. The result of it all was a very busy computer churning out meshes and skeletons, setting the first on the latter, firing up the client and letting the resulting hopeful pose before a nearly invisible Cally, taking a screenshot, killing the client ⁴ and then proceeding to repeat as requested. Having thus set the computer to work, I went and soaked up the sun outdoors while the scripts worked tirelessly, the hopefuls hoped hopefully and otherwise the material for this article of mine was getting nicely done, sorted and stored in the right place too, “all by itself” ⁵.

Before moving on to all the images though, here’s the summary of the main parts done since my last article on this, mainly so that I unload it all and have it here as reference for next article:

1. Updated the skeleton generation so that:

   • – bones in the skeleton don’t criss-cross/overlap one another: the algorithm starts now with the point closest to the centre of the unit sphere and then expands from there greedily, picking up at each step the next unconnected point that is closest to the sphere’s centre and connecting it to the closest point to it that is already connected.
   • – the number of points in the volume and on the surface of the sphere as well as the seed to use for the prng are exposed now as parameters to the script – this was needed and is useful at automation time, to generate as many skeletons as I wish. Worth noting here that each skeleton generation uses only the beginning of the prng sequence with the given seed – I don’t think this is any issue as such but still better written out in clear.
   • – the resulting skeleton is also written with *all* the required calculations of *everything* in the .xsf format that cal3d understands. This was the biggest pain and time-eater this past week, by far. Eurgh.

2. Updated the script setting a mesh to a given bone:

   • – the script calculates now the actual length of the mesh from its vertices and uses that to figure out the required scale factor so the mesh fits the length of the bone. Previous version of this script used an approximation based on the parameters used at mesh generation time – it was good enough for starters but it kind of reached its limits when I really turned on the knobs to generate hundreds of meshes and all that as in some cases the error was annoying.
   • – the script also figures out the lowest point of the mesh and then does the required translations so that the resulting mesh is always “on the ground” basically. This was needed because otherwise there is variation and it’s impossible to set anything so it’s in a fixed place – some would be too high up and others end up underground.
   • – a fix so that the mesh after all the required transformations is indeed set exactly where the bone starts; it turns out the previous version had an error due to how the transformations combined and that error resulted in some poor disjointed creatures with gaps between meshes. As this sort of errors tend to go, it took some hunting ⁶ to find out just which tiny bit and where was I getting wrong in all that but that made it all the more satisfying when I finally found the trouble and fixed it – the result is happily jointed creatures, too, so hooray!

3. Read some more and this time I finally managed to find the out-of-print original Peitgen book which turned out to be a pleasure to read even though a rather hefty one if one looks at the number of pages. Unlike the easy-to-find and way more popular book with shiny pictures ⁷ that focuses primarily on the various discovered “ways to do this or that” ⁸, Peitgen’s book focuses on walking the reader through a way to building up their understanding of fractals and how they are linked with chaos theory.
4. Experimented some more with different mesh deformations and what various parameters may or may not do – the main benefit here is that I quite know by now in the current setup how the various parameters tend to affect the result. Given the previous “cancers”, I pushed the buttons to have less of that and more of “creatures” but I’m not sure it’s quite there yet. I even generated a few meshes without fractals altogether, leaving the deformation to prng alone – the results are not terrible perhaps and they are certainly less intricate but I don’t think they are any good or even really in the best direction either. Instead, I think it’s possibly a different base function that might be more promising but as it tends to happen, the idea came fully formed only today after all the week’s reading and experimenting had time to settle down a bit and started to come together otherwise.
5. Experimented a bit more with textures too – just like for meshes above, it’s still not fully there yet and I have some promising ideas and directions to try out moving on, so whenever I’ll get some time for it. Anyways, I did get a few variations and got some not-bad new textures too. One interesting thing to note though is that there are textures that look lovely as images but don’t turn out all that well on the creatures themselves so there’s apparently some more to experiment on what matches the meshes and what doesn’t!

To start with, here are first a few texture pics:

Two of what I call “overdone” textures – they look like that to me as images but otherwise they can turn out not-bad on a mesh (especially the one on the right that is a multifractal as opposed to the one on the left that is just a higher level of noise single fractal):

Two sets of textures obtained by varying the colour and domain coding while still using a multifractal – especially the 2 in the second pic tend to give meshes this sort of “transparent creature” effect, I’d say:

A set from the play with stereographic mapping of the texture’s domain itself – I was curious how this turns out especially because I am currently using stereographic mapping from the texture to the mesh itself so it made sense to see if generating a “spherical” texture to start with works better. In practice I wouldn’t say it does, no. The difference between the two textures here is given by the amount of “noise” allowed in and the number of fractal iterations (they are both single fractals though):

One texture where I just tried out trig functions, without any clear idea really:

Finally, some differently coloured Mandelbrot’s as I ended up using the black and white one for the parade of hopefuls (though the yellow /single coloured ones also create at times interesting effects):

And finally, the pics you wanted all along – the hopefuls themselves! They are *all* generated using the very same mesh, just set on all the various bones so that the whole difference between what you see is at all times just one of skeleton. Here’s the first set of 50, generated ALL with skeleton seeds from 1 to 50 (MT prng), with points in the sphere volume between 4 and 8, points on the sphere surface between 4 and 8:

While the above set turned out some funny creatures, I thought they really could do with more bones to help shape out some proper poses. So here’s another set of 50, using the same skeleton seeds but with points in the volume between 7 and 13 and on the surface again between 7 and 13:

I should say the above makes for some clearer tails and even various potential limbs of sorts, even though the poses are full of…enthusiasm at times! The first two above got to try on some other skins too (see at the very end for the shots), as I think they are actually not that bad at all but in any case, otherwise, why stop at 7 to 13 bones when I finally have all the scripts at the ready? Let there be bones for everyone, so here are the shots from a run with 21 to 31 points in the volume and another 21 to 31 on the surface – those are only for seeds 1 to 31 as it turned out that even 4 seconds was not enough for CS to fully render the resulting mess-of-a-mesh and I didn’t bother to redo the run just for that (each additional bone adds up another full set of the original mesh’s vertices and apparently it’s not that hard to make CS slow down this way, at least when measured against the controlling bash script’s rush to shoot, heh):

I find quite a few in the above set absolutely hilarious – for instance the one at skelseed 24 still makes me laugh, no matter how many times I saw it. So maybe it’s not all that bad, with this idea of increasing bone count, after all! But still, since they already look segmented enough and otherwise CS/Cal3d seem to huff and puff for longer than before, how about turning instead the knobs to have more points on the surface, in the idea that this way there’s a push towards getting more limbs of sorts, right? Right, so here’s the result of the run -another 50 shots!- with points in the volume between 3 and 5, while points on the surface are between 5 and 13:

Having made it *this* easy to turn knobs around and get silly stuff, I couldn’t stop there, of course. Next run had 3 to 8 points inside the sphere and 9 to 31 on the surface:

While there seems to me that there might be a slight difficulty in deciding just which parts are what sort of limb, I’d say at least that in the above case, limbs there are quite plenty at times! And seed 25 even looks to me close enough to those American football gear types – overgrown/padded upper limbs ftw! Anyways, last run of silliness for today comes with points in the sphere between 5 and 9, while points on the surface are between 11 and 21:

Note that all the above use just one mesh that is created with one seed and so yeah, one of any number available otherwise. But this aside and in the most utterly serious manner otherwise, I also threw various pots of paint at 2 of the creatures from the set with points 7 to 13 (same inside as on the surface) while they were posing:

For the next steps, the main new area opened up for work now would be animation really – getting to figure out how to make all those bones move too, so that it gets really interesting. Other than that though, there would still be more experimenting to be done, perhaps implementing and trying out some new base function(s) for the fractals to see if I can have it generate meshes that look -perhaps- more like tool-yielding creatures than like drunken knotted fluffy ropes of sorts!

There’s also a potential issue to consider as the more intricate the mesh is, the more vertices and triangles the polygoniser is forced to generate and that gets multiplied by whatever number of meshes a single creature is made out of. On one hand I can always make the polgoniser’s steps wider and so reduce the number of triangles but on the other hand, this reduces also the detail and thus how interesting the resulting mesh is. At the moment there was a visible slowdown noticed when I ran the generator with most bones (hence most meshes per creature too) – I had to increase the delay of the bash script to 4 seconds to make sure that CS had time to render everything before the screenshot was taken.

1. This can’t really be properly checked until I have some animation going on too; and even then it will be a pain because “correct” is -in some interpretation at least- whatever happens![↩]
2. At which point I have to reiterate that no, cal3d’s bones are NOT bones at all, no matter what your optimism might insist on – they literally are articulations at most, there is no length either, not even implicit! It’s not the case that a bone starts where the previous ends (or that the previous ends where the new one starts), no – it’s just the case that the “length” like the “width” does not matter, it’s inconsequential. Each “bone” from cal3d’s point of view is just a point and that point is meant to be the new origin for all transformations related to the “bone”. So the “length” there doesn’t matter at all in any way and moreover, there isn’t even any sort of limit as to what bone acts on what mesh or anything of the sort! Basically a “bone” can even spread everywhere as far as cal3d is concerned – all that matters is where it “starts” and nothing more. This created first some headache as I was still -silly me- entertaining the notion that maybe I was indeed wrong and it was just some implicit length, so I was still trying to fit actual bones in that structure and getting all in a twist about it. This was solved of course when I finally figured out the different convention – although this different convention also means that in some cases I have some trouble when picking out a “root” bone because that can easily be the starting point of 2 bones in my generated skeletons. Anyway, long story short – it’s done now and so far cal3d eats it happily, I’ll see at animation time how it behaves and if there’s still any trouble left to smooth out in this area.[↩]
3. The darned thing initially failed to just set the camera where I wanted it pointing – because it turned out that there was another init that just forced a viewpoint it knew best! And once I sorted that out, I had further to hunt down where it insisted also on setting as initial camera mode this one where you can see the char with the camera but not what the char is looking at. After which it finally showed what I wanted – except there are still some slivers of Cally on the sides but who cares about those, just ignore them for now, I said. Except this was not all because the brilliant code has its own “screenshot” capability and that would be supposedly even better to use than taking an external screenshot as it can make sure the frame drawing finished before capturing the image. But then, it is “supposed to work” through a user command in the client’s own “command line” and otherwise the corresponding method is not exposed to be used by other code and moreover it wants a full-blown GEM-this-and-that and all sorts so that the whole thing turns out a simple screenshot into a huge thing for no good reason at all. At which point I just set the bash script to wait a bit for the client to load all, call imagemagick on it (import -window “Eulora (2.0)” $filename) and then just kill the client by pid directly. What can I tell you – if you keep saying you can’t do this and can’t do that and won’t do the other thing either, the result is not that whatever it was to be done doesn’t get done – it’s simply that it will not be done *with* you but rather *to* you and not in ways of your own choosing either.[↩]
4. I couldn’t be bothered to take the trouble to make it close down gracefully. Let it be killed several times per minute instead, can’t say I even feel sorry about it.[↩]
5. Could also just happen that my computer loves me, sure.[↩]
6. And recalculating the darned stuff several times again because I kept thinking I had just made some mistake when working out the formulae – but it wasn’t that this time, no.[↩]
7. Texturing and Modeling. A Procedural Approach. Ebert, Musgrave, Peachey, Perlin and Worley[↩]
8. Aka recipes, making for a rather frustrating read, especially as otherwise the authors clearly do have a deeper understanding of it all – they just cater to not stressing the poor reader because too many such readers, I guess.[↩]