-
Notifications
You must be signed in to change notification settings - Fork 12
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
Supply an Image-based Light file #71
Comments
/agenda |
Sharing this new HDR file format for awareness: |
I don't remember that we agreed that version 1 needs this. |
In #72, after finding value in the addition of a JS object for a model's root element, as well as looking forward to a future where a scene graph is appealing, I'm also leaning toward using that The main benefit being that many web authors may want to override the IBL on subsets of the scene graph - e.g. a different environment map on the polished stainless steel to the lights affecting the brushed aluminum casing of a high-end desktop computer. /facetoface |
/tpac |
/agenda One question would be if / how that alters an expected event model for the loadedness of the asset. Is there a right way to manage that in 2024 (and beyond?) |
There's a new GPU-optimized HDR format now: |
At TPAC we agreed that specifying an image-based light (IBL) is an important component of a V1 implementation and specification. In addition to the specific name (environment map, lighting environment, IBL etc), there is the matter of structural representation, i.e. how it resides within the tree structure of the
<model>
markup itself.I don't have a strong opinion but some candidates I can see are:
<model>
tag:<source>
tag<model>
blockOr some more complex nesting of
<source>
elements within such a tag. It should be simple, but my expectation is that the role and complexity of<model>
will increase over time, so something expressive enough to meet some obvious needs would be useful.The text was updated successfully, but these errors were encountered: