[Flightgear-devel] Two scenery design issues.
Hi. I'm just finishing up a set of general-purpose "runway length remaining" signs, along with a python script that will insert them into appropriate .stg files as desired. I used the FAA Advisory Circulars 150/5340-18C (Standards for Airport Sign Systems) and 150/5345-44 (Specification for Taxiway and Runway Signs) for the physical size of the signs, the physical size of the numerals upon them, and for the script's placement of the signs (including checking taxiways and other runways in runways.dat to avoid conflicting placements, adjusting +/- 50 feet as necessary). This is part of an effort overall to do up KDCA and KSDF, but the signs and accompanying script should be generically applicable, at least in the U.S. I dunno whether the international standards are different (if you do, please let me know). Right now, they're single-sided signs (I may adjust the script to do double-sided signs by placing two single-sided signs back to back, but I'm holding off on making double-sided signs directly because that's 105 or so signs to make and I'm tired). I've run into two issues with which I'm hoping folks here can help me. One's a Blender/ac3d materials + texturing problem. The other deals with the relationship between the parameters in the .stg file, and the actual placement of the object. 1. When I first tried to make these guys, I applied a black material to the entire sign; then, I took the appropriate white-numeral-on-black texture and UV-mapped it to one face, rotated so that it looks correct from Blender's "front" view. Everything looked great in Blender, both in the 3D windows (with "textured view" on), and in the rendering window. Once exported to ac3d and brought into fgfs, though, what I got was a black square. After lots of tinkering around with the shading numbers for the material by editing the .ac file directly, I found that the only way I could get the numeral to show was by assigning emissivity to the material. Does this make sense to you? It sure doesn't to me. Even worse, when I did this (added emissivity to the material), the opposite side from the side where the numeral is supposed to appear *also* showed the numeral, but rotated 90 degress. It was as if I'd UV-mapped it to that face too (with a bad/uncorrected rotation), even though I didn't (I've checked and checked). Why is this other side showing the numeral too, and with a bogus rotation on the face? Any ideas on things I might check? I solved this problem in the interim by UV-mapping *all six* faces on the sign, but mapping the five blank faces to small parts of the white-numeral-on-black image that only showed black. Naively, I would expect that texturing all six sides like this involves needless texture manipulation at runtime -- hence my desire to just paint the whole thing black, then apply texture to one face. But as noted above, this hasn't worked. 2. My understanding of the .stg file lines is this: a line like OBJECT_SHARED Models/Airport/Signs/distance_1.xml -85.746956 38.181455 146 165.47 places the object at the lat/lon specified by the first two arguments after the path, at an altitude ASL in meters given by the third argument after the path, and with a rotation from true north given by the very last argument. This seems borne out by my experience with placing the Washington Monument -- I gave it an angle of 0, and it was aligned with its sides facing N, S, E and W. So I would have expected that if I gave these signs an angle value equal to the runway direction, they'd be facing you as you took off from either that direction, or the opposite direction, on the runway. Instead, the signs show up at an unusual angle from the runway direction. It's as if the signs were not aligned properly within Blender -- except they are, I've checked and checked. Am I misinterpreting what the angle setting (that last argument) in the .stg file means? If not, can you think of anything I can check as to why angle 0.00 isn't giving me a sign that points north or south, but instead at a weird angle? Thanks, -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 pgpZuxEJr8b1s.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Two scenery design issues.
Chris Metzler wrote: > Sent: 10 August 2004 08:49 > To: [EMAIL PROTECTED] > Subject: [Flightgear-devel] Two scenery design issues. > > > > Hi. I'm just finishing up a set of general-purpose "runway > length remaining" signs, along with a python script that will > insert them into appropriate .stg files as desired. I used > the FAA Advisory Circulars 150/5340-18C (Standards for > Airport Sign Systems) and 150/5345-44 (Specification for > Taxiway and Runway Signs) for the physical size of the signs, > the physical size of the numerals upon them, and for the > script's placement of the signs (including checking taxiways > and other runways in runways.dat to avoid conflicting > placements, adjusting +/- 50 feet as necessary). This is > part of an effort overall to do up KDCA and KSDF, but the > signs and accompanying script should be generically > applicable, at least in the U.S. I dunno whether the > international standards are different (if you do, please let > me know). Right now, they're single-sided signs (I may adjust > the script to do double-sided signs by placing two > single-sided signs back to back, but I'm holding off on > making double-sided signs directly because that's 105 or so > signs to make and I'm tired). > > I've run into two issues with which I'm hoping folks here can > help me. One's a Blender/ac3d materials + texturing problem. > The other deals with the relationship between the parameters > in the .stg file, and the actual placement of the object. > > 1. When I first tried to make these guys, I applied a black > material to the entire sign; then, I took the appropriate > white-numeral-on-black texture and UV-mapped it to one face, > rotated so that it looks correct from Blender's "front" view. > Everything looked great in Blender, both in the 3D windows > (with "textured view" on), and in the rendering window. Once > exported to ac3d and brought into fgfs, though, what I got > was a black square. After lots of tinkering around with the > shading numbers for the material by editing the .ac file > directly, I found that the only way I could get the numeral > to show was by assigning emissivity to the material. Does > this make sense to you? It sure doesn't to me. Even worse, > when I did this (added emissivity to the material), the > opposite side from the side where the numeral is supposed to appear > *also* showed the numeral, but rotated 90 degress. It was as > if I'd UV-mapped it to that face too (with a bad/uncorrected > rotation), even though I didn't (I've checked and checked). > Why is this other side showing the numeral too, and with a > bogus rotation on the face? Any ideas on things I might check? > > I solved this problem in the interim by UV-mapping *all six* > faces on the sign, but mapping the five blank faces to small > parts of the white-numeral-on-black image that only showed > black. Naively, I would expect that texturing all six sides > like this involves needless texture manipulation at runtime > -- hence my desire to just paint the whole thing black, then > apply texture to one face. But as noted above, this hasn't worked. > AC3D seems to add the material colour to the texture. Try using material colour white, and mapping the texture onto all faces that you want to be black. The export from Blender to AC3D has some problems too, ISR, so you might try applying the texture in AC3D, if you have it. Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Two scenery design issues.
Chris Metzler wrote: Hi. I'm just finishing up a set of general-purpose "runway length remaining" signs, along with a python script that will insert them into appropriate .stg files as desired. I used the FAA Advisory Circulars 150/5340-18C (Standards for Airport Sign Systems) and 150/5345-44 (Specification for Taxiway and Runway Signs) for the physical size of the signs, the physical size of the numerals upon them, and for the script's placement of the signs (including checking taxiways and other runways in runways.dat to avoid conflicting placements, adjusting +/- 50 feet as necessary). This is part of an effort overall to do up KDCA and KSDF, but the signs and accompanying script should be generically applicable, at least in the U.S. That would be great. I definitely like to see this added to terragear: http://www.terragear.org I've run into two issues with which I'm hoping folks here can help me. One's a Blender/ac3d materials + texturing problem. The other deals with the relationship between the parameters in the .stg file, and the actual placement of the object. 1. When I first tried to make these guys, I applied a black material to the entire sign; then, I took the appropriate white-numeral-on-black texture and UV-mapped it to one face, rotated so that it looks correct from Blender's "front" view. Everything looked great in Blender, both in the 3D windows (with "textured view" on), and in the rendering window. Once exported to ac3d and brought into fgfs, though, what I got was a black square. After lots of tinkering around with the shading numbers for the material by editing the .ac file directly, I found that the only way I could get the numeral to show was by assigning emissivity to the material. Does this make sense to you? It sure doesn't to me. Yo have to apply a _white_ (or nearly white) material to the object because that color is the maximum color applied to an object (including the texture). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Two scenery design issues.
Vivian Meazza wrote: AC3D seems to add the material colour to the texture No, it's OpenGL that does this. With everything related to modeling you have to take into account the possibilities and requirements of OpenGL, and not that of your 3d modeler program. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Two scenery design issues.
On Tuesday 10 August 2004 10:14, Erik Hofman wrote: > Chris Metzler wrote: > > Hi. I'm just finishing up a set of general-purpose "runway length > > remaining" signs, along with a python script that will insert them into > > appropriate .stg files as desired. I used the FAA Advisory Circulars > > 150/5340-18C (Standards for Airport Sign Systems) and 150/5345-44 > > (Specification for Taxiway and Runway Signs) for the physical size of > > the signs, the physical size of the numerals upon them, and for the > > script's placement of the signs (including checking taxiways and other > > runways in runways.dat to avoid conflicting placements, adjusting +/- > > 50 feet as necessary). This is part of an effort overall to do up > > KDCA and KSDF, but the signs and accompanying script should be > > generically applicable, at least in the U.S. > > That would be great. I definitely like to see this added to terragear: > http://www.terragear.org > > > I've run into two issues with which I'm hoping folks here can help me. > > One's a Blender/ac3d materials + texturing problem. The other deals > > with the relationship between the parameters in the .stg file, and the > > actual placement of the object. > > > > 1. When I first tried to make these guys, I applied a black material > > to the entire sign; then, I took the appropriate white-numeral-on-black > > texture and UV-mapped it to one face, rotated so that it looks correct > > from Blender's "front" view. Everything looked great in Blender, > > both in the 3D windows (with "textured view" on), and in the rendering > > window. Once exported to ac3d and brought into fgfs, though, what I > > got was a black square. After lots of tinkering around with the shading > > numbers for the material by editing the .ac file directly, I found that > > the only way I could get the numeral to show was by assigning emissivity > > to the material. Does this make sense to you? It sure doesn't to me. > > Yo have to apply a _white_ (or nearly white) material to the object > because that color is the maximum color applied to an object (including > the texture). > > Erik As Erik (and Vivian in another post) have said, you need to make the base colour of the polys that make up the signboard a light (white) colour. How many polys are you using for the signboard? I'm guessing that you're just using one and have it double-sided. I think you'll either have to use two single-sided rectangles for it and apply appropriate front and back textures to each of the rectangles or, as the vertex count would be the same as for two rectangles, you could actually consider using a cube for the board. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Two scenery design issues.
On Tue, 10 Aug 2004 20:26:17 +0100 Lee Elliott <[EMAIL PROTECTED]> wrote: > > How many polys are you using for the signboard? I'm guessing that > you're just using one and have it double-sided. Nah, then it'd be infinitely thin, and look too weird. They're 2"/5cm thick. > I think you'll either > have to use two single-sided rectangles for it and apply appropriate > front and back textures to each of the rectangles or, as the vertex > count would be the same as for two rectangles, you could actually > consider using a cube for the board. That's what I did (an extruded plane, actually). I would like to have double-sided ones available; but there are 16000 foot commercial runways out there, and suddenly you're looking at needing (15*14)/2 signs, minus a few that would never happen (e.g. "1" on one side, "1" on the other). It's only one mesh model, of course; but assigning textures, uvmapping, and writing the file, over and over again, to get a kajillion files, gets really boring. Although wait a second . . .provided the black edges are uvmapped to a portion of the texture that's definitely not written with a numeral in any of the texture files, it's probably OK to create additional ones by doing nothing more than replacing the texture file names with a script. Maybe I'll try that tonight. -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 pgpfQwEz4exZF.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Two scenery design issues.
On Tue, 10 Aug 2004 11:14:56 +0200 Erik Hofman <[EMAIL PROTECTED]> wrote: > >> 1. When I first tried to make these guys, I applied a black material >> to the entire sign; then, I took the appropriate >> white-numeral-on-black texture and UV-mapped it to one face, rotated >> so that it looks correct from Blender's "front" view. Everything >> looked great in Blender, both in the 3D windows (with "textured view" >> on), and in the rendering window. Once exported to ac3d and brought >> into fgfs, though, what I got was a black square. After lots of >> tinkering around with the shading numbers for the material by editing >> the .ac file directly, I found that the only way I could get the >> numeral to show was by assigning emissivity to the material. Does >> this make sense to you? It sure doesn't to me. > > Yo have to apply a _white_ (or nearly white) material to the object > because that color is the maximum color applied to an object (including > the texture). Once upon a time, I knew this. Thanks. That's what I'd ended up doing (or had to do) when I went ahead and textured all the faces. -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 pgpP2zaMeZzEu.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Two scenery design issues.
Erik Hofman wrote: > Vivian Meazza wrote: > > > AC3D seems to add the material colour to the texture > > No, it's OpenGL that does this. With everything related to modeling you > have to take into account the possibilities and requirements of OpenGL, > and not that of your 3d modeler program. To be exact, it is PLIB that sets the texture environment to GL_MODULATE. It has the effect of ***multiplying*** the material color with the texture colors. So, if you set a black color (0,0,0), it would stay black because 0 * X = 0. If you want your texture unmodified by the material color, set it to white (1,1,1). The only way to have a emissive effect on an object is to set an emissive material color ( for example white ) and modulate it with the texture : black in the texture -> black on object, yellow in the texture -> emissive yellow on the object. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
