Board index FlightGear Development New features

Use Other 3d file formats in flighgear

Discussion and requests for new features. Please note that FlightGear developers are volunteers and may or may not be able to consider these requests.

Use Other 3d file formats in flighgear

Postby www2 » Fri Jan 19, 2018 12:14 am

After a discussion on the on discord i have done a test loading a Wavefront (obj file) in flightgear and here is the result:
Image

Here are the instructions for the test:
1. open blender and create a clean scene out of any objects.
2. import a AC3D file.
3. rename all mesh to the same name as the corespondent object (i think this is a bug in the AC3D importer script)
4. export to Wavefront obj
5. rename the file name from .ac to .obj
6. load flightgear
www2
 
Posts: 254
Joined: Thu Apr 16, 2009 1:58 pm

Re: Use Other 3d file formats in flighgear

Postby vanosten » Sun Jan 21, 2018 8:14 am

What is the reasoning behind opening up the possibility for other file formats? Are other formats more efficient to load or any other reason for your work? I am asking because osm2city has pretty large meshes and if there is a more efficient format, then that might be a good consideration.
Maintaining osm2city. Contributing with ground attack stuff to the OPRF FlightGear military-simulation community.
vanosten
 
Posts: 410
Joined: Sat Sep 25, 2010 5:38 pm
Location: Denmark - but I am Swiss
Callsign: HB-VANO
Version: latest
OS: Win 10 and Ubuntu

Re: Use Other 3d file formats in flighgear

Postby Thorsten » Sun Jan 21, 2018 9:01 am

I think whether this works or not depends on with which options the OSG model loader is compiled - I'm not sure how much control we have over that (?)

We have at one point tested binary formats (based on the notion that a binary native OSG model format would offer advantages) and the result were mixed - some people did see substantial improvements in loading time, others did not see anything.

The downside of binary formats is usually that they're very GIT unfriendly and create huge repository sizes, because every small change requires that the whole binary is stored again.
Thorsten
 
Posts: 10831
Joined: Mon Nov 02, 2009 8:33 am

Re: Use Other 3d file formats in flighgear

Postby www2 » Sun Jan 21, 2018 1:31 pm

@vanosten
Even i have done our of curiosity this have impact in the work flow a spatial we don't need to have install an AC3D exporter and in the future this open the door to a format that suport animation.
www2
 
Posts: 254
Joined: Thu Apr 16, 2009 1:58 pm

Re: Use Other 3d file formats in flighgear

Postby Thorsten » Sun Jan 21, 2018 1:42 pm

and in the future this open the door to a format that suport animation.


Unless the OSG model loader automatically converts this into a matrix stack usable by FG, I don't think this will work.
Thorsten
 
Posts: 10831
Joined: Mon Nov 02, 2009 8:33 am

Re: Use Other 3d file formats in flighgear

Postby DFaber » Sun Jan 21, 2018 3:46 pm

Thorsten wrote in Sun Jan 21, 2018 1:42 pm:
and in the future this open the door to a format that suport animation.


Unless the OSG model loader automatically converts this into a matrix stack usable by FG, I don't think this will work.


Maybe he thinks of a format that can do Vertex animations like MD2: https://wiki.blender.org/index.php/Dev:Ref/Outdated/Resources/File_Formats/MD2.

Could be useful for scenery Objects which move.

Greetings
Detlef Faber
FlightGear Development:
http://flightgear-de.net

German FlightGear Forum
http://forum.flightgear-de.net
DFaber
 
Posts: 687
Joined: Fri Dec 01, 2006 7:51 pm
Location: Aachen, Germany
Version: GIT
OS: Linux

Re: Use Other 3d file formats in flighgear

Postby Thorsten » Mon Jan 22, 2018 6:41 am

Maybe he thinks of a format that can do Vertex animations like MD2


Would that work in FG? I guess it all depends on what OSG is going to do with it, not really what the format supports.
Thorsten
 
Posts: 10831
Joined: Mon Nov 02, 2009 8:33 am

Re: Use Other 3d file formats in flighgear

Postby DFaber » Mon Jan 22, 2018 8:07 am

Thorsten wrote in Mon Jan 22, 2018 6:41 am:Would that work in FG?


it does partially, I made a quick test with an md2 (Quake 2 format) Model from http://www.telias.tk/models_md2_menu.html yesterday. OSG shows the Vertex Animation out of the box. The Model Size is hundred times too big, but that's an exporter issue. md2 files can contain multiple animations, but I doubt that calling them works with FG. A single recurring animation is already possible.
However, md2 isn't supported by recent Blender Versions anymore. Blender 2.5 is reported to work, but I haven't tried. The newer md3 format is not supported by OSG.
Detlef Faber
FlightGear Development:
http://flightgear-de.net

German FlightGear Forum
http://forum.flightgear-de.net
DFaber
 
Posts: 687
Joined: Fri Dec 01, 2006 7:51 pm
Location: Aachen, Germany
Version: GIT
OS: Linux

Re: Use Other 3d file formats in flighgear

Postby abassign » Mon Jan 22, 2018 4:16 pm

I read this article with great interest and I wanted to do some tests. Meanwhile, I noticed that OSG has its own binary format called ".ive", this format is recommended as it is faster in loading.
For my tests I used a rather complex object that reproduces the Bendix type J8 used for the FIAT G91-R1B, but also installed in many other aircraft of the 50s and 60s of the last century.

The gauge was made by Freecad, and then exported with the obj, the size of the freecad file is 1.4 MB which becomes 3.3 MB when exported to OBJ.

Image

Unfortunately Freecad uses different units of measure, which exchange the meters (used by Blender) in mm (used by Freecad). So I had to rescale the file using Blender.

Another problem is that Freecad converts objects into meshes by adding the postfix "(Meshed)" so the name of an object becomes: "xy_x" -> "xy_z (Meshed)". Blender when it converts the file to OBJ instead changes the name: "xy_x" -> "xy_z_ (Meshed)", which replaces the space with a "_". At this point I have to edit the names contained in the file with an editor or edit the XML. The decision must be taken once and for all, is simple solution and works well.

This is the image that was obtained through the .ac file. The fact that it looks so dark is due to the application of the shadows through an "Interior Shading" effect.

Image

Instead the result obtained using the .obj file resized by Blender (nothing else has been done) is this:

Image

Actually it seems better, but I doubt that the "Interior Shading" effect is working!
which instead is present in the other gauges that surround the image. Honestly I do not understand the reason for this problem because the file will then be converted to .ac, always in Blender, and the result that you see in the previous image. Freecad should not include its attributes, but it is probably a problem related to the fact that they are missing MATERIALS! f you look at objects in Blender, you can see that no one has a material definition. This could be the basis of the problem. But the materials are fully defined XML (which in fact prefer) even if it takes a little patience.

Reading the online manual of "openscenegraph" I found that there is an OBJ converter in a binary OSG format called ".ive":

http://www.openscenegraph.org/index.php/documentation/guides/user-guides/55-osgconv

This binary format, says the manual, is very efficient as it does not require any conversion and therefore its loading is immediate. Intrigued I tried to use this command, I loaded it on my Linux system Kubuntu 17.10 (I took version 3.4 of the command) and I did the test by entering the scale and the translate (necessary because the scale must be followed by a redefinition of the centers of reference).

This is the command (I used the obj file produced DIRECTLY by Freecad):

Code: Select all
osgconv -t 0,0,0 -s 0.001,0.001,0.001 j8.obj j8.ive


This is the result:

Image

The object has kept all its automation etc .. There is always the strange behavior with the effect, but at this point I do not know if it's correct this version or the other in .ac ... I will see to deepen.

This test has several important consequences:

1. You can build 3D objects in FreeCAD, and import them directly to Fgfs without using Blender.
2. You can use the OSG binary file, making this time probably faster loading of complex objects.
3. I do not know how stable the OSG binary format over time is for future versions, but nothing prevents you from automating this process in the FGFS loader. This way you could have a real improvement in loading performance for larger files.
4. Exporting files from FreeCAD to blender via OBJ does not involve materials, this feature can only be managed via XML. But this is a design choice, in the G91-R1B objects use only one type of material (type 0). Everything else is obtained through XML transformation, the performances (now that we are about 2/3 of the project) do not seem to have a particular reduction.
abassign
 
Posts: 791
Joined: Mon Feb 27, 2012 5:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2018.3
OS: Linux Mint 19. x

Re: Use Other 3d file formats in flighgear

Postby Thorsten » Mon Jan 22, 2018 4:22 pm

3. I do not know how stable the OSG binary format over time is for future versions, but nothing prevents you from automating this process in the FGFS loader. This way you could have a real improvement in loading performance for larger files.


As I said before: We have at one point tested binary formats (based on the notion that a binary native OSG model format would offer advantages) and the result were mixed - some people did see substantial improvements in loading time, others did not see anything.

(I might add that the result the test was a general feeling that it's not worth the trouble to have a binary format on the repository).

And I would generally not be surprised if other formats break FG effects in one form or the other.
Thorsten
 
Posts: 10831
Joined: Mon Nov 02, 2009 8:33 am

Re: Use Other 3d file formats in flighgear

Postby paju1986 » Mon Jan 22, 2018 4:33 pm

Maybe will be nice to use a format that is supported by blender out of the box without the need of plugins.
paju1986
 
Posts: 189
Joined: Sun Oct 30, 2011 7:42 pm
Location: Badajoz (Spain) - LEBZ
OS: Debian Testing

Re: Use Other 3d file formats in flighgear

Postby Thorsten » Mon Jan 22, 2018 5:50 pm

I can say with some confidence that *.blend files are a repository nightmare - they'll just crank the size up sky-high. We have 3.8 GB of binary history of blender cockpit mesh development on the Space Shuttle repository - for an end result that's like 150 MB of direct download.

So unless there's a *very* good advantage to the format, the downside will be substantial.
Thorsten
 
Posts: 10831
Joined: Mon Nov 02, 2009 8:33 am

Re: Use Other 3d file formats in flighgear

Postby abassign » Mon Jan 22, 2018 6:15 pm

Before feed too much hope, I wanted to test a gauge with the texture ... the result is certainly not very nice ...

With actual .ac version:

Image

When converted into .ive format ... unfortunately many things disappear, the effects and written stretched on a transparent support.

Image

I think the reason is the same for which the effects do not work ..
I also tried to use the OBJ file format used to convert to .ive format, but I got the same result.

We very much we use the technique of the transparent support on which is inserted the written order to modulate its illumination and obtain nocturnal lighting effects with typical UV lamp of these tools.
I suspect a defect in exporting the OBJ file from the original Blender file, unfortunately I can not insert textures on objects in Freecad, at least for now, if someone has found a technique to do it, I would be very grateful to know it.

I think the technique of converting into binary is very interesting, but should have further tests.
My biggest concern is precisely related to the lack of effects on the surfaces produced in this format. Can anyone do some further tests?
abassign
 
Posts: 791
Joined: Mon Feb 27, 2012 5:09 pm
Location: Italy (living 5 Km from airport LIME)
Callsign: I-BASSY
Version: 2018.3
OS: Linux Mint 19. x

Re: Use Other 3d file formats in flighgear

Postby wkitty42 » Tue Jan 23, 2018 4:28 pm

i don't want to sound bad or ugly but i don't understand... testing has already been done and discussed in the developer's mailing list... why are we testing again and (apparently??) reinventing the wheel? it is almost like too many cooks with a pot of stew :(
"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: 5568
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5


Return to New features

Who is online

Users browsing this forum: No registered users and 6 guests