Board index Other Hangar talk

Microsoft Flight Simulator, a small graphics study

Talk about (almost) anything, as long as it is no serious FlightGear talk and does not fit in the other subforums.
Forum rules
Please refrain from discussing politics.

Re: Microsoft Flight Simulator, a small graphics study

Postby Octal450 » Mon Jun 10, 2019 8:22 pm

StuartC wrote in Mon Jun 10, 2019 8:54 am:The new MS FS has one big obvious thorn sticking out. Xbox logo.
To me this signifies it will be like all Console ported - to -pc software. It will be impossible to develop for without what is likely to be a pay/regular licenced SDK which will remove all chances of any freeware. Any additional "Content" will be pay ware, and probably not cheap ether. This fits with the "DLC" content model of console based games. Eliminate the chance for free development and force you to buy anything above the basic off the shelf package.

No it's not true.
How does that at all signify you need to pay for an SDK? MSFS X came with the SDK, and so does a P3D. Pretty much all Microsoft SDKs are free iirc, even the Xbox one (I myself played around with Xbox 360 development. I bought a used X360 devbox for testing, but the SDK itself I think was in the visual studio.)

Kind Regards,
Josh
Free Speech? Hell yeah! Free Software? Hell NO!
User avatar
Octal450
 
Posts: 4382
Joined: Tue Oct 06, 2015 12:51 pm

Re: Microsoft Flight Simulator, a small graphics study

Postby www2 » Mon Jun 10, 2019 8:48 pm

curt
Good point about the model.

As for the tools i missing graphic editor for JSBSim systems aka gnuradio companion for JSBSim.
Other features for this tool:
* importer for OpenVSP/datcom/xflr5/etc
* Tool for simulate Braytoncyclus (to create Turbo prop/Turbo Fan/Jet Engine) and Piston Engine.

Beside this is a good idea to create a asset library for blender for buttons,
Switches, Gauges, etc that are proxy for similar object in flightgear that
are replace on export to ac/flight gear XML format.

For scenery.
A good idea is to create a share object library that is compatible with the X-plane Library and some parts from OpenSceneryX.
For the tools we need a WED like tool for import and converting x-plane airports and add/replace flight gear buildings.
www2
 
Posts: 258
Joined: Thu Apr 16, 2009 1:58 pm

Re: Microsoft Flight Simulator, a small graphics study

Postby Icecode GL » Tue Jun 11, 2019 11:55 am

I'd give it 25% of the full potential of what FG could deliver with a decent graphics artist behind it - not more.


Well, let's agree to disagree then. :)
Icecode GL
 
Posts: 528
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Arch Linux

Re: Microsoft Flight Simulator, a small graphics study

Postby bugman » Tue Jun 11, 2019 12:14 pm

@Icecode GL: That's an interesting analysis. But I do have quite a few questions. What rendering infrastructure are we actually missing? Is this something obviously missing from OSG, or from FG core? Is it just implementing PBR and HDR? I don't understand why there is a hypothetical, philosophical discussion about whether we can implement this or not, compared to a paid team, when the details and parametrisation of the problem are completely lacking.

And why is it a problem if the material system is changed? Couldn't this be an optional setting? You could then implement it for the default aircraft and then let the others follow. I don't see how this is a problem. We still have aircraft from back when 3D cockpits and external models were implemented, and which still do not have a 3D model (look at some of the research-based UIUC models).

Also note that in this forum, your technical analysis is likely to be misunderstood by most readers. They will see your screenshots and will interpret analysis as to why FG does not look as good as in those screenshots. You've pointed out that that is not the case but, even if you had it in bold at the top of the post, many will still misunderstand it. I see Thorsten and other pointing out the shortage of graphic art contributions as a reaction to that - I guess they are trying to balance out the misunderstanding that many readers will have.

Regards,
Edward
bugman
Moderator
 
Posts: 1696
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: Microsoft Flight Simulator, a small graphics study

Postby Icecode GL » Tue Jun 11, 2019 2:04 pm

What rendering infrastructure are we actually missing? [...] when the details and parametrisation of the problem are completely lacking


Great question. I've tried to explain the problem as best as I could in the OP, but I guess I oversimplified and ended up confusing both end-users and people who are looking for the juicy details.

Let's start with multi-threading. This is not particularly related to real-time applications, but it's definitely one of the biggest reasons why we are seeing a paradigm shift in 3D graphics. CPU clock speeds are hitting their physical limits, so manufacturers started increasing the number of cores. OSG uses OpenGL, which is an ancient API, but has been kept alive by extensions and numerous patches. However, we have reached a point where the paradigm shift is so big that you can no longer patch the behemoth until it does what you want. That's why Vulkan appeared, DirectX 11 has almost been completely rewritten and Apple developed Metal. It is not debatable that we are seeing a huge change - if we weren't, these companies wouldn't have spent millions in developing these new APIs.

FG exclusively uses a single core (yes, it may use several cores for very specific jobs, but FG is basically single-threaded). Clock speeds aren't getting faster so we can't take advantage of new hardware, we are essentially stuck with 5/10 year old hardware even if you just bought a brand new Intel i9. However, we keep adding features to FlightGear. Aircrafts are getting more complex systems by the day, models have huge triangle counts etc. This wasn't a problem 10 years ago because while the simulator kept getting more complex, newer hardware helped us keep the performance stable. Time helped us, now it doesn't.

This is all known by the community already, I've seen some of the discussions in the multi-core wiki article. A solution would be to rewrite FG using VulkanSceneGraph or something similar, while carefully rewriting the SGSubsystem loop to be multithreaded via a job dispatching system (or something like HLA). That's a mammoth task on its own, and unless a team of developers comes to the project and manifests their interest in rewriting FG, it won't happen any time soon. But let's assume this is all done. We have rewritten FG to take advantage of newer hardware. Now let's write a rendering pipeline for it.

Let's take concrete examples, HDR and PBR for example, since you mentioned them. HDR just means that shaders output the reflected light from the object to the viewer in absolute linear values. Later, these values are tone mapped and adjusted for the display range of the monitor. Legacy material definitions (ambient, diffuse and specular) don't make sense in such a system, so we need to use PBR. Note I'm using PBR to describe a material system where the material BRDF is described using physical values, the parametrization is not important. Is the team that moved FG to VulkanSceneGraph also going to change every material definition of every aircraft in FG? You mentioned you don't see why this can't be optional. Well, you can't have two systems outputting to the same framebuffer: one outputting physical luminous intensity and the other outputting an arbitrary 0-1 color value. How do you merge them? Would it even look good? And if you are not convinced yet, what about lights? Do you define lights in the PBR style or in the legacy style? PBR lights won't be compatible with legacy materials, and legacy lights won't be compatible with PBR materials.

You could argue that this is all optional and we don't need HDR and PBR. You could argue that we have much bigger problems. And okay, that's what Thorsten thinks, but that's not the subject of the topic. I like 3D modelling and I sometimes (try to) do some art. But in this project I'm only interested in the core rendering, so I don't care if I'm told that the main issue is that we don't have enough 3D artists. I care about the barriers and obstacles we will be facing in the rendering side of FlightGear. I tried to show what the new Microsoft Flight Simulator is capable of, and how we can learn from it. Many game companies (I don't like making comparisons with the game industry, but they are the main creators of real-time applications) are opting to rewrite their engines to add these features and to pave the way for even newer features. If they are spending money in doing this, it is very likely that the reasons are more than justified, and perhaps we, as a community project, need to think about it.
Icecode GL
 
Posts: 528
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Arch Linux

Re: Microsoft Flight Simulator, a small graphics study

Postby bugman » Tue Jun 11, 2019 7:35 pm

So to achieve the same as the new tech in the new Microsoft Flight Sim, the steps are:

    1) CPU multi-processing.
    2) Vulkan instead of OpenGL.
    3) Implement HDR and PBR.
    4) Better artwork.

Is something missing here? I don't see how these combined makes for a fundamental problem that FlightGear could not solve:

1) Firstly note that I have previously worked on the test suite now built into FG, worked on making the subsystems more robust (which would be essential for multiprocessor to ever work), and am in the process or redesigning the subsystems to be modular and more independent. But I'm not convinced that threading to allow for multi-processing is worth even looking at. I've had a lot of the core developers tell me this as well. Do you really have a system that is CPU limited? Note that Nasal is designed from the start to be multi-threaded, but no one has seen a need for this. Optimising the aircraft or FGData side Nasal code is a far better way to avoid CPU issues. Optimising Nasal's garbage collection algorithm is another that has been often discussed. If this really were an issue, then threading could be looked at. But the massive pain to little gain ratio is really against multi-threading now (debugging dead-locks introduced by threading is a nightmare). I don't see this changing for at least a decade yet, as no one has ever identified a spot in the code that could be threaded to relieve a CPU bottleneck.

2) Like you mention, there is VulkanSceneGraph. This evolution of OSG will still need some more time to bake. Would switching from OSG to VSG really be something that cannot be achieved in FG? Obviously, if we stick with OSG, this will eventually happen.

3) For HDR and PBR, I of course don't mean having these working at the same time as the current technology. I mean like ALS vs. Rembrandt. Would it not be possible to have FlightGear with a PBR 'on/off' switch?

4) I've been using FlightGear from almost the very start (1997 to be precise). The artwork evolution and quality improvements have been rather impressive. I'm confident that the FG contributors can continue to improve this.

Regards,
Edward
bugman
Moderator
 
Posts: 1696
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: Microsoft Flight Simulator, a small graphics study

Postby Icecode GL » Tue Jun 11, 2019 8:56 pm

Is something missing here? I don't see how these combined makes for a fundamental problem that FlightGear could not solve:


Unless I slipped up and some of my pessimism showed up I don't think I've ever said we could not solve any of these problems. In fact, right at the end of the OP I explicitly mention that I'm kind of optimistic about these challenges.


1. I think we are not talking about the same kind of multi-threading. I don't mean the classical concept of multi-threading: having a main loop on the main thread and dispatching specific jobs that can benefit from multi-threading to separate threads. I mean to have some kind of job queue where commands are sent asynchronously and a job dispatcher that sends these commands to different threads dynamically. I guess what I mean by multi-threading is more like HLA. Vulkan, unlike OpenGL, allows draw calls to be assembled from any thread into a command buffer to be sent to the GPU. That has a huge potential. I don't know what you mean exactly by "having a system that is CPU limited", but FG is very CPU limited. And even worse, the GPU idles while the CPU works and viceversa. A modern multi-threaded job dispatching system, combined with a modern graphics API, allow the GPU and CPU to be working in unison almost all the time, effectively reducing frame times.

2. Sure, looking forward to it.

3. How do you treat objects that don't have a PBR definition when PBR is enabled and viceversa?

4. No doubt about it.
Icecode GL
 
Posts: 528
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Arch Linux

Re: Microsoft Flight Simulator, a small graphics study

Postby curt » Tue Jun 11, 2019 9:50 pm

I would make a few cautions on multi-threading based on past systems I've seen.

The PX4 autopilot system has a really neat thread scheduler/messaging system called uORB. All threads communicate by subscribing to or publishing messages. The scheduler (uORB) handles message storage and passing and uses this to schedule threads. A thread waits on a message type by subscribing to it, so when there is a new message of that type, the scheduler gives copy of the data to the thread and drops it onto the run queue. When the thread is finished with an interation, it can publish it's own message and go back in the wait/block queue. It is quite a beautiful system from a computer science standpoint. There's almost no possible way to have a race condition or dead lock or crash due to simultaneously reading and writing a variable from different threads. The big problem however is with indeterminant timing. From an aerospace engineering perspective, we wanted threads to run at precise rates, or in a precise sequence. Some things just don't make sense to do out of order, but a generic scheduler doesn't care. For data collection and sysid work, we need our UAV autopilot to sample sensors and do it's work at a very precise deterministic time interval ... time jitter just adds undesirable noise. When we plotted out the interval between collecting IMU samples for example, we were rather shocked at how much variation the system produced. I believe the PX4 scheduler has improved quite a bit over time, but when we needed it, it just wasn't good enough for our purposes.

In the context of rendering simulator graphics, the most important thing is fluidity, and that is achieved with consistent frame rates and consistent update rates/amounts. This is something we learned after creating the original FlightGear architecture unfortunately. We thought if we just ran faster, then things would smooth out, and that's not entirely true. If we are running at 60hz and drop a single frame (momentarily down to 30hz) our eye's can pick that out. This is something that's fairly hard to achieve perfectly on a typical operating system like windows or linux. But the current flightgear timing architecture doesn't really help the situation, and the original scene graph library we used didn't offer any tools to manage this.

So by all means, architect a beautiful thread scheduling system that is robust to all the issues threads normally lead to, but keep precise time intervals in mind, or we will never climb out of the timing jitter hole we are currently in. (No worse than FSX probably, but we are no where close to the fluidity of sims like infinite flight and many other 3d games and simulators.) Don't fall into the trap of thinking we can climb out of the hole by just running faster, or boosting our average frame rates. That is only a partial solution.

The FlightGear property system is another beautifully designed piece of artwork. It is extremely powerful and useful for sharing 'state' between different program modules (even between nasal and C++). However, it is not thread safe, and it doesn't lend itself to being made thread safe. The property tree is such an integral part of the FlightGear design ... many of our past threading bugs and workarounds have come from ignoring that our property tree isn't thread safe, but pretending it is and trying to be mostly lucky most of the time. Some of our core developers have taken a really deep look at HLA/DIS as a way to rearchitect the flightgear core infrastructure in a way that is threadable and distributable.

I have a small knee jerk reaction against threading myself because I've seen so many times and so many ways that threading issues have been misunderstood leading to unexpected performance, unexpected bugs, extremely difficult to debug crashes, and on and on. Too often people toss "threads" around as a magic buzzword without fully understanding the implications, the capabilities, the dangers. I know that's probably not you (icecode) but for the more casual readers of the forum who might not have done as much with threads in their own projects. There is no magic in the world, nothing comes for free, not even with threads.

That said, traditionally, simulation/graphics programs spend upwards of 90% of their time rendering the scene, so if you were to improve the threading of FlightGear, concentrating on the rendering system (engine?) will give you the most bang. Generally things like the FDM and systems modeling take a tiny fraction of the overall program time.

There is lots to digest here, and everything is very interconnected in a mature program like FlightGear ... and very few people (if any?) understand all the interconnections and dependencies simultaneously.

All of this is interesting to discuss ... sometimes after some thought and discussion an idea gets so itchy it must be scratched ... that's usually how my adventures begin.
Aerospace Engineering and Mechanics
University of Minnesota
curt
Administrator
 
Posts: 1174
Joined: Thu Jan 01, 1970 12:00 am
Location: Minneapolis, MN

Re: Microsoft Flight Simulator, a small graphics study

Postby Michat » Tue Jun 11, 2019 9:53 pm

Doesn't anyone notice that is a trailer ? It's just a film, in fact is a reprography with many tricks, in and out, use of impostation, crhoma, external zoom and cropping, sometimes almost parallax impostation. Maybe Blender :mrgreen:

Wrong if you believe that you gonna get such film in your pc/console.

In my view I see thing air and big money, but poor physics, notice cessna crashing into the savannah tree :mrgreen: , also the anomalous behavior of the airliner late rotation running over ALS. :roll:

Again mss creating a vortex.

Will depend of how many people sukcs.
Same as mss Flight?

I'll relly in our people to make the best we can. Anything but compiting with the entertainement industry at hollywood, virginia or S Valley.

29.92 for our team. FG is leading.

Mss is in other bussines but flight simulation, this is just another skin and theme, the two other sides are provided by partners. ¡'ll not rely on such commercial relations, where the object is you, the user as a consumer, but user when they share your data.
User avatar
Michat
 
Posts: 958
Joined: Mon Jan 25, 2010 6:24 pm
Location: Spain
Version: 191b
OS: GNewSense

Re: Microsoft Flight Simulator, a small graphics study

Postby Icecode GL » Tue Jun 11, 2019 10:41 pm

Very nice write up curt, you basically summarized what I've been trying to say. Indeed multi-threading is no magic bullet, and its problems are beyond a simple headache, but if you can find some way of parallelizing huge tasks and sharing information between them (HLA being the most investigated one in FlightGear), you are paving the way for new features and their performance implications.

Doesn't anyone notice that is a trailer ? It's just a film, in fact is a reprography with many tricks, in and out, use of impostation, crhoma, external zoom and cropping, sometimes almost parallax impostation. Maybe Blender :mrgreen:


They say at the beginning that it is "captured in real time 4k". I don't think they would lie about that, I guess they would face some kind of legal issue. Something like a "batteries included" label in a toy ad. :lol:
Icecode GL
 
Posts: 528
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Arch Linux

Re: Microsoft Flight Simulator, a small graphics study

Postby Michat » Wed Jun 12, 2019 2:24 am

@Icecode the lie resides in it's UN-WYSIWYG what you see is not what you get. Differing totally from the final futurible product. What I saw was a film not a simulator. That's the main trick. Novela.

@curt here is a video that confirms part of your statements about: tasker, scheduler, threats and multicoring. Introducing trivial solutions to those problems from the scratch, just avoiding such arquitecture entirely with a new Commodore-like OS which includes a supercool flight simulator called EagleDive :mrgreen: physics + math lab and many more. Furthermore you'll be amazed to know that the command line feeds into a Holly C compiler, no make, no lib dependencies, the command line fits a bin hex code instruction debugger editor, in the same workspace you can see code and graphic sprites svg and bmps that you can zoom +- or simply drag and drop. Not GPU needed for graphics.
Cool Eh, isn't it.?
About 25mb the entire suite,

I believe guys you'll find interesting to know that scaling up will be the end of civilization. :mrgreen: Amiga rulez.

https://youtu.be/gBE6glZNJuU?t=699

29.92. I vote to scale down the entire FG to such arquitecture, pack in them with TempleOS, run it on a virtual box. Enjoining solid 25fps with 16 color. I'd paid for that. 8)
User avatar
Michat
 
Posts: 958
Joined: Mon Jan 25, 2010 6:24 pm
Location: Spain
Version: 191b
OS: GNewSense

Re: Microsoft Flight Simulator, a small graphics study

Postby bugman » Wed Jun 12, 2019 7:48 am

Icecode GL wrote in Tue Jun 11, 2019 8:56 pm:
Is something missing here? I don't see how these combined makes for a fundamental problem that FlightGear could not solve:


Unless I slipped up and some of my pessimism showed up I don't think I've ever said we could not solve any of these problems. In fact, right at the end of the OP I explicitly mention that I'm kind of optimistic about these challenges.


You said:

Icecode GL wrote in Sun Jun 09, 2019 11:43 pm:We are kind of stuck graphically. We can keep implementing goodies and other fancy effects, but in the end the underlying problem is very hard to fix (I'd say almost impossible). It's still useful to follow the progress being made on the flight sim market, to have a benchmark to compare to.


I'd say that the language "almost impossible underlying problem" and a "fundamental problem that FlightGear could not solve" are not too far from each other ;)

1. I think we are not talking about the same kind of multi-threading. I don't mean the classical concept of multi-threading: having a main loop on the main thread and dispatching specific jobs that can benefit from multi-threading to separate threads. I mean to have some kind of job queue where commands are sent asynchronously and a job dispatcher that sends these commands to different threads dynamically. I guess what I mean by multi-threading is more like HLA. Vulkan, unlike OpenGL, allows draw calls to be assembled from any thread into a command buffer to be sent to the GPU. That has a huge potential. I don't know what you mean exactly by "having a system that is CPU limited", but FG is very CPU limited. And even worse, the GPU idles while the CPU works and viceversa. A modern multi-threaded job dispatching system, combined with a modern graphics API, allow the GPU and CPU to be working in unison almost all the time, effectively reducing frame times.


I have a lot of coding experience with threading, OpenMPI, and other message-passing systems (I once wrote my own based on SSH). The key here is that even if the parallelisation of serial CPU sequences is theoretically beneficial, the costs of data transmission often outweigh the benefits. For my day job, I had a problem that I parallelised in 4 different ways (using different technology, different granularity, and different parallelisation targets). This time intensive full-time work took me almost a year to implement, debug, optimise, and test. In the end all 4 parallelised instances in timing tests were 2 times slower than the original serial code. This was due to the high costs of data transfer.

In FlightGear we have a similar data transfer issue - the property tree. A subsystem hypothetically parallelised to run on a different core, different CPU, different computer, etc. will still need access to the property tree. Stuart has looked into creating a local property tree for the subsystem instance which partly synchronises with the global property tree. However this is difficult due to cost of data transfer. It is also a major problem that the property tree is not thread safe. Combine that with almost all subsystems segfaulting or crashing in other ways if a certain property is missing from the tree (requiring our quite rigid and brittle fg_init startup sequence). To avoid this crashing, a lot of checking needs to be built into the subsystem, and the costs of this may negate the benefits of parallelisation.

So you really need to be extremely specific in the details of what should be parallelised and perform a deep analysis of the computational and data transfer costs of that parallelisation, In most cases what you feel will be a computational win will in reality only slow you down. Parallelised code is also probably an order or magnitude harder to manage and debug, and that is an important consideration as well. Anyway, I'm looking at this problem with my subsystem work. Stuart is looking at HLA. Richard is also doing a lot of work in the area. The benefits here are not going to be what most casual readers will probably assume - e.g. shifting from 1 CPU core to 8 CPU cores will make FG 8 times faster, or make all the CPU bottlenecks disappear. The benefits are more likely that you can run a subset of the simulation on a different computer and communicate between it and your FG instance via the network.

2. Sure, looking forward to it.


I assume that this internal core migration from OSG to VSG will solve the OpenGL parallelisation issues you mentioned earlier? Without requiring any GPU parallelisation in the FG core?


3. How do you treat objects that don't have a PBR definition when PBR is enabled and viceversa?


Have you tried to add a PBR definition to an object in a way that does not effect the current rendering pipeline? Or to have light sources that can switch between the two? If PBR were to start as an experimental feature that you specifically turn on (even if it is set up as a temporary, ugly hack), then people could slowly convert the FG world to benefit from the technology. There would no need to worry about breaking everything. That is how you can shift a well established codebase to something new.

Regards,
Edward
bugman
Moderator
 
Posts: 1696
Joined: Thu Mar 19, 2015 9:01 am
Version: next

Re: Microsoft Flight Simulator, a small graphics study

Postby Icecode GL » Wed Jun 12, 2019 9:51 am

I'd say that the language "almost impossible underlying problem" and a "fundamental problem that FlightGear could not solve" are not too far from each other ;)


But then you insist that large scale multi-threading is not possible in FlightGear and that we are stuck using a single core unless someone finds a magic place in the code where multithreading can be implemented without affecting other parts of the codebase. Not being able to take advantage of modern hardware is not a problem? Moving from OSG to VSG is not trivial either by the way.

In FlightGear we have a similar data transfer issue - the property tree. A subsystem hypothetically parallelised to run on a different core, different CPU, different computer, etc. will still need access to the property tree.


Then perhaps a global property tree isn't such a good idea in 2019? Isn't that a "fundamental problem"? Would FlightGear still be FlightGear if it didn't have a property tree?

So you really need to be extremely specific in the details of what should be parallelised and perform a deep analysis of the computational and data transfer costs of that parallelisation,


I agree, and I really appreciate the efforts made by Stuart, Richard and you to improve the situation. But let's not forget the numbers please. FlightGear runs at 40/50 fps on my machine with a moderately complex aircraft, which by today's standards is starting to become unacceptable. With my Compositor work I've had to add a few milliseconds (5-6ms) to the frame time just for shadows, that reduces the framerate to 30/40. You tell me if we are stuck or not. We can't add almost any complexity to the pipeline in fear of dipping the framerates below 30, which again is not exactly standard nowadays. Covering your eyes won't make the problem go away. Perhaps multi-threading is not the answer, but you have to acknowledge that having 7 unused cores is kind of tempting and the first thing one might think about when trying to optimize for modern hardware.

Have you tried to add a PBR definition to an object in a way that does not effect the current rendering pipeline?


Kind of pointless to discuss this as it is all hypothetical. You never know the small challenges and problems until you get your hands dirty.
Icecode GL
 
Posts: 528
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Arch Linux

Re: Microsoft Flight Simulator, a small graphics study

Postby legoboyvdlp » Wed Jun 12, 2019 10:25 am

Then perhaps a global property tree isn't such a good idea in 2019? Isn't that a "fundamental problem"? Would FlightGear still be FlightGear if it didn't have a property tree?


I'm talking about something I know little about but Richard's emesary (now implemented in C++ apparently?) sounds ideal for intra-subsystem communication :?
User avatar
legoboyvdlp
 
Posts: 7000
Joined: Sat Jul 26, 2014 1:28 am
Callsign: YV-LEGO
Version: 2018.3.1
OS: Windows 10 HP

Re: Microsoft Flight Simulator, a small graphics study

Postby bugman » Wed Jun 12, 2019 10:28 am

Icecode GL wrote in Wed Jun 12, 2019 9:51 am:
I'd say that the language "almost impossible underlying problem" and a "fundamental problem that FlightGear could not solve" are not too far from each other ;)


But then you insist that large scale multi-threading is not possible in FlightGear and that we are stuck using a single core unless someone finds a magic place in the code where multithreading can be implemented without affecting other parts of the codebase. Not being able to take advantage of modern hardware is not a problem? Moving from OSG to VSG is not trivial either by the way.


It is possible. However zero of the core developers consider that a CPU bottleneck is firstly a "problem", and secondly that it can be simply fixed with multi-threading. The reason being that, as far as I'm aware, the benchmarking that has been done does not point to this. Hooray has done a lot of benchmarking work along these lines.

In FlightGear we have a similar data transfer issue - the property tree. A subsystem hypothetically parallelised to run on a different core, different CPU, different computer, etc. will still need access to the property tree.


Then perhaps a global property tree isn't such a good idea in 2019? Isn't that a "fundamental problem"? Would FlightGear still be FlightGear if it didn't have a property tree?


This assumes that multi-threading is the solution to hypothetical current CPU bottlenecks. Anyway, for multi-threading, the concept of the global property tree is not the issue but rather its implementation. Stuart is looking at this with subtrees and data synchronisation.

So you really need to be extremely specific in the details of what should be parallelised and perform a deep analysis of the computational and data transfer costs of that parallelisation,


I agree, and I really appreciate the efforts made by Stuart, Richard and you to improve the situation. But let's not forget the numbers please. FlightGear runs at 40/50 fps on my machine with a moderately complex aircraft, which by today's standards is starting to become unacceptable. With my Compositor work I've had to add a few milliseconds (5-6ms) to the frame time just for shadows, that reduces the framerate to 30/40. You tell me if we are stuck or not. We can't add almost any complexity to the pipeline in fear of dipping the framerates below 30, which again is not exactly standard nowadays. Covering your eyes won't make the problem go away. Perhaps multi-threading is not the answer, but you have to acknowledge that having 7 unused cores is kind of tempting and the first thing one might think about when trying to optimize for modern hardware.


Again, I would say that almost all core developers think that parallelising to use the 7 unused cores will not bring about any noticeable frame rate improvements. The real benchmarking simply does not support this argument.

Have you tried to add a PBR definition to an object in a way that does not effect the current rendering pipeline?


Kind of pointless to discuss this as it is all hypothetical. You never know the small challenges and problems until you get your hands dirty.


You introduced the topic of PBR here on the forum. Have you tried implementing it? The large number of aircraft in FGAddon or the large conversion effort should not be an excuse to not try. A good implementation, especially if it is an optional experimental feature that is turned on, is likely to be acceptable for inclusion into the project.

Regards,
Edward
bugman
Moderator
 
Posts: 1696
Joined: Thu Mar 19, 2015 9:01 am
Version: next

PreviousNext

Return to Hangar talk

Who is online

Users browsing this forum: Google [Bot] and 2 guests