Re: [Flightgear-devel] Does changing paintjob/livery require a duplicate aircraft?
On Sat, 3 Jul 2004 01:19:27 +0100 Lee Elliott [EMAIL PROTECTED] wrote: As I understand it, the 3d model and texture handling in FG is done via plib, which treats the texture map path incorporated in the .ac model file as a relative path. Relative to what? To the directory containing the .ac file that uses the texture? To the directory containing the .xml file that has the Model tags? Relative to something else? Because if I understand it (and I may not), that's the heart of Erik's approach (and I'm hoping he'll jump in here if I've got it wrong). You have different subdirectories for each livery. Each one has the textures for that livery in it, as well as the xml file that specifies the 3D model, but NOT the 3D model itself (which is, say, in the parent directory). The .xml file gets read; the Modelpath tags provide a relative pathname from where the .xml is located upstairs to the .ac file; the .ac file calls textures which are loaded from the directory the thread is currently in -- namely, the one with the .xml file. This presumes that when the .xml file sends plib off to get the .ac file in a different directory by specifying a relative path, the place plib looks for subsequent file opens won't be in that different directory. That seems sensible. Do I have it right? If so, then the trick is having something in the (aircraftname)-set.xml file that makes the modelpath be conditional based on the livery. For example, for the 737, which currently has in its 737-set.xml model pathAircraft/737/Models/boeing733.xml/path /model and Aircraft/737/Models/boeing733.xml currently has pathB737-300.ac/path offsets stuff /offsets animation etc. you could instead have something like 737-set.xml containing model pathAircraft/737/Models/United/boeing733.xml/path condition equals property.../livery-name/property valueunited/value /equals /conditon /model model pathAircraft/737/Models/Southwest/boeing733.xml/path condition equals property.../livery-name/property valuesouthwest/value /equals /conditon /model Then, in Models/United/boeing733.xml and Models/Southwest/boeing733.xml, you have exactly the same content: path../B737-300.ac/path offsets stuff /offsets animation etc. so they both use the same 3D model; but the textures are drawn out of the directory that boeing733.xml is being read from, which means putting different textures in Models/United and Models/Southwest would do the trick. (in fact, since they have exactly the same content, each of the different boeing733.xml files could just read their content from elsewhere through an include) Does this make sense? Am I understanding you, Erik? -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgp1FBBM6muCM.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Does changing paintjob/livery require a duplicate aircraft?
Chris Metzler wrote: On Sat, 3 Jul 2004 01:19:27 +0100 Lee Elliott [EMAIL PROTECTED] wrote: As I understand it, the 3d model and texture handling in FG is done via plib, which treats the texture map path incorporated in the .ac model file as a relative path. Relative to what? To the directory containing the .ac file that uses the texture? To the directory containing the .xml file that has the Model tags? Relative to something else? Because if I understand it (and I may not), that's the heart of Erik's approach (and I'm hoping he'll jump in here if I've got it wrong). You have different subdirectories for each livery. Each one has the textures for that livery in it, as well as the xml file that specifies the 3D model, but NOT the 3D model itself (which is, say, in the parent directory). The .xml file gets read; the Modelpath tags provide a relative pathname from where the .xml is located upstairs to the .ac file; the .ac file calls textures which are loaded from the directory the thread is currently in -- namely, the one with the .xml file. I just tried this out. It doesn't work. :-( Plib expects the textures to be in the same directory as the geometry file which (at this moment) means you will always have to duplicate the .ac file. I think we need to push a patch to the plib developers list that optionally lets one specify the texture directory when loading a geometry file, but still default to the geometries own directory. I expect that approach might stand a chance of getting accepted. Does this make sense? Am I understanding you, Erik? That is what I was hoping should work, but it doesn't. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Does changing paintjob/livery require a duplicate aircraft?
Hi I'm new around here, and to the FG/plib way of doing these things, but i'd like to point that there are a lot of textures that can be shared, take a look at the 747 for example, and so my ideal directory structure would be like: example: a 757 with a panel.rgb, gear.rgb and fuselage.rgb Data/Aircraft/some_aircraft/Models/base0 : here put all the files, with fuselage.rgb having some default fallback (useful for online play or so, not everyone may have the livery someone else used in disk) Data/Aircraft/some_aircraft/Models/base1 : imagine someone redoes the panel texture with another style, put's the new panel.rgb here along with the old gear.rgb and fuselage.rgb, so you pick the panel you like most Data/Aircraft/some_aircraft/Models/United : if someone does a United Airlines painting, creates this folder and just put's the new fuselage.rgb here, since panel.rgb and gear.rgb don't change from airline to airline so you just specify something like this: base_livery/base0base_livery livery/United/livery and files with the same name in the United folder override files in the base0. One can imagine an arbitrary number of folders and priorities can be made, but i think this way should be enough. Of course this doesn't require remaking all aircrafts, but to use it properly, relevant textures must appear in different files. Hope i was clear :P Regards, Tiago O SAPO já está livre de vírus com a Panda Software, fique você também! Clique em: http://antivirus.sapo.pt ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Does changing paintjob/livery require a duplicate aircraft?
On Saturday 03 July 2004 09:49, Erik Hofman wrote: Chris Metzler wrote: On Sat, 3 Jul 2004 01:19:27 +0100 Lee Elliott [EMAIL PROTECTED] wrote: As I understand it, the 3d model and texture handling in FG is done via plib, which treats the texture map path incorporated in the .ac model file as a relative path. Relative to what? To the directory containing the .ac file that uses the texture? To the directory containing the .xml file that has the Model tags? Relative to something else? It's relative to the directory containing the .ac model. The default is for the texture map to reside in the same directory as the .ac model but you can edit the .ac file to change the texture path. I just tried creating a 'Textures' sub-dir in the 'Models' dir, which holds the .ac file, and moved the texture into it so that the .ac file was in 'Models', together with the xxx-model.xml file, but the texture.rgb was in the 'Models/Textures' sub-dir. Then I edited the .ac file to change the 'texture' entries from 'texture.rgb' to 'Textures/texture.rgb' and this seemed to work ok in AC3D. This doesn't really help though because it's still hard-coded into the .ac file. Because if I understand it (and I may not), that's the heart of Erik's approach (and I'm hoping he'll jump in here if I've got it wrong). You have different subdirectories for each livery. Each one has the textures for that livery in it, as well as the xml file that specifies the 3D model, but NOT the 3D model itself (which is, say, in the parent directory). The .xml file gets read; the Modelpath tags provide a relative pathname from where the .xml is located upstairs to the .ac file; the .ac file calls textures which are loaded from the directory the thread is currently in -- namely, the one with the .xml file. I just tried this out. It doesn't work. :-( Plib expects the textures to be in the same directory as the geometry file which (at this moment) means you will always have to duplicate the ..ac file. See above, but you still need to duplicate the .ac file to specify different textures - wherever they're put. I think we need to push a patch to the plib developers list that optionally lets one specify the texture directory when loading a geometry file, but still default to the geometries own directory. I expect that approach might stand a chance of getting accepted. Does this make sense? Am I understanding you, Erik? That is what I was hoping should work, but it doesn't. Erik A patch to plib that allowed a prefix to be added to the texture path specified in the .ac model is really the only answer to this problem. The prefix could be used to either specify a sub-dir containing the required texture.rgb or it could be a simple file prefix to allow choosing between say, UA-737.rgb or MyAirline-737.rgb textures - in this case the texture specified in the .ac file would just be 737.rgb As Innis suggested, it would be possible to replace the named texture with the one you want to use at run-time, and this could be coded into FG but it would have serious security implications. The FG user would need to have write permissions to the FG installation to permit the overwriting of the installed files, and that's not really on. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Does changing paintjob/livery require a duplicate aircraft?
On Fri, 02 Jul 2004 16:43:23 -0500 Curtis L. Olson [EMAIL PROTECTED] wrote: For a particalar model it would be possible to just modify the existing textures to give it a new livery. If you want to create an entirely new livery without disturbing the original, you could make a copy of the aircraft-set.xml file. Then make a copy of the .ac file and update the new -set.xml file to point to the new .ac file. .ac files can be hand edited with a text editor and it's pretty easy to find texture names and change them. So you could copy all the textures, give them new names and then update the .ac file to point to the new names. Then you can modify the copies of the original textures to the new livery. This makes perfect sense, and I think Innis Cunningham made the same point as well; but I think I did a crappy job of describing what I was getting at. Definitely you could change liveries by just replacing the texture, or by having more than one .ac file which differ only in the texture names, with different .xml files pointing to the different .ac's, and then different -set.xml files pointing to those. But in such cases, the paint job replacement is universal; all Cessnas or Piper Cubs or 747s in a scene at the same time will have this same different paint job. I was trying to imagine how one might have multiple instances of the same aircraft, but with different paint jobs, in a scene at the same time (e.g. taxiing towards take-off in your Cessna behind another Cessna that looks different from yours). -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpHS9r0tV2nq.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Does changing paintjob/livery require a duplicate aircraft?
Have pity on me; I'm new to this stuff. As I get it now, the textures applied to 3D models are specified in the .ac file (or .3ds file or whatever). This, in turn, means that if you want a different paint job for the Cessna, or different airline's livery for the 737, you need a different .ac file. And since the .ac model is uniquely specified in the .xml file for the model, which in turn is uniquely specified in the .xml file for the aircraft as a whole, a different paint job/livery effectively means a new aircraft. Is this right? -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgp8v6Zj9Epta.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Does changing paintjob/livery require a duplicate aircraft?
On Friday 02 July 2004 23:07, Chris Metzler wrote: Have pity on me; I'm new to this stuff. As I get it now, the textures applied to 3D models are specified in the .ac file (or .3ds file or whatever). This, in turn, means that if you want a different paint job for the Cessna, or different airline's livery for the 737, you need a different .ac file. And since the .ac model is uniquely specified in the .xml file for the model, which in turn is uniquely specified in the .xml file for the aircraft as a whole, a different paint job/livery effectively means a new aircraft. Is this right? -c Yes, that's pretty much the case right now, although you might be able to recycle some parts, like the FDM definition file. When more AI traffic will be added later on, I can see a need to make this more flexible. I wouldn't know how this could be done easily though.., Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Does changing paintjob/livery require a duplicate aircraft?
Chris Metzler wrote: Have pity on me; I'm new to this stuff. As I get it now, the textures applied to 3D models are specified in the .ac file (or .3ds file or whatever). This, in turn, means that if you want a different paint job for the Cessna, or different airline's livery for the 737, you need a different .ac file. And since the .ac model is uniquely specified in the .xml file for the model, which in turn is uniquely specified in the .xml file for the aircraft as a whole, a different paint job/livery effectively means a new aircraft. Is this right? http://baron.flightgear.org/pipermail/flightgear-devel/2004-May/028023.html I can add to that that you can easily re-use the animation file like this: ?xml version=1.0? PropertyList include=f16.xml pathf16klu.ac/path /PropertyList Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Does changing paintjob/livery require a duplicate aircraft?
Chris Metzler wrote: [...] a different paint job/livery effectively means a new aircraft. Is this right? Pretty much. Although this wouldn't really be hard to fix, if anyone wants to give it a shot. One way to go about it would be to provide a mapping somehwere in the aircraft properties which mapped texture names in the 3D model to actual relative filenames. Then the .ac file could be written using textures like Body1, TailNumber, etc..., and you could wrap a bunch of skins up in the -set.xml file inside conditionals. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Does changing paintjob/livery require a duplicate aircraft?
Chris Metzler wrote: Have pity on me; I'm new to this stuff. As I get it now, the textures applied to 3D models are specified in the .ac file (or .3ds file or whatever). This, in turn, means that if you want a different paint job for the Cessna, or different airline's livery for the 737, you need a different .ac file. And since the .ac model is uniquely specified in the .xml file for the model, which in turn is uniquely specified in the .xml file for the aircraft as a whole, a different paint job/livery effectively means a new aircraft. Is this right? Here's a couple things to consider. For a particalar model it would be possible to just modify the existing textures to give it a new livery. If you want to create an entirely new livery without disturbing the original, you could make a copy of the aircraft-set.xml file. Then make a copy of the .ac file and update the new -set.xml file to point to the new .ac file. .ac files can be hand edited with a text editor and it's pretty easy to find texture names and change them. So you could copy all the textures, give them new names and then update the .ac file to point to the new names. Then you can modify the copies of the original textures to the new livery. It's important to test that your new aircraft will run at every step of the process though. It's unfortunately very easy to mess up a path or any number of other things and wind up with something that flightgear can't load ... and unfortunately it often doesn't produce any useful error messages when this happens so it's very difficult to know what to go back and look at and fix ... unless you know what you just fiddled with so you can go back and revert it. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Does changing paintjob/livery require a duplicate aircraft?
Here is an idea: Right now, if we want to include an external model, we can do something like: model pathdirectory/*.xml/path /model What we can do is add a new type of tags called textures. It will be something like this: texture pathdirectory/*.xml/path /texture By using these texture tags, FlightGear will be able to load different textures (located in different folders) according to different airlines. Regards, Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Does changing paintjob/livery require a duplicate aircraft?
On Saturday 03 July 2004 00:00, Ampere K. Hardraade wrote: Here is an idea: Right now, if we want to include an external model, we can do something like: model pathdirectory/*.xml/path /model What we can do is add a new type of tags called textures. It will be something like this: texture pathdirectory/*.xml/path /texture By using these texture tags, FlightGear will be able to load different textures (located in different folders) according to different airlines. Regards, Ampere While it's easy to describe logically, it could be a little harder to implement practically. As I understand it, the 3d model and texture handling in FG is done via plib, which treats the texture map path incorporated in the .ac model file as a relative path. To be able to switch textures at run-time would require the texture path incorporated in each .ac model to be treated as a logical path, which could then be 'aliased' as required. Bottom line: it would need a re-definition of the .ac standard, and subsequent implementation in plib. ...I think. It would be nice though...;) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Does changing paintjob/livery require a duplicate aircraft?
On Fri, 2 Jul 2004 23:23:29 +0200 Durk Talsma [EMAIL PROTECTED] wrote: When more AI traffic will be added later on, I can see a need to make this more flexible. Yeah, that was one of the reasons I asked -- I remember seeing livery tags in the XML file you demonstrated for scheduled AI flight plans. I was wondering how that might end up being implemented, or whether it's even possible. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpRKyADhBxfA.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
