how can I use this so on a moving part such as a car if any hits or touches any destoryable part it voxelizes
You could create a moveable hitbox and weld it to the car
Appreciate the module, tried out Vex then realized I needed octree partitioning etc… and that the module wasn’t optimized and then realized your module exists with all of that already done, thanks.
Do you have an eta on when this update may be done? It will be vital for my game if I can get some better optimizations with this module
Hi hello first ever post in any forums but i have a question because when i use the destruction and lets say the vox size is 10 cause its a very big hitbox move some small parts Example a street light some parts of the street light is small and when i use the move on it, it doesnt regenerate fully some small parts doesnt get regen with it
Love your module, 10/10
yeah I get it, it happened to me too. A hitbox that covers an entire part at once will destroy it forever. Maybe later someone can find a fix later? (Probably never will happen though.)
Small update, I had put this project on hold because I genuinely felt no motivation to work on it, but recently I’ve been seeing some snippets of gameplay for Invincible related games on my social media feed and they all use some voxel based destruction systems, and that gave me a new idea for a game so I’ve gotten some motivation to work on this module again. Will resume progress tomorrow.
(Not sure If I’ve said this before but I was originally using this Module for a battlegrounds game which kinda got scope creeped to death, which is why the updates stopped.)
also I was not aware of this bug, you might have just saved me days of work
(Also if you’ve dm’ed me on discord asking for help with the module, sorry if I ignored you, I’m usually pretty busy so I forget to respond. I also don’t respond to people if you don’t clarify what you need first.)
By any chance, did you figure out a good way to replicate them whilst the voxel destruction is optimized? Jujutsu Shenanigans seems to be able to handle thousands of moving parts and it also replicates properly 100% of the time.
The way JJS does it is that it is all custom replication. Debris is at least to the best of my knowledge. That’s why there’s setting for its interpolation in JJS because it’s all replicated using non roblox replication. I’m pretty sure the actual parts that fill up holes and are anchored are made on the server using object cache. While debris is parented under a camera on the server so it doesn’t replicate then all those positions are sent to each client for them to interpolate their positions.
Yeah they do use custom replication, I was mainly bashing my head around why they would do that while at the same time doing physics on the server.
The camera thing might actually work though, essentially you would let the physics run and parent the debris to the camera on the server and do custom replication. Not sure what you mean by anchoring them on the server though since that would mean the clients would need to calculate the physics wouldn’t it?
I meant for the parts that are the voxels that help make the holes in parts. Those are the stationary parts while the debris is moving. Hence why you can handle the voxelization on the server and then just interpolate debris on the client for smoother results.
Not sure if I’m understanding the benefits of doing the camera trick. Parenting parts to the camera does stop them from being replicated, but the main issue is still that unanchored parts on the server are gonna be a problem for performance. Stopping them from being replicated won’t change that they’ll still be using processing power on the server. Now if your anchoring them then I guess this works but you’d get differing results across clients since your allowing the client to handle physics calculations. Not that that’s a bad thing, it’s just JJS has perfect replication across clients.
I’m pretty sure this is exactly what JJS does. Either way if you want to have debris synced and not lag with robloxs default replication custom is the way to go. And btw JJS definitely does not have perfect replication. I still have tons of encounters with huge parts covering half the map for only me.
Well I’m going to have to experiment with this, but the goal is perfect replication to avoid people floating on invisible parts. Though I’m not sure if that’s even possible.
What you proposed definetely works, just functionally I don’t see how there’s any benefit to putting debris under the camera rather than just firing the debris to the client and then destroying them/returning them to cache on the server. Additionally, wouldnt it be better to just create ALL your parts on the client, rather than just the debris.
When you do most of it client-side and you apply velocity to the voxelized parts, there’s a very high chance that the parts will not go to the same positions on each client.
There are also cases where you might want to have access to the positions on the server.