Re: [Flightgear-devel] [Flightgear-commitlogs] SimGear branch, next,
Flightgear-commitlogs wrote:
The branch, next has been updated
- Log -
[...]
commit 1dfde64ac2e6ed0af91cf986cad8808c0182d408
Author: Frederic Bouvier
Date: Wed Jan 25 23:42:10 2012 +0100
Use bigger point sprites for airport lighting
[...]
- Diff
[...]
diff --git a/simgear/scene/tgdb/obj.cxx b/simgear/scene/tgdb/obj.cxx
index 1d41422..9b8e75d 100644
--- a/simgear/scene/tgdb/obj.cxx
+++ b/simgear/scene/tgdb/obj.cxx
@@ -756,7 +756,7 @@ SGLoadBTG(const std::string path, const
simgear::SGReaderWriterOptions* options
if (!tileGeometryBin.vasiLights.empty()) {
EffectGeode* vasiGeode = new EffectGeode;
Effect* vasiEffect
-= getLightEffect(6, osg::Vec3(1, 0.0001, 0.01), 1, 6, true);
+= getLightEffect(32, osg::Vec3(1, 0.0001, 0.01), 1, 32, true);
vasiGeode-setEffect(vasiEffect);
SGVec4f red(1, 0, 0, 1);
SGMaterial* mat = 0;
On my (my wife's) system (Linux Nvidia proprietary driver) this change
turns PAPI/VASI lights into huge, illuminated baloons. Therefore I
strongly propose to just revert this change.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
I think that you have to add new techniques (an XML element) to existing effect file. You leave the current technique intact and copy/paste it in the same file, add or change what is needed and Modify its predicate. Look at model-default.eff that implements 2 techniques. Techniques can have a predicate that can test a property. Yesterday, I implemented the not operator that was creating syntax errors until then. Techniques (with their predicate) are tested in ascending order of their index (the n attribute), so you can create a new technique with a lower index than the one for the current technique and add a predicate that test (for example) /sim/rendering/lightfield. Okay, that looks sort of doable - I'll have a try. How does the parameter section at the beginning of the file change then? Simply declare all parameters which any of the techniques listed later might use? And what do the different passes do? Thanks, * Thorsten -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-commitlogs] SimGear branch, next,
Martin Spott wrote: On my (my wife's) system (Linux Nvidia proprietary driver) this change turns PAPI/VASI lights into huge, illuminated baloons. Therefore I strongly propose to just revert this change. The same applies to the other runway lights which are affected by the same commit. Anyhow I do acknowledge that there will be no proper solution for all the other ones as long as runway edge lights, approach lights, centerline, threshold and so on all use the same type of light source. One might argue that approach lights are still looking slightly reasonable from distance , but all the others are way too big. Therefore I think it would be a good idea to revert the entire commit as a whole and to leave this place as-is until a better implementation of airport lights comes up. Cheers, Martin. P.S.: I've never ever seen such a fat rabbit ;-) -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-commitlogs] SimGear branch, next,
Martin wrote: On my (my wife's) system (Linux Nvidia proprietary driver) this change turns PAPI/VASI lights into huge, illuminated baloons. Therefore I strongly propose to just revert this change. Same here on Nvidia Geforce GT 540M, see screenshot at: https://lh3.googleusercontent.com/-YGfvue1R00s/T1c-OMTX83I/CdQ/nnik0ZI1_Wk/s1024/fgfs-screen-055.png Gijs -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-commitlogs] SimGear branch, next,
On Wed, 2012-03-07 at 11:54 +0100, Gijs de Rooy wrote: Martin wrote: On my (my wife's) system (Linux Nvidia proprietary driver) this change turns PAPI/VASI lights into huge, illuminated baloons. Therefore I strongly propose to just revert this change. Same here on Nvidia Geforce GT 540M, see screenshot at: https://lh3.googleusercontent.com/-YGfvue1R00s/T1c-OMTX83I/CdQ/nnik0ZI1_Wk/s1024/fgfs-screen-055.png I believe their size used to be distance dependent in the past. Erik -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-commitlogs] SimGear branch, next,
De: Erik Hofman On Wed, 2012-03-07 at 11:54 +0100, Gijs de Rooy wrote: Martin wrote: On my (my wife's) system (Linux Nvidia proprietary driver) this change turns PAPI/VASI lights into huge, illuminated baloons. Therefore I strongly propose to just revert this change. Same here on Nvidia Geforce GT 540M, see screenshot at: https://lh3.googleusercontent.com/-YGfvue1R00s/T1c-OMTX83I/CdQ/nnik0ZI1_Wk/s1024/fgfs-screen-055.png I believe their size used to be distance dependent in the past. The change is mine, and is not specific to Rembrandt. Maybe the size should be tweaked again, and maybe some shared size should be segregated. But my opinion is that their size was ridiculously small on the runway. Just wanted to break the statu quo Regards, -Fred -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-commitlogs] SimGear branch, next,
Erik Hofman wrote: I believe their size used to be distance dependent in the past. It still is. When looking from the startup position on 07 at EDDS at the PAPI, the light 'balloons' appear as being much taller than a Cessna. From the centerline at PAPI position the still look like spheres of more than half a meter in radius. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-commitlogs] SimGear branch, next,
Frederic Bouvier wrote: Just wanted to break the statu quo I confirm, you've been successful :-) Anyhow I think you've just replaced one flaw by another - and the new one is even more inappropriate than the previous state. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Lightfields to GIT - some more advice?
Techniques (with their predicate) are tested in ascending order of their index (the n attribute), so you can create a new technique with a lower index than the one for the current technique and add a predicate that test (for example) /sim/rendering/lightfield. Thanks Frederic - this seems to be (sort of) working. I can only get it to work properly if I throw the new technique at index 7 (or lower) though. Otherwise all terrain types which have a special shader do not accept lightfield shading even if that special shader is off, and only by dragging down the index to 7 does this problem go away. No wonder I couldn't make it work before... I'll test this and rebase it with current GIT, then get it online, and then hopefully someone can commit it (and do the elegant implementations later). In the meantime, to iron out the edges, can someone help me with a few things: I need the true camera altitude above MSL as a shader-readable property (otherwise the scheme breaks in many custom sceneries). Currently I am doing this from Nasal, which means lightfields require Advanced Weather to run, but apart from that, I guess everything would run with Basic Weather as well. Is this information somewhere in the tree? - it somehow sounds like it could be, but I haven't found anything. Even if there's anything proportional to it, I think I could add a property rule, but I need something to work with, currently I'm using geo.viewer_position(). Do we have a list of what properties should control shader behaviour? I've now linked the whole lightfield to /sim/rendering/shaders/skydome because everything only makes sense together with the skydome scattering shader. But should we check for /sim/rendering/shader-effects or /sim/rendering/shaders/generic or any other properties in addition? Anyway, it's nice to see direct comparison screenshots for the two schemes - that makes it easier to spot weaknesses and problems. Thanks in advance, * Thorsten -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
De: thorsten i renk I think that you have to add new techniques (an XML element) to existing effect file. You leave the current technique intact and copy/paste it in the same file, add or change what is needed and Modify its predicate. Look at model-default.eff that implements 2 techniques. Techniques can have a predicate that can test a property. Yesterday, I implemented the not operator that was creating syntax errors until then. Techniques (with their predicate) are tested in ascending order of their index (the n attribute), so you can create a new technique with a lower index than the one for the current technique and add a predicate that test (for example) /sim/rendering/lightfield. Okay, that looks sort of doable - I'll have a try. How does the parameter section at the beginning of the file change then? Simply declare all parameters which any of the techniques listed later might use? And what do the different passes do? You don't have to create a parameter for the properties you want to test in the predicate. But you're right, all the parameters of all pass of all techniques of an effect need to be declared in a single section. A pass is a state set: all the OpenGl attribute of the geometry. When you declare multiple pass, it's because you want the same geometry be drawn several times. You may want to initialize the stencil buffer in one pass (you don't need material properties then) and then draw the object with the stencil test enabled. If you play with the render bins and the draw order that are settable in each pass you can achieve effect such as the light cone (pre - Rembrandt) Regards, -Fred -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Lightfields to GIT - some more advice?
Techniques (with their predicate) are tested in ascending order of their index (the n attribute), so you can create a new technique with a lower index than the one for the current technique and add a predicate that test (for example) /sim/rendering/lightfield. Thanks Frederic - this seems to be (sort of) working. I can only get it to work properly if I throw the new technique at index 7 (or lower) though. Otherwise all terrain types which have a special shader do not accept lightfield shading even if that special shader is off, and only by dragging down the index to 7 does this problem go away. No wonder I couldn't make it work before... Techniques are tested in ascending index order. The first technique with a predicate that succeed is used for the effect. If you want your technique be the first tested, you have to use the lowest number possible. But beware, there is an inheritance scheme (with the keyword inherits-from) where, for example, the urban effect inherits from the terrain-default effect. If terrain-default use 10 and 11 for technique index, urban has to use 9 at most. And someone can create an effect that inherits from the urban effect. It would have to use an index lower than the one used by the urban effect. If you use 0, you leave no room for inheritance. Regards, -Fred -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [Rembrandt] the plan
Hi all. 3. define an XML format for describing the two possible rendering pipelines (the current and new). The format will introduce optional elements (such as shadows, ambient occlusion, glow). I want to point out my work on my newcameras branch: https://gitorious.org/~zan/fg/zans-flightgear/commits/newcameras which allows user to define the rendering pipeline in preferences.xml. It does not (yet?) have everything Rembrandt's pipeline needs, but most likely is easily enhanced to support those things. Basically this version adds support for multiple camera passes, texture targets, texture formats, passing textures from one pass to another etc, while preserving the standard rendering line if user wants that. I wish this work could be extended (or maybe even I can extend it ;) to handle the Rembrandt camera system. This will not solve all problems in the merge, but some of them. Cheers, Lauri, Zan P.s. anyone know how to reply in the thread, when having the daily digest of this list? -- Lauri Peltonen lauri.pelto...@gmail.com -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Rembrandt] the plan
Hi Lauri, Hi all. 3. define an XML format for describing the two possible rendering pipelines (the current and new). The format will introduce optional elements (such as shadows, ambient occlusion, glow). I want to point out my work on my newcameras branch: https://gitorious.org/~zan/fg/zans-flightgear/commits/newcameras which allows user to define the rendering pipeline in preferences.xml. It does not (yet?) have everything Rembrandt's pipeline needs, but most likely is easily enhanced to support those things. Basically this version adds support for multiple camera passes, texture targets, texture formats, passing textures from one pass to another etc, while preserving the standard rendering line if user wants that. I wish this work could be extended (or maybe even I can extend it ;) to handle the Rembrandt camera system. This will not solve all problems in the merge, but some of them. I would like to extend the format to avoid duplicating the stages when you have more than one viewport. What I see is to specify a pipeline as a template, with conditions like in effects, and have the current camera layout refer the pipeline that would be duplicated, resized and positioned for each declared viewport Regards, -Fred -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Recent shader stuff vs 2.4
Martin Spott wrote: As far as I can tell there's still a functional gap in the current implementation of shader control. When I start FlightGear with: --prop:/sim/rendering/shaders/quality-level=0 (that's what is controlled by the slider, correct ?) then I still get the full truckload of shaders, despite the fact that the slider is on the left, the Rendering options menu says (0) and Adjust he slider to enable shaders and the Experimental effects is greyed out. The Shader Options sub-menue confirms that all the shaders are still active. Disabling the shaders requires moving the slider forth and back at runtime in order to take effect - that's inconsistent, I'd say ;-) As far as I can tell, that's still the case in the current state of GIT: http://foxtrot.mgras.net/bitmap/FGFS/Menu-no-Shaders.png Actually this slider doesn't override anything, instead it's being overridden by the defaults. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Double Input Resolution?
Hi everybody, it's a few weeks I'm dealing with a few analog to digital converters, I'm using them to convert external analog signals and use them as inputs to FlightGear controls. I'm wondering which resolution is best when dealing with properties of type double. My analog values get converted to digital ones before being fed to FGFS. I see FGFS likes doubles, that's ok, I am converting those digital inputs to appropriate double values. I'm talking about stuff like /controls/flight/aileron or /controls/engines/enigne/throttle. I'll try and be as precise as possible with my hardware so that I get reliable/stable/consistent readings to feed to FGFS, I'm getting closer to make rid of any unwanted highres noise, still I am going to deal with 8, 10 or 12-bit resolution digital values. That may be too much and useless. I'd like to crop them down to more reasonable resolution if possible/usefull. I see FGFS keyboard/mouse interface uses 7/8bit resolution. I'd like to know if someone can help me figuring out what input resolution should I use for: /controls/flight/aileron /controls/flight/aileron-trim /controls/flight/elevator /controls/flight/elevator-trim /controls/flight/rudder /controls/flight/rudder-trim /controls/gear/brake-parking /controls/engines/enigne/throttle /controls/engines/engine/cowl-flaps-norm /controls/engines/engine/propeller-pitch I'd prefer keep using 8bit resolution (cheap and reliable solution). I'm open to use 10bit resolution if usefull. I'm willing to go with a 12bit resolution input only if _really_ needed. That's how I see it now. I don't want to discard usefull information, nor I want to use useless over-precise values. I'm looking for a reasonable compromise here, but I don't know the internals of FGFS. Cheers, Roberto -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-commitlogs] SimGear branch, next,
Hi, On Wednesday, March 07, 2012 11:54:39 Gijs de Rooy wrote: Same here on Nvidia Geforce GT 540M, see screenshot at: https://lh3.googleusercontent.com/-YGfvue1R00s/T1c-OMTX83I/CdQ/nnik0 ZI1_Wk/s1024/fgfs-screen-055.png No screenshot here, but I also agree that the current lights are way too big. May be they were too small before, but with this commit I think they are now just too big. Greetings Mathias -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Double Input Resolution?
Am 07.03.2012 18:14, schrieb Roberto Inzerillo: Hi everybody, it's a few weeks I'm dealing with a few analog to digital converters, I'm using them to convert external analog signals and use them as inputs to FlightGear controls. I'm wondering which resolution is best when dealing with properties of type double. My analog values get converted to digital ones before being fed to FGFS. I see FGFS likes doubles, that's ok, I am converting those digital inputs to appropriate double values. I'm talking about stuff like /controls/flight/aileron or /controls/engines/enigne/throttle. I'll try and be as precise as possible with my hardware so that I get reliable/stable/consistent readings to feed to FGFS, I'm getting closer to make rid of any unwanted highres noise, still I am going to deal with 8, 10 or 12-bit resolution digital values. That may be too much and useless. I'd like to crop them down to more reasonable resolution if possible/usefull. I see FGFS keyboard/mouse interface uses 7/8bit resolution. I'd like to know if someone can help me figuring out what input resolution should I use for: /controls/flight/aileron /controls/flight/aileron-trim /controls/flight/elevator /controls/flight/elevator-trim /controls/flight/rudder /controls/flight/rudder-trim /controls/gear/brake-parking /controls/engines/enigne/throttle /controls/engines/engine/cowl-flaps-norm /controls/engines/engine/propeller-pitch I'd prefer keep using 8bit resolution (cheap and reliable solution). I'm open to use 10bit resolution if usefull. I'm willing to go with a 12bit resolution input only if _really_ needed. That's how I see it now. I don't want to discard usefull information, nor I want to use useless over-precise values. I'm looking for a reasonable compromise here, but I don't know the internals of FGFS. Cheers, Roberto Hi Roberto, for my poor mens procedure trainer, I use 10bit for the flight controls and found 8bit by far to coarse. Currently I use 8bits for the toe breaks and the engine controls and see some jitter at times. I'll use 10bit when I update the firmware the next time. Parking brake is just a on/off flag (1bit). HTH Torsten -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Rembrandt] the plan
Hi, On Wednesday, March 07, 2012 14:58:26 Lauri Peltonen wrote: 3. define an XML format for describing the two possible rendering pipelines (the current and new). The format will introduce optional elements (such as shadows, ambient occlusion, glow). I want to point out my work on my newcameras branch: https://gitorious.org/~zan/fg/zans-flightgear/commits/newcameras which allows user to define the rendering pipeline in preferences.xml. It does not (yet?) have everything Rembrandt's pipeline needs, but most likely is easily enhanced to support those things. Basically this version adds support for multiple camera passes, texture targets, texture formats, passing textures from one pass to another etc, while preserving the standard rendering line if user wants that. I wish this work could be extended (or maybe even I can extend it ;) to handle the Rembrandt camera system. This will not solve all problems in the merge, but some of them. I was not aware of your work. But given what you write here, this looks pretty promising. Fred mentioned your name in an offline mail. IMO the complexity of this kind of rendering method in terms of requirements to the driver makes me frighten a bit when I think that we have currently no fallback to the old style renderer. Even back to the fixed function pure oldest style stuff which is still the fastest thing we have. Keep in mind that plenty of people will likely trade speed/deterministic frame rates for any eye candy. And beyond that all people that cannot see anything with rembrandt but a black window will love to have something that at least shows the old style stuff (may be just fixed function?). So, wherever we end, I would highly apprechiate that we do not lock out low end graphics boards by not having any fallback. May you both should combine forces? From what I read, I think both are heading in the same global direction and both implementations have some benefits over the other? Hmm, I should really look into the code ... Greetings Mathias -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Double Input Resolution?
On Wed, 7 Mar 2012, Roberto Inzerillo wrote: I see FGFS keyboard/mouse interface uses 7/8bit resolution. I'd like to know if someone can help me figuring out what input resolution should I use for: /controls/flight/aileron /controls/flight/aileron-trim /controls/flight/elevator /controls/flight/elevator-trim /controls/flight/rudder /controls/flight/rudder-trim /controls/gear/brake-parking /controls/engines/enigne/throttle /controls/engines/engine/cowl-flaps-norm /controls/engines/engine/propeller-pitch Roberto, the _minium_ ADC resolution I'd use is 10 bit with 12 bit being preferred. 8 bit is just too coarse to give a good result. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Buying desktop hardware and installing a server OS doesn't make a server-class system any more than sitting in a puddle makes you a duck. [Cipher in a.s.r] -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Double Input Resolution?
Hi, I've been using 12 bit resolution. Need it since I'm also operating with a control force loading system and autopilot. If you go to 12 bits suggest you get some high res, multi-turn pots or some other systems (like magnetic) to give you the precision that warrants 12 bits. If you're using low cost single 270 degree turn pots, might as well stick with a lower bit resolution. Incidentially, those same 12 bits boards are used to fly the Global Observer UAV built by AeroVironment, so I guess they're good enough ;-) Think of it this way, determine the angular travel of your control stick; for 8bits divide by 256; for 12 bits divide by 4096. That defines the resoluion., i.e. degrees per bit. So then you have to decide how good is your sensor in defining the control stick location. If you can't sense 4096 discrete positions your wasting time and money using 12 bits. Regards John - Original Message - From: Roberto Inzerillo rob...@gmx.net To: flightgear-devel@lists.sourceforge.net Sent: Wednesday, March 7, 2012 10:14:44 AM Subject: [Flightgear-devel] Double Input Resolution? Hi everybody, it's a few weeks I'm dealing with a few analog to digital converters, I'm using them to convert external analog signals and use them as inputs to FlightGear controls. I'm wondering which resolution is best when dealing with properties of type double. My analog values get converted to digital ones before being fed to FGFS. I see FGFS likes doubles, that's ok, I am converting those digital inputs to appropriate double values. I'm talking about stuff like /controls/flight/aileron or /controls/engines/enigne/throttle. I'll try and be as precise as possible with my hardware so that I get reliable/stable/consistent readings to feed to FGFS, I'm getting closer to make rid of any unwanted highres noise, still I am going to deal with 8, 10 or 12-bit resolution digital values. That may be too much and useless. I'd like to crop them down to more reasonable resolution if possible/usefull. I see FGFS keyboard/mouse interface uses 7/8bit resolution. I'd like to know if someone can help me figuring out what input resolution should I use for: /controls/flight/aileron /controls/flight/aileron-trim /controls/flight/elevator /controls/flight/elevator-trim /controls/flight/rudder /controls/flight/rudder-trim /controls/gear/brake-parking /controls/engines/enigne/throttle /controls/engines/engine/cowl-flaps-norm /controls/engines/engine/propeller-pitch I'd prefer keep using 8bit resolution (cheap and reliable solution). I'm open to use 10bit resolution if usefull. I'm willing to go with a 12bit resolution input only if _really_ needed. That's how I see it now. I don't want to discard usefull information, nor I want to use useless over-precise values. I'm looking for a reasonable compromise here, but I don't know the internals of FGFS. Cheers, Roberto -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-commitlogs] SimGear branch, next,
On Wed, Mar 7, 2012 at 04:54, Martin Spott martin.sp...@mgras.net wrote: Therefore I think it would be a good idea to revert the entire commit as a whole and to leave this place as-is until a better implementation of airport lights comes up. On a slightly related note, this makes me think of bug #232 (point-sprites on ATI). The PAPI lights look great with point-sprites on, but the runway lights don't show up. With point-sprites off (and the light size change), everything shows, but they are massive. My ATI card does support GL_ARB_point_sprite and GL_ARB_point_parameters, so I think there is actually something broken in how runway/taxi lights are drawn versus PAPI. Even the OSG point-sprite example app works. The fix for bug #232 was to simply turn that technique off with an option, although I think that was more of a finger in the dike fix.. everything looks fine, but the problem still exists. I'm hoping this will spark someone with time/knowledge to investigate the way each of the lights are drawn—not really my realm, but I will help test. cheers, -- Rob -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Double Input Resolution?
Parking brake is just a on/off flag (1bit). Well, right, but not totally. I've seen aircrafts accepting a double value, and I'd like to make it consistent. Intermediate values make sense here since it's a lever that moves along a path (or at least rotates around a hinge). It's not a two positions switch. Anyway, that's not the point, I'm just disgressing :-) -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Double Input Resolution?
Roberto Inzerillo wrote: Well, right, but not totally. I've seen aircrafts accepting a double value, and I'd like to make it consistent. Intermediate values make sense here since it's a lever that moves along a path (or at least rotates around a hinge). It's not a two positions switch. The ancient C175 for example and the more recent DR400 are having a knob which arrests the toe brakes in the current position upon pulling - on the C175 via a mechanical link, on the DR400 it's a hydraulic valve. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Double Input Resolution?
On Wed, 7 Mar 2012, castle...@comcast.net wrote: Hi, I've been using 12 bit resolution. Need it since I'm also operating with a control force loading system and autopilot. If you go to 12 bits suggest you get some high res, multi-turn pots or some other systems (like magnetic) to give you the precision that warrants 12 bits. If you're using low cost single 270 degree turn pots, might as well stick with a lower bit resolution. Scratch building hall effect sensor input assemblies is very, very easy. See here: http://www.simpits.org/geneb/?p=299 Here's a more detailed how-to that I posted: http://simhq.com/forum/ubbthreads.php/topics/3225807/DIY_hall_sensor.html#Post3225807 I've been told by a guy that built a set of these for his cockpit that he gets a wider voltage range by using a single magnet instead of an opposed pair. I haven't had a chance to try that idea myself however. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Buying desktop hardware and installing a server OS doesn't make a server-class system any more than sitting in a puddle makes you a duck. [Cipher in a.s.r] -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Double Input Resolution?
Think of it this way, determine the angular travel of your control stick; for 8bits divide by 256; for 12 bits divide by 4096. That defines the resoluion., i.e. degrees per bit. So then you have to decide how good is your sensor in defining the control stick location. If you can't sense 4096 discrete positions your wasting time and money using 12 bits. Well, I'll choose the proper sensor depending on the expected resolution (but not only!), no doubt about that. The method used to measure this value has its role too. I've read a good deal about hall sensors for high res sensors (I already started investigating those one too). You see I try and choose considering various factors here; FGFS needs are a part of this decision process. There's costs, easy of usage, and reliability also. I'd like to know what FGFS developers think it has to be expected from a decent input device, the other aspects are up to me. Torsten's right when it says the Parking Brake needs only 1bit resolution. He's got a valid point: it's his point of view :-) I'm not using a joystick since I installed Windows7 so I can't see what's the default input res used by FGFS with a Joystick. Could someone help me there? That's the res people using FGFS are generally expecting for basic elevator/aileron/rudder actions. And I guess it's enough for them. I wonder if more is needed. Then again, engine controls may work flawless with an 8bit res input. Anybody thinks a 10bit res is needed here? I'm not talking about what people are currently doing (I'd go with 24bit on everything ... joking!), I'm asking about reasons (technical aspects, facts) that can help me decide for high-res against low-res. That would help me a lot in making good choices with respect to what FGFS is expecting from an input device. -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Double Input Resolution?
Am 07.03.2012 20:59, schrieb Roberto Inzerillo: I'm not talking about what people are currently doing (I'd go with 24bit on everything ... joking!), I'm asking about reasons (technical aspects, facts) that can help me decide for high-res against low-res. That would help me a lot in making good choices with respect to what FGFS is expecting from an input device. I can tell you from experience with many users during our LinuxTag and FSweekend presentations that you need - for throttle: 1 bit (full/idle) - for Mixture: 1 bit(full rich/cutoff) - for RPM: allway full (constant) Flight controls depend on user experience: first time user: 2 bit (full-left, more-or-less-centered, full-right) space cadets (those, who always know better): 32bit is not enough. ;-) Torsten -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Double Input Resolution?
I can tell you from experience with many users during our LinuxTag and FSweekend presentations that you need - for throttle: 1 bit (full/idle) - for Mixture: 1 bit(full rich/cutoff) - for RPM: allway full (constant) :D :D :D :D :D -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Double Input Resolution?
On Wed, Mar 7, 2012 at 2:46 PM, Torsten Dreyer tors...@t3r.de wrote: I can tell you from experience with many users during our LinuxTag and FSweekend presentations that you need - for throttle: 1 bit (full/idle) - for Mixture: 1 bit(full rich/cutoff) - for RPM: allway full (constant) Flight controls depend on user experience: first time user: 2 bit (full-left, more-or-less-centered, full-right) space cadets (those, who always know better): 32bit is not enough. ;-) Well said Thorsten, and make your controls and switches out of titanium or steel -- it's amazing how much damage a 7 year old can do when he doesn't realize the control or switch only goes so far and then is supposed to stop. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Double Input Resolution?
If you plan to do any formation flight, then you need all the resolution you can get from engine controls. Anyway, I would try to dimension the resolution on the minimum amount of play that can be obtained on the controls. Just build one sensor and edit the input file so that you can map it to a different channel every time, then check the FGFS property it is mapped to and see if you can hold it to a set value and move it smoothly between the extremes. Alessandro Date: Wed, 7 Mar 2012 20:59:18 +0100 From: rob...@gmx.net To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Double Input Resolution? Think of it this way, determine the angular travel of your control stick; for 8bits divide by 256; for 12 bits divide by 4096. That defines the resoluion., i.e. degrees per bit. So then you have to decide how good is your sensor in defining the control stick location. If you can't sense 4096 discrete positions your wasting time and money using 12 bits. Well, I'll choose the proper sensor depending on the expected resolution (but not only!), no doubt about that. The method used to measure this value has its role too. I've read a good deal about hall sensors for high res sensors (I already started investigating those one too). You see I try and choose considering various factors here; FGFS needs are a part of this decision process. There's costs, easy of usage, and reliability also. I'd like to know what FGFS developers think it has to be expected from a decent input device, the other aspects are up to me. Torsten's right when it says the Parking Brake needs only 1bit resolution. He's got a valid point: it's his point of view :-) I'm not using a joystick since I installed Windows7 so I can't see what's the default input res used by FGFS with a Joystick. Could someone help me there? That's the res people using FGFS are generally expecting for basic elevator/aileron/rudder actions. And I guess it's enough for them. I wonder if more is needed. Then again, engine controls may work flawless with an 8bit res input. Anybody thinks a 10bit res is needed here? I'm not talking about what people are currently doing (I'd go with 24bit on everything ... joking!), I'm asking about reasons (technical aspects, facts) that can help me decide for high-res against low-res. That would help me a lot in making good choices with respect to what FGFS is expecting from an input device. -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] scenery loading cleanup
Hi, Also for the breginning of the development cycle, I started working on improoving fgviewer and cleanup scenery/model loading. I have now checked in a change that should fix some long standing problems with modelss that appear to have z-fighting. This change should not harm and works so far for all I have tested. But it slightly changes the way stg files paths are handled. So if this really introduces a problem, please tell me. Greetings Mathias -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Two small weather issues
I still have two small (weather-related) issues which I can't resolve myself: * rain is still 'smart' i.e. de-activates above the lowest cloud layer. Since Advanced Weather has its own precipitation region control, I'd need a dumb version which just rains when I set the property * for visibility 1000 m, the skydome seems to unload. This is not a problem in the default rendering scheme, but it is with terrain haze and scattering shader, because the terrain haze is made seamless with what goes on in the skydome shader, not with background light. Thus, for 1.1 km visibility everything is fine, but if it deteriorates further suddenly rendering artefacts appear. Can we just not unload the skydome? Thanks, * Thorsten -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
