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 

Comments feed: RSS 2.0

9 Responses to “The Velvety Bloodsucker, the Twinheaded Dandy and Other Euloran Hopefuls”

  1. Man, those textures... just beautiful. You've definitely made it into paydirt on that line, now just needs excavating.

    > In practice, the approach seems to yield mostly overlapping bones

    I do not think this is correct. Add a rule that an inside point must be connected to its two closest neighbours and may be connected to a third as long as that isn't also ; while outside points must be connected to its closest single neighbour.

    > I implemented also a slightly modified version of picking

    Nah, it forces you to provide too much input in the sense of providing the two spheres.

    As to the hopefuls... nice cancers you got there ; I suspect they'll need a litle more work before they're worthy of pretending to talk and use tools tho.

    > I can't even decide if this approach of making the whole creature of a single mesh is a problem in itself or not

    I'd say rather not. If we manage to get away with it, it'll be a great backend boon.

    > 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.

    Yeah, should do that, at least so we know kinda what we want to AI-fill in the first place.

    Great newspoint though, keep it up.

  2. Diana Coman says:

    Man, those textures... just beautiful. You've definitely made it into paydirt on that line, now just needs excavating.

    Hm, if only it was all that clear what exactly to do for the best excavation, lolz. There are in principle some "techniques" quite well described for using fractal generation to create also more "standard" textures like marble/wood/stone - should I look into those and implement them too?

    I do not think this is correct. Add a rule that an inside point must be connected to its two closest neighbours and may be connected to a third as long as that isn't also ; while outside points must be connected to its closest single neighbour.

    Uhm, it sounds like you are asking for an implementation of the nearest-neighbour algorithm pretty much and then the above doesn't guarantee that everything is connected or otherwise depends on the order in which the points are even considered. Overall it seems like overkill to me for this - might as well just start from the two points closest to the centre that get connected and then greedily expand from there picking up at each step the two closest and unconnected points for each "end", without really making any difference whether inside the sphere or on its surface.

    As to the hopefuls... nice cancers you got there ; I suspect they'll need a litle more work before they're worthy of pretending to talk and use tools tho.

    Lol, talking too! So I gather I'll need to look into fractally-generated sounds too?

    Yeah, should do that, at least so we know kinda what we want to AI-fill in the first place.

    Should do it anyway but no, the AI-fill part is clear enough: for each vertex, what bone(s) influence it and with what "weight" (a % basically) + the position of each vertex at each keyframe (if talking of keyframe animation since morphanimation was not considered an absolute must currently). The parts I'm talking about there are additional pre-computed values that cs/cal3d require as part of the format. Those are not to be AI-filled since they are simply calculated from the rest but they are still to be figured out exactly since I need to implement the actual calculations and they'd better be all as cs/cal3d expects them or I can't even get to see whatever animation I might generate. Anyway, I'll clearly still have to do it so might as well push it earlier, for all the yuck factor it holds.

  3. > here are in principle some "techniques"

    Honestly my best guess is "don't worry about it, let it come naturally".

    > should I look into those and implement them too?

    No.

    > Overall it seems like overkill to me for this - might as well just start from the two points closest to the centre that get connected and then greedily expand from there picking up at each step the two closest and unconnected points for each "end", without really making any difference whether inside the sphere or on its surface.

    This is just what I had in mind ; the inside/outside distinction is meaningful wrt position ; not connectivity.

    > So I gather I'll need to look into fractally-generated sounds too?

    Lol, I just meant in the abstract, "does this thing look like it could talk".

    > Those are not to be AI-filled

    Yes yes, I was just being pompous.

  4. Diana Coman says:

    Honestly my best guess is "don't worry about it, let it come naturally".

    Might be, although it's a wider "exploration of the fractal space" than just the basic tweaking of one set or another of parameters. Anyways, unless we specifically want those, there is otherwise no pressing need to pick to go there on purpose, sure. Worth noting though that not all the fractal space is worth walking either - even though it arguably provides a better way to explore than just blindly/randomly flinging pixels, it still has its pitfalls and dead ends and traps to waste one's life in.

    This is just what I had in mind ; the inside/outside distinction is meaningful wrt position ; not connectivity.

    Great then, I'll get to it this week and see what happens.

  5. Aite, so what did happen ? Did I miss an article here ?

  6. Diana Coman says:

    I'd say rather interesting things happened in the end but it took a while - and the write-up is pending but will come with > 100 pics! The parade of various hopefuls only ever increases!!!1

    You didn't miss an article, it's just not yet ready. The skeleton format and a few other bone-related unexpected things (transformations! on top of more transformations!) were quite a headache and some serious time-eaters so it all spilled into more-than-1-week (and per earlier agreement, I didn't rush to write it on the week boundary necessarily). According to my current plan, I should have the write up done by this Thursday the latest (though more likely by tomorrow by the looks of it - it's been a pleasure to watch the box churn out once I set the scripts running).

  7. Cool, looking forward.

  8. Diana Coman says:

    And it's published, phew. With all the ton of screenshots too!

  9. [...] - 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 [...]

Leave a Reply