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

MeshPhysicalMaterial: Add .transparencyMap #19389

Closed
donmccurdy opened this issue May 18, 2020 · 9 comments · Fixed by #19690
Closed

MeshPhysicalMaterial: Add .transparencyMap #19389

donmccurdy opened this issue May 18, 2020 · 9 comments · Fixed by #19690

Comments

@donmccurdy
Copy link
Collaborator

donmccurdy commented May 18, 2020

Building on #17114, I'm proposing to add a .transparencyMap property to MeshPhysicalMaterial, as a texture alternative to .transparency. The two parameters combined would allow thin-surface optical transparency workflows.

Related:

@mrdoob mrdoob added this to the rXXX milestone May 18, 2020
@WestLangley
Copy link
Collaborator

WestLangley commented May 18, 2020

I'm proposing to add a .transparencyMap property to MeshPhysicalMaterial, as a texture alternative to .transparency.

So to clarify your proposal, even if the object was uniformly transparent, a transparency map and UVs would be required. Is that what you are proposing?

@donmccurdy
Copy link
Collaborator Author

No, sorry, just the same as we do for other .foo/.fooMap pairs. Either can be used in isolation, or they're linear multipliers when both are provided.

@mrdoob
Copy link
Owner

mrdoob commented May 18, 2020

The difference in this case is that transparency is 0 by default though? Same as metalness I guess.

@WestLangley
Copy link
Collaborator

WestLangley commented May 18, 2020

I had the same concern, but I think this is OK. transparency should be set to 1 by the loader if a map is present. The map attenuates the transparency.

Edit: Well, I am not sure if the loader should set it to 1, but the user should...

It does sort of make one's head spin...

@donmccurdy
Copy link
Collaborator Author

Hm. I see what you mean.

I think it's OK, but the full list of...

  • .opacity
  • .alphaMap
  • .transparent
  • .transparency
  • .transparencyMap

... is a lot for users to understand. For what it's worth, glTF and Blender will use the term "transmission" rather than "transparency" when referring to this property. I expect the transmission property in a glTF file will also affect refraction and subsurface scattering when those features come to glTF (a fair bit later).

@WestLangley
Copy link
Collaborator

Maybe make a thin-surface material as an extension?

We should think about what types of physical materials we want MeshPhysicalMaterial to represent.

I had originally assumed that would be Metals and Plastics, and probably Ceramics. But we seem to be adding properties that allow it to model a lot of materials -- an Uber Material. I am not sure that is a good idea.

@donmccurdy
Copy link
Collaborator Author

The list in #16977 is representative of what the more advanced glTF PBR model will allow, and very similar to Blender's Principled BSDF and Autodesk's Standard Surface as well.

Whether this all makes sense for MeshPhysicalMaterial I don't know. The alternatives to uber materials have their own complexities. I do not want to add any of these new features to MeshStandardMaterial, though, I think that has a pretty good scope already.

@donmccurdy
Copy link
Collaborator Author

@WestLangley @mrdoob What do you think of renaming the .transparency parameter to .transmission? Especially since it is generally used with .transparent = false, I think transmission may be easier to understand... this seems to line up with other tools:

@mrdoob
Copy link
Owner

mrdoob commented Jun 18, 2020

That sounds good to me 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants