On Sat, Nov 8, 2008 at 10:30 PM, Manuel Massing wrote:
> Hi Stuart,
>
> Attached is a small fix for the sorting in CloudShaderGeometry.cxx.
> I think the sorting problem stems from the osg idiosyncracy
> to store transposed matrices...so the intuitive
>
> osg::Vec4f p = vm * osg::Vec4f(_cloudsprites[i]->position.osg(),
> 1.0f);
>
> needs to be replaced with...
>
> osg::Vec4f p =
> vm.preMult(osg::Vec4f(_cloudsprites[i]->position.osg(), 1.0f);
>
> The patch also optimizes the distance calculation - it evaluates the
> distances
> in model space instead of eye space, which reduces computation to a dot-
> product instead of a matrix multiplication.
Hi Manuel,
I've committed this patch, it seems to be a very big improvement in cloud
sprite sorting.
Here are a couple comments for those that have their heads in the 3d cloud
code right now.
It appears that the clouds are drawn with "alpha test" turned on. This
ignores and skips drawing any part of the texture where the alpha value is
greater than some threshold. It may make sense to look at that value
closely, because if it's set too low, it may lead to harsher edges in the
clouds. This isn't a big deal for green trees drawn on top of greenish
terrain, but for clouds, we need really soft and subtle blending into the
sky. We might want to turn off alpha test entirely for drawing clouds?
Mipmapping: this has been brought up before, but we need to be really
careful with automatic mipmapping schemes and textures with an alpha
channel. The alpha channel is also mipmapped with the same algorithm, but
this leads to partial transparency in transparent areas (as neighboring
pixels are averaged together) which can result in poor looking clouds.
There are better mipmapping algorithms to deal with transparency, but I
don't know what they are specifically and if anything fancy is available
within OSG?
Texture repeat: I don't know know what this is set to in our clouds, but
it's another thing that can get us in trouble. If you see a row of odd
pixels on the edge of the texture that somehow seem to match the texture on
the opposite side, that's probably what is happening. This is something
that you can turn off if it's on, and probably makes sense to do it for
cloud textures.
There is definitely a draw order problem with regular 2d cloud layers.
Again, because of transparency issues, anything (anything) with transparency
needs to be sorted and drawn back to front. That means that a 3d cloud
layer needs to be interleaved and drawn in the correct order relative to any
2d cloud layers. If we draw all the 2d layers, then draw the 3d layers (or
visa versa) there will always be situations where the result is way wrong.
All that said, if we can get a set of cloud textures that have softer blends
around the edges, then I think the clouds will start looking *really* nice
in many situations.
When I was playing around with 2d cloud layers years ago, what I found often
worked pretty good was to keep the entire color channels as fully saturated
white, and then do all the interesting cloud shape and blending work in the
alpha channel. That seemed to work out the best, especially if we wanted to
color the clouds at dawn/dusk.
Regards,
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
