Demolition Script & Tests

My GOD!!
That is amazing! I bet you get that included in the official blender scripts, when you are done!

Thank you for doing this!

great results for a script. amazing. It looks actually more like tearing clothes, but it’s great.

How well does this work with simpler models or tests? Something like a cape getting caught on something and tearing. Or how about the car running into a wall (viewed from the side like a crash-test)?

Very nice just one queston. When will it be ready for download. I know programmer hate answering that because if its not ready on the exact day you get a bunch of post complaing. I promis not to be one of those

that’s a wonderful script.
using it combined with good modeling, texturing, camera shaking and some compositing nodes (motion blur) would produce interesting results!
i’m pretty sure it can bring to blender (and to the author) the same amount of attention from big companies that the fluid simulation did.
i’m looking foward the first release, as many others do :slight_smile:

It looks as good or better than the tractor trailer collision in The Matrix Reloaded. Using this with displacement maps is gonna be mind blowing.

Good job on the stiffness, I want to see this become an official script included in Blender.

Don’t forget volumetric breaking in the future, this is needed for many effects like vases breaking.

Grats man, that is a REALLY good looking script! KEEP IT UP!!!

So far so good. Keep up the great work Kai Kostack! Grins evilly in anticipation of demolishing objects in Blender :evilgrin:

I can’t believe this, nethier can I believe that no one asked for sticky. Sticky this!

http://img525.imageshack.us/img525/5976/43664042oj2.gif

lots of bugs fixed and i’ve worked on centrifugal forces, as you can see. also i have integrated the sleep mode, which is very useful indeed.

i plan to release the script sooner now, because i have no idea to make a useful GUI. for me it seems much more comfortable to have the list of settings editable in the script window and everything is saved also when saving the scene, whereas GUIs “forget” everything.

anyway, a GUI would be nicer for most endusers… i know.

i just want to do a few more tests and then i’ll make some simple example blend files with integrated script and some subdivided boxes or spheres colliding each other. so it will be easier to see your first result. you just have to enable script links and press the anim button.

wow! great! looking forward to it
perhap someone can make a nice GUI for you if you make some notes about the settings :wink:
I think this will be a very popular script

I just keep watching that animated gif over and over and over…:spin:

Amazing stuff. Take your time on it and release it when it is ready.

Koba

P.S> How complicated are the settings? Are they relatively easy to understand/explain? If so, I could make a Python contest for the GUI!

very nice!! I like how it cuts through the mesh. Did you have to split the edges first? Is this using softbody? I also like that there seems to work with different stiffness settings on the two separate objects.

Kai,

are you familiar with BlastCode?

http://www.blastcode.com/index.php

Also what papers are you using? These might be of interest

http://www.cs.berkeley.edu/b-cam/Papers/obrien-2002-GMA.pdf

http://www.huuhoa.com/thesis/PDFs/Cuts/Muller2004.pdf

http://www.cs.berkeley.edu/b-cam/Papers/iben-2006-GSC.pdf

Also this page is a rich resource

http://physicsingraphics.endofinternet.org/

http://scholar.google.com/scholar?num=100&hl=en&lr=&cites=15496696404387193233

For C integration - you might want to have a look at the fluid dynamics code - it creates a new mesh for each frame as well and has some code for storing it, etc. So there is already a framework that might be useful for you. Also you might want to chat with Jahka about his editable baking framework.

LetterRip

Good show for showing him ways he could hardcode it into Blender itself. Way to encourage someone to advance Blender’s simulation suite, a future version could be like this.

-Fluids
-Softbodies
-Rigidbodies
-Particle physics (Jahka’s work)
-Cloth
-Total demolition:eek:

Oh WoW! this looks flippin’ awesome!

This looks really cool, but i agree, being able to use vertex colors would make this way much more flexible, it looks great!

@ibkanat:
no and no, what you are seeing is a “real” simulation of this tire colliding at high speed with the kerb. :slight_smile:

@LetterRip:
i didn’t really used any papers. simply because i’m not smart enough to understand all the described math in it and how to translate it into usable code. it’s a very basic edge spring based system behind it, with some additions to make it practical for special effects simulations.

as for blastcode, it looks nice but that’s all. i call it faked simulation. you have to paint breaking maps, the breaks are not simulated dynamically by the system. this is something i can also do with the knifetool in blender, cutting a mesh into pieces and then use some physics, softbodies or the new particle system on the already destroyed mesh. nothing innovative from my point of view, it’s just a better rigid body solver.

i fear the c integration, a script is easy to handle and to change. but blenders source is so damn huge. we’ll see, but it’s not my priority.

using jahkas new baking system to edit baked crash simulations would be really nice, i thought of it myself. but i’m not sure if it’s compatible to meshes with changing topology from frame to frame. that’s the main connection problem with everything.

@marky1991:
vertex painting is also not a priority for me. you can already do enough cool stuff even without it, i guess. :wink:

@Koba:
that’s the current header, what would you say? is it easy to understand?

## crash group names
#gr1name = "Group"
#gr2name = "Group.001"
gr1name = "CrashGr1"
gr2name = "CrashGr2"
suffix = " Sim"
 
vmblur = 0  # tell me if you're doing a final render with vector motion blur, 1 = on, 0 = off
    # Vector Blur needs some special treatment, because the script is called three times per frame then.
    # Don't forget to activate it or you will get completely different results for the same settings.
 
sleep = 8  # 0   do no calculations beside speed vectors until this frame number
 
breaks = 1  # 1   meshes breakable, 1 = on, 0 = off 
limit = 0.3  # .5  edge break limit (*100 % edge length)
limitTrans = 0.05 # .1  edge break limit for tranparent faces (slower), 0 = disabled
 
maxf = 999  #   maximum speed per vertex
springDamp = .5 # .9  damping of all springs, 1 = no damping, <1 = more damping
    # Use this to prevent noise patterns or chaotic flipping bumps in the surface due to unstable high stresses, but try to keep it as high as possible to save iteration rate.
 
stiff = 0  # !obsolete, use elast instead! - create rigidity edges (very slow on first frame), >0 = count of edges, -1 = all possible edges 
 
elast = 20  # 5   elasticity, objects rebounces, 0 = disabled, >0 = multiplier  of rebounce energy
elastVec = Vector(1, 1, 1) # rebounce direction, (1,1,1) = backward, (0,0,1) = only z-axis is taken into account
    # This is useful to force the colliding object into a special rebounce direction or axis.
elastPieces = 0 #   elast speed correction of free pieces (very slow), 0 = disabled, 1 = enabled
elastDamp = .8 # .9  damping for deformation, 1 = no damping, <1 = more damping
    # Use this to reduce wrapping around effect on collisions, the mesh appears more rigid and less bendable on lower values.
    # But you can see this also as rotation damping, any  rotational speed is going to slow down when elastDamp <1.
    # Be aware that elast and elastDamp, both influences the overall rigidity of the mesh and if elast is disabled, elastDamp is disabled too.
 
iter = 30  # 90  iteration depth of main spring algo (must be a multiple of 3)
smooth = 0  # !obsolete, not needed nor recommended! - iteration depth of smoothing deformation (very slow)
 
self = 0  # !not yet supported! - self collision (slow), 1 = on, 0 = off 
ground = 0  #   ground collision, 1 = on, 0 = off 
frict = 1.5  # 1.5  ground friction (speed = speed /frict)
bounce = 5  # 5   ground rebounce multiplier
 
grav = Vector(0, 0, -.1)  # -0.01  gravity (BU per frame)
air = 1.000     # 1.001  air resistance (speed = speed /air)
 
gr1rigid = 0 #   make group 1 undeformable, 0 = deformable, 1 = completely rigid (indestructible)
gr2rigid = 1 #   make group 2 undeformable, 0 = deformable, 1 = completely rigid (indestructible)
fix = 0   #    make collided vertices stick together (use it with gr#rigid to have better deforming results)
 
gr1spd = Vector(2, 0, 0)  # initial speed vector for crash group 1
gr2spd = Vector(0, 0, 0) # initial speed vector for crash group 2
 
gr1rot = -5     # initial rotation impulse in degree per frame
gr1rotAxis = 'y'   # initial rotation axis, 'X' 'Y' or 'Z'

of course, i’ll write some more instructions and a little howto, too.

and last but not least, some more tests:

http://img201.imageshack.us/img201/415/6aan4.gif

http://img201.imageshack.us/img201/3470/6bdx8.gif

Yup.

I think those variables make sense (to me anyway). If you are sure that is the final set of variables you are going to use, I would imagine people would love writing a GUI. Mainly because it would provide an opportunity to play with your script! However, the next Python Contest is in 10 days at the earliest.

What do you think?

Koba