So yeah I took a look at a youtube vid and they seem to only turn on physics briefly if only a small portion of parts have been hit
Just check number of parts with region3 ig
Looks like some unanchoring action using a ontouch function
1 Like
please take a look at this message ^
this image is taken from my voxel destruction system and this began originally as a huge part until my system voxelized it:
4 Likes
So your system can divide one part into multiple? Could you direct me to how I could achieve something like that?
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
9 Likes
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.
2 Likes
I’ve been trying to figure this out myself and understand your pain. If I figure something I’ll come back here.
1 Like
So far this is the best I’ve been able to do:
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.
2 Likes
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.
1 Like
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.
1 Like
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).
External Media
1 Like
Thank you a lot. You’re advice helped me out. I need more optimizations but here are my results.
External Media
2 Likes
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.
2 Likes
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.
1 Like
keep dividing touching parts until it dimensions on x and z axis is equal to one or less ?
2x2 is probably better though
(ignoring y axis because it doesn’t have much problems with odd numbers)
Just use quadtree (i mean octree)partitioning to a small size, you’re not going to get perfect dimensions with any method unless you want to voxelize the whole part which would still give you the same effect just laggier. People aren’t gonna really notice it
edit: here is an example of octrees Dynamic Octree System - #9 by plasma_node
The question is: Why even destroy them? There’s a high chance you’ll regenerate those, so you should just turn off CanCollide and CanQuery, and set Transparency to 1, that allows u to detect if a part has been hit (by checking it’s transparency or any of the 3 properties), and allows easy regeneration; just setting back the values to their default.
phrehaps you should change this module so if the object that is destroyed is bigger the parts also become bigger and less.
I may be wrong about this but, from the examples i see on the module you linked, octree partitioning is basically the exact same as what i was already doing, which was diving the part into smaller parts, and continuously doing so for any parts touching the hit box until they reach a minimum size. In which case, i run into the same problem: Dividing uneven cuboids will result in rectangular voxels.
There’s nothing you can do for rectangular voxels (that i know of) except for dividing more so they are smaller, I’d reccomend avoiding non-cubes if you can and make sure the x and z axis are equal numbers.
My bad, I just realized the problem. https://www.youtube.com/watch?v=8AdcPD50aTQ