Board index FlightGear Development Aircraft

3D File Formats to use in creating aircraft

Questions and discussion about creating aircraft. Flight dynamics, 3d models, cockpits, systems, animation, textures.

3D File Formats to use in creating aircraft

Postby openflight » Thu Jun 18, 2020 4:40 am

I have been using Wings3D 1.4 and Blender 2.4 (which has the .ac import export function, without needing scripts).

Is there a better way, using free software? What about versions - for example the 'model-how-to.tml' in FGROOT DOCs says:
(The same 2002 model how to found in Flight Gear 1.0 and 2018.1.1 as well.

1. Loading the model
Through OpenSceneGraph, FlightGear supports many different 3D file formats, including VRML2, AC3D, DXF, and many others. The property /sim/model/path in the main FlightGear property tree controls what model will be loaded; it takes a string value giving the relative path of the model from FG_ROOT (the root of the base package, such as /usr/local/lib/FlightGear or C:\FLIGHTGEAR\).


Test 3D models with FG1.0

1) Block1.3ds Loads in FGRUN, does not load in FG (object 'fond' not found)
2) Block1.lwo Result: FGRUN - "failed to load 3D model C:\ProgramFiles|
3) Block1.obj Loads in FGRUN, does not load in FG (object 'fond' not found)
4) Block1.wrl Result: FGRUN - "failed to load 3D model C:\ProgramFiles|......
5) Block1.x Result: FGRUN - "failed to load 3D model C:\ProgramFiles|......

I think I can correct the error in FG, 'fond' etc.

Would it be possible to create models in .3ds or .lwo since these are easily exportable from Wings 3D, and .obj files are in readable text?

Or else some online program that can save in Blender and from there it can be exported to .ac format.

Anyone used these two?

https://www.tinkercad.com/things

https://clara.io/
openflight
 
Posts: 454
Joined: Fri Sep 16, 2011 11:14 am
Version: 1 2 2018
OS: Linux Mint 19.3

Re: 3D File Formats to use in creating aircraft

Postby CaptB » Thu Jun 18, 2020 7:18 am

The models need to be in .ac (AC3D) format. Use the export plugins available for Blender 2.7x and 2.8x or any software that can export to AC3D natively or via plugins.
CaptB
 
Posts: 578
Joined: Thu May 23, 2013 6:36 pm
Callsign: EKCH_AP
IRC name: CAPTB
Version: 2020.1.1
OS: Xubuntu 20.04

Re: 3D File Formats to use in creating aircraft

Postby openflight » Thu Jun 18, 2020 12:46 pm

Using Blender, Wings 3D and exporting and importing with success. Would be simpler if it could be all done within Wings 3D since Blender is still difficult for me to use.

Are there any fundamental problems with using .obj or .3ds ? I guess I will have to find out. And materials only, no textures.
openflight
 
Posts: 454
Joined: Fri Sep 16, 2011 11:14 am
Version: 1 2 2018
OS: Linux Mint 19.3

Re: 3D File Formats to use in creating aircraft

Postby wkitty42 » Thu Jun 18, 2020 3:54 pm

animations are a problem with other formats, IIRC...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 6444
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Some background from the horse's mouth ...

Postby Hooray » Thu Jun 18, 2020 5:01 pm

https://sourceforge.net/p/flightgear/ma ... /21504003/
Tim Moore wrote:It's true that Flightgear does all model animations via XML files that
are separate from the model files, but that's an artifact of the tools that
Flightgear modelers have used to date. While it is convenient to have a
human-readable format for animations, OSG does support animations directly in
its scene graph and can construct them from loaded files. If you can export the
pivots and sequences of your animations into one of the above file formats, then
the remaining work is connecting Flightgear runtime properties with the
controlling animation variables in the model. There would be some XML for you to
write (I think), and we would need to support hooking into an OSG animation
directly.


https://sourceforge.net/p/flightgear/ma ... /21915022/
Mathias Fröhlich wrote:But, it is well know to me that the animations are applied to the model and
all submodels. This is something I did not like to implement, but that
happened for some reason with the plib stuff and that was reimplemented with
osg. There is a comment in the model animation code that states that this is
something strange to do. But I guess that there are many configurations out
there that rely on this property.

There are many more surprising things in the xml format that has grown over
the years. I do not remember what else, but at the time I implemented that in
osg. I hit plenty of strange behaviours that are hard to implement in the
animations code, and might be very surprising to model authors if you step on
that.

I have often thought about introducing a more flexible and consistent xml model
format where such surprises do not happen anymore. We could probably produce
more tight scenegraphs which would help culling speed. We could stop the need
to flip all the ac models to a different axis orientation which will definitely
help modelers to animate their models. We could rethink some animations
semantics which is sometimes very slightly beyond that what could be
implemented efficiently. Often the most interesting use cases would work very
good. But due to having that stuff like it is I had to implement something that
was not very efficient to do.


https://sourceforge.net/p/flightgear/ma ... /26794801/
Tim Moore wrote:I'm not going to document the whole model loading process; it would be nice
one day to have better comments in the code, but this code has accreted over
many years, starting long before my involvement with FG. At a very high
level, when a model is loaded, its OSG subgraph is copied, except for its
textures and geometry. This is not-optimal, but it allows animation of all
models without a complicated optimizer.

In the monster function sgLoad3DModel_internal, effects mentioned in the
.xml file are gathered, along with any created implicitly by animations. An
effect is associated with named objects in the model. The .XML file can also
specify a default effect for the whole file; by default that is
Effects/model-default.eff. The model itself is transformed by
instantiateEffects, which uses MakeEffectVisitor. For each named object in
the model, this MakeEffectVisitor sets the appropriate effect as a "parent"
effect, and then creates a new effect for any osg::StateSet found,
inheriting from the parent. osg::Geode objects are replaced with
simgear::EffectGeode objects that will apply the effect at runtime. There is
quite a bit of hair to share effects and avoid creating new ones where
possible.

The dependency on .ac exists at this level in MakeEffectVisitor. The visitor
expects to find osg::StateSet objects only in osg::Geode objects i.e., near
the leaves of the scene graph. It only works with the simple attributes
created by the .ac loader (see makeParametersFromStateSet): osg::Material
properties, smooth vs. flat shading, polygon culling, blending (for
transparency), and one texture binding. Any other attributes are ignored.

If you want to apply effects to other kinds of models, you would need to
generalize MakeEffectVisitor "in both directions." StateSet objects can
appear in any scene graph node and also in the Geometry nodes that sit below
osg::Geode. A more general effects visitor needs to track the graphics state
as it traverses the scene graph and also needs to examine the geometry.
Effects sit at the Geode level.

Alternatively you could ignore any state attributes in the model and specify
it all in the .xml file, but this would quickly get tiresome.

I recommend you use the osgconv program to dump out the .osg representation
of our .ac models and the models that interest you and get an idea of the
differences you are up against. For .ac you should use our Optimizer options
found in ModelRegistry.cxx; you can set them with the OSG_OPTIMIZER
environment variable.


http://www.openscenegraph.org/index.php ... SceneGraph
https://subscription.packtpub.com/book/ ... le-formats
What file formats are supported by OpenSceneGraph?

File input and output is supported through the plugins in the src/osgPlugins directory of the source distribution. See Support/UserGuides/Plugins for an overview of available plugins, the file formats they support and the read/write capabilities of the plugins.

Note that some of the plugins depend on external libraries to be installed! A very frequent question from people just starting out using the OSG is why a certain plugin (such as for reading JPEG images) is not available. Most of the time missing plugins are caused by not having the correct information on dependencies during building of the OSG. The CMake build tool needs to know the location of plugin dependency headers and libraries, such as libjpeg, libtiff, GDAL, etc. Especially on Windows, where libraries do not have standard locations in the file system.

Some additional file formats are also supported by the Virtual Terrain Project (http://www.vterrain.org/). (Wiki editing note: what does this remark have to do with OpenSceneGraph?)
Does the OpenSceneGraph have a native file format?

From OpenSceneGraph-3.0 onwards we have new native file formats based on generic serializers that are extensible and support forward/backward compatibility, there is a .osgt ascii text file format, .osgx xml format and .osgb binary format. The extensible of the new formats enables end user application to add serializer wrappers for their own classes enabling them to extend the formats for their own application needs.

Prior to OpenSceneGraph-3.0 there were two native file formats, .osg for ascii, and .ive for binary. The .osg format is extensible and flexible but is slower and less compact than the .ive binary format, but the later suffers from not being forwards compatible and is not extensible so is only suitable for scene graphs that aren't extended by end user applications.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11791
Joined: Tue Mar 25, 2008 8:40 am

Re: 3D File Formats to use in creating aircraft

Postby Richard » Fri Jun 19, 2020 10:20 am

FlightGear 1.0 will support whatever plib can load - I don't know what formats are supported but probably only AC3D and some other really old formats.

Possibly you might be able to have some success using a command line conversion program to convert to AC3D - but generally the advice is to use Blender or AC3D as conversion programs often mess things up.

The talk of OpenSceneGraph is only relevant for FG 1.9 or later.
Richard
 
Posts: 772
Joined: Sun Nov 02, 2014 10:17 pm
Version: Git
OS: Win10

Re: 3D File Formats to use in creating aircraft

Postby Hooray » Fri Jun 19, 2020 10:31 am

Indeed, sorry about the noise - I completely missed the point that this was about FG 1.0
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11791
Joined: Tue Mar 25, 2008 8:40 am

Re: 3D File Formats to use in creating aircraft

Postby openflight » Sat Jun 20, 2020 2:42 pm

The discussion is about 3D modelling, and is about Flight Gear one as well as later versions, such as Flight Gear 2018, which I also have installed on my computer.
I made my template using the T38 model as a base, and here is what I found:

These formats do not load and run in FG1

.wrl, .x,

These formats work:

.3ds and .obj,

.obj loads on FG 2018 as well, with the material colors showing, but not sure how the shading and all that is going to work.

So it appears possible to use the .obj format with materials to build a model for FG versions.


The question is which version to develop for? I started a survey some time ago, and the results are here:

So best to make the model work in 2.0 and 2018, and the latest version.
openflight
 
Posts: 454
Joined: Fri Sep 16, 2011 11:14 am
Version: 1 2 2018
OS: Linux Mint 19.3

Re: 3D File Formats to use in creating aircraft

Postby D-ECHO » Sat Jun 20, 2020 2:46 pm

Out of curiosity, who participated in your survey?
User avatar
D-ECHO
 
Posts: 2058
Joined: Sat May 09, 2015 12:31 pm

Re: 3D File Formats to use in creating aircraft

Postby Hooray » Sat Jun 20, 2020 3:03 pm

you would need the corresponding OSG plugins (and their dependencies) for supported file formats to be recognized/supported.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11791
Joined: Tue Mar 25, 2008 8:40 am

Re: 3D File Formats to use in creating aircraft

Postby openflight » Sun Jun 21, 2020 3:24 am

D-ECHO wrote in Sat Jun 20, 2020 2:46 pm:Out of curiosity, who participated in your survey?


The link to the survey is below: so the lesson learned here is that users prefer the latest version, so I should test my models in the latest version possible:
I have 2018. FG1 can be used as a development environment.


viewtopic.php?f=42&t=21859
openflight
 
Posts: 454
Joined: Fri Sep 16, 2011 11:14 am
Version: 1 2 2018
OS: Linux Mint 19.3

Re: 3D File Formats to use in creating aircraft

Postby D-ECHO » Sun Jun 21, 2020 3:43 am

Thank you!
User avatar
D-ECHO
 
Posts: 2058
Joined: Sat May 09, 2015 12:31 pm

Re: 3D File Formats to use in creating aircraft

Postby wkitty42 » Sun Jun 21, 2020 2:33 pm

openflight wrote in Sun Jun 21, 2020 3:24 am:The link to the survey is below:

that was five years ago... things could easily have changed these days...

openflight wrote in Sun Jun 21, 2020 3:24 am:so the lesson learned here is that users prefer the latest version,

that is pretty normal, actually...

openflight wrote in Sun Jun 21, 2020 3:24 am:so I should test my models in the latest version possible:
I have 2018.

agreed... with that version being LTS, that's better than not...

openflight wrote in Sun Jun 21, 2020 3:24 am:FG1 can be used as a development environment.

until you get to the point where old methods cannot be used in the newer FG and the newer methods simply do not exist in that extremely old FG... sure, basic things should still work but things like shadows and lights... well... doubtful...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 6444
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: 3D File Formats to use in creating aircraft

Postby Hooray » Sun Jun 21, 2020 2:51 pm

also, the upcoming FlightGear version is likely to become a cut-off point for a handful of legacy features for which we don't have people/contributors around to step up and migrate/port those to the new architecture that people are working towards
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11791
Joined: Tue Mar 25, 2008 8:40 am

Re: 3D File Formats to use in creating aircraft

Postby openflight » Mon Jun 22, 2020 12:35 am

What if your favourite aircraft from previous version does not load in the latest FG? Can users at least be requested to post the solution online? Or maybe a thread for this?
openflight
 
Posts: 454
Joined: Fri Sep 16, 2011 11:14 am
Version: 1 2 2018
OS: Linux Mint 19.3

Next

Return to Aircraft

Who is online

Users browsing this forum: No registered users and 1 guest