4 ms·

Can I open an OpenUSD file in a text editor and read it?

by 2OEH8eoCRo0 3y ago

franzb 3y ago
Yes, absolutely.
deleted 3y ago
[deleted]
omershapira 3y ago
OpenUSD has a plaintext encoding mode, which by convention gets saved as .usda. The standard OpenUSD SDK contains two command line utilities `usdcat` and `usdedit` to do plaintext editing, but most programs using the SDK have better editing functionality by directly using the C/Python SDK.
- wilg 3y ago
  Here is an example file for the curious: https://github.com/PixarAnimationStudios/OpenUSD/blob/release/extras/usd/examples/usdGeomExamples/basisCurves.usda https://github.com/PixarAnimationStudios/OpenUSD/blob/releas...
pixelesque 3y ago
The ASCII (plain-text, .usda file extension version) absolutely. For large scenes/models, the normal .usd binary/compressed version is often used for efficiency reasons (and proper round-tripping of float values for xforms, etc), but you can convert between the two with the 'usdcat' util and the python/c++ apis for debugging.
- derefr 3y ago
  > proper round-tripping of float values Why do so many (all?) textual data serialization formats represent floats in base-10 scientific notation, anyway? If we wanted floats that are 1. human-editable but 2. bijective with IEEE754, wouldn't floating-point hexadecimal (and "e" notation representing a base-2 exponent) be a better idea?
  - andyferris 3y ago
    > human-editable I mean, depends on the human. Most don't know hexadecimal, but know what 3.14 means. The real issue is why do so many float parsers and printers fail to do exact round tripping? Designing a good algorithm for this was a bit difficult, but these days this is a solved problem.
    - johnnyanmac 3y ago
      If I had to take a slightly snide guess: because these are low level tools, so there's a 90% chance that these parsers/prints are written in C, or ultimately depend on C implementations. As any C programmer would know, C loves to throw "undefined behavior" at any problem it doesn't bother to document. Which is a lot. That combined with almost zero package management for retrieving things that were solved decades ago means we keep coming into this issue, partially because of the mindset of C programmers.
      - account42 3y ago
        This is just "hur dur C undefined lol" level of a comment. If you are serious about your data format supporting round tripping you can and should specify the precise ASCII encoding of binary floats and the inverse. If that means implementations have to ship their own float formatter and parser than so be it - no one is tied to whatever comes with their libc, package manager or no package manager.
        johnnyanmac 3y ago
        I did say slightly snide. But it isn't just about undefined behavior, it's more about the culture of C and how it approaches package management and sharing (or in this case, doesn't). Even if C has Rust level correctness checking it would have the same issue. >If you are serious about your data format supporting round tripping you can and should specify the precise ASCII encoding of binary floats and the inverse. Well I guess we have our answer in the case of seriousness. I'm guessing it didn't matter enough for the implementers, or it did matter but could never actually get it implemented. The reasons for this are numerous, contextual (with context we'll never have), and probably not rooted in technical reasoning. We are talking about the domain of animation and games, after all. Not mission critical code. There's more wiggle room, especially for the complexity of media around when the format was being developed.
- tsuru 3y ago
  Is the plain text diff-able? Easy to resolve merge conflicts? I consider xml(collada?) not to be diff friendly.
GoofballJones 3y ago
Yeah, sounds kind of like the old Renderman RIB files. Does Renderman still use RIB files? I've been so out of the loop it's insane. I learned not long ago they no longer use the original Renderman Shading Language.

Can I open an OpenUSD file in a text editor and read it?

franzb 3y ago

Yes, absolutely.

deleted 3y ago

[deleted]

omershapira 3y ago

OpenUSD has a plaintext encoding mode, which by convention gets saved as .usda. The standard OpenUSD SDK contains two command line utilities `usdcat` and `usdedit` to do plaintext editing, but most programs using the SDK have better editing functionality by directly using the C/Python SDK.

wilg 3y ago
Here is an example file for the curious: https://github.com/PixarAnimationStudios/OpenUSD/blob/release/extras/usd/examples/usdGeomExamples/basisCurves.usda https://github.com/PixarAnimationStudios/OpenUSD/blob/releas...

pixelesque 3y ago

The ASCII (plain-text, .usda file extension version) absolutely. For large scenes/models, the normal .usd binary/compressed version is often used for efficiency reasons (and proper round-tripping of float values for xforms, etc), but you can convert between the two with the 'usdcat' util and the python/c++ apis for debugging.

derefr 3y ago
> proper round-tripping of float values Why do so many (all?) textual data serialization formats represent floats in base-10 scientific notation, anyway? If we wanted floats that are 1. human-editable but 2. bijective with IEEE754, wouldn't floating-point hexadecimal (and "e" notation representing a base-2 exponent) be a better idea?
- andyferris 3y ago
  > human-editable I mean, depends on the human. Most don't know hexadecimal, but know what 3.14 means. The real issue is why do so many float parsers and printers fail to do exact round tripping? Designing a good algorithm for this was a bit difficult, but these days this is a solved problem.
  - johnnyanmac 3y ago
    If I had to take a slightly snide guess: because these are low level tools, so there's a 90% chance that these parsers/prints are written in C, or ultimately depend on C implementations. As any C programmer would know, C loves to throw "undefined behavior" at any problem it doesn't bother to document. Which is a lot. That combined with almost zero package management for retrieving things that were solved decades ago means we keep coming into this issue, partially because of the mindset of C programmers.
    - account42 3y ago
      This is just "hur dur C undefined lol" level of a comment. If you are serious about your data format supporting round tripping you can and should specify the precise ASCII encoding of binary floats and the inverse. If that means implementations have to ship their own float formatter and parser than so be it - no one is tied to whatever comes with their libc, package manager or no package manager.
      - johnnyanmac 3y ago
        I did say slightly snide. But it isn't just about undefined behavior, it's more about the culture of C and how it approaches package management and sharing (or in this case, doesn't). Even if C has Rust level correctness checking it would have the same issue. >If you are serious about your data format supporting round tripping you can and should specify the precise ASCII encoding of binary floats and the inverse. Well I guess we have our answer in the case of seriousness. I'm guessing it didn't matter enough for the implementers, or it did matter but could never actually get it implemented. The reasons for this are numerous, contextual (with context we'll never have), and probably not rooted in technical reasoning. We are talking about the domain of animation and games, after all. Not mission critical code. There's more wiggle room, especially for the complexity of media around when the format was being developed.
tsuru 3y ago
Is the plain text diff-able? Easy to resolve merge conflicts? I consider xml(collada?) not to be diff friendly.

GoofballJones 3y ago

Yeah, sounds kind of like the old Renderman RIB files. Does Renderman still use RIB files? I've been so out of the loop it's insane. I learned not long ago they no longer use the original Renderman Shading Language.