Now that Unity has level building tools built it does it have any destruction tools yet?

Way faster than Mono but it looks like it still has some work to compete with GCC and Clang in some algorithm types.

 

With the exception of fireflies (who cares?), Mandelbrot (not really a big deal either), and polynomials (valid), most of these are effectively neck and neck. Also this chart is really kinda useless without a labelled axis.

 

Even hollywood fake destruction anyway, practical effect are mostly done with pre cut model, so it retain artistic control. Most game don't actually resist the full destruction as gameplay thing, because YAGNI, crackdown 3 failed, the only example people quote is red faction mars, and it's cheating. Basically you generally don't need to cut mesh algorithmically, just swap module with "gibs", that's the way it's been done since lode runner, it's the best fun way, everything else is marketing.

 

I think this is a really niche request. Who wants real-time destruction and for what? If quality, realism is the goal, I would think a Houdini pre-computed simulation would look much better and perform on devices people actually use:

Demos like that always show a very simple test scene, and for good reason. The performance in a real game is just not worth it.

 

Cinemachine's path and dolly cart work very well for when you need an object following a spline.

 

Then your might as well be running your game on rails. Compare that with the potentially gameplay options of realistic physics damage to the environment, vehicles and even characters.

• Punching a hole through a wall/door to snipe through.
• Shooting an enemy in the foot to drop them so you can kill them.
• Taking down the leg of a tower to take out a sniper.
• Blow the supports of a building to block a road or trap a tank.
• Triggering a domino effect where a small obstacle knocks down a larger and larger one and complete a level.
• Damaging a road or railway track and derailing an entire train, truck or preventing an aircraft from taking off.

 

You can do this without dynamic destruction. I've done this with shaders and special meshes, which took far less computational power.

You can do this without dynamic destruction. This is just ragdolls and body part meshes, which take far less computational power.

You can do this without dynamic destruction as well. This is just the standard "model a box, shatter it in blender" method, but with standard physics applied, which is far less computational power.

This is the same as above but with different phrasing.

This can be done with the above methods. Nobody will notice that the shatter points are always the same because they'll never fall the exact same way since the physics aren't deterministic and the vast, vast majority of players won't even be paying attention.

Again, this can be accomplished with methods outlined above.

Game dev is smoke and mirrors. I've had to tell you this before, but our job is similar to that of a stage magician. We hide things, use distractions, play with line of sight. We don't saw an assistant in half and then sew them back together.

 

And you often really don't want a lot of those things to be truly or fully dynamic anyway. If a key moment in your game relies on a domino effect then do you really want to leave that to a dynamic simulation? Or, to state things differently... what benefit do you get from a dynamic simulation in the cases where you want to reliably reach the same outcome anyway?

The dynamic stuff is mostly of value if the variations tie into your gameplay.

 

So are you saying that every game created in 'Unity's main competitor' prior to the September 2019 release, the one that finally had a destruction engine in it, may as well have been on rails?

 

Fortnite
Battlefield 3
Just cause
Mario bros

 

Or it can provide a fun sandbox that allow the players to explore and play with less scripted gameplay.

 

We literally do that now. Using smoke and mirrors.

Why do you keep acting like games just don't exist?

 

And we used to use smoke and mirrors to mimic physics but now we tend to use physics engines. So why not adopt an optional destruction engine for Unity. Then their is an option to choose and use procedural destruction on some of the materials and objects in your game or not. Adding a procedural destruction component element to a game object the same way we add physics components to game elements.

Even for bigger effects if you could generate and record them in Unity in real time and see what they look like in your game, as opposed to having to work through a pipeline of tools each iteration. e.g. profiling and adjusting them for performance impacts. It could make for much faster iterations and an easier time for game developers.

 

Problem is, you are making conjoncture based on a flawed assumption, that physical destruction will allow for more phone. Problem is that hasn't been verified in x attempts with the latest one being crackdown 3. That is it's been proven to be an hindrance to fun, hence smoke and mirror, destruction physics have the following problem:
1- create chaos in navigation, it's easy to get stuck in random geometry rumble
2- flatten the level design to nothing, soon the level because as fun as an empty map
3- reduce the gameplay dynamics, once everything is destroyed there is nothing to play with.

Now some game DOES have some sort of solution to that:
1. minecraft and fortnite have non realistic destruction physics, using "gameplay metrics grid" unit as a coarse approximation allow to preserve navigation and the game playable in any configuration.
2. Minecraft and fortnite provide creation tools, so destruction is balanced by constructing from resources gathered in destruction.
3. Fortnite and red faction mars have indestructible elements, that allow for conservation of gameplay dynamics by having destruction as opportunities.

Plus you can mock a full fracture system quite "easily", use voxel geometry or module based level construction, "instantiate" physical gibs on destruction of voxel/module, flood fill the connectivity grid/graph to find stress point, break further the stress point into voxel/module chunk physicalized. Test level, if that's fun, do a proper 3D voronoi fracture system with mesh cutting.

 

Physics engines are also smoke and mirrors, champ.

 

I was thinking of the Battlefield style destruction, some of the structures remain and the terrain is designed to be a fun level with enough bumps and grooves to provide fun gameplay.

 

It's fake
https://battlefield.fandom.com/wiki/Destruction

It's a less visually cartoony version of the fortnite system, and simpler.

 

The thing is Battlefield has hundreds of developers, artists and deep pockets, so they can afford to do that. Indie developers can't. A tool and/or dynamic system in Unity could allow indie developers to add destruction to their games without needing to work harder or hire more artists.

 

If access to an affordable destruction system is so important to you, then why are you ignoring the fact that such systems are already available on the Asset Store for Indie-friendly prices.

https://assetstore.unity.com/?category=tools&q=destruction&orderBy=0

 

How many excuses are you going to make? I even told you ways you can pull this stuff off for free right now.

 

People have been making similar destruction system as indie game for a while now. It's not what's expensive in battlefield, thrust me. And the fluff that make it more realistic than fortnite is just basically particles, guess what Unity have 2 particles system for you to try, shuriken and full GPU VFX support which allow you to have physics interacting with gameplay (shuriken) and zillion smoke simulation (gpu).

Look sometimes unity miss some features, this ain't one of those.

 

Okay, so I'm going to necro this because I've seen it constantly popping up recently in other forums and here, is the first result in Google, as well as a comment I have concerning Havok in Unity.

tl;dr: There's no documentation for this stuff and @Arowx , most of what you want is already in Havok except for mesh/object deformation. Unity just hasn't implemented and documented things yet.

So first off, @Arowx :

This is how it's been done for as long as I've seen, even the Source Engine does this and this, along with the other Quake and GoldenEye-related engines, are the engines that gave Havok it's fame, for example Garry's Mod and Half-Life 2. Particle simulations (which is what full destruction turns into with 1k-10k+ gibs everywhere) is severely computationally and memory expensive.

The other problem is that game engines have no idea about where to split the textures for dynamic gibs, we can visually see this and imagine it but an engine cannot, the data isn't there so you need to add it manually. Also, textures are only 2D, applied to a 3D surface. What does the inside of a cube look like? You probably know, the engine does not.

Now with that out of the way, I think what a lot of people I've talked to want is a low man-hours solution to dynamic model destruction and terrain deformation. The only games that can do this easily are voxel games or low-poly terrain games because the limited resolution makes it easy to shatter the model dynamically (imagine a rocket blowing up a voxel wall and the cubes go flying everywhere), even for community-generated content. Deep Rock Galactic does this with the mining mechanic that allows you to form tunnels (deformation), Minecraft everyone know about.

For example, the Havok Deformation Demo is the model's mesh and colliders being deformed in real-time and building destruction results in a ton of physics interactable debris. People want this with a low man-hours requirement and feel like it's "natural" to have it handled by the same thing that handles collisions, force, pressure, knows the material type(?), etc. After all, metal is metal right? And this is how it works in real-life! (I know, I know, I'm not the who thinks it works like this in games, don't yell at me).

A compromising solution is you could have a system that allowed you to enter the object-model's material properties and then let the Physics engine handle mesh deformation only (Havok Destruction System is an example), this would of course have to be explicitly implemented in the objects of the prefab and would be off by default. This makes the process so much easier (technical knowledge-wise) to implement than to have to make a model deformation system yourself or work with an Asset not made for compatibility with ECS/Havok, which is very daunting to new developers [Unity's PhysX sucks, don't suggest it and the people who care about topic this don't care for the opinion of PhysX is fine]. You can actually use Pro Builder/Grids here to do the final construction of the gib model since it'll handle this fine if this was implemented into it.

In this demo,

, the individual entities (bridge pieces) that make up the bridge are the "gib-object" models physics-welded together in a sleep state and the explosion and following domino effect causes forces and torque that cause the "welds" to release/break. Can you honestly tell me with a straight face that someone who is relatively new to Game Dev is going to be able implement that in ECS or Havok with practically zero documentation? Some people can do it, most people can't.

What I think is needed is a properly documented workflow/process of time-efficient implementation of the generation of destructible and deformable content in Unity for the Havok engine. As it stands in Unity now, all of these things are poorly documented at best or undocumented at worst, go take a look at the plugin/package descriptions in the Unity docs and you'll see how piss-poor they are. If these features were documented, threads like these wouldn't be so prevalent.

 

I remember reading at some point that the developers on Red Faction: Guerilla had to get architects and/or engineers to teach them how to design buildings that wouldn't fall down when they implemented their full destrictibility. The issue wasn't that the physics system was hard to use, it was that designing structures with structural integrity is its own field of study that nobody on the team had experience with.

Edit:

So what I'm really saying is that, documentation aside, I'm an experienced game developer and I wouldn't expect myself to be able to do that. Not because of a lack of game dev experience, but because of a lack of bridge building experience. And I don't expect Unity or Havok to teach me that.

I could probably make a decent looking fake, though.

 

Point taken and I agree, understanding the theory behind it matters very much for design. My point was that even with that knowledge, you can't implement these things right now unless you are comfortable enough to dig around in the Native code for the Havok package and finding the functions for it .

Further on that point, while I agree that a large building or a bridge is a bit much, being able to make smaller things is also important. As an anecdote and not to brag, I have personally studied a decent bit of Uni physics & chemistry, hardware + software engineering, art & design, biology, etc. (I'm all over the place lol). The reason for this was I had goals and hobbies that compelled me to do it.

Creating an inaccessible barrier for things like this will reduce a lot of peoples' motivation to advance in this regard. New developers come to Unity because the community, resources and general workflow supports new developers and indie/small teams, that's why I think things like this really matter.