You guys are doing a fantastic job trying to make the client run on the widest range of hardware possible and adding some really cutting edge features. The last few months have probably seen some of the most exciting and important strides towards preparing Orbiter for the next decade of graphics technology and all the wonderful experiences it promises.
This includes not just what you've mentioned, but water reflections (and actual water instead of just a texture like it's now) as well. But this will be a bit later.
Its great that you are ready to think out of the box to implement features that fill in the gaps :thumbup:
Let me push you guys some more then
I see that you already render meshes that are not controlled directly by the core. A separate graphics client gives you the freedom to do that and in fact add and
move things around any which way you want. Well, then why not expose this capability through a function provided by the graphics client's API. That would allow meshes to be imported and moved by a Orbiter plugin independent of control by the Orbiter core. The advantage to that would be that plugins can add external physics engines that complement Orbiter's own capabilities and widens its scope. Custom maps are already supported, custom meshes seem to be a logical extension of the idea.
And whats more, since you are thinking of adding water on the high seas, what about ships on the water that float realistically. Such ships meshes would require accurate simulation of buoyancy etc which can be easily added by plugins. To control the meshes the idea I have followed so far is to use attachment points. But if the graphics client were to provide a way to directly position a mesh on a planet's surface without going though the core(which is pointless if the orbiter core is not controlling the object anyway). then it opens a lot of possibilities. I would think it would just be a matter of multiplying the right matrices in the proper order to position meshes on the surface of a planet or inside a vessel. It would be a one time extension which you can then forget about, but it would be a valuable addition to an add-on developer's options.
Its not limited to just ships and vehicles, someone could use one of the open source flight sim libraries to have a super-accurate boeing flight model. Specialized libraries can be integrated with meshes directly under their control but running in the same process(or even out of process, in a thread ?) as Orbiter. The Orbiter API is always available to sync with the main Orbiter simulation as needed. All in the same graphics viewport.
I am not requesting this feature be considered immediately of course, as you guys are busy with preparing the client. Maybe not today or tomorrow but it could be considered ultimately and perhaps you can keep it in mind. Separating the client would probably be one of the best decisions the good doctor took and it would really bring more into Orbiter than he had bargained for
Adding extra physics capabilities like movement of vehicles, water simulation etc allows for more complex missions right from detailed ground operations, in space and on other planetary bodies. It will truly elevate Orbiter from a space flight simulation to one that simulates all aspects of it
No point wasting those CPU cycles
