[Flightgear-devel] Skydome and Terrain shader with haze - some help required
Im the last weeks, I've been working on integrating Lauri's skydome scattering shader in a seamless way with the rest of the environment. I have now a working version of the shaders available which could be committed. This is: * the original skydome shader, with an added simulation of a low altitude constant density haze layer and meaningful response to the parameters /rendering/scene/overcast, /rendering/scene/scattering and /rendering/scene/saturation. * a matching terrain shader which connects to the skydome in a (mostly) seamless way * this can render everything from rather heavy fog on the ground to a near space view at high altitude with (mostly) seamless transitions * some additional code getting the sunrise/sunset plausible by darkening the haze where needed. See http://www.flightgear.org/forums/viewtopic.php?f=47t=11274start=135#p140031 for some recent pictures * a small change in 3dclouds.frag to let clouds fade into a matching horizon haze color. All this is conceptually independent of Local Weather - while it is supported and the relevant parameters are automatically set by Local Weather, they can be set from anywhere else. Now, I need some help. First, the combined effect of lots of 3d clouds and haze shading isn't fast. It isn't really slow either, with multiple layers of 6/8 clouds drawn to 45 km distance I still get ~20 fps out (36 without the haze and skydome shader for the same clouds), but I have the feeling it could go faster, there's too much redundant things happening. For instance, I get my altitude in model space by vec4 ep = gl_ModelViewMatrixInverse * vec4(0.0,0.0,0.0,1.0); alt = ep.z; in the vertex shader - but this could probably easily be passed as a uniform if I just would know how (lat, lon, alt) maps into model space. And so on. So if anyone with more experience in shader writing can look over it and smooth it a bit, that'd be very good. There is a writeup of the underlying ideas available, and I have tried to comment a lot, and I can also explain the underlying math. The second thing is - I can't get it into a distributable form myself. I don't understand the structure of effect files. In my current implementation, I have just overwritten the Flightgear defaults, used some really ugly hack at one point and distributing that in this form means either using my skydome/terrain or CPU rendering. I don't want to commit it in such a form, this should be optionally linked to the scattering shader on/off. Also, I run into other problems - I've tried to use the haze shader instead of object default, but they're not blended to the same final color when fully fogged, they come out too dark, and I don't know why. I suspect that something happens to objects later that doesn't happen to terrain... So, I'd need the help of someone who understands the effect file structure to create a structure which can be committed without wrecking everything else. If anyone is willing to help with either problem, please let me know and then we can take the bulk of the technical discussion off list (where I can use attachments). I have a pretty good idea what the issues are and in what direction one should probably go to address them - I'm just a bit out of my depth doing it myself. Thanks in advance, * Thorsten -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] UDP communication between 32bit and 64bit systems
Hello everyone! I'm new to this list, but due to my work I am going to have a lot to do with FlightGear and will hopefully be able to contribute a little to the development too. I have found an issue with the udp-communication between 32bit and 64bit systems. To reproduce try using the --native-ctrls option for communication between the different architectures. As you will see it is not working as the udp-packets received have a different size than expected. The underlying reason is that class-objects are stored differently on both machines even though all variables are strictly the same size, e.g. 32bit ints and 64bit doubles. Key to solving this is the class FGNetCtrls in net_ctrls.hxx. What I did is declare all variables of the class in such an order, that they can fit the same way in 32bit as well as in 64bit chunks. This is probably not the most elegant solution, so I hope you cann suggest a better one. Curiously, --native-fdm works without a problem, as its variables are by accident(?) already declared in a right order. Regards, Yavor -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Skydome and Terrain shader with haze - some helprequired
Thorsten Im the last weeks, I've been working on integrating Lauri's skydome scattering shader in a seamless way with the rest of the environment. I have now a working version of the shaders available which could be committed. This is: * the original skydome shader, with an added simulation of a low altitude constant density haze layer and meaningful response to the parameters /rendering/scene/overcast, /rendering/scene/scattering and /rendering/scene/saturation. * a matching terrain shader which connects to the skydome in a (mostly) seamless way * this can render everything from rather heavy fog on the ground to a near space view at high altitude with (mostly) seamless transitions * some additional code getting the sunrise/sunset plausible by darkening the haze where needed. See http://www.flightgear.org/forums/viewtopic.php?f=47t=11274start=135#p140 031 for some recent pictures * a small change in 3dclouds.frag to let clouds fade into a matching horizon haze color. All this is conceptually independent of Local Weather - while it is supported and the relevant parameters are automatically set by Local Weather, they can be set from anywhere else. Now, I need some help. First, the combined effect of lots of 3d clouds and haze shading isn't fast. It isn't really slow either, with multiple layers of 6/8 clouds drawn to 45 km distance I still get ~20 fps out (36 without the haze and skydome shader for the same clouds), but I have the feeling it could go faster, there's too much redundant things happening. For instance, I get my altitude in model space by vec4 ep = gl_ModelViewMatrixInverse * vec4(0.0,0.0,0.0,1.0); alt = ep.z; in the vertex shader - but this could probably easily be passed as a uniform if I just would know how (lat, lon, alt) maps into model space. And so on. So if anyone with more experience in shader writing can look over it and smooth it a bit, that'd be very good. There is a writeup of the underlying ideas available, and I have tried to comment a lot, and I can also explain the underlying math. The second thing is - I can't get it into a distributable form myself. I don't understand the structure of effect files. In my current implementation, I have just overwritten the Flightgear defaults, used some really ugly hack at one point and distributing that in this form means either using my skydome/terrain or CPU rendering. I don't want to commit it in such a form, this should be optionally linked to the scattering shader on/off. Also, I run into other problems - I've tried to use the haze shader instead of object default, but they're not blended to the same final color when fully fogged, they come out too dark, and I don't know why. I suspect that something happens to objects later that doesn't happen to terrain... So, I'd need the help of someone who understands the effect file structure to create a structure which can be committed without wrecking everything else. If anyone is willing to help with either problem, please let me know and then we can take the bulk of the technical discussion off list (where I can use attachments). I have a pretty good idea what the issues are and in what direction one should probably go to address them - I'm just a bit out of my depth doing it myself. Looks like you are doing things the hard way. Emilian and I are busy rationalizing, and combining and improving shaders as appropriate right now: we would be happy to add your stuff to the pile. You could do a merger request to our sandbox here: https://gitorious.org/fgdata-textures-ng/fgdata-textures-ng Or post the files somewhere that we can get them, or email them as an attachment to me. I can't promise an instant solution, because we already have a heavy workload in FG and RL, but we can take a look. Vivian -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Skydome and Terrain shader with haze - some helprequired
On Tue, 2011-10-11 at 09:30 +0100, Vivian Meazza wrote: Thorsten Im the last weeks, I've been working on integrating Lauri's skydome scattering shader in a seamless way with the rest of the environment. I have now a working version of the shaders available which could be committed. Looks like you are doing things the hard way. Emilian and I are busy rationalizing, and combining and improving shaders as appropriate right now: we would be happy to add your stuff to the pile. You could do a merger request to our sandbox here: https://gitorious.org/fgdata-textures-ng/fgdata-textures-ng Or post the files somewhere that we can get them, or email them as an attachment to me. I can't promise an instant solution, because we already have a heavy workload in FG and RL, but we can take a look. Let me state that all of you are doing an excellent job! FlightGear keeps getting better by the day and I see leaps of progress just in a few months. Great work. Erik -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FW: Skydome and Terrain shader with haze - some helprequired
-Original Message- From: Vivian Meazza [mailto:vivian.mea...@lineone.net] Sent: 11 October 2011 17:48 To: 'Erik Hofman' Subject: RE: [Flightgear-devel] Skydome and Terrain shader with haze - some helprequired Erik On Tue, 2011-10-11 at 09:30 +0100, Vivian Meazza wrote: Thorsten Im the last weeks, I've been working on integrating Lauri's skydome scattering shader in a seamless way with the rest of the environment. I have now a working version of the shaders available which could be committed. Looks like you are doing things the hard way. Emilian and I are busy rationalizing, and combining and improving shaders as appropriate right now: we would be happy to add your stuff to the pile. You could do a merger request to our sandbox here: https://gitorious.org/fgdata-textures-ng/fgdata-textures-ng Or post the files somewhere that we can get them, or email them as an attachment to me. I can't promise an instant solution, because we already have a heavy workload in FG and RL, but we can take a look. Let me state that all of you are doing an excellent job! FlightGear keeps getting better by the day and I see leaps of progress just in a few months. Great work. Thank you for your kind remarks. We have some more eye-candy in the pipeline, nothing earth shattering. Vivian -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Object scope help
Hi,
I am trying to develop a radar module which consists of two 'texture'
classes that are overlaid.
The classes are instantiated within instrument_manager:
} else if ( name == taradar ) {
set_subsystem( id, new TaRadar( node ), 1 );
} else if ( name == taecho ) {
set_subsystem( id, new TaEcho( node ), 1 );
and the objects perform as i would expect within flightgear.
next, I wish to call a method (TaRadar::getAngle) from within TaEcho, so to
do this, I assume that i do something like:
TaRadar* _taradar_node = (TaRadar*) globals-get_subsystem(
taradar);
cout angle: _taradar_node-getAngle endl;
OR (neither work)
FGInstrumentMgr *imgr = (FGInstrumentMgr *)
globals-get_subsystem(instrumentation);
_taradar_node = (TaRadar *) imgr-get_subsystem(taradar);
cout angle: _taradar_node-getAngle endl;
Now then, if TaRadar::getAngle() has the following fixed code:
return 10;
everything works ok, but if the method returns an object variable:
return _angle;
I get a segmentation fault. I assume this to be because the private
variable (_angle) has not been initialised, however, i even tried setting
the value to a fixed value within the constructor and it still does not
work.
constructor:
TaRadar::TaRadar(SGPropertyNode *node) {
cout TaRadar initialise endl;
_angle=5; //(declared in .hxx as float _angle;)
}
Does anybody know why this variable is appearing to be not initialised? am i
calling the wrong function to return a pointer to this object?
Thanks for any help
--
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. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object scope help
On 11.10.2011 23:31, Robbo wrote: TaRadar* _taradar_node = (TaRadar*) globals-get_subsystem( taradar); Now then, if TaRadar::getAngle() has the following fixed code: return 10; everything works ok, but if the method returns an object variable: return _angle; I get a segmentation fault. That means _taradar_node is NULL. Calling _taradar_node-getAngle() is illegal if _taradar_node=0. However, if the method you're calling doesn't access the object itself, but just returns a constant (return 10), then nothing happens (lucky!). Add a check if (_taradar_node!=0) ... and see why the pointer is NULL. cheers, Thorsten -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object scope help
On Tue, Oct 11, 2011 at 11:31 PM, Robbo robbo_b...@hotmail.com wrote:
The classes are instantiated within instrument_manager:
} else if ( name == taradar ) {
set_subsystem( id, new TaRadar( node ), 1 );
Notice that the subsystem will be registered using the id not the
name. So make sure you are using the correct value when retrieving
it, below:
TaRadar* _taradar_node = (TaRadar*) globals-get_subsystem(taradar);
--
Csaba/Jester
--
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. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object scope help
Thorsten, Thanks for your prompt reply. I get that the pointer is NULL, but I do not understand why! I believe that I have called the correct method to return a pointer to the object. And since I know that the object has been instantiated (since i get a cout message to tell me and also i can see the object doing what its supposed to be doing on screen). Do you have any idea why this object may be null? have i correctly registered the instrument? does the instrument not persist until program completion? How do I correctly obtain a pointer to this object if this is not the correct way? Thanks Robbo Date: Tue, 11 Oct 2011 23:42:42 +0200 From: bre...@gmail.com To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Object scope help On 11.10.2011 23:31, Robbo wrote: TaRadar* _taradar_node = (TaRadar*) globals-get_subsystem( taradar); Now then, if TaRadar::getAngle() has the following fixed code: return 10; everything works ok, but if the method returns an object variable: return _angle; I get a segmentation fault. That means _taradar_node is NULL. Calling _taradar_node-getAngle() is illegal if _taradar_node=0. However, if the method you're calling doesn't access the object itself, but just returns a constant (return 10), then nothing happens (lucky!). Add a check if (_taradar_node!=0) ... and see why the pointer is NULL. cheers, Thorsten -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object scope help
Csaba,
Thanks, that makes complete sense, I did not spot that the id may be how it
is registered.
However, I have checked what value comes back from id and it is
'instrument-1-taradar', so i changed my call to:
globals-get_subsystem(instrument-1-taradar);
but this is still returning NULL!
i print out some useful info from my code:
log: set_subsystem: taecho: instrument-0-taecho
log: TaEcho constructor called
log: set_subsystem: taradar: instrument-1-taradar
log: TaRadar constructor called
log: TaRadar isnull = YES
Any other ideas why this is NULL?
Cheers
Robbo
2011/10/11 Csaba Halász csaba.hal...@gmail.com
On Tue, Oct 11, 2011 at 11:31 PM, Robbo robbo_b...@hotmail.com wrote:
The classes are instantiated within instrument_manager:
} else if ( name == taradar ) {
set_subsystem( id, new TaRadar( node ), 1 );
Notice that the subsystem will be registered using the id not the
name. So make sure you are using the correct value when retrieving
it, below:
TaRadar* _taradar_node = (TaRadar*) globals-get_subsystem(taradar);
--
Csaba/Jester
--
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. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
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. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] LOD Slider for Aircraft
How about adding an Aircraft Level-of-Detail slider to the Rendering Options dialog? It could provide an easy way for aircraft developers to add lots of detail to their models but still make them usable on low-end systems. Ideally it would work like the existing Performance vs. Quality slider for shaders. Since almost no aircraft would use the new slider, perhaps it could be disabled and enabled on a per-aircraft basis? sim model level-of-detail type=float5/level-of-detail level-of-detail-enable type=booltrue/level-of-detail-enable /model /sim -- 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. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
