Hi,
I’m trying to get more realistic destruction of walls and other structures for my game, but I wasn’t able to get a solution for my problem despite of intensive research.
So here is my problem:
When I simply shoot some stacked bricks with a cannonball, the entire wall gets pushed towards the contact point.
Sometimes, the wall even falls over after getting hit.
What I want to achieve is that some bigger parts of the wall will break out, but the rest of the wall withstands.
I tried to manage the broken fragments with CompoundCollisionShapes but that doesnt work fine.
I also played with gravity, weights and friction for hours with no satisfying result.
I think of something like cement or glue, wich keeps the bricks together, until the force (the impact of the cannonball) gets too big.
I want to use that in a siege simulator: The walls of a fortress don’t shift when hit by projectiles, they also do not simply fall over. They get defragmentated part by part.
You may want to find some articles, about how voronoi fractures work, thats how udk does it.
To elaborate i believe the way this effect is achieved, is by having your wall be pre broken, and having collision rules to activate certain pieces of the wall for physics interactions upon collision with a predifined collision shape around the wall fragments. That way your walls dont fall apart until something important hits them, and also the way your tests work is pretty accurate to what happens to brick walls, although not many walls are made of brick, and most are made of several layers of brick, there are also other layers, plaster and so on. Either way this physics partitioning scheme should help you avoid doing a tons of physics calculations all the time and restrict the simulation to parts that actually get damage. You also might not want to have all the walls destructible, or all of one wall destructible as it will make things like AI conditioning and navigation calculations much more complex(not to mention game design).
Thank you for the fast reply.
I know predifined destruction from many games, and I think, it often is very “boring”, but I will have a closer look on that voronoi fracture.
This could be what I’m searching for, thank you!
Well it is coding == research, but I’m only making small test games, keeping a bigger project in mind.
@FabianoSantalucia said:
Thank you for the fast reply.
I know predifined destruction from many games, and I think, it often is very "boring", but I will have a closer look on that voronoi fracture.
If you notice no game has everything be a dynamic object, the reason for that is because physics simulation is extremely expensive, the partitioning idea i proposed is whats used in unreal, the reason it works is that it doesnt simulate physics until it needs to, and there is still a limit to how much you can have in the scene so there are several optimizations you potentially need to employ. That is >>> remove old chunks that have fell off previously to allow room for new ones.
In the video bellow you see exactly that, but please note, that in UDK they use physx which is hardware accelerated unlike bullet(especially jbullet) so the amount of dynamic objects you can dedicated to physics is going to be much smaller.
[video]http://www.youtube.com/watch?v=oatcdoTH30Y[/video]
Well, that example doesn’t really have many active sections at all, in fact falling sections seemed to leave no debris which is already less impressive than lexicon.
You also will note that he never completely cuts the wall in half
There was no code in there to spot when it reached a critical point and collapse the whole thing.
@nick.meister37: Actually they struggle everywhere to fulfill the promises of hardware accelerated physics, it seems they still got to figure out some decent algos But bullet is getting there too, thats one of the reasons we will move to native bullet.
@zarch
That example i pasted was the last clip that i got to before i gave up looking for what i as intending to show :’( which was the actual construction of a scene like this i saw a long time ago when APEX was first introduced, to illustrate the fact that not the whole scene was meant to be destructible, and the ones that were meant were pre subdivided and only activated on impact, but alas no luck
@normen
They struggle sure, but what i was trying to point out that some ( i dont remember which parts if not all) of physx utilizes cuda, which is supposed to provide simulations with ridiculous amount of participating objects(pointing to >>> the car smoke demo with like a million real time particles, which is not really related but oh well). Anyways
yes that Lexicon thing was pretty cool, unfortunately there were some shadow artifacts along the cut lines which put me off, it must be because of the ppsm shadows with their real time camera change flickering problems. (http://hub.jmonkeyengine.org/forum/topic/ppsm-stabilisation-approach/)
Yeah, particles and generally stuff that doesn’t collide works very well on GPUs Also the occasional “lotta marbles/boxes test”… Cuda is basically OpenGL/CL “raw”, so generally (given theres no serious api limitation in OpenCL or “direct access” for some new hardware function in Cuda sooner) bullet should be able to get into that performance range too… Well lets see what they come up with
Yeah, TBH personally if I was doing the splitting then I’d have a single mesh and I’d do the split dynamically in CPU by editing the mesh. That way no wasted cycles processing the multiple objects before hand, no ugly seam lines, etc… Just provide a spot on the texture atlas for the “cut” wall, and when the split happens generate the mesh for the fragment and remove the corresponding area from the main mesh. Once the mesh stops falling batch it back into the original, recalculate the physics shape and you are back to original geometry count (although with more vertices).
Would take a fair bit of maths and experimenting with algorithms etc to get a good result but entirely feasible.
A system like this would even support really neat stuff like blowing a section out of the wall and then blasting that section apart while it is in mid air, etc.
@FabianoSantalucia I’m the one that did the building destruction. There’s a little explanation of it on that thread, but here’s a little bit more in-depth:
Create the model, then use a fracture script (in 3DS Max, use FractureVoronoi 1.1, in Blender it has it’s own fracture thing built in.) to break the model into the desired number of pieces. On load, give each one a MeshCollisionShape and 0 mass. Track any collisions with them, check the force, and if it’s higher than your given threshold, give the part a DynamicMeshCollisionShape and a mass of whatever you want, and optionally you can give it an impulse in the direction of the force that caused it to “fracture.” Keep in mind though, the more parts in one wall you have the longer it takes to load it all. In my game it took about 3 seconds to calculate the mesh collision shapes and everything like that. Also, it’s pretty overhead-heavy, but seeing as you don’t have a huge number of parts it shouldn’t be anything to fret over at first. However, you may look into extending RigidBodyControl, pre-calculating the DynamicMeshCollisionShapes, and setting it via a new method like “setFinalCollisionShape(CollisionShape coll)” or something, and give it a method called “fracture(Vector3f impulse)” which simply gives it a mass and sets it’s new collision shape internally. Also, the impulse Vector3f can be used to apply the force. Just supply Vector3f.ZERO if you don’t want to apply the impulse.
Thats exactly how I understood your building destruction program and how I would have used it. But I don’t want the destruction to be predefined, so I’m searching for another way.
I am pretty close to a good solution and I think what I figured out will work, but I currently don’t have very much time to implement everything.
It’ll have to wait some weeks because of some nasty exams
Well opencl runs on Nvidia,AMd and even intel even pure cpu if no graficcard with suport is there.
Also similar to the jit in java it has the possibility to optimize your code for the aviable hardware agressivly (at the cost of a few seconds more load time)
Has anyone successfully calculated these voronoi fractures in jME dynamically? I tried out the Blender’s build-in Fracture object thingie and I wasn’t very impressed by it. It works for the default 1x1x1 cube quite well. But I tried to create a simple house model and it didn’t work at all. I tried many approaches on creating the house model and none of which were very successful.
One particular thing that the Blender’s fracturing algorithm fails is calculating somewhat even fractures. On a large surface, creating only few fractures leads to few small fractures on the center of the surface. It makes up an ugly fracturing…
And it would be much nicer to have a dynamic fracture calculation. Models could remain more simple… Thank you for these tips on this thread. I was successful to destroy many things with vinexgames’ tips.
Real-time dynamic fracture is definitely possible (and becoming more common now), as it allows the “breaking” to be concentrated in the affected area (like a stone hitting glass), rather than a predefined breaking pattern. I had a look into it a couple months ago, read many papers on it and from what I remember, Fortune’s algorithm was the most used, and convex shapes are the easiest to fracture. It’s definitely not a beginner topic, you need to look into volumetric techniques, procedural uv/texturing, and some other shizzle. Erin Catto (creator of Box2d physics), had a nice article on the different techniques, but I can’t seem to find it, somewhere in here: https://code.google.com/p/box2d/downloads/list
I second what @zarch said… and honestly do not think it would be as difficult as even he suggested.
I would take a very similar approach to how a particle emitter works for manipulating the potential fragment within the destructible.
I would store the index buffer in chucks that can be re-assembled based on how fragmented the particles were, but ALWAYS keep the vertex count exactly the same.
However the potential vert count tracked by any one particle would be completely dynamic, thus the need for a chunked index buffer.
I would only represent larger fragments in physics space and consider smaller ones non-collidable and only there for over-all effect.
It would be a pretty cool system for someone to put together… and between BatchNode (as it contains code that could be leveraged with some severe tweaking) and my (or @zarch 's) particle emitter system… it would not be difficult to put together at all.
Anyways… for what it is worth. The over-all effect > the accuracy of the effect. An accurate lump of shit… is still a lump of shit and since FPS > all… a compromise would have to be reached between realism and bad-assery.
@t0neg0d said:
I second what @zarch said... and honestly do not think it would be as difficult as even he suggested.
I would take a very similar approach to how a particle emitter works for manipulating the potential fragment within the destructible.
I would store the index buffer in chucks that can be re-assembled based on how fragmented the particles were, but ALWAYS keep the vertex count exactly the same.
However the potential vert count tracked by any one particle would be completely dynamic, thus the need for a chunked index buffer.
I would only represent larger fragments in physics space and consider smaller ones non-collidable and only there for over-all effect.
It would be a pretty cool system for someone to put together… and between BatchNode (as it contains code that could be leveraged with some severe tweaking) and my (or @zarch 's) particle emitter system… it would not be difficult to put together at all.
Anyways… for what it is worth. The over-all effect > the accuracy of the effect. An accurate lump of shit… is still a lump of shit and since FPS > all… a compromise would have to be reached between realism and bad-assery.
b) I think the hard part is generating the surfaces for where the object has fractured so that it doesn’t look like it’s made out of a hollow paper shell.
and i think that it depends on the model we have. If we only have a mesh, then it’s very hard to do, because we don’t know anything about how the object is suppose to be. A wall of bricks and a wall of metal behave differently.
That said, i thing that a “wall of brick” model should be too hard to do, and put over an existing mesh. And, once we have this (but it implies some work for the dev - except in cube worlds where it’s already done), i think that it’s not that hard to have an algorithm that dispatch the force in the “wall of brick” model and break it of the wall isn’t resistent enough.
Actually, this would be easily done by just adding some join between bricks, and add a “maximum-resistance” to the join (if the applied force is greater than the maximum-resistance, the join break (=is removed)). I know that there is already such “maximum-resistance” in the actual join system. BUT, it will be very expensive for the physics engine (and the cpu/ppu) and for nothing. What i was suggesting with my “wall of bricks” model was something more specific but maybe less cpu intensive.
But bullet is getting there too, thats one of the reasons we will move to native bullet.
and since FPS > all… a compromise would have to be reached between realism and bad-assery.