Request: doge2 as the default IBL

[echadwick-artist]

I would prefer to have "doge2" as the default IBL.

While the current default "papermill" may be the prettiest in reflections, "doge2" casts the least amount of color onto the model, which helps when judging material colors. "papermill" and "field" cast significant green/orange/blue colors, making it difficult to judge the color accuracy of a model, especially something off-white. Is it a warmer white, or a cooler white? Hmm.

Thanks!

[donmccurdy]

I would suggest two additional IBLs from this site: http://www.hdrlabs.com/sibl/archive.html

• Footprint Court
• Helipad GoldenHour

The first is included with the threejs and BabylonJS viewers, which makes comparison easier for us. The second has been suggested previously by PlayCanvas.

[ghost]

I've been wondering on what we should do with these environment maps for a while now, at least in the long run. I really don't like the idea to have these binary assets in Git repositories with code, since they really clutter up the Git history and make cloning the repository take ages. Also, some people might not even want to have the environment maps we bundle. It's the same reason why there are no models bundled anymore, and that is instead left to the glTF-Sample-Models repository which does a better job at this. Instead we optionally let the user fetch it via a submodule, which leaves our Git history clean (and up-to-date with upstream, no need to manually sync).

For now it's fine for us to bundle the environment maps (and I definitely think we should have the ones Don has mentioned, to compare with BabylonJS and other major viewer), but for the future, I would like to see a repository that somehow has "most" of the environment maps used by the major glTF viewers, something like a glTF-Sample-Environments so that we can have a common repository of environment maps to compare against. This means the repo will not be cluttered anymore with these binary assets, and also made optional to the user (the real reason to do this IMHO, if we want this reference viewer used for other things as well).

Of course, that would mean we might have to run this repository through e.g. BFG Repo-Cleaner as well.

It would be awesome if a user could clone this repo, only the "core" reference viewer, and optionally fetch the models and environment maps. This would make the repo fast to clone, keep the history clean (mostly only text, which Git likes, with maybe a few screenshots and stuff like LUTs), and also be very slim in size.

[donmccurdy]

Agreed. Certainly we won't want to include environments in the NPM package.

Perhaps a good starting point would be to add an Environments/ folder to glTF-Sample-Models, so the existing submodule can bring in environments?

[ghost]

That's a very good idea Don! I think that's even better than having a completely separate repository for it!

[emackey]

That sample model repo is over a gigabyte in size now. Not sure what the ultimate size limit might be.

[emackey]

But +1 for getting them out of this repo, so long as they're in a standard format that everyone can use. Right now it looks like Babylon, Cesium, Three, and this reference viewer each have their own separate standard of how these things should be stored.

[emackey]

BTW I have a suggestion for how to store them: glTF.

Specifically, an "empty" glTF that contains only the EXT_lights_image_based extension, and the associated assets for the environment. Then you could load an environment from one glTF file and a model from another glTF file into the same viewer.

We would, of course, need buy-in from across the ecosystem to make that work, but I think it would be an easy sell.

[donmccurdy]

GitHub does offer an LFS option (https://git-lfs.github.com/, https://help.github.com/articles/configuring-git-large-file-storage/) for situations like this, but it may introduce some hassle. 1GB is pretty close to the limit for non-LFS repositories already, but I don't think a few IBLs are going to make too much difference there, and keeping things together still sounds easier to me.

I haven't tried implementing EXT_lights_image_based in threejs yet, but I don't think there should be any technical issues there. To me the larger question is whether we want to encourage the ecosystem to distribute and use standalone IBLs in glTF containers, and to what extent we want to canonize EXT_lights_image_based in its current form? Does KTX2 make more sense for this, long term?

[lexaknyazev]

KTX2 can store all mip levels and cube faces in one file. We'll need a new IBL extension for that (or to make an extension for existing IBL extension)

[echadwick-artist]

It looks like Doge2 is no longer the default IBL. Can we get it back as the default again?

Also the punctual light is off by default. It would be helpful if it was enabled by default (see #129)

[ghost]

That was me by accident – I always use the LDR map when developing because it loads so much faster. It's back to Doge2 now. Any thoughts on the punctual lights default @UX3D-nopper ?

[echadwick-artist]

We could down sample Doge2 into LDR to make it load faster.

Besides being better because it's less colorful/more neutral, it's also nice that it has no strong light sources, which means it can probably be LDR without much loss at all.

[ghost]

I really like this idea!

[emackey]

Is there any way to speed up HDR loading? Settling on LDR reference images would be setting the bar pretty low for a format that wants to lead the way in interoperable PBR.

[ghost]

The main problem isn't even that HDR loading takes long, but that we do it for every single model, even if the environment map stays the same. We have a separate issue for this #124 .

[ghost]

Speeding it up would of course help, but I don't know if we can.

[ghost]

@emackey Punctual lights are now active by default only if the WebGL extension EXT_shader_texture_lod that is required for IBL is not available.