So firstly I'll answer your original points:
You're wrong that FG isn't designed in a future proof way; it's modular and well architected and parts can be replaced. I'd be interested to know what you specifically think isn't 'future proof'. The fact that FG can have 2 completely different rendering engines, many different FDM, be extended easily by XML etc.... Probably the biggest constraint in developing FG is retaining compatibility with all of the models that are already out there. Drop this as a requirement and some significant changes could be made, but well you'd have nothing to fly around in. This is pretty much the same problem that plagues any well established piece of software.
- Yup
- Modularity is essential; dynamic plugins (.so / .dll) are much more complicated; if anything adopting OpenRTI or Open-DIS is probably a better idea.
- Very hard to achieve. OSG is pretty good at what it does. There are other options but the demands of a FlightSim are quite often way in excess of your typical game engine. Needs to be decided first.
- Better to abstract the GUI completely away from the simulation engine and allow multiple front ends, such as http.
- This is the hardest one of the lot; probably I'd go with shapefiles - OSGEarth uses these to great effect; but the biggest single performance problem FG is WS2.0 and missing LOD. Any terrain engine must have LOD designed in from the start.
- Not worth wasting time on; OSG can load from lots of different model formats - so largely the choice of model format depends on the rendering framework (3)
- possibly; but not really important.
- Probably not as using JSON doesn't achieve much over XML, JSON is harder to reliably validate and not as easy to enter.
- As a DSL Nasal is pretty good at what it does. There are many options you could choose from, DCS uses LUA. Python could work. I'd probably go for C# embedded.
- This is a double edged sword. If from the outset you support import of JSBSim FG models then you will probably end up driving development to support this and may end up driving the architecture towards the same way that FG is structured. You may not see this as ideal; I'd not worry about importing at all - anything new will benefit from models that are designed from the ground up to work with the new architecture.
- Software engineers or programmers often think that you can modularize aircraft because it looks to a software engineer that aircraft are full of the same parts. Anyone who's made a decent aircraft simulation will tell you that there is a degree of variance in even the basic instruments; but once you get onto avionics and aircraft systems it starts to differ massively; more so with recent aircraft (since the mid 1980's when they started to use black boxes extensively). IIRC simulating electrics and hyds was the main reason to implement Nasal in the first place.
A more sensible approach is to build up a library of aircraft parts simulations by their model number; but this is a massive undertaking and requires a lot of tedious work which is why you often see a lot of cut and paste coding in the aircraft models; but this is nothing to do with the core capabilities as FG is already setup to allow modular instruments, parts of models etc. it’s just that most modellers don’t have the time to maintain this library. - Multiplayer is a lot harder than it seems. Peter’s JoinFS looks very promising and I’ve heard good things, but it isn’t GPL or opensource. FG multiplayer is something that does need improving. I’ve already made two improvements to this (packet efficiency and Emesary) – but the next step is going to be the biggest improvement (and the most complicated so it might never get done); which is to enable p2p for aircraft that are ‘close’ (i.e. within say 3nm).
If I were to build my own Simulator then I'd probably not be worrying about most of your list; instead it would go something like this.
- Investigate, evaluate and choose a rendering platform. ref (3)above. The main thing I'd be worried about is how well it works at 36,000ft and at sea level. I'd be reviewing all of the usual rendering effects and overall quality and peformance, but at the same time part of this process would have to be to build terrain for limited region, I'd probably choose the Cote d'azur because there is decent DEM, OSM and it's an area that has both coastlines and mountains. I'd want to see how well it performed in cockpit, outside models, z-buffering etc. Shadows, PBR, lightpoints, atomspheric light scattering, 3d clouds, water effects, reflection, heat haze (etc.). Probably the rendering engine should be multithreaded and thread safe. Probably at least 200 hours effort to properly evaluate each possible rendering engine; plus probably 200 hours to a list of rendering engines to evaluate. I'm going to estimate this at 800 hours, i.e. evaluating 3 different engines[1].
- Having chosen a rendering platform I'd then concentrate on how to build the world scenery; importing airports, lights, OSM data, navaids etc. The goal would be to build a model of the entire world that was of good quality and performance that looked great and ran at more than 30fps everywhere. Probably 1000hours.
- Having now got a rendering engine; I'd next build the simulation engine. This needs to be modular (at the source level), multi-threaded and configurable both by the end user but also by the aircraft and scenery models. The rendering engine and simulation engine would be free running, so I'd have to solve that first. I'd probably go with conceptual compute nodes, each of which would be a thread and would be loaded up with a set of simulation modules. The compute nodes would be frame based; and strict start of frame synchronisation required. In this sense the simulation frame is separate from the rendering frame. The rendering is free-running and would therefore be interpolating the view position from the output of the simulation nodes. Probably 500 hours.
- Design and implement interaction between the rendering and the simulation for animations, ground interactions, etc. Probably 200 hours.
- Connect (3) to JSBSim. Build an aircraft model and get it working. This may require choosing a scripting engine and implementing it. Probably 500 hours.
At this point you'd have a basic simulation platform after spending 3000hours. You'd not even be close to what FG can currently do.
…maybe I’m too old and lack enthusiasm but having seen that starting from the ground up on a project will generally take two or three times longer than it would to improve an existing project.
The reasons for a massive redevelopment effort have to be more than the list you’ve posted, a lot of the architectural issues are simply not causing a real problem to most modellers, and Nasal is reasonbly easy to pickup - but it's interfacing with the aircraft model that is the hard part and that is not something the improves just because the language is better. Really the list boils down to improving performance and graphics – which is a fine goal, but ultimately the same problems that are the root cause of the graphics / scenery problems in FG will still be there; namely the lack of active modellers fixing up the world so that it looks great *and* that FG is already using most of the good sources of DEM, mapping data and terrain meshes, there simply isn’t that much better available (on a worldwide basis).
Personally I'd dispute that "...FG has become a Bloated software hard to run in low specs machines.." there are parts of the internals of FG that could do with optimising, but this oft quoted “bloated software” is almost a worthless statement – programmers don’t go around writing huge amount of code for no reasons; and what someone calls bloat someone else may well refer to as a neat feature. Generally FG is well structured although there is a lot of code to understand; it's reasonably memory and CPU efficient (although the lack of multithreading hurts performance, but multithreading in C++ is very far from being easy).
The big problem with optimising software for low spec machines is the amount of time it takes; and the rather vague “low end machines” is a constantly moving target that would need to be defined, e.g. i3 with integrated graphics. Almost certainly it becomes even more complex If you want to get the good graphics that medium to high end users expect and keep performance ok on lower end machines – because you may find that you need to restructure the terrain model to work with minimum shaders (i.e. 1). This sort of optimising may require a switch in rendering engine, or a rebuild of the interface to the rendering engine or rebuild of the scene models DB.
IMO most of the performance problems that you'll encounter with FG are related to the terrain mesh (WS2.0), together with poorly coded aircraft, using Canvas etc. The F-14 gives roughly 1.5 times faster fps, and that’s mainly the less detailed cockpit mesh and the lack of canvas displays. I’ve spent a fair amount of time trying to get better performance out of the F-15, and now the main thing left is to rebuild the entire cockpit as a single mesh with a single texture atlas which would take a lot of time for possibly little reward (as it might not even help much).
If FG ever gets WS3.0 then you can expect a significant performance improvement just because of the LOD and improved terrain meshes. You just need to look at the OSG stats to see where the performance is going to realise just how significant LOD in the scene model DB will be.
So personally I’m not really interested in doing this; if I was I’d probably already have started, instead I’m slowly working through a list of things that I think need improving in the current FG.
-------------------------------
[1] one of these would certainly be the opensource OpenIG by my friends over at Compro; as they understand how an image generator for a flight sim should work.
