Re: [Flightgear-devel] Release 2.4.0: on short final
Did it again! This is it, 2.4.0-final is tagged at fgdata, simgear and flightgear. Or as an aircrew callout: "Minimum! Runway in sight, continue." Thanks everybody and special thanks to ThorstenB for your hard work creating a good and stable code base for our new FlightGear version. In just a few days it will be available, not at your local dealer but at the well known location in the internet. And for those who care about our c172fg project, here are some images from slaughter-day 2: http://www.c172fg.de/ We are now well prepared for the road transport tomorrow. Torsten Am 12.08.2011 22:46, schrieb Torsten Dreyer: >> OK - I just tagged fgdata, simgear and flightgear branch release/2.4.0 >> with the label version/2.4.0-final. This is the codebase for the 2.4.0 >> release. >> >> Some off topic: >> Today, Martin and I started to prepare our new simulator for road >> transport. Enjoy some pics here: >> http://www.c172fg.de/ > > Oups - sorry. Forget the tag, this was one day too early. It was planned > for Saturday (Thanks, ThorstenB for the heads-up). > > One day more for bug fixing is available, sorry for the noise. > > (Too much kerosine in my brain today) > > -- > FREE DOWNLOAD - uberSVN with Social Coding for Subversion. > Subversion made easy with a complete admin console. Easy > to use, easy to manage, easy to install, easy to extend. > Get a Free download of the new open ALM Subversion platform now. > http://p.sf.net/sfu/wandisco-dev2dev > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > -- FREE DOWNLOAD - uberSVN with Social Coding for Subversion. Subversion made easy with a complete admin console. Easy to use, easy to manage, easy to install, easy to extend. Get a Free download of the new open ALM Subversion platform now. 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 Sat, Aug 13, 2011 at 12:02 PM, Thorsten Renk wrote: > Thanks. I have to take a look at the max-cloud-height-m - currently I'm > only setting min-cloud-height-m for the following reason: > > It seems to me that the cloud *center* gets placed at (alt-ft + > layer_altitude), such that (0.5 * cloud-height-m) is below the specified > altitude and (0.5 * cloud-height-m) is above. For small sized clouds, > that's not an issue, because the layer comes out right anyway. > > Now, at least convective layers in flat terrain have a relatively sharp > altitude for the cloudbase - even if cloud tops can vary by a large > margin, it simply doesn't do to have a cloudbase 500 m lower than for the > surrounding clouds (for a cloud top, that's quite okay). It took my 30 > minutes yesterday to find out that this was the trouble with my developing > Cb clouds - so I fixed cloud-height-m to not have random variation and > stacked the cloudlets using my routines such that the cloudbase is > constant but the top of the layer may vary. > > Basically, in the current setup using random cloud-height-m between min > and max values, it's impossible to get a well-defined cloud base altitude, > because I can't know the random value for the height up front. I don't > know if it makes sense to alter it though - for other layers, it may be > useful to place the center at given altitude... I'm sure I can solve this with a bit of coding. :) I can see that it makes more sense to have the altitude define the base of the cloud rather than the centre. I'll change the code to do that. For layers with a more variable cloudbase, that variability can be defined in the cloud layer. > I also came across a second issue (sorry, they just keep coming...) FYI, I just spotted what looks like another bug in the . > Large cloudlets tend to vanish from view at the edges of the view field. I > suspect I understand why: I'll take a look at this too. I suspect that the problem is simply the bounding box defined for the cloud. -Stuart -- FREE DOWNLOAD - uberSVN with Social Coding for Subversion. Subversion made easy with a complete admin console. Easy to use, easy to manage, easy to install, easy to extend. Get a Free download of the new open ALM Subversion platform now. 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
> I've got a patch to do this that I'll submit shortly. the parameter is > , and it defaults to false. > > I'm also taking the opportunity to change some of the defaults, so that > the > max-[cloud|sprite]-[width|height]-m> parameters default to 1.5x the min > equivalent. > > I suspect it won't make much difference to your clouds, as I expect > you'll > want to explicitly set all the parameters, but it should mean the > defaults > make more sense. Thanks. I have to take a look at the max-cloud-height-m - currently I'm only setting min-cloud-height-m for the following reason: It seems to me that the cloud *center* gets placed at (alt-ft + layer_altitude), such that (0.5 * cloud-height-m) is below the specified altitude and (0.5 * cloud-height-m) is above. For small sized clouds, that's not an issue, because the layer comes out right anyway. Now, at least convective layers in flat terrain have a relatively sharp altitude for the cloudbase - even if cloud tops can vary by a large margin, it simply doesn't do to have a cloudbase 500 m lower than for the surrounding clouds (for a cloud top, that's quite okay). It took my 30 minutes yesterday to find out that this was the trouble with my developing Cb clouds - so I fixed cloud-height-m to not have random variation and stacked the cloudlets using my routines such that the cloudbase is constant but the top of the layer may vary. Basically, in the current setup using random cloud-height-m between min and max values, it's impossible to get a well-defined cloud base altitude, because I can't know the random value for the height up front. I don't know if it makes sense to alter it though - for other layers, it may be useful to place the center at given altitude... I also came across a second issue (sorry, they just keep coming...) Large cloudlets tend to vanish from view at the edges of the view field. I suspect I understand why: You must generate the texture sheet somehow in the scenery with some orientation and size. The shader code then grabs it, resizes it using wScale and hScale to what you need and rotates it. Now, if wScale > 1, it may easily occur that the true coordiantes (i.e. before rotation and scaling) are outside the field of view, while the apparent coordinates (i.e. after rotation and scaling by the shader) are in the field of view - but if the true coordinates are outside, the shader code is never called at all, and so the object suddenly vanishes. Basically, the base texture must be generated so large that wScale < 1 is guaranteed to get rid of the problem (I had some models at 4 times design size, to be resized by the shader with a factor 0.25 to get rid of the problem). I suspect you should be able to generate the base texture with max-sprite-width/height-m rather than a constant and then scale down a bit. The trouble is that if the base scale is too large, the shader code needs to run for a lot of objects which are not inside the visual field, so wScale <<1 (~O(0.01) is also something one'd like to avoid. Anyway, that's my diagnosis of what I'm seeing... I hope there's a way to fix that, for Cb clouds I can't simply go to small enough textures such that these problems don't occur... Cheers, * Thorsten -- FREE DOWNLOAD - uberSVN with Social Coding for Subversion. Subversion made easy with a complete admin console. Easy to use, easy to manage, easy to install, easy to extend. Get a Free download of the new open ALM Subversion platform now. 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 Fri, Aug 12, 2011 at 10:52 AM, Thorsten Renk wrote: >> 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. > > If it's not too much trouble, I think the switch would be nice. > Duplicating textures in this case (since a single image has about 1000x400 > pixels) would mean going to a 2048x1024 sheet (possibly doesn't work) or > then quadrupling it with several permutations on 2048x2048 - which seems a > waste of good disk space. I've got a patch to do this that I'll submit shortly. the parameter is , and it defaults to false. I'm also taking the opportunity to change some of the defaults, so that the max-[cloud|sprite]-[width|height]-m> parameters default to 1.5x the min equivalent. I suspect it won't make much difference to your clouds, as I expect you'll want to explicitly set all the parameters, but it should mean the defaults make more sense. > I've done my first 'real' flight (i.e. not using the ufo) with the new > system (and after compiling against OSG 3.01) yesterday - just a short hop > from KLSV to KINS with the F-16 - framerate never dropped below 40 fps > even with a fairly dense layer and 45 km visibility, in sparse clouds > climbed above 70 fps. Pretty awsome... I don't really know how much of > this is due to the new OSG version and how much due to the different > cloud/terrain interaction system, but the combination is rather powerful. > Even without splitting a sky generation across several frames, the delay > building a new tile is actually less than the texture loading delay when I > turn my head in the F-16 too much... Fantastic. I look forward to seeing the final results. -Stuart -- FREE DOWNLOAD - uberSVN with Social Coding for Subversion. Subversion made easy with a complete admin console. Easy to use, easy to manage, easy to install, easy to extend. Get a Free download of the new open ALM Subversion platform now. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
