-
Notifications
You must be signed in to change notification settings - Fork 470
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Property table array in subtree format #642
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While I haven't yet started the implementation, this change looks sensible to me.
extensions/3DTILES_implicit_tiling/schema/subtree/contentMetadata.schema.json
Outdated
Show resolved
Hide resolved
Co-authored-by: Peter Gagliardi <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's good to align the structure more with that of EXT_structual_metadata
.
I'm a bit confused about tileMetadata
and contentMetadata
, though: They are ... wrappers for an integer. If I had to find a reason for that, could only come up with ~"well, maybe, some day, we want to store other things there, beyond the property table index". But that sounds a bit vague. Is there any specific reason to wrap this index into objects?
Future proofing was the main reason. Maybe there would be other encodings in the future? Metadata inheritance is also in the back of my mind, but now that I think about it those fields would be part of the property table definition. It should be ok to simplify and make them integers instead of wrappers for integers. I'll make the change. |
@javagl updated |
So now it will be my fault if we hit a road block in the future :-) But I don't see any reason now to not merge it. |
Instead of inlining a property table in
tileMetadata
andcontentMetadata
there is now a dedicated section for property tables. This is consistent with EXT_structural_metadata and is more future proof if we ever need to support property tables referring to other property tables for metadata inheritance (#641).