[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] bo105 + patch
On Monday 09 August 2004 17:12, Martin Spott wrote: Gunnstein Lye wrote: How? If pulling the collective up makes the heli go up, then I would expect the keyboard to behave in the same way: press up/pageup to go up. (If he meant mouse up, then I might agree) When you control the collective pitch of a heli flight sim you usually don't look on what's written on the keys - at least _I_ don't ;-)) To my sense the two keys substitute a little stick that has a flexible mounting between them. When you pull the stick, the PgDown key gets pressed down by the stick due to the flexible mounting. Then you could adapt the action of pulling the lever from the real heli, Martin. That is if the imaginary stick extends away from you (over the Pause/Break button on a normal keyboard). If it extends towards you the effect is the opposite. Anyway, for a user who has never seen the inside of a helicopter cockpit, this just means inverting the meaning of up and down, which surely must be confusing. -- best regards, Gunnstein Lye Systems engineer [EMAIL PROTECTED] | eZ systems | ez.no ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Newbee
On Monday 09 August 2004 03:35, Jim Wilson wrote: What O.S.? For this use any OS you want. A lot of folks using Linux, most any distro will do. Mandrake is actually fine, gentoo might require a bit more experience (or at least patience) to get started. For a linux beginner I would recommend suse (my favourite), mandrake or fedora/redhat. AFAIK, they have the best hardware support and the easiest installation. (Debian is great for gurus, not so great for beginners.) -- best regards, Gunnstein Lye Systems engineer [EMAIL PROTECTED] | eZ systems | ez.no ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: bo104 - patch
On Monday 09 August 2004 17:13, Melchior FRANZ wrote: * Gunnstein Lye -- Monday 09 August 2004 16:35: Seriously though, it seems the problem here is that most, but not all, find it logical to map the up/down behaviour of a collective to the backward/forward motion of a joystick (or joystick throttle). There is no right or wrong here, as there is no logical way to translate Y-axis movement to the Z-axis. Yes, there is: pull - raise, push - sink. It doesn't matter how the joystick is mounted. This is the right and realistic way. The other may be consistent with fixed wing and newbie friendly, but fgfs' goal is realism. It's not a game, but a simulator after all. I'm tending more and more to revert today's patch. Okay, for joystick throttles I agree with you. (Although personally I would go for the second joystick option.) For buttons, on the other hand, I think up should mean up. Solution: make the default whatever most people agree on, but make it easy to invert, as in X-Plane where you have an invert button next to each joystick axis. That was my first solution, but the patch was rejected (please not yet another property). I inverted the collective axis in the YASim config then. Too bad. -- best regards, Gunnstein Lye Systems engineer [EMAIL PROTECTED] | eZ systems | ez.no ___ 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
[Flightgear-devel] Re: bo104 - patch
* Gunnstein Lye -- Tuesday 10 August 2004 10:18: On Monday 09 August 2004 17:13, Melchior FRANZ wrote: pull - raise, push - sink. It doesn't matter how the joystick is mounted. This is the right and realistic way. The other may be consistent with fixed wing and newbie friendly, but fgfs' goal is realism. It's not a game, but a simulator after all. Okay, for joystick throttles I agree with you. (Although personally I would go for the second joystick option.) A second joystick would be nice, or even one that looks and feels like a real helicopter collective, with throttle twist grip etc. But the lever on my Saitek Cyborg 3D Gold is quite OK. I'm glad I don't have to use a Micros~1 joystick with horizontally mounted throttle wheel. I'm not sure if a reversed throttle collective is intuitive there. For buttons, on the other hand, I think up should mean up. Too late. I asked Erik already to revert that part of the last patch. The rest will remain, especially the initialization to least pitch angle for keyboard pilots. The next time the collective discussion breaks loose, it should be about a property ... That was my first solution, but the patch was rejected (please not yet another property). I inverted the collective axis in the YASim config then. Too bad. Maybe we'll get some more user feedback. The release of the ec130 may motivate more people to fly helicopters. In the end a property might be necessary. Now, if only we had someone to finish YASim's missing helicopter FDM parts, and fix the bugs. Hey, or what about a JSBSim helicopter? :-) m. PS: there never was a bo104, btw ( AFAIK). But it's worth to mention the other Boelkow helictopters: http://www.helis.com/50s/h_bo1023.php, http://www.hubschraubermuseum.de/Hubschraubermuseum_Buckeburg/Archiv/Bolkow_Entwicklungen_KG/Bolkow_BO_46/bo-46_01.JPG, http://www.246.ne.jp/~heli-ss/Bo108.jpg ___ 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
[Flightgear-devel] ALERT: Losing the DAFIF
This message just came to one of the aviation newsgroups from Paul Tomblin, who maintains several free GPS/flight-planning databases. It looks like we'll be losing the DAFIF soon, which is our source for most airports outside the U.S., as well as for ATC frequencies, airways, arrival procedures, etc. This is extremely bad news -- of course, we can keep using the final edition of the DAFIF (whenever that is) for a while, but it will get further and further out of date. All the best, David -- All the best, David -- Majority rule only works if you're also considering individual rights. Because you can't have five wolves and one sheep voting on what to have for supper. --Larry Flynt ---BeginMessage--- In a previous article, [EMAIL PROTECTED] (Paul Tomblin) said: I've been hearing nasty rumours that the DAFIF file will no longer be available on the net for free download, and the CD won't be available to non-government users. Here is an email I got from Jerry Leicht, the DAFIF Program Manager: :From: Leicht, John J. [EMAIL PROTECTED] :To: 'Paul Tomblin' [EMAIL PROTECTED] :Subject: RE: DAFIF data :Paul, : : Thank you for sending in your question about DAFIF and whether it'll :be available any longer. Here's what I know. There is an initiative to :remove DAFIF from the www and from public sale. The issue is not set in :stone, but is being entered into the federal register for comments and :complaints. There is still some talk about having a US only DAFIF, but for :now that's just talk. : This initiative began because the Australian AIP producers are suing :Jeppesen for copyright infringement. I don't know any of the details :involved, but in order to prevent a similar situation, we are researching :contingencies like this. : :Jerry Leicht :DAFIF Program Manager :National Geospatial-Intelligence Agency (NGA) :Comm: 314-263-4636 :DSN: 693-4636 :Pager and Voicemail: 877-523-0130 :[EMAIL PROTECTED] -- Paul Tomblin [EMAIL PROTECTED] http://xcski.com/blogs/pt/ D: is just a data disk. That's why it's called D, for DATA. C: is the Windows OS disk, so it's called C, for CRAP. -- David P. Murphy ---End Message--- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ALERT: Losing the DAFIF
On Tue, 10 Aug 2004 11:20:28 -0400 David Megginson [EMAIL PROTECTED] wrote: This message just came to one of the aviation newsgroups from Paul Tomblin, who maintains several free GPS/flight-planning databases. It looks like we'll be losing the DAFIF soon, which is our source for most airports outside the U.S., as well as for ATC frequencies, airways, arrival procedures, etc. This is extremely bad news -- of course, we can keep using the final edition of the DAFIF (whenever that is) for a while, but it will get further and further out of date. Is there an official announcement of this somewhere? I've looked all around the NGA and NACO sites but haven't found anything. How did he hear about this? Is there any kind of timetable? Were there reasons stated? -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 pgpW93Y455KfL.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ALERT: Losing the DAFIF
Chris Metzler wrote: Is there an official announcement of this somewhere? I've looked all around the NGA and NACO sites but haven't found anything. How did he hear about this? Is there any kind of timetable? Were there reasons stated? According to the message I quoted, the Australian government is suing Jeppesen for publishing information obtained from Australian aviation publications. That's bad news not only for the flying community but for the flight sim community as well -- it sounds like they're claiming copyright not only on their publications but on the information itself (i.e. the location of runways or VORs). All the best, David ___ 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] ALERT: Losing the DAFIF
On Tue, 10 Aug 2004 15:19:15 -0400 David Megginson [EMAIL PROTECTED] wrote: Chris Metzler wrote: Is there an official announcement of this somewhere? I've looked all around the NGA and NACO sites but haven't found anything. How did he hear about this? Is there any kind of timetable? Were there reasons stated? According to the message I quoted, [ snip ] Duh! on my part. My message view window is sized such that your All the best came at the bottom of the viewport. So I figured the message ended there; I didn't even see all the stuff quoted underneath. Duh. Sorry about that. -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 pgpfAJR1WsKlx.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ALERT: Losing the DAFIF
On Tuesday 10 August 2004 20:19, David Megginson wrote: Chris Metzler wrote: Is there an official announcement of this somewhere? I've looked all around the NGA and NACO sites but haven't found anything. How did he hear about this? Is there any kind of timetable? Were there reasons stated? According to the message I quoted, the Australian government is suing Jeppesen for publishing information obtained from Australian aviation publications. That's bad news not only for the flying community but for the flight sim community as well -- it sounds like they're claiming copyright not only on their publications but on the information itself (i.e. the location of runways or VORs). All the best, David I'm pretty sure that information/data can't be copyrighted - but the design of the presentation of the information/data can. For example, it wouldn't be possible to copyright a word so that no-one could say it or write down but it might be possible to copyright a specific entry for that word in a dictionary - other dictionaries might then need to re-word their entries. Another example is with maps - you can obtain data from a map and publish that data - so you could say that the elevation at lat-lon is n ft - but you couldn't re-publish the map that you got that info from itself. Certainly, if someone produces or originates data in someway, they have a right to decide if they want to keep it secret or not, and if they do want to keep it secret they can choose to sell that data with whatever restrictions the buyer will accept (If someone just measures something and publishes it they can't stop anyone else from measuring it and also publishing it) Is this what the Australian Govt. want though - to charge every flyer for the info they need to land? Hmm... on second thoughts, considering the twisted control freaks that seem to be running the world atm, perhaps it isn't too far from the truth. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ALERT: Losing the DAFIF
On Tue, 10 Aug 2004 20:58:15 +0100 Lee Elliott [EMAIL PROTECTED] wrote: I'm pretty sure that information/data can't be copyrighted - but the design of the presentation of the information/data can. You'd think so, wouldn't you? And traditionally, that's been the opinion of U.S. courts -- that to be covered by copyright, the work must pass an originality standard, and the collection of facts itself can't pass that standard. Unfortunately, in the U.S. anyway, many corporations still file lawsuits against smaller companies and organizations over this, figuring that the smaller party will find it easier to knuckle under than to defend themselves in court, even if they'll be successful. And then, on top of this, there's H.R. 3261, to be considered by the full House of Representatives when they return. The Database and Collections of Information Misappropriation Act would extend copyright protections to such collections of facts. http://news.com.com/2100-1028_3-5145040.html Anyway, since removing the DAFIF is being entered into the Federal Register for comment, and since it's still the case in the U.S. that collections of facts aren't illegal (and thus, such removal seems very premature), maybe it's a good idea to take an evening to write such a comment. -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 pgpZLUClgkuUx.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] ALERT: Losing the DAFIF
Lee Elliott wrote: I'm pretty sure that information/data can't be copyrighted - but the design of the presentation of the information/data can. I hope not, but every country has its own (bizarre) laws about this kind of thing -- for example, in Commonwealth countries, including Canada and Australia, the Book of Common Prayer has a perpetual copyright in the name of the Queen. Jeppesen does draw its own approach plates, updated based on the information in the Australian AIP (I'd assume), so it really looks like a data grab from the little I've seen so far. Before I bash Oz any more, I'll repeat the problem that Garmin had with my own government recently. The Garmin 296 handheld GPS includes terrain obstructions (such as towers), which could save of lives; however, the Canadian government refused to provide obstruction information for Canada unless they got a royalty for each unit sold -- as a result, Canadian pilots do not see towers displayed on their Garmin 296 units, and at least a few will likely crash in the next few years as a result, costing the Canadian government millions in search and rescue, medical bills, lost taxes, etc. etc. D'oh! All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] A method for getting funds...
Ever thought of selling art works that are used in FlightGear at very low price? http://www.turbosquid.com/ Regards, Ampere ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ALERT: Losing the DAFIF
On Tue, 10 Aug 2004 18:01:38 -0400, David wrote in message [EMAIL PROTECTED]: Lee Elliott wrote: I'm pretty sure that information/data can't be copyrighted - but the design of the presentation of the information/data can. I hope not, but every country has its own (bizarre) laws about this kind of thing -- for example, in Commonwealth countries, including Canada and Australia, the Book of Common Prayer has a perpetual copyright in the name of the Queen. Jeppesen does draw its own approach plates, updated based on the information in the Australian AIP (I'd assume), so it really looks like a data grab from the little I've seen so far. Before I bash Oz any more, I'll repeat the problem that Garmin had with my own government recently. The Garmin 296 handheld GPS includes terrain obstructions (such as towers), which could save of lives; however, the Canadian government refused to provide obstruction information for Canada unless they got a royalty for each unit sold -- as a result, Canadian pilots do not see towers displayed on their Garmin 296 units, and at least a few will likely crash in the next few years as a result, costing the Canadian government millions in search and rescue, medical bills, lost taxes, etc. etc. ..so, in Canada, copyright is more important than lives. This has been in the media? They usually love to roast governments over stuff like this. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ALERT: Losing the DAFIF
Arnt Karlsen wrote: ..so, in Canada, copyright is more important than lives. This has been in the media? They usually love to roast governments over stuff like this. ;-) COPA's done its best, but the issue is not going anywhere. On the bright side, while the copyright law in Canada does not help us avoid flying into towers, it does allow Canadians to download and share movies and music legally, unlike most of the rest of the world (that's because of a greedy cash grab by the entertainment industry a few years ago that has backfired on them spectacularly). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
