Query Seamless Cubemap Support for WebGL1

[mattdesl]

FireFox Nightly recently introduced seamless cubemaps, and enabled it in a way that works in WebGL1 contexts. It seems like other browsers (Chrome, Edge) intend to match this behaviour, which means this feature might be usable soon in a lot of WebGL1 apps.

This is good news for physically based rendering, since ThreeJS is currently having to work around the cubemap seams by jumping through various hoops (packing LODs and faces into a 2D texture and manually interpolating).

It would be neat if there was a function or reliable way to query/detect for this feature in the WebGL1 contexts, so that ThreeJS and other engines could use an optimized path when possible, e.g. just a single texture fetch with textureCubeLodEXT.

[kdashg]

My understanding is that Chrome and Edge already have this behavior, but I haven't tested this.
I don't know what Safari's plans here are.

We could add a querying extension that exposes whether or not cubemap filtering is seamless.

[kenrussell]

There is a compatibility difference in this area between ES 2.0 and 3.0, and consequently, between WebGL 1.0 and 2.0.

ES 3.0 specifies that cube map filtering is always seamless. This is a compatibility difference from ES 2.0. It is mentioned in ES 3.0.4 section F.2:

"OpenGL ES 3.0 requires that all cubemap filtering be seamless. OpenGL ES 2.0 specified that a single cube map face be selected and used for filtering. See section 3.8.9."

The behavior isn't described clearly in the ES 2.0 spec as far as I can tell, mainly because seamless cube maps didn't exist as a concept when that spec was written.

WebGL 1.0 is therefore always supposed to expose "seamful" (?) cube maps. Unfortunately, there are some situations in which it is simply not technically feasible to do so. The primary one is ANGLE on top of Direct3D 11. There is no way to disable seamless cube maps in D3D11, so ANGLE strictly speaking can not implement the conformant ES 2.0 behavior. However, there are no conformance tests for this at the ES 2.0 or WebGL 1.0 level so this went unnoticed for a very long time -- basically, until people started doing physically based rendering and needed seamless cube maps.

WebGL 2.0 is going to clear up this ambiguity by exposing seamless cube maps everywhere. I would like to please request that we not change the defined WebGL 1.0 behavior or add some kind of implicitly-enabled extension describing seamless cube maps to that environment (which would be the only way to do this -- it's not possible to port GL_ARB_seamless_cube_map to ES/WebGL because the enable bit can not be implemented on these platforms). It will be a distraction toward shipment of WebGL 2.0 which we can not afford at this time. Please assume that if you are running WebGL 1.0 that you have to perform manual cube map filtering.

I'm going to close this issue. Please reopen it if there are strong objections.

[kenrussell]

P.S. Firefox nightly should not be exposing seamless cube maps to WebGL 1.0 contexts except in those situations where it's absolutely infeasible to avoid. As described above, this should basically just be on ANGLE on Windows. Let's please not introduce implementation differences in this area at this point in time.

[MarkCallow]

The behavior isn't described clearly in the ES 2.0 spec as far as I can tell, mainly because seamless cube maps didn't exist as a concept when that spec was written.

WebGL 1.0 is therefore always supposed to expose "seamful" (?) cube maps.

Indeed the ES 2.0 spec is not clear and there is no conformance test. This resulted in several ES 2 implementations implementing seamless cube mapping. Existence of these, and the fact the behavior is clearly preferable, is why ES 3.0 mandated seamless cube mapping. Unless the WebGL 1.0 spec has a clarification calling for seamful, then it is in the same fuzzy space as ES 2.0. If we can't clarify it to require seamless, a querying extension seems like a reasonable solution.

[kenrussell]

There is no reliable way to determine whether an ES 2.0 implementation supports seamless cube mapping without creating a cube map texture, generating mipmaps for it, rendering from it, performing a ReadPixels and checking the result. While I understand that it would be convenient to add this code to WebGL implementations and use it to advertise (and auto-enable) a "WEBGL_seamless_cube_map" extension, I remain not in favor of doing so since it will be a distraction. If someone would like to write the minimal WebGL code to do this detection we can file requests for enhancement against the various browsers. Reopening this issue; feel free to attach a file implementing this.

[zhenyao]

WebGL's extension always requires an explicit call to enable the related functionality; this is to force developer awareness that the functionality isn't available everywhere.

However, in this case we can't disable it, so it is not aligned with WebGL extension philosophy.

I vote that we tell developers to assume seamful everywhere in WebGL 1, and do not expose an extension for that.

[MarkCallow]

I vote that we tell developers to assume seamful everywhere in WebGL 1, and do not expose an extension for that.

How can you guarantee the cubemaps will be seamful?

[zhenyao]

We don't, but developers always implement their own sampling method if they want seamless (i.e., always assume seamful).

[kdashg]

I actually think we should add a signifier ext for this. (or at least some way to query it)
Seamless is valid in ES2, since it's not specified as seamful.
It's useful to know whether WebGL's providing seamless so as to avoid reimplementing seamless.

[zhenyao]

If a developer wants their content to run everywhere, they will need to implement seamless by themselves anyway. If they don't care, then they can just boldly hope their clients' driver support it. No need to query it.

[mattdesl]

@zhenyao the purpose of the extension would be so that engines (eg ThreeJS) can choose an optimized rendering path if the browser supports seamless cube maps.

The current ThreeJS PBR material requires a pretty slow/clunky workaround to fix seamful contexts.

[zhenyao]

If that's the case, then a query sounds good to me.

However, we found seamless cubemap is buggy on certain drivers (for example, Mac Intel), so the situation will be less perfect than you would expect even if we expose this bit of information.

[makc]

seamless cube maps didn't exist as a concept... Firefox nightly should not be exposing seamless cube maps to WebGL 1.0 contexts

Someone did not do their job back then - so let's do nothing now and let it slide. There is probably no single developer on the planet who actually wants seams, but who cares, right? Seams must stay, absolutely.

we found seamless cubemap is buggy on certain drivers (for example, Mac Intel)

actually, I get no seams in nightly ff / 2009 mac, and was referred to this issue by someone who does have seams on another device.

until people started doing physically based rendering

I don't know why you guys think this is limited to PBR, btw. The one who referred me here was just trying to do a skybox.

[zhenyao]

See #1819 for the Mac Intel driver bug.