I am new to the rigid body world so please forgive me if I sound naïve in my comments/suggestions below. Let me also add that I have only played around with AnyBody for a few weeks so please take the rest of this note with a fistful of salt. Finally, I am sure some of what I have noted down below has already been, or, is currently being addressed. With that disclaimer out of the way, let me begin my feedback:
I like AnyBody for several important reasons (structure, flexibility, options, support options, details in the anatomy, model repository, videos, etc.). However, I think AnyBody could benefit from by committing to certain areas. Please note that I have also tried to provide suggestions where I could think of something. So, here goes:
A. User interface:
a. If you navigate through the model tree at a rapid rate, AnyBody crashes. This should not happen. [I use a Windows 7 64-bit OS.]
b. The User Interface is a bit awkward. The Window sizing/organization, for example, doesn’t seem to be ‘tuned’ well for the convenience of the user. This may already be in place but, if it is not, I also think a user should have the option of saving user interface settings for later use.
c. The global coordinate system should not disappear when you zoom in to a certain segment of your model in the Model View window.
d. Navigating (zoom, translate, rotate) a model in the Model View window seems odd: For instance, if you make a mistake in AnyScript and load the model, and then try navigating in the Model View window, you will realize that the navigating options do not work the way ought to.
e. There should be an option to record movies of varying frames/sec of your simulations.
B. Scripting environment:
a. Highlighting the beginning and ending braces (much like in many modern IDEs or, in Matlab/Mathematica, etc.) when the cursor is next to them will help a person in writing their script.
C. Documentation:
a. Documentation needs a little polishing. If it were a Wiki, then expert level users could edit and improve it over time.
b. Consistency in writing needs some ironing out. I have noticed some subtle inconsistencies in the writing style.
D. Core code defaults:
a. I understand that there are default drivers in place to make a model run when, in reality, it should not. So, it is incumbent upon the user to be careful of the defaults. While I think I understand why you’d want to do it, I have a philosophical issue with the approach of making software so “user-friendly” that it is too easy to make mistakes. It may help if the user is warned that the solution was reached at by using some default drivers.
b. Additional degrees of freedom at certain anatomical locations (knee and spine, for instance) will help tremendously in some applications.
E. Technical marketing:
a. It would be great, particularly for users in the industry to have an idea of where the company and the code are headed. In order to answer tough questions from the powers-that-be, users such as myself must have some idea and confidence in where the relationship might head in the coming years.
Personally, I think the first three categories ought to be a priority for AnyBody. It is important for new users (such as myself) in the industry, or perhaps, students who are being taught a course, to have a short and fun learning curve because they are the ones who are going to be the proselytizers of the AnyBody religion :). Once you become an intermediate or expert level user, you are fine with or even enjoy the idiosyncrasies of a given code, but folks at the beginner level who are still trying to get their heads around the code and the user interface may not feel the same.