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

OpenEXR support #4706

Closed

Conversation

rawnsley
Copy link
Contributor

@rawnsley rawnsley commented Oct 4, 2021

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.

@rawnsley rawnsley changed the base branch from master to env-settings-fixes October 4, 2021 12:32
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)
Copy link
Contributor

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.

Copy link
Contributor Author

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.

@netpro2k
Copy link
Contributor

netpro2k commented Oct 4, 2021

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.

@rawnsley
Copy link
Contributor Author

rawnsley commented Oct 4, 2021

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.

@netpro2k netpro2k deleted the branch Hubs-Foundation:env-settings-fixes October 4, 2021 22:20
@netpro2k netpro2k closed this Oct 4, 2021
@netpro2k
Copy link
Contributor

netpro2k commented Oct 4, 2021

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.

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.

3 participants