Draft data structure for LongBone

[zennithn]

Message copied from Discord below for record-keeping purposes

Alright, I want to float this idea for the LongBone object. @Lathreas in particular, I'd love your feedback!

I've drafted some potential, formal specifications for the objects herein, but I'd first ask for a quick eyeballing and gut-check.

On the left is a data structure for datatypes that would be within a LongBone. ShellPrimitive incorporates the central spline and radial definitions, with a special spin on it. Then, IntrinsicShellModifiers provide a semi-bio-inspired way of modifying the surface. Finally, ExtrinsicLinks might permit further modification such as by muscle insertion sites creating areas of tension.

The current LongBone utilization of central spline and radial definitions is treated more as an implementation detail, and new types of data objects are treated as ways to save and load that data in potentially a more structured way.

actually, @/Gear I'd love your gut check as well. Does this sound like a step in the right, or wrong, direction?

[zennithn]

Updated specification per discussion

[Lathreas]

Message copied from Discord below for record-keeping purposes, in relation to the first post

Ooh, very nice! This looks quite good. The green circles are good control points indeed, and I agree with your statement that the end points must have a thickness modifier. One question: do you intend these thickness modifiers to only change the radius and remain circle-shaped, or can it also be deformed so you can have e.g. ellipses or more complex shapes? That would allow long bones to not be perfectly cylindrical along their shaft. If so, then I can start working on adding a mechanism that interpolates nicely between those rings (that should be very easy to add at this point).

For the central spline, indeed the idea was to eventually have branch points if we need to, but since that's non-trivial to code in, if we can do without those for as long as possible we would probably speed things up a bit. That might also make coding that spline easier from a UI perspective! So I think you'd be fine with using just a central unbranched spline for now. Of course, if it turns out they're really necessary, then we can add it in, but unfortunately that'd likely take some more time.

From my gut feelings, I feel like encoding primary ossification centers in IntrinsicShellModifiers might overcomplicate things, since it's a bit unclear to me what final shape it will have. Since we already have the longitudinal growth defined by the central spline, there seems to be no need for an additional modifier by the primary ossification centers anymore. That is, the primary ossification centers are already implicitly present in the end points of the central spline, so defining the same information twice will lead to a redundancy (which we want to avoid for now). I do see your point in that it would make it more bio-inspired, but of course we can add such functionality later on if we realize we actually need it for something.
I think if we're lucky, the secondary ossification centers might also be redundant, if we can manage to encode all shape information in the ExtrinsicLinks instead (so joints and muscle attachments). Though if not, there could definitely be some use in explicitly encoding those with IntrinsicShellModifiers in locations where there are no attachment points yet there is a complex shape. Could you give me an explicit example in the humerus where you'd imagine there to be no ExtrinsicLink but still a significant protrusion/shape? Also: is the bulging always spherical, or more of a Gaussian curve-shape? Or can it be more extensively controlled?

Overall: this looks very nice already, and I think it's definitely in the right direction! We can always shuffle the actual coding implementation around a bit while we're going over the definitions.