Manually created octrees no longer working in BJS 4.0

I have a scene where I manually create and manage the selection octree, but since moving to BJS 4.0 the octree seems to be ignored - nothing gets culled, regardless of how I construct the octree or octreeBlocks.

My code basically looks like this:

// at init
scene._selectionOctree = new Octree(() => {})
scene._selectionOctree.blocks = []

// ... later when creating a chunk of world
var min = new Vector3( ... )
var max = new Vector3( ... )
var block = new OctreeBlock(min, max, undefined, undefined, undefined, () => {})

From source diving it looks like maybe I need to add some kind of component to scene to tell BJS that octrees are being used? But I can’t find any sample code doing this, or docs on what changed.

How can this be done in 4.0?

What package are you using, the es6 version with @babylonjs/core ? Or the umd/cdn version ?

I’m using es6. I’m guessing the “_components” array on scene has something to do with that?

According to the es6 doc, you need to import “Culling/Octrees/octreeSceneComponent”; for side effects to use octree with es6.

Is anything else needed? Adding just the import has no effect I can see, the selection octree still doesn’t affect the scene.

I’d repro this in the playground but since it seems to depend on es6 imports I’m not sure how that would work.

The imports I have currently look like:

import { Scene } from '@babylonjs/core/scene'
import { Octree } from '@babylonjs/core/Culling/Octrees/octree'
import { OctreeBlock } from '@babylonjs/core/Culling/Octrees/octreeBlock'
import { Engine } from '@babylonjs/core/Engines/engine'
import { Vector3, Color3 } from '@babylonjs/core/Maths/math'
import { Mesh } from '@babylonjs/core/Meshes/mesh'
import '@babylonjs/core/Culling/Octrees/octreeSceneComponent'

So you have a simple github project for the repro ???

A repo wouldn’t help here. ES6 Babylon apparently requires some new extra step to use a selection octree; an empty repo wouldn’t help figure out what it is.

Guess I’m on my own, I’ll go sourcediving…

Hmm, it looks like the extra step is:

scene._addComponent(new OctreeSceneComponent(scene))

I guess _addComponent is some new (undocumented) mechanism to work with ES6 imports?

Hi @fenomas. Unfortuantelly I cann’t help you to solve the issue, but I can give you a sugestion where to isolate and reproduce.

I did few times and it is very usefull - BabylonJS ES6 - CodeSandbox

Oh I see, you do not rely at all on the createOrUpdateMecanism in your case. So the automatic reference through createOrUpdateSubmeshesOctree or createOrUpdateSelectionOctree is not called.

Actually the code called in both those functions is:

    let component = scene._getComponent(SceneComponentConstants.NAME_OCTREE);
    if (!component) {
        component = new OctreeSceneComponent(scene);

Do you want me to wrap it in a public function for you ?

No idea - I just want to use a selection octree where I manually create and position the blocks. Is that currently possible to do with public methods, or is it not intended to be?

You can but as you did, you need to reference to OctreeSceneComponent in the scene.

If you use the built in system, this step is done for you.I was wondering if you d like that I introduce a new function like:

OctreeSceneComponent.RegisterForScene(scene) so you do not have to worry about changes on the _ functions ???

I understand what you were suggesting, but it looks to me like 4.0 has introduced some kind of “component” mechanic, that seems to touch lots of different features. Do other such features already have some way of getting initialized?

FooComponent.RegisterForScene would be fine here, but it would be best if there’s a consistent way of dealing with all “componentized” features.

They are all automatically initialized when you use a feature from its embedded method. Unfortunately using Octree manually is a bit edge case as it requires the component but can not initializes automatically as you are doing all the rest manually. It is probably only an issue with the octree system.