I would like to create a system in where any part that intersects with hitboxes, will be split based around them. This means that whenever a hitbox intersects with a valid part, the part will be divided continuously until there are enough parts of a minimum preset size in the area that the hitbox is touching. Then I can choose to either destroy the parts or unanchor them.
You can reduce the bigger block into four parts when the hitbox (red box) lands and then recreate the intersection as a part (the “5th part”) that has the same size as the hitbox but matches the dimensions of that intersection (i.e. notice the red box’s Y value for example would be the Y of the new size). I suppose a possible way to get the “longer” dimension that you would need to actually change is by seeing what side of the part the hitbox touches. You could do like a table for each side of the cube that way. For example, if the box intersects with the front face of the cube which is along the Z-axis, then you simply resize the Z and keep the rest of the intersection cube’s size coordinates for your new cube size.
Notice that it is arbitrary how you make the four blocks. It won’t matter because the greedy meshing will do it the same wherever you position/size them. Why does the position/size vary? Well, the blue block could have been as tall as the big block then the green block would be a tad smaller than in the image. That’s a different configuration but the greedy meshing is going to be the same in runtime complexity (it’s 4 blocks, not any different).
Then, you could probably greedy mesh after all is said and done.
Given, I did not implement this so be aware of your own implementation. Knowing what greedy meshing is a separate problem from this thread. One thing, from the images: if you just want to subdivide it evenly, you could easily do that with the intersection cube with no greedy meshing algorithm. Just simply cut it into equal-size parts of a certain amount.
In fact, I might be misunderstanding your problem since I actually don’t see where greedy meshing would be used here. My current understanding is that you’re cutting a hole in your block and then inserting a block to fill the hole and then subdivide it. Let me know if I am wrong and I’ll adjust my answer accordingly.
You’re mostly correct, the main reason why I’d use greedy meshing is because when it comes to much, much larger parts, you’re going to be dividing them much, much more. In which case I would just greedy mesh them all for performance. And my interpretation of dividing the parts in that image was meant to just be an example of what dividing a part might look like, though I don’t know how a divided part would actually look. And your suggestion of a “5th part” may actually work here. Thinking about it a bit more, I could just divide the part into more and more smaller cubes until they fit the size I want, and then outside of the cubes that the hitbox is touching, just greedy mesh the rest so all that remains is the parts that are touching the cube. This isn’t exactly Ideal as I would imagine this might take a hit on performance, but it may work.
Yes, it would be a little confusing to imagine dividing a part uniformly with non-powers of 2. I just imagined you cutting it in halves for simplicity sake.
Are you actually creating a hole with the hitbox from one side to the other side of the cube or are you shaving a hitbox-sized part of the box and replacing it with subdivided cubes that equate to the hitbox’s size in total? My initial impression was the former. You would not be creating “four parts” otherwise with the latter and this would vary.
I am trying to create a voxel destruction system. I think this post better explains what I’m trying to achieve. And the ideal is to be able to carve out shapes into a part with any sort of hitbox. Any sort of method I mentioned in this thread was just an idea on how I would go about it. It doesn’t really matter to me how I achieve it, just as long as it has good performance.
Here’s something I cobbled together, but the performance is less than ideal
Yes, I looked at a few posts you had about this topic. Your subdivision can be done using an octree because basically, a cube (any part in general being a bunch of cubes if we wanted it to be) can be represented as a piece of a voxel/chunk. Octrees subdivide until a certain point (otherwise you’d just split infinitely) so this helps you make the algorithm to create the splices.
I think what might be done to optimize performance is to locate exactly what voxels are being affected. This way, you ignore every other voxel that a collision has not occurred in. Yes, if some really big part was holding up four voxels and you saw it in one of them, you’d still detect that big part as part of the voxel and include it in the greedy meshing algorithm.
I suppose octrees is more confusing in this implementation than the distance-based one that developers use for example to detect where a player is in the world. That example is much simpler and a good case for you to study octrees if you feel that a better understanding of that will lead to you solving this optimization problem (definitely understand linked lists → binary trees, if it’s still daunting as maybe they are easier versions of the whole tree data structure type). You subdivide the world into a bunch of cubes and you need to control exactly how big you want these subdivisions to be such that you optimize your distance checks the best.
I’m unfortunately not someone who has made such a system before but I think this should give you a step in the right direction.
