[Flightgear-devel] no engine fuel flow in 737-600 but ok on 737-300 how is it defined?
I have been making some panels and lots of tinkering etc for a 737-NG600 based set up, upgrading from the old 737-300 based model i have used in the past. The 300 model used *fuel-flow_pph* from the engine prop tree to drive the panel fuel flow meters. In the 600 model these values remain unset, but the engines are the same, and the model engine configs for the CFM56 are identical files and don't define a fuel flow rate. I see these days there is a nasal script that adds *fuel-consumed-lbs* and * out-of-fuel* to the engine properties, but it also relies on the flow rates so the total and flag are never set. It must be in the aircraft model somewhere as one works and one does not, but I cant find it it anywhere in the old 737-300 model. On top of that I see the fuel levels on the tanks is dropping when the engines run. Even then the tank valves are turned off. And the engines only start when there fuel in the tank then stop as soon as the tank is empty. So can anyone advise what is the story here and how the *fuel-flow_pph *is defined? I assumed it was just a function on the engine in jbsim I need bit of a primer here. -- Regards Harry -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Using native OSG 3D models - is it possible?
Am Donnerstag, den 17.03.2011, 13:33 -0700 schrieb Hal V. Engel: On the forum there was a thread about an ebook on using Blender to create aircraft models. The web site for the ebook included a number of models and one of these was a WWII USAAF pilot that is very nicely done. The creator of these models has given permission to use these models in FlightGear without any restrictions. A link would be nice. The pilot is built using armatures so that he can be animated but of course FG/OSG does not support native Blender files. I have attempted to use the OSG and COLLADA export scripts to create a file that is supported but the resulting files are not handled correctly by FG/OSG. Have you looked at the Bluebird Pilot and Walker Animation System? Maybe this could be used in this case. I suspect that there are issues with the Blender export since using osgviewer to view the export also has major issues. I see messages like: $ osgviewer pilot-wwii.osg LinkVisitor links 3 for Thigh.R LinkVisitor links 3 for Calf.R LinkVisitor links 3 for Foot.R LinkVisitor links 3 for Thigh.L LinkVisitor links 3 for Calf.L LinkVisitor links 3 for Foot.L LinkVisitor links 3 for Pelvis LinkVisitor links 3 for Neck LinkVisitor links 3 for Head LinkVisitor links 3 for Arm.L (looks good to this point but) RigTransformSoftware Bone Jacket not found, skip the influence group Jacket RigTransformSoftware Bone Shoes not found, skip the influence group Shoes RigTransformSoftware Bone Trousers not found, skip the influence group Trousers RigTransformSoftware Bone Shoes not found, skip the influence group Shoes RigTransformSoftware Bone Trousers not found, skip the influence group Trousers ... (look broken to me and so doe the next set of messages) 0x7f3c9c070fe0 RigTransformSoftware::UniqBoneSetVertexSet no bones found 0x7f3c9c070fe0 RigTransformSoftware::UniqBoneSetVertexSet no bones found 0x7f3c9c070fe0 RigTransformSoftware::UniqBoneSetVertexSet no bones found 0x7f3c9c070fe0 RigTransformSoftware::UniqBoneSetVertexSet no bones found So the exported file is clearly an issue for OSG. I have not been able to make the COLLADA export work at all. With a COLLADA 1.3 export I get an empty file and an error message about a script failure. With the COLLADA 1.4 export I get a file but osgviewer will not load it because Warning: Could not find plugin to read objects from file pilot-wwii.dae. Do I need to change the way OSG is built or do I need to get a COLLADA plugin from some other place? I have been able to get a AC3D export but of course all of the armature stuff is gone and all I have at that point is a static model that can not be animated. So my questions are: 1. Is it possible to use and animate a model with armatures in FG/OSG assuming the 3D file is correctly formed? 2. If so what 3D file formats are best? 3. And how do I get a viable export from Blender? Hal -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Detlef Faber http://www.sol2500.net/flightgear -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] no engine fuel flow in 737-600 but ok on 737-300 how is it defined?
So can anyone advise what is the story here and how the *fuel-flow_pph *is
defined? I assumed it was just a function on the engine in jbsim I need bit
of a primer here.
There is Nasal/system.nas in the 737-300 directory. Around line 200 of that
file the code
pph1=getprop(/engines/engine[0]/fuel-flow-gph);
if(pph1 == nil){pph1 = 0.0};
pph2=getprop(/engines/engine[1]/fuel-flow-gph);
if(pph2 == nil){pph2 = 0.0};
setprop(engines/engine[0]/fuel-flow_pph,pph1* fuel_density);
setprop(engines/engine[1]/fuel-flow_pph,pph2* fuel_density);
computes fuel-flow_pph.
Greetings, Torsten
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] no engine fuel flow in 737-600 but ok on 737-300 how is it defined?
HI Torsten
Thanks for the reply,
Are you sure about this? I believe my distro 737-300 model is is up to date,
and almost identical to my 2008 one, but either way I dont have any file
Nasal/system.nas in the 737-300 directories and it gives a pph value on the
engine prop tree though no gph when running. The model is almost a pre nasal
design.
The 737NG600 has both gph and pph but neither has a value on its prop tree
when running.
Also, the way I read your snippet, this nasal code requires a *fuel-flow-gph
* value then calcs *fuel-flow-pph *but my props for the engine dont have a
value in either.*
*Now I am really confused.*
Harry
*
On Fri, Mar 18, 2011 at 3:53 PM, Torsten Dreyer tors...@t3r.de wrote:
So can anyone advise what is the story here and how the *fuel-flow_pph
*is
defined? I assumed it was just a function on the engine in jbsim I need
bit
of a primer here.
There is Nasal/system.nas in the 737-300 directory. Around line 200 of that
file the code
pph1=getprop(/engines/engine[0]/fuel-flow-gph);
if(pph1 == nil){pph1 = 0.0};
pph2=getprop(/engines/engine[1]/fuel-flow-gph);
if(pph2 == nil){pph2 = 0.0};
setprop(engines/engine[0]/fuel-flow_pph,pph1* fuel_density);
setprop(engines/engine[1]/fuel-flow_pph,pph2* fuel_density);
computes fuel-flow_pph.
Greetings, Torsten
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flighhttps://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] no engine fuel flow in 737-600 but ok on 737-300 how is it defined?
From: Harry Campigli Sent: Friday, March 18, 2011 1:01 PM To: FlightGear developers discussions Cc: Torsten Dreyer Subject: Re: [Flightgear-devel] no engine fuel flow in 737-600 but ok on 737-300 how is it defined? HI Torsten Thanks for the reply, Are you sure about this? I believe my distro 737-300 model is is up to date, and almost identical to my 2008 one, but either way I dont have any file Nasal/system.nas in the 737-300 directories and it gives a pph value on the engine prop tree though no gph when running. The model is almost a pre nasal design. The 737NG600 has both gph and pph but neither has a value on its prop tree when running. Also, the way I read your snippet, this nasal code requires a fuel-flow-gph value then calcs fuel-flow-pph but my props for the engine dont have a value in either. Now I am really confused. Harry It seems that fuel in gals for many models (e.g Concorde ) has been broken by recent changes. The symptoms are start up errors, and the Equipment-Fuel And Payload menu reports zero Fuel Gallons, but non-zero Fuel Pounds. Could whoever created these changes please give us some guidance as to how the models should be changed? Alan-- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Using native OSG 3D models - is it possible?
Hi Hal, Oh yes, it is possible. But not easy. Hal V. Engel wrote: I have been able to get a AC3D export but of course all of the armature stuff is gone and all I have at that point is a static model that can not be animated. The export process from Blender may not be the problem. _If_ each limb is correctly defined separately, and a child of the parent limb, then the hard part is generating the _xml_ file that defines the center of rotation of each limb's connection, and how it rotates. Each limb needs between 1 and 3 axis properties. Take a look at the animated walker in the Bluebird aircraft. Stewart http://seahorseCorral.org/flightgear_aircraft -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Using native OSG 3D models - is it possible?
@Hal could we get a link?@Stewart. Seems you live in a beautiful nature surrounding. I've to go there once. Kind of adventure your living... X-Plane 10 is delayed until fall so where is FGFS 2.2? Recently i stumbled across a OSX/Linux installer based on Loki but cannot refind it. --- On Fri, 3/18/11, S Andreason sandrea...@gmail.com wrote: From: S Andreason sandrea...@gmail.com Subject: Re: [Flightgear-devel] Using native OSG 3D models - is it possible? To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Date: Friday, March 18, 2011, 3:08 PM Hi Hal, Oh yes, it is possible. But not easy. Hal V. Engel wrote: I have been able to get a AC3D export but of course all of the armature stuff is gone and all I have at that point is a static model that can not be animated. The export process from Blender may not be the problem. _If_ each limb is correctly defined separately, and a child of the parent limb, then the hard part is generating the _xml_ file that defines the center of rotation of each limb's connection, and how it rotates. Each limb needs between 1 and 3 axis properties. Take a look at the animated walker in the Bluebird aircraft. Stewart http://seahorseCorral.org/flightgear_aircraft -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] no engine fuel flow in 737-600 but ok on 737-300 how is it defined?
Well I have had a poke around (blind man in the dark scenario) in the jbsim turbine code and found the fuel flow value is already and always generated on a per second scale, And also Oil Temp ,another goodie i was looking for, from there is appears on the *fdm/jsbsim/propulsion/engine* property tree. I am not sure how it gets over to the engines prop tree and multiplied to hours in the model but I will take it from the fdm for now. And it looks like JBSim is taking the fuel from the tanks as well. I have to much to learn here. Harry On Fri, Mar 18, 2011 at 8:33 PM, Alan Teeder ajtee...@v-twin.org.uk wrote: *From:* Harry Campigli harryc...@gmail.com *Sent:* Friday, March 18, 2011 1:01 PM *To:* FlightGear developers discussionsflightgear-devel@lists.sourceforge.net *Cc:* Torsten Dreyer tors...@t3r.de *Subject:* Re: [Flightgear-devel] no engine fuel flow in 737-600 but ok on 737-300 how is it defined? HI Torsten Thanks for the reply, Are you sure about this? I believe my distro 737-300 model is is up to date, and almost identical to my 2008 one, but either way I dont have any file Nasal/system.nas in the 737-300 directories and it gives a pph value on the engine prop tree though no gph when running. The model is almost a pre nasal design. The 737NG600 has both gph and pph but neither has a value on its prop tree when running. Also, the way I read your snippet, this nasal code requires a * fuel-flow-gph* value then calcs *fuel-flow-pph *but my props for the engine dont have a value in either.* *Now I am really confused.* Harry * ** It seems that fuel in gals for many models (e.g Concorde ) has been broken by recent changes. The symptoms are start up errors, and the Equipment-Fuel And Payload menu reports zero Fuel Gallons, but non-zero Fuel Pounds. Could whoever created these changes please give us some guidance as to how the models should be changed? Alan -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Regards Harry 19b Jln Danau Poso Sanur, Bali 80228 H +62 361 285629 M +62 812 7016328 -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Using native OSG 3D models - is it possible?
X-Plane 10 is delayed until fall so where is FGFS 2.2? Recently i stumbled across a OSX/Linux installer based on Loki but cannot refind it. Fall? At first it was December '10, then spring, now fall FGFS 2.2 - I heard when the automatic Release (Hudson Builds)is 100% working, so we can produce FGFS in more regular way than now. Anyway, with the Hudson Builds I have a Release nearly every day ... The Power of OpenSource! *g* -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Using native OSG 3D models - is it possible?
On Friday, March 18, 2011 12:50:02 AM Detlef Faber wrote: Am Donnerstag, den 17.03.2011, 13:33 -0700 schrieb Hal V. Engel: On the forum there was a thread about an ebook on using Blender to create aircraft models. The web site for the ebook included a number of models and one of these was a WWII USAAF pilot that is very nicely done. The creator of these models has given permission to use these models in FlightGear without any restrictions. A link would be nice. Sorry, Here is a link to the forum thread: http://www.flightgear.org/forums/viewtopic.php?f=4t=11210sid=be965cf355c646bb6e77cebf5a5dca9c It has a link to the site with the ebook and there is an easy to find link there to the models including the pilot model. The pilot is built using armatures so that he can be animated but of course FG/OSG does not support native Blender files. I have attempted to use the OSG and COLLADA export scripts to create a file that is supported but the resulting files are not handled correctly by FG/OSG. Have you looked at the Bluebird Pilot and Walker Animation System? Maybe this could be used in this case. I suspect that there are issues with the Blender export since using osgviewer to view the export also has major issues. I see messages like: $ osgviewer pilot-wwii.osg LinkVisitor links 3 for Thigh.R LinkVisitor links 3 for Calf.R LinkVisitor links 3 for Foot.R LinkVisitor links 3 for Thigh.L LinkVisitor links 3 for Calf.L LinkVisitor links 3 for Foot.L LinkVisitor links 3 for Pelvis LinkVisitor links 3 for Neck LinkVisitor links 3 for Head LinkVisitor links 3 for Arm.L (looks good to this point but) RigTransformSoftware Bone Jacket not found, skip the influence group Jacket RigTransformSoftware Bone Shoes not found, skip the influence group Shoes RigTransformSoftware Bone Trousers not found, skip the influence group Trousers RigTransformSoftware Bone Shoes not found, skip the influence group Shoes RigTransformSoftware Bone Trousers not found, skip the influence group Trousers ... (look broken to me and so doe the next set of messages) 0x7f3c9c070fe0 RigTransformSoftware::UniqBoneSetVertexSet no bones found 0x7f3c9c070fe0 RigTransformSoftware::UniqBoneSetVertexSet no bones found 0x7f3c9c070fe0 RigTransformSoftware::UniqBoneSetVertexSet no bones found 0x7f3c9c070fe0 RigTransformSoftware::UniqBoneSetVertexSet no bones found So the exported file is clearly an issue for OSG. I have not been able to make the COLLADA export work at all. With a COLLADA 1.3 export I get an empty file and an error message about a script failure. With the COLLADA 1.4 export I get a file but osgviewer will not load it because Warning: Could not find plugin to read objects from file pilot-wwii.dae. Do I need to change the way OSG is built or do I need to get a COLLADA plugin from some other place? I have been able to get a AC3D export but of course all of the armature stuff is gone and all I have at that point is a static model that can not be animated. So my questions are: 1. Is it possible to use and animate a model with armatures in FG/OSG assuming the 3D file is correctly formed? 2. If so what 3D file formats are best? 3. And how do I get a viable export from Blender? Hal - - Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 59, Issue 9
On 03/18/2011 07:28 PM, flightgear-devel-requ...@lists.sourceforge.net wrote: I'm trying to implement thrust reversal (if possible) for the ATR 72, a YASim turboprop, but I can't seem to find a way to do so. I've tried the same parameters used for jets: control-input axis=/controls/engines/engine[0]/reverser control=REVERSE_THRUST / control-output control=REVERSE_THRUST prop=/engines/engine[0]/reverser-pos-norm / But YASim spits out a solution failure error. Changing /controls/engines/engine[X]/propellor-pitch to 0 or 1 does not seem to have an effect, and I haven't been able to find reverse thrust on any other YASim turboprop. Hey Ryan, You can study my C130. I use to simulate reverser this : !-- trusters for reverse -- thruster x=3.764 y=4.929 z=3.307 vx=-1 vy=0 vz=0 thrust=15000 control-input axis=/controls/engines/engine[0]/reverser control=THROTTLE src0=0 src1=1 dst0=0 dst1=1/ /thruster thruster x=3.764 y=-4.929 z=3.307 vx=-1 vy=0 vz=0 thrust=15000 control-input axis=/controls/engines/engine[0]/reverser control=THROTTLE src0=0 src1=1 dst0=0 dst1=1/ /thruster The result is quite satisfactory Regards. Emmanuel -- BARANGER Emmanuel http://helijah.free.fr -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] File sizes in fgdata, clean up needed?
On 18.03.2011 17:50, HB-GRAL wrote: Today I checked the current fgdata/Aircraft folder for sizes. It’s about 4,3 GB here. Nice. Some of this files are .gz already, when I .gz the rest I get another 100 MB, or in other words I get two MiG-15 or another p51d. Nice statistics! Maybe this motivates some of us to be a bit more considerate before committing something to the repo. However, remember that dropping any file from the repository wouldn't help at all now: a git repository never shrinks - it can only grow... It's an especially bad idea to drop files and resubmit a smaller/compressed version in a futile attempt to shrink the repository. git contains a complete history of every file. If you dropped files and resubmitted a smaller version, the local fgdata directories may at first appear smaller - but if you checked the total size (that is including the hidden .git folders) you'll see that the total size was actually increased... And another warning: the complete history issue also affects personal git branches on gitorious. So, if an a/c designer adds 19 versions of an image file to his private branch and then placed a merge request to fgdata/master - then the merge will actually copy the history of all 19 file versions to the master branch - even the history of files which were already dropped on the private branch. So, in such cases it's a good idea to not actually git merge the complete personal branch to our master - but to simply take a copy of the latest version of the a/c files and to submit them to master using a fresh commit (I think that's what our fgdata-merge-committers do anyway - at least I hope so...). Or maybe any git expert knew if there was a git-merge-without-history command? Indeed, fgdata/master is becoming way too big though. But we can only solve this by splitting our current repository - and then push the different parts to fresh git repositories. Splitting fgdata was planned anyway. The new --fg-aircraft options was the first step to make this possible. I'm just not sure what the status of splitting fgdata is though... cheers, Thorsten -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] File sizes in fgdata, clean up needed?
And another warning: the complete history issue also affects personal git branches on gitorious. So, if an a/c designer adds 19 versions of an image file to his private branch and then placed a merge request to fgdata/master - then the merge will actually copy the history of all 19 file versions to the master branch - even the history of files which were already dropped on the private branch. So, in such cases it's a good idea to not actually git merge the complete personal branch to our master - but to simply take a copy of the latest version of the a/c files and to submit them to master using a fresh commit (I think that's what our fgdata-merge-committers do anyway - at least I hope so...). Or maybe any git expert knew if there was a git-merge-without-history command? You can merge a branch using one commit with git merge --squash branch_to_merge git commit The merge --squash applies the changes from all the commits to the current branches working tree and stages them. It also creates a commit message that concatenates all the commit messages for the ones that are being merged. git commit then allows you to edit that message (and commit of course). Basically it does exactly what you're after :) Cheers, Luuk -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Using native OSG 3D models - is it possible?
On Friday, March 18, 2011 07:08:14 AM S Andreason wrote: Hi Hal, Oh yes, it is possible. But not easy. Hal V. Engel wrote: I have been able to get a AC3D export but of course all of the armature stuff is gone and all I have at that point is a static model that can not be animated. The export process from Blender may not be the problem. _If_ each limb is correctly defined separately, and a child of the parent limb, then the hard part is generating the _xml_ file that defines the center of rotation of each limb's connection, and how it rotates. Each limb needs between 1 and 3 axis properties. Take a look at the animated walker in the Bluebird aircraft. Stewart http://seahorseCorral.org/flightgear_aircraft Sorry I should have been clearer. I didn't mean to imply that the AC3D export was not working. Rather only that all it created from this armature based model is a static model that had very limited posibilities for animation. You are correct that if ..each limb is correctly defined separately, and a child of the parent limb.. for non-armature animation that the export would likely work OK. The model I am looking at only has one mesh for the body including arms, hands, fingers, figer tips, thumb, legs and feet. This mesh is drapped over a set of armatures (bones) and it is designed to be animated by moving the bones with that mesh following them (IE. no visiable seams). AC3D has no support for armatures as far as I can tell so this imformation is lost on export and I end up with a mesh that is the shape that the model was posed in when it was exported. Inside of Blender I can pull, push and/or rotate the bones to pose the model in extreamly precise ways even down to changing the grip of the hands to fit around controls. The exported AC3D model can be made to fit very nicely into the cockpit but the only thing that can be animated is the head because it is a seperate mesh from the rest of the model. Inside of Blender the posing process is actually very elegant as all of the bones know how they are connected and everything moves together as it should when one part of moved. That is if you rotate the forarm the hands and fingers follow along with no need to move them seperately. I am not sure (I am new to this 3D stuff) but it seams to me that the same types of transformations should happen when the bones are animated in sim/game (IE. move the hand with the stick and the fingers, finger tips, thumb, forarm and upper arm should follow automatically). But maybe I'm wrong. The walker model is much like the existing modern pilot that is part of the P-51D. Very unnatural and complex to animate and with seams at the joints that are visible. The OSG docs I have looked at indicate that it supports armature based animation. So in theroy if I can get the armature based blender pilot into a correct OSG 3D file then it should be possible to animate it and the animation should be fairly elegant. But it appears that the Blender OSG exporter is broken. It also appears that no one has tried doing armature based animation with any file format from with in FG yet. So I don't even know at this point if this will work with the correctly formed 3D files. What I am really trying to get at is: 1. Will this work from with in FG? 2. If so how do I get well formed armature based 3D files that will work with OSG out of Blender (I don't care what format it is as long as OSG understands it)? Hal -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] File sizes in fgdata, clean up needed?
On Friday, March 18, 2011 09:50:50 AM HB-GRAL wrote: Hi all Today I checked the current fgdata/Aircraft folder for sizes. It’s about 4,3 GB here. Nice. Now some statistics (and this is no critcs on aircrafts of course, I like all the development and improvements a lot!): We have 372 aircrafts in the directory. 22 of this aircrafts have more than 30 MB and this 22 aircraft gives 1,1 GB of the aircraft folder. Number One is p51d with 104.5 MB (!). 50 MB in the models folder comes from GIMP .xcf-files and from Blender files (.blend). Do we distribute this files uncompressed? i. e. compressing .xcf to .gz will give a 1,2 file instead of a 4,3 MB. I think 12 MB vs. 43 MB. Number Two is 767-300 with 82,2 MB. I. e. this one comes with widely used .wav-sounds in the cabin ;-) This sounds, or better short loops, take 17,3 MB here. One livery (VRN.png) takes 6.3 MB. Number three is MiG-15, a really nice one, with a lot of instruments, and it seems like every byte is used here. I am looking deeper into the files and I see a radio-tune.wav which has 3.5 MB for 10 seconds of sound and 10 seconds of silence ;-) Some models like IAR80 have liveries with 13 MB .png-files. Totally we distribute 18 blender files with the directory. This is only 16,4 MB. Not much. But we distribute also 310 MB of original GIMP files. Some of this files are .gz already, when I .gz the rest I get another 100 MB, or in other words I get two MiG-15 or another p51d. Cheers, Yves I think Yves has several good points. First many of these advanced models have working files that are not actually used when the model is being flown in sim. The p51d GIMP files and blender files are two examples. Now there are valid reasons for these to be source controlled. For example the gimp files in the p51d/Models directory are complex multi layer files that are intended to make working with the resulting textures easier and they do indeed do that. Reading Yves comments I think one of the things he hionted was not so much that these working files made GIT bigger but that that they made the distribution size to users bigger and really served no purpose for users other than wasting disk space and bandwidth. This is a valid concern at least if the size of these working files is significant and in some of these case they are. A look at p51d/Models clearly shows that the three big space users are (in order of the highest space useage) the working files mostly in the form of high resolution multi layer textures, 3D models and the actual textures. In the case of the p51d all 3D models are AC3D files and many of the textures except some newer ones are *.rgb files. These are not the most compact formats and changing these could reduce the size of the model significantly but the 800 pound gorrila is still the working files. In the case of the p51d, and I suspect that this is true for most models, the working files could be located anywhere in the file system tree. And perhaps it makes sense to have a directory with a standard name that is used for these types of files that is always excluded (somehow?) when regular user gets a copy but is included for GIT clones. In the case of the p51d this would cut the size of the distributed copy almost in half. The 3D and texture parts of the p51d are now fairly far along and will not grow too much more even though there is still 3D work that needs to be done. It's size will only grow by perhaps 10% as it 3D model and FDM are finalized. There may be other models that get implemented for more complex aircraft that could result in significantly larger models. I suspect that the 100 meg p51d to 310+ meg IAR80 sort of represents the size range we will be seeing for really advanced highly detailed models with a few really careful modelers being able to bring these numbers down to lower levels while achiving the same effective level of detail like the Mig-15 does. I really think we are only seeing the begining of a period where are will see more efforts to take existing models to the next level and where we will start seeing new additions that enter GIT already in a very advanced state. As this process unfolds we will see many more models that approach the size of the ones listed by Yves. We don't want to discourage that work but if we can create a set of best practices we can perhaps help those working on this stuff create these highly detailed aircraft while using less space for the files needed to support this work. Hal -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net
Re: [Flightgear-devel] File sizes in fgdata, clean up needed?
I've been threatening for some time to break up the aircraft portion of fgdata into several repositories by using some git magic. It's true that the current repository size is out of hand. I would encourage people to check in their source files whenever possible. I'd also encourage people to add new aircraft to their own repositories on gitorious and think about moving past the central repository model. Tim On Fri, Mar 18, 2011 at 9:48 PM, Hal V. Engel hven...@gmail.com wrote: On Friday, March 18, 2011 09:50:50 AM HB-GRAL wrote: Hi all Today I checked the current fgdata/Aircraft folder for sizes. It’s about 4,3 GB here. Nice. Now some statistics (and this is no critcs on aircrafts of course, I like all the development and improvements a lot!): We have 372 aircrafts in the directory. 22 of this aircrafts have more than 30 MB and this 22 aircraft gives 1,1 GB of the aircraft folder. Number One is p51d with 104.5 MB (!). 50 MB in the models folder comes from GIMP .xcf-files and from Blender files (.blend). Do we distribute this files uncompressed? i. e. compressing .xcf to .gz will give a 1,2 file instead of a 4,3 MB. I think 12 MB vs. 43 MB. Number Two is 767-300 with 82,2 MB. I. e. this one comes with widely used .wav-sounds in the cabin ;-) This sounds, or better short loops, take 17,3 MB here. One livery (VRN.png) takes 6.3 MB. Number three is MiG-15, a really nice one, with a lot of instruments, and it seems like every byte is used here. I am looking deeper into the files and I see a radio-tune.wav which has 3.5 MB for 10 seconds of sound and 10 seconds of silence ;-) Some models like IAR80 have liveries with 13 MB .png-files. Totally we distribute 18 blender files with the directory. This is only 16,4 MB. Not much. But we distribute also 310 MB of original GIMP files. Some of this files are .gz already, when I .gz the rest I get another 100 MB, or in other words I get two MiG-15 or another p51d. Cheers, Yves I think Yves has several good points. First many of these advanced models have working files that are not actually used when the model is being flown in sim. The p51d GIMP files and blender files are two examples. Now there are valid reasons for these to be source controlled. For example the gimp files in the p51d/Models directory are complex multi layer files that are intended to make working with the resulting textures easier and they do indeed do that. Reading Yves comments I think one of the things he hionted was not so much that these working files made GIT bigger but that that they made the distribution size to users bigger and really served no purpose for users other than wasting disk space and bandwidth. This is a valid concern at least if the size of these working files is significant and in some of these case they are. A look at p51d/Models clearly shows that the three big space users are (in order of the highest space useage) the working files mostly in the form of high resolution multi layer textures, 3D models and the actual textures. In the case of the p51d all 3D models are AC3D files and many of the textures except some newer ones are *.rgb files. These are not the most compact formats and changing these could reduce the size of the model significantly but the 800 pound gorrila is still the working files. In the case of the p51d, and I suspect that this is true for most models, the working files could be located anywhere in the file system tree. And perhaps it makes sense to have a directory with a standard name that is used for these types of files that is always excluded (somehow?) when regular user gets a copy but is included for GIT clones. In the case of the p51d this would cut the size of the distributed copy almost in half. The 3D and texture parts of the p51d are now fairly far along and will not grow too much more even though there is still 3D work that needs to be done. It's size will only grow by perhaps 10% as it 3D model and FDM are finalized. There may be other models that get implemented for more complex aircraft that could result in significantly larger models. I suspect that the 100 meg p51d to 310+ meg IAR80 sort of represents the size range we will be seeing for really advanced highly detailed models with a few really careful modelers being able to bring these numbers down to lower levels while achiving the same effective level of detail like the Mig-15 does. I really think we are only seeing the begining of a period where are will see more efforts to take existing models to the next level and where we will start seeing new additions that enter GIT already in a very advanced state. As this process unfolds we will see many more models that approach the size of the ones listed by Yves. We don't want to discourage that work but if we can create a set of best practices we can perhaps help those working on this stuff create these highly detailed
