Could you tell me more about the InstancedTriangleMeshes? What benefits can they bring (lower memory use?, improved speed?)
Their primary benefit is memory. An instanced triangle mesh shape contains both its base triangle data and its hierarchy in local space. Each instance can have completely different, non-rigid transforms as well (sheared, scaled, skewed, translated, rotated, etc.).
In terms of performance, a convex shape colliding with a InstancedTriangleMesh will be very slightly slower than a non-instanced mesh, since the shape must be transformed into the instance's local space. Relative to the rest of the collision detection process, this is a very small cost.
Colliding a complicated compound body or mesh against an instanced mesh will have an extra cost compared to two objects with world-space hierarchies. However, such collisions are rare and are still not that slow.
A good example of where the InstancedTriangleMesh would be useful is if you have 4-10 unique tree collision models which are repeated in various poses and transformations to form a forest. With normal meshes, the hierarchy (with size proportional to the number of triangles in the mesh) would need to be repeated for every single tree. For instanced meshes, only the original 4-10 hierarchies exist and each instance just has a transform matrix. For a sufficiently large forest and complicated tree mesh, the simulation might be impossible without using instancing due to the memory required.
Are there any features that are missing from .14, if so will they be returning? (one shot manifolds are obviously gone at the moment)
Other than the manifolds, the compound bodies with non-convex children might be another one. My goal is to support non-convex children, but we'll see how it works out.
I can't immediately remember anything else. There's probably a few obscure properties that no longer have a meaning due to the new system or got removed, but the major functionality should all still be present.
Any idea yet on the speed of .15 compared to the speed of .14? It seems like lots of improvements have been made to just make the engine smarter and do less work which usually would mean it would be faster.
It should indeed be faster, but I still don't have real benchmark numbers. The biggest sources of speedup will likely be from the redesigned collision systems. MPR received some improvements to how support mappings are managed. GJK was basically rewritten from the ground up. I wouldn't be surprised to see GJK running 2-4x faster now, although what that translates to in end performance gains depends on the simulation. The general convex-convex collision detection case also received some other miscellaneous improvements.
Simulations with lots of triangle meshes stand to benefit the most. Triangle-convex collisions should have a special case which, in many cases, will be extremely fast and accurate (5-30x faster than GJK, close to sphere-sphere). In some circumstances, the special case will fall back to the new and improved MPR/GJK. In addition to the per-triangle test improvements, the triangle hierarchies have been rewritten and should play nicer in memory and have a bit of a speed boost too.
Less importantly, I plan to add a few more special cases to things like capsules. These might wait until v0.16.0, but they are pretty simple shapes which can benefit a lot from a little more attention.
What those numbers will actually translate to in 'end performance increase' is unknown. My guess is that the Xbox360 and WP7 will benefit proportionally more due to the various memory-handling changes (reductions in memory usage from instanced meshes, large reductions in heap access in general, more very local stack fiddling).
Given that the box-box special case changes from a couple of versions ago boosted the Xbox360 from 30ms to 15ms on the wall simulation, I would suspect simulations heavily relying on the improved bits would get a similar speedup.
Obviously there are many breaking changes, do you think upgrading will prove to be a problem or is it mostly strait forward and simple fixes.
It depends on what a given project is closely integrated with. For example, a simulation relying heavily on certain quirks of StaticTriangleGroup functionality is probably going to have to do a little redesigning. A simulation that simply includes a StaticTriangleGroup, on the other hand, might just have to change a name or two and the parameters to a constructor.
I assume we are looking at 2+ weeks for testing, debugging and finishing .15 yes?
Yes; I really don't want it to take much longer than that. I'm looking at the to-do list for what still needs to be done and, while it's pretty long still, if I can finish one or two of the items each day and push a couple of the less important ones to v0.16.0, it should work out.
But then, of course, I'm sure some sort of horrible bug will crop up at the last second