Re: [Flightgear-devel] Issues regarding the "texture-path" tags in XML.
Paul Surgeon wrote: On Sunday 11 September 2005 23:15, Erik Hofman wrote: Yes, correct. The texture positioning is done in the 3d model. So there's nothing we can do other than duplicating the model. But if a model is UV mapped shouldn't it still work? With UV mapping the texture co-ords are normalized to 1 if I'm not mistaken so doubling the texture size for instance shouldn't cause any problems. I think it should work, but only if the texture layout is exactly the same. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Issues regarding the "texture-path" tags in XML.
On Sun, Sep 11, 2005 at 11:15:31PM +0200, Erik Hofman wrote: > The texture positioning is done in the 3d model. So > there's nothing we can do other than duplicating the model. ... unless you use a 'material' animation, which I would prefer in any case. Not only does this allow livery switching at runtime, it also doesn't require to duplicate *all* textures. See the bo105's emblem for an example. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Issues regarding the "texture-path" tags in XML.
Melchior FRANZ wrote: On Sun, Sep 11, 2005 at 11:15:31PM +0200, Erik Hofman wrote: The texture positioning is done in the 3d model. So there's nothing we can do other than duplicating the model. ... unless you use a 'material' animation, which I would prefer in any case. Not only does this allow livery switching at runtime, it also doesn't require to duplicate *all* textures. See the bo105's emblem for an example. I'm starting to lag behind on this stuff! Nice work Melchior. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Issues regarding the "texture-path" tags in XML.
On September 12, 2005 04:10 am, Melchior FRANZ wrote: > ... unless you use a 'material' animation, which I would prefer > in any case. Not only does this allow livery switching at runtime, > it also doesn't require to duplicate *all* textures. See the > bo105's emblem for an example. > > m. Okay, I will look into that. Thanks, Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Issues regarding the "texture-path" tags in XML.
On Mon, Sep 12, 2005 at 10:16:55AM +0200, Erik Hofman wrote: > Melchior FRANZ wrote: > >... unless you use a 'material' animation, which I would prefer > >in any case. Not only does this allow livery switching at runtime, > >it also doesn't require to duplicate *all* textures. See the > >bo105's emblem for an example. > > I'm starting to lag behind on this stuff! BTW: this works with textures of different resolutions -- thanks to the normalized UV coords --, but they do still need to be laid out in the same way. (Although you can work a bit around that using 'texrotate' etc. animations.) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] GPS Track
On Monday 12 September 2005 00:20, Steve Knoblock wrote: > The Digitrak autopilot project is coming along. I have the first mode > running, which captures and holds the GPS track. I get the GPS heading > to feed to the autopilot controller from the default GPS instrument. > The autopilot is set to reduce the GPS bug error to zero by driving > the aileron until the orientation roll equals the target roll. This > works fine, however, I notice some differences in the numbers reported > by the heading and track properties. Are you sure that the Digitrack actually knows the roll angle of the airplane? > I may be a dummy, but can anyone explain this? Not the variation > between true and magnetic, but between GPS and orientation. Heading and track are _not_ the same thing. Heading is the direction that the nose of the aircraft is pointing. Track is the direction that the aircraft is moving. You probably have a crosswind that is blowing your aircraft to one side. The numbers that you observe seem quite reasonable. If you try to fly parallell to the wind, heading and track should be similar. For a good explanation of the different GPS navigation terms read chapter 7 of John Bell's "Cockpit GPS" available on-line http://www.cockpitgps.com -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Flightgear-devel Digest, Vol 29, Issue 16
>> works fine, however, I notice some differences in the numbers reported >> by the heading and track properties. > >Are you sure that the Digitrack actually knows the roll angle of the airplane? > I am not sure I have the technical background to understand how the Digitrak actually works. It does not use a turn coordinator as a source of roll information. There is an explanation on the website http://www.trutrakflightsystems.com/overview.html which may be new, I do not remember having it when I made the model for MSFS. In the FG generic autopilot, the second stage of the heading bug hold, inputs /orientation/roll-deg into the controller and uses the target roll as the reference. I copied this to get it working. I looked at the KAP140, but it depends on the turn indicator for input to the wing leveler (roll mode). The Digitrak docs clearly state that it does not employ a turn coordinator, so I cannot take this approach. The overview claims it can sense motion about the three axes, apparently through the directional gyro. I assume it uses that to obtain roll angle. The orientation/roll-angle would be a good place to start, being closest to getting the roll information from the digital gyro. Is it possible to use the directional gyro as a source? It seems that I would need to create my own gyro model to do this. The DG/heading indicator only outputs heading. I can only assume from the documents (the PDF manual particularly) that the gyro is periodically corrected for drift using the magnetometer or the GPS. I have not decided how to simulate this. >Heading and track are _not_ the same thing. Heading is the direction that the >nose of the aircraft is pointing. Track is the direction that the aircraft is You're right. I forgot about wind effects. I have studied this in instructional texts on navigation, but I have become lazy flying PC flight sims by GPS route most of the time. Thanks for clearing that up, Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Lufthansa liveries
Thanx. :) I'm glad you like it. About the mini howto, I have no idea what to write in it. I've just took the original file, and repainted it in Gimp. For source I used airliners.net and some of my own photos. Then, as the resolution was too low for the 737, I decided to double the resolution. That's all. Regards, Gabor On Sunday 11 September 2005 15:45, mat churchill wrote: > Gabor these look great. > How about a mini howto on the texture creation for the livery, you seem > to have got the balance just right between the look and the resolution > of the texture. > > Another screenshot: > > http://projects.34sp.com/Flightgear/luthansa.jpg > > Clouds seem to have come a long way recently as well. > > Mat ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/b1900d b1900d-set.xml, 1.6,
"Curtis L. Olson" wrote: > Update of /var/cvs/FlightGear-0.9/data/Aircraft/b1900d > In directory baron:/tmp/cvs-serv4749 > Modified Files: > b1900d-set.xml b1900d-sound.xml b1900d.xml > Log Message: > > Syd Adams: > > Here are some updates to the b1900d: The panel looks pretty nice it's just that I failed to deliver appropriate operation. In simple words: May I find a readme which tells me how to start the engines ? I remember someone made such a readme for the Beaver, which I couldn't operate without. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] EasyXML.cxx
In its JSBSim configuration there is a problem with easyxml.cxx in that
it frees the parser before using it which is generally not a good thing.
i.e.
if (!input.good()) {
XML_ParserFree(parser);
throw sg_io_exception("Problem reading file",
sg_location(path,
XML_GetCurrentLineNumber(parser),
XML_GetCurrentColumnNumber(parser)),
"SimGear XML Parser");
}
Surely the XML_ParserFree should be after the throw? (I appreciate this
is 99% safe, but it probably isn't the way that things should be done).
--Richard
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Issues regarding the "texture-path" tags inXML.
Hi Guys Just wondering why if it is possible in the AI to use one model with one or more liveries why it is not possible in the main aircraft folder. Cheers Innis Erik Hofman writes Ampere K. Hardraade wrote: KoverSrac and I have been doing some experiments with the texture-path tags to allow aircrafts to have multiple liveries. However, there are some issues related to the tags that need to be fixed. There are two issues that we have noticed so far. The first issue is that the property tags don't work inside the texture-path tags. ie. sim/livery doesn't change the livery even if property sim/livery exists. This makes texture path assignment at runtime impossible. The second issue has to do with the resolution of the texture. When the texture-path tags are used, all the livery textures need to have the same resolution as the original livery. Otherwise, this would occur: http://www.students.yorku.ca/~ampere/fgfs-screen-012.jpg Yes, correct. The texture positioning is done in the 3d model. So there's nothing we can do other than duplicating the model. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] ASCII interface
Hi, do we already have ASCII realtime I/O for data like position, orientation, controls, configuration etc.? -Gerhard -- o o Gerhard Wesp| http://www.cosy.sbg.ac.at/~gwesp/ \_/ See homepage for email address! ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
