GLTF Glass Materials Render Without Volume on Windows/OpenGL (v1.68.4)

[0xcode-lasagna]

Description:

I'm experiencing an issue where GLTF models with glass materials appear to render without any volume-they look flat or like dull plastic-when using Filament 1.68.4 on Windows with OpenGL as the backend.

Platform:

Windows
OpenGL backend
Filament version: 1.68.4

Repro Steps:

1. Apply graphics setting to AR's View, that renders GLTF model (attached below).
2. Render an AR model and feed to a texture using an image.mat material (attached below).
3. Use this texture as a parameter for another on-screen material.
4. Use the Dragon Attenuation model for testing.
5. The rendering pipeline uses multiple render targets in the same render loop.

Expected Behavior:

The glass material should appear volumetric, as it does in the minimal boilerplate project (it uses the same settings, and the model renders correctly there.).

Actual Behavior:

The glass material looks flat, similar to dull plastic.
This effect can also be reproduced by setting hasVolume, hasVolumeThicknessTexture, and hasDispersion to false in the filament::gltfio::MaterialKey config.
setScreenSpaceRefractionEnabled is enabled for the view.
The same behavior occurs with both Ubershader and JIT material providers.

Additional Info:

GraphicsSettings

struct GraphicsSettings
{
  // standalone View settings
  filament::AntiAliasing antiAliasing = filament::AntiAliasing::FXAA;
  filament::Dithering dithering = filament::Dithering::TEMPORAL;
  filament::ShadowType shadowType = filament::ShadowType::PCF;
  bool postProcessingEnabled = true;

  // View Options (sorted)
  filament::AmbientOcclusionOptions ssao = { .enabled = true };
  filament::ScreenSpaceReflectionsOptions screenSpaceReflections = { .enabled = true };
  filament::BloomOptions bloom = {
    .strength = 1.0f,
    .enabled = true,
    .lensFlare = true,
    .ghostThreshold = 2.f,
    .haloThreshold = 2.f,
  };

  filament::DepthOfFieldOptions dof = { .enabled = true, .nativeResolution = true };
  filament::DynamicResolutionOptions dsr = { .minScale = { 1.f, 1.f },
                                             .maxScale = { 2.0f, 2.0f },
                                             .sharpness = 0.9f,
                                             .enabled = false,
                                             .quality = filament::QualityLevel::LOW };
  filament::FogOptions fog;
  // #  if !defined(__EMSCRIPTEN__) && !defined(__EMSCRIPTEN_PTHREADS__)
  filament::MultiSampleAntiAliasingOptions msaa = { .enabled = true, .sampleCount = 4 };
  // #  else
  //   filament::MultiSampleAntiAliasingOptions msaa = { .enabled = false };
  // #  endif
  filament::RenderQuality renderQuality;
  filament::TemporalAntiAliasingOptions taa = { .enabled = true };
  filament::VignetteOptions vignette = { .enabled = false };
  filament::VsmShadowOptions vsmShadowOptions = { .anisotropy = 0 };
  filament::GuardBandOptions guardBand;
  filament::BlendMode blendMode = filament::BlendMode::TRANSLUCENT;

  filament::View* Apply(filament::View* view) const;
};

// Actual graphics settings for AR model rendering
{
  .postProcessingEnabled = true,
  .ssao = { .enabled = false },
  .screenSpaceReflections = { .enabled = false },
  .bloom = {
    .dirtStrength = 1.0f,
    .strength = 1.0f,
    .blendMode = filament::BloomOptions::BlendMode::INTERPOLATE,
    .threshold = true,
    .enabled = true,
    .lensFlare = false,
    .chromaticAberration = 0.03f,
    .ghostThreshold = 0.000000002f,
    .haloThreshold = 0.000000002f,
  },
  .dof = { .enabled = false, .nativeResolution = true },
  .dsr = { .minScale = { 1.f, 1.f }, .maxScale = { 2.0f, 2.0f }, .sharpness = 0.9f, .enabled = false, .quality = filament::QualityLevel::LOW },
  .fog = {},
  .msaa = { .enabled = true, .sampleCount = 4 },
  .renderQuality = {},
  .taa = { .enabled = false },
  .vignette = { .enabled = false },
  .vsmShadowOptions = { .anisotropy = 0 },
  .guardBand = {}
},

image.mat

material {
    name : image,
    parameters : [
        {
            type : ${FEED_SAMPLER},
            name : image
        }
    ],
    requires : [
        uv0
    ],
    flipUV : true,
    depthWrite : false,
    colorWrite : true,
    shadingModel : unlit,
	variantFilter : [ directionalLighting, dynamicLighting, shadowReceiver, skinning, fog, vsm ],
    culling: none,
    depthCulling : false
}


fragment {
#if USE_SAMPLER_EXTERNAL
    vec3 sRGB_to_linear(highp vec3 color) {
	     return  vec3(
            color.r <= 0.04045 ? color.r / 12.92 : pow((color.r + 0.055) / 1.055, 2.4),
             color.g <= 0.04045 ? color.g / 12.92 : pow((color.g + 0.055) / 1.055, 2.4),
             color.b <= 0.04045 ? color.b / 12.92 : pow((color.b + 0.055) / 1.055, 2.4)
         );
        //return vec3(pow(color.r, 2.2), pow(color.g, 2.2), pow(color.b, 2.2));
        //return color;
    }
#endif
    
	vec3 imageColor(highp vec2 uv) {
        uv = vec2(uv.s, 1.0 - uv.t);
        // We need to convert extneral texture to linear space 
        // (in case of internal texture - we do it with hardware automatically based RGB8_A8 format)
#if USE_SAMPLER_EXTERNAL
            return sRGB_to_linear(texture(materialParams_image, uv).rgb);
#else
            return texture(materialParams_image, uv).rgb;
#endif
	}
	
    void material(inout MaterialInputs material) {
        prepareMaterial(material);
        highp vec2 imageUV = getUV0();
        if (imageUV.x > 0.0 && imageUV.y > 0.0 && imageUV.x < 1.0 && imageUV.y < 1.0 ) {
            material.baseColor.rgb = imageColor(imageUV);
            material.baseColor.a = 1.0;
        }else{
            material.baseColor = vec4(0.0, 0.0, 0.0, 1.0);
        }
    }
}

I'm happy to provide code snippets or further details if needed.

Question:

Is there something I'm missing in the pipeline or material configuration that could cause this? Any hints or suggestions would be greatly appreciated!

[romainguy]

@pixelflinger

[pixelflinger]

is the problem only limited to windows + opengl? Or have you not tested elsewhere? (e.g. have you tested windows+wk) or on Macs.
It definitely renders properly in gltf_viewer on mac+gl:

Have you tried our sample gltf_viewer, does it render correctly there?

[0xcode-lasagna]

Yes, I've tried the gltf_viewer from samples and it works correctly. The minimal boilerplate project replicates basic functionality of gltf_viewer, but uses the same post-processing preset and multiple render targets as our proprietary project. It also renders correctly.

Backend-wise, we always use OpenGL. The primary development platform is Windows, and we also ship a WebAssembly build targeting OpenGL ES (WebGL). The bug reproduces there as well.

[0xcode-lasagna]

Small update: I simplified the render-target chain, and now I render the glTF model and the feed quad directly to the screen. The bug is still present. As I mentioned above, it reproduces with both the Ubershader and the JIT material providers.
I've also checked AssetLoader::getMaterial() - all refraction-related flags (e.g., hasVolume) are true, but it feels like they get dropped/ignored later in the pipeline.
Could you point me to where this might happen, and what I should look at first?
Thanks in advance.

[pixelflinger]

No I can't point you anywhere because I don't understand how that could happen; especially if it works in gltf_viewer and the minimal project. So the only place it doesn't work is in your larger project?

[0xcode-lasagna]

Hey @pixelflinger, I found the root cause.

The material volume parameters volumeThicknessFactor and volumeAbsorption aren't being scaled with the model.

The key difference between our project and gltf_viewer is that we scale the model by 100 (our tracker returns distances in centimeters, while glTF models use meters). We apply this scale by setting a scaled transform matrix on the root element via TransformManager (scaling the diagonal elements of the transform matrix).

To keep the same volume/material appearance, we need to:

• multiply volumeThicknessFactor and attenuationDistance by the scale factor, and
• then recompute volumeAbsorption.

AssetLoader code snippet

Question: what’s the proper way to handle this? Should this scaling be addressed on Filament’s side, or is it expected to be handled by the application pipeline?

For now, my workaround is to update these MaterialInstance parameters after applying the model scale.

[pixelflinger]

Ah yes. You're going to have the same problem with lights (radius).

My take is that this scalling shouldn't be done by the engine because we can't know what your intention is.

That said, one complication is that material instances can be shared between objects and they could have different scaling (which suggests the engine should do it).

I think we should look at two things:

1. What other engines are doing
2. How this affects glTF

There is also the issue of even knowing what scaling to apply. And breaking existing apps.

I need to think more about this. Thank you for the investigation.

[romainguy]

An alternative could be what we did in a way for spotlight: an attribute to toggle scaling compensation or not (spotlights can be configured so the perceived intensity stays the same no matter the cone angle).