The Austria Scenery Project

[merspieler]

Okay...

I've asked cause currently there are collisions of this scenery with osm2city... if you've uploaded it into terrasync, let me know, then I'll rebuild the tiles to fix these.

[litzi]

Thank you. Anyway, I will not submit anything without prior consultation. I encountered two problems already, on which I might need some support:

(1) do I really have to rebuild the whole scenery tile(s) the airport is situated in, after editing the airport layout? This means to download the full DEM and landclass definition datasets and rebuilt everything with terragear. Or is there a way to just produce the airport model without having to do all the other stuff?

(2) all forum recommandations advise to put only one building model per object file and not to group buildings in one .ac file. However, I found it improves performance to have just about 10 groups of about 10 buildings each, instead of approx. 100 individual building models. How strict is the rule really, to put just one building per model file?

Martin

[vnts]

Some of the buildings are real heavy so fps for loww and lows break down to 12 fps.

Thank you. Anyway, I will not submit anything without prior consultation. I encountered two problems already, on which I might need some support:

[..]

(2) all forum recommandations advise to put only one building model per object file and not to group buildings in one .ac file. However, I found it improves performance to have just about 10 groups of about 10 buildings each, instead of approx. 100 individual building models. How strict is the rule really, to put just one building per model file?

If you need to increase CPU bound performance at airports, there is only one way. Each time the CPU (FG rendering) has to communicate to the GPU [e.g. to change state like switching to another texture atlas or issue draw commands for many objects] there is a huge slow down. That's in addition to the tree of objects OSG uses growing larger - so OSG takes much longer in CPU side to go through all the objects to determine what could be in view and then draw them. The fastest way is to bunch as much vertex data together as possible, use one effect/shaders, use one set of textures/lightmaps, and then tell the GPU to whizz through them with one draw call. The CPU/GPU can handle a reasonable number of objects so having a small number of draw calls for different objects is ok , but if possible things should be bunched together. OSM2City uses meshes that are 4km big for example. (I don't know if the way AC files content is internally bunched together and rendered might is optimal either - e.g. if everything in a mesh is bundled together into a set of vertex buffers and there are no unneeded uniform/state changes).

Having too many small objects ends up with the the KBOS effect where even reasonably recent CPUs get low CPU bound FPS, and it's a no-go zone for people with older systems and laptops.

The 2012 (?) advice in the forum to limit object sizes to 2mb (and try to keep buildings to 0.5 MB) is an extremely rough measure from an older era - it's intended to encourage people to optimise their meshes and not use too large textures (and compress PNG textures properly). The measure used is extremely crude and isn't ideal for airports or landmarks - file size doesn't consider how large a building is, texture sizes needed depend on how large something is and how close the camera gets to it, and people spend much longer or get closer to airport buildings or landmarks so the modelling quality affects the experience more.

xDraconian is handling reviews IIRC (and probably D-ECHO and Catalonic) [1] and they should be aware of optimisation so it runs well on older hardware - so you should probably get in touch via the review process (or just PM xDraconian on the forum) to submit combined models to TerraSync.

Request: Permission to use scenery LOWW for flight gear
Gerhard Scholz <oe3gsu@x-plane.at> April 9, 2021 at 4:03 am
Reply to: oe3gsu@x-plane.at
To: Bernhard
Hello Bernhard!
As long as the scenery is passed on free of charge, we have nothing against it.
But please add the credits, THANK YOU!
vlG Gerhard

It's probably best to just get them to explicitly license it under GPL v2 (and any later version).

FG has always been free and available for download, but the Flightgear store does sell the DVD for people with limited internet to cover the price of packaging and sending it to them (X-P also charges far more, and is a non-free for-profit sim).

The way I would explain it to them if they are concerned about being non-commercial:

FlightGear is a free project obviously, and developed by volunteers. Everything will be downloadable for free. But to be distributed through TeraSync it has to be under GPL. It's better to get explicit permission for FlightGear to use under GPL2 and later.

If their license is not GPL, I guess any FG scenery can be added alongside custom sceneries people can download separately - but the amount of people that get to enjoy their scenery will drop off massively (there's something like 400-500k downloads of FG per year on sourceforge alone).

The issue is that technically GPL allows people to charge for things like distributing physical copies - which the flightgear store normally does for people who don't have a fast internet connection by sending them the entire world scenery on DVD/USB - for a small fee.

So it's better to get explicit permission under GPL2 (or "GPL version 2 and any later version").

There's no practical chance that their scenery will be officially integrated into a for-profit simulator - because GPL requires that everything else be GPL as well, and people can request sources of GPL material etc. In fact there will likely be far more people using X-Plane and spending far more money on X-P as a result of their addon support than FG sales through the store - and FG is not for-profit unlike X-P. For instance MS-FS can't take their GPL work and integrate it into their scenery, without making the rest GPL. Eventually scenery art will become obsolete as the standard of graphics improves, so there's a limit on how long people can make a profit from scenery anyway.

Kind regards

[litzi]

Thank you very much for the extensive answer. So in summary the recommendations are:

1. yes, groups of reasonable size are acceptable for airport buildings

2. ask for explicit GPL2 licence from the original x-plane authors

I will continue to work into these directions.

Kind Regards

[Catalanoic]

"The 2012 (?) advice in the forum to limit object sizes to 2mb (and try to keep buildings to 0.5 MB) is an extremely rough measure from an older era - it's intended to encourage people to optimise their meshes and not use too large textures (and compress PNG textures properly). The measure used is extremely crude and isn't ideal for airports or landmarks - file size doesn't consider how large a building is, texture sizes needed depend on how large something is and how close the camera gets to it, and people spend much longer or get closer to airport buildings or landmarks so the modelling quality affects the experience more. "

You are right, the problem is, some people (me too) tend to place unnecesarily good textured and high poly objects alltogether and in quantity so it can overkill most GPU/CPUs and eat most of your RAMs, even with high-end machines. Experience and time organizing it so you can optimise keeping all your quality is what really difficult is but you know, most projects are made by individuals, not profi-ready teams. Hard to solve, but I think, if the infrasctructure was able to easier to modify and correct, like contribute to Wikipedia or any similar project, most of these problems would be already solved and the limits about these objects/textures further

[merspieler]

if the infrasctructure was able to easier to modify and correct, like contribute to Wikipedia or any similar project, most of these problems would be already solved and the limits about these objects/textures further

It's quite easy to modify objects... go to the scenery portal open the details of the model you want to edit, download it as .zip do your modifications and reupload it.

Even I as a total modelling noob was able to fix some minor things that bugged me...

[vnts]

You are right, the problem is, some people (me too) tend to place unnecesarily good textured and high poly objects alltogether and in quantity so it can overkill most GPU/CPUs and eat most of your RAMs, even with high-end machines.

(This is more a wider topic now, and maybe the thread could be split?)

Yeah, it's tempting - there should be some guideline/examples/automatic warnings/rules, or scaling at runtime on older hardware (scaling should allow models to eb a bit more future proof as harware will get faster).

It's the textures sizes that need attention first/more. GPUs can handle a (reasonably) high polygon count. Vertices in AC files are in human readable text and don't take that much space in RAM/VRAM - they also compress well in TerraSync (if you want to reduce AC file size on disk it's possible to round off vertices to a 1cm or 1 mm grid in blender).

Higher res textures and more vertices won't affect CPU-side boundness (unless there's not enough VRAM and the GPU caches to RAM). They'll mostly cause GPU-side boundness. What causes CPU bound slowness and FPS drop in busy areas is having too many models, or too many state changes (maybe also if content in AC files is sub-optimally arranged by FG rendering - don't know if that's the case).

In any case, it should be fine to combine models in existing areas like KBOS into 1 or a few objects - as those are known to be reasonably well optimised in terms of textures (KBOS is CPU bound even on reasonably fast CPUs, and is a no fly zone for older/mobile systems).

Ideally as much of the geometry should be bundled together as possible. OSM2City happily bundles 4km meshes. Textures/lightmaps for buildings around a busy area like an airport should be combined, so it gets drawn in one call / with no extra state changes. In general the same 'type' of textured surface should be bundled in one object where possible. It's fine to combine things, even if it means doing different parts of buildings in an area as different objects. For example if parts of a airport buildings like the roofs has a light map and the rest doesn't it's possible to do roofs and walls/interiors of buildings in two objects, - or the fastest way would be to just use a small blank area of the lightmap for some parts of buildings and do everything in one object. If roofs of buildings have a separate specularity to walls/interiors doing those as 2 seperate objects is justified as it prevents a state change.

Experience and time organizing it so you can optimise keeping all your quality is what really difficult is but you know, most projects are made by individuals, not profi-ready teams. Hard to solve, but I think, if the infrasctructure was able to easier to modify and correct, like contribute to Wikipedia or any similar project, most of these problems would be already solved and the limits about these objects/textures further

With regards to textures - there are several ways of addressing the issue.

Firstly, With regards to VRAM and GPU memory latency - recent era GPUs have many GBs of VRAM, and higher end models have 8 GB+. In the coming 5+ years both VRAM memory latency and amount of VRAM will improve.

- First approach might be to reduce the size of texures on GPUs that ahve limited VRAM or have VRAM latency issues. Textures are already downscaled if a texture exceeds the GPUs max texture size. There could be options for downscaling depending on category of object. Example Object categories: aircraft (cockpit interiors need to be readable), environment (uses a reasonable amount fo textures so high payoff for leaving this turned up), 3d scenery objects (maybe a OSM category as OSM doesn't use much textures), airport objects and landmarks. Each category could just be a two settings, using a tick box (for recent era and older era GPUs).

- Second approach might be to have different categories of scenery objects with different specifications on how stretched out textures are. These could have different automatically imposed size limits, or just have different guidelines people could follow.

Categories of scenery objects could be identified based on filename - e.g. *-viewed-close (airports, helipads, carriers), *-viewed-close-clutter (airport ground clutter which could aslo be optional on slower machines), *-landmark , *-viewed-medium , *-prominent-medium-range (similar to viewed-medium for objects that stand out a bit because of colour or shape, or just because the terrain around them is barren), *-viewed-long (low textures for generic buildings that don't stand out and are numerous) .

It's possible to specify how stretched textures could be - e.g. 1 meter = x pixels. It's also possible to provide some example objects and textures that people could use as a guideline.

It's also possible to find a way of telling a modeller how stretched out the texture is when uploading and check it against different categories - blender can probably tell someone this anyway by some option or a plugin.

- Third approach would be for scripts to automatically combine buildings/objects in an area where possible - and have people do smaller objects. Something like this is/was planned for the next world build if I recall correctly? using STGmerge scripts. The different object categories and guidelines are still useful for reducing VRAM use / latency.

Kind regards

[litzi]

Okay...

I've asked cause currently there are collisions of this scenery with osm2city... if you've uploaded it into terrasync, let me know, then I'll rebuild the tiles to fix these.

I have now finalized the upload of all relevant LOWW building groups to the scenery server and they are already available via TerraSync. I will just fix some minor things and add the jetways in the near future, however a osm2city rebuild for that area could already be done now.

[merspieler]

Will do... rl is really busy rn... so if I forget, pls ping me

[litzi]

OK - LOWW is completed and is now available through TerraSync. It's quite "frame rate friendly" too, as far as I can judge.

Thanks to merspieler who rebuild the osm2city - buildings for the affected tiles, to powoflight for the original X Plane model conversion and to Johann Stigleithner for additional building textures! And of course a big thanks to the original X Plane authors who made their models available under GPL: wuseldusel, danielman, Patrik W. and oe3gsu !