Took me a while to realize that tying this to a certain hardcoded field
isn't a good idea. The new variant is useful also for example for
getting absolute light positions or just whatever else. Besides taking a
SceneField there's now also an overload taking a field ID to avoid
double lookups. The only behavioral difference compared to the old API
is that the field is now required to exist, instead of the API being a
silent no-op if not present.
Eventually these APIs may get further extended to take a BitArrayView of
objects for which to calculate the transforms, for example to take only
meshes that are a part of the hierarchy, or meshes that satisfy an
arbitrary other condition. Which will also resolve the remaining
concerns with the API. I'm still keeping it marked as experimental tho,
the usefulness isn't set in stone yet.
The old APIs are marked as deprecated and implemented using the new
ones.
It doesn't discard meshes that are not a part of the hierarchy, but that
was the plan in the beginning. However, over the time I realized that a
better property for it is that the output is guaranteed to be in the
same order and size as the mesh field in the scene. Because that's what
I relied on in every use case, and every time I had to dig that property
out of the sources because it was deliberately not documented *because*
it was meant to change.
No longer. The compatibility with the mesh field ordering is now
documented, the behavior regarding loose objects also, and if there's
ever a need to discard everything that's not in the reachable hierarchy,
it'll probably get its own API. Because it's useful for general
asset cleanup and other use cases, not just meshes.
I'm still keeping the experimental tag here though, tp be sure.
Vladimír Vondruš