| feedbot: | http://ossasepia.com/2020/03/04/no-bones-in-thy-skeleton-and-no-theory-in-thy-research/ << Ossa Sepia -- No Bones in Thy Skeleton and No Theory in Thy Research | [12:20] |
| diana_coman: | mp_en_viaje: ^ the promised write-up | [12:22] |
| ossabot: | Logged on 2020-03-03 19:13:47 diana_coman: I have ~3k words trying to set down the work of those past 2 weeks and I'm still not done; and it's anyway a set down out of necessity (aka it needed the structuring) rather than out of having arrived at a can-stop-here point, sigh; anyways, I should be able to finish and publish the write-up tomorrow. | [12:22] |
| mp_en_viaje: | i just finished mine, so thus i can now proceed... to yours | [12:23] |
| diana_coman: | ah, new trilema read? /me goes to read then | [12:24] |
| mp_en_viaje: | diana_coman, noy so fast lol. so basically, "bones" should really more straightforwardly be called pinch points ? | [12:32] |
| diana_coman: | mp_en_viaje: it's a mess - basically it depends on *which ones*/where you mean; in cal3d's format they are pretty much pinch points, yes; in theory and in modelling tools (such as Blender) you get proper bones with length and thickness and all that, precisely because those things DO matter for figuring out which vertices are affected | [12:34] |
| diana_coman: | not even pinch points really; just...points, lol | [12:35] |
| mp_en_viaje: | so basically there's a half-compiled sitution because in geometrical truth the only thing they can be is pinch points ; but in an intuitive sense they'd better be somewhat more like the layman's notion of a bone in the ghuman skeleton | [12:35] |
| diana_coman: | it's not that the attached mesh gets pinched there | [12:35] |
| mp_en_viaje: | diana_coman, but that if it DOES get pinched, it will have to be there | [12:36] |
| diana_coman: | hmmm, in practice, annoyingly and infuriatingly and insanely - not even that; you can have those points ANYWHERE and they can "influence" ANY vertices ANYWHERE | [12:36] |
| diana_coman: | for all the logic that makes | [12:36] |
| mp_en_viaje: | i confess that all is not so much | [12:36] |
| diana_coman: | welcome to my love of CG! | [12:37] |
| mp_en_viaje: | let's work at this through the immediate example. | [12:37] |
| diana_coman: | is listening | [12:38] |
| mp_en_viaje: | unwind with me the history of mathematics, and let's be again in the days of lagrange. the problem of modelling a rope under load informs all this, yes ? the "bones" aka "pinch points" are the discrete portions of the rope (or length of chain), and in ~this~ sense any one can influence any one ? | [12:38] |
| mp_en_viaje: | ie, mediatedly through the nearest one ? | [12:38] |
| mp_en_viaje: | this might explain at least why they tend to count so ungodly uselessly many, anyways. | [12:39] |
| diana_coman: | hm, I would *hope* that indeed that is what informs all this (though evidence that there is something exactly informing is rather ..sparse); and yes, the theory as far as I can see it seems to be that indeed. | [12:39] |
| mp_en_viaje: | alright, this is pretty fucking stupid, not to mention century+ out of date | [12:40] |
| mp_en_viaje: | what you get when you teach people the alphabet only, they'll "read" their "own" vulgate into the bible. | [12:40] |
| diana_coman: | well, honestly, they probably don't mean that specifically; there's nothing all that clear at any point; it's more a matter of "this seems to fit/work well enough and it's intuitive!!" | [12:40] |
| mp_en_viaje: | rediscover half of everything, make a tower of it... | [12:40] |
| diana_coman: | sure, there are some approaches that go further and consider also a layer of muscle between those bones and the mesh etc | [12:40] |
| mp_en_viaje: | how are the points given ? like if there's a bone (1, 1, 1) and a bone (3, 0, 0) and a bone (0, 2, 1) then the model's implicitly a rectangle 3x2x1 units ? | [12:41] |
| mp_en_viaje: | well, a parallelipiped, whatever. | [12:42] |
| diana_coman: | mp_en_viaje: heh, why u so logical; the first insanity is that the skeleton has nothing to do with the model at any other time than strictly animation-time | [12:42] |
| mp_en_viaje: | but i mean, how are these "bones" defined ? not by absolute position ? what are they then ? | [12:43] |
| diana_coman: | the bones are defined by relative position to their parent bone; ie it's a tree with a root bone | [12:43] |
| diana_coman: | it's that root bone (the one without a parent) whose position is considered the origin of the model | [12:43] |
| diana_coman: | so if the root is at 10,10,10 then the model's space is supposedly with origin at 10,10,10 | [12:44] |
| mp_en_viaje: | so polar rather than cartesian, 1st bone is always 0, 0, 0 and the 2nd being 1, 1, 1 and the third being 1, 1, 1 makes the third absolutely 2, 2, 2 away from wherever the first is ? | [12:44] |
| mp_en_viaje: | or are they aCTUALLY given in steres and distances ? | [12:44] |
| mp_en_viaje: | steradians* | [12:45] |
| diana_coman: | they are actually given as relative transformations so translation (3d vector, x,y,z) from parent bone and relative rotation (quaternion from parent bone) | [12:45] |
| mp_en_viaje: | aha | [12:45] |
| mp_en_viaje: | so it then can be said that indeed each bone is the length (of unclear thickness) from its parent to "itself". ie, bones are only defined as the point of their ending | [12:46] |
| mp_en_viaje: | on the implication that all bones off this bone START where it ends. | [12:46] |
| diana_coman: | on top of that, each bone further stores the translation+rotation to bring a vertex to the bone's own local space; so basically the inverse transformation for the cumulative transformations from the root to that bone | [12:46] |
| mp_en_viaje: | this actually makes perfect sense to me. | [12:47] |
| diana_coman: | I guess you can see it that way, yes; but there's no thickness then anyway | [12:47] |
| mp_en_viaje: | it's not clear why thickness is wanted. | [12:47] |
| mp_en_viaje: | but yes, abstract 0-thickness bone seems to be the case | [12:48] |
| diana_coman: | because it normally matters if you really go for a biological model, doesn't it? position of bone inside the volume of flesh and the bone's thickness also matter with respect to what the movement looks like | [12:48] |
| mp_en_viaje: | yes, but you see, i'm sure there's a parametric distance somewhere, saying how close to the abstract bone the texture should pack | [12:49] |
| mp_en_viaje: | so yes, you can't really have eccentric bones, but then again... something you gotta give | [12:49] |
| diana_coman: | mp_en_viaje: the format itself makes sense as above; it's not as much as it doesn't make *any* sense, it's simply that it's geared towards using the results of something already generated and fully "produced" aka it's not the generation that is coded but the most detailed (as in as much detail as needed) result | [12:50] |
| mp_en_viaje: | why do you say so ? | [12:50] |
| diana_coman: | heh, that sort of thing "a parametric distance" is at most in ...blender | [12:50] |
| mp_en_viaje: | what does prevent you from wrapping a mandelbrot over an arbitrary bone tree, for shits and giggles ? | [12:51] |
| diana_coman: | the most obvious example I'd say is the actual "which vertices does this bone influence" | [12:51] |
| diana_coman: | the "which vertices" is in the mesh file where each vertex has attached the list of bones that affect it and the "influence" as a \% | [12:52] |
| diana_coman: | so there's nowhere the function that calculates "what vertices are affected if this mesh is attached to that bone" | [12:53] |
| diana_coman: | it's already the result of such a calculation (whatever that may be) | [12:53] |
| mp_en_viaje: | hm | [12:54] |
| diana_coman: | re wrapping mandelbrot or anything else - I need to do the actual wrapping and then spit out the coordinates, vertices, faces, influences, whatever comes out of it. | [12:55] |
| mp_en_viaje: | so use something simple, like a law of halves. closest does 1, the next 1/2 and so on | [12:55] |
| diana_coman: | sure, I'm not saying it can't be done or anything; I'm just saying it's something I'll need to figure out in some way, wherever I'm starting from; it's an open field, can do whatevers. | [12:55] |
| mp_en_viaje: | aha | [12:57] |
| mp_en_viaje: | well, i think this'd be worth trying out. | [12:57] |
| diana_coman: | mp_en_viaje: what specifically? at this stage I can think of ~anything worth trying precisely because there's not much in the way; nevertheless, all tries take time and some effort, ofc. | [12:58] |
| mp_en_viaje: | take a fractal to be your texture ; take an arbitrary graph, to be your skeleton ; take some paramatric manner (such as, say, fibonnaci might inspire) to do the dampening. produce the object and diplsy it. | [13:00] |
| mp_en_viaje: | display* | [13:00] |
| diana_coman: | mp_en_viaje: and the geometry? | [13:00] |
| mp_en_viaje: | isn't the geometry implicit in the bone and the bone-texture relation ? | [13:01] |
| mp_en_viaje: | isn't the geometry implicit in the bone structure and the bone-texture relation ? | [13:01] |
| diana_coman: | you do realise I have to produce the list of vertices AND triangles, nothing less and no implicit will do; not sure I get fully your meaning of texture because the CS "texture" is just an image really. | [13:02] |
| mp_en_viaje: | and this takes to what i'm missing. | [13:03] |
| mp_en_viaje: | yes, texture is just an image. what triangles ? | [13:03] |
| diana_coman: | the "mesh" aka specifically the description of the outer surface (of an underlying 3D object supposedly) through triangles in CS case; basically approximating the 3D surface through a long list of 2D triangles | [13:04] |
| diana_coman: | by "geometry", CG means the 3D shape | [13:05] |
| diana_coman: | I get it that you'd expect to have a skeleton + influences on texture and so derive the shape from there; except that's not what CS expects/does and so if it is to be that, I'll have to explicitly do that derivation and spit out the shape in "neutral pose" or whatever. | [13:09] |
| mp_en_viaje: | is this hard ? | [13:10] |
| diana_coman: | recall, the skeleton is used only during animations, while there IS a "model" even at rest and then the skeleton is fully ignored to start with. | [13:10] |
| mp_en_viaje: | well yes, by the cs. but i mean, this is what "wrap" or "produce" means above | [13:10] |
| mp_en_viaje: | again, take a simple rule, "around main bone, distance x ; around child bones, distance x/2 ; etc". | [13:12] |
| diana_coman: | I can't really say atm; it's not like I have any experience at ALL with this sort of thing or with meshing or with ANY of it; it took me two weeks after all to at least get wtf is exactly the full input cs/cal3d want anyway; I can look into it and see, that's about all I can say. | [13:12] |
| mp_en_viaje: | sure. | [13:12] |
| diana_coman: | anyway, re the above, why is the texture even needed, I don't get it? | [13:12] |
| diana_coman: | you can use any image as texture anyway | [13:12] |
| mp_en_viaje: | what ~I~ am saying on the other hand is that caution can't even be thrown to the wind, for lack of anything but wind to set it on in the first place | [13:13] |
| diana_coman: | it's on top, painted on whatever shape I define through those vertices and triangles | [13:13] |
| mp_en_viaje: | so you know, just do a thing and let's laugh at the product. we'll be way ahead of more responsible adults who do not venture themselves so unconscionably. | [13:13] |
| mp_en_viaje: | diana_coman, i expect you need it to ~see~ the thing. | [13:13] |
| diana_coman: | neah, can even paint it green,w hat | [13:13] |
| mp_en_viaje: | nah. you're looking for subtle detail and meaning. | [13:14] |
| mp_en_viaje: | this is why i said mandelbrot. | [13:14] |
| diana_coman: | hm | [13:14] |
| diana_coman: | from what I gather, your suggestion is in fact simply to "grow" the structure around a set of bones and rely on the mandelbrot paint to trick the eye? | [13:15] |
| mp_en_viaje: | i just want to see what comes out. this isn't a definitive or any other kind of solution | [13:16] |
| mp_en_viaje: | the paint is there to, eg, illustrate something about "this is JUST how the bones should work" or "this is TOTALLY NOT how t=bones shoul work" that we aren't atm in a position to divine for lack of experience | [13:17] |
| mp_en_viaje: | the whole exercise is self-didactic. | [13:17] |
| diana_coman: | as I said earlier - at this stage and the way I see it, pretty much ~any try is worth the same; but I guess after this write-up I got rather cold re "bones" | [13:18] |
| mp_en_viaje: | ie, very cheap experience of the very best kind is available, let's have some. even if the only product of it is that we can later say "well, at least this model isn't as bad as the mandelbuddy", we are still ahead of more responsible adults who do not venture themselves so unconscionably. | [13:19] |
| diana_coman: | ie my inclination was more towards generating whatever shapes of some sizes and *then* attaching those to even random bones for all one cares | [13:19] |
| diana_coman: | I doubt there's anything really very cheap in there, heh | [13:19] |
| mp_en_viaje: | i think this is better than that. | [13:19] |
| mp_en_viaje: | well, eyah, cheapness is always relative. | [13:20] |
| diana_coman: | why? | [13:20] |
| diana_coman: | why this better than that , I mean | [13:20] |
| diana_coman: | (with cheapness it's clear enough, lol) | [13:20] |
| mp_en_viaje: | i got that. because, i believe, that forces you to make more assumptions you're not aware off that then you have to fight with. | [13:21] |
| diana_coman: | hm; funnily enough what I had against the skeleton-based in pretty much the assumptions, hehe | [13:22] |
| diana_coman: | perhaps it's simply that I can see them better there than in the other case, might be. | [13:22] |
| mp_en_viaje: | consider the matter from the traditional republican pov of standing and opposability. you will be asked "why do you even think this is a shape ?" what do you answer, "Because it's in my geometry shapebook ?" then what of "what makes you think your book has any power here, mage ?" | [13:22] |
| diana_coman: | anyways, fine with me, I'll re-read, try to see what it takes, shout when stuck and otherwise see. | [13:22] |
| mp_en_viaje: | k | [13:23] |
| diana_coman: | mp_en_viaje: because it's an equilibrium :D | [13:23] |
| diana_coman: | I don't care of no geometry shapebook; it could not be any other way, given those here parameters; if you don't like it, change the parameters | [13:23] |
| diana_coman: | and/or the process, sure. | [13:24] |
| mp_en_viaje: | you said "make some shapes", did you not ? | [13:24] |
| diana_coman: | yes, but "shapes" does not mean regular shapes or even "usual shapes" | [13:25] |
| mp_en_viaje: | but you will have to by your word make some actuall shapes, specific and given. | [13:25] |
| diana_coman: | hm? so you make with the wrapped mandelbrot, what | [13:25] |
| diana_coman: | or what, because you don't call them shapes they are not that? | [13:25] |
| diana_coman: | I make some "actual shapes" aka the result of one process+one set of params, that's all | [13:26] |
| mp_en_viaje: | and how do you know they are shapes ? | [13:27] |
| mp_en_viaje: | i can say "dude i dunno, i just fucked with the bones, WHICH ARE PART OF THIS". what can you say ? "I got them from geometry, which should be a part of all things" ? | [13:27] |
| diana_coman: | uhm, I suspect it's just some superficial misunderstanding really | [13:29] |
| mp_en_viaje: | well, in any case it's why i suspect this is better than that :P | [13:30] |
| diana_coman: | on one hand I'm not that sure that any bones are part of it; on the other hand you seem to invest "shape" with more meaning than "a finite piece out of the infinite 3d space " (since it's 3d shapes we are talking about, to be more precise) | [13:32] |
| mp_en_viaje: | their space is in principle great, and the actual space of interest in context an unknwon carving from it. hence the problem, an why "it forces you to make assumptions you then have to fight". | [13:33] |
| mp_en_viaje: | anyways, re to have to plug any attempt into the full client just to see the mess. << is this so ? | [13:33] |
| diana_coman: | the way I see it you go for growing it out of a root (the bones) while I go for carving it out of the 3d volume in which it supposedly fits, that's about it all | [13:33] |
| diana_coman: | while initially I was thinking indeed of growing it from the root, the bones debacle dissuaded me from the assumption that indeed that is the root (if there's any clear root) | [13:34] |
| diana_coman: | mp_en_viaje: what being so? now there's the adapted viewer so no, don't have anymore to plug into the client , can see it in the viewer, that was the point of it. | [13:34] |
| mp_en_viaje: | yes, is the client so bulky it's worth having a separate viewer ? | [13:35] |
| mp_en_viaje: | rather the problem is that the client fucks the ooda loop spuriously, innit. | [13:35] |
| diana_coman: | mp_en_viaje: ofc | [13:35] |
| mp_en_viaje: | idiots. | [13:35] |
| mp_en_viaje: | how they manage to always so unerringly cut the branch under foot at the tightest point... it's like god hates people. | [13:36] |
| mp_en_viaje: | anyways, i suppose that code is useful because... well... it might even end up backported ol | [13:36] |
| diana_coman: | and you know, it's insane to go through the whole "load the world" just to see a test char ffs; not to mention that no matter how you put it, the viewer is ...tiny. | [13:36] |
| diana_coman: | anyways, this doesn't mean that I don't intend to see the models in eulora too; it's just that it's really wasting time to fire up the client for each and every viewing of whatever attempt, pretty much. | [13:37] |
| mp_en_viaje: | yeah | [13:37] |
| mp_en_viaje: | anyways, as you say, pretty good news. | [13:38] |
| diana_coman: | it dawns on me that my complaint re "wasting time to fire up the client" is terribly funny now given how it's anyway the client that starts 10x faster than the deployed client since no preloads and all that, lolz | [13:39] |
| mp_en_viaje: | yes well :D | [13:39] |
| diana_coman: | but for futzing with gen-chars, it's still too much. | [13:39] |
| mp_en_viaje: | this is how it goes, nothing more intolerant of the slowness of fast performance than the same spirit that turned mere performance into fast performance in the first place. | [13:39] |
| diana_coman: | lol, I can see it, yes. | [13:40] |
| mp_en_viaje: | relying on a rather neat I'd say physical analogy of finding the equilibrium of an underlying truss structure << right. | [13:55] |
| mp_en_viaje: | I must say that I really like the idea of a generator that effectively looks for an equilibrium solution for a set of displacement functions that are let loose << i think for the record that this intuition is sound. what exactly would be the meaning of such a thing in the context is a little vague yet, but otherwise i don't expect there's alternative approaches. | [13:57] |
| mp_en_viaje: | that blum quote in footnote 6 is fucking beautiful. | [14:01] |
| diana_coman: | it is, isn't it? and coming after a boatload of crap, it literally made my day, that Blum paper. | [14:04] |
| mp_en_viaje: | i see it. | [14:04] |
Comments feed: RSS 2.0