Re: [Flightgear-devel] Local Weather 1.4
The LoD is currently hardcoded to 20km, so if visibility 20km, it kicks in before the transparency effect. I have a good fix that takes into account the current visibility as part of the Impostors work, but that won't be available until after the release. In the meantime, I can increase the LoD range to (say) 40km. However, there will probably be some performance penalty. What's the maximum visibility that the Local Weather package uses? We used to have 45 km range out to which clouds were shown. With the new more efficient system, I have made tests with 75 km (which is enough for a good impression even from airliner cruise altitude), see here: http://www.phy.duke.edu/~trenk/pics/local-weather-next05.jpg The penalty for having this is not so severe as compared with other goodies (it's cheaper than the terrain haze for instance). Technically, tile generation is tied to actual visibility. The max. visibility the system generates at high altitude is 140 km or a user-specified maximum, whichever is lower, so cloud positions are computed at most out to 80 km or so. Clouds are shown out to the same distance as normal 3d clouds since they are subject to the same distance slider. If you hard-code some lower number for the release, please let me know where to change it so that I can go back to my extended layer testing. * Thorsten -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Stuart On Sun, Dec 4, 2011 at 10:14 PM, Stuart Buchanan wrote: I've already managed to use a second texture to mask where trees are placed. The following screenshot shows a golf course where I've used a mask so that the random trees are only placed in the rough. http://www.nanjika.co.uk/flightgear/golf.jpg As an update on this, I've now written some code to apply the same technique to the random objects and rotations, so the green channel determines the random vegetation density, the blue channel determines random object (i.e. building) density, and the red channel indicates the rotation. Using the DDS textures, the effects can be quite convincing: http://www.nanjika.co.uk/flightgear/object_mask.jpg Note that these are all random objects - none of the buildings or trees were placed manually. The rotations aren't perfectly aligned with the textures, but it's fairly close. Vivian - are you anticipating the materials-dds.xml file replacing materials.xml at some point? Any plans for further DDS texture work? Creating the masks is a bit of work, and not something one would want to do if the textures are likely to change. No, there is no intention to replace the materials.xml file with the materials-dds.xml file, at least while there are those systems that cannot use .dds. Equally, we cannot, for obvious reasons, backport all of the new stuff in dds format to png, so over time the two files will drift further apart. There are significant gains in performance and appearance by using dds, so it's worth running both formats in parallel. The current phase of work is largely complete; I think Emilian has some tidying up to do. Apologies for the tardy reply: I replaced one of my HDD with a SSD on Christmas Day - it worked well for 3 hours or so then it all fell apart. The hardware is fine - but I'm still rebuilding all the software from scratch. I expect to have it all back by the end of the weekend. (OK, I'm an optimist.) Vivian -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Mathias On Tuesday, December 27, 2011 00:27:41 Stuart Buchanan wrote: Vivian - are you anticipating the materials-dds.xml file replacing materials.xml at some point? Any plans for further DDS texture work? Hmm, regarding dds. I have to say, that not all OpenGL drivers support texture compression, and the models with dds files, are those that I cannot display, because of that. And in fact this will not happen to the open source drivers before something about 2020 because of patent issues. Sorry to step in this so late - probably way too late - but is there a reason that the on disk format must be compressed? The previous strategy to have on disk an format that everybody can read and to make the driver compress them as needed/possible is better I think? So, for me the f16 lost its livery lately - where I can live with this for the f16, I hope that this does not happen to flightgear as a whole ... There is no intention to migrate as a whole to .dds: it is offered as an appearance and performance upgrade for those who wish to use it. It is up to aircraft developers to decide which format they will use. Indeed - they could provide models with either format so that the user could choose. That said - why use drivers that cannot handle .dds compression formats? I assume closed source drivers are OK? Vivian -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Some More Detailed Scenery
Curt: I would be happy to help, though I don't know of many non-CORINE sceneries (Helgoland and some photoreal sceneries). I can make a list of the sceneries I've created and hopefully other scenery developers will come forward? Oliver: All the sceneries I've been creating are GPL, with the exception of the sceneries where I've been using OSM data (unsure about the CC license compatibility with GPL). At the same time I do not support the inclusion of some sceneries I've created in the main FlightGear repository, as users with lower-end machines may wish to use the vmap0 scenery over the more detailed ones - plus there is now a marked difference in scenery versions between scenery compatible with 2.4 and scenery not compatible with 2.4. The user should be allowed to choose. Furthermore, the data I've been creating is also generally available to end-users. Cheers John -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] DDS texures (Was: Improving random trees buildings)
On Thu, 2011-12-29 at 14:37 +0100, Erik Hofman wrote: On Thu, 2011-12-29 at 14:16 +0100, Mathias Fröhlich wrote: Could we do dds files without compression but with precomputed mipmaps? So at next, can you try out which combination of compression/provided mipmaps/forced simgear compression still work fine? Good Idea, I will try that. Ouch, compressed: 5.3Mb, uncompressed: 16Mb .. Erik -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather 1.4
Hi Curt! Curtis Olson curtol...@gmail.com wrote: Hi Joe, actually the FlightGear scenery is round -- technically oblate ellipsoid based on a wgs-84 coordinate model. If you stitched enough tiles together you will see the earth curvature start to form. I must have missed the implementation of this capability totally. I assumed a comparatively small cut-out of the ellipsoid was projected on a plane/disc. But, hey, thats great news to me! Thanks for clarification! Joe -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather 1.4
Hi Joe, actually the FlightGear scenery is round -- technically oblate ellipsoid based on a wgs-84 coordinate model. If you stitched enough tiles together you will see the earth curvature start to form. The FlightGear world model lets you fly accurate great circle routes, and enables all the chart intersections to be at the correct location with the correct radials from all the relevant navaids. This also allows for correct relative placement of the sun, moon, stars, planets, correct phase of the moon (by just shading the moon from the position of the sun like in real life.) This ties into correct sunrise/sunset times, correct seasonal amounts of light and position of the sun, etc. Best regards, Curt. On Thu, Dec 29, 2011 at 7:29 AM, wrote: On Thu, 29 Dec 2011 10:37:44 +0200 (EET) thorsten.i.r...@jyu.fi wrote: http://www.phy.duke.edu/~trenk/pics/local-weather-next05.jpg Impressive! Technically, tile generation is tied to actual visibility. The max. visibility the system generates at high altitude is 140 km or a user-specified maximum, whichever is lower, so cloud positions are computed at most out to 80 km or so. At view distances 100 km it becomes more and more apparent that the flightgear scenery is flat and not a sphere, doesn't it? I think a realistic horizon is impossible as long as scenery/world is a disc. This applies even to low altitudes. In reality you can see that the clouds wrap our planet. Joe -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather 1.4
On Thu, 29 Dec 2011 10:37:44 +0200 (EET) thorsten.i.r...@jyu.fi wrote: http://www.phy.duke.edu/~trenk/pics/local-weather-next05.jpg Impressive! Technically, tile generation is tied to actual visibility. The max. visibility the system generates at high altitude is 140 km or a user-specified maximum, whichever is lower, so cloud positions are computed at most out to 80 km or so. At view distances 100 km it becomes more and more apparent that the flightgear scenery is flat and not a sphere, doesn't it? I think a realistic horizon is impossible as long as scenery/world is a disc. This applies even to low altitudes. In reality you can see that the clouds wrap our planet. Joe -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Le 29/12/2011 14:16, Mathias Fröhlich a écrit : Hi Erik, On Thursday, December 29, 2011 13:33:09 Erik Hofman wrote: Setting compression to 'none' does speed up texture switching considerably. Unfortunately there's little difference in switching from internal to external view for the first time. Thanks. I do also see an initial frame drop on switching views with the f16. That is with or without textures that could be uploaded. I do have read somewhere that generating mipmaps can also be slow for some drivers (NVidia?) and the dds textures provided pre generated mipmaps. That's probably what I wrote now several times. And over the time where I had different drivers installed on this current machine and over the machines that I had access to using an nvidia driver it looks like this being a problem. this is the same here with fglrx driver, so not a particular driver issue, but may be the mipmap generation? for me as a multiplayer pilot, dds (with pregenerated mipmap) is the way to go, as it provide me (with a luckily dds compliant driver) a better flightgear experience with dds textures (materials and planes): smoother flight, mp planes converted load faster, no more age to pass on external view for the first time or change livery. [...] jano -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather 1.4
At view distances 100 km it becomes more and more apparent that the flightgear scenery is flat and not a sphere, doesn't it? I think a realistic horizon is impossible as long as scenery/world is a disc. What's more important from high altitude is what happens beyond view distance where no terrain is loaded. What you see then is the skydome, and the skydome shader for instance knows about the Earth radius and gives you (approximately) the right behaviour. A postcard from 85.000 ft is here: http://www.flightgear.org/wp-content/uploads/2011/09/fgfs-blackbird05.jpg (this is still from some early work where I didn't have the terrain haze shader yet - by now the seam between skydome and terrain is completely gone. I would redo these pictures except... I can't draw clouds to more than 20 km, and from 85.000 ft that means clouds aren't drawn at all because you are more than 20 km above them) This applies even to low altitudes. In reality you can see that the clouds wrap our planet. They do - Stuart spent a lot of time reacting to my complaints that clouds were placed in a flat layer initially :-) It's difficult to spot the curvature though, I can't (even conceptually) draw clouds to 140 km without changing the code in a major way. * Thorsten -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather 1.4
On Thu, Dec 29, 2011 at 8:44 AM,wrote: I must have missed the implementation of this capability totally. I assumed a comparatively small cut-out of the ellipsoid was projected on a plane/disc. But, hey, thats great news to me! Thanks for clarification! Each tile is a square shape, and when you push the visibility out far, it's possible to see the square edges of the tiles -- especially against the sky dome if it's not blended together properly. Then also there is a far clip plane that can also be seen in extremely high vis scenarios -- so it's really hard to see the earth curvature in flightgear, but you see the side effects of everything being in the right place relative to each other with proper headings and directions and intersections for everything. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Vivian, There is no intention to migrate as a whole to .dds: it is offered as an appearance and performance upgrade for those who wish to use it. It is up to aircraft developers to decide which format they will use. Indeed - they could provide models with either format so that the user could choose. That said - why use drivers that cannot handle .dds compression formats? Because there is no other driver. Like for the intel ones for example. Because work on other interresting system stuff gets much more annoying with any closed source driver. I just do not want to limit myself to flightgear - so I really apprechiate that you could do even serious development to the closed source drivers. Because most stuff that the average linux user cares work perfect with the open source driver stack. And that makes manny people just use these. Then when one of them tries flightgear he will see that it does not work as expected and most of them will then just never again try flightgear. Some of them will land here and probably get saied that he should use an other driver. But most people just don't ask and probably tell others that they have a new laptop but once they tried flightgear, that boring game just does not work anymore ... I assume closed source drivers are OK? The ati and nvidia closed source drivers can do this. So, I think the mipmap generation hangs with the nvidia drivers are a serious problem. But just limiting everything to the use of exactly this driver where this problem is worst cannot be a valid answer. I would like to have a flightgear that is by default just running on every average system. Having this run faster on a special configured system with some better configuration options and hand tuned hardware and drivers is very fine. But without tuning it must at least work in an acceptable way. I have checked in a change to flightgear to make the use of the compressed internal formats a starttime configuration option. I am still interrested if we have that hangs also with texture compression disabled and without providing precompressed dds textures? Mathias -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
On Thu, 2011-12-29 at 17:36 +, Vivian Meazza wrote: Mathias I have checked in a change to flightgear to make the use of the compressed internal formats a starttime configuration option. I am still interrested if we have that hangs also with texture compression disabled and without providing precompressed dds textures? Yes - good idea - I'm using that now - unfortunately my system was working just fine before so it might be a little hard to see if there is any effect! I'm not entirely clear what bug this fix is trying to solve. At least the bug where switching from internal view to external view cause a big 'pause' for the F-16. It also effects livery switching for the F-16. Erik -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Stefan On Thursday 29 December 2011 10:21:11 Vivian Meazza wrote: That said - why use drivers that cannot handle .dds compression formats? I assume closed source drivers are OK? They simply are not. I currently cannot use FlightGear due to simply unusable performance with free drivers but still, it's worth this tradeoff for me after years of pain with closed source drivers (both NVidia and ATI/AMD). Free drivers allow me to: * do my job which is programming which needs loads of text on the screen (closed source drivers gave unusably low performance here) * have multiple X servers running, so my girlfriend can have her own user on my computer without either of us having to log out all the time * upgrade to current (development) kernel any time * have decent video performance * actually get support for kernel problems In sum, these features are worth more to me than FlightGear, though I miss it very much. The free radeon drivers nowadays are good enough for many games and other software. It would be nice if FG developers acknowledged their existence and avoided breaking their user's experience. Personally I hope to get back to at least flyable performance levels with a CPU upgrade in the near future. But even if not, I would never go back to closed source drivers. I hear your pain - but as I said - you don't have to use materials-dds.xml - it's not the not the default. Neither do you have to use any shaders - they are switchable. If you still can't run Flightgear - well you know the solution - upgrade your system. Vivian -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Some More Detailed Scenery
Am 29.12.2011 06:43, schrieb J. Holden: At the same time I do not support the inclusion of some sceneries I've created in the main FlightGear repository, as users with lower-end machines may wish to use the vmap0 scenery over the more detailed ones - plus there is now a marked difference in scenery versions between scenery compatible with 2.4 and scenery not compatible with 2.4. The user should be allowed to choose. All valid points which need to be addressed, especially the compatibility issue. However, the current conclusion, that we therefore need many separate scenery projects, and should even actively proclaim the use of various external sources, doesn't sound right to me. Do these issues really mean that our central scenery project is limited for ever? Just in comparison: what would happen if Fred provided patches for the new shadow support on his private site only, Mathias did the same for HLA and OSG support, Torsten for the NAV radio and environment code etc. Then we create some central website listing all available patches, so people can choose (according to their hardware/performance/interests). And to make it easier for users: we create a large compatibility matrix, describing which patches fit seamlessly together, and which probably don't. That's a possible solution - but neither does that sound right to me... ;-) Results in the same nightmare that Oliver described for scenery. Instead we all contribute to a central Git repo and try to make features configurable - so you can disable 3D clouds, AI traffic, shaders, multiplayer, ... So we should also discuss other solutions for scenery. It'd be possible to abandon the current TerraSync server and switch to a new one. So, FG 0.1 - 2.4 users keep using existing scenery, while new developments (compatible with FG=2.6) are stored on a new central repository. Or we could extend the scenery project to provide two levels of scenery: a lower quality scenery for older FG versions/older machines, and a high quality version for new/powerful machines and recent FG versions (in a somehow separate directory structure). Maybe we have more options. But we need a _common_ solution for these issues here - and I don't think that the scenery compatibility issue was really discussed here yet (but I may be wrong). There'll always be some external scenery projects, same as there are external FG core or Nasal patches. That doesn't matter much as long as these are small compared to the work on the common project. But it gets to be real trouble when almost everyone works on his separate private projects, and therefore progress of the common project slows down significantly. So, rather than forking development into many little subprojects, and finding ways to better support these forks, we should find solutions, so that scenery developers keep joining forces and improve our common scenery world (uh, that sounds cheesy, right?). cheers, Thorsten -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
On Thursday 29 December 2011 10:21:11 Vivian Meazza wrote: That said - why use drivers that cannot handle .dds compression formats? I assume closed source drivers are OK? They simply are not. I currently cannot use FlightGear due to simply unusable performance with free drivers but still, it's worth this tradeoff for me after years of pain with closed source drivers (both NVidia and ATI/AMD). Free drivers allow me to: * do my job which is programming which needs loads of text on the screen (closed source drivers gave unusably low performance here) * have multiple X servers running, so my girlfriend can have her own user on my computer without either of us having to log out all the time * upgrade to current (development) kernel any time * have decent video performance * actually get support for kernel problems In sum, these features are worth more to me than FlightGear, though I miss it very much. The free radeon drivers nowadays are good enough for many games and other software. It would be nice if FG developers acknowledged their existence and avoided breaking their user's experience. Personally I hope to get back to at least flyable performance levels with a CPU upgrade in the near future. But even if not, I would never go back to closed source drivers. Stefan -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
On Thu, 2011-12-29 at 14:16 +0100, Mathias Fröhlich wrote: Could we do dds files without compression but with precomputed mipmaps? So at next, can you try out which combination of compression/provided mipmaps/forced simgear compression still work fine? Good Idea, I will try that. Erik -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Local Weather 1.4
We should agree on a common place to publish actual surface wind (for one or many given locations?) in the property tree. /environment/config is definitely not the best place to use but due to historical reasons, many objects rely on these properties (windsock, chimneys/smoke, many more). Someday, we also might want to have winds aloft data for one to many locations and altitudes, so it might be worth to think It's actually surprisingly intricate. For instance, Local Weather allows for boundary layer gusty winds. For some problems (the wave pattern) you'd like to have the base (mean) wind at the surface, for others (windsock) rather the actual wind that the aircraft is feeling. I am now internally storing the interpolated wind (wind at aircraft location and altitude based on all available 3d interpolation points), the current wind (interpolated wind after local boundary layer correction and gust effects), the interpolated surface wind at current location and the current surface wind at current location. May I suggest a subfolder /environment/surface (and possible subfolders /environment/location[i] in case a location other than aircraft position is needed? /environment/surface/ could then contain surface-base-wind-speed-kt surface-base-wind-direction-deg surface-actual-wind-speed-kt (for gusts) surface-actual-wind-direction-deg (for variable winds) In addition we could maybe use effective-cloud-coverage-octas (how much is covered by the sum of all relavant layers) wetness-flag (boolean - in case we want to use wetness-dependent textures) snow-level-ft ...? What would shader people like to use? I hope we find a way to integrate global weather and local weather into just weather one day which provides the full range, from simple 2d-layered clouds without shaders to the full-sized weather model in just one system. Hopefully not with a plain Nasal implementation, but by using existing and new FlightGear systems and Nasal. I wouldn't have any problems with that. It's just difficult for me to imagine how it would look like, as the philosophy is rather different. Although the boundaries become more and more blurry since now both systems refer to the same set of cloud textures and to the same rendering system. If anyone has a vision how the finished product should look like, please let me know :-) By the way, Torsten, could you clarify the status of --prop:/environment/terrain/area[0]/enabled=1 to start the terrainsampler in 2.6 - will this be needed at startup (i.e. should I re-activate the check at startup if this is on), or will the sampler be available automatically, i.e. can I assume that the system will be available? * Thorsten -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Mathias There is no intention to migrate as a whole to .dds: it is offered as an appearance and performance upgrade for those who wish to use it. It is up to aircraft developers to decide which format they will use. Indeed - they could provide models with either format so that the user could choose. That said - why use drivers that cannot handle .dds compression formats? Because there is no other driver. Like for the intel ones for example. Because work on other interresting system stuff gets much more annoying with any closed source driver. I just do not want to limit myself to flightgear - so I really apprechiate that you could do even serious development to the closed source drivers. Because most stuff that the average linux user cares work perfect with the open source driver stack. And that makes manny people just use these. Then when one of them tries flightgear he will see that it does not work as expected and most of them will then just never again try flightgear. Some of them will land here and probably get saied that he should use an other driver. But most people just don't ask and probably tell others that they have a new laptop but once they tried flightgear, that boring game just does not work anymore ... I don't fully understand the point - we're not using .dds, and fancy shaders as the default option - what else isn't working with open source drivers? FlightGear should be working just as it always was. Those unable or unwilling to use closed source or fully compliant drivers just don't get to see some of the fancier eye-candy, but that should be all. I assume closed source drivers are OK? The ati and nvidia closed source drivers can do this. So, I think the mipmap generation hangs with the nvidia drivers are a serious problem. But just limiting everything to the use of exactly this driver where this problem is worst cannot be a valid answer. I haven't see such a problem - now I will look for it. I would like to have a flightgear that is by default just running on every average system. Having this run faster on a special configured system with some better configuration options and hand tuned hardware and drivers is very fine. But without tuning it must at least work in an acceptable way. It should - and I thought it did - I see no problems here with shaders off and using the default materials.dds - where is the problem? I have checked in a change to flightgear to make the use of the compressed internal formats a starttime configuration option. I am still interrested if we have that hangs also with texture compression disabled and without providing precompressed dds textures? Yes - good idea - I'm using that now - unfortunately my system was working just fine before so it might be a little hard to see if there is any effect! I'm not entirely clear what bug this fix is trying to solve. Vivian -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
On Thu, 2011-12-29 at 12:40 +0100, Mathias Fröhlich wrote: I have checked in a change to flightgear to make the use of the compressed internal formats a starttime configuration option. I am still interrested if we have that hangs also with texture compression disabled and without providing precompressed dds textures? Setting compression to 'none' does speed up texture switching considerably. Unfortunately there's little difference in switching from internal to external view for the first time. I do have read somewhere that generating mipmaps can also be slow for some drivers (NVidia?) and the dds textures provided pre generated mipmaps. Erik -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Hi Erik, On Thursday, December 29, 2011 13:33:09 Erik Hofman wrote: Setting compression to 'none' does speed up texture switching considerably. Unfortunately there's little difference in switching from internal to external view for the first time. Thanks. I do also see an initial frame drop on switching views with the f16. That is with or without textures that could be uploaded. I do have read somewhere that generating mipmaps can also be slow for some drivers (NVidia?) and the dds textures provided pre generated mipmaps. That's probably what I wrote now several times. And over the time where I had different drivers installed on this current machine and over the machines that I had access to using an nvidia driver it looks like this being a problem. Yes, the dds textures could provide pregenerated mipmaps. I guess that our dds files really do so. Could we do dds files without compression but with precomputed mipmaps? So at next, can you try out which combination of compression/provided mipmaps/forced simgear compression still work fine? Thanks Mathias -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Vivian, On Thursday, December 29, 2011 17:36:24 Vivian Meazza wrote: I don't fully understand the point - we're not using .dds, and fancy shaders as the default option - what else isn't working with open source drivers? Well, the default f16 does not work anymore for example. I have also never tried the new textures, but I assume that these also contain precompressed data? Also you claimed that the old texture files start to bitrot comared to the new ones which makes me think that the new standard should be the dds files. This together makes me think that the dds files should replace the traditional image files. FlightGear should be working just as it always was. Those unable or unwilling to use closed source or fully compliant drivers just don't get to see some of the fancier eye-candy, but that should be all. Well, the drivers are fully compiant. And if compliance would be a problem I would rather improove the driver than raise this at an application level. These kind of precompressed images limits their usage to a specific set of drivers. And no, due to the patent issues no open source code including ours is allowed to implement compression/decompression code for these image formats. Even if this is easy implementation wise. So, I think the mipmap generation hangs with the nvidia drivers are a serious problem. But just limiting everything to the use of exactly this driver where this problem is worst cannot be a valid answer. I haven't see such a problem - now I will look for it. Ok, for that you might need to understand that the reason for Erik to use the dds files for the f16 is that they appear to improove the hangs that occur with ati and nvidias drivers on mipmap computation. Which means either use the f16 together with the closed source stuff or don't use the f16. This is as of today *practically mutually exclusive*. I would like to have a flightgear that is by default just running on every average system. Having this run faster on a special configured system with some better configuration options and hand tuned hardware and drivers is very fine. But without tuning it must at least work in an acceptable way. It should - and I thought it did - I see no problems here with shaders off and using the default materials.dds - where is the problem? As long as all is optional, the 'old stuff' is not bitrotting and as long as the usual model still work, this should not be a huge problem. I already told, I can tolerate not having the f16 - that would be sad, but ok - but if the same happens with the majority of our texture files, I would object. And this is what I try to do now: Object against using these patented compression algorithms. I do not care for the on disk format of any image file we have. But the problem is that some kind of precompression that can be stored in these dds files cannot be used with other drivers than the closed ati and nvidia ones. As long as these patented compression techiques are not used, every OpenGL driver can use this and displays this fine. Think: Intel has the hugest marketshare in graphics today. If I remember right, they sell more than ati and nvidia together (*). This kind of change in effect rules out the majority of users as intel cannot work with these files. (*) There are several statistics out there, this is the intel one that counts all sold computers. AMD does usually counts the revenue made with graphics boards (where ati wins I believe) or nvidia that usually limit statistics to professional systems (where nvidia wins). ... or something along the lines - you get the idea. I have checked in a change to flightgear to make the use of the compressed internal formats a starttime configuration option. I am still interrested if we have that hangs also with texture compression disabled and without providing precompressed dds textures? Yes - good idea - I'm using that now - unfortunately my system was working just fine before so it might be a little hard to see if there is any effect! I'm not entirely clear what bug this fix is trying to solve. You do not experience any hangs? What is the motivation for you to use dds files? What do you gain by not using the usual image files? The motivation behind this mentioned change is to sort out the best compromise so that the hangs hopefully disappear - which I hope to get with precomputed mipmaps - and being able to display fine with any driver/gpu. Greetings Mathias -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___
Re: [Flightgear-devel] Some More Detailed Scenery
Well, the scenery structure is dissimilar to the normal structure of patching git. A scenery like Washington, DC does not have the same frame rate hit as Juneau or Innsbruck does. And as stated there are now sceneries incompatible with older versions of FlightGear. The problem is, some new sceneries are detailed enough and different enough to be distinct from the base scenery. Even if I had git access, I would be reluctant to put these on TerraSync, even though Hawaii and St. Maarten are on there. However, Hawaii is heavily cleaned and St. Maarten is a very simple scenery. I would like to see these areas placed in the base FlightGear package, though. The only idea I've had is perhaps creating a new server for high-end scenery. There's not much of it at the moment, only Europe and selected parts of North America, but it does take up some bandwidth. But setting up a separate distribution channel is better than overwriting the existing scenery. Cheers John -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
2011/12/29 Mathias Fröhlich mathias.froehl...@gmx.net: And this is what I try to do now: Object against using these patented compression algorithms. I do not care for the on disk format of any image file we have. But the problem is that some kind of precompression that can be stored in these dds files cannot be used with other drivers than the closed ati and nvidia ones. As long as these patented compression techiques are not used, every OpenGL driver can use this and displays this fine. I agree fully with Mathias on this issue, even though I am using the binary fglrx at the moment. I check the open source one from time to time, however, to see if it has improved enough for my purposes. Incidentally, AMD's favorable open source policy was the reason I switched from nVidia. I wonder if there is an open standard counterpart that can do the same as the dds compression? Or is the whole idea patented? (Eww, too broad software patents are the work of the devil). -- Csaba/Jester -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-commitlogs] FlightGear Base Package branch, master,
Flightgear-commitlogs wrote: The branch, master has been updated - Log - commit c8d6a0afe0d9f2d35f2da9ce9a23b8974803b731 Author: Gijs de Rooy Date: Thu Dec 29 17:02:33 2011 +0100 Taxiing tutorial: C172P does not move with throttle near idle. [...] +messageI've already started the engine. Press Shift-B to release the parking brake. Throttle up to about + 20% RPM is a more commonly used unit for engine power on simple piston engines (without injection or turbo), Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improving random trees buildings
Erik, On Thu, 2011-12-29 at 17:36 +, Vivian Meazza wrote: Mathias I have checked in a change to flightgear to make the use of the compressed internal formats a starttime configuration option. I am still interrested if we have that hangs also with texture compression disabled and without providing precompressed dds textures? Yes - good idea - I'm using that now - unfortunately my system was working just fine before so it might be a little hard to see if there is any effect! I'm not entirely clear what bug this fix is trying to solve. At least the bug where switching from internal view to external view cause a big 'pause' for the F-16. It also effects livery switching for the F-16. The F16 is just excellent here. I get a slight pause on firest switching from an internal to external view, but I expect that is the testure loading for the first time. Thereafter it is as near instantaneous as you could wish. Likewise livery changes. Couple of small bugs - a USAF insignia seem to get left behind on the lower wing surface when changing liveries and some errors: Property systems/hook/tailhook-cmd-norm is already defined. Could not find at least one of the following objects for animation: 'Pilot_int' Could not find at least one of the following objects for animation: 'Pilot_int' Could not find at least one of the following objects for animation: 'Pilot_int' Some of the textures aren't properly aligned on the RNlAF-J015-demo livery Overall an excellent experience! However, this is perhaps not a totally fair test: I'm running Windows XP on a 128GB SSD, with a Core2 Quad and nVidia GTX 260, so I would expect quick switching etc. Vivian -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Live Multiplayer
Ok.. Then I;m in.. I'd like the idea to maintain openRadar in Java to at least build a skill set.. and get to know the code and mainly comment it..andhopefu;;y find some cool future team.. My hidden motivation is to android and devices for purpose eg a TCAS Android, or a PFD .. live atc chat on mobiles and voip..and its in jvm.. so maybe we can also use some formulae in java and creation of simgear /python|java|\c|cpp|\js libs to ensure same delegation of issues.. So.. who can fork this to http://mapserver.flightgear.org/git/gitweb.pl?p=openradar to gitorious.. so I can fork it.. and thats just the parallel runways... I don't like java as am unfamiliar and previous coding from a few years ago..and, is owned by oracle now, is heavy on ma system, and two flavours that dont agree sometimes.., python, php , javascipt and qt/c++ are familiar.. and looking at toolset of android for devices, browers and pyqt desktops.. Embeddig in browser apps again..and the phone gap and others... I think the first serious step we all have to take though.. cos its getting silly is to fork apt.dat and nav.dat and aero data in a seperate repositirory... unpacked.. That way we can update bits and reverse rewiend into various commits.. eg fg-2.4 version-updated-latest.. Openradar has huge outdated tarballs.. so that is first problem we have to solve... Cant we just get gitrououos/fg/xplane.git working pelase unpacked.. and maybe /810 /850 directories etc...and consistent terrasync corrected.. even knock out the new data in olde format.. and vice versa.. Pete On Wed, Dec 28, 2011 at 6:55 PM, Martin Spott martin.sp...@mgras.netwrote: Hi Geoff, Geoff McLane wrote: de.knewcleus.fgfs/src/de/knewcleus/fgfs/multiplayer/ protocol/MultiplayerPacket.java - public static final int MAX_PACKET_SIZE=1024; + public static final int MAX_PACKET_SIZE=1200; // FIX20111226 I knew there was an obvious flaw in one of the public versions, but that's been a different one :-) And I was able to create for myself another new sector.xml from the samples given, for an airport of my choice, thanks to mapserver shapefile downloads, etc... which all seemed to work well ;=)) Sounds cool ! BUT I could NOT seem to get the comms (fgcom?) working... any ideas, pointers... I never noticed a comm console in OpenRadar - and I've used it frequently in earlier days. Therefore I'm quite surprised I'll have to have a closer look these days, maybe this helps reminding the idea behind this comm console you mention. http://www.flightgear.org/forums/viewtopic.php?f=6t=10221 seems more interested in using Atlas as the base... OpenRadar has been designed with EUROCONTROL (the European air traffic control / safety organization) user interface standards for real life radar consoles in mind. Therefore it's a lot different from the so-called radar consoles people are familiar with in FlightGear land. Maybe *too* different :-/ http://wiki.flightgear.org/index.php/Stand_Alone_ATC_Control_Development likewise seems to again favor Atlas... Well, I don't know what to say about that But are there other places where I can read more specifically about this java OpenRadar setup, running, operations? No, not much. The most elaborate reference so far is the source code. I know what Ralf was having in mind because we've been talking a lot about OpenRadar (which even didn't have a name until shortly before development stopped), therefore I should be able to answer questions. If you think it's worth doing so, I'd put it into a Gitorious project alongside simgear and all the other stuff, hoping that people drop a patch every now and then. One of the various nice features in OpenRadar is its abstraction layer for switching data source interfaces. Somone built a pure Java HLA compilant interface for OpenRadar, but that's never been integrated into the main source tree. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to
Re: [Flightgear-devel] Live Multiplayer
On Fri, 2011-12-30 at 02:50 +, Pedro Morgan wrote: Ok.. Then I;m in.. I'd like the idea to maintain openRadar in Java to at least build a skill set.. and get to know the code and mainly comment it..andhopefu;;y find some cool future team.. I'm a JEE developer, not a Swing developer, so if there is stuff that isn't related to the UI components, I'm happy to help. If you are looking for a place to host this in gitorious (I'm not sure if it should be part of the FG repository???), I'm happy to offer and maintain it as a project under my fg-misc repository; https://gitorious.org/fg-misc My hidden motivation is to android and devices for purpose eg a TCAS Android, or a PFD .. live atc chat on mobiles and voip..and its in jvm.. so maybe we can also use some formulae in java and creation of simgear /python|java|\c|cpp|\js libs to ensure same delegation of issues.. I'm not sure what you are saying here, but android apps are written in Java and convert to Dalvik bytecode by the build process in your favourite IDE. You build PhoneGap apps for Android with HTML, JavaScript and a little bit of Java and this is compiled to Java bytecode that is then converted to Dalvik bytecode by the build process in your favourite IDE. However if you are going to the trouble to build a HTML version, why not just build a web app that can be deployed to any platform, you need to be online to be using the multi-player network anyway, and a web browser is more ubiquitous than any mobile device platform. S. remainder snipped -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
