CoordinateSystem: Backwards compatibility - Read legacy transform #1504
Conversation
CoordinateSystem used to derive from the deprecated and removed StateRenderable holding additional transform information for the renderer. A better approach that is also used in Gaffer, the transform information is better stored as separate transform information. Cortex 10.6 also removed all DCC integrations, i.e. IECoreMaya, which stored, for example Locator transformation on the CoordinateSystem. We provide a way to still retrieve this information from old SceneCaches, although not fully transparent and backwards compatible. Clients of CoordinateSystem will need to be adjusted if needed. The `M44fData` is stored as `LegacyTransform` in the `BlindData` of the CoordinateSystem
|
@johnhaddon Thanks again for giving me pointers for the different approaches. I think the less complex way of reading the matrix directly in Cheers, |
johnhaddon
left a comment
johnhaddon
left a comment
There was a problem hiding this comment.
Hi @yannci, thanks for taking this on.
Let me know if my implementation is overly complicated for the matter or if there's anything I might have missed.
I've made a few notes on the implementation, but I'll leave it to you and @ivanimanishi to decide if they're relevant to you or not. Since none of this affects Gaffer users I think it's your call rather than mine.
I considered not to add this to the CoordindateSystem test suite
Again, your call. But personally if I was depending on it I think I would want some test coverage (unless perhaps you have some internally).
Cheers...
John
| for ( auto levelDirectory : levelDirectories ) | ||
| { | ||
| ConstIndexedIOPtr subdirectory = directory->subdirectory( levelDirectory, IndexedIO::MissingBehaviour::NullIfMissing ); | ||
| if( subdirectory ) | ||
| { | ||
| findMatrixEntry( subdirectory ); | ||
| } |
There was a problem hiding this comment.
Are you using this recursive search because you need to support MatrixMotionTransform as well as MatrixTransform, and it's convenient to deal with both using the same code?
| } | ||
| }; | ||
|
|
||
| findMatrixEntry( container ); |
There was a problem hiding this comment.
Perhaps it's worth starting the search from container->subdirectory( "transform" ), so we're sure we can't accidentally pick up fields from elsewhere? This would also avoid a little bit of work when loading new files, where the subdirectory won't even exist.
| if( directory->hasEntry( matrixEntry ) ) | ||
| { | ||
| float *f = matrix.getValue(); | ||
| directory->read( matrixEntry, f, 16 ); |
There was a problem hiding this comment.
Should this return as soon as a matrix is found? And if so, should we stop the iteration through levelDirectories when it does?
| } | ||
|
|
||
| IndexedIO::EntryIDList levelDirectories; | ||
| directory->entryIds( levelDirectories, IndexedIO::EntryType::Directory ); |
There was a problem hiding this comment.
I have a feeling that entryIds() doesn't return things in a stable order from one run to the next (the order is based on InternedString comparisons, which can give different results from process to process). So in the case of MatrixMotionTransform, you may not always be picking up the same time sample.
2 participants
CoordinateSystem used to derive from the deprecated and removed StateRenderable holding additional transform information for the renderer. A better approach that is also used in Gaffer, the transform information is better stored as separate transform information. Cortex 10.6 also removed all DCC integrations, i.e. IECoreMaya, which stored, for example Locator transformation on the CoordinateSystem. We provide a way to still retrieve this information from old SceneCaches, although not fully transparent and backwards compatible. Clients of CoordinateSystem will need to be adjusted if needed.
The
M44fDatais stored asLegacyTransformin theBlindDataof the CoordinateSystemRelated Issues
Checklist