So I’ve noticed a game that has risen to popularity pretty explosively as of recent, being Jujutsu Shenanigans
And If you’ve played this game or even seen videos of it, it has some pretty impressive voxel destruction with little to no lag at all.
Here’s me testing out an ability and it just destroys a building with 0 hiccups.
(this one is a bit of a bad example since the parts are just being destroyed, but there are a lot of cases where you just blast through walls or floors and parts go flying.)
And so I’ve tried recreating something like it, but with little success:
(flashing lights warning for this video, they should be playing instantaneously but the lag is making them play incredibly slow)
The building in that video was made up of a few hundred parts:
And obviously, destroying hundreds of parts that have collisions at the same time is gonna lag like crazy, but I don’t know how else you could do this without lag.
The way I have it set up is that a hitbox detects parts with the attribute “Breakable” and then fires to the client to clone those parts and unanchor them, and after a certain delay they’re set back to normal.
But as you can see this doesn’t work with large scale destruction, so I’m a bit stumped here.
I think it’s a mix of both straight up making the parts invisible and unanchoring them with collisions. I’m noticing now if they just unanchored a whole building then yeah the game would probably explode, but they don’t. With larger attacks they just straight up make the parts invisible and with smaller ones they make the parts have collisions. Pretty interesting, and I’m gonna see if I can implement that.
Oh and, yeah thats not a health bar, its like a mana bar like you said.
ofc,
First:
Divide the hit parts into 8 pieces.
Second:
Divide the pieces of the part that are hit into 8 pieces.
Third:
Repeat Steps 1 and 2 until you reach the desired size.
Fourth:
Turn the final touching parts into 1 by 1 by 1 cubes.
Fifth:
Unanchor or destroy the cubes
Sixth:
Greedy Mesh the unaffected parts to lower the part counts.
If this is confusing try researching these topics:
Greedy Meshing
Octrees
Splitting Parts
So I’ve done a bit more research into it, mainly checking these posts:
And honestly I can’t really seem to figure it out. From what I understand you just divide the parts based around the contact point of choice, and then greedy mesh everything. The issue comes with actually dividing the part. From what I can find, there isn’t any explanation or tutorial on dividing a part around a contact point. You mentioned octrees, which I believe you are using here for that, but I have no idea on how those work, or how I would even implement them here. And most resources I can find on voxel destruction and the like are either entirely unoptimized or not at all what I’m looking for.
Thank you for the suggestions though, I would really like to figure this system out, as it is something that I find really cool and would like to implement into my own game, it just seems there is a lack of community resources based around voxel destruction.
It uses the Vex Module. But unfortunately it isn’t very optimized for larger parts. Meaning that when the “hitboxes” touch larger parts, much more parts are created than normal. But smaller parts work significantly better for performance. I’ve been unable to implement greedy meshing into it, as I can’t really find a simple “greedy mesh function” that fits my case.
Sorry for the late reply! For greedy meshing, I edited this module to be able to be used in my script.
Also, not sure about the lag, either make the voxels bigger or the hitboxes smaller. I’m attempting to optimize my system but I’m kind of lost on it as well.
VDP seems to have a pretty optimized system besides the flickering, I’m trying to get there but currently, I’m not. But it seems none of their weapons spam fire, even the laser gun looks like it’s constant but if you move your mouse quickly the destruction doesn’t keep up. Maybe for moves that have to constantly destroy parts you should just increase the voxel size. I’m sure there are other optimizations you can do under the hood though.
Thank you for the module! But after implementing it, seems like my performance is even worse now. This is mainly due to my one use case of using balls to go through parts, which fire every second meaning the part has to redivide and then remesh over and over again. If I used this for just one touch event like an explosion for example, the performance would likely be much better. Seems like the only way to do a sort of constant digging through one part with proper optimization is with octrees. Though once again, I have no idea how to use them.
Alright, the way my octree system works is by dividing the part into 8. After that, you now have 8 parts, you choose the ones currently inside your hitbox and divide each of them into 8. Now once again you choose the ones inside your hitbox and divide them by 8, you keep repeating this until you reach a size that you can divide the final parts into 1 by 1 by 1s or whatever size you wish.
I don’t think octrees will completely solve your problem either, it does prevent the creation of unnecessary voxels though.
Also yeah, the constant digging will likely cause performance issues. It still
I’m really bad at explaining things so apologies if you don’t understand.
I’m still searching for ways to improve performance. As shown by the flickering, also depending on your use case creating voxels on the server will most likely be your best bet, I quickly found issues because parts on each client are usually in a different spot for each player(standing on floating objects).
Thank you for the excellent explanation, I was able to use this to make something much more optimized, though still a bit flawed.
I’ve also been trying to incorporate greedy meshing into it, but it seems kind of redundant, as the majority of the lag is caused by instancing the parts rather than the parts existing in the workspace. And you would greedy mesh after the parts have been divided, so there is really no point in greedy meshing here as far as I’m aware.
One other thing, with parts that are uneven, when you divide them, they end up not looking like cubes, but just smaller versions of the original part. Which is obvious. Instead of just dividing the part, a better idea would be to divide the part into cubic shapes. Now how you’d go about doing this, I have no idea. But if anyone figures this out please let me know.
As for the odd part size, you could try finding the biggest number that can be divided into all 3 axes of a part. Effectively turning it into a bunch of cubes. However, I’m not sure how you could implement both octrees and this system. Maybe octrees aren’t necessary? Also, the smaller the voxels are the less noticeable this is.
I’m not so sure about the greedy meshing situation I’d imagine the fewer parts created the less laggy but it puts a lot of strain just to greedy mesh the parts. But if you plan on adding welding greedy meshing before you weld will reduce the strain on welding. Just depends it seems.
