 |
It's specifically portal sky that hides the foreground decals. Caulk sky shows them up ok. Caulk sky draws before *anything* in the scene. Portal sky draws later.. is it drawing after the decals? |
|
|
Yes the crack decal is being painted before the portalsky. Not immediately clear why that is since portalsky has a sort of 2 and the decal uses decal_macro which should give it a sort of 1. |
|
|
I'm parking this for later because it's confusing and taking too much time. No doubt all this can be untangled. Mysterious findings so far: The decals are drawn with sort 0, because they're translucent and therefore light-interacting. Their sort parameter is ignored. The decal is drawn by the translucent interaction code -- confirmed. But it doesn't behave translucent. The black parts do not darken the background by 50%. On the other hand, the cracks are not visible in 0 light. They need light but they don't respond to the player lantern??? Heat haze gets applied afterwards, after all the above and it should distort all the above. |
|
|
"But it doesn't behave translucent. The black parts do not darken the background by 50%." That was a misunderstanding on my part. TDM doesn't use screen-door translucency for lit transparencies, it uses an additive blend, adding the brightness of the lit translucent surface to the colour of the solid background. Portalsky draws after lit transparencies, and it draws all over the solid surface that it's on, and it wipes out the lit decal in front that got drawn earlier. Caulk sky doesn't have the problem because it doesn't re-draw the sky over its surface. It doesn't draw anything, it simply exposes the earlier rendering pass that drew the skybox all over the screen at the beginning of the frame. The only way to fix this would be to change the glass crack decal so that it's no longer light-interacting, so it has a constant brightness. But that would make it look like it's glowing strangely in dark places unless the mapper tweaks the rgb settings. Hmm, I'm not sure it should be fixed. I suspect that mappers would have to mess with settings more often after the fix than they would without the fix. |
|
|
Actually there could be a fix: make portal sky draw with an additive blend too, instead of the default opaque (GLS_SRCBLEND_ONE, GLS_DSTBLEND_ZERO). Normally portalsky will be drawing on black anyway, so it'll make no difference. Only 1 solid surface is ever drawn on any given pixel: the surface that matches the depth buffer. The only time there'd be some colour already in the buffer is when a light-interacting translucent surface has been drawn onto the same region of screen as the portalsky. The other time would be when portalsky is z-fighting with some other surface, but mappers will fix that. |
|
|
That worked, in a test map and in a fly-through of WS2 which has complex skies. Rev 14380 /trunk/materials/tdm_portal_sky.mtr |
|
|
Re-opening because the portalsky texture is now transparent in DR, which isn't desirable. |
|
|
I've added a hack to stop portsky being transparent in DR -- added a diffusemap stage with a condition that means it'll never be drawn in game. I'll leave the tracker open while I consult on whether there's a better fix in the dev forum. at rev 14395 /trunk/materials/tdm_portal_sky.mtr |
|
|
Feedback was the hack is preferable to the transparency. |
- Anonymous
