Auxiliary bitplanes and Transparency

I’m using a setup like this

colorTex = Texture()
auxTex = Texture() 
final_quad = manager.renderSceneInto(colortex=colorTex, auxtex=auxTex) 

to store some extra data in the ‘auxtex’, using shaders (glsl) like this:

//fragment of a fragment shader
gl_FragData[0] =vec4(color.rgb, alpha);   
gl_FragData[1]=vec4(fog, shadow, specular, distortion);

And that works fine for most cases… except water. The data written to the auxtex is overwritten by the data from my terrain.
My water plane is somewhat transparent and intersects the terrain mesh. The terrain has an omni bounding volume and I think that may cause a sorting problem or something (I don’t know really).
I don’t know how to bite this problem.

…and there’s one more thing with transparency. If I have an egg file with format { rgba } or RGBA color with A!=1 or an explicit alpha mode set in the egg file, I can’t override the transparency setting from python (with node.setTransparency(TransparencyAttrib.MAlpha)). Can’t say for sure but I think it only happens on nodes with a glsl shader (I know it used to work, but I haven’t been using glsl in the past).

To avoid sorting issues when rendering transparent water, you should simply force the water plane to be rendered last, and/or disable depth write for it. The depth test will make sure the water only gets rendered at places where the terrain isn’t above it.

To override a transparency setting specified at a lower level node, just add an override, like setTransparency(x, 1).

You’re right about overriding transparency, setTransparency(x, 1) was what I needed :blush:

The water is rendered good in the main buffer, but it’s wrong in the aux buffer, that’s the whole problem.

It’s a bit hard to show, but here are two screenshots with the buffer viewer on.

The buffer in the middle has the specular of the scene, in the first screen water transparency is off and in the second one it’s on


Disabling depth write and putting it in a different bin didn’t do much :frowning:

Did you try what I said about making the water being rendered in front of everything? There are two things that can occur with z-buffered rendering:

  1. the water is rendered first; a plane that covers everything. Then the terrain is rendered. The depth test only adds in the terrain where it covers the water, overwriting the existing pixels in the framebuffer.
  2. the terrain is rendered first. Then the water is rendered. The depth test only executes the water fragment shader where the terrain isn’t already higher than the water height.

In scenario 1, which seems to be what is happening, the problem is that the water shader is executed for fragments that are really covered by the terrain. Since the terrain shader never writes to the aux target, those aux target fragments never get overwritten. You want to force scenario 2, where the water isn’t rendered in the first place at spots where the terrain is higher than the water, so those fragments are never written to the aux buffer either.

So, I do think the best solution is to force the water to be rendered last, which you can do using setBin(“fixed”, 0).

You are usually right, so I always try your advice :mrgreen:

In my scenario everything writes to the aux texture, water, terrain, player avatar, trees, grass, other objects, you name it, all of it. The water is also discarded where terrain is above it (base on the height map used for terrain), but the whole thing with render order is wrong, the problem is elsewhere. My bad.

I write some value into the alpha channel of the aux texture and for water this happens to be 0.0 and it looks like alpha testing also works on the aux texture -in this case and the aux texture gets discarded :neutral_face:

Lucky for me the value in the alpha is a on/off mask so I can write 0.5 and then when reading back the value I can use something like clamp(aux.a-0.5, 0.0, 0.5)*2.0, that should give me 1.0 when it was 1.0 and 0.0 for 0.0 and 0.5 as well.

At this point I’m not sure if all the values read from the auxtex are multiplied by the alpha value, but it looks sort of ok, so I’ll leave it at that.

A quick google search got me an gl extension (or two):
opengl.org/registry/specs/A … _blend.txt
opengl.org/registry/specs/E … ffers2.txt
My card can actually support both, but the first one theoretically needs ogl 4.0 and the later 3.0. I don’t know if or how to use this in P3D and for the time I don’t actually need it.

I’d call this ‘fixed until proven otherwise’.

Yes, there are indeed ways to use different blend settings for each color target. This is a fairly recent feature, though. Even on the Direct3D side, it is only supported from 10.1 onwards (10.0 only supports enabling/disabling the blend state for individual targets). It will be supported eventually in Panda, as part of the planned architectural changes to the render-to-texture system.

If setTransparency is giving you trouble, you could try just manually setting the appropriate alpha settings. MAlpha translates to a setBin of “transparent” (which is in front of “regular” objects, and sorted back-to-front), combined with an AlphaTestAttrib (which masks out fully transparent pixels, a la MBinary) and also a ColorBlendAttrib that blends the incoming value appropriately with the framebuffer color depending on the incoming alpha value.

I expect more problems with transparency when I’ll get to particles, hair etc …and I think only alpha-to-coverage (multisample) can save me then, but that’s another topic.