Vertex Blending

[Springheel]

I was going to do some experiments with vertex blending, where one texture fades into transparency (rather than into another texture), but I can't find info on how to set up the material file. How do you link the alpha channel to vertex color? If anyone could point to an example of this I'd appreciate it.

[SteveL]

I'd expect you could just add "vertexColor" to your diffuse stage and simply don't add a second matching "inverseVertexColor" diffuse stage. You probably need to specify "blend add" instead of "blend diffusemap" to stop it fading to black. Your diffuse color will be multiplied by the vertex color in the range 0..1, so it almost certainly would fade to black without "blend add". If you can use a blend add material, then areas with low vertexcolor close to zero will add little to no colour i.e. be transparent.

 

So instead of a diffuse stage:

 

{
  blend    add
  map      textures/darkmod/someDiffuseTexture
  vertexColor
}

 

NB the rules will be the same as with any blended texture.. you'll need to use a blend, there'll be no lighting. If you make the material lit, the uncoloured parts will come out black not transparent. You can use lighting if you have two opaque textures blended using vertex colour. The rule is that a given pixel has to be opaque in some way to be lit, whether through an opaque colour, or alphatested (all pixels either opaque or invisible), or the translucent keyword (which alternates pixel by pixel, fully opaque or fully transparent).

[Springheel]

I thought you could have a true fade to transparency using vertex blending?

[Bikerdude]

Obsttorte is the man to talk to about this.

[nbohr1more]

Hmm, can you blend a lit and unlit material stage?

 

I believe Arcturus blended a reflective (mirror render) surface and and another surface type

[Obsttorte]

Arcturus has done this once, but it only works for translucent textures. I'm not sure it is easely doable with vertex blending, and would suggest trying makealpha. Check some of the glass textures for this.

[Arcturus]

I managed to do this with mirror material but couldn't do it with a simple diffuse texture.

[SteveL]

That makes sense. The mirror material doesn't receive any lighting, but it's showing a snapshot of a scene that did get rendered with lighting, so you have lit areas blending out.

 

The no-lit-transparencies rule is embedded in the renderer as a performance optimization by the look of it. We do an early depth pass to record how deep the solid scene is at any given pixel, then when we come to draw light effects on surfaces, only pixels that exactly match the recorded depth are drawn. Anything in front of or behind that recorded depth is not drawn. That guarantees zero overdraw for the expensive light effects. I'm not sure off hand whether it'll be possible to overcome it for individual materials, but the thing to try would be letting lit materials ask to be drawn where their depth is less than the solid geometry instead of equal to it, and by making sure they get drawn after all other light interactions, else the solid scene behind could draw over them randomly. If you let more then one of them overlap you'd get the usual problems of them being drawn in the wrong order over one another.

[OrbWeaver]

but the thing to try would be letting lit materials ask to be drawn where their depth is less than the solid geometry instead of equal to it, and by making sure they get drawn after all other light interactions, else the solid scene behind could draw over them randomly. If you let more then one of them overlap you'd get the usual problems of them being drawn in the wrong order over one another.

Admittedly it's been years since I last tested, but I thought the "translucent" keyword did allow lighting interaction with translucent materials, presumably by bumping them into a later rendering stage as you describe. The disadvantage was that it limited your ability to actually modify the level of transparency, and instead applied a hard-coded 50% blend.

[SteveL]

Admittedly it's been years since I last tested, but I thought the "translucent" keyword did allow lighting interaction with translucent materials, presumably by bumping them into a later rendering stage as you describe. The disadvantage was that it limited your ability to actually modify the level of transparency, and instead applied a hard-coded 50% blend.

 

That's right, it does allow lit transparency, but not by drawing later or blending. Instead the surface gets stippled in a tiny checkerboard pattern, one pixel opaque, the next pixel missing and revealing what's behind. That's why it's locked to 50% translucency. So it gets to draw at the same time as the usual lit surfaces because there're no blended pixels. It's just that only half the pixels are drawn into the depth buffer and subsequently coloured in.

[Springheel]

I guess I misremembered the bit about transparency.

[OrbWeaver]

 

That's right, it does allow lit transparency, but not by drawing later or blending. Instead the surface gets stippled in a tiny checkerboard pattern, one pixel opaque, the next pixel missing and revealing what's behind. That's why it's locked to 50% translucency. So it gets to draw at the same time as the usual lit surfaces because there're no blended pixels. It's just that only half the pixels are drawn into the depth buffer and subsequently coloured in.

 

Ah, that makes sense. I never could figure out precisely what it was doing, or why the technique couldn't extend to fully controllable partial transparency (with lighting), but the reason is obvious if it's just an alpha test hack.