Developing accurate models of the human body is an enormous task, and it is not something each user can do from scratch. We all have to rely on models other people have made, and if we keep improving and exchanging them, we shall end up with a very good supply of models that fit most purposes. The AnyBody™ Managed Model Repository is an attempt to provide such a library.
These are some of the tasks you will want to accomplish with predefined models:
- To change the model pieces to fit your own purposes - preferably without tampering with the interior workings of the parts you are using.
- To be able to combine existing body parts to larger models.
- To be able to attach the parts you can find to model bits you construct yourself.
All this can be done very elegantly in the AnyScript™ language provided you keep it in mind when you construct your models. The AnyBody™ Model Repository is constructed that way, and it contains numerous examples of the technique. In short, it uses the following elements of the language to make it happen:
- Include files
- Parameters
- Equipping parts with their own interfaces
While there are many different ways models could be constructed to obtain the modularity we are looking for, the AnyScript™ Model Repository representsone very well-structured solution, and AnyBody™ Technology strongly recommends following the structure of this library when new models are developed.
The Repository Model Structure
The model repository is really not a part of the AnyBody™ Modeling System. It is a library of models that scientists and other advanced users have developed and made available in the public domain. The AnyBody™ Modeling System does not require you to structure your models in any particular way. But it is much easier to manage large models if you divide them into logical parts, and if you follow the structure of the Repository, then you can use the body parts in the Repository for your own models.
So this tutorial is an introduction to the Model Repository structure as well as a case in point of how models can be organized and interfaced with each other in general.
The Repository has its files structured into two main groups:
Application contains the various devices, environments and working situations you may want to hook the body up to. An application could be a model lifting a box, walking, or riding a bicycle. This means that the Application branch is where you can find the main files of models you can analyze, i.e. the files you actually load into the AnyBody™ Modeling System. You will know them because they have "Main" in their names: <application name>.Main.any.
Body contains AnyScript™ models of the body with no attachments and no specification of movement, forces, or supports. The entire body model contains many hundred muscles and it is rather heavy computationally. For this reason the Body directory is structured to enable the user to link applications to subsets of the body model such as the lower extremities or the shoulder model.
The idea behind the division into Application and Body is that each user wants to model the human body in a special situation. This can take place in the Application branch with references to the Body branch but without tampering with the more delicate Body parts at all.
Let us stay with the Body branch for just a moment. The initial models were created by the AnyBody™ Research Group from Aalborg, Denmark, but from a rather early stage in the development, other groups of model developers chipped in. So the Body branch is divided into separate parts where each group of developers can keep their own models:
AAUHuman contains the Aalborg full body model, while AUHuman contains a mandible model developed in rhus, and Beta refers to other research groups and the non-human models. When you develop an application you can choose to link to whatever body model is your favorite or even choose to generate your own. You may also copy the models of another group into a separate directory and introduce the changes you favor into it.
Body modeling is challenging because so much data is involved, so most users will - at least initially - prefer to link to the body models that are already in the Body branch. This means that the user will create an application in the Application directory that links to a number of model parts in the Body directory. The Application directory has also its internal structure:
Within each of the subdirectories in Application you will find different type of applications, the Examples folder as its name indicates is the main content with a lot of examples of applications, then you will find a folder with validation studies and the Beta folder contains the non-human applications. This is the kind of applications you can find in Examples:
You can find more information on the structuring of the individual body part files in the Structure lesson .
In the rest of this tutorial we shall consider the situation where a new application is to be built using body parts from the Aalborg branch of Body. We shall do so using two different strategies of increasing complexity:
- When an existing application is similar enough to what you want to do to form the basis of the new application.
- When a new application is constructed using a custom set of body part.
This tutorial is based on version 8 of the AnyScript™ model repository. Please notice that the repository models are subject to frequent updates and that a newer, better, and possibly slightly incompatible version may be available from the homepage of the AnyBody™ Research Project . Also the demo models provided in the AnyBody™ Modeling System may be updated compared to the version used here.
With the AnyBody™ Modeling System you already have a repository of models available, for details please see the AnyBody™ Assistant available from the menu. This tutorial has been written using the AnyBody™ Managed Model Repository Ver. 1.1 (AMMRV1.1) if you see differences between the tutorial text and your own results please download AMMRV1.1 from http://forge.anyscript.org/gf/project/ammr/frs/
With that done, please proceed to lesson 1: Modification of an existing application .