When breaking stuff, there’s kind of like a glitch and you can see that other areas get destroyed for less than a second and it looks kinda weird, if you want i could send a vid. The issue doesnt happen in studio, just roblox
2 Likes
This is due to having to load in new parts as they are instanced, which sometimes results in some weird gaps since the clients machine is still rendering the part as its being created. This should be fixed once I successfully implement partcache into the module, which is coming soon.
2 Likes
If you create the hitbox on the client its very smooth. If you do make it on the client you can send the parts to server so others can see but idk if that’s optimal.
1 Like
How do you even make the voxels even smaller?
Please implement part cache in it. And if possible implement a good way for parts to be in the same position for everyone so it wouldn’t look weird.
Whats tripping me is that Jujustu Shenanigans seems to do everything on the server because when you join a server, all the voxels that were made before you join are there. And what makes it more obvious is the fact the voxels go in slow motion when there is alot of destruction which means the server is slowing down.
How does jjs make seemless destruction on the server? I havent been able to get around that annoying pause when making the voxels on the server.
btw look at a bug in my code did lol:
Yeah Jujustu Shenanigans does a really good job on voxel destruction. If only they’d release it.
1 Like
Its likely that partcache is heavily improving performance. and responding to @Z_irico , as I stated before, partcache is coming soon to the module with a few other changes.
Though, I cant say for sure if its just partcache thats making performance work so well for jjs, and speaking of that, jjs seems to be making use of the client in some way. If you look at the console on the client, you can pretty clearly see partcache being used, so im not entirely sure what tze is doing. Who knows if they’ll ever reveal their secrets
5 Likes
Hello again! I’ve been busy these past few weeks so I didn’t have time to help with this. I have some time now to help you. I’ve sent you a friend request on another chatting platform as I believe it’s more convenient to communicate there.
1 Like
Thanks, but im currently travelling. Ill be back home tomorrow so ill respond then, and ill get to working on updates to the module.
1 Like
maybe jjs builds their map without going above 200 studs for the size on parts because i tested vox breaker on a part with the size as 200 vs 300 vs 500 vs 1k vs 2k studs and 200 was the most optimized (minimum size was 5 on vox breaker)
JJS uses part cache to reduce instancing parts, not sure if they do greedy meshing as well but I’m certain they also use voxel size relative to the hitbox size. All of these reduce part count drastically, without this the physics handling of new parts would cause a jump in part instancing.
That being said, the best way to ensure you see parts created quickly is to reduce the amount of physics the server handles is to use a combination of greedy meshing, part cache, and relative voxel size (and obviously keep the amount of collisions to a minimum somehow, not going overboard with huge explosions?) and it should work well if the module you’re using isn’t the cause of the delay.
JJS’ larger collisions like sukuna’s flame arrow don’t create debris, I suspect they don’t use quadtree but just slice parts and return an intersection, that way they can just destroy the intersection without voxelizing it, not sure if OP’s module has this capability as quadtree’s part count is relatively high without meshing. This is another way to reduce part count.
It isn’t so much that JJS has a more efficient method, its just that they do a good job at minimizing the physics requirement, regardless of what module you use and what methods they have of voxelizing just aggressively focus on reducing part count and your game will run just fine.
For my game I simply delete all the voxels if the explosion has a radius bigger than 50. Although I might actual look into using the new csg api because the part count does get a bit crazy.
I also thought about just giving a table of voxels from someone else’s client to someone who just joined so they can see all the debris aswell.
And for smaller explosions, this module works just fine even with alot of them.
2 Likes
They minimize part count to reduce lag, size is irrelevant unless the sizes you set are egregious and unnecessary. Read my prior reply to see what they do focus on to reduce lag.
Size of parts directly correlates to the physics requirement they have as if they have a bigger size they interact with more parts around them. Larger parts affect touching events, gravity, bounding box methods, collisions, and mass for all of the parts in or around it.
Even though size has an effect on lag size isn’t a significant cause of lag unless its coupled with high part count, I doubt you’d ever need to use voxel destruction on very large parts in the first place and even if you would I’d advise against it.
Oh, I should have clarified what I meant by greedy meshing. CSG isn’t highly optimized yet and it actually uses more memory than just parts standalone because it uses all of the parts which made it for its physics detection, the math included to create a not cuboid collision surface is heavy on physics. The memory use in relation to the part count used to make it isn’t even linear, it would be exponential for what we are trying to accomplish.
Even if CSG were more optimized it still wouldn’t be the best way to reduce count, go with greedy meshing for sure- it was intended specifically for voxel destruction and for this purpose! I’m close to being finished with a pretty effective module to have voxel destruction with minimized part count for this reason exactly so if I don’t reply soon with that just wait till OP included it in his work.
(Edit) Now that I think about it, CSGs surface used for collisions is stored in memory so the math isn’t recreated every time collisions are made but the biggest problem is the way that CSG drastically increases triangle count.
Yea I feel like this module needs some sort of greedy meshing since the quadtree really slows down to a crawl when demanding bigger hitboxes.
An explosion with a radius of 10 - 40 is instant but when pushing it to something like the hollow nuke in jjs, it takes about half a second (while increasing hitbox size):
1 Like
Im currently looking into different splitting algorithms, particularly the one used in jjs. If the part count is reduced then i will be updating the module to use that algorithm.
And ill try and implement greedy meshing some way if possible.
I’m not aware of the one that JJS used but it might be similar to mine, the one I went for wasnt a well known algorithm because it doesnt really have a name? its just slicing along faces of parts and its meant for minimizing part count.
It was a splitting algorithm from egomoose. What I first did was get a bounding box oriented with the wall positioned at the hitbox part, then this bounding box was split on all sides so at most there would be 7 parts, one per side only when needed though. I’d eventually end up with a bunch of parts as well as an intersection part, the intersection of the wall with the bounding box we made. I would voxelize the intersections (if you dont voxelize them they just get returned) and then get the voxels touching the hitbox, and make a hole. Then i would greedy mesh the leftover voxels and the wall pieces.
Thats at least how I did it, there were so many caveats and it took weeks honestly but its working amazingly, I wanted to make it a resource but I want to add more features to it before I do, as well as optimize it as much as possible and add part cache.
It has some very nice features already, I made a function queue so if you try to destroy a wall it will queue and run when possible, this way you wouldnt be able to destroy parts that are being cut or greedy meshed. I’ll release it soon or I can send you some methods if you need help implementing this algorithm.
1 Like
Seems like you have a solid implementation there. I can’t really visualize it from your description, so it’s kind of hard for me to get what you mean, but this post:
It suggested to use an algorithm that looks like the image, which is allegedly what jjs uses. I might use this one.
Also, I’m considering adding a setting to decide what algorithm the module uses. In some cases you get entirely visually different results. Someone messaged me about a rectangular voxel algorithm like the one in eat the world, and I thought it might be interesting to include different algorithms than just the normal cubic voxels.