Re: [Flightgear-devel] Improved 3D Clouds patch
Hi, On Nov 9, 2008, at 3:30 PM, Ron Jensen wrote: On Sun, 2008-11-09 at 05:30 +0100, Manuel Massing wrote: Hi Stuart, Attached is a small fix for the sorting in CloudShaderGeometry.cxx. I think the sorting problem stems from the osg idiosyncracy to store transposed matrices...so the intuitive osg::Vec4f p = vm * osg::Vec4f(_cloudsprites[i]-position.osg(), 1.0f); needs to be replaced with... osg::Vec4f p = vm.preMult(osg::Vec4f(_cloudsprites[i]-position.osg(), 1.0f); The patch also optimizes the distance calculation - it evaluates the distances in model space instead of eye space, which reduces computation to a dot- product instead of a matrix multiplication. bye, Manuel Well, that seems to have solved the alpha blending issues! Thanks! Not 100% but way much better than the last one. I saw some unexpected sky/scenery blending, probably when a half of cloud is in front of another one and the other half has nothing behind, but I'm not 100% sure on this. Anyway, it's one more great step up! By the way, I found a very interesting thing that the clouds always face to the aircraft. I placed ufo in the middle of clouds and made a spin by pressing left cursor. Then all the clouds were turning toward me, changing their order. I don't complain about this. it's rather cute to see these are facing me and say Hi! :-) Best, - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved 3D Clouds patch
On dimanche 09 novembre 2008, Heiko Schulz wrote: Well, that seems to have solved the alpha blending issues! Thanks! Not 100% but way much better than the last one. I saw some unexpected sky/scenery blending, probably when a half of cloud is in front of another one and the other half has nothing behind, but I'm not 100% sure on this. Anyway, it's one more great step up! So the ugly edges are gone? Would be great news! Maybe Stuarts try to solve this works against the patch. For now I which a bit more documentation about making the cloudshapes. I did understand that there are layers with Boxes with a set of clouds. But I have problems with these coordinates: box x3200/x y0/y z2400/z typest-large/type /box and grid sizes. Without this informations I dn't know how to make realistic looking cloudtypes and formations. (Dreaming of a wonderfull Cumulonimbus Incus with praecipitatio like that http://en.wikipedia.org/wiki/Cumulonimbus_incus:-)) Cheers HHS Wouah, when i see such cloud on the road, i run as fast as possible to get back home. :) -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved 3D Clouds patch
Well, that seems to have solved the alpha blending issues! Thanks! Not 100% but way much better than the last one. I saw some unexpected sky/scenery blending, probably when a half of cloud is in front of another one and the other half has nothing behind, but I'm not 100% sure on this. Anyway, it's one more great step up! So the ugly edges are gone? Would be great news! Maybe Stuarts try to solve this works against the patch. For now I which a bit more documentation about making the cloudshapes. I did understand that there are layers with Boxes with a set of clouds. But I have problems with these coordinates: box x3200/x y0/y z2400/z typest-large/type /box and grid sizes. Without this informations I dn't know how to make realistic looking cloudtypes and formations. (Dreaming of a wonderfull Cumulonimbus Incus with praecipitatio like that http://en.wikipedia.org/wiki/Cumulonimbus_incus:-)) Cheers HHS - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved 3D Clouds patch
If thereis'nt other cloud layers, looks great from any angles, thanks! If any other cloud layer above, then from ground look same as without patch :( Now time to tune textures and xml, maybe -- --- WBR, Vadym. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved 3D Clouds patch
Here is my attempt to improve textures http://img.uz/images/128039fgfs-screen-055.jpg http://img.uz/images/958274fgfs-screen-057.jpg http://img.uz/images/614841fgfs-screen-060.jpg http://img.uz/images/853167fgfs-screen-059.jpg http://img.uz/images/876560fgfs-screen-068.jpg http://img.uz/images/942683fgfs-screen-061.jpg http://img.uz/images/633126fgfs-screen-069.jpg http://img.uz/images/254267fgfs-screen-070.jpg http://img.uz/images/252610fgfs-screen-071.jpg It is only first try, but its look like we can make it better than in plib-fg. -- --- WBR, Vadym. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] SimGear SGMutex - OpenThreads patch by Benoit
Martin Spott wrote: for a rather long time now I have always been applying this patch to my SimGear builds: http://blaniel.free.fr/pub/flightgear/patches/ot_simgear.patch I have to admit that I never made any performance comparison against the previous state, nevertheless I have the impression that applying this patch adds to a proper 'cleanup' of the current source code. Does anyone of FlightGear's CVS commit people have an opinion about this patch ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved 3D Clouds patch
On Sat, Nov 8, 2008 at 10:30 PM, Manuel Massing wrote: Hi Stuart, Attached is a small fix for the sorting in CloudShaderGeometry.cxx. I think the sorting problem stems from the osg idiosyncracy to store transposed matrices...so the intuitive osg::Vec4f p = vm * osg::Vec4f(_cloudsprites[i]-position.osg(), 1.0f); needs to be replaced with... osg::Vec4f p = vm.preMult(osg::Vec4f(_cloudsprites[i]-position.osg(), 1.0f); The patch also optimizes the distance calculation - it evaluates the distances in model space instead of eye space, which reduces computation to a dot- product instead of a matrix multiplication. Hi Manuel, I've committed this patch, it seems to be a very big improvement in cloud sprite sorting. Here are a couple comments for those that have their heads in the 3d cloud code right now. It appears that the clouds are drawn with alpha test turned on. This ignores and skips drawing any part of the texture where the alpha value is greater than some threshold. It may make sense to look at that value closely, because if it's set too low, it may lead to harsher edges in the clouds. This isn't a big deal for green trees drawn on top of greenish terrain, but for clouds, we need really soft and subtle blending into the sky. We might want to turn off alpha test entirely for drawing clouds? Mipmapping: this has been brought up before, but we need to be really careful with automatic mipmapping schemes and textures with an alpha channel. The alpha channel is also mipmapped with the same algorithm, but this leads to partial transparency in transparent areas (as neighboring pixels are averaged together) which can result in poor looking clouds. There are better mipmapping algorithms to deal with transparency, but I don't know what they are specifically and if anything fancy is available within OSG? Texture repeat: I don't know know what this is set to in our clouds, but it's another thing that can get us in trouble. If you see a row of odd pixels on the edge of the texture that somehow seem to match the texture on the opposite side, that's probably what is happening. This is something that you can turn off if it's on, and probably makes sense to do it for cloud textures. There is definitely a draw order problem with regular 2d cloud layers. Again, because of transparency issues, anything (anything) with transparency needs to be sorted and drawn back to front. That means that a 3d cloud layer needs to be interleaved and drawn in the correct order relative to any 2d cloud layers. If we draw all the 2d layers, then draw the 3d layers (or visa versa) there will always be situations where the result is way wrong. All that said, if we can get a set of cloud textures that have softer blends around the edges, then I think the clouds will start looking *really* nice in many situations. When I was playing around with 2d cloud layers years ago, what I found often worked pretty good was to keep the entire color channels as fully saturated white, and then do all the interesting cloud shape and blending work in the alpha channel. That seemed to work out the best, especially if we wanted to color the clouds at dawn/dusk. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved 3D Clouds patch
It is only first try, but its look like we can make it better than in plib-fg. Oh - they look good! Thanks to all of you working on 3d clouds. I have assembled some in flight pictures showing various types of clouds that might aid in creating textures. Find it here: http://www.t3r.de/flightpics/clouds/ Torsten - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved 3D Clouds patch
Tatsuhiro Nishioka wrote: By the way, I found a very interesting thing that the clouds always face to the aircraft. I placed ufo in the middle of clouds and made a spin by pressing left cursor. Then all the clouds were turning toward me, changing their order. I don't complain about this. it's rather cute to see these are facing me and say Hi! :-) Unfortunately the billboarding scheme isn't perfect. Effectively the texture is rotated so that it is at right angles to the viewing direction, with the bottom of the texture pointing down in the world-coordinate system. This works pretty well most of the time, but if your view direction is close to vertical, and you rotate the viewpoint, it is very obvious that the textures rotate with you. The easiest way to see this is to do an aileron roll in a vertical dive. -Stuart - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved 3D Clouds patch
On dimanche 09 novembre 2008, Torsten Dreyer wrote: It is only first try, but its look like we can make it better than in plib-fg. Oh - they look good! Thanks to all of you working on 3d clouds. I have assembled some in flight pictures showing various types of clouds that might aid in creating textures. Find it here: http://www.t3r.de/flightpics/clouds/ Torsten Since it is easier to criticize (sorry :) ) i wonder which clouds are supposed to be shown, they seems to be surrounded by a smog, Here when i look at the sky ( i look at it very often) i can see the shape of the clouds. The actual texture ( which can be improved ) , gives to me that real result. I know that we can do better than with Plib, however the effect was (is) very representative of the reality ( that one, i can see). In any case bravo for the work :) Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] SimGear SGMutex - OpenThreads patch by
Martin Spott wrote: Well, this patch to SimGear is one piece of a set of two, of which the FlightGear-related part had been applied long ago - and which, apparently, lead to no implications at all: http://mapserver.flightgear.org/git/gitweb.pl?p=flightgear;a=commitdiff;h=baa5a4adc495a6343bd6a909128cfccbebbc2546 FYI, here's a reference to the list discussion earlier this year, it might me worth reading in this context - especially wrt. other people's opinion on threading robustness of the existing implementation: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg16687.html Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] SimGear SGMutex - OpenThreads patch by
Curtis Olson wrote: On Sun, Nov 9, 2008 at 9:44 AM, Martin Spott wrote: Martin Spott wrote: for a rather long time now I have always been applying this patch to my SimGear builds: http://blaniel.free.fr/pub/flightgear/patches/ot_simgear.patch My opinion which I've stated before is that I'm extremely nervous about anyone messing with the thread structure of FlightGear because this can lead to bugs that are extremely subtle and extremely hard to find and reproduce. Well, this patch to SimGear is one piece of a set of two, of which the FlightGear-related part had been applied long ago - and which, apparently, lead to no implications at all: http://mapserver.flightgear.org/git/gitweb.pl?p=flightgear;a=commitdiff;h=baa5a4adc495a6343bd6a909128cfccbebbc2546 Furthermore, I've been applying the above SimGear-patch to my working copy for the time being and it has shown to be pretty robust during use - including running the three-monitor-setup at the FGseekend show last weekend. Therefore, from a users point of view, I see no reason why it should not get applied. There may be other reasons hiding, therefore I'm asking. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved 3D Clouds patch
Heiko Schulz wrote: For now I which a bit more documentation about making the cloudshapes. I did understand that there are layers with Boxes with a set of clouds. But I have problems with these coordinates: box x3200/x y0/y z2400/z typest-large/type /box and grid sizes. I've checked in a new data/Docs/README.3DClouds, which should explain how the cloudlayers.xml file works. Please let me know if any of it is unclear. Thanks very much for all the feedback and help everyone has provided in the past week. I've been humbled by the help and encouragement everyone has shown, and the 3D clouds have improved greatly due to this. A superb example of FG community development at its best! Best regards to all, -Stuart - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved 3D Clouds patch
On dimanche 09 novembre 2008, Stuart Buchanan wrote: Gerard Robin wrote: I do like that new version , i hope that the next one without that ordering problem will be perfect. It appears that Manuel has solved the ordering bug. Yeah, change nothing it is perfect, and the textures are right, with it. http://pagesperso-orange.fr/GRTux/3DClouds-img6.jpg with that screenshot we may identify where the problem is: -no clouds layer behind it is very good ( bottom part of the sky ) - with clouds layers behind ( upper part of the sky ) we get that ugly blue color I think this might be something to do with the draw order relative to the cloud layers. I'm sure Tim will know :) -Stuart Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear in IVAO network
Hi all, my name is Pep Ribal. I belong to the Software Development department of the IVAO network. Some of you might remember me, as I was involved in a project regarding IVAO-FlightGear interconnection time ago. That specific project was discontinued, but we at IVAO have not forgotten about the idea of making FlightGear drop in the network in a future. We think this is a good moment to give it a serious try, though changing the approach, i.e., not via a separate application. It would be really positive either for the FG community as well as for the IVAO community. FG would benefit from the real life human controllers, as well as the big amount of virtual pilots available at the same time, sharing a common airspace between pilots running either FG or other simulators. And IVAO would become the first flight sim network that would accept FlightGear simmers, which in our opinion would be a huge plus for the network. I'd like to ask you developers what do you think it would be the best way to proceed, and what help could we expect from you. The situation is as follows: We are not willing to publish our server protocol. That means that a possible module for connecting FG to the servers shouldn't be open source. We have developed a shared library called the INL (IVAO Network Library), freely available at no charge (IVAO freeware), but not open source, that would encapsulate all accesses to our servers. A potential FG module for connecting to the IVAO servers should link and use this library. What I would like is to know what do you think it can be done technically, what license problems could arise, and see if there's any of you willing to help in the possible development of such a software module. Once I had a clear idea of the best way to proceed, I would hand the project to IVAO for approval. We would provide you developers with the INL binaries, and all necessary documentation and other files. Any suggestion is really welcome. Hope something can be done. Thanks to all. Pep. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear in IVAO network
Hi Pep, I haven't personally flown in the IVAO network, but if it is staffed by realistic real world controllers and maintains similar standards of professionalism as in the real aviation world, then I could see this being a really nice option for FlightGear pilots. The biggest challenge here is the constraint imposed by IVAO that your protocols must be closed and the only access to your network is through a dll you provide. FlightGear is licensed under terms of the GPL and the GPL specifically disallows linking to a proprietary library simply for the purpose of avoiding the terms of the GPL which state among other things that any derivative work must have the same terms of open access as the original work (applied to the entire application.) There may be some discussion about it being ok to link to operating system level libraries, but the answer to that question might depend on if you are speaking with RMS himself or someone who is a little more pragmatic about life. The other big issue for us is that if we must live with your shared library, will you provide an equivalent version for windows, linux, macintosh, freebsd, solaris, sgi, and all the other platforms that flightgear supports? If not, which platforms would you be willing to support (or which platforms do you already support?) There is nothing wrong with imposing strict closed source requirements around the use of your work if that is what you chose to do. And likewise if you do not wish to disclose the details of your communication protocol. However makes things really tough to try to find a way to integrate your proprietary work into FlightGear's open structure. Because of this clash between license terms of closed and open source software we can't link your library into our code. And because you have chosen to hide your protocols in addition to the source code, we don't have a chance to write our own interface to your network. So what options does that leave? One possible option I can see at this point is to implement a seperate gateway process that runs along side FlightGear. (I think this was a solution that was proposed in the past.) FlightGear would talk to this proprietary gateway application, which is linked to your DLL and then that would in turn relay information to and from the IVAO network. The downside is that this is much more complicated for the user since they would have another application they'd have to start on their machine along with FlightGear. Another possible option might be to write a gateway application that relays information between the IVAO network and FlightGear's multiplayer network. That could even live on your server and you could have complete end-to-end control over it. That should theoretically be possible if your protocols and dll provide the capability for and end application to report data for more than one aircraft. It occurs to me that you might not like this option since it would reduce the level of control you have over individual clients in the FlightGear world. So to summarize, I'd love to see some developers push forward with this, but due to the very strict closed-source requirements of IVAO, we don't have many options for bridging the gap. Regards, Curt. On Sun, Nov 9, 2008 at 5:11 PM, Pep Ribal wrote: Hi all, my name is Pep Ribal. I belong to the Software Development department of the IVAO network. Some of you might remember me, as I was involved in a project regarding IVAO-FlightGear interconnection time ago. That specific project was discontinued, but we at IVAO have not forgotten about the idea of making FlightGear drop in the network in a future. We think this is a good moment to give it a serious try, though changing the approach, i.e., not via a separate application. It would be really positive either for the FG community as well as for the IVAO community. FG would benefit from the real life human controllers, as well as the big amount of virtual pilots available at the same time, sharing a common airspace between pilots running either FG or other simulators. And IVAO would become the first flight sim network that would accept FlightGear simmers, which in our opinion would be a huge plus for the network. I'd like to ask you developers what do you think it would be the best way to proceed, and what help could we expect from you. The situation is as follows: We are not willing to publish our server protocol. That means that a possible module for connecting FG to the servers shouldn't be open source. We have developed a shared library called the INL (IVAO Network Library), freely available at no charge (IVAO freeware), but not open source, that would encapsulate all accesses to our servers. A potential FG module for connecting to the IVAO servers should link and use this library. What I would like is to know what do you think it can be done technically, what license problems could arise, and see if there's any of you willing to help
Re: [Flightgear-devel] FlightGear in IVAO network
On Mon, Nov 10, 2008 at 1:00 AM, Martin Spott [EMAIL PROTECTED] wrote: BTW, I'm not sure if I really should trust the statistics on this page: http://www.ivao.org/network/servers.php Nope. Try: http://network.ivao.aero/ao/aio.cgi Currently (01:25 UTC) 24 controllers and 202 pilots. -- Csaba/Jester - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved 3D Clouds patch
Gerard Robin wrote: I do like that new version , i hope that the next one without that ordering problem will be perfect. It appears that Manuel has solved the ordering bug. http://pagesperso-orange.fr/GRTux/3DClouds-img6.jpg with that screenshot we may identify where the problem is: -no clouds layer behind it is very good ( bottom part of the sky ) - with clouds layers behind ( upper part of the sky ) we get that ugly blue color I think this might be something to do with the draw order relative to the cloud layers. I'm sure Tim will know :) -Stuart - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear in IVAO network
Thanks for your comments and suggestions. In the first place, I need to tell you that personally, I'm a free software guy, and I agree that the best possible solution is always the GPL license. But this is personal. BTW, you can find information about IVAO at www.ivao.aero, for those that asked. The reason why I wanted to start a discussion about this was to achieve a project proposal or roadmap that we can hand to IVAO Softdev directors for approval. I know their preference is to use the INL library, that's why I suggested this. What I really want is the IVAO approval, and with the use of the INL I think that was guaranteed. But I'm not a salesman; my only interest is just get FG and IVAO join, whatever means that please all. So, as the INL library poses a few important problems, and I see your preference (and my personal one as well) is to go for an open solution, I think we should work on this idea. The thing is, whatever solution is finally pointed out, I'd like to hand them a document about this best solution, well reasoned and clearly explained, so that it helps convince not only software development directors, but the board of governors as well. So yes, the solution that some of you have pointed out of opening a different gateway inside IVAO servers for FG users, had crossed my mind as well time ago. But I need a bunch of arguments and explanations to convince the rest of IVAO that this is the best solution possible. I know Softdev directors are really interested in getting FG join the network, so if we can hand a good explanation there shouldn't be any problem (I'm always optimistic). Regarding why IVAO keeps their protocols closed being a free community, what I've been always answered is that's for security reasons. So explaining them that the mentioned open gateway for FG wouldn't be a security issue is crucial. Developing it in a way that takes security into consideration would be important. I need to tell them how security issues will be addressed. I think the best way to proceed, after reading your posts, is to focus on this solution: a different (open) protocol for FlightGear inside IVAO servers. So what I'd ask you is a set of reasons why we should go for this solution and forget the INL: techical reasons (security-related above all), license reasons, etc. Please help me prepare an interesting proposal. I'm aware the worst hurdle to overcome will be this agreement between two communities with different points of view, but if we could address this specific issue successfully, I'm sure the outcome would be very interesting for the community in general. I'll be waiting for your answers. Best regards, Pep. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear in IVAO network
On Mon, 10 Nov 2008 01:11:01 +0200, Pep wrote in message [EMAIL PROTECTED]: Hi all, my name is Pep Ribal. I belong to the Software Development department ..this is a business enterprise, no? of the IVAO network. Some of you might remember me, as I was involved in a project regarding IVAO-FlightGear interconnection time ago. That specific project was discontinued, but we at IVAO have not forgotten about the idea of making FlightGear drop in the network in a future. We think this is a good moment to give it a serious try, though changing the approach, i.e., not via a separate application. It would be really positive either for the FG community as well as for the IVAO community. FG would benefit from the real life human controllers, as well as the big amount of virtual pilots available at the same time, sharing a common airspace between pilots running either FG or other simulators. And IVAO would become the first flight sim network that would accept FlightGear simmers, which in our opinion would be a huge plus for the network. I'd like to ask you developers what do you think it would be the best way to proceed, and what help could we expect from you. The situation is as follows: We are not willing to publish our server protocol. That means that a possible module for connecting FG to the servers shouldn't be open source. ..ok, so you're not hiring me the GPLv3 fundamentalist to do it. ;o) Pity. You could sell my binaries in full compliance with the GPLv3. We have developed a shared library called the INL (IVAO Network Library), freely available at no charge (IVAO freeware), but not open source, that would encapsulate all accesses to our servers. A potential FG module for connecting to the IVAO servers should link and use this library. What I would like is to know what do you think it can be done technically, what license problems could arise, and see if there's any of you willing to help in the possible development of such a software module. Once I had a clear idea of the best way to proceed, I would hand the project to IVAO for approval. We would provide you developers with the INL binaries, and all necessary documentation and other files. ..I would reject any such delivery. What you propose, is a potential, but quite serious litigation trap. ..if we FG'ers figure out how to talk IVAOese, I see we now risk litigation, we don't even have to agree on _anything_ here, all it takes, is your offer to provide you developers with the INL binaries, and all necessary documentation and other files. ..reverse engineering is less risky, than entering into some agreement with you Pep on IVAO's behalf, it's either legal or not, depending on your jurisdiction. If illegal, it may be a felony. If not, reverse engineering is perfectly legal. Agreements like e.g. NDA's, are always litigation bait under contract law. ..IVAO sounds like a big bureaucratical commercial enterprise to me. It would, or should have guidelines on how to do these things. Urls? ..whoses' other flight simulators are on IVAO, anyway? And what policy do they have on publishing protocols or file formats? Not to mention their contributions to case law and litigation settlement history? And how _are_ they doing now, with the recent finance crisis etc chasing away IT purchases such as MS Office? ..this is what made http://groklaw.net/ a necessary tool to us. Any suggestion is really welcome. ..write a _detailed_ specification on what library you want written, and _publish_ that spec, so it becomes possible to read it on e.g. http://groklaw.net/ with no NDA and so we can have e.g. some Samba type do it for us all. (Could backfire if he becomes a FG developer though. ;o) ) ..expect to have Groklaw and FG people recommend changes to your spec. You will also find Groklaw people helpful in convincing you GPLv3 is _the_ license to use, even if it takes a wee while to get your lawyers embracing it, we can help. ;o) ..maybe you (IVAO) could have your INL learn the FG protocols instead? Our protocols are open, just like the code. Or, you (IVAO) could write a FG specific interface lib to INL? ..nice firm straight borders between FG's and your stuff would keep both your lawyers happy, and all us FG'ers happy and safe from the risky kinda litigation that made http://groklaw.net/ necessary. Hope something can be done. Thanks to all. ..me, I'm hoping for some Samba style signals guru to do it. An external reverse engineer guru is much safer for all of us, as there will be two clear nice firm borders, rather than just one. ..would the IVAO community help sponsor such a guy to do it, Pep? I can see the Groklaw community do that. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case.
Re: [Flightgear-devel] FlightGear in IVAO network
On Sun, 2008-11-09 at 18:40 -0600, Curtis Olson wrote: It occurs to me that you might not like this option since it would reduce the level of control you have over individual clients in the FlightGear world. One might suggest that this would be easily resolved by IVAO by simply ignoring the data about multiplayer entities who they don't want to know about? - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] stall horn sound
I've done some work on the sound system in main.cxx and have attached a patch for folks to review if they want to look at what I did. I made a simplifying assumption that the listener is either stationary (stationary enough) or it is tracking with the aircraft model position. The existing code does a good job of transforming the listener and model velocities into the correct coordinate frame. This is required for doppler effects to work, so I didn't want to change that. However, the mechanism for computing model and listener velocities (current position - last position) leads to enough jitter/variability that it causes noticeable defects or artificats in the audio output. So what I have done is to grab the velocity vector from the FDM in NED coordinates, compute the length, and use this to scale the existing model_vel vector to the correct length. This should remove velocity jitter artifacts from the previous scheme and result in a smooth consistent velocity vector. Then I used my simplifying assumption to set the listener velocity vector to (a) zero if the listener is stationary or (b) the model_vel if the listener is moving. This seems to really help clean up the stall horn sound (and hopefully the marker beacon sounds which suffered the same effect.) But at the same time, the doppler effects are maintained as they were. I'm not sure this is the final solution, but I think it's a step in the right direction. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ main-sound-patch.diff Description: Binary data - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved 3D Clouds patch
Manuel Massing wrote: Attached is a small fix for the sorting in CloudShaderGeometry.cxx. I think the sorting problem stems from the osg idiosyncracy to store transposed matrices...so the intuitive osg::Vec4f p = vm * osg::Vec4f(_cloudsprites[i]-position.osg(), 1.0f); needs to be replaced with... osg::Vec4f p = vm.preMult(osg::Vec4f(_cloudsprites[i]-position.osg(), 1.0f); The patch also optimizes the distance calculation - it evaluates the distances in model space instead of eye space, which reduces computation to a dot- product instead of a matrix multiplication. Great - I was wondering if my sorting was working properly. Obviously it wasn't! Thank-you very much for taking the time to look at the problem and for the patch. I really appreciate you taking the time to correct my programming errors. -Stuart - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear in IVAO network
Pep Ribal wrote: We are not willing to publish our server protocol. That means that a possible module for connecting FG to the servers shouldn't be open source. BTW, I'm not sure if I really should trust the statistics on this page: http://www.ivao.org/network/servers.php According to this page there is not a single active user on sunday evening (23:57 UTC) while the FlightGear multiplayer network has approx. 20 pilots on-line. If this is really the case, then I wonder for which reason FlightGear developers and/or users should bite the bullet of tolerating a multiplayer solution which involves linking to a binary-only library. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear in IVAO network
On Mon, Nov 10, 2008 at 12:11 AM, Pep Ribal [EMAIL PROTECTED] wrote: We are not willing to publish our server protocol. That means that a possible module for connecting FG to the servers shouldn't be open source. We have developed a shared library called the INL (IVAO Network Library), freely available at no charge (IVAO freeware), but not open source, that would encapsulate all accesses to our servers. Given that IVAO seems to be a free community, can you explain why you are insisting on closed protocols and source code? -- Csaba/Jester - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved 3D Clouds patch
Ron Jensen wrote: Well, that seems to have solved the alpha blending issues! Thanks! Is this applicable to the trees, too? The cloud code does a single bubble sort pass per frame, to avoid the performance penalty of sorting the entire cloud set each frame. We could do something similar for the trees if we were within a given distance of the tree set. However, I'm not sure if it worth the performance penalty. -Stuart - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
