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

Reflections not working in glTF #561

Closed
silvainSayduck opened this issue Mar 4, 2019 · 22 comments

Comments

Projects
None yet
3 participants
@silvainSayduck
Copy link

commented Mar 4, 2019

I have tried a few glTFs which use materials with metallicFactor and roughnessFactor, and the environment map is not visible in the reflexions, which is what normally gives the metallic and/or glossy appearance. I use <ViroLightingEnvironment /> - which is working since I can see the object and there are no other light source in the scene - it's just without any visible reflexions.

This is a basic example: a simple cube, with fully metallic, fully glossy material.

You can see how that it should look by using https://gltf-viewer.donmccurdy.com.
And here is a screnshot from my app:

Here is also the environment map I am using.

@dam00n

This comment has been minimized.

Copy link
Contributor

commented Mar 5, 2019

Hi @silvainSayduck, not sure if the files you attached came through correctly. Can you email them to support@viromedia.com instead.

Also, are you assigning materials like the example below under ViroMaterials?

boombox : {
      lightingModel: "Constant",
      diffuseTexture: require('./res/gltf/BoomBox_baseColor.png'),
      roughnessTexture: require('./res/gltf/BoomBox_Roughness.png'),
      normalTexture: require('./res/gltf/BoomBox_normal.png'),
      metalnessTexture: require('./res/gltf/BoomBox_Metallic.png'),
    },
@silvainSayduck

This comment has been minimized.

Copy link
Author

commented Mar 5, 2019

Hi,

Thanks for the answer! I have now also sent the files by email, but they should be correct. The main thing is that this basic example does not use any textures at all, it's just using the values (factors as they are called in glTF), as in a "true" PBR model.

In any case, the documentation is in fact a little unclear on the need to manually create materials with ViroMaterials and/or manually pass resources={[ ... ]} to <Viro3dObject /> when using type="GLTF" or type="GLB". Could you clarify that?

I do hope none of that is needed, and it is handled under the hood, as obviously, those materials are contained within the GLTF file, and should ideally be created automatically instead of requiring the user to open and parse the gltf (or worse glb) file, and manually recreate ViroMaterials from the contained materials. That would pretty much defeat the entire point of using a format such as glTF.

Thanks a lot once again for the great work and your help :)

@dam00n

This comment has been minimized.

Copy link
Contributor

commented Mar 5, 2019

Thanks for the file. We are seeing the same issue on our end and will have to investigate further. There are some features of GLTF we do not support at this time, it was not clear if your file was using any of the limitations listed at the end of this section -> https://docs.viromedia.com/docs/3d-objects#section-gltf

You are correct. I did not realize how the file was outputted originally. For this file, the following should work (though it is appearing white-ish at this time)...

<Viro3DObject
      scale={[.1, .1, .1]}
      position={[0,0,-1]}
      source={require('./res/gltf/chrome_cube.gltf')}
      resources={[require('./res/gltf/f5f5f0cef97735ca45d3dd7dd3a61230710e93dee636f041fee6e8043d183d86-original.bin'),]}
      type="GLTF"
        />
@silvainSayduck

This comment has been minimized.

Copy link
Author

commented Mar 5, 2019

Hi,

Just wanted to say that in theory, this is really a super simplistic model, so it shouldn't use any of the features listed as not yet supported. It's basically just a (very simple) bin file, on which the metallicFactor is set to 1 and the roughnessFactor to 0.

Also, there is in fact no need to set the bin in the resources prop manually - which is good - at least the cube is showing up without it for me.

Please let me know if you find any workaround to makes reflections appear using the "GLTF" type.

@silvainSayduck

This comment has been minimized.

Copy link
Author

commented Mar 10, 2019

Hi,

Is there any progress on this? My initial thought was that metallicFactor/roughnessFactor were (wrongly) ignored because there was no texture, but I have now tried this same cube with a plain white texture as metallicRoughnessTexture, and the results are still the same than on the screenshot above.

This makes the glTF format rather unusable currently, unless I am doing something completely wrong here...

Using GLB also yields the same results. Also, baseColorFactor and baseColorTexture are working as expected.

<Viro3DObject
  source={{ uri: localGltfUrl }}
  type="GLTF"
  onLoadEnd={this._onLoadEnd}
  onError={this._onError}
  visible={visible}
/>
<Viro3DObject
  source={{ uri: glbUrl }}
  type="GLB"
  onLoadEnd={this._onLoadEnd}
  onError={this._onError}
  visible={visible}
/>

Here are the test models of the cube with the white texture:

Thanks a lot in advance for any information you might have :)

@silvainSayduck

This comment has been minimized.

Copy link
Author

commented Mar 11, 2019

I made a couple additional tests, and maybe they can help you figure out the issue(s).
My scene only has an HDR envMap, no other light.

  • changing the HDR environment map does not fix any of the issues, although it does change the rendering slightly, so I'm assuming the maps are somehow loaded in the scene.
  • when not using textures, the metallicFactor and roughnessFactor seem to be ignored. Whether metallicFactor is 0 or 1 and/or roughnessFactor is 0 or 1, the rendering is the same. This results in some inconsistencies (see below).
  • when using a metallicRoughnessTexture, the [metallic|roughness]Factors seem to be ignored. With a white texture, all renderings are always the same, independently of their values.
  • setting metalness with a texture seems to work: a white texture makes the product appear more metallic than a black texture.
  • a black texture for roughness makes the product appear all black, instead of fully glossy. A white texture seems to work as expected. This is the main issue.

Here's the cube using a half white / half black roughness texture.
The desired outcome:

In my scene

One thing to notice is that because of the ignored metallicFactor, the cube on the lower part is wrongly fully metallic.

@dthian

This comment has been minimized.

Copy link
Contributor

commented Apr 1, 2019

Hi @silvainSayduck, thanks for reaching out. I've been investigating this issue and have found a bug with the way gltf models are applying direct metal / roughness values. I've patched a fix and this will be fixed in the next release. Here is an image showing the fix:

2019_04_01_13_03_41

As a mitigation, (if your model is a single node) you might be able to apply pbr values directly to the texture you are overriding the model with. For example, 3d models can materials with pbr values.

@silvainSayduck silvainSayduck changed the title Reflexions not working in glTF Reflections not working in glTF Apr 2, 2019

@silvainSayduck

This comment has been minimized.

Copy link
Author

commented Apr 2, 2019

Hi!

Thanks for this great news, I'm eager to try it. Is there any way to get access to a pre-release version?
The screenshot you sent looks great, and I assume you have also been trying all the use cases (only a roughnessFactor or metallicFactor, factor & texture channel, only texture channel, neither)?

Regarding your workaround, I am not sure exactly what you suggest, but I understand that I could basically manually create the material using ViroMaterials.createMaterials? The problem with this is obviously that I would have to parse my glTF file, which makes the value of using glTF fairly minimal. In any case, I can definitely wait at this point for the proper fix.

Once again, thanks for the great work, I am looking forward to trying this and being able to render complex models using glTF with this next release :)

@dthian

This comment has been minimized.

Copy link
Contributor

commented Apr 3, 2019

Hey @silvainSayduck, we are currently preparing an upcoming patched release that should be ready next week.

We do have internal tests with some of the gltf samples containing both metal and roughness channel textures.

Having said that I'll update this issue once the patch has been pushed to release.

@silvainSayduck

This comment has been minimized.

Copy link
Author

commented Apr 3, 2019

Great to hear, thanks again!

@dam00n

This comment has been minimized.

Copy link
Contributor

commented Apr 11, 2019

This has been fixed in the latest release, ViroReact 2.14.0 | Release notes and upgrade instructions here -> https://docs.viromedia.com/docs/releases

@dam00n dam00n closed this Apr 11, 2019

@silvainSayduck

This comment has been minimized.

Copy link
Author

commented May 13, 2019

Hi,

I finally got around to update my project to the latest version, and it seems that this didn't fix my issues. My non-rough materials are still completely black. In fact, it seems that more materials are now completely black, when previously some where fine apart from missing the reflections.

There also seem to still be visual differences between materials with no roughness/metalness map, and one with fully white channels in the map.

I'm thinking that maybe I did not update correctly, since this seem pretty ciritical still, and I will proceed to a more in-depth analysis and report tomorrow. But I thought I would also first ask if there was anything that I could have missed while updating from 2.13 to 2.14 (changes to the HDR environment or to the glTF materials, ...)? Could you maybe share an HDR envMap that works for you, as I'm also thinking this whole thing could come from my environment map...

Thanks in advance, I'll come back with more details as soon as possible.

@silvainSayduck

This comment has been minimized.

Copy link
Author

commented May 14, 2019

Hi @dthian and @dam00n,

As promised, I dug a little deeper, and can confirm that this is still not working fully properly, although there has in fact been some improvements!

The reason why I still thought reflections were not working at all was that my tests were originally just testing 0 and 1 values. However, it turns out that reflections are now working as expected, unless roughness is too low, something like under 0.05.

I used this cube with a linear gradient as the roughness texture, from 1 (top) to 0 (bottom), and you can see that the bottom of the cube becomes fully black under a given roughness threshold.

I guess for now, I can work around this issue by making sure that none of our models are using roughnessFactor values under 0.05 - but this is obviously not the expected behaviour, and it would be helpful to be able to use 0 roughness for fully glossy materials :)

Here is the glTF of the cube, and a screenshot from the three.js glTF online Viewer:

Thanks again for all the help and great work!

PS: As I noted in my previous comment, there seem to still be some other issues with the glTF format, but I created another dedicated issue: #623

@silvainSayduck

This comment has been minimized.

Copy link
Author

commented May 15, 2019

I have now made a precise test, and it's indeed roughness <= 0.05 that causes the material to go full black. A cube with roughness 0.06 works as expected, a cube with roughness 0.05 is all black.

@silvainSayduck

This comment has been minimized.

Copy link
Author

commented May 22, 2019

Hi @dthian and @dam00n,

Could you guys reproduce the issue(s) on your end? Any timeline on a possible fix for this?

Thanks a lot in advance!

@dthian

This comment has been minimized.

Copy link
Contributor

commented May 22, 2019

Hey @silvainSayduck, that is interesting, much thanks for your testing and observations - it is greatly appreciated. I've also started to see this behavior in another bug that I am looking at. Will get back to you once i've root cause the issue.

@silvainSayduck

This comment has been minimized.

Copy link
Author

commented Jun 11, 2019

Hi @dthian! Nice to hear that you have been able to reproduce on your end :) Any estimate on a fix release?

Thanks again!

@dthian

This comment has been minimized.

Copy link
Contributor

commented Jun 12, 2019

Hey @silvainSayduck, np! :) Unfortunately, the next release date is yet unknown, but we'll let you know as soon as we've determined one!

@silvainSayduck

This comment has been minimized.

Copy link
Author

commented Jun 12, 2019

Alright, thanks for the heads up! You wouldn't even have a rough estimate to share at this point?

@silvainSayduck

This comment has been minimized.

Copy link
Author

commented Jul 17, 2019

Hi @dam00n and @dthian,

Great work with the latest release!

I have some more information about this bug. I have been able to test on an iPhone 8, and everything seemed fine! This is probably a model-specific problem then.

That being said, using 2.15.0, the roughness under 0.05 still does not work on iPhone 7. When roughness factor <= 0.05 or if the value in a roughness texture <= 0.05, the material still appears all black (and also breaks the depth buffer actually, as it always appear on top of everything).

It may be worth noting that while using the gradient texture makes the material appear fully black on the edge where the values are under 0.05, a fully black roughness texture successfully makes the material fully glossy even on iPhone 7.

This was already the exact situation on 2.14.0 (I just tested again).

@dam00n

This comment has been minimized.

Copy link
Contributor

commented Jul 17, 2019

Hi @silvainSayduck, we filed a new issue for the roughness under 0.05 not working on iphone 7 -> #673

Will take a look and report back on that issue

@silvainSayduck

This comment has been minimized.

Copy link
Author

commented Jul 17, 2019

Awesome, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.