Pennsylvania, New Jersey, and New York City

[V12]

Yes, only Manhattan is the problem. Over other places fps was 30-40.

[Thorsten]

Check CPU and GPU usage :

Since neither are used very much, you really should check your configuration... (given that often you see framerate issues others don't, I'd really recommend it at some point - but hey - if it'd work, you'd have one reason less to complain... )

[wlbragg]

@montagdude
My previous comments on the New York City scenery were based on the images and video on this thread. After installing it and seeing it in the sim, all I can say is WOW, that's impressive. Well done!

I'm only getting 14fps with everything at the max which is flyable but not as smooth as I would like. This is in the dev version of the AirCrane and near Central Park. But still, this is a testament to oms2city and the terragear tool chain.
It's not that far off of what I am getting with MS2020 and the frame rate is worse with ms2020, pretty much un-flyable with MS2020 at max settings.
I am so impressed with how far osm2city has come. With a few professional artists on our payroll, I think we would be right up there with the paid programs. Even without it certainly shows the talent of our developers, all the way around, from tech to art.

[vnts]

Looks like the right terrain. I'm guessing you intentionally left out all the osm2city stuff for this screenshot though?

If you mean the screenshots towards the bottom looking at textures, yes. Trees and structures was off to show terrain. For some of the building screenshots I pressed reload and it was in the process of loading buildings as that showed problems - the AC files take a lot more time to read than instanced shader building list files (and building lists would load even faster if they were in binary).

I brought this up before in one of the osm2city threads. I was told that it puts multiple basic buildings on top of each other to represent more complex buildings. Unfortunately, the textures often don't line up and you get z-fighting issues like this. I don't know if there is anything being actively done to fix that, but vanosten is aware of it.

Hm, some of those buildings had ground level textures (with trees) instead of the same wall textures as skyscrapers, and there were floating buildings or buildings hanging out(?). Skyscrapers certainly would be built from a few blocks, but this seems like a bug/problem? The skyscrapers were placed by OSM2City, and not just scenery objects that are probably badly optimised, right right?

eastern-us-town2 is a new one I added for this scenery. I actually debated not including it due to the issues you mentioned. I did try to bump up the saturation a bit, but like you said, it's still not great. Thanks for the tips on improving it. By the way, if anyone is good at this stuff and wants to help, I would gladly accept it. I'm not much of an artist myself.

I'm not a digital artist either, I'm learning as I go along .

The thing I'm lacking is an idea what a truly representative town texture is for that general region to match colours to - that is, typical colours/hues that would be seen by the eye on an overcast day with dry ground in summer. If you have a non-GPL photo on flikr or somewhere that is representative of the intended colours/hues I can try to play around to match it - having that knowledge/subject research is the most hard to replicate or time consuming bit (gsagostinho did the existing US textures a while ago).

There doesn't seem one way to correct this washed out look, or to remove shadows, according to google. If anyone knows what is appropriate for this type of photo please point mention it.

Playing around with eastern-us-town2 in GIMP:
- Selected shadows ok, with "Select by color tool" and select by Lch lightness, using a small threshold value, and clicking on a dark shadowed area.
- Made greyscale-ish shadows a greenish hue by Colors > Map > Rotate colors. Under Grey Handling, increase grey threshold, change hue to green.
Then:
Colors > Exposure. Exposure = 0.1: link
Colors > Exposure. Exposure less than 0.1: link
Colors > Exposure. Exposure = 0.1. Select by color with composite, select grass, Colors> saturation to desaturate a bit. Select shadows again, delete, fill using Colors > Enhance > heal transparency (needs resynthesiser), fill inwards with 50 context pixels (link) and 7 context pixels (link)

The problem with large shadows is not knowing which is shadowed tree, and which is grass. Once there's a procedure for removing shadows for terrain from aerial photos it can be added to the wiki page (link) on getting textures from photos - I added things I've found out so far, and more general info last week.

I think at least the crop textures would be good to include.

They have a bit of washed out look that should be fixed to the level of other textures, so all textures and soil colors blend in.

One way I found to view various GIMP effects on textures quickly inside the sim was to reload textures. There doesn't appear to be a button for this as far as I can see(?). A faster way than restarting is to change the texture name in a materials file to something, then reload materials/scenery, and change it back again and reloading materials/scenery. FG won't re-load textures if the file name remains the same.

Another issue with the town textures is that I don't think I did the relief map correctly. I tried my best to emulate what is in the other ones, but when I tried turning off buildings and using the shader, I didn't see any raised areas with my town2 texture. I thought I had verified that it worked previously when I created the town1 texture, but I will have to check again. If that one works then maybe that one could be merged too.

Not sure about the urban shader. Haven't used it much as it's not as good as 3d buildings, and the urban effect gets flickery even with NVIDIA driver settings turned up. It seemed to work on gsagostinhos system when he did the textures a few years ago. The urban shader is tech from an older era and gets turned off if any form of 3d buildings are on.

over Manhattan I achieved 10 fps. Check CPU and GPU usage :
https://i.imgur.com/mqnvMCL.jpg

Even with the unnecessary amount of buildings problem, wlbragg got 14 FPS on a slower/older system? As Thorsten said you don't appear to be CPU bound /or/ GPU bound. Check your FPS isn't throttled somehow (CPU thermal throttling due to dust, or capped power management settings?). CPU use is 6.5%. The CPU would need approx. 15 cores if FG was just maxing out one core (100/6.35). FG uses more than one core for driver, loading models, loading trees, etc. so even on a CPU with 16 cores you should see a higher utilisation than 6.35 when FG is CPU bound due to one core being maxed(?). I get 50-100% on a 4 core i5 as FG uses more than 1 core for loading etc.

There just aren't many buildings in view in that screenshot, so without the bug or whatever, you should get better FPS than in areas with a sea of buildings as happens in older OSM2City which runs ok. Reducing LoD:rough can help for people having issues.

Kind regards

[V12]

I used my standard config - bare lod 270 km, AW visibility limit 250 km. Will test with default setup 30 km. And yes, my CPU has 8 cores and 16 threads.
CPU is not throttled down, in commercial sim I have 25-30 fps over similar places, no problem 100% CPU utilization in Blender or videoencoder all night. Multithreading model is CullThreadPerCameraDrawThreadPerContext, because all other modes makes troubles with terrasync download in the storms.

AMD Ryzen 7 CPUs have poor single core performance in comparison with Intel Core. This fact is not visible in benchmark, only in real apps.

[GinGin]

Yeah we know V12 .
1000Th times you post with the same things about AMD.



Anyway, very very nice work .
I will test that end of the week with a Shuttle landing in Manhattan

[vnts]

I used my standard config - bare lod 270 km, AW visibility limit 250 km. Will test with default setup 30 km. And yes, my CPU has 8 cores and 16 threads.
CPU is not throttled down, in commercial sim I have 25-30 fps over similar places, no problem 100% CPU utilization in Blender or videoencoder all night. Multithreading model is CullThreadPerCameraDrawThreadPerContext, because all other modes makes troubles with terrasync download in the storms.

The default LoD:rough is 9km. Can set it shorter in Manhattan. The default LoD:Bare is 30km.

"my CPU has 8 cores and 16 threads". On my 4 core intel i5 the lowest utlisation I get is around 50% because of trees, buildings etc. being loaded. I only see buildings partially loaded in that screenshot, so CPU should have plenty of laoding. In Manhatten I get 50-100% utilisation. This is 2-4 cores worth. You should get 25%-50% with an 8 core CPU(?).

I'm not sure how CPU utilisation is reported when there's an set extra logical cores (The thread running opportunistically on the logical core doesn't have the same power.). Even if there were 16 physical cores, you should get 12%-25%(?). Getting only 6.35 implies that something else is wrong? You are also using an extra cull thread, so you should get even more utilisation? I only have DrawThreadPerContext and I see a lot more utilisation.

Intel having better single thread performance only affects FPS, not core utilisation. (My i5 is pretty old, and in recent years single threaded performance on both side have improved a lot.)

As for OSG multithreading mode, OSG selects it correctly in most cases, so it works ok out of the box (e.g. Windows and Intel). There appears to be a problem with OSG mode choice on some systems - only Linux & AMD Ryzen reported so far. James said a way to deal with it is to manually set at least DrawThreadPerContext in future [1].

Edit: what results do you get in Manhattan if SMT is switched off and CPU operates as a 8 core CPU? Also maybe try UFO to eliminate any interference from craft, and set lod:rough and lod:bare to defaults. Manhatten coords are: 40.783333, -73.966667 for anyone that wants to spawn in middle of city.

Kind regards

[abassign]

Unfortunately, FGFS uses cores in a very "particular" way as creating a decent multithreaded system requires the redesign of various parts. For example NASAL operates within the same main process, if you accidentally make an infinite loop in NASAL you block everything! I think that currently there are no programmers who have the courage to change the current code, there are already several stability problems and the changes make everything more difficult to follow. Personally I would opt to detach NASAL or rather to replace it with a different, better documented programming language and operate on the property tree with external processes, released from the main program.

I think OSG uses its own thread, I notice this from the fact that when the system loads scenario objects the CPU load goes from 100% to a more comfortable 200%. Of course, understanding how to better exploit OSG with the GPU and maybe distribute the load better between the two processing systems can be an advantage, but my considerations are very general, it would be better if you answered your question who actually modifies the kernel code. If I use X-Plane the system load goes to full on all CPUs and this makes a difference in performance. It seems that FGFS is made to save electricity, while all other simulators are made for racing.

However, the beauty of FGFS is that it allows it to be modified, perhaps there is already someone who is doing it also because this is the beauty of the Opensource project.

[Thorsten]

Okay, yeah - time to admit it. All FG developers intentionally try to make FG run as slowly as possible so that your computers can all save powers. We don't actually enjoy using the sim, we just like still images. And we intentionally block all optimizations so that it stays that way - so that nobody can run FG fast.

Sounds likely to you?

No?

At least that's what abassign is suggesting...

For example NASAL operates within the same main process, if you accidentally make an infinite loop in NASAL you block everything!

Well, if you program that way, you shouldn't complain - for most applications you actually need to synchronize Nasal with the sim, and for those where you don't, you can program differently.

there are already several stability problems and the changes make everything more difficult to follow

Actually you just made this up.

Personally I would opt to detach NASAL or rather to replace it with a different, better documented programming language and operate on the property tree with external processes, released from the main program.

Well, that will create the stability problems for sure, which is why the rest of us would not opt to do that - but you're free to use <insert exotic language of your choice here> instead of Nasal in your own FG branch

If I use X-Plane the system load goes to full on all CPUs and this makes a difference in performance.

Yes - the X-Plane developers realized that users really like to see full CPU utilization in the stats, so they took care to make sure you see that. The extra performance goes into solving more FDMs for AI craft (aka, goes waste for the actual simulation).

Yet people like it.

I guess FG would be better off by introducing some dummy Nasal loops just wasting CPU power - THEN everyone would really be impressed how well multi-CPU settings are utilized.

(People who've never bothered to parallelize problems often have quite... interesting... ideas about how useful the exercise actually is...)

[V12]

With default LOD I had 20-24 fps. Maximum CPU utilization was 13-15%.

[montagdude]

Well that sounds pretty good then. Here I was thinking that even if I bought hardware as good as yours I'd still only get 10 fps in Manhattan.

[V12]

If You will upgrade Your system, avoid AMD CPU and GPU. i7-9700K is easy overclockable to almost 5GHz and has far more power than best AMD. For heavy multithreaded apps is AMD better choice than Intel.

[Thorsten]

Well that sounds pretty good then. Here I was thinking that even if I bought hardware as good as yours I'd still only get 10 fps in Manhattan.

No, FG actually is pretty good - V12 has some config quirk in his system, which is why he regularly gets half of what others get, but with a gaming laptop even with visibility maxed out etc, even in densely populated OSM2City regions I never go below ~25 fps.

So don't worry overly much

[vnts]

Yep, results look odd

..Maximum CPU utilization was 13-15%.

If this was with SMT on (16 logical cores) it might be not that bad. Still low utilisation - on my 4 core system it goes up above 75% on Manhatten as it's busy loading scenery, i.e. 3+ cores used just using ufo to get reproducible results. Utilisation on a 16 core system would be: 3+/16=18.75%+.

If this was with SMT off (8 physical cores), it's very low.

If you have an improvement in FPS with SMT off with the same LoDs then that is a separate problem (1. Scheduling issue on your OS for Ryzen, 2. It may be able to be worked around somehow, maybe by pinning threads to cores, so core devs should know to avoid it for other systems).

Lower LoDs (especially LoD:rough) increasing FPS, while still being CPU bound, sounds like OSG scene traversal related.

Kind regards

[V12]

IMHO, this is not scheduling problem for Ryzen. I had this problem on i5-2550K on Win 7, on Ubuntu from 14 to latest 20, this problem exists now on R7 3700X on Win 10 and Ubuntu 20.04. And only with FG or another singlethreaded or bad multithreaded apps. All good multithreaded apps - 3DS Max, Blender, video encoders etc. can utilize CPU at 100%. BTW, on my system I can't disable SMT