Skip to content
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

EXR: Stop translating "worldToNDC" to "worldtoscreen". #2609

Merged
merged 1 commit into from
Jun 19, 2020

Conversation

lgritz
Copy link
Collaborator

@lgritz lgritz commented Jun 18, 2020

This seems wrong. EXR standard metadata "worldToNDC" is exactly what it
says, not screen space. I'm not sure how we ended up with the historical
accident of reading "worldToNDC" from exr headers and auto-translating
it to "worldtoscreen".

The hope is that nearly no one is affected by any of this, since the
use case for these matrices was shadow maps, which were never
fully implemented in OIIO's TextureSystem anyway (they were last on
the list, and the VFX world switched to ray tracing before anybody got
angry enough at my procrastination to force me to implement it).

Signed-off-by: Larry Gritz lg@larrygritz.com

@fpsunflower
Copy link
Contributor

This looks good, but I am not sold on adding the "fill in the other matrix automatically" idea. It only works seamlessly in some directions and is very confusing in others.

For example if the file on disk has worldToNDC (written out from worldtoscreen via an old OIIO). Now a shader that reads "worldToScreen" via the new OIIO will get a shifted matrix. But I think getting nothing back from the new OIIO is more "correct" and less surprising. (And this is the exact unfortunate mess we got ourselves into).

Another example, if someone was filling in worldToNDC correctly and directly (not relying on the translation from worldtoscreen) they would suddenly get an extra matrix in their header that they didn't ask for without any way to remove it.

@lgritz
Copy link
Collaborator Author

lgritz commented Jun 18, 2020

Yeah, I'm on the fence about it. Do you think it's worth having an option to control this? Or just rip it out entirely?

@fpsunflower
Copy link
Contributor

I think its only likely to cause more confusion. I would just rip it out.

Files written the old way will fail to read the worldToScreen matrix (as some of our shaders do) - but I rather error out and force those files to be re-generated rather than try to accomodate them automagically with a heuristic that could fail in some other direction.

src/openexr.imageio/exroutput.cpp Outdated Show resolved Hide resolved
src/libOpenImageIO/imageio_pvt.h.in Outdated Show resolved Hide resolved
This seems wrong. EXR standard metadata "worldToNDC" is exactly what it
says, not screen space. I'm not sure how we ended up with the historical
accident of reading "worldToNDC" from exr headers and auto-translating
it to "worldtoscreen".

The hope is that nearly no one is affected by any of this, since the
primary use case for these matrices was shadow maps, which were never
fully implemented in OIIO's TextureSystem anyway (they were last on
the list, and the VFX world switched to ray tracing before anybody got
angry enough at my procrastination to force me to implement it).

Signed-off-by: Larry Gritz <lg@larrygritz.com>
@lgritz
Copy link
Collaborator Author

lgritz commented Jun 18, 2020

Updated a more minimal patch.

No more generation of missing matrices.

@lgritz
Copy link
Collaborator Author

lgritz commented Jun 19, 2020

I'm going to merge this as it stands now -- simply ending the silent translation of the name.

If this causes problems later and people speak up, we can always put in an option that restores the old behavior or tries to supply the missing matrices.

@lgritz lgritz merged commit fed3442 into AcademySoftwareFoundation:master Jun 19, 2020
@lgritz lgritz deleted the lg-ndc branch June 19, 2020 06:23
pixar-oss pushed a commit to PixarAnimationStudios/OpenUSD that referenced this pull request Aug 22, 2023
Oiio 2.2 made a change to how it handles worldtoscreen metadata that makes exr images generated with < 2.2 incompatible with our texture-based cards geometry implementation in usdImaging. For details on the oiio change, see AcademySoftwareFoundation/OpenImageIO#2609.

Regenerating the texture asset with oiio >= 2.2 is the "correct" fix. To aid with the transition, however, this change checks for and uses "worldToNDC" as a fallback if it fails to find "worldtoscreen". We issue a warning recommending regenerating the texture asset if "worldToNDC" is present instead of "worldtoscreen".

(Internal change: 2291623)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants