Re: [Flightgear-devel] 3D clouds and precepitation affects.
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
Re: [Flightgear-devel] 3D clouds and precepitation affects.
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 rather than a horizontal axis. Again it only appears to happen in vertical maneuvers. In a spin this is very disconcerting as the clouds spin in the same direction as the aircraft. 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. 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. 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). 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... 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! Cheers, * Thorsten -- 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
Re: [Flightgear-devel] 3D clouds and precepitation affects.
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
Re: [Flightgear-devel] 3D clouds and precepitation affects.
2. Clouds rotate in an unrealistic way when doing loops and other maneuvers that involve going to/from inverted (loops, half Cuban eights, split S's ...) but it does not happen when doing rolls. The clouds will flip over 180 degrees at the top and bottom of loops for example. (...) The problem appears to be that the shader that rotates the cloud texture rotates them from upright to inverted and inverted to upright as the aircraft transitions between upright and inverted flight in vertical maneuvers. This is clearly wrong. Is it possible to fix this? The algorithm explicitly breaks symmetry between horizontal and vertical direction, i.e. it assumes that you look more or less horizontally. If you do not do that, you get clouds which roll with you - very bad... so breaking that symmetry is what you need. So, what matters (for that purpose) to the algorithm is your horizontal orientation (heading). This changes continuously if you fly a circle, but it changes discontinuously (or very rapidly) at the top and bottom points of a loop. This discontinuous change in heading makes the unrealistic effect. It is possible to fix that by an algorithm based on position vector rather than view direction, because the relative position between plane and cloud must change continuously at all times. Unfortunately, such an algorithm has other drawbacks (the red sea effect - clouds turn away from you as you approach them). I have last year experimented with a lot of algorithms and schemes, and in the end my conclusion was that Stuart had picked the best one already. In case you're seriously interested, I documented all in the wiki: http://wiki.flightgear.org/index.php/Howto:_Modelling_clouds While the unrealistic behaviour in loops can't really be cured, it could be lessened by doing what nature does - using more cloudlets with less features (up-down distinction) and build cloud structure not by texture but by positioning selected cloudlets with better control. That would need a factor of maybe 20-100 more cloudlets per cloud. With the resources of a current PC in the Flightgear environment, you can have 5000-1 cloudlets, i.e. you'd be limited to 50 Cumulus clouds in the sky or so. I concluded that under these circumstances, fixing the aerobatics problem is not worth pursuing. You can experiment with building clouds that way - the local weather menu point has a 'cloudbox' entry, that is designed to build such many-cloudlet clouds (you may have to edit a bit of you want different textures). I have cooked up also schemes with static (non-rotated models) clouds - these would have none of the above problems, but the trouble is that Flightgear (OSG?) doesn't display a stack of multiple semi-transparent surfaces correctly if they are not exactly parallel - so these schemes don't work. So unless Cheers, * Thorsten -- 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
Re: [Flightgear-devel] 3D clouds and precepitation affects.
While the unrealistic behaviour in loops can't really be cured, it could be lessened by doing what nature does - using more cloudlets with less features (up-down distinction) and build cloud structure not by texture but by positioning selected cloudlets with better control. That would need a factor of maybe 20-100 more cloudlets per cloud. This is probably right on. With the resources of a current PC in the Flightgear environment, you can have 5000-1 cloudlets, i.e. you'd be limited to 50 Cumulus clouds in the sky or so. I concluded that under these circumstances, fixing the aerobatics problem is not worth pursuing. You can experiment with building clouds that way - the local weather menu point has a 'cloudbox' entry, that is designed to build such many-cloudlet clouds (you may have to edit a bit of you want different textures). 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. It would be nice to have a GPU-based particle system that did the clouds, smoke, etc., but we don't yet. I have cooked up also schemes with static (non-rotated models) clouds - these would have none of the above problems, but the trouble is that Flightgear (OSG?) doesn't display a stack of multiple semi-transparent surfaces correctly if they are not exactly parallel - so these schemes don't work. This is more of an OpenGL / graphics hardware problem. There are schemes to do order-independent transparency, but it's hard to see the benefits of rewriting the entire renderer to take advantage of them. So unless Cheers, * Thorsten -- 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 -- 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
Re: [Flightgear-devel] 3D clouds and precepitation affects.
Hal Just built FG, simgear, OSG from GIT yesterday. My previous build was from before the new environment stuff went in. 1. The clouds in general look better than in the past. In non-aerobatic flight these look very realistic to me. But... 2. Clouds rotate in an unrealistic way when doing loops and other maneuvers that involve going to/from inverted (loops, half Cuban eights, split S's ...) but it does not happen when doing rolls. The clouds will flip over 180 degrees at the top and bottom of loops for example. This is actually a long standing issue with clouds that has been there for as long as I have been using FG (since 0.7). From checking the list archives I see that the same basic algorithm is used for both the old and newer cloud code. Stuart's 3d clouds and mine are based on very similar technology. There is a collection of textures for cloudlets, and these are rotated in the scenery towards the viewer by vertex shaders (I adapted Stuart's shaders for my purposes, so they are almost identical and I checked that my modifications did not change the performance significantly). (From Thorsten's note to this list dated 11/17). The problem appears to be that the shader that rotates the cloud texture rotates them from upright to inverted and inverted to upright as the aircraft transitions between upright and inverted flight in vertical maneuvers. This is clearly wrong. Is it possible to fix this? 3. Precipitation for some reason is not deflected by the windshield/canopy and goes directly through the windshield/canopy into the cockpit.I am not sure if this is an issue with the precipitation code or my model. Is anyone else seeing this? This has been an issue from the beginning. There is a workaround in FG though, which turns off the rain in internal views, and instead puts a moving rain texture on the canopy. It's not perfect but it is quite a bit better than rain-in-the cockpit. Try the Spitfire IIa to see it in action. The script is generic, and is in data\Nasal\aircraft.nas. I don't think it has been widely adopted though. Vivian -- 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
Re: [Flightgear-devel] 3D clouds and precepitation affects.
Hi, This has been an issue from the beginning. There is a workaround in FG though, which turns off the rain in internal views, and instead puts a moving rain texture on the canopy. It's not perfect but it is quite a bit better than rain-in-the cockpit. Try the Spitfire IIa to see it in action. The script is generic, and is in data\Nasal\aircraft.nas. I don't think it has been widely adopted though. Vivian Yes and no. Frederic had another workaround which creates a zone around the cockpit view without precipitation. Some weeks ago it worked o.k. for me. Did not test it yet with newer builds heiko -- 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
