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

Extension: Static lightmap textures #1017

Closed

Conversation

stevenvergenz
Copy link

An initial pass on an extension to provide precomputed lighting and global illumination to glTF materials. I'm going to attempt to implement this in the UnityGLTF project, but I want to run it by this group too. Thoughts?

@stevenvergenz stevenvergenz changed the title Extension: static lightmap textures Extension: Static lightmap textures Jun 13, 2017
@lexaknyazev
Copy link
Member

Since glTF is a data format, it's fine to not provide exact implementation details, but some basic data properties should be provided to enable interoperability.

So, could you elaborate a bit more about texture data:

  • grayscale or RGB;
  • alpha channel;
  • sRGB or linear colorspace.

@stevenvergenz
Copy link
Author

Updated

@stevenvergenz
Copy link
Author

After thinking about how this extension will work with a texture atlas (my primary use case), I'm considering moving this extension out of the material, and onto the node. From a data economy point of view, this makes the most sense as every node with a lightmap is going to have a separate texture from an otherwise identical but differently-placed node. This may force some engines to do a fair bit of duplication (Three.js and Blender come to mind), but it's nothing that model authors or loader contributors wouldn't have to do anyway. Lightmaps are hard in those engines.

Any objections?

@pjcozzi
Copy link
Member

pjcozzi commented Jun 19, 2017

Sounds OK to me.

@donmccurdy
Copy link
Contributor

...every node with a lightmap is going to have a separate texture from an otherwise identical but differently-placed node. This may force some engines to do a fair bit of duplication (Three.js and Blender come to mind)...

I haven't used lightmaps before, but curious what you mean by this. In three.js, can you just use the material.lightMap property in the same way that other textures are set?

@stevenvergenz
Copy link
Author

stevenvergenz commented Jun 20, 2017 via email

@donmccurdy
Copy link
Contributor

donmccurdy commented Jun 24, 2017

One side effect of moving the light maps to the node: a mesh may contain more than one primitive, and the primitives may use different materials. It will not be possible to apply the lightmap to one primitive's material but not another's.

Also, while the idea of sharing materials but allowing different lightmaps makes good sense, will editors/exporters support this? In Maya at least, lightmaps are associated with a material, so practically it seems unlikely that you would merge those materials at time of export.

EDIT: On the other hand, if environment maps will be an extension to the node (#946 (comment)) then it would not be so inconsistent to do that here.

@stevenvergenz
Copy link
Author

stevenvergenz commented Jun 26, 2017 via email

@pjcozzi
Copy link
Member

pjcozzi commented Jul 16, 2017

@McNopper OK to close as duplicate with #947 and #945?

@pjcozzi
Copy link
Member

pjcozzi commented Jul 16, 2017

Sorry, wrong PR.

@electrowolff
Copy link

Is this still being worked on? I feel like having the light map on the node is incorrect. Why would the light map be handled any different from the occlusion map, which is specified at the material level?

@stevenvergenz
Copy link
Author

I think extension work had been put on the back burner while the 2.0 spec was being finalized. Hopefully we'll see some more activity here soon?

Regarding lightmap location justification, see my previous responses. Basically, occlusion is constant for all instances of a mesh, but the lightmap is highly dependent on position/orientation/scale, which is only defined for nodes.

@electrowolff
Copy link

Maybe I'm missing something about occlusion maps, but it's not constant across mesh instances? Take a contrived example of two instances of a mesh, one out in the open and one fully inside a box. The one inside the box would be fully occluded, while the one outside is not occluded at all. Maybe what I'm saying is the occlusion map should be on the node too?

@stevenvergenz
Copy link
Author

You're technically right, but I understand that "ambient occlusion" is usually implictly self-occlusion only. So position relative to the rest of the scene wouldn't matter.

@Kupoman
Copy link
Contributor

Kupoman commented Sep 14, 2017

Ambient occlusion usually takes global lighting into account, which is what you might see in a light map. Occlusion maps for PBR are also sometimes called cavity or cavity occlusion maps, and are just based on the geometry.

@Ben-Mack
Copy link

+1 for lightmap. It especially helpful for static scene and being used a lot in games, hoping it will be implemented soon 🙏

@AnneKitsune
Copy link

👍 Anything going on here?

@donmccurdy
Copy link
Contributor

I see lightmaps have already been mentioned there, but for others in this thread, note that we are looking for feedback on the next iteration of glTF materials: #1442

@pjcozzi
Copy link
Member

pjcozzi commented Jan 25, 2019

@donmccurdy there's a lot of interest in lightmaps, e.g., #1017 (comment), does it make sense to keep this extension PR open or keep this conversation as part of next-gen PBR, #1442, potentially influenced by this PR?

@donmccurdy
Copy link
Contributor

I think lightmaps are orthogonal to next-gen PBR. If there’s enough interest and supporters to push the extension it could even be created before next-gen PBR, and (with some care) should be forward- and backward-compatible.

I don’t use lightmaps in my own workflow and can’t do this myself right now, but if interested parties want to identify both engines and authoring tools where lightmaps are supported and this extension can likely be implemented, that would be good progress.

I also think that more detail in this section is necessary:

The details of how this lightmap is applied will depend on the lighting model in use by the consumer.

With AO we’ve found some similar questions, and if those details (or the range of possibilities) can be clarified early on it will benefit implementers.

@AnneKitsune
Copy link

Currently I am using blender to bake the lightmap directly onto textures before exporting to glTF. The issue with that is that the whole baking process in blender needs to happen for each object present in the scene, one at a time, using a custom script (no built-in way to do multiple objects at once). A glTF lightmap extension would be great!

@idorurez
Copy link

Hi all, looking to see if we can start spec'ing lightmaps. Thinking of proposing FB_materials_lightmap or some extension of sort

@donmccurdy
Copy link
Contributor

@idorurez Would you be willing to open a new Pull Request and help address feedback/questions there? I think this PR stalled on time/availability. I believe a lightmap extension would still be a welcome addition to glTF, although more detail on the client implementation will be necessary. Even if some clients handle lightmaps differently today, we should do the work of understanding the most common implementations.

@idorurez
Copy link

idorurez commented Jul 23, 2019 via email

@idorurez
Copy link

idorurez commented Aug 12, 2019

Opened up a pull request, draft for a vendor spec out

#1658

@bghgary bghgary mentioned this pull request Aug 19, 2019
@donmccurdy
Copy link
Contributor

Moving this discussion to #1658 – please add feedback, needs, and comparison of implementations there!

@donmccurdy donmccurdy closed this Aug 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants