I’m currently working on implementing a simple method that, given an object ID, finds the bounding box that contains the object. I noticed that everytime I call ComputeAABB() method on the renderview it simply sets the bounding box to -inf,inf for all values. I’m not sure If I’m currently using it wrong or its not implimented correctly.
try {
node.model.renderView.computeAABB(); <<<< PROBLEM
const aabb = node.model.renderView.aabb;
if (aabb && aabb.min && aabb.max) {
if (debug) {
console.log(`${' '.repeat(depth * 2)}Found valid bounding box:`, aabb);
}
// Create a Box3 from the bounding box
const nodeBox = new THREE.Box3(
new THREE.Vector3(aabb.min.x, aabb.min.y, aabb.min.z),
new THREE.Vector3(aabb.max.x, aabb.max.y, aabb.max.z)
);
console.log(nodeBox);
// Union with the combined box
combinedBox.union(nodeBox);
}
} catch (error) {
console.warn(`Error getting aabb for node:`, error);
}
…
For my intended use, I was able to assume the current bounding box is correct and move on, but I just wanted to bring this up to the community.
There is indeed an issue with computeAABB and how it works, or more like doesn’t work, after load time. The function looks into the renderView’s geometry to compute the aabb and it’s being used internally while constructing the render tree at load time.
However, there is another thing that we do after everything is loaded in and batched. Each individual render view geometry data is being wiped. We’re doing this to reduce memory footprint. Because we batch objects together their individual geometry data no longer makes sens so we choose to get rid of it. That’s why when calling computeAABB yields an undefined aabb.
This is an issue in itself because it nukes the render view’s aabb. We’ll make some changes around this, so this doesn’t happen
For AABB purposes, you can always assume the render view’s aabb is correct. For meshes, you can also use the BatchObject's aabb property especially when dealing with instances.
An important thing to remember about the render view’s aabb is that it reports the object’s bounds ‘in a vaccum’. That is, it does not take any possible transformations into account.
Thank you for pointing this issue out to us! And if you run into any other issues do let us know!
I do have one quick follow-up question: How do you identify duplicated object instances? (I mean this in the sense that the same base mesh is transformed to a new location)
From reading the viewer/Data Tree documentation, I thought this would be something that shows up as true in the object instance field?
However, whenever I push up a Revit scene with several duplicated instances of the same object, it doesn’t appear to be instanced; instead, it appears as a unique object. Is this possibly a property of Revit to speckle model conversion?
Programatically there are several ways you can grab instances. There is the getInstances API member. Additionally instanced geometry will have an instanced flag.
However, the action of actually creating and using instances is up to the connectors. From what I’m aware not all connectors use instancing, even more so the newer v3 ones. Ideally everything that can be instanced, should be instanced and I believe that more support for instancing will be added as we move along into the new generation of connectors
