Strange shadow effects with transparent quads

[rainergericke]

In project::chrono we encountered a strange effect, when (hard) shadows are used. The simple tree objects (textured quad with transparent backgound) throw strange shadows. That doesn't seem to be logical. How can this be avoided?

Scene without shadows:

Scene with shadows:

[robertosfield]

My best guess is the trees are made up from textured quads and use alpha blending to pick out just the leaves and branches when rending to the colour buffer, but when being rendered to the shadow map no alpha discard is happening for the transparent texels so the whole quad is making it through to the shadow map.

Have a look at the material settings to see if alpha cutoff/discard is on/off.

[AnyOldName3]

If I zoom in on the edges of leaves, I can see the edge of the terrain through them, so that basically confirms they're using blending. As a bit more context, alpha blending still does a depth write for the entire triangle, even the fully transparent parts, and just makes it so the colour written is a mixture of the previous colour and the fragment colour, a bit like an octopus changing its colour to match what's behind it. Shadow mapping doesn't care about the colour, just the depth, so blending the colours doesn't stop things casting shadows.

[rainergericke]

Thanks for looking in depth. The tree objects we use are an export from a Blender model. When I look into the mtl-file, there is also a reference to an opacity map ('map_d'). Does VSG support opacity maps (maybe with a different name)?

# Blender MTL File: 'Tree.blend'
# Material Count: 2

newmtl TreeTexture
Ns 250.000000
Ka 1.000000 1.000000 1.000000
Kd 0.800000 0.800000 0.800000
Ks 0.500000 0.500000 0.500000
Ke 0.000000 0.000000 0.000000
Ni 1.450000
d 1.000000
illum 2
map_Kd textures/mapletree.png
map_d textures/mapletreeA.png

newmtl TreeTexture90
Ns 250.000000
Ka 1.000000 1.000000 1.000000
Kd 0.800000 0.800000 0.800000
Ks 0.500000 0.500000 0.500000
Ke 0.000000 0.000000 0.000000
Ni 1.450000
d 1.000000
illum 2
map_Kd textures/mapletree90.png
map_d textures/mapletree90A.png

Commenting out the map_d references the appearance changes a lot. So I see, sometimes it is better not to relie blindly to external software. I am going write a handmade piece of software for this purpose.

[rainergericke]

To be mentioned, we mostly use our own reader for wavefront files. The vehicle is read with the vsg reader. Its windows are opaque, where they should be transparent. That's a bug in assimp https://stackoverflow.com/questions/72875876/how-to-load-transparent-materials-using-assimp.

[AnyOldName3]

I don't think that StackOverflow thread is relevant - it's talking about the glTF loader (usually AssImp bugs are format-specific), and they don't confirm there's a bug, just point out that it's a possibility if it still doesn't work after checking whether a specific property is present. vsgXchange's AssImp loader isn't currently querying whether there's a dedicated alpha texture and instead assumes that if alpha blending or testing are specified, they use the alpha channel of the diffuse texture.

[rainergericke]

Here is an example for a correctly working wavefront reader:

The hmmwv obj file is the the same file used in the above pictures, look at the windows.