I’m gonna try a few more methods, I’ll let ya’ll know if I can fully optimize this!
1 Like
You should try using that one part cache module that used BulkMoveTo, I think FastCache? So instead of creating new parts youre pulling and returning parts from the cache (faster because BulkMoveTo)
If that still is bad for low end, id try checking the microprofiler to see what exactly is the bottleneck, and optimize that.
1 Like
i think it’s ObjectCache
2 Likes
I tried objectcache but some voxels that were created with it ended up becoming nil for some reason
1 Like
you can try to, but parts will always just be parts and physics will be physics. i do know that jjs uses partcache (so maybe if you use objectcache, you might get even better results than jjs). but, one thing that jjs has over this module is i guess the algorithm for the voxelization, or maybe it’s greedy meshing. i’ll show an example of the algorithm of this module compared to how jjs’ destruction module does it
jjs has like more than half the part-count than voxbreaker and it kinda pains me to see this algorithm from voxbreaker because i use this myself personally 
and yes i did implement greedy meshing to the creator marketplace version of voxbreaker with the help of non-voxel greedy mesher and did it by just tagging the partTable in “CreateHitbox” with “Debris” and having the greedy mesh not mesh parts with the Debris tag. but the destruction after the mesh was so scuffed, that i gave up and didnt even try to fix it
4 Likes
same, i tried using objectcache too and it didnt work that well so i made my own instead
Just found this out recently but roblox just completely stops rendering parts in the workspace if theyre far enough away from the player. Meaning that if a part is far enough it will just return as nil in the workspace (though i believe this is only on the client). Ive had this problem with both ObjectCache and PartCache for a while where they would just randomly return nil parts and I think this is probably the issue. Though ObjectCache returns parts just fine sometimes, so its very strange.
1 Like
Doesn’t this just happen because of streaming enabled. Because as soon as the parts are far enough they are parented to nil. Also would explain why this only happens on the client and not the server.
1 Like
This sounds like something caused by instance streaming. Unfortunately, it is not a perfect system to work with yet. But, fortunately, there’s a few ways to fix nil instances. Just turn off StreamingEnabled under Workspace, or, if you prefer to keep it enabled, set every model you know you’ll use with the module to ModelStreamingMode.Persistent. This mode streams the models in and never streams them out.
Hey, I don’t seem to be able to get it to work anymore. Can you help?
How can i use this module in serverside and client side seperately. Basically i want to have 2 seperate hitboxes, one will be replicated to all client and inside server and one hitbox will be only shown to local player. I tried to create 2 seperate MoveableHitboxes one in ServerScriptService and one in StarterPlayerScripts but i got this cache error
“Attempted to return part “Part” (Workspace.VoxelHolder.Part) to the cache, but it’s not in-use! Did you call this on the wrong part?”
What should i do? should i use seperate caches for client and server? if so how can i do that and is vox breaker capable of that.
How do i make it so that the parts that were seperated from the original block get destroyed when the original block regenerates? Right now i can duplicate parts indefinitely by just breaking a part and waiting for it to regenerate