T82084 : Blender sets glTF backculling setting based on Eevee material

[julienduroure]

https://developer.blender.org/T82084

System Information Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: Intel(R) UHD Graphics 620 Intel 4.5.0 - Build 26.20.100.7263

Blender Version Broken: version: 2.90.1, branch: master, commit date: 2020-09-23 06:43, hash: rB3e85bb34d0d7 Broken: 2.83.8 LTS. Tested that the issue was the same before the new glTF exporter. Worked: NA

Short description of error Blender sets glTF backculling setting based on Eevee material. I and other Godot users have gotten confused as to why our imported glTF models appear with backculling turned off. Since this is not a general material setting, but an Eevee specific one this feels unintuitive. When you work in Blender you'll almost always want backface culling to be turned off so it's easy to work on your model, but 9 times out of 10 when you are using the model in a game engine you will want backface culling on. An option in the exporter to override the backface culling option to always be on could also be a solution.

Exact steps for others to reproduce the error export the default cube as a glTF and import it into Godot 3.2.3 and you will see that backface culling is set to off.

[julienduroure]

Setting as enhancement, because if I understand correctly, export does work, but default material setting in Blender is not the best for game engine, and you want a quicker way to change the backculling setting that change it manually in each of your material.

For information and people reading this ticket, here is documentation about how it works for now : https://docs.blender.org/manual/en/latest/addons/import_export/scene_gltf2.html#double-sided-backface-cullings

[Arnklit]

Hi Julien,

I really don't think it is correct as it is. I've been thinking about a good way of explaining it. The problem as I see it is that you are using an Eevee specific setting and exporting it out as a general material setting.

If I'm working on a game model in Blender and I have Cycles set as my render engine because I'm using it to bake textures. That setting is not shown on the material, so to change the backface culling setting for exporting my model, I would have to know to change over to Eevee rendering engine for the option to appear, that is not very logical. Now that might be a problem on Blender's side that it would make more sense if they had culling settings for materials always in the material regardless of renderer, but they don't.

[scurest]

to change the backface culling setting for exporting my model, I would have to know to change over to Eevee rendering engine for the option to appear, that is not very logical

For reference, you can find Backface Culling (along with Blend Mode/Clip Threshold which work the same way) under Viewport Display when in Cycles mode. It affects the Material Preview mode in the 3D view, but not full renders.

[Arnklit]

@scurest Ah I didn't know that. Again I feel like this is not a logical place for settings to reside that decides how the settings are set for the exported material. If you hadn't told me this, I would definitely not think that something under "Viewport Display" would actually change how a material is exported.

I think if Blender has these options spread around it would be better to not use them. Or maybe have a fold-down in the exporter where you could set the back-face culling to "On", "Off" and "Use Eevee/Viewport Display setting" or something like that.

[donmccurdy]

Hm. It's challenging that Blender presents the option under material Settings when using Eevee, then moves it to Viewport Display, with a different functionality, under Cycles. Whether it's really a material setting or a viewport setting, ultimately users are going to have one of two problems:

• A. User doesn't realize backface culling is disabled (default for new materials) and performance in their application is worse than it could have been.
• B. User doesn't know much about backface culling (not uncommon for new users) and becomes confused when their model exports with unwanted "holes."

Should we ask Blender core developers to consider treating this setting more consistently across Eevee and Cycles? Or even to change the default for new materials? It looks like the FBX addon ignores the Backface Culling setting entirely. Or at least when tested with the FBX Review viewer, backface culling is always enabled.

Or maybe have a fold-down in the exporter where you could set the back-face culling to "On", "Off" and "Use Eevee/Viewport Display setting" or something like that.

I'd be OK with this suggestion, but it still leaves us with a decision to make about the default behavior re: (A) and (B) above. I'm leaning toward considering (A) the more important problem to eliminate, since it's subtle to identify for many users, whereas (B) is easy to identify and affects mostly newer users.

[will-ca]

I think the current behaviour works great, honestly. EEVEE materials have a backface culling setting, and that setting is mapped directly to how the GLTF files are exported— Adding any extra steps to try to divine user intent when there is already such a clear and direct setting right there would only convolute usage of the exporter.

I don't think the game engine workflow argument that enabling the material setting makes it harder to work on the model really holds much water. The material backface culling setting only affects the "Rendered" and "Material Preview" preview modes. It's generally more sensible to be in "Solid" mode when you're working on a model, possibly with "Color" set to "Texture" in the viewport "Shading" menu— In which case, the material backface culling setting has no effect anyway. The only time it does have an effect is in the "Rendered" and "Material Preview" modes. There, the entire point is to preview all objects and materials as they will eventually be rendered or exported, so parts of the mesh becoming invisible based on the backface culling is part of what makes those modes useful.

Honestly, I think this entire issues seem a lot like something that could reasonably be called user error. There is a backface setting in Blender's Principled PBR material node, and that setting is exported directly and correctly to backface culling in GLTF's principled PBR materials. What is the problem there? You wouldn't try to change the Metalness settings in the exporter because the user has set it incorrectly. You wouldn't make a drop-down in the exporter to override material Roughness or colour— That's what the entire material system is for. Why should backface culling in GLTF be exported as anything other than a direct copy of its BPY value? It's just another material setting, which is currently handled correctly and sanely by the exporter.

And as someone who has some experience with 3D software in general but is also one of those "newer users" to using GLTF as a publishing format, my opinion on the two options is (A) having backface culling disabled as is currently the default in EEVEE is the more useful/robust behaviour in more cases, more likely to produce results that look good, (B) anyone whose scenes are complex enough for backface culling to be a major performance bottleneck really should know how to set it correctly anyway.

Should we ask Blender core developers to consider treating this setting more consistently across Eevee and Cycles? Or even to change the default for new materials?

I believe the current way to simulate backface culling in Cycles is with a Mix shader and a Transparency shader controlled by the Backfacing output of the geometry node. To me it seems like it would be a pretty major departure to move such a dramatic behaviour change to the core UI (like in EEVEE) or the raytracer, especially with the current trend of moving more functionality into nodes.

Cycles and GLTF are always going to be different anyway, as one's a raytracer and the other's a rasterizer. Cycles and EEVEE don't have perfect 1:1 equivalency in behaviour either. I think "Viewport Display" is actually a reasonable place for the backface culling setting to be in Cycles. Where else are they going to put a rasterizer setting which doesn't make any sense in the raytracer? The "Viewport" in Cycles is the closest analogue to the rasterizers that GLTF exports often targets.