I have attempted to make it easy to convert between physics engines. However, because of the differences outlined above you should really take this as a starting point for you conversion. Most simple systems should convert over and run with no problems. More complex simulations though will almost certainly require work on your part to get them up and running. There is a new menu option under the File menu for Convert physics engine. This will open a conversion dialog that will let you choose among the other available engines. It will attempt to convert the simulation to run in the new engine and if there are issues that need to be fixed first it will give an error message letting you know what the problem is.

With version 2.1.0 AnimatLab has been upgraded to work with both the original Vortex physics engine from CM-Labs, and with the free, open-source Bullet physics engine. All new development in AnimatLab will be on the Bullet physics engine. Vortex will be maintained for an extended period, but eventually it will be going away entirely. I strongly urge you to use Bullet for any new projects, and to begin porting over any old projects that you would like to keep going forward. I tried my best to make it easy to port existing projects over to Bullet. Unfortunately, if it is a complex project it will probably require some work to try and get it running the same with Bullet. There are several differences between the Vortex and Bullet versions, and there are some issues that Bullet currently has that you will need to work around. Below is a list of the differences you should be aware of while porting your applications.

• The biggest issue with the Bullet physics engine is that the motors have trouble running at low unit scales. Below decimeter and decagram the motors start having problems reaching the desired velocities. To help with this, I built a motor assist system for the prismatic joint. I attempted to do the same for the hinge joint, but it did not work, so I have removed it. However, it seems to work fine for the prismatic. In the properties for the prismatic joint you will now see a section for Motor Assist. This allows you to turn the motor assist on/off, and to configure it. It basically uses a simple PID controller to check the position against what it should be, and if there is an error it applies forces manually to try and assist the motor to reach the required speed. For the prismatic joint this seems to work well, and you should hopefully not see any major differences its behavior in Vortex and Bullet. However, this did not work for the hinge joint. I plan to go back and look at this to try and come up with a better solution, but for now the only way I have found to get the hinge motors to work when they have run into this problem is to either decrease the physics time step, or increase the substep increments. The physics substeps parameter is something that is available in Bullet on the Simulation node. It is defaulted to 1. By increasing this value you are telling the physics engine to split its normal physics integration step size up into multiple substeps. Of course, this slows the simulation down, but it does allow the motor model to have the extra processing it needs to converge and move. One way I have been dealing with this is trying to convert my projects up to higher unit scales. Bullet seems to be much better at handling this than Vortex did, so by moving up from grams to decagrams, centagrams, or kilograms helps alleviate the motor problem.
• Dynamic triangular collision meshes are not allowed in Bullet. These really should not be something you are using in Vortex either, because they are so computationally expensive, but Bullet does not allow them at all. You can create a static triangular collision mesh (static means it is frozen and does not move). If you attempt to convert a project that has dynamic triangular collision meshes you will get an error stating you need to change this before it can be converted.
• Friction coefficients are different. Vortex allows you to specify friction coefficients and then chooses the more permissive of the two to use. Bullet works a bit differently and multiplies the coefficients of two colliding objects together and uses the resulting number to calculate friction forces. When you convert a vortex project it attempts to correct the coefficients to make them match as closely as possible, but this is something you may have to look into and play with to get the same behavior.
• Material parameters have been reduced in Bullet. You can only specify linear and angular friction coefficients, and a restitution value.
• Constraint limits behave differently. In Vortex you could specify stiffness and damping parameters for any constraint. You can still do this for the prismatic constraint in Bullet, but there is no equivalent functionality for the hinge joint. Instead, you must specify a bounce parameter that determines how much bounce is allowed. This is similar to restitution, but not quite. Also, even for the prismatic joint, the way the stiffness and damping are modeled is not exactly the same as in vortex, so the results will not be identical. You may need to adjust the params. Another difference is that you could specify the parameters for both the low and high limit in Vortex, but in Bullet you only get one set of params for both limits. So if you have set different values for the low and high constraint limits then the converter will always take the upper values.
• Bullet allows you to specify a spring relaxation for each axis of a joint, including the one where movement occurs. For a prismatic joint this means you can add a spring in it directly to control its movement along the prismatic axis. This is done with the relaxation parameters of a constraint.
• The damping value for all relaxations is not a true damping. If you look at it you will notice that I have removed the units from the relaxation damping. This is because the spring for joint relaxations are implemented using the motor in Bullet. Damping is really just a scaling value that specifies the maximum velocity for the motor. By increasing the damping you are decreasing the maximum velocity and how quickly it can respond to changes. Please keep this in mind if you are using relaxations.
• The Ellipsoid and Torus parts are not available in Bullet. I plan to add these back at some point, but they did not seem important enough to mess with right now.
• The Distance joint is not available in Bullet. I do not intend to add this back in Bullet. However, Bullet does have a number of new joint constraints that I plan to add in the future.
• The Universal joint is really just a ball-socket joint for now. The implementation of the Universal constraint was not stable in Bullet. I plan to look into this, but for the moment I made it duplicate the behavior of ball-socket so it does not give you an error if you are attempting to convert a project that uses this. However, the behavior will not be the same.
• The Bullet plug-in allows you to choose whether you want to use single point or double point precision. It is double point precision by default, but you can specify this when creating a new project, or you can change it by setting the Library Version parameter of the Simulation node.
• The Bullet physics engine will run under both Windows and Linux systems.