[Flightgear-devel] Some background info: 3d cloud layer design issues
This is basically an answer to Vivian who asked me why my Cumulus layers look like stacks of cardboard rather than smooth volumetric objects like Stuart's 3d clouds - I thought that maybe some others are also interested in some background info, and maybe someone even has a new idea. Basically, 3d cloud rendering works between 2 limits: Billboard: Here a single cloud photograph is projected into the scenery. Looks like an actual cloud from large distance, looks highly artifical from close up, all the structure information of the cloud is encoded in the texture. Volumetric: Many small-sized 'particles' are brought into the scenery, the sum of which forms the cloud. Here the cloud structure is encoded in the distribution function of 'particles' which is *much* harder to get right, as a result these clouds look good from up close, but not really from far away. Usually one uses a mixture between the two, say Stuart's default setting uses 20 texture sheets O(200 m) in a 500 m cloud - that's not really volumetric, but not really billboard either. First issue: Cloud size distribution. It's not enough to generate one realistic looking cloud and randomly distribute copies of it across the sky - the repetition of clouds of the same size and shape looks very artificial. A real image of an afternoon Cu layer shows that the sky contains small-sized whisps O(100 m) up to well-developed towering cloud masses O(5000 m) (and may even contain Cb O(20 km)). The underlying reason is that Cu layers are a turbulent phenomenon, and turbulence mixes all size scales in the problem. Thus, to get realistic layers, one need to reproduce the size variation. Second issue: Volume grows like L^3. If my basic 500 m cloud looks good with 20 sprites O(200 m), and I want to use the same technique to render 5 km cloud masses, I need 10^3 * 20, i.e. 20.000 sprites _per cloud_ (1.280.000 sprites for a Cb tower) to get the same effect. Short of waiting for a next-to-next generation GPU, that's simply out of the question. A technique that produces very nice small-scale clouds simply doesn't scale to large clouds. The only way out is: As cloud sizes grow, so must sprite sizes such that #sprites/cloud is approximately a constant. That inevitably means loss of detail. Third issue: Shape distribution. Cumulus clouds have different shape, often correlated with size. Small clouds are feathery whisps, large clouds have well-defined cauliflower-like tops with sharp boundaries between opaque cloud and sky. If that is to be right, the texture mixture needs to be changed with the texture size. As the clouds become more opaque, largely transparent feathered textures need to be changed against largely opaque cauliflower-textures. Taking issues #2 and #3 together, a large Cu cloud of 3 km size can only reasonably be built from O(10-50) sprites with O(1000 m) sprite size with rather opaque textures. Inevitably, that tends to look like a stack of cardboard, because... that's largely what it is. For small clouds, the fact that the textures and resulting clouds are rather transparent and have no well defined boundaries hides the fact very well that one is looking at a stack of sprites. For large opaque clouds, that illusion unfortunately works not so well. The obvious solution is to move towards a volumetric rendering limit, i.e. get the same opacity by using more sprites which are individually less opaque - but that limit runs into severe performance problems with a third power, see above. Ultimately, it's the inability of the GPU to render millions of sprites which prevents large clouds from looking as spectacular as small clouds from close up, given the techniques we're using. I haven't seen any definite answer to that problem anywhere - maybe there is something I'm overlooking, but as far as I've been able to work out these are generic reasons why large clouds can't look as good as small ones. * Thorsten -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
Some progress and minor issues: I am in the process of redoing textures and cloud definitions for Cu layers (the toughest nut), about halfway through converting all available cloud types. I have implemented tested tile management functionality (automatic building and removing clouds) and it seems to be working fine. The new geodinfo() works great - many thanks for that! - it speeds up the system considerably. Not to the point that all could be done in a single frame without generating a noticeable delay, so I'll have to write some routines to split it over maybe 10-20 frames (much better than 30 seconds though). I've noticed that 3dcloud.vert contains the line fogFactor = exp( -gl_Fog.density * fogCoord * 0.5); which tends to fade distant clouds to transparent dependent on visibility range. I find the visual impression better if the 0.5 is changed to a lower value, say 0.3 or even 0.2. Is there a reason to keep it at 0.5, or could we lower it? Also, at one point Stuart told me that the y-position of a texture on the texture sheet is correlated with the position the sprite gets in the cloud - is this something I should be aware of? For some cloud types, this may be useful, but for others it makes no sense. In particular the Congestus type images are much broader than high, so they are arranged in a 1x3 pattern on the sheet, but I don't really want the same texture to always form the cloud top. In any case - I take the opportunity to say thanks for all the help - I think the system is moving a big step forward right now. Cheers, * Thorsten -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default 3d clouds in Local Weather
On Thu, Aug 11, 2011 at 9:29 AM, Thorsten Renk wrote: Some progress and minor issues: I am in the process of redoing textures and cloud definitions for Cu layers (the toughest nut), about halfway through converting all available cloud types. I have implemented tested tile management functionality (automatic building and removing clouds) and it seems to be working fine. The new geodinfo() works great - many thanks for that! - it speeds up the system considerably. Not to the point that all could be done in a single frame without generating a noticeable delay, so I'll have to write some routines to split it over maybe 10-20 frames (much better than 30 seconds though). That should be 1 second for most systems, so that's great. Does that just cover the elevation queries or generating the full model? If so, then I wonder if we can look at hiding the stop/start function from the end user. I think that would help the UI, and hopefully allow us to move towards my holy grail of a single (simple) UI for both global and local weather. I've noticed that 3dcloud.vert contains the line fogFactor = exp( -gl_Fog.density * fogCoord * 0.5); which tends to fade distant clouds to transparent dependent on visibility range. I find the visual impression better if the 0.5 is changed to a lower value, say 0.3 or even 0.2. Is there a reason to keep it at 0.5, or could we lower it? I suspect the 0.5 factor was copied straight from the 3D forest shader I wrote. I'll have a look and see what impact changing it has. I'd prefer not to make it configurable. We've seen some problems on older system where we exceed the number of registers available to the shaders for input, so I'd like to avoid adding any more if possible. Also, at one point Stuart told me that the y-position of a texture on the texture sheet is correlated with the position the sprite gets in the cloud - is this something I should be aware of? For some cloud types, this may be useful, but for others it makes no sense. In particular the Congestus type images are much broader than high, so they are arranged in a 1x3 pattern on the sheet, but I don't really want the same texture to always form the cloud top. Yes, the sprite is selected from the sheet randomly on the x-axis and based on it's height in the cloud on the y-axis for precisely this reason. The behaviour isn't switchable at present though it could be. For the relatively small texture sheets I used in the default 3D clouds, I simply duplicated the textures, so you'd have a 2x6 or 3x9 sheet. Given that cloud performance is effectively limited by sprite resolution and coverage rather than texture sheet size, that might be OK. Otherwise I can add a switch fairly easily. Let me know if you want me to do so. In any case - I take the opportunity to say thanks for all the help - I think the system is moving a big step forward right now. No problem. Great to help. -Stuart -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Having an issue with my mags
Syd, Thanks for the heads up. I'll just work with the electric/key functions for now until I get to know the programming language and syntax better. I only found the FlightGear software a week ago. I have two questions for you. First one is what is the differance between the Yasim engine and what you have here? Like I said, only been diving into this a week and am still figuring things out, so a simple answer would be best. ;) Second question. Since the R22 has a bad tendency to move around when engine is at idle on the ground, do you think setting 'brakes' while there is weight on the skids would stop that. I might be able after a bit to figure out the code needed to apply 'brakes' while the skids are under deflection from weight, similar to what people do for figuring out the scissor deflection of struts in other aircraft. I ask so I don't go trying to figure it out if it won't work for this aircraft model. Rob On 8/10/2011 8:05 PM, syd adams wrote: Hi , It's been ages since i looked at this one again , I see it's in serious need of an update (still uses panel style hotspots)! and fuel management needs to be brought up to date anyway , Going back over the files , i see i used controls/electric/key to manage the magnetos / starter . I'm pretty sure magneto positions have no real effect,other than 0=off , 1,2,3 = on , since it doesn't use any yasim engine , just simulated effects using nasal. The R22.nas file watches the position of /controls/electric/key to set magnetos , engage starter if this is vague , bug me some more , I have a day off tomorrow so i can dig a little deeper. Cheers -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Having an issue with my mags
Gary, Thanks for the insight. I'll look into using the fuel as a cut out for it. ROb Howdy Rob, A YASim FDM helicopter doesn't usually define an engine in the conventional sense. In addition to what you've already done, you might have to terminate the fuel flow to kill the engine. I had a quick look at the R22-- it looks like Syd has a similar routine for killing the engine in R22.nas, but he calls it /after/ fuel supply is terminated. You might have a look at that for ideas if you haven't already. I'm guessing Syd will come on after a while and give you some more information. -Gary aka Buckaroo -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Martin is responding slowly ....
Martin wrote: Hi, if anyone is wondering why I'm responding even slower as usual, this might be caused by the simple fact that I'm being distracted by our daughter who was given birth last night. Fresh from a 3:40 + 7:28 hour flight from Costa Rica (via Atlanta, GA) I found this happy message in my (exploded) mailbox! Congrats Martin! And I wish your daughter all the best in sharing your love with a Cessna ;) Gijs -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Martin is responding slowly ....
Gijs de Rooy wrote: Fresh from a 3:40 + 7:28 hour flight from Costa Rica (via Atlanta, GA) I found this happy message in my (exploded) mailbox! Congrats Martin! And I wish your daughter all the best in sharing your love with a Cessna ;) I guess in a couple of years the entire crowd is going to show up at FSweekend :-) I have to admit that I've under-estimated the time requirement - not so much concerning nappy service for the little lady but instead the time I'm spending together with our three year old son. On the other hand it's a very exciting and pleasant development ! Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Having an issue with my mags
I have two questions for you. First one is what is the differance between the Yasim engine and what you have here? Like I said, only been diving into this a week and am still figuring things out, so a simple answer would be best. ;) I'll have to look through the code again , but the helicopter uses a rotor , there is no engine definition for them . It's been a long time , someone else may be able to answer this better than I can. Second question. Since the R22 has a bad tendency to move around when engine is at idle on the ground, do you think setting 'brakes' while there is weight on the skids would stop that. I might be able after a bit to figure out the code needed to apply 'brakes' while the skids are under deflection from weight, similar to what people do for figuring out the scissor deflection of struts in other aircraft. I ask so I don't go trying to figure it out if it won't work for this aircraft model. Rob I spent several hours last night trying to fix this (again) , still no luck. This has been a problem for a long time. In this case I think it's due to the light weight of the aircraft. The approach speed has a large impact on this problem , and reducing the approach speed to 25 helped a little.I've also had this problem with ultralights Ive modelled , and applying brake made it worse. I,m still working on the gear problem , if i find a solution , I'll commit an update and let you know. Cheers On 8/10/2011 8:05 PM, syd adams wrote: Hi , It's been ages since i looked at this one again , I see it's in serious need of an update (still uses panel style hotspots)! and fuel management needs to be brought up to date anyway , Going back over the files , i see i used controls/electric/key to manage the magnetos / starter . I'm pretty sure magneto positions have no real effect,other than 0=off , 1,2,3 = on , since it doesn't use any yasim engine , just simulated effects using nasal. The R22.nas file watches the position of /controls/electric/key to set magnetos , engage starter if this is vague , bug me some more , I have a day off tomorrow so i can dig a little deeper. Cheers -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG Serial; Was: Release 2.4.0: on short final
On 11.08.2011 05:14, Derrick Washington wrote: Hi Thorsten Thanks for the help, sorry for the delayed reply been really busy with this hardware. I'd love to give it a shot, can you point me in the right direction as far as what to download, how to set things up, compile etc? I'm looking forward to giving it a shot. Derrick, if you're running Windows or Mac, you could just grab an updated binary from the Jenkins build server. If you're familiar with compiling on your own, and you're going to work a lot with I/O and protocols, it indeed might be a good idea to set up your system and build FG yourself. To get started, you should find a lot of information in the Wiki: http://wiki.flightgear.org/Building_FlightGear cheers, Thorsten -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Having an issue with my mags
I have two questions for you. First one is what is the differance between the Yasim engine and what you have here? Like I said, only been diving into this a week and am still figuring things out, so a simple answer would be best. ;) Hi Rob, As Syd said, a YASim aircraft doesn't use the YASim fixed-wing engine declarations, but uses a different set of specifications for the rotor and its drive train. I'm not a helicopter developer, so I can't help with details of rotor stuff, but maybe Heiko other helicopter gurus will drop in with comments. What I can say is that you don't have to rely on the YASim FDM to do all the simulation and in some cases you're better off not using YASim's results. For my own projects (fixed-wings), I'm increasingly taking engine parameters into my own hands, crafting my own code (nasal scripts) to supplement, modify, or replace the engine parameters YASim provides. If you want to simulate a helicopter engine you could write your own routines to manage the engine itself; temperatures, pressures, RPMs, start-up, shut-down, fuel, that sort of thing. Some things might link to YASim's rotor outputs, like RPMs etc. Others might be managed separately with no FDM dependencies. Since you're fairly new to Flightgear it may take a little while to get comfortable with all this. If you study the configuration files of many planes and helicopters, you'll encounter a lot of clever ideas and solutions. There really aren't many restrictions other than what you are willing to do. That's kinda the cool thing about Flightgear. -Gary, aka Buckaroo -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
