Re: [Flightgear-devel] Blender Status
On 13 Nov 2002 18:17:58 -0800, Tony Peden [EMAIL PROTECTED] wrote in message 1037240278.6275.4.camel@raptor: On Wed, 2002-11-13 at 18:05, Arnt Karlsen wrote: or hook up a plane, balloon, submarine or a wind tunnel to it Real time CFD is a pipe dream. Period. ..they are all approximations. ;-) -- ..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
Re: [Flightgear-devel] Blender Status
On Thu, 14 Nov 2002 02:36:12 -,
Jim Wilson [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]:
Right now we've got a lot of great starts for 3D Models, and now
excellent support in the program for instrumenting and animating them.
My focus (especially since I don't have the time to dive into
programming now) is on fixing up 3D models. Making them better
looking and more complete. We really need more people modeling,
which is where this thread started isn't it? :-)
..to get the _cool_ ones, especially after Michaels Red Baron TV show,
we might want to set up guidelines for say, the EAA membership on how to
add their aircraft to FG. ('http://eea.org/') Some will work from
built, photographed and flight tested aircraft, some off raw sketches
and anywhere in between. I like these to talk with all fdm's.
--
..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
Re: [Flightgear-devel] Blender Status
Arnt Karlsen [EMAIL PROTECTED] said:
we might want to set up guidelines for say, the EAA membership on how to
add their aircraft to FG. ('http://eea.org/') Some will work from
Think you meant http://eaa.org
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
On Thu, 14 Nov 2002 18:10:59 -,
Jim Wilson [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]:
Arnt Karlsen [EMAIL PROTECTED] said:
we might want to set up guidelines for say, the EAA membership on
how to add their aircraft to FG. ('http://eea.org/') Some will
work from
Think you meant http://eaa.org
..no different in _modern_ email clients. ;-)
--
..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
Re: [Flightgear-devel] Blender Status
Arnt Karlsen [EMAIL PROTECTED] said:
On Thu, 14 Nov 2002 18:10:59 -,
Jim Wilson [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]:
Arnt Karlsen [EMAIL PROTECTED] said:
we might want to set up guidelines for say, the EAA membership on
how to add their aircraft to FG. ('http://eea.org/') Some will
work from
Think you meant http://eaa.org
..no different in _modern_ email clients. ;-)
Maybe I don't get it? :-) Note the second letter in the domain name. This
wasn't a syntax, issue the address you entered points to Edmonton Executives
Association.
After looking over the page I thought it might be nice to join, but it's a
hell of a commute for the meetings and currently I'm not interested in
expanding business in Alberta right now anyway. ;-)
Best,
Jim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
On Thu, 14 Nov 2002 20:34:34 -,
Jim Wilson [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]:
Arnt Karlsen [EMAIL PROTECTED] said:
On Thu, 14 Nov 2002 18:10:59 -,
Jim Wilson [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]:
Arnt Karlsen [EMAIL PROTECTED] said:
we might want to set up guidelines for say, the EAA membership
on how to add their aircraft to FG. ('http://eea.org/') Some
will work from
Think you meant http://eaa.org
..no different in _modern_ email clients. ;-)
Maybe I don't get it? :-) Note the second letter in the domain name.
This wasn't a syntax, issue the address you entered points to
Edmonton Executives Association.
After looking over the page I thought it might be nice to join, but
it's a hell of a commute for the meetings and currently I'm not
interested in expanding business in Alberta right now anyway. ;-)
..tock-tock-tock/ note to self: *read* what you write. ;-)
--
..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
Re: [Flightgear-devel] Blender Status
Jim Wilson wrote: Michael Selig [EMAIL PROTECTED] said: If space becomes an issue, I think there are bigger fish to fry, like the SkyClouds dir(?). That does seem large for what it is. Almost all of the size is in three files: field37.cld, field56.cld, and valley.cld. The names seem to indicate scenery, not cloud data? It might be a good thing for everybody to dicide if we want to keeo the Textures.high/Runway directory. For what I've seen there is little need for it anymore and it saves another 11 Mb. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
Michael Selig writes: * So if the top ten were optional, that would save about 15MB from the base package and 10 interesting aircraft would be downloaded separately. Is that worth it? I think so, especially if we can trim down other parts (like the cloud textures) as well. What happens when we have 100, or 1000 aircraft? Are we going to keep putting them all in the base package? On the other hand, let's assume that we were willing to keep the base package at 100MB -- it might be a fair tradeoff to remove some default aircraft and add more default scenery. Most flight sims come with few planes but at least low-grade world-wide scenery by default; we give only a tiny square around KSFO, which a fast plane like the 747 or A4 will use up in minutes. We can also save some space for individual aircraft by looking at textures. Aircraft converted from MSFS are sometimes texture pigs, and a little scaling down might not hurt. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
Jim Wilson writes: I'm already concerned about the base-package size. We need to start thinking seriously about making most aircraft optional add-ons. It's easy for me with a fast cable modem, but I don't want to scare away regular users. If the DC-3 (for example) was its own, separately downloadable package, then I'd have no problem including the Blender and XCF sources with it. What are the options as far as CVS? I can see splitting up the base package release, either into individual aircraft perhaps a few groups of aircraft. But it seems a little trickier with CVS and the current directory structure. One option is to put an aircraft completely into its own subdirectory, and then put the *-set.xml file inside there. So, instead of Aircraft/c172p-set.xml we'd have Aircraft/c172p/set.xml That's an easy code change. The hard part is managing panels, 3D models, and aero models, since there's not a 1:1:1 relationship among these. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
Erik Hofman writes: It might be a good thing for everybody to dicide if we want to keeo the Textures.high/Runway directory. For what I've seen there is little need for it anymore and it saves another 11 Mb. I don't understand this one ... unless something has changed the high res runway textures make a huge difference for those people that can use them. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
Curtis L. Olson wrote: Erik Hofman writes: It might be a good thing for everybody to dicide if we want to keeo the Textures.high/Runway directory. For what I've seen there is little need for it anymore and it saves another 11 Mb. I don't understand this one ... unless something has changed the high res runway textures make a huge difference for those people that can use them. That was what I was thinking until I designed the new textures and removed that directory to check them Might be worth a try. I'll be happy to leave them in if anybody thinks it *is* worth it though. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
JD Fenech writes: Major note: I've been trying to follow FG development for somewhat over a year, and still haven't been able to really figure out how FDMs are handled (are they internal to the software, or are they externally loaded). The FDMs are the aerodynamic engines (special-use physics engines). Unlike most simulators, FlightGear contains several different aerodynamic engines: JSBSim (the default), YASim, LaRCsim, UIUC (based on LaRCsim), and a few other special-use ones. The three major FDMs are runtime-configurable using external files so that they can simulate the physics of many different aircraft types: - JSBSim uses XML files scattered throughout $FG_ROOT/Aircraft/ - YASim uses XML files stored under $FG_ROOT/Aircraft-yasim/ - UIUC uses INI-like files stored under $FG_ROOT/Aircraft-uiuc/ Before you say anything, yes, I agree that this is wrong. We either want something like $FG_ROOT/Aircraft/fdms/jsbsim/c172r.xml $FG_ROOT/Aircraft/fdms/yasim/c172r.xml $FG_ROOT/Aircraft/fdms/uiuc/c172r.dat or something like $FG_ROOT/Aircraft/c172r/aero/jsbsim.xml $FG_ROOT/Aircraft/c172r/aero/yasim.xml $FG_ROOT/Aircraft/c172r/aero/uiuc.xml depending on whether we want to group the aero files together with others using the same FDM or together with others for the same aircraft type. We could even replace 'aero' with 'physics' to make it clear to new users what's going on, since physics engines are starting to be heavily used in the 3D gaming world. The modern definition of 'racist' is someone who is winning an argument with a liberal. --Peter Brimelow What's the modern definition of 'liberal'? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
Jim Wilson writes: We certainly need to decide on which ones to include. It would seem that 10 or so aircraft and a total base package size of 50mb compressed (150-200mb uncompressed) would be reasonable. For CVS users having the models in a separate tree so they can be download selectively makes sense. BTW the AC3D files, compress 90% or more. Agreed. In fact, I think that we should package *all* of the models individually but then preinstall a few of them in the base package, just as we do with the scenery. So how does this look? Aircraft/type/config.xml Aircraft/type/info.xml Aircraft/type/picture.jpg Aircraft/type/Documentation/ Aircraft/type/Model/ Aircraft/type/Panel/ Aircraft/type/Physics/ Aircraft/type/Sound/ Aircraft/type/Systems/ config.xml would include properties to be placed in the main property tree, while info.xml would contain properties exclusively for sorting and selecting aircraft (such as a description, manufacturer, etc.), and an optional reference to an image (like 'picture.jpg') that could be displayed in a selection box. Documentation/ would contain human-readable documentation, Model/ would contain the 3D model including animations, Panel/ would include a 2D panel (if appropriate), Physics/ would include all of the aero files for different FDMs, Sound/ would include sound samples for the aircraft and the sound config file, and Systems/ would include special config files for systems like the electrical system, autopilot, or FMS. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
Are the textures in each directory different resolutions? I'm not at a machine where I can check right now ... Maybe your machine is always picking up the low res textures??? Curt. Erik Hofman writes: Curtis L. Olson wrote: Erik Hofman writes: It might be a good thing for everybody to dicide if we want to keeo the Textures.high/Runway directory. For what I've seen there is little need for it anymore and it saves another 11 Mb. I don't understand this one ... unless something has changed the high res runway textures make a huge difference for those people that can use them. That was what I was thinking until I designed the new textures and removed that directory to check them Might be worth a try. I'll be happy to leave them in if anybody thinks it *is* worth it though. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
David, One additional thing that would be very nice to support is the ability to have at least one additional directory level for grouping aircraft: Aircraft - Small-Single-Engine - WWII - WWI - Modern-Jet-Fighters - Commercial-Jets - Bi-Planes - Sea-Planes - R/C Planes - etc. And then have the individual aircraft directory inside of the group directory. Otherwise it's going to be a big mess (like it is now) when you start having more than 10-20 aircraft. This also makes finding a particular aircraft more convenient becuase you don't have to traverse obscenly large lists. Regards, Curt. David Megginson writes: Jim Wilson writes: We certainly need to decide on which ones to include. It would seem that 10 or so aircraft and a total base package size of 50mb compressed (150-200mb uncompressed) would be reasonable. For CVS users having the models in a separate tree so they can be download selectively makes sense. BTW the AC3D files, compress 90% or more. Agreed. In fact, I think that we should package *all* of the models individually but then preinstall a few of them in the base package, just as we do with the scenery. So how does this look? Aircraft/type/config.xml Aircraft/type/info.xml Aircraft/type/picture.jpg Aircraft/type/Documentation/ Aircraft/type/Model/ Aircraft/type/Panel/ Aircraft/type/Physics/ Aircraft/type/Sound/ Aircraft/type/Systems/ config.xml would include properties to be placed in the main property tree, while info.xml would contain properties exclusively for sorting and selecting aircraft (such as a description, manufacturer, etc.), and an optional reference to an image (like 'picture.jpg') that could be displayed in a selection box. Documentation/ would contain human-readable documentation, Model/ would contain the 3D model including animations, Panel/ would include a 2D panel (if appropriate), Physics/ would include all of the aero files for different FDMs, Sound/ would include sound samples for the aircraft and the sound config file, and Systems/ would include special config files for systems like the electrical system, autopilot, or FMS. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
Curtis L. Olson wrote: David, One additional thing that would be very nice to support is the ability to have at least one additional directory level for grouping aircraft: Aircraft - Small-Single-Engine - WWII - WWI - Modern-Jet-Fighters - Commercial-Jets - Bi-Planes - Sea-Planes - R/C Planes - etc. And then have the individual aircraft directory inside of the group directory. Otherwise it's going to be a big mess (like it is now) when you start having more than 10-20 aircraft. This also makes finding a particular aircraft more convenient becuase you don't have to traverse obscenly large lists. This could also be done by including a type tag inside the file. I agree this doesn't change the directory layout like you propose, but it could be used by the menu system. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
Curtis L. Olson wrote: Are the textures in each directory different resolutions? I'm not at a machine where I can check right now ... Yes: Textures/Runway -- 256 pixels Textures.high/Runway -- 512 pixels Maybe your machine is always picking up the low res textures??? No, I've checked that. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
Norman Vine writes: Having a 'aircraft type' index into the aircraft database is a good idea but I think that it should probably be just that an index otherwise you end up needing multiple copies of the actual data. ie where would you put a WWII sea-plane fighter in the heirarchy ?? Indices can be easily built using the XML construct $TAG include=$PATH / A type tag or multiple type tags would certainly be nice. The aircraft selector gui could use that to put the aircraft several appropriate places in the menu structure. But I would also like the ability to organize the aircraft in subdirectories, just for sanity. Once the aircraft builders and painters really get cranking we are going to have hundreds if not thousands of aircraft and variations of aircraft. There's no way we want to have these in a single flat directory structure. I don't think we want to necessarily impose a standard directory structure either, although it makes sense to suggest one in the base package. Perhaps the tools / code that locate aircraft should be smart enough to scan the Aircraft directory tree. Plib provides directory scanning functions now. The gui aircraft selection menus could be built dynamically based on what the code discovers in the Aircraft directory ... maybe organized based on tags or directory layout or both. For instance ... (layout is off the top of my head and for the purposes of this example only, I'm not proposing this as the actual layout ...) Choose Aircraft - Small - low wing - faster - slower - high wing - Big - commercial - military - Jet - Piston -- - By Directory Layout - Airbus - Boeing - Sea Planes - Fighters - WWI - WWII - Korea - Vietnam - Modern - etc. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
Erik Hofman writes: Curtis L. Olson wrote: Are the textures in each directory different resolutions? I'm not at a machine where I can check right now ... Yes: Textures/Runway -- 256 pixels Textures.high/Runway -- 512 pixels Eric, Compare the following two images side by side: http://www.flightgear.org/tmp/runway-lo.png http://www.flightgear.org/tmp/runway-hi.png Especially look at the diagnal part of the numeral 2 and the notches cut out of the sides of the 8. Also notice the additional fuzziness at the tops and bottoms of the numbers in the lo res version. And, overall, the hi image is much sharper. You may not notice this as much when you are looking at the runway from the ground, but you will definitely notice it from the air, and will definitley notice the difference in all circumstances if you have a high level of anisotropic texture filtering turned on (for GeForce3/4 cards.) This makes the runway markings beautifully sharp and virtually eliminates all the mipmap bluriness we see on lower end cards. I would be *very* disappointed if the hi res version of the runway textures went away. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
Curtis L. Olson wrote: I would be *very* disappointed if the hi res version of the runway textures went away. Allright, If you think lowres is not good enough, we can keep them. I was just trying to remove 11 Mb from the base package and thought the lowres version would be good enough. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
Norman Vine writes: It's hard to argue against 'sanity' :-) And hard to argue against coupons. Although if it came down to either/or, I think a coupon would trump sanity. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
Erik Hofman writes: Curtis L. Olson wrote: I would be *very* disappointed if the hi res version of the runway textures went away. Allright, If you think lowres is not good enough, we can keep them. I was just trying to remove 11 Mb from the base package and thought the lowres version would be good enough. My view is that this is the first thing a person sees when they first start up flightgear (that along with the instrument panel.) I think it's worth making these two items as nice as possible because in large part (and right or wrong) that is how FlightGear will be judged. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
On Wed, 13 Nov 2002 09:39:05 -0500, David Megginson [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: JD Fenech writes: Major note: I've been trying to follow FG development for somewhat over a year, and still haven't been able to really figure out how FDMs are handled (are they internal to the software, or are they externally loaded). The FDMs are the aerodynamic engines (special-use physics engines). Unlike most simulators, FlightGear contains several different aerodynamic engines: JSBSim (the default), YASim, LaRCsim, UIUC (based on LaRCsim), and a few other special-use ones. The three major FDMs are runtime-configurable using external files so that they can simulate the physics of many different aircraft types: - JSBSim uses XML files scattered throughout $FG_ROOT/Aircraft/ - YASim uses XML files stored under $FG_ROOT/Aircraft-yasim/ - UIUC uses INI-like files stored under $FG_ROOT/Aircraft-uiuc/ Before you say anything, yes, I agree that this is wrong. We either want something like $FG_ROOT/Aircraft/fdms/jsbsim/c172r.xml $FG_ROOT/Aircraft/fdms/yasim/c172r.xml $FG_ROOT/Aircraft/fdms/uiuc/c172r.dat or something like $FG_ROOT/Aircraft/c172r/aero/jsbsim.xml $FG_ROOT/Aircraft/c172r/aero/yasim.xml $FG_ROOT/Aircraft/c172r/aero/uiuc.xml ..I like a birds view building block approach: JSBSim can be run as an external fdm to FG. How about making this the standard approach? Engine models imho should be called externally again, from the fdms. All of this is built on top of zlib, plib, SimGear etc. Modules. With clear interfaces. ..some of us like hot OpenGL graphics and neat sceneries to plan and tweak our next air show. At other times, we analyse and tweak an airframe or an engine, and then we prefer to burn our cpu cycles in the fdm and engine models and can live with slow vesa-type graphics. depending on whether we want to group the aero files together with others using the same FDM or together with others for the same aircraft type. We could even replace 'aero' with 'physics' to make it clear to new users what's going on, since physics engines are starting to be heavily used in the 3D gaming world. The modern definition of 'racist' is someone who is winning an argument with a liberal. --Peter Brimelow What's the modern definition of 'liberal'? ..someone who feels Saddam deserves yet another chance. ;-) -- ..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
Re: [Flightgear-devel] Blender Status
Curtis L. Olson writes: One additional thing that would be very nice to support is the ability to have at least one additional directory level for grouping aircraft: Aircraft - Small-Single-Engine - WWII - WWI - Modern-Jet-Fighters - Commercial-Jets - Bi-Planes - Sea-Planes - R/C Planes - etc. And then have the individual aircraft directory inside of the group directory. Otherwise it's going to be a big mess (like it is now) when you start having more than 10-20 aircraft. This also makes finding a particular aircraft more convenient becuase you don't have to traverse obscenly large lists. I don't know. Most users won't install more than 20 or 30 aircraft (if my MSFS experience is anything to go by), and there are many different ways to classify aircraft. I prefer an info.xml file in each directory with all the classifications, so that we can eventually list all Cessna aircraft, all single-engine aircraft, all piston-engine aircraft, all aircraft with a gross weight under 12,500lb, and so on. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
On Wed, Nov 13, 2002 at 01:01:39PM -0500, David Megginson wrote: Curtis L. Olson writes: One additional thing that would be very nice to support is the ability to have at least one additional directory level for grouping aircraft: Aircraft - Small-Single-Engine - WWII - WWI - Modern-Jet-Fighters - Commercial-Jets - Bi-Planes - Sea-Planes - R/C Planes - etc. And then have the individual aircraft directory inside of the group directory. Otherwise it's going to be a big mess (like it is now) when you start having more than 10-20 aircraft. This also makes finding a particular aircraft more convenient becuase you don't have to traverse obscenly large lists. I don't know. Most users won't install more than 20 or 30 aircraft (if my MSFS experience is anything to go by), and there are many different ways to classify aircraft. I prefer an info.xml file in each directory with all the classifications, so that we can eventually list all Cessna aircraft, all single-engine aircraft, all piston-engine aircraft, all aircraft with a gross weight under 12,500lb, and so on. Possibly if we divided the aircraft up by the class of license that would be needed to fly them? Given we're trying for a high degree of realism, that could easily be the most useful approach, and certainly it'd be one that people might want as an option . . . Simon -- PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc (crappy) Homepage: http://himi.org doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://himi.org/pub/mirrors/css/ msg09743/pgp0.pgp Description: PGP signature
Re: [Flightgear-devel] Blender Status
On Wednesday, November 13, 2002, at 07:16 pm, Gene Buckle wrote: Wouldn't it just be easier to allow the user to configure how they'd like the aircraft lists presented? The model file can indicate aircraft details such as licence requirements, operation category, etc. The user could then configure via a global option of some kind as to how they want the available aircraft sorted and listed. Agreed whole-heartedly I think storing each aircrafts' data in a tar file was mentioned earlier. Why not use the infozip libs (gpl'd I think) to create .FGAR (FlightGearARchive) files that would hold the model configuration and any associated textures in a compressed format. It would keep things simple for the end-user and any fancy editing tools could be built to crack open the archive easily enough. The software should be smart enough (based on data in the config portion of the model definition) so that directories breaking down aircraft by FDM wouldn't really be required any longer. Basically I have been planning to suggest the same thing : Mozilla uses .jar files for this purpose, and it works really (really) well. Managing different packages / installing aircraft for FS2k(2) / Fly! is an exercise in tedium and hassle getting paths correct, copying panel files, etc, etc. A simple package format (hence something zip / tar.gz based) with good meta-data for type and versioning will be a huge, huge benefit as the number and kind of add-ons grows. And FG already uses Zlib, so adding jar support wouldn't even require another library dependency. Crystal space again uses .zips for this purpose, with a VFS layer that can 'mount' zip archives into the data file-tree, and again it's very simply to author for and works well. Dependency tracking would be a huge benefit here (common instruments / models / sounds / whatever) if it can be done simply and effectively. And of course if the system can be coupled to wget / curl, it will just rule :-) Though that's getting a bit carried away. Good ideas or should I go back under my rock? :) Excellent ideas :-) HH James -- Whenever a friend succeeds, a little something in me dies. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
David Megginson [EMAIL PROTECTED] said: Erik Hofman writes: Allright, If you think lowres is not good enough, we can keep them. I was just trying to remove 11 Mb from the base package and thought the lowres version would be good enough. Perhaps the high-res could be an optional add-on. That wouldn't be good I don't think. They seem to be used by default. And are worth it. Gzipped we'd be looking at about 5.5mb. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
And FG already uses Zlib, so adding jar support wouldn't even require another library dependency. Is Zlib zip or bzip2 based? Or is it just the InfoZip lib and I didn't know? :) Crystal space again uses .zips for this purpose, with a VFS layer that can 'mount' zip archives into the data file-tree, and again it's very simply to author for and works well. That's an interesting idea - if Crystal Space is GPL, the code for that could be easily snipped out and installed over here. :) Dependency tracking would be a huge benefit here (common instruments / models / sounds / whatever) if it can be done simply and effectively. And of course if the system can be coupled to wget / curl, it will just rule :-) Though that's getting a bit carried away. But only a bit. :) g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
At 11/13/02, you wrote: JD Fenech writes: Major note: I've been trying to follow FG development for somewhat over a year, and still haven't been able to really figure out how FDMs are handled (are they internal to the software, or are they externally loaded). The FDMs are the aerodynamic engines (special-use physics engines). Unlike most simulators, FlightGear contains several different aerodynamic engines: JSBSim (the default), YASim, LaRCsim, UIUC (based on LaRCsim), and a few other special-use ones. The three major FDMs are runtime-configurable using external files so that they can simulate the physics of many different aircraft types: - JSBSim uses XML files scattered throughout $FG_ROOT/Aircraft/ - YASim uses XML files stored under $FG_ROOT/Aircraft-yasim/ - UIUC uses INI-like files stored under $FG_ROOT/Aircraft-uiuc/ The Aircraft-uiuc dir is for the most part obsolete, but the files still run (the code is backward compatible). The $FG_ROOT/Aircraft/UIUC supercedes it. Before you say anything, yes, I agree that this is wrong. We either want something like $FG_ROOT/Aircraft/fdms/jsbsim/c172r.xml $FG_ROOT/Aircraft/fdms/yasim/c172r.xml $FG_ROOT/Aircraft/fdms/uiuc/c172r.dat - I like this approach (fdm/type named dirs vs aircraft/aero below). There's a lot more than just aero in the aircraft files: inits + aero + gear + engine + flag setting, etc. Also, I think from a developer standpoint, it's best to start w/ the fdm-type/aircraft-name rather than aircraft-name/fdm-type. - Note that once in the fdms/*/ dir, the aircraft will each need their own dir like I have in $FG_ROOT/Aircraft/UIUC/ because, for instance, we could have upwards of 60 or so aero data files. - My guess is that JSBSim will also be using supporting aero data files, so I suspect it will also need a special dir for each aircraft. Regards, Michael or something like $FG_ROOT/Aircraft/c172r/aero/jsbsim.xml $FG_ROOT/Aircraft/c172r/aero/yasim.xml $FG_ROOT/Aircraft/c172r/aero/uiuc.xml depending on whether we want to group the aero files together with others using the same FDM or together with others for the same aircraft type. We could even replace 'aero' with 'physics' to make it clear to new users what's going on, since physics engines are starting to be heavily used in the 3D gaming world. The modern definition of 'racist' is someone who is winning an argument with a liberal. --Peter Brimelow What's the modern definition of 'liberal'? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:m-selig;uiuc.edu http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
Gene Buckle wrote: And FG already uses Zlib, so adding jar support wouldn't even require another library dependency. Is Zlib zip or bzip2 based? Or is it just the InfoZip lib and I didn't know? :) IIRC zip == Zlib != bzip2 CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
Michael Selig writes: - I like this approach (fdm/type named dirs vs aircraft/aero below). There's a lot more than just aero in the aircraft files: inits + aero + gear + engine + flag setting, etc. Also, I think from a developer standpoint, it's best to start w/ the fdm-type/aircraft-name rather than aircraft-name/fdm-type. The bad news is that that complicates installation. Instead of installing just one directory (or archive file) for each aircraft, a user has to install two. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
On Wed, 2002-11-13 at 08:16, Arnt Karlsen wrote: On Wed, 13 Nov 2002 09:39:05 -0500, David Megginson [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: JD Fenech writes: Major note: I've been trying to follow FG development for somewhat over a year, and still haven't been able to really figure out how FDMs are handled (are they internal to the software, or are they externally loaded). The FDMs are the aerodynamic engines (special-use physics engines). Unlike most simulators, FlightGear contains several different aerodynamic engines: JSBSim (the default), YASim, LaRCsim, UIUC (based on LaRCsim), and a few other special-use ones. The three major FDMs are runtime-configurable using external files so that they can simulate the physics of many different aircraft types: - JSBSim uses XML files scattered throughout $FG_ROOT/Aircraft/ - YASim uses XML files stored under $FG_ROOT/Aircraft-yasim/ - UIUC uses INI-like files stored under $FG_ROOT/Aircraft-uiuc/ Before you say anything, yes, I agree that this is wrong. We either want something like $FG_ROOT/Aircraft/fdms/jsbsim/c172r.xml $FG_ROOT/Aircraft/fdms/yasim/c172r.xml $FG_ROOT/Aircraft/fdms/uiuc/c172r.dat or something like $FG_ROOT/Aircraft/c172r/aero/jsbsim.xml $FG_ROOT/Aircraft/c172r/aero/yasim.xml $FG_ROOT/Aircraft/c172r/aero/uiuc.xml ..I like a birds view building block approach: JSBSim can be run as an external fdm to FG. How about making this the standard approach? Engine models imho should be called externally again, from the fdms. All of this is built on top of zlib, plib, SimGear etc. Modules. With clear interfaces. I can see the appeal of multiple processes in some instances (such as the need to avoid mixing GPL and non-GPL code). Otherwise, it's unnecessary complication, especially from a users point of view. ..some of us like hot OpenGL graphics and neat sceneries to plan and tweak our next air show. At other times, we analyse and tweak an airframe or an engine, and then we prefer to burn our cpu cycles in the fdm and engine models and can live with slow vesa-type graphics. You really don't need to be concerned about such a trade ... the fdms simply do not consume alot of cpu cycles. depending on whether we want to group the aero files together with others using the same FDM or together with others for the same aircraft type. We could even replace 'aero' with 'physics' to make it clear to new users what's going on, since physics engines are starting to be heavily used in the 3D gaming world. The modern definition of 'racist' is someone who is winning an argument with a liberal. --Peter Brimelow What's the modern definition of 'liberal'? ..someone who feels Saddam deserves yet another chance. ;-) -- ..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 -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
On Wednesday 13 November 2002 4:38 pm, Jim Wilson wrote: David Megginson [EMAIL PROTECTED] said: Erik Hofman writes: Allright, If you think lowres is not good enough, we can keep them. I was just trying to remove 11 Mb from the base package and thought the lowres version would be good enough. Perhaps the high-res could be an optional add-on. That wouldn't be good I don't think. They seem to be used by default. And are worth it. Gzipped we'd be looking at about 5.5mb. I haven't been following the conversation but, a couple things about the base package: 1) Releases != cvs snapshots It gets groomed. 2) While a smaller download is always better, the better FGFS gets, the more slack people will cut us when it comes to the download. The current gzipped cvs snapshot tarball is less than 40mb. How does this compare with other sims -demo- downloads? The base package also includes a manual in PDF and HTML formats, so add that in to the calculations. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Blender Status
John, From: [EMAIL PROTECTED] [mailto:flightgear-devel-admin;flightgear.org]On Behalf Of John Check The current gzipped cvs snapshot tarball is less than 40mb. How does this compare with other sims -demo- downloads? From my (a user's) point of view 40 MB is not large today. People have to and most people will understand that a full-featured Flight Simulator does not fit onto a 1.44 FD. As John says, compare it to the X plane demo, which a lot of people actually do download. Personally, I'd prefer not adding even more hassle to the installation by having the newcomer decide which modules to install. Of course we might revise this point of view later anytime. And, no, I neither have a cable modem nor SDL (but ISDN). I'd vote for adding a source/add-on package, though. This could include all the stuff a normal user does not need (including the manual source stuff). Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
On 13 Nov 2002 15:22:15 -0800, Tony Peden [EMAIL PROTECTED] wrote in message 1037229736.19944.727.camel@raptor: On Wed, 2002-11-13 at 08:16, Arnt Karlsen wrote: ..I like a birds view building block approach: JSBSim can be run as an external fdm to FG. How about making this the standard approach? Engine models imho should be called externally again, from the fdms. All of this is built on top of zlib, plib, SimGear etc. Modules. With clear interfaces. I can see the appeal of multiple processes in some instances (such as the need to avoid mixing GPL and non-GPL code). Otherwise, it's unnecessary complication, especially from a users point of view. ..coming from penguin world with many nice utilities co-operating to do the work, I beg to differ. ;-) ..some of us like hot OpenGL graphics and neat sceneries to plan and tweak our next air show. At other times, we analyse and tweak an airframe or an engine, and then we prefer to burn our cpu cycles in the fdm and engine models and can live with slow vesa-type graphics. You really don't need to be concerned about such a trade ... the fdms simply do not consume alot of cpu cycles. ..currently, no, agreed, in the future we may want to tinker with more complex fdms, flexing wings, iceing, damage models, or hook up a plane, balloon, submarine or a wind tunnel to it, then we have Atlas, Open Cockpit, networking, etc, etc, some day I will want to try fire more sparkling pine wood in my zeppeliner's gasifier... ;-) -- ..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
Re: [Flightgear-devel] Blender Status
On Wed, 2002-11-13 at 18:05, Arnt Karlsen wrote: On 13 Nov 2002 15:22:15 -0800, Tony Peden [EMAIL PROTECTED] wrote in message 1037229736.19944.727.camel@raptor: On Wed, 2002-11-13 at 08:16, Arnt Karlsen wrote: ..I like a birds view building block approach: JSBSim can be run as an external fdm to FG. How about making this the standard approach? Engine models imho should be called externally again, from the fdms. All of this is built on top of zlib, plib, SimGear etc. Modules. With clear interfaces. I can see the appeal of multiple processes in some instances (such as the need to avoid mixing GPL and non-GPL code). Otherwise, it's unnecessary complication, especially from a users point of view. ..coming from penguin world with many nice utilities co-operating to do the work, I beg to differ. ;-) I live in that world too ... and I've seen the kind of confusion multi-process programs cause. For me, its enough to avoid creating one without good reason. ..some of us like hot OpenGL graphics and neat sceneries to plan and tweak our next air show. At other times, we analyse and tweak an airframe or an engine, and then we prefer to burn our cpu cycles in the fdm and engine models and can live with slow vesa-type graphics. You really don't need to be concerned about such a trade ... the fdms simply do not consume alot of cpu cycles. ..currently, no, agreed, in the future we may want to tinker with more complex fdms, flexing wings, iceing, damage models, None of which will consume a great deal more CPU cycles. or hook up a plane, balloon, submarine or a wind tunnel to it Real time CFD is a pipe dream. Period. , then we have Atlas, Open Cockpit, networking, etc, etc, some day I will want to try fire more sparkling pine wood in my zeppeliner's gasifier... ;-) -- ..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 -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Blender Status
Michael Basler [EMAIL PROTECTED] said: John, From: [EMAIL PROTECTED] [mailto:flightgear-devel-admin;flightgear.org]On Behalf Of John Check The current gzipped cvs snapshot tarball is less than 40mb. How does this compare with other sims -demo- downloads? From my (a user's) point of view 40 MB is not large today. People have to and most people will understand that a full-featured Flight Simulator does not fit onto a 1.44 FD. As John says, compare it to the X plane demo, which a lot of people actually do download. Personally, I'd prefer not adding even more hassle to the installation by having the newcomer decide which modules to install. Of course we might revise this point of view later anytime. And, no, I neither have a cable modem nor SDL (but ISDN). Agreed. I kind of like the current structure, and we don't have enough finished models to start worrying about classifications...yet. Of course it is always good to look toward the future. Obviously, as David pointed out we can only reasonably include so many models in the base package. Right now we've got a lot of great starts for 3D Models, and now excellent support in the program for instrumenting and animating them. My focus (especially since I don't have the time to dive into programming now) is on fixing up 3D models. Making them better looking and more complete. We really need more people modeling, which is where this thread started isn't it? :-) I'd vote for adding a source/add-on package, though. This could include all the stuff a normal user does not need (including the manual source stuff). Disagree. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
At 9/2/02, David Megginson wrote: For those of you not currently following it, the Blender fund has been successful: out of the EUR 100,000 needed to buy the sources from the NaN shareholders, the fund has collected EUR 96,540 and has another EUR 9,481 pledged. With luck, we'll have a decent, cross-platform open-source modeller in a few weeks; here's the current plan: http://www.blender3d.com/blenderdotorg.html In the medium term, it would be nice to write a plugin that writes FlightGear XML files for animating models, rather than having to do them by hand. Any idea on the status of this? I assume this is the tool of choice for making models? Regards, Michael ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:m-selig;uiuc.edu http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
Michael Selig writes: Any idea on the status of this? I assume this is the tool of choice for making models? It is Open Source, while AC3D is commercial, but FlightGear really doesn't care which tool you use. I was repulsed by Blender the first few times I ran it and immediately removed it from my hard drive again. A couple of years later, I invested an hour or two in some of the online tutorials (castle, pencil), and was hooked. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
It is Open Source, while AC3D is commercial, but FlightGear really doesn't care which tool you use. [...] I had the impression these two tools target at different audience. Should Blender be capable of being used for 'real' 3D CAD as AC3D does ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
Martin Spott [EMAIL PROTECTED] said: It is Open Source, while AC3D is commercial, but FlightGear really doesn't care which tool you use. [...] I had the impression these two tools target at different audience. Should Blender be capable of being used for 'real' 3D CAD as AC3D does ? Depends on what you mean by 'real' 3D Cad i guess. David has done both c172's, and the j3cub in Blender. The biggest drawback is the blender files aren't in cvs and David doesn't use ac3d so if anyone offers a modification to the ac file it can't be added directly in without making it impossible for David to do further work on the model. If I'm not mistaken the process to get from Blender to flightgear is to save the file in blender, run the file through a conversion script to crate an ac3d file, and then edit that file in ppe to add name labels to objects. I beleive another step required involves sorting the alpha textured objects down the bottom of the list in a text editor. Also, there are things you can do in Blender that aren't supported in plib yet, e.g. nurbs. AC3D is a great program and I've used it for all my work, but it has two major drawbacks, it's license fee and it's license. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
Martin Spott writes: I had the impression these two tools target at different audience. Should Blender be capable of being used for 'real' 3D CAD as AC3D does ? Much more so than AC3D, I'd think -- it has many features that AC3D lacks, like a UV editor. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
Jim Wilson writes: If I'm not mistaken the process to get from Blender to flightgear is to save the file in blender, run the file through a conversion script to crate an ac3d file, and then edit that file in ppe to add name labels to objects. Fortunately, it's much simpler than that, since Blender has built-in Python scripting -- I just export the file to AC3D format from within Blender using a 3rd-party export script, and the object names, texture mappings, and material colours are preserved automatically. Usually, however, I have to do about 30 seconds of post-processing in a text editor: 1. Rearrange some objects (like the propeller disk) to work around plib's alpha-handling limitations. 2. Manually change the emissive properties for coloured materials (like nav lights), since the current AC3D export script doesn't save them (fixing that would take about 15 minutes of Python coding, but I'm lazy). Blender can export directly to VRML, and if plib had decent VRML support, I'd use that instead. In my tests, however, AC3D was the only fully-supported 3D format (other than MDL) in plib. Also, there are things you can do in Blender that aren't supported in plib yet, e.g. nurbs. Right, and 3D animation, etc., but none of those is useful for FlightGear -- we just need basic meshes. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
David Megginson [EMAIL PROTECTED] said: Fortunately, it's much simpler than that, since Blender has built-in Python scripting -- I just export the file to AC3D format from within Blender using a 3rd-party export script, and the object names, texture mappings, and material colours are preserved automatically. Usually, however, I have to do about 30 seconds of post-processing in a text editor: 1. Rearrange some objects (like the propeller disk) to work around plib's alpha-handling limitations. 2. Manually change the emissive properties for coloured materials (like nav lights), since the current AC3D export script doesn't save them (fixing that would take about 15 minutes of Python coding, but I'm lazy). Ok good, for some reason I thought the object names weren't getting carried through the conversion script. It is still a bit kludy though. Popping a complex model into a text editor can involve a little more than 30 seconds. It certainly isn't difficult though. My main concern is that if we use Blender, then files that will read into Blender should be maintained CVS as source data. We might even want to maintain our own version of the python script and at least Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
Jim Wilson writes: My main concern is that if we use Blender, then files that will read into Blender should be maintained CVS as source data. We might even want to maintain our own version of the python script and at least I would be happy to put my original Blender and XCF (Gimp) files online. They're not enormous, but they do take some space: -rw-r--r--1 daviddavid 230332 Nov 11 15:45 /home/david/src/blender/Aircraft/c172p/c172p.blend -rw-r--r--1 daviddavid 239608 Nov 10 15:11 /home/david/src/blender/Aircraft/c172p/c172p-01.xcf -rw-r--r--1 daviddavid 179949 Sep 8 11:34 /home/david/src/blender/Aircraft/c172p/c172p-02.xcf -rw-r--r--1 daviddavid 441208 Sep 14 10:06 /home/david/src/blender/Aircraft/c172p/c172p-int-01.xcf (and so on for each model). I don't think that the base package is the right place, though, and the FlightGear CVS repository certainly isn't. Any suggestions? Perhaps we need a new base-source CVS repository (we could put the original MDL files there as well). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
David Megginson wrote: Jim Wilson writes: My main concern is that if we use Blender, then files that will read into Blender should be maintained CVS as source data. We might even want to maintain our own version of the python script and at least I don't think that the base package is the right place, though, and the FlightGear CVS repository certainly isn't. Any suggestions? Perhaps we need a new base-source CVS repository (we could put the original MDL files there as well). There should be a graphics CVS module which sounds fine to me. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Blender Status
David, I don't think that the base package is the right place, though, and the FlightGear CVS repository certainly isn't. Any suggestions? Perhaps we need a new base-source CVS repository (we could put the original MDL files there as well). IMHO this is a splended idea. This way we could shift the LaTeX/Picture source files from documentation out of the base package, too. Would save another 1 MB from the base repository. I guess very few, if any, people are interested in these. Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
David Megginson [EMAIL PROTECTED] said: I don't think that the base package is the right place, though, and the FlightGear CVS repository certainly isn't. Any suggestions? Perhaps we need a new base-source CVS repository (we could put the original MDL files there as well). It does get a little sticky. We have some files that are original AC3D creations and some that are not. To the casual observer, they appear identical otherwise. It wouldn't make sense to add in the MDL files that the c310 U3-A, A-4 BlueAngels, and Wright Flyer were based on. In all three cases there was a significant amount of work in the initial conversion, and then a great deal of modification made using AC3D (the Wright Flyer was about 95% redone). Those changes will never be migrated back to the MDL file, unless someone else wants to do it. And in all three cases I never discussed redistributing the MDL files for those models, so we might have to obtain further permission to distribute them in their original form. If Blender becomes the tool of choice, as it probably should, for developing FlightGear Models then it makes sense to have those files in the CVS directory with the ac files that are derived from them. The CVS is a development repository after all. This doesn't prevent releasing a runtime base package that doesn't include all the sources for a smaller download, but such a release should clearly indicate that these are not the sources to be used for submitting changes back to the project. In the future, if we convert an MDL file to AC3D then we should decide what to do with those on a case by case basis. We may want to consider the conversion a replacement or we may not. It hardly makes sense to consider them sources since there is no easy way to convert them. I've done it (as has Wolfram) and what comes out of plib is not a normal ac3d file. It can require a tremendous amount of work. The Wright Flyer was a 2GB file (yes, gigabytes!) on my disk when I first saved it to AC3D format from PPE. This, I presume, is due to a major difference in the way MDL data is organized and the fact that plib attempts to maintain texturing in the output ac3d formatted file. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
Jim Wilson writes: If Blender becomes the tool of choice, as it probably should, for developing FlightGear Models then it makes sense to have those files in the CVS directory with the ac files that are derived from them. The CVS is a development repository after all. I'm already concerned about the base-package size. We need to start thinking seriously about making most aircraft optional add-ons. It's easy for me with a fast cable modem, but I don't want to scare away regular users. If the DC-3 (for example) was its own, separately downloadable package, then I'd have no problem including the Blender and XCF sources with it. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
At 11/12/02, David Megginson wrote: Jim Wilson writes: If Blender becomes the tool of choice, as it probably should, for developing FlightGear Models then it makes sense to have those files in the CVS directory with the ac files that are derived from them. The CVS is a development repository after all. I'm already concerned about the base-package size. We need to start thinking seriously about making most aircraft optional add-ons. It's easy for me with a fast cable modem, but I don't want to scare away regular users. If the DC-3 (for example) was its own, separately downloadable package, then I'd have no problem including the Blender and XCF sources with it. All the best, David (flame suit on) Some thoughts on the size of the base package. I did a 'du -k' on fgfsbase. The results can be viewed here: http://michael.selig.com/fgfs/021112-size.html From this I get: * The base package is about 100MB. Over a cable modem, this is not a problem. Over a phone modem, it is a nighttime chore. I have not heard complaints from those downloading overnight, or from those who get it in a flash over a cable modem. * I looked at the size of the dirs. The output is given below (sorry for the length!). When looking at this it's important to realize that the size of each nested dir is given, so don't be misled. For example, this info 10800 fgfsbase/Data/SkyClouds 10820 fgfsbase/Data All the space (10MB) is obviously in SkyClouds, not 20MB total. * I have included (in the link above) two versions of the same output. First in alfa order, and then in order of size. * The entire Aircraft dir, takes up about 25MB of the space --- 25%. Topping the list is the Wright Flyer w/ 4MB and then smaller after that. I doubt if these larger aircraft are ones that one would like to make optional (especially at this stage in the still early development of fgfs). For example, here are the largest dirs in Aircraft: Top 10 4060fgfsbase/Aircraft/wrightFlyer1903/Models (4MB) 2604fgfsbase/Aircraft/X15/Models (2.6MB) 1820fgfsbase/Aircraft/747/Models (...) 1228fgfsbase/Aircraft/sopwithCamel/Models/uiuc/sopwithCamel 1124fgfsbase/Aircraft/asw20/Models/uiuc/asw20-stuck 1044fgfsbase/Aircraft/j3cub/Models 908 fgfsbase/Aircraft/c172p/Models 660 fgfsbase/Aircraft/a4/Models 640 fgfsbase/Aircraft/c310u3a/Models 556 fgfsbase/Aircraft/c172/Panels Next 2 280 fgfsbase/Aircraft/c172/Models 260 fgfsbase/Aircraft/airwaveXtreme150/Models/uiuc * So if the top ten were optional, that would save about 15MB from the base package and 10 interesting aircraft would be downloaded separately. Is that worth it? It's a flight simulator and I think people who download it are expecting to have aircraft to fly immediately---several to choose from. To download things separately is going to be a hassle. Until people really start complaining, I'd say take a wait and see attitude. Let's not throw the baby out w/ the bath water. If space becomes an issue, I think there are bigger fish to fry, like the SkyClouds dir(?). Finally, it seems retro to take aircraft out of a flight simulator. Regards, Michael -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:m-selig;uiuc.edu http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
David Megginson [EMAIL PROTECTED] said: I'm already concerned about the base-package size. We need to start thinking seriously about making most aircraft optional add-ons. It's easy for me with a fast cable modem, but I don't want to scare away regular users. If the DC-3 (for example) was its own, separately downloadable package, then I'd have no problem including the Blender and XCF sources with it. What are the options as far as CVS? I can see splitting up the base package release, either into individual aircraft perhaps a few groups of aircraft. But it seems a little trickier with CVS and the current directory structure. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
Michael Selig [EMAIL PROTECTED] said: * The base package is about 100MB. Over a cable modem, this is not a problem. Over a phone modem, it is a nighttime chore. I have not heard complaints from those downloading overnight, or from those who get it in a flash over a cable modem. It's 32 ~ 37 mb depending on if you grab the bzip2 or gzip. By today's standard that isn't gigantic. But a lot of by today's standard projects out there are making it tough for modem users. It's a flight simulator and I think people who download it are expecting to have aircraft to fly immediately---several to choose from. To download things separately is going to be a hassle. Until people really start complaining, I'd say take a wait and see attitude. Let's not throw the baby out w/ the bath water. Good point, although I think there has been concern expressed. Just because we split some of the models out into a different files doesn't mean we're throwing them out. The idea would be to split up the base package into smaller chunks, not necessarily a lot of files. We could just have a second file that had more aircraft. Or a couple files with groups of similar aircraft. And we could still offer a file with everything in it. If space becomes an issue, I think there are bigger fish to fry, like the SkyClouds dir(?). That does seem large for what it is. Almost all of the size is in three files: field37.cld, field56.cld, and valley.cld. The names seem to indicate scenery, not cloud data? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
