Perhaps it is time for a different approach (yet again)

Greeting, friends. Over the weekend, I've been trying to use Bullet to do the following:

• Break down an input head mesh (.obj) into multiple convex hulls (check!)


• Deform the vertices of the hulls and tell every other colliding object in the scene about the deformation so that they will collide with the deformed convex hulls instead of the original ones (check!)


• Add key hair soft bodies to the scene according to the topology of another .obj mesh (check!)


• Anchor the key hair soft bodies to the convex hulls (check!)


• Deform the vertices of the hulls and tell the key hair soft bodies about the deformation so that they will collide with the deformed convex hulls instead of the original ones (not so much...)

I can anchor the key hair soft bodies to the convex hulls just fine, but the key hairs are completely oblivious to any vertex defomations that take place. I've scoured the source code and searched the forums for a way to force the key hairs to recognize the vertex deformations, but this just doesn't seem to be an implemented feature at the moment. What confuses me the most is the fact that I can shoot spheres (rigid bodies) at the deformed convex hulls and they will bounce off as expected (they recognize the vertex deformations just fine). But, for some reason, the hairs (soft bodies) are not as smart.

The way I see it, there are 3 directions I can take from here:

1. Keep looking for a way to hack the soft body key hairs so that they recognize the vertex deformations - if the rigid bodies can do it, then there has to be a way for the soft bodies to do it!
   
   
2. Take a step back and contextualize what I'm trying to accomplish. This hair is going to go on a virtual character who will nod and shake his/her head. Even though all I have access to is individual vertex positions over time (i.e. key frame data), perhaps there is a way to extrapolate rotation data for the entire mesh by analyzing the net movement of its vertices over time. Bullet will be happy to rotate the convex hulls for me, and the key hair soft bodies can recognize this kind of movement on a larger scale (a transform applied to the convex hulls instead of their vertices). I did some testing to prove this:
   
   
   
   (In this screen shot, I'm moving my mouse back and forth to call ->setImpulse() on the convex hull - there's just 1 convex hull and only 60 hairs to maintain simulation speed, but you get the point. The key is that ->setImpulse() looks at the convex hull as a single body to which a single transformation matrix is applied - individual vertiex positions are not being altered).
   
   
3. Create my own soft body key hairs and give them some thickness. At the moment I am modeling/simulating the key hairs as collections of 2d links with soft body physics applied to them (i.e. some deformation and bounciness is permitted). Please note I was not 1337 enough to create these myself - I modified one of Bullet's soft body primitives (rope). If I were to bring these links into the 3rd dimension, however, maybe this would make their collisions more robust and, as a result, force them to recognize the tiny vertex deformations of the convex hulls. I think I could go about doing this by either (a) joining together some rigid body cylinders or (b) joining together some soft body trimeshes (this would involve building a trimesh "cylinder" out of soft body patches). The downside to (a) is that I lose the deformation and springiness of soft body physics. As we all know, hair bounces just slightly and does indeed stretch slightly as well (maybe not to the degree that I have them bouncing above, but it still yields a more realistic approach than stiff sticks connected together).

2 and 3 are not easy endeavors (but which part of this project has been, eh? ;-) ). I am leaning towards 2, but at the same time, I am hesitant to take that approach because I'm not sure how to look at a cloud of vertices and extrapolate one transformation matrix to represent their net movement over one time step. Perhaps I will ask one of my advisors about the 3 approaches...maybe they'll have a better idea of what's feasible.

For those of you who don't know, I am going to try to continue this project into next semester - in other words, apply for an "Incomplete" and finish it at a later point. This is a relief, seeing as, as it stands, the project is nowhere near worthy for judging eyes. In order to successfully apply for an "Incomplete" however, I need to list out my remaining goals for the project and give an approximate time line for accomplishing them. My next post will consist of this time line - seeing as I did a poor job with predicting how long my project goals would take to complete, I'm going to ask for some planning advice this time. I have my list of goals, I just don't know how much time I should allot to them. :-/

Expect an update later tonight!