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] 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.
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 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.
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 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. > > Erik 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. Paul ___ 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.
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] Issues regarding the "texture-path" tags in XML.
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 Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
