Initialization method that stays within Box3 bounds about linear-octree HOT 5 CLOSED

Yes, level 0 is the smallest / most fine-grained level.

That was it! It all came down to me thinking that the finest level was maxLevel - 1 and thinking that the OctreeHelper was a source of truth for the tree bounds. So I basically added things out of bounds because I was using the largest, instead of the smallest cells to calculate the next voxel position.

Maybe such an out of bounds check (as a warning) makes sense for the helper? I.e. check if the helper becomes larger than the original octree bounds expected.

Anyways, as usual the error sat in front of the monitor haha
Thanks so much for your time and help - I got it to work now :)

from linear-octree.

Hi,

I'm not sure if I understand the problem 🤔 The octree bounds shouldn't change and the amount of levels per axis define the number of subdivisions as you'd expect.

Could you provide a failing test case to better describe how you're using the octree, what methods you're using and what results you're expecting? You can take a look at the existing unit tests for reference: https://github.com/vanruesc/linear-octree/blob/main/test/core/Octree.js

from linear-octree.

Thanks for the quick Response. Yeah that's what I'd expect too. I'll compare the tests with my code tomorrow and follow up.

from linear-octree.

This is how I'm initializing the octree.

function initOctree(mergedGeometry, level) {
  const keyDesign = new KeyDesign(level, level, level); 
  const treeBounds = new Box3();
  treeBounds.copy(mergedGeom.boundingBox);
  const octree = new Octree(treeBounds, keyDesign);
  const octreeHelper = new OctreeHelper(octree);
  scene.add(octreeHelper);
}

and this is the result:

level == 1
The bounds of the tree fit the mesh bounding box exactly (you can see z-fighting between the BoxHelper and the OctreeHelper)

level == 2

level == 3

So it seems like instead of describing the final bounds, the bounds stay that of the level 1 bounds.
I haven't come up with a test yet (can follow up in the coming days), octree.min and octree.max stay the same regardless of level, but it can't only be the octree helper that's wrong, I've been spawning voxels in each cell like this and they match the octreeHelper as well:

for (const ocWrapper of octree.octants(maxAccessLvl)) {
    ocWrapper.getCenter(position);
    matrix.compose(position, quaternion, scale);
    voxels.setMatrixAt(voxelIdx, matrix);
    voxelIdx++;
}

Two other things I've noticed:

• The octree helper is only included in the sparse-octree, not linear-octree package
• The api for getting cell sizes seems to be different than in other functions (level 0 being the smallest cell, instead of the largest - is that intended?)

const c1 = octree.getCellSize(0, new Vector3());
const c2 = octree.getCellSize(1, new Vector3());
const c3 = octree.getCellSize(2, new Vector3());
console.log(c1, c2, c3);

from linear-octree.

I've been spawning voxels in each cell like this and they match the octreeHelper as well

It's possible that you're adding data at positions that lie outside the octree. The current implementation doesn't have any safe guards for bounds checks. Are you converting the world positions of the voxels to key coordinates via Octree.calculateKeyCoordinates?

octree.min and octree.max stay the same regardless of level, but it can't only be the octree helper that's wrong

The helper iterates over the keys in the octree grids. If the keys are wrong, the resulting bounds will also be wrong while the initial bounds remain the same.

The octree helper is only included in the sparse-octree, not linear-octree package

Oh right, I'll re-export that in linear-octree for convenience.

level 0 being the smallest cell, instead of the largest - is that intended?

Yes, level 0 is the smallest / most fine-grained level.

from linear-octree.