[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] 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
