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
anyway back to bullet i hope it will be universal, not only for Nvidia like in Cuda situation.
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)
Btw long term side info wich is kinda related
http://openjdk.java.net/projects/sumatra/
will be really interesting as oracle works with them togheter.
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
a) it was @wezrule…
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.
@pspeed said: a) it was @wezrule...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.
Actually…
a) It really was @zarch First page… prior to @wezrule 's comment-- that I was referring to anyways.
b) Correct… this would be the most difficult part.
@pspeed
An semi-easy solution would be to add the extra vertices as you’re fragmenting the object into it’s smallest components. Which can original sit at 0,0,0 of the outer-most fragment verts origin, then adjust them as needed when breaking apart the object to give some sense of irregularity.
The more focus that leans towards over-all effect, the less of a problem this would become. Though, I’m sure there is some happy middle ground that would please all.
@t0neg0d said: Actually...a) It really was @zarch First page… prior to @wezrule 's comment-- that I was referring to anyways.
Ah, my bad… I didn’t realize you were responding the almost-a-year-old part of the thread. I incorrectly assumed you were responding to the current parts.
I found out that Blender has this Cell fracture add-on also. It actually seems to work out quite nicely. Except the results are not as fine in jME than in Blender.
[video]http://youtu.be/wtvhGhoDxyo[/video]
And it comes to jME as following:
it’s because fracture in jme and not specific for wall of bricks. A glass will never break like in the video.
Plus, even if the video it’s not really nice : you shouldn’t have a hole that is a square, you should have something more like a bunch of squares put together (like in the picture on the first page of this topic).
And this is the problem :
hole in metal : http://t2.ftcdn.net/jpg/00/43/16/55/400_F_43165529_NR44Tm84N8rGpCICQQ763di59fZDlp4z.jpg
hole in glass : http://www.shutterstock.com/blog/wp-content/uploads/2010/03/break_broken-glass-512x341.jpg (and even larger and more irregular if the ball is slower)
hole in brick wall : http://us.123rf.com/400wm/400/400/antos777/antos7771207/antos777120700106/14382449-hole-in-an-old-brick-wall--background.jpg
Also, they will not always break. For exemple, a metal plate will be distorded, but a glass can only break or resist. And a brick wall, because it’s thicker, will be able to keep the detached brick in it and be “distorded” (but none of its brick will be distorded)
With using bricks I’ll end up getting too costly and expensive physics. Ok, the picture has 100 fractures. But really like 10 looks decent for the building. And for windows I think I could cheat a bit and when some force is applied to a window, it could just disappear with some nice particle effect of shattering glass. I’m not looking for super realistic brick-by-brick destruction. At least not for the “city buildings”. And I would have it that they are easy to model.
