Re: [Flightgear-devel] Flash with altitude change
On Apr 23, 2008, at 4:09 PM, Adam Dershowitz wrote: On Apr 21, 2008, at 2:17 PM, Melchior FRANZ wrote: * Adam Dershowitz -- Monday 21 April 2008: I did make the minor change that Alex suggested in this discussion: [...] and then rebuilt and it seems to be working. Is that essentially the change that you were referring to? It's the correct thread. The fix isn't and will probably cause other problems (jitter in some newer view modes, IIRC), but as long as it works for you, all is well. :-) m. I have run into what might be different issue...and might be what you are talking about. With playback data the ground slightly jumps back and forth. It looks almost like a vibration. It seems to happen with all of the views. At first I thought that it had to do with how smooth my Lat/Long data was, so I tried fixing that. But it didn't help. So I finally just did a recording of a simple takeoff at high frequency, with everything at the defaults: fgfs --generic=file,out,32,/Users/dersh/Documents/Cases/587\ Animation/DFDR\ data/test_out.csv,playback and then did a playback: fgfs --generic=file,in,32,/Users/dersh/Documents/Cases/587\ Animation/DFDR\ data/test_out.csv,playback --fdm=null and I get this "jitter" of the ground back and forth on playback. It is not much (perhaps a couple of feet back and forth). I started to wonder if it might be that the code that reads in the lat/long is not reading in enough significant digits? Internally clearly there are enough because it looks smooth when I am recording. Is there some rounding, or reading in as float instead of a double? Any ideas on this one? Is it the same bug that was fixed in CVS? I have not yet tried to rebuild from CVS since Alex's suggestion to change the order of: globals->get_viewmgr()->update(delta_time_sec); upwards after the line fgUpdateTimeDepCalcs(); seemed to be working for me. But did I hit another issue related to this? Melchior, is this also what you fixed? I am a little nervous about doing a new build because I am using Tat's download/build instructions for a Mac and then I applied Pigeon's patch to capture video. All seems to work, but I am not sure which pieces of that process might break if I do a full CVS update and rebuild. That is also why I have stayed with PLIB. --Adam I spent a while trying to track this down, and finally figured out what is going on. The problem is that generic.cxx can only handle floats, and that is not enough resolution for latitude and longitude, so the last few digits are lost in the conversion. I found a simple solution, that is working for me to be able to read in data correctly: So I changed line 208 of generic.cxx from: _in_message[i].prop->setFloatValue((float)val); to read in a double: _in_message[i].prop->setDoubleValue(val); Now, if I play my data files the aircraft moves in a smooth way. So I figure the more general solution is to add a new type to the generic protocol which is "double". That way there is no change to any existing examples. I have attached a few diff files that work for me. playback.xml.diff Description: Binary data generic.hxx.diff Description: Binary data generic.cxx.diff Description: Binary data the only changes are to generic.hxx and generic.cxx to add the new double type. I have also added a diff to playback.xml that make it use doubles for latitude and longitude so that I could test it out. And it worked fine both to record and to playback in a nice smooth way. If there is a better way to submit this patch please let me know. --Adam - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flash with altitude change
On Apr 21, 2008, at 2:17 PM, Melchior FRANZ wrote: > * Adam Dershowitz -- Monday 21 April 2008: >> I did make the minor change that Alex suggested in this discussion: >> [...] >> and then rebuilt and it seems to be working. Is that essentially >> the change that you were referring to? > > It's the correct thread. The fix isn't and will probably cause other > problems (jitter in some newer view modes, IIRC), but as long as it > works for you, all is well. :-) > > m. > I have run into what might be different issue...and might be what you are talking about. With playback data the ground slightly jumps back and forth. It looks almost like a vibration. It seems to happen with all of the views. At first I thought that it had to do with how smooth my Lat/Long data was, so I tried fixing that. But it didn't help. So I finally just did a recording of a simple takeoff at high frequency, with everything at the defaults: fgfs --generic=file,out,32,/Users/dersh/Documents/Cases/587\ Animation/DFDR\ data/test_out.csv,playback and then did a playback: fgfs --generic=file,in,32,/Users/dersh/Documents/Cases/587\ Animation/DFDR\ data/test_out.csv,playback --fdm=null and I get this "jitter" of the ground back and forth on playback. It is not much (perhaps a couple of feet back and forth). I started to wonder if it might be that the code that reads in the lat/long is not reading in enough significant digits? Internally clearly there are enough because it looks smooth when I am recording. Is there some rounding, or reading in as float instead of a double? Any ideas on this one? Is it the same bug that was fixed in CVS? I have not yet tried to rebuild from CVS since Alex's suggestion to change the order of: globals->get_viewmgr()->update(delta_time_sec); upwards after the line fgUpdateTimeDepCalcs(); seemed to be working for me. But did I hit another issue related to this? Melchior, is this also what you fixed? I am a little nervous about doing a new build because I am using Tat's download/build instructions for a Mac and then I applied Pigeon's patch to capture video. All seems to work, but I am not sure which pieces of that process might break if I do a full CVS update and rebuild. That is also why I have stayed with PLIB. --Adam - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] osgShadow - a nosuccess-story
--- Torsten Dreyer <[EMAIL PROTECTED]> schrieb: > Hi all > > encouraged by my first "bugfix" for the osg-code and > after digging through the > osg examples, I found the osgShadow implementation. > I extracted the relevant > code from the osgshadow example (which looks very > promising) and merged it > into the renderer.cxx to see, if it works. > To keep it short: I tried the ShadowMap, the > SoftShadowMap and the > ShadowVolume technique. Both ShadowMap techniques > produce some > visual "effects" but no shadow. The ShadowVolume > technique (that's the > technique implemented in the plib version) print > some debug messages and > after eating all my 4GB of memory, I get a unknown > exception in the main loop > while still showing the splash screen. The > ShadowVolume is still under > development so there is a chance that it might be > usable for us in the > future. > > Sorry - you still have to "get yourself some cheap > sunglasses" in osgland. > > Greetings, Torsten > So much as I know, Tim is still working on that. For a while he send a screenshot in the IRC-Chat- looked promising. But it is nice to see, that there are also some others working on that! Cheers HHS still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html __ Gesendet von Yahoo! Mail. Mehr Möglichkeiten, in Kontakt zu bleiben. http://de.overview.mail.yahoo.com - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] osgShadow - a nosuccess-story
Hi all encouraged by my first "bugfix" for the osg-code and after digging through the osg examples, I found the osgShadow implementation. I extracted the relevant code from the osgshadow example (which looks very promising) and merged it into the renderer.cxx to see, if it works. To keep it short: I tried the ShadowMap, the SoftShadowMap and the ShadowVolume technique. Both ShadowMap techniques produce some visual "effects" but no shadow. The ShadowVolume technique (that's the technique implemented in the plib version) print some debug messages and after eating all my 4GB of memory, I get a unknown exception in the main loop while still showing the splash screen. The ShadowVolume is still under development so there is a chance that it might be usable for us in the future. Sorry - you still have to "get yourself some cheap sunglasses" in osgland. Greetings, Torsten - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Generic Headshake/G-compression
--- On Sun, 20/4/08, Ron Jensen wrote: > On Sun, 2008-04-20 at 12:55 -0700, Stuart Buchanan wrote: > > Hi All, > > > > Enthused by a comment on the forum by snork > > > (http://www.flightgear.org/forums/viewtopic.php?t=1333), > I've been > > working on an extension to the generic blackout/redout > script which > > attempts to simulate the feeling of compression due to > g-forces, by > > moving the pilot viewpoint vertically depending on the > apparent > > g-force. This has now been checked in. > > 2) Currently the redout and headshake enabling > properties are > > userarchive, which (as I understand it) means that the > user's > > preference will over-write any aircraft setting. Given > that both these > > generic features duplicate existing aircraft-specific > code, I think I > > should remove this flag, so aircraft designers can > over-ride it. Any > > comments? > > STRONGLY OPPOSE. User preference should absolutely > outweigh the > aircraft designer. While I might feel, as an aircraft > designer, that a > function adds a degree of realism, I can't and > don't test on different > hardware, monitor resolutions, multi-head setups, hardware > simulator > setups, etc. which head-shake may cause problems with. > > I personally find it annoying to have the panels jumping > around during > IFR flight. OK. I've left the enabling properties as userarchive. However, aircraft designers can _disable_ it by simply settings /sim/rendering/headshake/rate-m-g=0 I think that should satisfy both users and aircraft designers. -Stuart __ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] helipad lighting (loxl)
Does anyone here know how helipad lighting typically works in a case like this? http://doris.ooe.gv.at/viewer/%28S%28lzssrqnmskruqee2yda3lcus%29%29/init.aspx?ks=alk&karte=gk&koord=62803.89;343426.49&massstab=15000 It's sized 25x25m with 7x7 edge lights and 4 corner lights. I assume that, depending on the wind direction, only three edges are lighted and the corner lights of the opening are turned on, so that you'd fly into an U opening: | wind | \|/ . . * * * * * * * * * * * * * * * * * * . . . . . * o o Any idea about the colors? Google didn't show me anything useful. I could imagine that the corners are green and the edges yellow or white. m. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Un-hide panel?
I am interested if there is a way to make a 2-D panel visible when not in the cockpit view? I have a mini-panel that shows a few variables, and I want to know if there is a way to make this small panel of information visible when looking at an outside view of the aircraft. Is there just a property that hides the panel for views other then view 0? Is this handled by a nasal script somewhere? Or is it coded directly into the sourcecode somewhere? /sim/panel/visibility stays true for other views, when the panel is not actually visible. Thanks, --Adam - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [patch] fix pick animations
hi,
this is a small (-1/+3) patch to fix pick animations on scenery objects. since
picking apparently doesn't care for polygon offsets, the objects got into the
picklist in the wrong way. now, no matter if the "highlight group" or
the "normal group" gets hit first, the callback will fire.
... i wonder how much water goes down the danube before this gets
committed :-p
cheers,
-till
diff --git a/simgear/scene/model/animation.cxx b/simgear/scene/model/animation.cxx
index 1bb11be..4d9c773 100644
--- a/simgear/scene/model/animation.cxx
+++ b/simgear/scene/model/animation.cxx
@@ -2027,14 +2027,16 @@ SGPickAnimation::createAnimationGroup(osg::Group& parent)
// Contains the normal geometry that is interactive
osg::ref_ptr normalGroup = new osg::Group;
+ normalGroup->setName("pick normal group");
normalGroup->addChild(commonGroup);
// Used to render the geometry with just yellow edges
osg::Group* highlightGroup = new osg::Group;
+ highlightGroup->setName("pick highlight group");
highlightGroup->setNodeMask(SG_NODEMASK_PICK_BIT);
highlightGroup->addChild(commonGroup);
SGSceneUserData* ud;
- ud = SGSceneUserData::getOrCreateSceneUserData(highlightGroup);
+ ud = SGSceneUserData::getOrCreateSceneUserData(commonGroup);
std::vector actions;
actions = getConfig()->getChildren("action");
for (unsigned int i = 0; i < actions.size(); ++i)
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ai-Traffic (Interactive)2....
Hi Durk, --- Durk Talsma <[EMAIL PROTECTED]> schrieb: >> You mean that (for instance) /ai/aircraft[100]/ does >> not always refer to the >> same aircraft, but changes as aircraft are added or >> deleted as demanded? Right >> However, each >> property should remain pointed to the same aircraft. >> If that is no longer the >> case, then it looks like a bug to me. I will have a >> look, but the property >> tree itself isn't really my expertise, so I might be >> wrong here. It seems to me, but maybe I did understand something wrong. At least in the moment it seems not to be possible for me to add a property driven feature to the AI-Interactive-Aircraft. My wish would be, as an example, that the 737 switch on its landinglight and strobes at a velocity greater than 31 ktn and switches off the landinglights at a altitude greater than 1 ft. I would see something to all AI-InteractiveTraffic-Aircrafts- looks more realistic. > Cheers, > Durk > Regards Heiko still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html __ Gesendet von Yahoo! Mail. Mehr Möglichkeiten, in Kontakt zu bleiben. http://de.overview.mail.yahoo.com - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
