Return to “Suggestions”

Post

Re: Dynamic Destruction

#16
BFett wrote:
Sun Aug 13, 2017 2:53 pm
How difficult is it to check that all the pieces are connected? Other games have done that to some degree anyways.
you have to individually check if theres connections from all elements (voxels, vertices, whatever the fundamental unit is). And the amount of checks rises exponentially with the number of elements to check
Something in the order of n! (I cant find the correct expression right now)
You can do a lot with preparing your connecting graph properly or flood fills but its still computationally very expensive.

Space engineers does it and lags noticeably when its doing it on anything above a medium sized ship.
(Like at block destructions or block construction when it recalculates airtightness when you enable that)

From the depths limits the total amount of blocks present in a scene and does such checks spread out over a few seconds during which the ship graphics are wrong and disconnected elements remain "connected"

Avorion does basically the same as ftd but without limiting the number of elements in a scene. But it perf degrades noticeably anyway with more/larger ships present.

Starmade ignores the issue completely and allows floating connections.

And i think it'd be a lot harder for SDFs which dont have discrete nodes you can iterate through for the continuity check
Post

Re: Dynamic Destruction

#17
To have the ability to damage part of a ship (and that must not be physically correct in such a game) sounds a lot like deformation in a car-racing game.
And that can be precalculated for each ship model, and thus does not need to have to be done in real time. (same goes for hitboxes),

The ship can be separated into sections at generation, wich have different grades of destruction. The seams between sections keep constant. When a section is damaged, the rendered model gets updated with the damaged part receiving a new polygon mesh / texture uv.
Additionally, outside modules / doodats could be shot of.

So, as long as the goal is not a physically correct damage model, and just the ability to damage specific parts of it, its not wizardry to implement in a perfomant manner, as the deformation stages can be precalculated.

And even in a scene with hundreds of ships in a battle, the majority of them would be at such a distance, that their detail damage can be ignored, and just the low lod model is displayed.

A destroyed ship (broken apart) is then using a separate new model / chunks of debris.

---

The skill of the AI to target and hit specific parts of a ship is something that can be tuned up and down at will. Data can be drawn from letting a human play a set of dogfights, to see how hard it is to target a specific part. To gather some statistics on specific situations. Then you could just alter the AIs ability (time to track the target area and accuracy / random offset) to match that of a decent player to get a more fair AI pilot.
Post

Re: Dynamic Destruction

#19
Cornflakes_91 wrote:
Mon Aug 14, 2017 5:25 pm
That would work.
If the goal wasnt
S46 wrote:
Sat Aug 12, 2017 5:44 am
rip ships in half with strong lasers!
Just generic indents on the hull are comparatively easy.
Cutting into/apart ships along precise enough borders isnt
Yep I agree, thanks for the explanation Cornflakes. I'd be perfectly happy with race car level damage in LT without cutting ships into little bits and pieces. Let's leave that feature for LT3.0
Image
Post

Re: Dynamic Destruction

#20
Cutting into/apart ships along precise enough borders isnt
Well a precise cut at the laser-hit might not be nessecary. (its not a "welding game")
But a precalculated model that is split in half would be a lot of gameplay fun.

Like having different shipwreck endmodels:
-cut in half
-cockpit blown out (crew dead)
-completely ripped into chunks (big explosion)
-big holes in the hull (rapit decompression)
-burned out (internal explosion, but frame is intact)
Post

Re: Dynamic Destruction

#21
Damocles wrote:
Tue Aug 15, 2017 4:00 am
Well a precise cut at the laser-hit might not be nessecary. (its not a "welding game")
it would be very statisfying to see a gouge in a ship along the path where you just dragged your laser across, though :lol:

i wonder if just adding deformations/displacements on the surface without any topology changes for deflection/hit marks would be particularily hard/perf intensive
Post

Re: Dynamic Destruction

#22
Damocles - this is a lot more feasible than pieces flying off, and I think it'd be really cool to see, so for that, I'm totally on board. Hopefully S42 likes the idea as well?

Cornflakes - I wouldn't think preset model changes would do too much. There couldn't be many changes - it would basically have to be just a handful of separate models that get swapped in and out depending on how much the ship is damaged, if we wanted it to play nice with framerate... but it could be enough to make it more interesting. For capital ships it would probably look odd, though... :thinking:
Have a question? Send me a PM! || I have a Patreon page up for REKT now! || People talking in IRC over the past two hours: Image
Image
Image
Post

Re: Dynamic Destruction

#23
Talvieno wrote:
Tue Aug 15, 2017 8:11 am
Cornflakes - I wouldn't think preset model changes would do too much. There couldn't be many changes - it would basically have to be just a handful of separate models that get swapped in and out depending on how much the ship is damaged, if we wanted it to play nice with framerate... but it could be enough to make it more interesting. For capital ships it would probably look odd, though... :thinking:
my last point is about dynamic changes to the model, not predefined ones.
but its about minor changes on the surface, not significant changes through the volume or even topology changes (cutting stuff off).

like impact/deflection marks on the hull.
where, say, a laser cut across the hull theres a small glowy indent along the path.

and the question is how expensive would "small" changes be when you dont have to think about topology changes which you can still include in the collision mesh on large ships.
so that when a particularily large ship hit by a particularily large cannon maybe has a large enough gouge in its hull that you can fly into that gouge with a particularily small fighter.
Post

Re: Dynamic Destruction

#25
Cornflakes_91 wrote:
Tue Aug 15, 2017 8:43 am
my last point is about dynamic changes to the model, not predefined ones.
but its about minor changes on the surface, not significant changes through the volume or even topology changes (cutting stuff off).

like impact/deflection marks on the hull.
where, say, a laser cut across the hull theres a small glowy indent along the path.

and the question is how expensive would "small" changes be when you dont have to think about topology changes which you can still include in the collision mesh on large ships.
so that when a particularily large ship hit by a particularily large cannon maybe has a large enough gouge in its hull that you can fly into that gouge with a particularily small fighter.
pre-edit: This is not just to you, so apologies if I'm explaining things you already know. Not meaning to sound patronizing

This varies entirely depending on how much deformation you want. Due to the way polygons are likely to exist after the remeshing/optimization process, you might be able to get away with deforming corners. Otherwise you're going to have to re-mesh the whole thing, and then re-optimize. If you just want a couple dents, that shouldn't be too much more difficult than adding a few extra vertices and denting them in slightly. This could look weird in many instances, though, so it would have to be controlled - you'd need to know the thickness of the surface so you weren't accidentally denting something through to the other side. (And if you were, and you wanted that to be a hole, then you have even more math you're going to be dealing with.) However, that's on the simple side of things, because we're only dealing with a handful of points. If, however, you want a long, glowing gash across a ship... well, then, that will be probably hundreds (if not thousands) of new vertices, and a great many calculations to the point that you're basically doing another geometry subtraction algorithm like with the chunk idea - minus the added floating chunk, of course. That's still a significant amount, though, and if we want to extend that to hundreds of lasers from dozens of ships, we can expect significant slowdown (if not a sudden crawl).

As to the gouge, that's essentially the same chunk extraction method, minus the floating chunk, same as the laser gash. If you want to fly into that gouge, you have even more calculations incoming. If you want that gouge to look like the inside of the ship (decks, rooms, etc) instead of a flat-sided hole, then you can expect so many calculations that it almost certainly wouldn't be feasible for anything other than a pre-rendered movie. :P

Now, something you didn't mention: Slicing ships completely in half. This is almost certainly feasible, because slicing meshes across a solid plane is actually incredibly easy. All you have to do is find the lines that intersect a plane, add vertices, detach, and cap the ends. That's it. The textures on the end might look a bit odd, but it's probably the simplest destruction method you could possibly do. :P And seeing as you'd only see it on destroyed ships, it probably wouldn't take too much processing time either.

post-edit:
N810 wrote:
Tue Aug 15, 2017 9:00 am
Perhaps just some primitive particle effects and some smoke,
and maybe like a texture patch to show the burnt/damaged hull ?
I'm hoping Josh at least does this. :P I'm sure he'll do particle effects. Smoke? Maybe. Texture patches? Hopefully he'll at least do that, it's always nice to see some effect of the damage you're dealing visually. :lol: But all of the things you mentioned are very simple and not very taxing, so completely on the table.
Have a question? Send me a PM! || I have a Patreon page up for REKT now! || People talking in IRC over the past two hours: Image
Image
Image
Post

Re: Dynamic Destruction

#26
Talvieno wrote:
Tue Aug 15, 2017 9:03 am
Now, something you didn't mention: Slicing ships completely in half. This is almost certainly feasible, because slicing meshes across a solid plane is actually incredibly easy. All you have to do is find the lines that intersect a plane, add vertices, detach, and cap the ends. That's it. The textures on the end might look a bit odd, but it's probably the simplest destruction method you could possibly do. :P And seeing as you'd only see it on destroyed ships, it probably wouldn't take too much processing time either.
that assumes perfect, instant, 0 width cuts, though. and not some wavering cut with some given thickness done over multiple passes with multiple different weapons.

and the changes im thinking about are to be "small" vs the structure of the hit object (some low percentage of the smallest box dimension)
and i wonder if the removal of a lot of generalisations one would have to make for full deformations increases the efficiency enough that such things can be included.
(only having to look at a small part of the model for reoptimisation for example, or the lack of topology changes etc)

with something similar to a displacement mapped decal system.
Post

Re: Dynamic Destruction

#27
I know. If you want anything other than instant cuts, you're gonna have a bad time. Cuts over time would likely be harder on the framerate than even just "chunking it". I don't think it's really a possibility, because now you're multiplying all those impact craters by game time, which is probably well over what Josh's engine could handle, even if you're only dealing with, say, 25 ships shooting each other. He could do a engine rewrite (again, taking up another one to four years), but even then, we'd almost certainly lose the ability to see a few hundred ships flying around at once. A projection system might work, for instance - if it works by simulating edges by "projecting" from areas at certain points and "welding" the areas together - but that would necessitate either black magic coding, a low framerate, or a low number of ships. :ghost:

If you want to do a bumpmapped decal system, that's a possibility... :think: I mean, it isn't that hard to just gen a bumpmap and paste it over a "cut" area, and then paste on a glow map. It would accomplish, essentially, exactly what you're wanting to do. It might even be possible through Josh's Lua code. It wouldn't actually be physically 3d, but... hey, laser gashes :) That's what they do in most games anyway.
Have a question? Send me a PM! || I have a Patreon page up for REKT now! || People talking in IRC over the past two hours: Image
Image
Image
Post

Re: Dynamic Destruction

#29
If you say "computationally cheap", you're thinking of normal maps. They have more definition than bump maps, although less definition than a displacement map. In short, bump maps contain height information, normal maps contain height and angle information. Neither of them change the actual geometry of an object - just how light reflects off of surfaces. It makes it appear as though there are bumps in an otherwise flat surface. Naturally, they work best on... well, flat surfaces. :P

If you do actually mean displacement maps... those change the actual physical geometry of the object (like you said) and are typically far too expensive to use in games not explicitly designed for them (and even then, typically only on flat surfaces), for several reasons. First, they change the actual physical geometry of an object. :ghost: Second, because they work by moving vertices around, they need a large number of them - and thus a VERY! high polycount - a vertex per pixel, essentially. High poly counts aren't good for if you want a fast game, so we'd have to optimize everything back out after each hit - which would get messy fast and lead to glitches fairly rapidly unless we want to smooth it out again every time, at least enough that the subsequent hits don't break it. It's not quite as expensive as chunking, but it's getting there, and has a much higher chance of breaking things than chunking does. Actually, at that point, you might as well use chunking because the reoptimization process basically destroys any gain you might be getting, and you lose the ability to put gashes/craters reliably across non-flat surfaces (say, greebles). (That, and mapping that sort of thing across greebles would be unbelievably glitch-prone.
Have a question? Send me a PM! || I have a Patreon page up for REKT now! || People talking in IRC over the past two hours: Image
Image
Image
Post

Re: Dynamic Destruction

#30
i didnt say "cheap" i said "cheap enough" :ghost:

and theres ways to increase polygon density for graphical purposes that doesnt affect anything but the rendering side
see tesselation which has been hardware supported in all gpus built after 2009 (amd 5xxx and nvidia 4xx series and upwards)
that may wasnt sensible to include when LT was kickstarted (when it was only 2-3 years old) but its now as the cards that dont support it are all but scrap by now.

edit: with the dedicated hardware it seems to have pretty secondary effects on framerate according to tests by gamersnexus on GTAV.
its only from one game though and may not representative
http://www.gamersnexus.net/guides/1936- ... e-graphics

Online Now

Users browsing this forum: No registered users and 2 guests

cron