On 31-Mar-05, at 11:38 AM, Jeff Quan wrote:
If you want to fade a model (with no alpha mask) out smoothly and it
has specularity, then fade out the SpecularColor as well or set it
initially to &c000000 (no specularity). If you don't do this fade, the
object's texture(s) will disappear but it's specularity will still
remain until transparency = &c000000, at which point the object will
disappear entirely and create a visual pop.
Good point. Rendering a strong highlight on a barely visible object is
actually a neat effect though (poor man's Fresnel reflection).
This one is slightly trickier: If you want to fade a masked sprite
(ie: AddShapePictureWithMask), then fade out its DiffuseColor as well.
If this is not done, then it seems as if the sprite's mask is faded
out, but the texture remains at 100% until transparency = &c000000
(another visual pop).
Another good point. This kinda blows, as it's unintuitive and won't
work on lit geometry - more below...
Fading the diffuse color is akin to fading the texture to black and
due to alpha blending will look like the sprite is disappearing. While
I haven't tested this, I'm assuming this works similarly for models
with alpha masks.
It should work the same way for models, but only null shaded (unlit)
textured objects will actually blend diffuse colours, so although this
won't be a problem for the majority of sprites, it will be a problem
for most meshes. This could be considered a Quesa bug however,
especially if it's handled properly in QD3D (which I'd expect it would
be, since QD3D doesn't suffer from related additive problems that
premultiplied alphas expose in OpenGL). It should be easy enough for
Quesa to fade the diffuse colour automatically for the lit cases. The
null shaded cases are a bit tricker, since you need to take any user
defined colours into account, but it should still be doable.
I actually use a hacked Quesa library to enable diffuse blending on lit
objects at all times. Although the QD3D behaviour seems logical from a
programmer's perspective, it makes little sense to me from an artistic
point of view. When I gave the blending code in Quesa an overhaul last
year the folks on the Quesa list insisted the QD3D behaviour be
maintained, so there it is. I may eventually set this up as a global
runtime switch via Quesa's SetProperty API, so maybe it'll make it into
the official release at some point.
Oh, and transparency is one case where the number of polygons does
matter. Fading out 30 models is much slower than fading out 30
sprites. Makes sense, as transparency is a more render-intensive
operation.
Yes, very much so. Alpha blending can strain the GPU somewhat but the
main slowdown is due to the fact that all transparent triangles are
lumped together and manually sorted back to front, which is an
exponentially expensive process. This is one area where a custom engine
can be tweaked for much faster results, but Quesa has to assume the
worst case all the time and use a generic (i.e. slow) algorithm to
ensure correct results.
Frank.
------------
Open Source RB Plugins and Classes
<http://developer.chaoticbox.com>
_______________________________________________
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>
|