That’s what I used, its surprisingly fast although lots of cuts are being made with a moving hitbox. I assume that eat the world uses this as well, but instead of voxelizing the intersection theyre just returned, greedy meshed, and modelled/welded to create a chunk. And instead of using a single part to cut they use an algorithm to create some type of rectangular shape with a dampening float to get a random look, make it out of voxels then greedy mesh it, then they use that to cut intersections, the intersections are then greedy meshed and returned, welded to make a chunk.
It sort of works the same way but there are a decent amount of extra steps?
Its a very versatile algorithm.
my friend made a custom map in jjs with a big floor, compared to when u destroy a floor on the regular map and floor on his map his map is laggier jjs has no reason to not set their parts to 200 or under considering its a small map
Module now supports PartCache. From my tests, it has somewhat improved performance. It can be toggled in the module settings.
Bug Fixes
There was a bug where more parts would be created than necessary, which has now been fixed.
Minimum part size in some tests would not go below (5,5,5), I believe I have fixed this now, but let me know if the issue is still occuring.
Other
I have setup a github repository with the help of @FlikterIsLinked , you can access it here
I will be migrating the current algorithm of the module, which is quadtree partitioning, to a more optimized one in the future. So please be patient for that.
I believe this was fixed with a previous update, so could you share a video of what your seeing if possible? If your using the most up to date version of the module, then I believe the near instant flash of parts resetting may not always occur, and if it does then it’s likely due to ping or the client itself taking a moment to render the parts. In some cases this may be inevitable, especially if the original part your using is pretty large. But if it’s a significant issue, then it might be an oversight in the source code.
Using the up to date version of the module
Happens 100% of the time on my end, Is it relatively smooth on yours?
Ping range of 50-70
I’m using the module through a fireallclients event to create it on everyone’s client for smooth physics, module itself is not edited.
That being said I have an i5-7400 so maybe my cpu isn’t powerful enough to provide quick enough calculations?
My friends seem to have very few performance issues if any with this module and i haven’t tested it on another system since.
Yeah, I’m not sure if this is something that can be fixed. I’m going to try to tweak a few things in the module for a future update, but I don’t know if this can be fixed entirely. It does happen on my end, so it’s likely not entirely a hardware issue.
I believe its possible (Maybe thats ignorant because im just basing that off of jjs) my friend tried fixing it, this is what they said
“it was destroying the broken model before making the unbroken model visible again, leaving a split frame where there is no model visible”
" making the model appear before the broken model is destroyed makes it z-fight making the model appear and the broken model be destroyed at the exact same time causes a race condition where it works too soon and the unbroken model is made invisible again"
“I haven’t found what part of the code is making the model invisible again after the model is made visible when I made my change”
Also, Part Cache improves performance drastically on lower end systems, There are times where id break objects and the game would get very laggy all at once, this has been minimized.
And for a suggestion, maybe the ability to choose a mesh as a hitbox so we can have some complex shapes but i feel like the use case on that is limited, wanted to create some sort of circular hole but the ground you are standing on is untouched and my best first thought was just to make it a mesh hitbox with a hole in it using shapecast or something.
Something like this
or idk you could do
DEATH kanji carved into a wall after a huge dramatic attack or whatever
The name voxel breaker implies that destruction is voxelated, meaning it wont have any strong detail unless your voxels are very small. You wouldn’t be able to use a mesh with either my module or OP’s because of the way the math works, but eventually you’ll be able to use models of which you could make a shape like this and use that instead.
I’m so close to releasing my module, I just have an insane issue with part cache where sections of the wall are removed while part cache is active, once I fix this I’ll write a page for it and release it. If all goes well you could expect a feature like this within a week of release.
You are misunderstanding my intended application, I would us CSM for what you are talking about, i am just talking about a relative hitbox shape, the voxel would still be made of cube parts, but the parts deleted or affected will be in the shape of said hitbox
Fixed my modules horrible bug, part cache is now fully implemented. Decided before I release it I’m going to make your request a feature.
Do keep in mind though that more complicated shapes require all of the processes for a single hitbox part for every part in your model, you have a time and space complexity of O(n) and thats as best as it’ll get. Having more parts in your hitbox model will slow down the queue so destruction will trail behind high velocity models with large part counts.
I’m also going to release it with a randomized chunk generator so you can easily create a model to work with.
Hey i was testing out the new update and when I make hitboxes on the server there’s still a weird bug where you can see other things being destroyed? Was the bug fixed with the addition of part cache?
