Add shader generation hwTexcoordVerticalFlip option for UV convention

[hybridherbst]

Add GenOptions::hwTexcoordVerticalFlip to flip the V component at the texcoord node output before UVs enter the hardware shader graph. This allows applications to preserve mesh UV data while selecting the target shader convention through generator options.

Note: the existing texcoordVerticalFlip is a load-time option; it's not available in external systems (or they need to roll their own); and it requires duplicating geometry streams when wanting to switch to MaterialX materials from others. The new option preserves data and allows choosing the intended convention.

Geometry loaders now expose whether their source texture coordinate convention requires a shader-side vertical flip. MaterialXView and MaterialXGraphEditor query that through GeometryHandler, so glTF and GLB keep their previous visual orientation while OBJ remains unflipped, including when switching mesh formats.

Alternative approaches

One alternative found in e.g. three.js is that texture objects carry information on whether they need a shader-side Y flip; in practice, this is almost always used per-material with one flag, and its rare to mix "flipped and non-flipped" textures.

[ld-kerley]

I need to digest this a bit more to really know what I think - but initial reaction to this is that the tex-coord node is often used for reading things other than images - and that the flip-v "problem" is largely centered around a differing of opinion around where the origin is in an image when reading it in - it feels more natural to me that the "problem" is solved at the image reading node - not at the texture coordinate generation site.

[hybridherbst]

Thanks!

but initial reaction to this is that the tex-coord node is often used for reading things other than images

Maybe my wording / rationale wasn't great there: The reason this is at the texcoord node is exactly that UVs are often used for things other than images. The mismatch we’re addressing is a UV-coordinate convention mismatch between source geometry and the target shader convention. If we handled this only in image nodes, image sampling would be corrected, but procedural UV consumers, masks, ramps, and per-vertex effect controls would still see the wrong coordinate space.

Before this PR, this had to be done either on the geometry level, which makes everything slow, or by patching the generated shaders (which is what we were doing before the work done for this PR). With this PR, we can simply enable the flip option for e.g. three.js where we know the UV coordinate convention is different, and thus change the semantics at the right level instead of patching over it.

[hybridherbst]

I'll think about how I can explain / show this better...

[ld-kerley]

Very happy to have mis-understood here if thats what's happening.... It sounds like you want to be able to effect all uses of the UVs - because you think that the UVs on the geo are inverted (perhaps by someone else trying to already account for a discrepancy in the image orientation?).

If I'm understanding your response correctly - then I'm wondering how we determine what are the "correct" UVs? Or maybe you're just looking to add a different way to correct the problem. I'm not opposed - just maybe worry that having two different ways to fix the same problem - could end up making the problem even worse?

[kwokcb]

This feels a bit strange to me. The source of the geometry shouldn't play a factor in the orientation used for rendering. I assume "correct" is the renderer / rendering API convention always. For images they should conform to that on load or allow a way to flip at shader time (the current load logic isn't really very robust). For procedurals (like ramps) it should also check the renderer's convention and allow flip at shader time. I don't think this should be a user option as they could just arbitrarily go around flipping UVs but instead a shader gen or render time decision (*)

I am curious how things work with the PR logic if:

1. You load in geometry from 2 different loaders with 2 different assumed conventions.
   You assign the same shader to both geometries ?
2. You load in the geometry as in 1 but you render with 2 renderers with different UV conventions (say DX vs GL) ?
3. I noticed that ambientCG has 2 versions of shaders to handle DX vs GL flipping. How would that work as the network has adjusted for renderer convention already ?

(*) Note that emitting different code in C++ will require regeneration on convention change whereas I'd propose a "V-up" convention shader input which would allow for flipping without regeneration (and image load).

Let me know what you think. My understanding could be totally off.