Its approach to decouple form the graphics backend (in the server-based orbiter_ng.exe version)
According to the Readme, those sources seem to be on SourceForge! (But not seen via the SF web UI.) Are they still accessible via SVN though?
_Anyhow, a guy commented in 2021 that he could rebuild the NG version ("I managed to compile the Orbiter and Orbiterng with VS2015 and both seems to be running.")
... Currently, a DirectX7 graphics client is under active development on OVP. This will essentially be a re-implementation of Orbiter's internal graphics system (or a subset of it) in the form of a plugin. It is mainly intended as a reference implementation, or demonstrator. It is expected that the main development effort will eventually switch to more up-to-date graphics interfaces, such as OpenGL or DirectXn (n >= 9).
Numeric methods
(BTW, he also calls his import/3rd-party/vendor lib folder "extern" (but with a capital E), like me, yay. :) )
Wow. This is really a surprise and my jaw almost dropped on a floor. Thanks.
So, How is this going to effect to the OVP ? Having two renderers with a different capabilities doesn't sound like a good idea based on the experience from D3D9. If the inline engine is replaced with DX11 then this would likely mean letting go the OVP and a physics/graphics separation. I don't really have an opinion or preference on that matter. So, It's fine by me.
Regarding the seperation of Physics and Rendering engines, do you think we could get away using the protobuf messages or nanomsg communication approach? Or do you think that the latency would be too high to be useful.
This http://gazebosim.org/ simulator kind of does that. The physics client and the graphics client are seperate processes and they communicate using protobuf if I am right.
Comment from the XRSound guy about scenarios possibly being able to select entirely different sounds modules (for even better vessel-specific experiences).
https://github.com/orbitersim/orbiter
Especially:
Its approach to decouple form the graphics backend (in the server-based
orbiter_ng.exeversion) According to the Readme, those sources seem to be on SourceForge! (But not seen via the SF web UI.) Are they still accessible via SVN though? _Anyhow, a guy commented in 2021 that he could rebuild the NG version ("I managed to compile the Orbiter and Orbiterng with VS2015 and both seems to be running.")At the Orbiter wiki:
Numeric methods
(BTW, he also calls his import/3rd-party/vendor lib folder "extern" (but with a capital E), like me, yay. :) )
See also:
OVP at the Orbiter wiki
Dr. Martin Schweiger's OSS release post (2021): https://www.orbiter-forum.com/threads/orbiter-is-now-open-source.40023/#post-584737
From its comments, regarding OVP: https://www.orbiter-forum.com/threads/orbiter-is-now-open-source.40023/post-584801:
Random discussion about multiple (camera views in OVP
Comment from the XRSound guy about scenarios possibly being able to select entirely different sounds modules (for even better vessel-specific experiences).