Anatomy Re-engineering Framework Progress Report
By Ellie, Lathreas, Kistaro, SiberDrac, Liz, Videah, Athamanatha, and Zennith
Why are we working on this?
To briefly recap why we are building this tool, we have to consider what it takes to create a full-body transformation. Most importantly, whatever the resulting anatomy will be, it must both look good and be safe for the patient. This requires the anatomy of end result to work as intended, both internally and externally. The human body plan is too complicated to safely redesign by hand, and as such requires a Computer Aided Design (CAD) tool.
Unfortunately, despite the existence of many CAD tools and anatomical models of humans, there exists no CAD tool to safely alter human anatomy to a nonhuman form. To bridge this gap, we are developing a new tool for this purpose, which we expect we’ll be using extensively to design new surgical or genetic treatments in the future.
Brief overview of this project
The most important functions of our program are edits to bones, muscles, and skin, since we’ll need to design anatomy at that level the soonest. We will add additional details, such as nerves, blood vessels, lymph nodes, and so on afterwards. You can read more about the road we’ve traveled in our previous update report.
We’ve designed a novel system that is capable of parametrically defining bones and muscles. This means that an engineer has full control over the functional properties of bones, and the bone is not just an eyeballed sculpture. For example, the characteristic club-shaped head of a humerus is not just random: its function is clearly defined by the fact that it is a hinge joint. As such, it is essential for us to understand and preserve the functions of a bone before we attempt surgery or genetic treatments.
New progress: our first bone hinge joints work!
After designing, implementing, and a lot of testing, we’re now nearly done with the bone-to-hinge-joint interface! This feature allows us to accurately represent the bone shape at hinge joints, which were the most difficult joints to implement. Previously, it was only able to represent the cylindrical shape of the humeral head, but now it also generates the cup-like shape of the ulna. This new method accurately represents the hinge-joint socket, so that it actually works correctly as it does in real life. You can read about the concept of our model’s design in our previous update under the Concept of our model’s design section.
The above videos show an accurate bone joint generated by the program. The ulna, at the bottom, rotates around the humerus around its hinge joint. Although these are just toy bones, the hinge joint surfaces themselves are perfectly shaped to be able to hinge in real life. Remember, this is not a hand-sculpted hinge joint. Instead, the program ensures that the hinge joint is shaped correctly using input from the user. To make this possible, Lathreas and the team have implemented new joint shape methods to smooth the hinge constraint to the surrounding bone. The hinge joint was the most difficult joint type to implement due to its unique properties. Now that we know the system works, it will become much easier to add additional joint types.
We’re now ready to work on the muscle system
With the bone system well-underway, the next major function of the tool is for users to add and edit muscles. This actually ties back into the bone shape system, since not only does muscle tissue attach to the bone, it also deforms it based on the attachment and forces applied. Like the joint interactions, the muscles have an effect on the shape of the bone, and therefore need to be taken into account when generating the bone shape.
The muscles themselves are quite a bit different from bones, of course. Whereas bones are rigid objects, muscles can contract, stretch, and bulge. This means that the program must be able to account for this softness, to ensure that the muscles are attached and routed properly. This will be essential to properly design the snout of an anthropomorphic creature, for example – the muscles under the skin will greatly affect how the face of a person looks, and whether facial expressions look natural. Or for adding tails, where incorrectly placed muscles can make it impossible to move your tail.
Figure 2: The muscle system involves attaching a muscle to a bone. This deforms the attachment site on the bone.
Simulating muscles as springs
It is important to note that the volume of a muscle cannot change when it contracts. This is important to consider in our model to ensure that the thickening of a muscle during contraction will not prohibit movement, or lead to squishing surrounding veins. As such, we will have to simulate muscle contraction correctly. We can do this relatively easily by representing muscles as strings of beads that are connected by springs:
Figure 3: We will model the muscles as beads connected by springs, which have a volume element attached to it. When a muscle contracts, its volume cannot change. As such, the decrease in length must be accompanied by an increase in width. We account for this by making each bead a volume element.
Muscles are comprised of fascicles
Muscles are more than just that, though. To accurately represent muscles, we have to look back at biology. Muscles are fundamentally built from parallel fibers that are bundled together in ‘fascicles’. We can represent muscles in the same way, by placing deformed cylinders next to each other to represent fascicles.
Figure 4: We can represent fascicles as cylindrical elements packed close together. This defines the shape of the attachment site as well.
By representing the muscles as bundles of fascicles, we ensure that the model remains physiologically accurate. At the same time, it allows us to properly emulate the ways in which muscles move in real life.
Figure 5: Muscles will have varying thickness along its length, and should be able to deform. During movement, this means we need to simulate the fascicles so that they don’t intersect, and maintain their volume.
We are currently working through setting up the simulation, and perhaps most importantly, we are investigating methods to prevent the muscle from intersecting bones while editing or simulating.
Together, the muscle system constitutes the second major function of the engine, with the third and final step for our initial demo being skin.
A good user interface is in the works
Now that the tool actually has some basic functionality, we need to take a look at how users will interact with the software. Making an effective user interface is important to adoption and usage of any software, so we’d like to ensure that we pick a good route to go down.
Figure 6: Very rough mockup drawing of a possible user interface. This is all very early stage, so the theme, font and colors are of course subject to change. On the left is a hierarchy of joint, bone, muscle and skin objects that the user can change the settings of. On the right is an example interface of a hinge joint connecting two bones. The red and green surfaces represent the inner and outer surfaces of the joint, and can be adjusted to provide the maximum flexion angle (here 163 degrees).
So far, we have prototyped the 3D Anatomy tool using the Godot engine. Although this has been an excellent tool for prototyping so far, we are now entering a stage where we want to focus on building a good user interface. This requires a frontend that has the tools necessary for computer-aided design. Godot, being a game engine, isn’t optimized for editing meshes, which would require us to reimplement most of the 3d editing tools ourselves.
A fast road towards a user interface
Luckily, there are very powerful and extensible front-end frameworks available for to plug into. One such alternative is Blender, a free and open source 3D modeling platform used widely in research, animation, prototyping, simulation, and many other fields. It has a robust suite of tools and features, as well as strong community support and contributions. Importantly to us, Blender has recently added many new mesh, sculpting, and rendering tools we need – in particular Geometry Nodes. We expect that integrating our engine into Blender will significantly speed up development and improve the final product.
We are currently investigating what would be required to integrate our engine into Blender. In this scenario, the 3D Anatomy tool would be a plugin for the Blender software. This has the added benefit of allowing our team to do significantly less work to establish a user interface, as Blender already has all the tools we need. The team is currently doing some more detailed investigation to determine whether or not Blender would be a good route to take. Whatever happens, we want to make sure the 3D Anatomy tool is both easy to use and powerful, so we’re taking the time to figure out what would be best for the project.
We’ve added new team members!
Last but certainly not least, we’ve onboarded two new team members! Our new member Liz will help implementing the new muscle system, which is no small task indeed. She is currently working on simulating the muscle as a bundle of fascicles. We’ve also added Videah to the team. He’s an excellent programmer who will be focusing on user experience and the user interface. He will assist anywhere the anatomy engine will be interacting with users.
Going forward
More and more pieces of the puzzle are coming together, which allows us to look at the future. Having successfully implemented hinge joints, we are now ready to add the remaining types of bones and interactions. Our main priority right now is to implement the muscle system and creating a user interface. We are currently evaluating Blender to build our user interface with. Expect an update about that progress soon!
The final remaining component of our proof-of-concept system is skin tissue. We will begin working on once the muscle system is in place. At that stage, we can consider adding more advanced detail, such as veins, nerves, fur/scales/feathers. Finally, we must add features to test and verify that the transformation outcome is safe and aesthetically pleasing.
Thank you all so much for the support and interest you’ve shown in this project. We’ll keep you posted with minor and major updates as things progress! If you have any questions, please feel free to reach out to us.
Sincerely,
The Project Team
3D Anatomy
Freedom of Form Foundation
501(c)(3) EIN 82-4415111
Our updated code will soon be published on GitHub under a GPLv2 open-source license, once we have finalized our git procedure for .blend files. The binary format of .blend files requires some attention to avoid illegible merge conflicts, which we expect to settle on in the coming few months. You can take a peek at our previous C# repository in the mean time – which covers the main data structures and logic used.
Acknowledgements
Ellie drafted the update report. Lathreas edited and provided graphics, and developed the core concepts of the bone and muscle engine. Liz is deriving the mathematics of muscle deformations. Kistaro provided thorough code maintenance & review and guided tooling. SiberDrac reviewed and explained the developmental biology of bone and muscle development. Athamanatha, Kistaro, Lathreas, Liz, SiberDrac, Videah and Zennith provided technical contributions to project development.
