Want to recreate Teardown, destructable voxel physics

Lets take a concrete tower building as an example. I was thinking about having a dynamic parent (invisible) with dynamic suports as child (invisible). Then attach destructable voxel layers (visible) as child of the dynamic parent within a collider, surrounding the corresponding suport. The destructable voxel layer will be destroyed based on type of impact and type of material. For example group voxels together, in a random pattern, based on distance from explosion impact. Smaller groups closer to to impact. When collider surrounding voxel layer is hit from explosion spherecast, it will count number of voxels left in layer. If, lets say less then 1/3 of the voxels remains after impact the suport will simply disapear. When the building falls over it will have some additional damage. I was thinking about adding some sort of destruction outwards from suports where the rotation is happening, when building is falling over. Also some sort of destruction outwards from collider hitting another collider, ground, when building smash to ground. I was thinking about having a collider surrounding the entire building to switch structure from static to dynamic when it is active, to make game perform better. Is this how it is done?

 

This is mostly a question of efficiency. What seems different here from other voxel games is the attempt to add some physics simulation to it. For that id "simply" add a structural integrity value to each voxel. When some voxels take damage or a collision occurs, recalculate the structural integrity of relevant neighboring voxels (based on some arbitrary criterias) and check if this leads to their destruction due to stress. If a mesh is separated from the groundmesh, it needs to become its own object, including being physics simulated. All of which needs to happen in realtime, of course.

The rest should work more or less on its own now. But getting to that point requires heavy optimizations. Voxel games in general are pretty performance reliant. Any half-decent one will already make good use of multithreading and other optimizations.This adds more complexity on top of it.
That does however assume you also want the world to have the usual voxel world features, like being procedurally generated, infinite, houses being buildable and so on. If you just want to destroy a finite, prebuild scene, then you can get away with less complexity. If players building houses themselves is not a requirement, you could even get away from a voxel-based approach entirely and puzzle the houses together from other predefined shapes which you physics-simulate according to some arbitrary rules when they take damage.

In the end it depends on what exactly you are trying to do. If you are trying to 1:1 recreate the game, then you should look up 1:1 how exactly that specific game was made. I only glimpsed over the video, but from what the narrator says, this game specifically seems to use a raymarching/tracing approach for rendering the underlaying voxel world, which is physical simulated. But i can guarantee you that there are a truckload of optimizations involved.
This is a highly advanced topic, so it depends on your dedication and knowledge first and foremost.

Edit: Later on the video there is some information about performance. Which may give you an impression about how heavy these calculations are.

 

Maybe I will understand it if I studdy raymarching and tracing, but it seems to be more used for shaders and lightning not physics. I cant understand how the voxels can be grouped together and create a new destructable objects after an explosion.

 

From the bit i watched it seemed like they march through the underlying data structure to visualize the voxels. Theoretically you could do the entire thing on the GPU tho, if you wanted.

I personally never created movable objects from voxels and so far worked mostly with grids for terrain. However, when the voxel data changes (ie through destruction) you then check if it is still in one piece, and if not you create a physically simulated object from the separated piece. Ie, making it its own mesh with its own collider and physics. If you want to keep it further-destructible you will also need to keep track of the the voxel data of the separated object separately from the ground mesh. At least thats how i would approach it.

 

Ok, I will try to understand this, but I'm new to raymarching. I just watched an example on how it was possible to visualize a rotating cone within a square object using raymarching. This is what I immagine shadergraph would be able to do, but I can't see how this would be related to physics.

I was thinking about studying something like this asset, see link below. Then try to make it work for voxels. I would then try to make each separate part part from the destruction as a child of the main object and when physical velocity is low, grounded, I would unchild it and make it a seperate destructible object? Watching some of the other Teardown movies I can see that the objects falling to ground are made static after a while due to physical movement if it is stuck in a weird angle. Does this mean that we can assume all objects are static then switch to dynamic right before impact or can the invisible parent be static with dynamic components?

https://assetstore.unity.com/packages/3d/props/fragmented-objects-25699

 

Also I think the object is reduced in size after each impact so if the object is hit enough times it will disappear. I'm not sure if this is relevant or just something he added to reduce remains on the ground

 

I thought i made this clear. The raymarching / raytracing is only for visualization purposes. This is usually used for volumetric data. Clouds, fog, shapes you want to melt together.. and here for voxels, but the idea is similar. So dont worry too much about the raymarching part for now.

The underlying data structure is what defines the world and objects. If you are not familiar with voxels, start with something more simple and approach your goal from there. Create, for example, a world with layered perlin noise and visualize it with the marching cubes algorithm. Now you have an underlying data structure defining the shape of things, and an algorithm to visualize it. Like all voxel games do. Next, get to the point of being able to edit the underlying data structure and re-render the world / chunks to apply the change. Now you can add or remove parts of the world.
The next step is to check whether stuff gets disconnected when editing. This is the step where you then make sure to prevent "floating islands" from existing. How you do that is up to you. As i mentioned, id likely calculate a structural integrity value for each relevant voxel, which can be based on its material, damage, .. and so on. How you handle the objects after you decided to separate them is something to worry about now, not earlier. First get to that point.
Id likely not do any parenting and just apply general physics to the broken-off part, based on gravity and potentially the force that separated it. The rest would be handled by the physics engine. If things get broken off by the same force, theyd already fly in the correct directions. But again, this is the one part that is mostly up to game design. Do what works. But first get there.
I feel a bit like you are skipping over all the actually hard parts, and worry about the best way to apply physics after that is done, or when to make separated objects static or not. Those are optimizations.

The asset itself says "pre fragmented objects". Meaning the objects are already puzzled together by predefined pieces. The asset just breaks the correct pieces off depending on where it is hit, or how strong. That is more or less what i meant when i wrote above that, if you are only interrested in destruction itself, you could build your world from pre defined pieces instead of using actual voxels for everything.

All of which would be handled by the underlying data you edit when the voxels take damage. At which point you would re-render the mesh and recreate or reshape the collider. I can only again recommend to get some experience with voxels in general first.

 

Ok, I try to find relevant material to studdy, but I cant find much. I guess this means that he has a custom voxel editing tool within the engine since he needs a seperate layer for each voxel with a collider and jont on each side of the qube

I found this, but its not enough to get me started

 

It is a highly advanced topic, what do you expect?
What really helped me when i first implemented marching cubes was this: http://paulbourke.net/geometry/polygonise/

To understand the general idea, Sebastian Lague did a nice visualization of the algorithm in his related video.

But the effort you have to put in to chew through this topic and make sense of it, cant come from anybody other than you. There are some open-source implementations you will find on the net. Im not sure how much help they would be tho, as this is mostly an exercise for understanding the basics involved in what you are actually trying to do, which is yet a step above this. So having a good understanding of how things work is important when approaching a topic that builds on them.

 

Ok, I'll have a look and see if marching cubes makes more sense. I was thinking about trying to make a procedural-random-mesh destroy script, like the one used in the video below. Make the script slice along edges of voxels. First slice mesh into pieces that will come loose from original mesh after impact, then slice the pieces, that will come loose, into shattering parts that will fall to the ground, then recalculate the volume of the remaining original mesh and continue as described in the beginning, removing support if less then 1/3 of mesh is remaining.

https://gist.github.com/ditzel/73f4d1c9028cc3477bb921974f84ed56

 

That is mesh cutting. Also pretty advanced, but has little to nothing to do with voxels. When you have voxels you dont need this. If you just want to cut / destroy a mesh, then asking how to reproduce Teardown wasnt exactly the right approach. In the end it comes down to what exactly you want to do, and what that requires you to implement.
Right now it rather seems like you are throwing random topics into the discussion. So make sure you yourself know what it is you want to achieve. Then look up specifically what you need for that. And most importantly; start doing something to collect actual experience. If you first decide to experiment around with something like mesh cutting, you will aquire meaningful knowledge about handling and editing meshes in general, which will help you approach your actual goal, even if mesh cutting itself turns out to be the wrong approach for you.

 

Ok, I was just trying another approach to reach the same goal. Visually you won't be able to tell if I am using mesh cutting or marching cubes, if I am able to slice the mesh along the voxel edges and find an algorithm that slice and add forces to the pieces realistically? I can keep the mesh kinematic, then add forces and dynamic rigid body to pieces that fall off. I was just thinking about a way to cheat and get somewhat the same results. I want voxels because it is possible to create good looking level design, animations and VFX as a solo developer in shorter time, more effective. In the end his physics is also simulated and not realistic. Or maybe he is actually applying forces to each corner node of each voxel using finite element calculations, used in advanced engineering softwares. But I highly doubt this since this would require a lot of data and would not update each frame with above 30 fps, I think

 

Voxels are in no way a "good and simple way" to approach anything, especially as a solo dev. You only use voxels when there are no other ways of approaching something or they are vital for your game mechanics. Even AAA studios don't use voxels. As a matter of fact, I can pretty much only name 1 AAA game that uses voxels in any way and that would be No Man's Sky (Also maybe Space Engineers, not sure if it's AAA though). Those two use it because it's at the very core of their gameplay. There are tons upon tons of things to consider when making a voxel engine. How do you store the voxel data? a 2048x2048x2048 voxel area (if we assume that each voxel hold 4 bytes of into in it) would already take 34 GIGABYTES of storage. What about rendering? You can use ray marching, which is hella hard. You can also just generate the mesh itself, but it's super slow on the CPU and will hold up the main thread, so you either need to multithread it or make a compute shader. Oh, and that all needs to run in parallel. What about structural stability system? Sparse voxel octrees? How are you even going to generate the large volumes of voxels anyway? LOD System? Are you using marching cubes, regular voxel meshing, or ray marching? Also, you can't make animations with voxels. Bad idea. Those are just some things to consider while making a voxel engine and it scales with difficulty the smaller the voxels are, obviously.

 

While i definitely agree that voxel based games are nothing a beginner should attempt, you are making things seem unnecessarily complicated imho.
Unless you talk about planets, noone will render something 2048 voxels high. Take minecraft for example, a chunk is 256 in height if i remember right. You also would never attempt to just store every value. Why would you? You can just regenerate the data when needed. Unless of course, the user (or other systems) altered the chunk in some way. And that's what you save. Nothing else. There you go, a couple MB savegame, maybe a couple hundred.
Having implemented both, i dont think ray marching is harder than marching cubes. Actually, implementing a performant version of marching cubes in DOTS took me several times longer, which to be fair may be because of the bad / lack of DOTS documentation.
The thing is, usually you want the mesh. So ray marching - for anything other than visual effects - is not really something you have to consider. I used it for clouds, which would be a perfect visual-only example for where ray-marching is applicable. Even then it eats up tons of performance. Getting collisions to work on raymarched data.. it's pretty math'y. I only know of one game that did that, and that's marble marcher. Which despite the super simple gameplay barely runs well.
So yeah, you will want to generate the mesh. CPU or GPU is both possible, and id say it depends on what else you run on the same processor. If the game is gonna have simple graphics, GPU will be faster. If you need the GPU for something else, go with the CPU.
And sure, of course you will have to multithread it to run well. That's just part of the complexity of the topic, but done right the performance can be great. Just as a reference, my experimental DOTS marching cubes implementation was able to calculate 2 chunks per frame, iirc that was 3-7ms per chunk (32*32*64 voxels, including everything from noise to rendering, uvs, .. tho i didnt put textures and the noise could be more complex, but you could also further optimize it all).
Structural stability is something i'd consider an entirely different topic, so i dont know why you would throw it into the mix. Only a tiny fraction of voxel based games implements structural integrity, so the average reader wont.

Bad idea? Maybe. But cant? I wouldnt use it as a go-to tool for animations, but i actually thought about a boss-fight where the boss was literally the terrain itself, moving. You could check where the voxels are inside the "boss model" and simply set those on, then re-render the chunk(s) in question. Animate the model, the voxels do the rest. With the above described performance, this would easily run in realtime. If run on the GPU it would be far faster still.

In the end voxels are a highly advanced topic. I would not recommend it to beginners. And at the very least you should have a good understanding of multithreading and be able to implement complex algorithms directly from scientific articles or papers. If you fulfill that, pretty much nothing should stop you. The percentage of people who do is pretty slim, but overcomplicating the topic doesnt help either

 

Hi,

I created a unity package for Voxel destruction, maybe it helps you: https://assetstore.unity.com/packages/tools/physics/voxel-destruction-237943