I was wondering if OpenUSD had any plans for defining the axes for “left”/”right” or “forward”/”backward” at an asset level. Perhaps this would be by convention, or explicitly like with upAxis? I’m seeing more traction for standardizing on this idea in places like glTF and Unreal Engine, and it sounds like a good idea for interchange purposes.
Unreal uses the term LUF (Left-Up-Forward), which I’ll use here. Other terms like FRU (Forward-Right-Up) and RUF (Right-Up-Forward) are essentially the same.
DCCs in my experience tend to have an unspoken convention based on how you might rig a character. For a character rig in Maya, the left side would (usually) be +X, resulting in LUF = +X +Y +Z.
I did some searching around before posting, and found that OpenUSD has definitions of “up” and “forward” from a rendering POV ( Universal Scene Description: UsdGeom : USD Geometry Schema ) - but I think this is subtly different than how you’d define assets (The camera’s view “up” is always +Y, but an asset’s up depends on the layer’s upAxis).
Like OpenGL and the fallback for UsdGeomGprim::GetOrientationAttr(), UsdGeom stipulates a right-handed coordinate system. Therefore, when viewing a UsdStage with a “Y” up axis, the stage’s Z axis will be pointing out of the screen, and when viewing a UsdStage with a “Z” up axis, the stage’s Y axis will be pointing into the screen.
Hmm I think that’s relating to the view coordinate system and how it transforms the scene relative to the camera. I’d like to address what an asset’s idea of “forward” is, which to my understanding might be different than the stage or the view.
If I had to guess, the most common way to author assets in USD is Left=+X or Right=-X, but I haven’t seen this prescribed. I doubt most people pay an incredible amount of attention to this, however.
It would be helpful if you could specify what/where you expect this information to be used? I think @dhruvgovil and I immediately jumped to mixing and matching coordinate systems in a renderer, because if we put this capability into USD, for sure you will get scenes that comprise assets with numerous different configurations. As Jeremy Cowles has eloquently written about in the context of USD, that’s really hard!
But if this is just about scraping information from an asset to be able to frame it properly in a camera for thumbnails, etc, that seems more tractable.
Yeah, I don’t doubt that adding more wacky coordinate systems to the rendering side of things would get out of hand. No thanks!
What I had in mind was more workflow-oriented. Tooling can understand the intent of the asset better if it knows what “forward”/”left” is, like for thumbnailing, layout, or importing/exporting between DCCs consistently.
I’m not necessarily proposing any schema changes, but to compare the idea conceptually: Much like how metersPerUnit might be used by a USD workflow to xform-scale the asset to match the stage, a hypothetical leftAxis (or similar) could be read by a DCC to xform-rotate the asset 90 degrees on the up axis. That’s one approach, but IMO, doing nothing but establishing a convention is probably good enough. Most things seem to assume left is +X anyway, and from what I can tell, very few DCCs like Unreal are the oddballs.
Visual anchors are good, so here’s one. The left of the model is +X for both Y-up and Z-up here:
I think I can agree with a “forward” hint in the same way we have the up hint.
You can imagine trying to procedurally place a TV for example. With up you know how the asset should be mapped to the surface normal, but without a forward hint you have no way of knowing what direction to use as the face of the tv.
Studios have conventions ( usually Z or -Z in Y up studios ) but those are just internal conventions.
I could support that if it does the same thing as the up axis metadata does and is just for information. If we only specify up and forward there is also no issues with handedness.
This seems related to the orientation attribute of the mesh. I image the axes following the same convention as the polygons with respect to left and right handiness?
I’d like to draw a distinction to upAxis in that upAxis (or rather an API-schema replacement for it) will be used by core OpenUSD logic to transform-orient referenced assets whose upAxis differs from that of the stage onto which they are being referenced. Whether that’s via an authored xformOp or an execution behavior associated with the applied schema, TBD. So, it’s more than just a hint.
But a forward hint would be just that - something available for DCC’s to use for camera framing, but triggering no core behaviors itself.
@koen , I look at orientation as a needed thing to decode the implementation of Mesh (or other) topology properly, whereas forward is more like a judgment about what’s the “most useful” side of a thing? But yeah, they are both about orienting stuff.
I am just re-reading this thread as I ran into this at our studio. I did not understand the request very well earlier, now I agree a “forward” hint would be very useful. We will stick this in a custom meta datum for now, but an official hint would be great.
Acknowledged, @koen .. we’ll consider this while formulating the Geom/Linear metrics proposal out of the more general layer metadata replacement proposal. With that proposal in mind, with its concern of transforming embedded coordinate systems hierarchically, I wonder whether this hint should also be transformed, or whether we require it be always consumed from the most-root prim that expresses an opinion about it?
The other question is, what the fallback should be… I don’t think we want to guess, so maybe the fallback is “none” ?
I dont think this should ever “automatically” be applied. For us, this is meta data we read when importing into the engine, and together with scale and handedness fixes, we apply it, but I would not expect usd to do any transforming.
I agree the fallback should be something like none or undefined, so the consuming code knows this information was not authored.
I had not seen that metadata proposal, reading now, thanks for sharing, also happy new year!
