It's a state management bug where the state of last solid object
drawn may dictate some of the state used for the transparent pass.
You can try drawing a solid null shaded object (like 1 triangle
offscreen) right before the transparent pass (i.e. last) and see if
that helps, but really this needs to be fixed in Quesa to work
predictably.
Hmm...okay.
Does 1-bit alpha textures suffer from the same issues? If it does
not, how do I use 1-bit alpha textures?
You'd use a 16bit texture (ARGB16 inside Quesa) but I'm not sure
how or if the new Rb3D Material class handles that. 1bit textures
aren't manually sorted since they write depth, so you won't see a
sorting slowdown here, but 1 bit transparency tends to be ugly -
it's only really suitable for "screen" fonts, and even then you
should use nearest-neighbour filtering and turn off mipmaps.
Unfortunately texture filter settings are global in Quesa.
Ugly or not, it's a zillion times faster. I'm using RB's trimesh now,
so I guess there's no way to change the texture alpha mode like with
the Quesa wrappers?
Global as in... it makes every alpha surface 1-bit?
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
|