Got storing nodes in C#, sending nodes to Blockland from C#, and collapsing nodes in C# figured out today.

Tomorrow I want to tackle sending brick bounding information over to C#, so I can do all the node calculations there. To replicate containerBoxEmpty I guess I'm just going to store all the bricks in memory by their bounding box and check to make sure none of them intersect with the container box.

This will end up as a nested loop though when generating nodes for every brick though, how could this be improved?

i'm not too exactly sure what loop structure you're thinking of but you could certainly improve a containerBoxEmpty search by implementing a chunking system. essentially, imagine cubes of one size being tessellated infinitely. each brick that you add can be assigned to one of those cubes. how we're able to do this is through some mathematics. you have a map of vector3 -> cube and determine which cube a brick goes in by

`floor(brick.position / cubeSize)`. when you create cubes on the fly, you're able to assign bricks to these cubes and from there you can implement an efficient containerBoxEmpty search. this works because containerBoxEmpty, instead of looking through every single brick, would only look in the cubes whose bounds intersect with it. so instead of checking every single brick, you might only have to check say 4 cubes which will have way less bricks than the entire map contained within them. under the hood, that's how TS does these calculations itself more or less. they probably use octrees, which are just basically more advanced cubes. the thing about brick density in a build is its obviously not constant. you will have some areas which are sparsely populated and some areas that are densely populated. what an octree does is dynamically scale its cubes based on density of the bricks, which squeezes some additional performance out of the original chunking algorithm. iirc, it tries to keep a somewhat constant density in its cubes. so cubes will be scaled down if there's higher density in an area, resulting in more cubes but each cube will have a relatively constant number of bricks within it. for sparse areas, the cubes will be way larger in order to maintain the constant density. they behave in the exact same way the quad-tree nodes you implemented behave, except octrees are in 3d instead of 2d

all that being said you will not have to program any of this yourself. there are for sure c# libraries out there that you can exploit that will do all of this and more. to get you started on your search, you might want to look for collision checking libraries or soPhysician Prescribed Desoxyning along those lines. octrees are basically necessary for collision engines because of the aforementioned density problems and you'll probably have a lot of luck starting your search there