Implementing Bullet Collisions

I apologize for the lack of updates (again, I had to devote most of my time to another CIS564 project - http://www.youtube.com/watch?v=YQApmArwUSk). I am going to try my best to catch up on hair sim work this week/weekend over TG break. I do have some tiny things to show in the meantime, however. Using one of the Bullet demos as a starting point (and the power of the Bullet forums - I'm so glad that this library is well documented and supported...yes, I'm talking to you, OpenMesh!), I have put together a mini project that lets me shoot "particles" at an "animated" head collider! Check out the footage below.

The keen observer will note, however, that some of the cube "particles" pass right through the head mesh instead of bouncing off. I'm not exactly sure why this is - I've posted a question on the forums and will get back to you when I receive a reply. So, hopefully I have come close to solving the issue of "which collision detection method is most efficient" (again, by letting more experienced programmers take care of it for me). The next step will be to decide where to draw the line between Bullet and my own particle dynamics code (i.e. how to integrate the two). For example, I could let Bullet take care of the initial particle movements/collisions and then append my own special iterative constraints (including where / how far the particles are allowed to move). I think I will go with that plan of integration for now...

This brings me to another simultaneous task that I'd like to complete this week - developing a class hierarchy (including OpenGL representations) for different hair LODs. Here are the 3 major players:Strips, clusters, and strands. I already have a rough strand class working...it shouldn't be too difficult to use it as a starting point for the other 2 LODs. Also, now that I'm working with Bullet, I can start to think of how to structure these in terms of collision shapes that Bullet is familiar with (spheres, boxes, cylinders, and others). So, I could see I strand as being a collection of constrained (to each other) collision spheres, while a cluster would be a collection of constrained collision cylinders (or spheres with a radius equal to the cylinders that will be drawn around the base skeleton). The strip is a bit trickier - again, perhaps I could just use collision spheres held together in a kind of net. There's also the question of whether or not all 3 LODs are extremely necessary (as far as this project is concerned). I'd love to just use 2 of the 3. I found this video from a Pixar paper about hair simulation / rendering in the Incredibles:

They're just using strips here, and already (with some rendering tricks and interpolation) things are looking good.

So, to summarize, here are the things that I'd like to at least have started by next week:

• Resolve the disappearing particles issue in Bullet
  
• Construct a class hierarchy for the 3 LODs, including both OpenGL representations (how does OpenGL draw them?) and Bullet representations (how does Bullet see them?)
• Bring everything back over to my OpenGL/FLTK testing ground (as opposed to Bullet's)
• Populate the scalp with 1 of the 3 (or all 3) LODs
• Begin looking into methods of interpolation across the scalp geometry (the Nalu demo comes to mind)

Ready, set, break!

Which Pile of Bunnies is Better?

I spent some time today messing with the Bullet / ODE demos, specifically comparing and contrasting collision detection performance and mesh-mesh interactions between the two. This has left me with two very large piles of Stanford bunnies:

(Bullet Bunnies)

(ODE Bunnies)

I know, I know...you can't really tell which is the better engine by just looking at snapshots, but based on dropping these guys on top of each other (and shooting cubes around, among other things), I think I'll try to plug Bullet in first. Its collision performance looks a bit smoother (which also seems to be the consensus reached in various programming forums that I visited).

...Although, Pixar has been known to use ODE. No, no...Bullet for now. I'll let you know how it goes.

Sorry, I was making a game...

This past weekend was dedicated entirely to completing a CIS564 project (http://www.youtube.com/watch?v=o3x2L8oXaKY), so no progress was made on my hairs. However, the following statistics may give you a hint as to my plans for the rest of this week/weekend.
See, this way...I don't need to worry about whether or not my collision detection algorithm is efficient (though I'm still proud that I was able to implement it). Hmm, for some reason this decision to use a pre-made library for the sake of a higher quality output sounds familiar (Qt and OpenMesh *cough, cough*).

Narrowing Down Algorithms

Modeling

• Transition between different Levels-of-Detail (LODs) or Wisps

1. Strands (highest) --> Clusters --> Strips (lowest)
2. Use (a modified) Adaptive Wisp Tree (AWT) to facilitate transitions

• Interpolation of sparse guide hairs (points connected by curves) to create density

1. Guide hairs grown based on scalp geometry
2. Guide hairs loaded from a file

Animating

• Particle dynamics (treat control points of guide hairs like particles)

1. Verlet integration
2. Runge-Kutta integration

• Collision detection using a polygonal mesh boundary around the head

Rendering

• Anisotropic reflections

1. Marschner model
2. Look-up textures

• Opacity shadow maps

Collision Detection using Rays

Ray tracing isn't just for rendering scenes, you know! It also comes in handy for 3d collision detection (as opposed to, say...projecting your collider onto all 3 coordinate planes and trying to call pointInPoly for each projected face...not like I tried that or anything...). I know this is just one hair strand, but the ability to maintain speed at this stage is encouraging. No more snapping either!

(yes, I know...his one eye creeps me out too)

Upcoming Tasks:

• Using Connelly's HairQuad class as a road map, begin devising a way of organizing hair strands into groups that collide with each other [Update: Actually, I don't think I'll combine hair strands into groups quite yet - I'd like to create classes for the other 2 LODs (hair clusters and hair strips) first. Maybe they can all be subclasses of the same virtual class (HairLOD or something like that). Then I'll look into ways of transitioning between the 3 (maybe based on proximity or occlusion - this will require reading through the Adaptive Wisp Tree paper again). So, I'm going to rewrite this task as: Implement self-intersection for hair strands. Then, create HairCluster and HairStrip classes, both with collision (self and collider) capabilities like the HairStrand class.]
  
• Try connecting the hair strand control points with curves (Bezier, Hermite, B-splines?)
• Continue to collaborate with Cat --> use OpenMesh objects as input for colliders (I'm currently using a simple .obj parser instead)
• Write the "Background" section of my proposal [Update: done, but I'll probably keep revising it]
  

Collider-phyllic Strands

Collision detection is working! Unfortunately, the hair strand seems to want to stick to the collider. I'm going to look into this more...

(just one "free" control point)

(collder-phyllic strand!)

UPDATE: I have fixed the issue! Silly me, I was projecting all of the "free" control points onto the collider mesh whenever just one collided (hence all of them suddenly snapped into place). I've adjusted my code to snap just the colliding particle:

(getting better...)

Alas, the snap is still a bit too forceful. I don't really know what's causing this. It seems almost contradictory: one the one hand, the snap means that my code has registered a collision, but on the other, the abruptness of the snap seems to imply that some extra steps are needed to get the particle a little closer to the collider before it actually collides. So, my eyes are telling me one thing, but my code (the math) is telling me another. I trust my eyes more, honestly. ~__~

A Strand of Progress

Good one! Using Connelly's Hair class as a road map (in addition to Jakobsen's paper), I've constructed my own (albeit crude) HairStrand class. Here's the little guy in action (gravity is turned on in the negative y direction, and the drag coefficient is set to 0.5):

Cat is currently helping me to get a grip on manipulating OpenMesh objects (specifically how to grab vertex positions from a TriMeshT object - it looks like I'll probably need to use iterators). Unfortunately, the library is not very well documented and definitely not very intuitive (for me, anyway). So, with that going on in the background, my next step consists of colliding this little guy with a polygonal mesh. I have the function written up and ready to go, but I'm betting it won't cooperate on the first test run. For testing these interactions, I'm using a simple Fl_Gl_Window object (vs. Qt).