Code for computing inertia tensor and mass of a closed triangle mesh.
Code for computing the convex hull triangulation of a point cloud.
Easy creation of convex hulls via the ChBodyEasy.h shortcuts
Cleaned code
Support for changing the contact breaking/merging tolerance of Bullet using a static function in C::E side
Better comments.
Faster collision detection in Bullet with very small objects (the AABB were unnecessarily larger)
New easy class for creating cluster of spheres, ChBodyEasyClusterOfSpheres.
Other improvements in all ChBodyEasyXXXX classes (ex visualization or collision can be on/off at creation)
New ChColorAsset . If one object of this class is added to the asets of a body, all assets should get the specified color (it is up to the converters, ex for OpenGL or POV or Irlicht, to handle this behavior.)
If the ChColorAset is enclosed in a ChAssetLevel, only the shapes included in that level should get the color. This is similar to the behavior of ChTexture, btw., and it is very memory efficient.
Previously, one had to use a ChVisualization asset, but the name was misleading, and the confusing fact is that ChVisualization was also a base class of other shapes like spheres etc.
Some bugs in postprocesser and Irrlicht converter have been fixed too.
Old unused stuff removed.
Fixed the 'multiple defined symbols' linker issue that happened if you linked Irrlicht stuff  from more than one single .cpp. It did not happen with demos, in fact, that are single cpp, but in complex apps with Irrlicht viewing and more than one cpp, it caused troubles.
The problem was that ChIrrCamera and ChIrrEffects came from separate .h and .cpp files that I merged into single .h to keep things simple, but definitions were not inlined. Adding the 'inline' stuff fixed the problem.
Some changes in the FEM test code.
All objects ChBodyEasyXXXX also initialize own 'density' field (that is not widely used, though, but it is here, so it is better to initialize it for completeness)
IMPORTANT change in the way that ChSystem does the management of its lists of bodies, links etc. Internally, there are three lists/vectors, that is: one for ChBody items, one for ChLink items, one for all other ChPhysicsItem that are not bodies or links.
Previously, if using the mysystem.Add( myitem) command, the Add() machinery detected in which of these three lists the item had to be put, but it did not take into consideration that someone might have inserted a ChBody-inherited item, so that was add anyway to the list of 'other ChPhysicsItem' stuff.
Indeed, now it works in the following more reasonable way: if one adds a ChBody-inherited item, such as ChBodyEasySphere or such, it will be sent to the list of ChBody.
Change in the PovRay exporter.
The fact that an object must be exported or not does not depends anymore on the old system of having it inserted in the POVray exporter list (that was limiting in some cases, and not coherent with other exporters).
So, now, one can flag that an object must be rendered by adding the new ChPovRayAsset (it is just a lightweight asset that acts as a flag).
IT is still backward compatible because I modified the Add() function accordingly.
Note that one reason for this change is that it should be able to accomodate the situation where particles / objects are deleted in the course of the simulation, and the POV exporter will handle this automatically.
BTW Last minute update: this 'deletion' feature is broken. Must be tested/fixed.
Fixed some warnings.
Fixed a bug in the POVray exporter. It happened that, if one removed a ChBody from the simulation while running, the POVray exporter still had a list of cached assets and some of them were not used anymore.
The new implementation scans the hashtable of cached assets to see if some asset is referenced only by the hashtable, using the ref counter of the shared pointer, and if so, it can remove it safely from the hashtable.
IMPORTANT. Change in API of shared pointers. Previous code will work as before, but in some cases you will need to add  "DynamicCastTo<...>()" when casting shared pointers.
Background---
Previously, casting between ChSharedPtr shared pointers was too 'liberal', in the sense that it also allowed casting bwtween unrelated pointer types.
Not only this was inconsistent with the way that C++handles normal pointers, but also this left room to programmer mistakes.
Solution---
In the new ChSharedPtr it happens that:
- casting between shared pointers is automatic if upcasting from a specialized class to a parent class, or between same classes, as in c++ pointers; in this case your code does not need any changes.
- casting between shared pointers in downcasting from a base class to a specialized class now explicitly REQUIRES A DYNAMIC CASTING, otherwise you get a compiler error.
- casting between unrelated pointers will generate a compiler error at compile time.
The dynamic casting can be obtained by using the new   DynamicCastTo<>()  function, or by using the new    dynamic_casting_chshared<>(...)   method that is very similar to c++ dynamic_casting.
This means that in this commit we had to change many parts of the code where a base shared pointer was previously cast to specialized classes by doing simply
   ChSharedPtr<MySpecialClass>myspecialized = mybase;
into the new:
   ChSharedPtr<MySpecialClass>myspecialized = mybase.DynamicCastTo<MySpecialClass>();
Note that this requires more typing, but it is less prone to misunderstandings than the previous approach.
The Python wrapper for generating the Chrono::PyEngine units have been modified according to the new safer API of the ChSharedPtr.
Compatibility with GCC compiler: add .template in the new code for dynamic casting. (it compiled ok on MSVC compiler, not on GCC)
Local classes cannot be used in templates (this worked fine in MSVC but broke compilation in GCC, so we moved out the demo classes from the main(..) block of demo_sharedptr.cpp and the demo runs fine anyway).
unit_FEM works without enabling unit_MATLAB