This week's parade of hopefuls features a heartfelt attempt at zombiefication as well as several commendable efforts at horsification, frogification, carnivorousplantification and bring-your-own-imagination-ication. The show's 4th and improved edition provides all participants with an updated set of skins (that come each with their own specific pose, too!) including the best ones from the latest fashion, a doubling up on that 2nd plane of symmetry (of sorts), an abundance of bones going at times all over the place and bigger screenshots for all the bigger monitors out there. There's still a list of various things I want to try whenever I get a chance, including both texture and mesh attempts. For now though and for future reference, here's again the list of changes implemented this week:
- first plane is defined by the 2 points furthest apart from one another + the one point that is closest to those 2, where "closest to those 2" means that the "sum of distances from candidate to point 1 and to point 2 is minimum";
- ALL points (original as well as those reflected in the 1st plane) are reflected in the 2nd plane (so total ends up 4 times the original number but then the collapsing drops up to 3/4 of this total and usually it seems to drop indeed that many);
- took out textures 8 and 9 (mandelbrot grays & mandelbrot blue+yellow);
- added textures 1,4,13,14 from new set so the total textures now is 13;
- replaced fixed pose with a rotation by a prng-number of degrees (around all three axes) using texture's number as seed (so that each texture has its own); this is shown in the file's name too, for easy ref;
- client's window is made bigger so that the screenshot is 1280px wide to start with, so the detail is there;
- the fix to remove that seam from the texture mapping is in as well.
Here's the absolute winner of this show's edition as far as I'm concerned:
In other commendable entries that will therefore remain here even after the full dump1 gets wiped out, there's Horsey and his gang of hopefuls:
Until next time, the past, present and future hopefuls, all want to wish you a well-jointed weekend with rounded symmetries, interesting skins and most pleasing rotations!
50 skeleton seeds * 2 symmetry planes * 8 combination of points * 13 textures = 10400 screenshots. I've made them .jpg though as there isn't any visible loss really and the size is half of png so that the whole thing does not weigh 5 Gigabytes or more, sheesh. Fwiw, it took me about 2 hours to just go through all of them this time. ↩
Comments feed: RSS 2.0
Do I even need to explain -- can it even be explained -- how fucking fabulous it is to hear "by Friday the latest" and then sit Saturday morning with the damned thing, as you had planned to do, and EVERY TIME ?
Because it's pretty fucking fabulous, let me tell you, I took a great shit and now here I sit with my greek style chefir and my diana-style hopefuls, oh what a joy divine.
Nice intro, too, Mz Barnum! I lolz'd&chuckled.
~to be continued~
God fucking help us... I think next time it'll work better as a single archive rather than this wgetting individual jpegs piddly business ; and also ima have to do something to reduce the pile, going through 10k imgs is no joke, will take some digestion.
Making it an archive doesn't help all that much, since they are already compressed so you don't gain anything in terms of size, only at overhead perhaps and there's the potential downside that a glitch means all of it is borked. This is why I didn't really make it an archive. I'm all ears for any way of reducing it - that's pretty much the thing with unleashing this beast, that it knows no limits, there's literally tons of them waiting to be generated and so it's back to that filtering the sea or something.
I was considering though if it's not actually easier to pack the whole code and send it over with a readme and all that but in all fairness, it's at most a workaround.
To add to the pile, yesterday I finally got around to up the game a bit on textures too so that I have it now at the point where I can ... turn knobs and generate whatever set mixing and matching mappings of texture domain, noises & styles, colour mappings. Looking at a set of those swirly textures was like looking at a flowing river with weird eyes that get from time to time in the right place to seem part of something. On the bright side though, those clearly work perfectly fine for animating stuff - it's a river, it flows, there's no doubt about it.
I think I might still spend some time today just looking at all sorts.
Great to hear it's very much appreciated!
I suspect most of those 7 hours (as in, about 5) were spent doing dns calls and getting server connections. Otherwise 1MBps gets a coupla gigs in anhourish you know.
Yup, I've got very much what I asked for, no complaints whatsoever, I'm quite satisfied.
As it turns out the adventure is stressing out all sorta infrastructure, I am apparently poorly equipped to deal with five figure imagesets in every which way, but it's being fixed as we speak and so... really, these are the best problems to have, I wouldn't have constructed anything else.
I expect that works fine ; for my part I don't expect I'll manage to dig myself out of the pile you snowed me under before Wed at the earliest, and so therefore you get to focus on other sides, this channel's well stuffed.
I must say the larger imgsize makes all the difference ; these are a genine pleasure to wade through. Besides that, here's a first set of notes :
skel_51_vol57_57_srf119_119_sym_1_tex5_rot66_1280
Aw fuck again with the brackets. Brb.
I must say the larger imgsize makes all the difference ; these are a genine pleasure to wade through. Besides that, here's a first set of notes :
skel_51_vol57_57_srf119_119_sym_1_tex5_rot66_1280 << this model is very interesting for a sea creature/plant sorta hydra. i think it may work well as it is really, for that purpose.
skel_52_vol11_11_srf5_5_sym_2_tex13_rot129_1280 << take this one specifically ; what decides whether very thin segmental strangulations occur (as seen in the very middle) rather than the thicker constructs on the periphery ?
I am also perplexed by the way symmetry works out ; are you absolutely certain the implementation is a bug-free translation of the spec ?
skel_52_vol29_29_srf37_37_sym_2_tex1_rot121_1280 << how expensive is something like this guy in game terms ? say in multiples of a caly or something ; could we actually mass deploy them into the water as decor ? and how about skel_52_vol57_57_srf119_119_sym_2_tex3_rot355_1280 ?
skel_52_vol29_29_srf37_37_sym_2_tex4_rot214_1280 << probably the best texture of the lot ; how was this made again ?
skel_60_vol11_11_srf23_23_sym_1_tex7_rot184_1280 << i think this texture can also be taken out as not really good enough anymore. it was pretty fucking cool back in the early days, but facts are facts : it could be a rock or something (so save it for fire etc), but it can't be a guy. Same goes for tex2 (could be a grass cheap paint i guess) and 3 fire-like thing. Six is also dubious (though it'll make a great sky ; none of that plain blue skybox bs no mo) but let's keep it for now. And incidentally, do you have more candidate textures to propose wink wink nudge nudge ? :D
skel_79_vol11_11_srf23_23_sym_2_tex13_rot129_1280 << whoa check it out, scorpion tail!
This is the fundamental problem here, this rubberbanded effect, almost as if everything has to be pinched in segments, like we're doing balloon knotting or something. This is in fact how things even work, at least on occasion, but only up to about insects or thereabouts. It's stunting us, it looks almost like "every bone must be shown" is an undeclared but ever-present rule of the generator, there's no such thing possible as a jointure underskin.
The tails in skel 88 are actually pretty fucking cool also ; is there some way we could isolate them ?
I suppose this is in principle a possible avenue to success here, end up with disjointed body parts vat-produced, to be selected, polished and joined by a human hand.
Also, I don't think the rotation is working quite as indended. Take for illustration the case of skel_100_vol11_11_srf5_5_sym_2_tex10_rot295_1280, skel_100_vol11_11_srf5_5_sym_2_tex6_rot322_1280 and skel_100_vol11_11_srf5_5_sym_2_tex2_rot316_1280 -- I get three pretty much identical povs. They're on different textures which is nice but I'm missing out on you know, actually seeing the model. Rather than generating one random radian and applying that rotation on all three axes, how about you generate three random radians and apply them one to each axis ?
Anyways, I will be meditating on the matter as I'm going through these again the coming days ; it seems to me self-obvious there's a fundamental something needful here, maybe something in the vein of a priviledge vector (if you give a small child any animal, he'll be able to orient them heads-up, because obviously ; whereas our guys are geometrically-neutral, because... also obviously), but as things stand right now I don't have a very clear idea formed.
PS.
<blockquote>Copyright © 2009-2030 for all text and images. </blockquote>
That's a new one lol.
The length of the bone and more precisely the ratio of the bone's length to the original mesh's length. Specifically: all the parts are in fact just *one single mesh* (aka one single 3D shape) - this one gets simply scaled (on all directions) to fit exactly the length of the bone (since the bone anyway doesn't have any dimension other than length). So if a bone is very short compared to the original full length of the mesh, then the resulting part is quite thin and it may appear "strangulated" as you put it.
On a side note since this got back to meshes all of a sudden - I was in fact looking at maybe trying out generating at least a few *types* of meshes as opposed to this single-mesh-for-everything approach. But it's a long road to explore there and I'm not sure if it's burning /first in line given how many other things are to do - arguably and as a barely-formed/fuzzy idea for instance heads would be more reasonable starting with an egg-like shape (rather than a rounded cylinder) and deforming that based on/around some feature points. Not that it wasn't fun to get a proper implicit equation for eggs!
While I can go through all the calculations once again, I would possibly need a fresh pair of eyes/ longer break/someone else to pick up if I messed something up in there. But otherwise and what I tested bit by bit, I'd say that so far I don't see a mistake, no. Since you don't say what perplexes you there/what's unexpected, I can't directly address that but remember that the points are mirrored indeed but that doesn't translate either in directly symmetrical end of bones (because of the collapsing which moves them further about and with some unpredictability) nor in symmetrical bones at all (because of how the points are then paired, greedily from the centre). What is the more specific part/trouble you see in there?
If you want stuff as decor only (ie not moving), then the logical thing would be to transform them into a single-mesh CS thing as it's way cheaper. So kind of hard to say atm how expensive it would be since that transformation should anyway cheapen it considerably (though I'll have to write it, ofc, not like anything useful exists, what). What I can say now, before setting out to instrument some measurement (still not sure it makes a lot of sense at this stage as such) would be that up to the >50/100 I didn't have any need to increase that initial delay for full client launch (which was at 2 seconds) but again, not clear how much of that is the guy itself, how much is anyway needed if he's not moving and moreover whether the factory/instance thing works to save anything or not (ie it might be felt the first time when one loads the factory hence the files from disk but then supposedly the factory is loaded in the engine and subsequent instances should be created faster; should be...)
Hm, texture 4 is that one where I ...threw some trig at it out of no idea in particular, lol. And I can't say it really seemed all that great to me (not even now, hm). The thing with textures though is that the way in which they are mapped to the shape (and the fit between the shape and the original mapping of the texture space itself...) can make a *huge* difference. The surface itself adds to it (via normals, since they control how the colours light up or not) but the mapping is almost more important than the texture itself.
Sure thing. And in any case, the pure Mandelbrot ones (like tex7) are easiest to re-generate at any time (and in any colours, for that matter). Tex 2 was one of those experimenting with stereo texture domain mapping - it may possibly look better on a round(er) mesh for instance but yeah, not that great for parts of creatures. As for 6, I can see it as a sky indeed, though for creatures it always looked to me like an accident with painting pots, lolz. Anyways, will update the texture list, sure.
Ahaha, I can write-up and show off at least some more silly stuff - I've been mainly exploring to get a better grip on how each bit/thing influences there the result since it's a sort of painting-with-numbers and I have ~0 experience with it (and yeah, the only time I was any good at drawing was when I worked on it way more than for any Maths or CS or any of the "difficult subjects"; though in fairness there is some theory still coming in handy from back then).
Yes, it's an effect of the "fit mesh to bone length", really. The only (rarer) times when it seems as if it's "underskin" is at some long-short bone meetings (when the volume of the bigger mesh may therefore happen to cover also part of the joint perhaps). The possible "cure" for this would be to either relax the fit so that the mesh overhangs the bone rather than strictly fitting it or otherwise... overhaul the approach entirely and dunno, start with a full 1 unit sphere, pick the points and then erode it or something (HA, wouldn't THAT be a way to reset the work and sink tons more time into it!)
What do you mean there? Automatically so far I can't tell head from tail anyway, lol. Other than that, they are all "parts" anyway so one can always pick whatever is desired (only trouble being when it ends up manual picking, ofc). I can't quite tell which of skel88 you mean either as I tried a few and I can't quite see the tails you mean.
Ahaha, should I search that comment where I was saying I expected this? Lolz. But yeah, not a big issue really, I'll just pass 3 parameters to the client instead of 1, now it's all set otherwise.
Myeah, I kept going through them and having this itch of "wtf is missing in there" but I can't say I have any idea that crystallised on the matter (and given how much *new* stuff I kept gobbling up this past month (or more, huh), there has hardly been any space & time for much crystallising. The only thing coming to mind would be the proportions of the human body that could perhaps be useful to split the sphere in bands with different amounts of points or similar (volume vs surface is ~roughly body vs limbs, but on a circumscribed human figure, there's also clearly some different density of points closer to the centre of the sphere than to the outside; perhaps even on bands on the y axis; maybe some ...more biased prng selection or something).
The copyright notice used to be in the older theme!
Here's the margin of a hole, I think, because weren't you saying the bones have no length, being just points ? Did I misunderstand ?
I think it should start with the following single step : explain to me how they'd be different from one another ?
Possibly. The only problem being that I don't feel like reading code right now, and nobody else exists, "everyone" being a bunch of completely retarded & entirely useless fuckheads such as'd make, at best, reasonable onions to go into a salad or something, but in no case may touch anything with blinkenlichten on it. In any case not my blinkenlicthen, not ever again.
It's not necessarily possible to state both simply and correctly ; but taking a bender on literal correctness for the sake of right-now simplicity : if indeed there's some geometrical relation between the points on the sphere as we're discussing and the bones actually visible in the end product (for instance as rendered visible by the strangulations discussed above) -- a point itself not yet resolved in my head -- then why is it not the case there's any visible symmetry of these later ?
In the end, I don't understand what I'm seeing just yet.
Intuitively it should not be possible for this to be the case, for a reason much to do with why exactly you can't really use PRNGs to produce truly random numbers. Are you proposing that we've found an arithmetic manner to generate entropy and therefore henceforth von N. is the one living in a state of sin ?
As part and parcel of a general programme of getting Diana a few days off the bashing of bones, only available avenue in the triplet you proposed above, how about you do this ? We'll need it anyways, not like it's possible it be lost work ; and it'll be something somewhat else for a change.
I'm with you, I don't think this is an item whose time has come yet. We will definitely need it eventually, as good quality measures from here will be a key metric in the eventual decision of which hopefuls make it in etc, so it is on the list of definitely-will-be-done ; but indeed it's not yet time for it, not least of all because we don't yet actually have a good view of all the kinds of things we'll want to measure.
Do more of this ; in fact, take a family holiday some convenient day, bake some cupcakes or something, sit everyone in a circle and just throw stuff at it for the lulz of it, like other people play charades or monopoly or whatever group activity like that. Whoever picked the three prettiest gets a cupcake or something. I know I'm having lots of family fun with the whole thing ; it probably should be spread.
This I've rather noticed myself, indeed ; but it's in the pile of "wtf is this crashed delivery van of disparatcy ; and how would I ever hope to wrap head around it" currently. What can we do, we're only superhuman over here -- and superhumancy, like infinitcy, comes in degrees. And since we're on it, I propose we call it the ghayn number, as opposite of the aleph number -- because what could truly be more opposite ?
Aren't you glad a little bit of actual human attention made computer graphics breathable again, and interesting again, and something actual people can take an interest in, that'll be satisfying in that darkly complex manner things are satisfying to actual people ? Because I definitely am ; who knew the skin of stupid covering this particular humongous rock was quite so thin, a mere membrane (disgusting, indeed, but so readily pierced...). If all pantsuit grime washes this easily...
To me this has by far been the greatest result of all this effort.
Let's try something out here, with no expectation it'll do anything. First, divide the bones into three groups : 1) which contains all bones that have no neighbour closer than 1/3 of the average distance between bones ; 2) which contains all bones that have no neighbour closer than the average distance between the bones ; 3) which contains all bones not in 1 or 2. Then change the fitting rule, such that if the bone's category 3, the mesh is fit as it is fit currently ; if the bone is category 2, the mesh is fit to the length of the average distance among the set of bones that are its closest neighbours (where "closest" is defined as "no further away than 1/3 of the average distance between bones) ; if the bone is category 3, the mesh is fit to the length of the largest distance among the set of bones that are its closest neighbours. Then regenerate the hopeful pile, with the following count params : 31/31 ; 47/23 ; 23/47 ; 167/167 ; 127/31 ; 31/127 ; 431/431 ; 263/503 ; 503/263 ; 983/983 ; 719/1319 ; 1319 / 719.
Amusingly enough, I was parsing the comment ; meaning the above came before I ran into your parens. I think we may well have something here.
No fucking way.
Ah no, not automatically, what I was thinking was someone as in, an actual model artist, could just load up the model, cut out that pre-made part, and affix it to some other thing that was otherwise pre-made, by hand, by himself. Sorta give artists a large vat of parts and let them just copy/paste them into place (as it seems that's really the only utility possibly remaining in the subhuman biomass still left standing post-cataclysm). It was just a stray through, that ran aground almost immediately on the jagged shores of "wouldn't that require you also equip them with a model editor, which isn't something that really exists" and such. Later, we deal with this later.
:p
What am I gonna do, not pick the fruit ?
Ok, but I mean how did you pick the year 2030 ? (And, for the lulz of they reading along, how did I pick the arbitrary things I picked in this comment ?)
Neways, this 1`400 word novelette now coming to an end, we wish the reader a great time, and so following.
It's the cal3d/cs/ps "bones" that have no length, basically they are misusing the term for no good reason. Nevertheless, their misuse and so on gave me a lot of headache when translating stuff to the format required so the client can use it but other than that ...it doesn't matter really, nor do I see why it should matter. So, to keep it simple: there's "cal3d bone" (that is in fact just a point) and there's bone (aka used for generating the hopefuls) which consists in 2 points and therefore has length (though no other dimension so far). It's even worth noting that a bone will be at the end of the day whatever we want it to be, really - so far I gave it length mainly because I needed to set *somehow* the meshes in place. But if some other characteristic makes sense, we'll add it since it's anyway my scripts that do all the work really - once that is done, the result will simply be translated to the format cal3d/cs/ps can use and that's that. Let me know if this is still not that clear though.
This kind of triggers a whole article, to answer. I'll think of it a bit more to see if I can pack it any tighter - if not, I'll write the article since I have already started on it basically.
To my eye there is *some* visible symmetry. The trouble is that it's not... overpowering or how to put it more clearly. And hm, it kind of ties up even with the answer-article to the previous question so I start thinking I will have to write that anyway.
No, I don't think this is the case. I think it's simply that the sequence we use is *too short* for the prng (as opposed to trng) to matter.
Apparently I have/had to get off all of it at least for today - there's a point where a break is long overdue and today at least it's that break (I slept from ~11pm yesterday to ~9am today and then I still couldn't stomach any more new stuff on this for today; it's pondering, taking a break, doing-something-else-entirely time for now). There's still quite a pile of stuff waiting for me to get it done anyway, so this can get added there and it will have to wait its turn. While I agree that it will probably be needed anyway, I'm not yet 100% sure of the final shape it will have to take, hence my slight hesitation in getting it done first. But I'll give it a closer think at any rate and see if there's at least some part that is fixed enough so it can be done now without any loss, perhaps using the fixed formats, for all the yuck factor of looking at them again.
Heh, so far I got the child quite interested in it all, for sure. It's still though a bit over his head in terms of what he even has any idea about, to even throw at it, but yeah, I can see it working as a game, why not.
I'd say it's possibly because as late as the (early) '80s, the group around Mandelbrot still worked on this in fact in the right direction. Basically ~all the useful reading I could find on the matter comes really from even earlier than that (e.g. Blum's medial axis) or otherwise the fractal and chaos theory work that aimed clearly and purposefully to enable people to explore what computers made possible - pretty much what we are doing here, I should say. But then it seems that this direction got dropped/overlooked/swamped by the easy-crowd or I don't even know what/why/how abandoned. And even reading the older vs newer editions of the *same* authors kind of gets me sad, because there's a subtle but obvious shift towards accommodating and making it "more intuitive" instead of aiming to develop the required "intuition". I'm still mulling all sorts around this whole thing.
All right, I'll add it to the to-do list.
Myeah. In principle it wouldn't be all that difficult since it's just a matter of saying "I want bone x, bone y, and bone z". That being said, I admit that currently I would actively resent doing some work *just to facilitate* the pick and choose of whatever "model artist".
Heh, I literally picked it as it came to me. For once, I did exactly that and nothing more.
Looking forward to said article(s)!
"Model artist" whatever, it'd be Hannah or something, not like I'm contemplating letting the simps in again wth.
But anyways, I'm not fixing fucking blender, so this doesn't have any legs anyways.
Ah, that makes sense. And good god, no blender ever again, no! What I had in mind though was possibly less than what you were thinking though (since you mentioned blender) - simply allowing to pick, group & tag sets of meshes so that there are then "tails", "heads", "trunks", "noses", whatevers and then putting them together *automatically* mix-and-match. Basically allowing an intermediate manual step to choose role for bits and pieces, if that's at all desired/useful/needed.
Still, I'd say it's in the best case too early for anything like this.
Possibly that'd be the better way to go about it ; we revisit this whenever.
As I went through this in more detail to extract the spec exactly for implementation, I realised that it's all muddled in that confusion points/bones I think. So specifically, to clarify this:
1. By "average distance between bones" do you mean a. average length of bones (hence: distance between paired-points so not just all possible pairs) or b. average distance between points (hence: between all possible pairs of points)
2. By "no neighbour closer than" do you mean no connected bone with length longer than 1.a (or 1.b) ?
3. What is the distance you have in mind between bones? Minimum distance between two points on the bone-segments?
4. At fitting, is that meant to read ~if category 1 (not 3) then fit as currently, if 2 then fit to average length among its neighbours, if 3 then fit to largest of its neighbours?
Note that ALL bones are *connected* to one another, there is by design no disconnected bone at all. Literally each bone *shares* one end with at least one other bone. (And bones are segments of line, hence have length and 2 ends).
Let's do one of those old Gheba-style back-of-book terseness of glory. Man I miss it! So : 1-b;2-aaaad, this is how far it went.
2. No, I mean that no bone-as-a-point (as opposed to bone-as-a-length) is to be found within a sphere centered on the bone-point in question and with radius equal to the "closer than" parameter.
3. Geometric distance between the bone-points, I thought that's what these were, points. Aren't they ?
4. No ? I mean 1 (and not 3) be fit as currently ; but I do mean the category selection to be exclusive and processed in that order, meaning that once a bone is put in cat-1, it is not available to figure in cat-2 anymore. So first cat-1 takes its pick, then 2 picks from the remainder, then 3 picks all that's left.
> Note that ALL bones are *connected* to one another, there is by design no disconnected bone at all.
Certainly, but not all bones are connected to each other. In fact (especially in larger bonecount generations) the links are relatively sparse in a mathematical sense.
Ha, at some point I got that Gheba scanned and sent to print some pages of it and cure a few guys of avoiding fractions on top of fractions on top of more fractions. The initial horror look they gave it was quite fun, too.
Getting back to the thing at hand: please, can we stick to points = points and bones = already matched pairs of points (hence with lengths)? It would make it all way clearer. (And again: my generator works with bones that are segments of lines; the mess of cal3d was the "point=bone" and no, it's not helping to use their thing because then it's all a mess: if you consider now each point a bone then what length and moreover - which fucking direction should the mesh be fitted on? to which of the connected other points etc? It just makes it all a horrible mixup and a way to not get anywhere really; it was enough of a mess to have to do the format conversion, I really don't want to *also* import that broken thing into everything.)
3. No, bones are segments of line. (Cal3d has other ideas indeed but it does nothing with them so it's no use and no help).
> please, can we stick to points = points and bones = already matched pairs of points
This is actually a good idea, will try my best!
Still trying to make sure I fully follow your idea there, as I really don't get it why link the mesh fitting back to distance between *points* that might meanwhile end up *not connected*? Wouldn't it make more sense to choose the mesh fitting style based on the relative lengths of connected bones instead?
Anyway, here's what I understand of your request as it stands and where I'm not sure what you mean:
1. - divide the *points* into 3 groups, assigning in order: G1 for all points that have no neighbour closer than 1/3 of average distance between points; G2 for all points that have no neighbour closer than average distance between points; G3 any remaining points.
2. - pair the points for bones as previously; NB: each bone will therefore have 2 points and those points may easily be in different groups.
3. - at mesh fitting time, how does the *bone* end up in one group or another since its ends *can* be in different groups?
4. - at mesh fitting time for groups 2 and 3: is the average/largest length based on distances between neighbouring points (hence, those that might *not* be directly connected to this one anyway)? Or based on lengths of connected bones (ie only those neighbours that are actually connected to this bone, on either end)?
Because whether they're connected or not, they're still geometrically close. Your chin and your clavicle are not (directly) connected, but the folding of skin on your neck is decided by their proximity and not by their connecivity.
3. - this is a very good question, seeing how obviously the meshing will be done per-bone in practice, even though a philosophical pov'd be more interested in handling jointures separately.
There are two directly obvious ways to proceed. The simple one is to say that any bone is in such a category as its lowest point, so a 1-2 bone is in 1, a 2-3 bone is in 2 and a 3-1 bone is in 1. The complex one is to produce both meshes for the bone, as per each endpoint, and then mesh them in the middle. How feasible is this ? (Basically, make both meshes, cut each in half, declare a margin where they're supposed to join and fractalnoise them together ?)
4 - yes, neighbouring points, irrespectively how connected.
Mhm, I had an inkling that you were going for that idea of "geometrically close" - the main reason I didn't go for it is twofold: first, if they are indeed all that close to influence folds and whatnots, I'd rather expect the joints will anyway end up themselves overlapping to some degree and therefore influencing naturally what is rendered as "fold"; second, it forces this new parameter "what does close mean" and I'm SO weary of additional parameters (this might be irrelevant though, indeed).
Anyway, alright, points-based it shall be then.
In short, with the current polygonizer, not very feasible. In long, as it's worth considering more here:
It seems to me that the philosophical "handling jointures separately" + the above would really mean essentially "ditch the silly simplification of actually fitting meshes on bones and consider instead all articulations as some feature points + fractal noise your way around them, possibly varying the amount of noise depending on distance to closest articulation/other similar measure". Essentially growing the creature as a whole based on the skeleton as a whole - which certainly makes way more sense I'd think than trying to do it piece-wise as if each part was in isolation. The trouble with it was never one of not-making-sense but one of how many mountains to move and right from the start too. It's certainly not impossible - the core problem that I'll have to solve then is basically to implement in the end my polygonizer too, pretty much (maybe some of the current one/the experience with it can help, sure). That's how it tends to always go anyway - whatever simplification is made, it won't last if one wants a better result, certainly.
I suppose the above is possibly closer to what you had in mind at the very start anyway - and which ran into the practical trouble of creating the corresponding surface as a closed one and meshed as per cs/cal3d requirements given that I also had no idea of anything in there to start with.
The above aside, currently *any* part that breaks the existing surface (e.g. that cut & recreate) runs into the limitation of meshing & polygonizing (or agonizing, it's more fitting). If however this sort of thing will end up a must-have anyway in whatever number of steps from now, there's no point in sinking more work into trying to avoid it, since it will just be that, more work sunk - might as well proceed to do own polygonizer script too, I suppose, for all the horror of it. At least I still know obviously more about it now than I did a month ago, there is that.
For completeness, I guess I should mention that some possible middle-place approach there might be to basically interpolate the scaling factor of the mesh between the 2 ends - not quite sure how the result will end up looking, but it's kind of closest to "might have different fitting-requirements at each end" while not breaking the surface as such. The main trouble with it is that it might still end up creating invalid triangles and therefore have cs/cal3d throw up on the end result.
Let's not go that far just yet. For now, let's do a gen5 as updated in the other comment.
I don't know yet that it will. Let's go with the simple option for now, and think of this more later. In principle it seems like meshes-meshing would be a great shiny tool to have, "offering so much potential" ; I'm not nixing it but also not putting the effort in just yet.
Something like this was my original idea, yes, and still possibly an intermediate step, yes.
Alright, I'll get to implementing that then and see.
It turns out there *was* an error that affects the sym2 hopefuls in this parade and only them.
Ha!
This is still giving me a headache and I suspect it's because of the negative formulation ("those having no.."). Specifically: all points that have no neighbour within 1/3 average distance are in G1 (as G1 takes first pick) is fine but then what is G2 meant to be since those NOT picked will therefore HAVE a neighbour within 1/3 average distance and so it's not possible they also do NOT have a neighbour within average distance. There's something I just don't get here.
To turn this into the positive statement for clarity and to make sure I'm implementing here what you have in mind, here's my current algorithm:
1. calculate average distance between all points: avgd
2. calculate for each point the distance to its nearest neighbour, mind[i] (hence, the minimum distance from point i to any other point; or otherwise put: how close IS the closest neighbour; basically point i will have no neighbour within less than mind[i], whatever that is)
3. trying to go for what I think the idea was:
if mind[i] less than 1/3 avgd G3 (aka: points that HAVE a neighbour within 1/3 of average distance are in G3 and it's really this one getting to pick first)
else if mind[i] less than avgd G1 (aka: points that do NOT have a neighbour within 1/3 of average distance BUT have one within average distance are in G1)
else G2 (aka: points that have all neighbours further away than the average distance)
Is the above correct?
They warn you in school about negative formulations, I suppose this is precisely why.
Let's work it with examples. Given points a, b, c, d, e, f, g at distances 1, 2, 5, 7, 8, 11, 22, we then :
1. compute the average of these 7 distances, coming with 8.
2. As 1/3 of 8 is two-something, a and b are in G1, but c and the rest are not.
3. As 8 is within 8, c, d, and e will be in G2 ; leaving
4. f and g in G3.
So our split becomes (a, b), (c, d, e), (f, g), that make sense ?
Ah sorry, should have read your whole comment first.
Good.
Good.
No, it isn't.
First, calculate avg = sum(mind[i])/i.
Then, iterate over the points, and if mind[i] > 1/3 avg, put that bone in G1.
Then, iterate over the remaining points (ie, of bones not already put in G1) and if mind[i] > avg, put that bone in G2.
What's left is in G3.
(This includes refinement from the other discussion re bones, making a bone go with its earliest point)
Uhm, an average of an average? Let me see if I figure this out because the more it goes, the less I seem to get it: once I got for each point the distance to their closest neighbour, the next step is to calculate then the average *closest* distance overall (as opposed to the first average distance). So a sort of "on average, a point has its closest neighbour at 0.212 or whatever that is". Assuming this far I'm following, it gets then still stuck exactly the same way as above, because:
The points with closest neighbour further away than 1/3 of average-closest-neighbour are in G1 ...and then those that are NOT picked at this step, have therefore and as a consequence that mind[i] LESS than 1/3 avg so how can they then have it also > avg? If it is NOT greater than 1/3 (hence not picked into G1), then it can't possibly be greater than 1 or what am I just not getting there?
Also, trying to move this further, I realised that the fitting is unclear too but surely I need to understand the groups before I can even hope to understand the fittings.
And I saw the other comment only now and from the example it would seem you mean *less than 1/3* rather than > 1/3 ie they HAVE a neighbour rather than don't have a neighbour ?? And those distances assigned one per point are the mind from my earlier code ie the distance to closest neighbour.
So then: G1 would be the group of points with closest neighbour at less than 1/3avg, G2 at less than avg but more than 1/3 avg and G3 at more than avg. Which makes at least sense but it seems entirely the opposite of the "do NOT have a neighbour within..."
Re fittings: for the case when the actual bone length is different than the length to which the mesh should fit - where should the actual bone be positioned? Ie in the middle? (and what if the bone is shorter...)
Jesus we got this completely confounded, and seemingly for no good reason.
No, no, it's just the average distance as originally calculated.
I think I understand the actual problem ; the original formulation was possibly over-terse. Does this restatement fix the misunderstanding ?
Ultimately, a more computer-ready, programming-style rule'd have been very advisable on my part, in lieu of the very legal-style thing I attempted. So how about, "if mind[i] < 1/3 avg, g3 ; else if mind[i] < avg, g2, else g1" ?
And since we're here, let's also correct a typo in the original text,
,
Apparently the box eats <del> tags ; the first 3 above was intended to be struck through.
This is easily the weakest part of the entire proposal, owing to my poor understanding of meshes and fittings.
It is my (perhaps naive) expectation that due to the relative density of points being processed no open figures would be produced through this mechanism (basically, the meshes of other points would overlap any problems such as a whole, rather than partial final object be produced). Is this even how anything works ? Is this something your polygonizer can even deal with ?
Most importantly : can your polygonizer be upgraded such that it auto-closes (preferably on a "smallest area" criterion) ?
We did get it all muddled up - if one follows the statements through, they don't fit with one another really, I don't see it.
This is very close to what I was proposing earlier (here: http://ossasepia.com/2020/05/08/an-abundance-of-bones-4th-parade-of-hopefuls/#comment-8438) based on what I understood and it means effectively: G3 is group of points that have closest neighbour within 1/3avg; G2 is group of points that have closest neighbour between 1/3avg and avg; G1 is group of points that have closest neighbour further away than avg. So it seems to flip G1 and G2 from original formulation, if I get that right, but I am fine to go with this if you say it is what you meant. (Otherwise, the updated formulation would fit the pseudocode I gave earlier and you said that was incorrect.)
Would you confirm then the fittings ie with those G1, G2, G3 as above? Is G1 fit to bone length as currently, G2 fit to average distance between closest neighbours (where supposedly closest here means between 1/3avg and avg) and G3 fit to largest distance between closest neighbours (where closest neighbours here means within 1/3avg)?
As previously discussed, each bone will be assigned to the lowest of its ends (ie G1 if at least one end in G1; failing that, G2 if at least one end in G2; failing that, G3). And then the "closest neighbours" when calculating fitting length would consider together the neighbours of both ends, I assume.
Uhm, the confusion seems to be deep there and I'm even at a loss where to start from. The core bit that apparently still managed to not be clear: the polygonizer does *not* work with the *full* thing, there is no full thing as one joined-up entity as such, the cal3d model *by their format* is a puzzle of pieces where each piece is on its own and hence closed or not-closed. So there is no automated meshing together of any sort - what *can* happen indeed is that several meshes will overlap and therefore the *engine* (nothing to do with the polygonizer) will end up picking one surface on top of another in some parts - but the crucial thing here is that this overlap is *not* going to mix them in any way ie just because they end up overlapping, it does not mean that they *join*. And in turn, I rather expect that this will end up in weird effects at best when the thing moves. Just to be clear: the existing models (e.g. Cally or Foxy) are made still from separate parts that simply *fit* one another at the joints, very closely, that is all, se imbuca una in alta, cum sa-i zic mai bine.
Basically, to reiterate, the polygonizer does *not* come into play in the thing as a whole, at least not unless we do what I was saying earlier ie "ditch the silly simplification of building it mesh by mesh and grow it as a whole instead". On the other hand, the trouble with going for "it's all just one mesh" will possibly be at animation time since then .... can't define movements for different parts, there's just one single bone too so ugh again. In any case, the polygonizer makes one single *mesh* as a puzzle piece, not the whole thing, nor is the whole thing ever changing in any way the parts - those stay as they are once made, nothing changes. The "whole" as you get to see it is just literally made putting piece *next to* piece but *never* mixing them together nor ever considering them as a whole in a any meaningful way (other than perhaps as a sort of grouping of stuff).
Currently the polygonizer has no idea even *if* its output is closed or not - this is left entirely up to the poor soul defining the surface and/or setting the parameters (ie tweaking them so that the process keeps going until the surface is closed).
Going for "auto-close" is probably going to be a matter of either surface definition taking this on itself (hm, no clear idea how would I even quite enforce that), or otherwise outside script adding vertices or something but the trouble is that the result is likely to look stitched up no matter what (or I end up building another polygonizer, pretty much). I'll think of this some more but if really what you are trying to do is to fit the gaps between pieces, then the question raised is why pieces in the first place. Their idea was that by having pieces, one can move each of them independently and one can change them too ie each Cal3d model has a set of "core" pieces and then potentially any number of other pieces that can be used instead (so a core head and 100 alternative heads to put on depending on occasion).
Ok, well, this excursion exhausts my available resources to deal with it. Therefore, forget about it. I thought I had a decent idea of how to resolve the visual problem of strangulation perceived in g4, but it doesn't seem like it's something that can in practice be done.
Proceed with g5 without this part, and we'll take it from there.
Ok.
Timing tests with the updated orchestra currently show a bottleneck at collapsing points time, slowing the generation down for combinations that have more than 700 starting points (meaning 4*700=2800 points for collapsing to start with). This is mainly because my collapsing is picking at every step the pair of points with minimum distance rather than the easier option of picking first pair with distance less than average. I ran both options and the difference is striking - picking just any pair ends up in "sparser" models so I don't think it's ideal. Consequently, I'll try first to separate instead the skeleton generation so that I can keep the more costly but better collapsing version and just generate the skeletons in parallel if needed so the whole thing doesn't need to take days on end.
I expect to have the above done by tomorrow the latest so I'll then be able to update you on the expected delivery date for the full Gen5 too.
After delivering Gen5, I'll aim to publish and illustrate some of the mesh generation part as well.
Works.
It turns out that the current combinations of points (esp. those above 800 hence 4*800 starting points) require some significant time to generate. Specifically, as the full generator is now neatly separated into the different stages so I can run them on different machines and time them separately too:
1. meshes generation: negligible time, it takes less than 1 second in total (for now it's only 2 meshes, aka 1 cylinder-based and 1 egg-based).
2. skeletons generation - there is a huge difference here depending on whether the collapsing stage picks each time the pair of points at minimum distance or whatever pair of points it finds first within less than average distance; this difference increases quickly for large number of points since that's the whole trouble, of course - as one pair is collapsed, there are a whole lot of distances to recalculate if one has otherwise many points; to get an idea: using minimum distance, 431/431 takes 1.5 hours, while using first pair within less than average distance is done in 30 seconds. It might perhaps be interesting to see the resulting hopefuls from *both* options at least for some seeds - I'd rather suspect that the more points there are, the *less* difference this choice makes, as they are anyway all crowded together, but currently I don't have a clear formula as to the best cutting point for switching from min to first based on geometrical considerations (otherwise, based on timings, the cutting point seems to be ~800 points total volume+surface to start with, but I didn't really try to narrow that down).
Timings here for the full set of 12 combinations and just ONE single seed: the "quick" version takes ~20 minutes; the "slow" version (min distance) seems set to take ~1.5 days (with more than half of that time spent on the heavy combos: 983/983, 719/1319, 1319/719).
3. models generation: a set of 24 models (ONE seed * 12 point combos * 2 symmetry options) takes ~12 minutes .
4. rendering: a set of 24 models and the current 22 textures (hence, 24*22=528 resulting screenshots) takes ~1 hours to render (this is optimised already, as the delay to wait for the client to finish rendering a model is calculated based on number of meshes in the model so that it adjusts across the different combinations). Hence, 50 seeds means 50 hours and I'm therefore looking at 2 days for rendering only (I can't even speed this up atm as I made this station with all the graphics bells and whistles specifically for client work as it is - the rest don't have the same graphics capabilities).
Given the above - how many seeds do you want used for Gen5? Do you want to see the results of both collapsing options?
For now and still aiming for the full 50 seeds set, all combos, all textures and so on, the "quick" option seems set to be ready for publishing by next Wednesday the latest. The "slow" option is iffier and possibly really better done on fewer seeds. Fwiw, the screenshots don't say much re client's capability but trying to move around one of the models generated with 983/983 was horrible - clearly not a working thing in game atm (and yes, slowing the movement down *just* for being in view; the thing had about 3k meshes but the count that matters is really faces so in this case approx 3k*1k faces as each of the meshes has about 1k triangles).
I'm willing to go with 50 seeds = 50 hours, ie run the thing for a coupla days and do something else while the earth moving machinery... moves earth. Isn't it nice, incidentally, to have the computers put in their place ? Ca doara-s tractoare...
This is a one-off thing, we'll be back to either more limited point counts or with needed improvement depending on how the end result looks, ie whether it looks like there's anything there to explore or just stone wall.
> Do you want to see the results of both collapsing options?
Sure.
Does this mean runtime specifically takes that long and I misunderstand something ? I mean, today's Thurs, there's 6 days till next Wed.
Indeed, quite the pleasure to sit in the sun and just check from time to time on the churning computers! Talking of which, I realised they are not even used to the maximum really, so I shall see to that - since otherwise the "slow" min-distance full run is taking too much for my liking, heh.
No, not runtime but actual "latest publication day" ie it includes some buffer (as things *may* go wrong at some point, who knows which of them churning tractors keels over right in the middle of this or something) and some time for the packaging of the whole pile (and it will be quite the pile!), writing up etc.
Anyways, I'll set then to do both (min distance and first pair) and will certainly publish as soon as they are ready.
Alrighty, this works.
[...] the previous parade of hopefuls is essentially still ongoing, I focused for a bit on painting with numbers, functions and scripts [...]
[...] I can ~never be absolutely certain the implementation is a bug-free translation of the spec, I can certainly check again and check better and take a break from that code before checking then [...]
[...] http://ossasepia.com/2020/05/08/an-abundance-of-bones-4th-parade-of-hopefuls/ << Ossa Sepia -- An Abundance of Bones: 4th Parade of Hopefuls [...]