Bounding boxes of all the objects in the tree

[koen]

Hello all,

For many applications, (for example efficient rendering, easy proxy display or deferred loading of geometry) it is very useful to be able to load the bounding box of any object in the hierarchy in an alembic file, without loading the actual geometry. 

Is this currently implemented as a standard feature in the library? I would love if alembic has standard get and set functions for the bounding box and when writing a file, the library would make sure the bounds are stored at every level where a transform is stored. 

Is this currently implemented, and if not, would it be worth considering making that part of the specification?

Thanks,

Koen

[Ben Houston]

This is part of Alembic already and used by Exocortex Crate and Kahana for showing boxes on screen when using deferred loading/proxies.

Sent from my phone, sorry for my grammar and terseness.

--
You received this message because you are subscribed to the Google Groups "alembic-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[koen vroeijenstijn]

Ah, great.

Is every alembic file guaranteed to have these bounds, or does that depend on the implementation of the writer?

Thanks,

Koen

[Steve LaVietes]

Bounds are automatically added for every shape by the library. Bounds on the enclosing xforms -- as well as at the archive root level -- are currently optional.

The reference implementation of the maya writer always includes archive level bounds. I believe the Houdini writer does as well.

-stevel

[Brian Leair]

Hi Koen,

The enclosing volumen of children objects, which you'll see as the childBounds property in AbcGeom classes, is optional. If the property hasn't been set you'll get a default Box3x which spans the world (by way of Box3x::makeEmpty())

There is a utility function in AbcGeom/Fondation.h called ComputeBoundsFromPositions() that might be of use to you, though I'm sure you likely already have your own iteration utilities.

I see that Steve has just replied, and he captured it perfectly. 

Back in the day there was debate about whether the enclosing bounds should be a guaranteed part of the Alembic spec. Ultimately it was argued that while most applications have this information as they write, a few might not, so it's optional but encouraged to be part of the data you write.

cheers,

-Brian

[Koen]

Hello all,

Thanks for the responses. I was wondering how Katana handles this. If the bounding boxes are only guaranteed to exist on the leaves, you have to start loading a large part of the file pretty soon.

Do people using Katana modify the exporters to make sure the bounds on the xforms are set? Ben, is crate setting all these bounds on export?

Thanks,

Koen

[Steve LaVietes]

At SPI, we use an Alembic archive per asset -- i.e. a single character or environment prop element. The archive-level bounds are sufficient for our deferred-loading-during-rendering purposes. 

Our archives are referenced within a simple scene assembly container which can optionally store higher-level bounds of its own. Enclosing xform-level bounds would serve the same purpose (without changes on the Katana side) were we to work with less granular archives.

-stevel