On Mon, Nov 29, 2010 at 2:21 AM, Tim Moore <timoor...@gmail.com> wrote: > 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. I've been thinking that, especially with multiplayer in mind, what we need is a cloud factory that takes some random (or manually selected) values and generates a realistic looking f(x,y,z) for a given class of weather phenomenon. That lets all the participants share the generator parameters and thereby have consistent rendering of the sky with suitable realism. People whose graphics servers have true 3D voxel support can use the function directly. > 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. If we outsource the conversion from voxels to blurry texture layers, the machines which are trying to maintain consistent framerate can simply send RPCs with a cone of likely flight paths and get back a cheap decomposition that looks good from those paths. Airplanes in formation or, for example, following a standard departure path will be able to reuse the decompositions. The reason I'd like to get the raytracing off the UI is that the server can use its graphics card to perform the matrix operations for doing decompositions. >> 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. It might work well if we have a dodecahedron of textures, but only show six at any given time. That way, we're always blending about one third of our textures in or out ... and it never snaps from one to the next. >> 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 > > ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
