[prev in list] [next in list] [prev in thread] [next in thread] 

List:       flightgear-devel
Subject:    Re: [Flightgear-devel] Size limit of ac-files in FG?
From:       Rick Gruber-Riemer <vanosten () runbox ! com>
Date:       2021-10-08 18:03:58
Message-ID: 12361f9b-2b88-099e-5724-fb06d7ba325c () runbox ! com
[Download RAW message or body]


On 10/6/21 10:03 AM, James Turner wrote:
> 
> 
>> On 5 Oct 2021, at 20:37, Rick Gruber-Riemer <vanosten@runbox.com 
>> <mailto:vanosten@runbox.com>> wrote:
>>
>>> Good to know that I can exclude the size. And I can exclude the LOD, 
>>> because I can fly back and forth, in and out of the tile without 
>>> stuff happening.
>>> Even on info level the logs do not indicate any problem. I will have 
>>> to try with finer grained log levels and hope for the best. I am 
>>> quite stuck now.
>>
>> There is nothing on debug level. So I will have to find a way to debug it.
> 
> Can you verify if it's the individual AC files by loading them elsewhere 
> or in isolation?
> 
> I.e just put that .ac in some piece of ocean or similar. Then we would 
> know if it's file loading issue or something in the LOD/pager.
> 
> Kind regards,
> James
> 

After a lot of hours of experimentation and frustration - amongst others 
constantly recompiling osm2city only using buildings in some specific 
areas of a tile and making sure that every single area has been included 
incl. overlaps at more than one time - and then start FG and visually 
compare => I conclude:
* like it has already been indicated by AC3D not finding any problems 
with the ac-files: there is no problem in the files
* there is just a very noticeable exponential relationship between an 
ac-file disk size (or number of faces or whatever indicator FG uses to 
schedule) and the time it takes to load it. When the content is 20% of 
all buildings, it takes few seconds - when it is 50% it takes minutes - 
when it is 100% I do not even bother to wait.

My conclusion is that reducing the number of nodes in the scene graph by 
reducing the number of ac-files generated by osm2city does not pay off 
at all, because these larger files do not get loaded in due time (or 
almost "never" on a desktop computer with many CPUs, abundance of memory 
and a 3 year old 6GB NVIDIA graphics card). The radius feature of stg 
entries is nice for large areas, but it does not help.

So my conclusion is to throw away again all "optimization" to generate 
tile-size ac-files and chop them off as before into minor quadrants 
(e.g. 4000m*4000m).

Which leaves me with 2 questions, for which I would love to get some help:
1) Is there a way to get out some statistics from FG regarding when a 
specific ac-file is loaded and how large (disk size, number of faces, 
...) it is? That way I could do some kind of optimisation (after all 
osm2city knows the number of buildings/faces etc. before deciding into 
how many ac-files they should be divided).
2) If one would convert osm2city stuff into OpenSceneGraph .osg ascii 
format or .ive binary format: would the behaviour still be similar or 
would it be worth a try?

Thanks in advance.

Rick


_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[prev in list] [next in list] [prev in thread] [next in thread]