[Flightgear-devel] Default effects for cockpit
I've noticed recently more or less by accident and to my dismay that model-default.eff is used both by models placed in the scenery and by typical aircraft 3d cockpits. This is rapidly looking like a bad idea when a more detailed atmosphere model enters the game - the terrain haze shader has altitude-differential fog, the sunrise/set code I'm working on has position-differential lighting and fog coloring. Models placed into the scene need essentially the same shader as the terrain and skydome, otherwise they don't blend properly - no choice here. However, half the visual field is typically taken by the cockpit, and the vertices and pixels of that don't really need to go through ~120 lines of differential fogging and lighting code just to discover that they get the default light at the position and no fog. One could probably write some provisions into the shader to make a distance check first and if the model is very close not to go through all the motions, but it seems more reasonable to me to do this on the level of the effect declarations and simply feed the 3dcockpit through a different default effect file which never tries to do any fogging in the first place. Would this be complicated to do (i.e. require changing all aircraft xmls), or is there an easy way to do this? I'm just testing the waters here... as far as I know none of the position differential shading code has been committed yet, but I'm sort of developing strongly into that direction, and I want to identify trouble as soon as possible... * Thorsten -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] proposal: new keybing to show map
Hi, looks like nobody has added the keybinding for the map I suggested some time ago, my proposal is to modify the 109 key binding in the keyboard.xml file from: key n=109 namem/name descMixture richer/desc repeatable type=booltrue/repeatable binding commandnasal/command scriptcontrols.adjMixture(1)/script /binding /key to - key n=109 namem/name descMixture richer/desc repeatable type=booltrue/repeatable binding commandnasal/command scriptcontrols.adjMixture(1)/script /binding mod-alt descShow map/desc binding commanddialog-show/command dialog-namemap/dialog-name /binding /mod-alt /key Cheers Francesco -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default effects for cockpit
On Monday 16 January 2012 11:34:23 thorsten.i.r...@jyu.fi wrote: I've noticed recently more or less by accident and to my dismay that model-default.eff is used both by models placed in the scenery and by typical aircraft 3d cockpits. This is rapidly looking like a bad idea when a more detailed atmosphere model enters the game - the terrain haze shader has altitude-differential fog, the sunrise/set code I'm working on has position-differential lighting and fog coloring. Models placed into the scene need essentially the same shader as the terrain and skydome, otherwise they don't blend properly - no choice here. However, half the visual field is typically taken by the cockpit, and the vertices and pixels of that don't really need to go through ~120 lines of differential fogging and lighting code just to discover that they get the default light at the position and no fog. One could probably write some provisions into the shader to make a distance check first and if the model is very close not to go through all the motions, but it seems more reasonable to me to do this on the level of the effect declarations and simply feed the 3dcockpit through a different default effect file which never tries to do any fogging in the first place. Would this be complicated to do (i.e. require changing all aircraft xmls), or is there an easy way to do this? I'm just testing the waters here... as far as I know none of the position differential shading code has been committed yet, but I'm sort of developing strongly into that direction, and I want to identify trouble as soon as possible... * Thorsten This behaviour is hardcoded, as there needs to be a default fallback effect/shader when none is specified in the model and shaders are turned on. -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default effects for cockpit
This behaviour is hardcoded, as there needs to be a default fallback effect/shader when none is specified in the model and shaders are turned on. Yes, I know that - but can you somehow catch that it's a cockpit you're loading rather than a scene model and hard-code that pointing to a different default effect file? * Thorsten -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default effects for cockpit
thorsten I've noticed recently more or less by accident and to my dismay that model-default.eff is used both by models placed in the scenery and by typical aircraft 3d cockpits. This is rapidly looking like a bad idea when a more detailed atmosphere model enters the game - the terrain haze shader has altitude-differential fog, the sunrise/set code I'm working on has position-differential lighting and fog coloring. Models placed into the scene need essentially the same shader as the terrain and skydome, otherwise they don't blend properly - no choice here. However, half the visual field is typically taken by the cockpit, and the vertices and pixels of that don't really need to go through ~120 lines of differential fogging and lighting code just to discover that they get the default light at the position and no fog. One could probably write some provisions into the shader to make a distance check first and if the model is very close not to go through all the motions, but it seems more reasonable to me to do this on the level of the effect declarations and simply feed the 3dcockpit through a different default effect file which never tries to do any fogging in the first place. Would this be complicated to do (i.e. require changing all aircraft xmls), or is there an easy way to do this? I'm just testing the waters here... as far as I know none of the position differential shading code has been committed yet, but I'm sort of developing strongly into that direction, and I want to identify trouble as soon as possible... If I understand this correctly, you want to change the default behaviour for the scenery models while leaving the cockpit as is with the current default behaviour? Does it also involve changing the behaviour of the non-cockpit parts of the aircraft model? At first glance this seems to be a huge task to modify each aircraft model, but it might be automatable. I would think the work should lie where it falls - if you want to change the default behaviour of scenery models do just that and leave the aircraft alone. Just some final thoughts - what is the framerate cost of this enhancement? And with Project Rembrandt waiting in the wings is this worth doing at this stage at all? I take it that whatever you do it is not for the upcoming release? Vivian -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default effects for cockpit
On Mon, Jan 16, 2012 at 10:40 AM, Thorsten Renk wrote: This behaviour is hardcoded, as there needs to be a default fallback effect/shader when none is specified in the model and shaders are turned on. Yes, I know that - but can you somehow catch that it's a cockpit you're loading rather than a scene model and hard-code that pointing to a different default effect file? I don't think you want to be changing the behaviour for all cockpits, just the one that is your aircraft. For other aircraft (AI/MP), you want them to fade etc. just like the scenery and the rest of the aircraft model. So, I think you can constrain what you want to do to objects that are very close to the viewer. That's mainly (but not exclusively) your aircraft cockpit. IIRC we have two separate cameras, one for 0.0 to ~2m and another from 2m to the visibility range. Perhaps it might be possible to use a different default effect for objects using the near camera? or pass in a Uniform indicating which camera is rendering the object. Alternatively, are you not already determining the distance of the object from the viewer? Can you now simply put an if() test around this, or are there fragment shader implications as well? -Stuart -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default effects for cockpit
If I understand this correctly, you want to change the default behaviour for the scenery models while leaving the cockpit as is with the current default behaviour? Does it also involve changing the behaviour of the non-cockpit parts of the aircraft model? That depends... For most external views, one can safely assume that the plane isn't fogged and that the light is that light at the airplane position. Except for tower view if the plane is far from the tower - then it needs to be fogged. There's also usually better framerate in external views. To be on the safe side, I'd treat the external model just like scenery then and just dump the cockpit into a different class. At first glance this seems to be a huge task to modify each aircraft model, but it might be automatable. I would think the work should lie where it falls - if you want to change the default behaviour of scenery models do just that and leave the aircraft alone. Well, how would we do that then? Just some final thoughts - what is the framerate cost of this enhancement? Surprisingly, so far it doesn't show much difference to the terrain haze shader without differential lighting (the new code primarily hits the vertex shader - apparently the bottleneck is the fragment part). In practical terms, with the F-16 flying over default scenery (KNID to KLSV) I get ~17-20 fps with 120 km visibility range and moderate clouds. It strongly scales with visibility and terrain vertex count - Alaska custom scenery Juneau for instance hits quite badly with 120 km visibility range dependent on whether you look into details scenery US side, or default scenery Canada side. With the X-15 in suborbital flight and 250 km visibility range I get similar figures but no clouds (too high...). But this isn't optimized shader code, for instance currently all haze is done in the fragment shader which is a must for terrain, but for models this can go into the vertex shader since they're not so large, no scattering integrals for the lower half of the skydome need to be computed, ... And with Project Rembrandt waiting in the wings is this worth doing at this stage at all? Project Rembrandt seems to be about something different - detailed rendering of shadows in the near zone (~15 km) - what I do is about approximate rendering of atmospheric shading in the far zone (~1000 km). The two approaches might be mutually exclusive such that you have to run one or the other, I don't know, but somehow the question itself strikes me as odd - certainly it's worth doing if only for the simple reason that I find it interesting working out what causes all the colors we see at sunrise. I take it that whatever you do it is not for the upcoming release? No - it's part of the terrain haze shader branch - the fate of which to be determined. Maybe it can be integrated properly, maybe it can be committed as an alternative scheme whenever the skydome scattering shader is on. Cheers, * Thorsten -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default effects for cockpit
I don't think you want to be changing the behaviour for all cockpits, just the one that is your aircraft. For other aircraft (AI/MP), you want them to fade etc. just like the scenery and the rest of the aircraft model. We seriously show cockpits over MP?? I actually wouldn't want to show them at all for distances where it matters if they would be fogged or not - some LOD animation should eliminate them long before... Alternatively, are you not already determining the distance of the object from the viewer? Can you now simply put an if() test around this, or are there fragment shader implications as well? It would also affect the fragment shader to some degree. But yes, one can in principle also do an 'if' statement, it's just one of these things which strike me as bad design, probing for 1000 vertices 30 times per second if the cockpit is still nearby... * Thorsten -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default effects for cockpit
And with Project Rembrandt waiting in the wings is this worth doing at this stage at all? Project Rembrandt seems to be about something different - detailed rendering of shadows in the near zone (~15 km) - what I do is about approximate rendering of atmospheric shading in the far zone (~1000 km). The two approaches might be mutually exclusive such that you have to run one or the other, I don't know, but somehow the question itself strikes me as odd - certainly it's worth doing if only for the simple reason that I find it interesting working out what causes all the colors we see at sunrise. Rembrandt is not just shadowing. A fair amount of code is about lighting. The principle is that the geometry is not renderer shaded at the first stage, but just geometric and material properties are recorded in textures. Then the lighting is done globally on the whole scene, with one pass for each light source. The atmospheric source (usually the sun but it could be the moon by night) is done by rendering a screen aligned quad on the whole scene, reconstruct the view position and normals from data stored in textures and apply whatever lighting equation you can write in a fragment shader. The fog is applied by another similar pass. The exception is transparent objects, including clouds, that are rendered the classical way and composited with the opaque world. Regards, -Fred -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Creation of the release-branches TOMORROW!
S - the outer marker is hooting, final checklist ist completed, the gear is down and shows three green - let's go for it! Tomorrow morning, on Jan. 17th between 06:00 and 09:00 UTC, I'll bump the version number to 2.6.0, tag and branch gitorious and if everything turns out as expected, bump the next/master branch to 2.7.0 for the next release cycle. Please, NO COMMIT AND NO PUSH during that period to ANY repository in http://gitorious.org/fg I'll post a message here on the list when this task is completed. Thanks for you cooperation, Torsten Am 11.01.2012 22:18, schrieb Torsten Dreyer: Hi everybody, in less than one week we will pass the outer marker for our release of FlightGear 2.6.0: the creation of the release branches in our git repositories. A good time to read the final checklist: * All features work as desired? * All major bugs fixed? (http://code.google.com/p/flightgear-bugs/issues/list?q=-Type%3DFeatureRequest) * All aircraft in FGDATA checked in? * No console debug messages? The EOBT (estimated-off-branch-time?) for our branches is 0800UTC on January, 17th. I'll announce the precise time the evening before that day. Please note that during that short period of 1-2 hours, everybody with commit rights is requested to _NOT_ push anything to our repositories. Go flying, hug your kids, have a beer at the pub - whatever you like. Just stay away from gitorious.org/fg. Please fasten your seat belts, fold away the table in front of you and turn off all your electronic devices. Thanks for flying FlightGear! Torsten on behalf of the entire release crew. Am 17.11.2011 23:57, schrieb Torsten Dreyer: Hi everybody, after some very active weeks of development in the core and data, we are slowly but steadily heading into the next release. This will be version 2.6.0 to be released in February 2012. Please note that - the next feature-freeze state will be entered on December, 17th - one month from now. - the release branch is to be created on January, 17th - two month from now. - the release should be ready by February, 17th - three month from now. (More details here: http://wiki.flightgear.org/index.php/Release_Plan) Those of you who are working on new features or major changes, please make sure you code is in the repositories by Dec., 17th. Thanks for your cooperation and all the excellent and hard work! Torsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ 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 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 -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] NASA's openVSP
OpenVSP, a parametric aircraft design tool, has been released by NASA as open-source software. Details here: http://www.openvsp.org/ -- Roberto Waltman. -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Creation of the release-branches NOW
Subject says all... Am 16.01.2012 20:41, schrieb Torsten Dreyer: S - the outer marker is hooting, final checklist ist completed, the gear is down and shows three green - let's go for it! Tomorrow morning, on Jan. 17th between 06:00 and 09:00 UTC, I'll bump the version number to 2.6.0, tag and branch gitorious and if everything turns out as expected, bump the next/master branch to 2.7.0 for the next release cycle. Please, NO COMMIT AND NO PUSH during that period to ANY repository in http://gitorious.org/fg I'll post a message here on the list when this task is completed. Thanks for you cooperation, Torsten Am 11.01.2012 22:18, schrieb Torsten Dreyer: Hi everybody, in less than one week we will pass the outer marker for our release of FlightGear 2.6.0: the creation of the release branches in our git repositories. A good time to read the final checklist: * All features work as desired? * All major bugs fixed? (http://code.google.com/p/flightgear-bugs/issues/list?q=-Type%3DFeatureRequest) * All aircraft in FGDATA checked in? * No console debug messages? The EOBT (estimated-off-branch-time?) for our branches is 0800UTC on January, 17th. I'll announce the precise time the evening before that day. Please note that during that short period of 1-2 hours, everybody with commit rights is requested to _NOT_ push anything to our repositories. Go flying, hug your kids, have a beer at the pub - whatever you like. Just stay away from gitorious.org/fg. Please fasten your seat belts, fold away the table in front of you and turn off all your electronic devices. Thanks for flying FlightGear! Torsten on behalf of the entire release crew. Am 17.11.2011 23:57, schrieb Torsten Dreyer: Hi everybody, after some very active weeks of development in the core and data, we are slowly but steadily heading into the next release. This will be version 2.6.0 to be released in February 2012. Please note that - the next feature-freeze state will be entered on December, 17th - one month from now. - the release branch is to be created on January, 17th - two month from now. - the release should be ready by February, 17th - three month from now. (More details here: http://wiki.flightgear.org/index.php/Release_Plan) Those of you who are working on new features or major changes, please make sure you code is in the repositories by Dec., 17th. Thanks for your cooperation and all the excellent and hard work! Torsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ 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 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 -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
