-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
OpenEXR support #4706
OpenEXR support #4706
Conversation
This reverts commit 76165f1.
const extensionDef = textureDef.extensions[this.name]; | ||
const source = json.images[extensionDef.source]; | ||
return parser.loadTextureImage(textureIndex, source, this.loader).then(t => { | ||
// TODO pretty severe artifacting when using mipmaps, disable for now (assumption copied from GLTFMozTextureRGBE) |
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 suspect this was to do with decoding the RGBM which shouldn't be a factor here, the mips should blend more smoothly here since EXR actually uses float values from the start. Didn't test it obviously.
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.
Makes sense. I'll remove and check.
Is there any particular reason you want to use OpenEXR over Radiance HDR? My plan was to only support 1 non-compressed HDR format for now and wait for some compressed standard to solidify. |
Good question with a somewhat complicated answer: I'm exporting from Blender in EXR to preserve the maximum precision ahead of some post-processing steps that might otherwise suffer from the noise introduced by RGBE. Actually the output from that process doesn't include EXR files (because it's so verbose) so support in Hubs client isn't vital, but it would be useful for making a visual comparison of the scene before and after post-processing. I wasn't going to bother with the PR, but I realised it might have some small implications for the flipping logic. |
Did not intend to close this with the merge. But I also don't think I will land it unless there ends up being a particularly strong demand for it or something that cant be represented with a radiance HDR map, since it will just add further support burden to each part of the pipeline. |
I've added a
MOZ_texture_exr
component with a simple implementation to support OpenEXR.The caveat is that the imported textures end up being interpreted as upside down. For this reason I've branched from some of the corrective code for SDR images as it appears to be related and it's not easy to see where the various flipping should be applied.
Here's an example scene file file for testing that was exported using this pending PR for the Blender exporter.