I want to introduce a new destruction engine called MOAB to the community. This has been a work in progress for sometime. While it does handle fracturing, it is primarily focused on structural destruction, meaning how an entire structure should react to a force. Not just how it should break.
The MOAB engine is built around Blast Code, a Maya destruction tool for film and games. Anyone familiar with Blast Code should immediately feel at home with the authoring process. While I did put together a simple game engine for demos, ideally it should be integrated alongside a more fully featured game engine such as Source, Unity or Unreal.
I wanted to start showing this to the community in order to get some feedback and find people who may find this tech useful and want to use it in their own games, or just want to be involved in the development.
Here are a few videos showing the engine in action. They are bit old, but should give a good idea where the tech is going:
Structure reset test:
I’ll be uploading more demos soon.
My current plan of attack is to release a demo game showcasing the f/x, and then find a way to get it ported to one of the commercial game engines so anyone can use it. But not being an artist, it’s been difficult to give the demo game the polish found in typical games today. My game engine is pretty rudimentary as well so it’s a struggle.
Any feedback or recommendations would be great. Would love to start a dialogue with anyone.
Thanks.
Helmar
PS. Want to put a shout out to the hosts of this site. Absolutely love it. It’s my go-to for anything involving real time fx. Has been super helpful.
Hey, this looks great. I am not familiar with Blast Code so could you tell something more about how this works? Is this pre-fractured or does it happen in realtime? What is the performance footprint? And what about dynamic sound and particle effects spawn events on collisions like here:
Fracturing occurs in real time with one exception:
There is stress fracturing for when the structure contorts excessively. This process uses a simplified version of the finite element method.
There is overlay fracturing, which allows artist created fracture maps to be applied at impact locations. Good example of this would be the cracking that would occur from a cannon ball impact. A fracture overlay is placed at the location of impact. This is nice because it allows for a lot of control over the crack pattern. Plate glass vs safety glass for example.
Then there is pre-fractured geometry. This is used for smaller detail objects that get glued to the main structure. For smaller geometry, there didn’t seem a need for fracturing in real time. Plus these models are typically more detailed, where a traditional solid fracturing algorithm would give poor results.
Performance is adjustable. Fracture resolution can be adjusted in game to match the computer performance. Adjustments can be made to both the CPU and GPU side of the f/x. On the CPU side it would be how much fracturing do I want, and on the GPU side it is how much debris do I want to draw.
When looking at just the destruction, I try to keep the frame rate around 50 FPS.
When it comes to sound and particle f/x, there are hooks everywhere. Most recently Ive been experimenting with bend speed and sound f/x pitch level.
I’m working on a blurb Ill post soon that describes the authoring process in more detail.
I’ve been actively putting the program through its paces and fine tuning the authoring process. Creating destructible assets can be very time consuming. Suddenly you have to consider all aspects of the structure and not just the outer facade. Creating and moving hundreds of individual rigid bodies around would be maddening so I’m trying to make the process as painless as possible. For example, I’m working on an auto rig routine that takes a mesh template as input and outputs a completely functional asset ready for import.
I’m creating a test game called DestuctoPod. This game is helping in the transition from prototype to release, and will let everyone try out the tech easily.
Keep it coming man, Unity is way overdue for a genuine stress-based fracture system(not the likes of the many faux fracture systems that merely cleanly break stuff off on some threshold impact, but rather the likes of Pixelux’s DMM)
I presume your system handles plastic/elastic deformation as well yes? That would make it an all-purpose physics engine.
