On Mon, Nov 29, 2010 at 9:39 AM, <thorsten.i.r...@jyu.fi> wrote:
> > One more observation. Yesterday I was doing tweaks to the spin related
> > functions in my model and during spin tests I noticed that I get the same
> > affect when I am in a spin only the clouds are rotating about a vertical
> > axis
>
> ...
> Yes - same reason - rapid change of the orientation of the view axis.
>
> The problem is generic: a real cloud is a 3-d distribution of droplets,
> i.e. for rendering purposes a function f(x,y,z) of opaqueness where
> projections like
>
> \int f(x,y,z) dz = c(x,y)
>
> determine the appearance of the cloud as seen from the z-direction.
>
> I don't quite know if one could render that in real time if enough
> interpolation is used (I'm no 3d rendering expert), but even coming up
> with a physically correct f(x,y,z) which projects in all directions into
> something like a cloud is a pretty hard task.
>
The current state of the art in cloud rendering does treat the cloud as some
kind of 3d density function and then renders it using tricks that
more-or-less emulate ray-tracing. Such a system would require a lot of work
to implement in fgfs (GSoC project?) The advantage of the current system is
that it looks pretty good and doesn't need very powerful graphics hardware.
>
> So we have to fake it by using texture sheets projected onto something,
> and then there is always some situation in which the nature of the fake is
> apparent.
>
> I can given you clouds which look more or less realistic in level flight
> and normal airplane operation (by using rather high-resolution cloud
> images as done now) - but they rotate in an odd way when you do
> aerobatics.
>
> An alternative might be to use non-rotating crosses -- like the trees --
for the cloud blobs. The problem is that the blending between the blobs
becomes even trickier than what we have now.
> I can give you static cloud sheets which look great from far below or high
> above - but they look unrealistically flat when level with them (doesn't
> work for convective clouds though - I did some of the Cirrus sheets that
> way).
>
> I can give you clouds which are stable against the rotations you observe
> in aerobatics - but they behave in an odd way when you are close to them.
>
> I can give you clouds which are stable against aerobatics and have the
> right behaviour when you are close to them and look straight - but when
> you look out of the side window or take an external view they look odd.
>
> The problem isn't going to go away - you simply can't make a 2d sheet
> appear like a 3d object without the 2d nature being revealed somewhere, in
> some situation - it's like asking from a stage magician that you should be
> allowed to sit and observe behind the stage as well - if you want
> something which looks always and everywhere like a genuine 3d object, you
> need a genuine 3d object. All you can do is decide where you want the
> problem to be.
>
> And I guess that having clouds which are stable against an airplane flying
> through them are more desirable as clouds which look good from a spin...
> But you could simply edit the cloud shaders to insert the relative
> position vector to the object as the reference vector for the transform
> rather than the view axis just to see if you like that better - it's one
> line to edit I think.
>
> Stacking many 2d illusions into a 3d volume is a step towards a genuine 3d
> object, and Tim appears to think it can be done
>
> "> I've been looking at the clouds code again recently, which is oddly slow
> > on
> > my "monster" machine (Phenom II x6, GTX 460) . It has the same problem
> > that
> > the trees code did before a big makeover: it uses instancing techniques
> > on
> > geometry (flat quads) that is to far simple to be treated as an
> > instance. It
> > would be much better to take the same approach we do in trees and treat a
> > cloud as a list of quad or triangle polygons. The messy part is the
> > distance
> > sorting that is not optional for the cloud sprites."
>
> (I have no real idea as to what all this means... since I am not a 3d
> rendering expert).
>
All I'm saying is that the current implementation could be improved and that
we seem to have headroom for more cloud blobs per cloud.
>
> But then you run into a different problem - right now, the cloud code
> doesn't need to know any convective physics, because the cloud texture is
> a photograph and has all the information where a cloud looks how.
>
> If you break that and build the whole shape from 200 different elements,
> you need to input the whole information about where the texture should
> look how yourself, i.e. to get the same visual quality, the code to place
> the texture elements must have some rough idea about convection. There's
> no free lunch...
>
> Either that or create the clouds statically in a modeling program.
> So, I guess rather than more information where the current cloud schemes
> fail (which I at least know, I've spent 3 months with dreaming up and
> testing schemes adn trying to come up with workarounds), an opinion where
> you would like them to fail instead or how much performance you would be
> willing to throw at improved clouds would be more helpful to make progress
> :-) Or if you can come up with an even better scheme/transformation, I'd
> be very excited!
>
> Tim
------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
