Breaking Brittle Objects

Justin Weidner, CS 777 Tech Piece, Spring 2003

 

      Project Goal:

To create a system that would simulate breaking objects and create animations of that simulation.

 

      Methods Used:

Used this paper as a guideline:

J. Smith, A. Witkin, and D. Baraff, "Fast and Controllable Simulation of the Shattering of Brittle Objects," Graphics Interface, May, 2000.

 

Major elements of this paper: taking a mesh and turning it into tetrahedrons, implementing a solver for constraint dynamics,  simulating breaking forces on a lattice representation of the tetrahedrons, removing constraints based on maximum constraint forces, simulating crack propagation.

 

      What I did:

Implemented a general constraint solver that acts on particle systems, including a particle system representation, an ODE solver based on Runge-Kutta, sparse matrix code, a constraint system manager that initializes the necessary variables to solve the system for constraints, and a conjugate-gradient method that solves the linear system created by the constraint manager.

 

Unfortunately, I spent a great deal of time debugging the above code. Probably the main reason that I spent so much time was that I did not do exhaustive testing of some of the portions of code, after I had tried a few simpler examples that worked. When dealing with numerical systems like the constraint solver, errors can propagate slowly, and only show themselves by blowing up the system at moments when it is not entirely clear which specific portion of code caused the explosion. As a result of time constraints created by that lost time, I was only able to get a somewhat simplistic example of my system evaluating distance and nail constraints into our final animation.

 

      Integration into MAYA:

The simple example (a web) was easy to get into maya, as I merely had my code create a MEL script which imported the particles (web crossings) as spheres, and the distance constraints(web strands) as connections between those spheres. From that point, it was simple to keyframe the motion of the spheres, and as such drive the animation of the web.

 

UPDATE:

Web scene was cut from the final animation, since it didn't mesh well. See it here.

 

      Advice:

It’s important to balance understanding the basic concepts behind whatever processes your technical piece may use (in my case, constraint dynamics) with understanding how specifically those processes are used in the paper you’re trying to implement. In my case, I saw that the paper I intended to implement used constraint forces to drive the simulation, so I concentrated (perhaps too heavily) on creating a constraint force solver, without considering the fact that while the paper did in fact use a constraint solver, the method it used for solving constraints was actually a simplified constraint solver, based on F=MV physics, while I built an F=MA solver. It’s probably better to do what is necessary for you to implement what you need, and then build off of that, than to try and gain some sort of greater understanding of the process and then try to scale back what you’ve done.

Basically, the example above boils down to:

      You should take the time to do a complex analysis of what precise elements will be needed in your paper, preferably with someone who understands the paper enough to be able to help you point out what will be necessary. I thought the best way to understand would be to jump into the code and start plugging away, and while that certainly is true of some aspects of what you’ll probably need to do, it’s prone to getting caught on debugging hang-ups. Once you understand all the parts of whatever it is you’re planning on doing, you should then sit down with someone who knows what will be involved in implementing these parts, and set up a schedule of time that it will take for you to implement the individual pieces and also put them together as a whole.

 

      Results:

Here’s a screenshot of my simulator running:

 

The lines here represent distance constraints, and their color represents the direction and amount of force they are applying to their relative particles(the intersections of lines).

The colors represent:

White – no force(no examples in this shot).

Blue, Green, Red – Increments of positive(pushing) force, with blue being the smallest increment.

Purple, Teal, Yellow – Increments of negative(pulling) force, with purple the smallest increment.

The small white dot in the lower left corner of the lattice is the only particle being acted on by an outside force. All of the constraint forces shown propagate from that force.

 

The simulator does not currently remove forces in anything other than a trivial manner. (the maximum constraint forces are basically arbitrary values, and there is no crack propagation).

This causes the breaks developed to look, well, bad. As in not what they should look like.

In addition, there are no rigid body physics (like intersections/torque) implemented, so when the breaks do occur, the only way the simulator can move the shards (tetrahedrons)

is by moving the centers of the shards, which doesn’t look very good, either.

 

 

      Evaluation:

While I feel that I have gained a much greater understanding of constraint solvers and particle systems, it’s hard to be happy with not having finished what I set out to do by the animation deadline.

It’s kind of funny, that while I’ve probably done a great deal more as far as understanding and implementing complex processes in this project than in any other, it still feels like a net loss without

the accompanying feeling of accomplishment. All in all, though, I’d do it again. Though in a rather more structured manner, I think.