3d models, how to produce them in an understandable way

[willemjonathan]

Hi everyone.

I dearly wish to make 3d models for FG as i find it quite empty and like to contribute.

But...

I spend hours and hours reading about how to do it and it just is way to difficult to understand all these helpfiles,
they never explain anything complete and you always needs scripts to install without ever an explination how to do it.

I also search a free way to do it. But i cant seem to find how to do it.
I just read somethign about only creating in xml instead of al that energy in ac, without getting there, would that be a possibility ?

I think it is very demotivating, as not everyone is an IT person. I say this because you probably would get a lot more people joining
scenery efforts if the info would be more clear. I hope this is not offending ?

If anyone can explain me clearly how i can export a 3d building from a free program in a simple way to an file format i can upload on the scenery database,
I could start helping to build this world :p

greetz

[Johan G]

Sorry for a long answer.

TL;DR: Unfortunately you are likely stuck with paying for AC3D or struggling with Blender plugins.

Unfortunately instead of using the now rather common Wavefront .obj file format FlightGear is a bit stuck on using the AC3D .ac file format. My guess is that we used it because X-Plane used it when we got more serious about scenery. We use files for airport layouts, navigation aids etc. that for long was was used and partially developed together with the X-Plane community.

The problem with the .ac format is that quite few 3D modeling software support it these days. Back when I actually modeled things to use in FlightGear I used a by then already old Blender 2.49b that had native support for it. As Blender is quite popular, and since it have since long dropped support for the .ac file format, some aircraft developers in the FlightGear community produced a few plugins for Blender that could import and export models. I have not tested these myself, but I see that while many seem to have no problem, there is also those ho struggle with them.

[DFaber]

Unfortunately instead of using the now rather common Wavefront .obj file format FlightGear is a bit stuck on using the AC3D .ac file format.

We use it, because we can animate it. We can have any object of the 3D-Model move, rotate or translate as we need to. FlightGear can load obj files, but they lack the capability to be manipulated as we can do with AC3D files.

If anyone can explain me clearly how i can export a 3d building from a free program in a simple way to an file format i can upload on the scenery database,
I could start helping to build this world :p

Get the latest Blender and the scripts that Johan mentioned and you have everything you need. If you want to use another 3D-Editor which lacks an AC3D Export, Blender can import obj files and export to AC3D.

Greetings

[Johan G]

FlightGear can load obj files, but they lack the capability to be manipulated as we can do with AC3D files.

Ah. Thanks for the clarification.

[willemjonathan]

okay ppl, thanks,

i installed a newer version of blender, i couldnt install those older scripts for my somewhat older blender version but the latest script for blender i could install, it seems it works to export, although i will still have to test it out, i have some progress made now

lets see if this works out....

[Richard]

We use it, because we can animate it. We can have any object of the 3D-Model move, rotate or translate as we need to. FlightGear can load obj files, but they lack the capability to be manipulated as we can do with AC3D files.

This isn't quite true - FlightGear can load and animate any format that is supported by OSG; in fact .ac support is provided by an OSG plugin.

From memory I think that formats other than .ac (and possibly .obj) don't support certain things related to effects or materials but I can't find the code at the moment. Using only the following formats is probably safe because we have the necessary logic to translate the axes into the FlightGear convention.

• ac
• obj
• ive
• osgt
• osgb

So basically we use .ac format files because they are quite a good, well documented format, that Blender can export nicely (with the appropriate plugins).

[DFaber]

Using only the following formats is probably safe because we have the necessary logic to translate the axes into the FlightGear convention.

• ac
• obj
• ive
• osgt
• osgb

I tested obj export from one of my Aircraft before posting. The Model loaded, there were issues with texture and it exported all parts of the model instead only the visible ones. Most important, none of the Control Surfaces moved. I didn't look into it too deep and checked the model names in the obj file, but - at least with Blender - the obj Export is not usable for Aircraft Development.
I'm well aware, that a skilled Person could bring either the OSG Plugin or the Blender Exporter or both to a state that it actually is usable, but right now it isn't.

Greetings

[willemjonathan]

ppl, i am trying to produce my first buildings, but noticed that with the latest blender and the latest script for that blender version (2.82) when i export some simple changes into the basicfile im already up 500kb..... im new to all this but a design i made is already around 1000. I noticed the script gives many options before saving, which is do not understand all of, i know i dont have to check the double facing there in the export script options, but is a standard blender file still having double faces ? any advise welcome, i didnt use texture yet.

also i noticed on the worldmap, i was surprised to see many blue circles in ghent for example, a city in belgium, as i never see any building when overflying it....does it mean they are invalidated for now ? and something needs to be updated ? or that my flightgear isnt properly set.

and putting new static models in belgium, will that create problems with os2city ?

thanks for every assitance.

[mk2]

Hey.
Not to blow my own horn, but I started a thread to help modelers by gathering information in the same place. The thread is at https://forum.flightgear.org/viewtopic.php?f=5&t=37282&p=366034#p366034.

For example, you might want to add the command line I listed in the beginning. I went to the same thing - in reality many buildings have already been made and are being uploaded weekly (not by myself). The main post assumes some familiarity with modeling for 3D games, so it might not be perfect for complete beginners. I do intend to keep improving it though, so if it is not understandable feel free to ask.

Moreover, 500KB does sound like a lot. My latest model ended up less than 200KB altogether. Model is not very simple either: https://scenery.flightgear.org/app.php?c=Models&a=view&id=7795, and has 1400 faces (minus 1 bridge that was not included). For now I wouldn't know what would be causing the size on your side, but if you don't have textures on it then it really shouldn't be that large. You can use pasteall.org to upload screengrabs for a few weeks, so people can have a better idea.

[willemjonathan]

i tried your suggestion, here is the example of what i am doing as a first try, it is the police tower in antwerp...
but i noticed that the files get big very fast, in the first steps, not the last detaillist steps....which is strange no....it s not a history that is being saved in it i hope.


im going to check your thread


i noticed this line works, --prop:/sim/rendering/static-lod/bare=20000 , but what does it mean ? and why is not automaticly done ?

https://pasteall.org/pic/b6920b074fce4d ... e4a51f3ec0

[Johan G]

Some quick notes on the model. It is almost universally better to implement things like the structures around the windows and on the sides of the top of the building not in the model, but in the texture for the building. In essence having them modeled only makes sense if people regularly would be really close to the building (like for example airport terminals and oil rigs).

[willemjonathan]

yes but antwerp airport is a small airport, the land is flat, but it has a rich history in its buildings, so its perfect to fly around with a small plane,
up close to the port and the old city... so some detail would be really nice there as the country land is a bit boring... any way i decided to start over with a water tower first for mechelen (140 metres) to practise with that first lets see if i can figure out textures in blender also...
i do wonder why so many buildings were invisble to me until i added that scriptline in FG..

[amue]

Using only the following formats is probably safe because we have the necessary logic to translate the axes into the FlightGear convention.

• ac
• obj
• ive
• osgt
• osgb

Beware, FlightGear handles the axes differently depending on the file format.
In the obj format the axes are identical to the FlightGear axes.
In the ac, ive, osgt and osgb the axes mapping is as follows: x_file = x_FlightGear, y_file = z_FlightGear, z_file = -y_FlightGear.
Fortunately the ac plugin for blender takes care of it (by setting the import/export axes options "Forward = -Z Forward" and "Up = Y Up"). You can model in "FlightGear axes" and while exporting the axes are transformed accordingly.

[wkitty42]

i do wonder why so many buildings were invisble to me until i added that scriptline in FG..

because those objects erroneously use range animation linked to that property when they should not use any range animations at all... when that property was removed for the newer LOD code update, it caused all those objects to not be shown at all... so there's actually two errors/flaws/defects with those objects... first, they should not be using range animations at all... second was tying those range animations to that property which could go away at any time as the LOD system is refined and made better...

[Hooray]

This topic probably contains quite a bit of useful information, which should ideally be added to $FG_ROOT/Docs, the FAQ or the wiki respectively, any takers (if not, then please don't complain about the use of quotes )?