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.

Sign up for GitHub

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

Jump to bottom

NormalMap with wrong colors? #7

Open
flamacore opened this issue Sep 17, 2020 · 1 comment
Open

NormalMap with wrong colors? #7

flamacore opened this issue Sep 17, 2020 · 1 comment

Comments

@flamacore
Copy link

Hey there, truly great plugin. Probably the only actually working one I could ever find and I'm using this with three.js :)
Strange thing is, I see normal maps are in somewhat red-ish color. Is this expected? I normally would expect to see the regular purple palette so I thought I should ask here.

Thanks a lot in advance. Attached is the exported folder.

image
@DCjr-Infy
Copy link

I had the same problem, I didnt get my albedo or roughness maps. In unity, the material is a Standard (roughness setup). Did you ever figure out what happened? I noticed that my exported object did not have the lightmap baked textures embedded. No baked data at all

modanhan added a commit to modanhan/gltf-exporter that referenced this issue Jan 7, 2022
@modanhan
Export normal maps correctly
a460e16 
This addresses Plattar#7.

I think the root cause is the temporary render texture not having the correct color space, this is after I tried the solution suggested here: https://answers.unity.com/questions/1757606/export-normal-texture-at-runtime.html but that didn't do anything. So I also tried using RenderTextureDescriptor to set the correct color space but that didn't seem to have an effect. I tried changing the Edit -> Project Settings -> Player -> Other Settings -> Color Space setting to linear instead of gamma, still nothing.

After reading some docs it's still unclear to me why a color space transformation is happening in a simple blit operation.

My solution is to copy pixel data on the CPU instead where nothing funny is happening. There are some huge performance implications because:
1. The copy is happening on the CPU instead of GPU.
2. By default textures don't have CPU read access. So for textures that don't have read access, it does a reimport first to enable it, and another reimport after the copy to disable it again. This slows down the script even more significantly than the CPU copy.
@modanhan modanhan mentioned this issue Jan 7, 2022
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@flamacore @DCjr-Infy