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.
do you know why the parts are copying other part size ? it becomes a lot more clearer when you set the part threshold to zero, the parts will copy another part size…
i figured it out
If anyone is down to help me make my system more like JJS, I’d much appreciate it, I’ve tried client sided destruction, server sided destruction and the same method but with the client rendering debris but all methods create a horrible amount of lag for lower end devices, if anyone is willing to help it’d mean a lot to me.
i think trying to make it not lag on lower end devices is gonna be hard
I’m gonna try a few more methods, I’ll let ya’ll know if I can fully optimize this!
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.
i think it’s ObjectCache
I tried objectcache but some voxels that were created with it ended up becoming nil for some reason
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
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.
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.
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?
