Orbiter is now open source

JDat

Member
Joined
Sep 6, 2010
Messages
93
Reaction score
52
Points
18
Thanks Martin for for great work during past 20 years!
Now orbinauts can continue your great work!

:hailprobe:


I dreamed that on one day Orbiter can become open source. Dreams come true after few months... :)


After quick look on source code (I am not programmer). I want to see following trends in future versions:
1) Unwind (remove) build-in MFD modes from core and make them as addons.
2) Make Orbiter as much as possible independent of CPU architecture to run both on 32-bit and 64-bit. Graphics can be problem? Addons can help here.?
3) Make as portable as possible and run on ARM (Raspberry pi or similar) aka native Linux Orbiter. There is lot of work regarding WinAPI removal. :(
4) OpenGL (again for linux?) support aka more graphics clients.
5) Separate core (mathematics) and graphics and run them over network on different machines.
6) Make separate HUD output, so separate projector can do HUD stuff in simpit. Quickest and dirty way is to make hudMFD addon and run via VNCMFD...
7) Python support as 2nd scripting together with Lua. Maybe?
8) Remove DDE server and DDE sclient from orbiter source code.
9) Remove build in joystick support and make it as addon.

Lot of work for these who wear ADDON DEV badges in they profiles...
 
Last edited:

pappy2

Active member
Joined
May 3, 2012
Messages
389
Reaction score
24
Points
33
Thank you Dr MARTIN for these many dreamy hours spent with Orbiter. :hailprobe:

Without you, (and all the other addon makers) I would never have been able to take off to the moons and planets of our solar system. 🚀🌠🌏🪐💫

Thank you for your work, and your future work to come.

See you soon
 

francisdrake

Addon Developer
Addon Developer
Joined
Mar 23, 2008
Messages
798
Reaction score
207
Points
58
Website
francisdrakex.deviantart.com
Thank you for creating Orbiter! It is your brainchild, and it must be a big step to let your child step out into the open source world. I am sure this will keep Orbiter growing and improving. Orbiter is the reference for spaceflight simulation in the solar system, challenging and beautiful at the same time!
 

ggalfi

Active member
Joined
May 31, 2020
Messages
42
Reaction score
65
Points
33
Location
Budapest
It's been a while ...

Dear Orbiter users and developers,

I haven't been around this place in quite some time, and for personal reasons haven't been able to push Orbiter development along for a few years now. In order to keep Orbiter alive and allow others to work on it, I have decided to publish the sources under an open source license:


This is essentially the 2016 Edition with some minor (and at least one major) fixes. I hope this is of use to somebody. The code is somewhat unorganised and sparsely documented, but it should compile and leave you with a working Orbiter installation. Note that the repository doesn't include all the required planetary textures, so you need to install those separately (e.g. by reusing an existing Orbiter 2016 installation - this is explained in the Readme and only requires setting a CMake option before configuring the build).

I am still hoping to work on future enhancements of Orbiter, but I can't make any promises or commitments. One of the most pressing issues is switching the code over to 64-bit, but this requires ditching the DX7 dependency (and ideally replacing it with DX11), but that is a major undertaking which I may or may not be able to do).

Please let me know of any compilation problems or any other issues with the repository, either here or by raising an issue on github. I am also happy to consider merge requests.

Happy coding!
Dear Dr. Schweiger,

it was only a few weeks ago, when I made a not-so-well-thought promise on NASSP IRC channel, that when I'll be a billionaire then I'd buy a yacht for you to make Orbitersim open source. I'm not (yet) a billionaire, but I surely owe you at least a beer :)

Thank you for all your work you put into this sim during the past two decades, and now also for allowing others to mess up your own well-written code!
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
4,539
Reaction score
751
Points
138
Being able to "peek behind the curtains" has allowed me to figure out why the brake force can't be configured: the new touchdown point logic doesn't use the value passed in SetMaxWheelbrakeForce(). The new logic adds to the friction coeficient the difference between mu and mu_lng, scaled with the brake level. So one could control the braking force by using the correct difference between those 2 parameters... but my first tries ended up giving me either too little lateral drag (the vehicle goes sideways down the runway) or too much basic longitudinal drag (i.e., without braking).
Interesting bone to chew...
 

Blake

Addon Developer
Addon Developer
Joined
Mar 9, 2009
Messages
174
Reaction score
35
Points
43
Martin, thank you.

There is tremendous talent and knowledge in this community and I am looking forward to see how it can be used to keep Orbiter relevant and fresh. I think this will also renew some interest in add-on development now that there is some clarity on a path forward.
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,410
Reaction score
297
Points
83
Website
orbit.medphys.ucl.ac.uk
Thanks all for your comments!

Nobody has reported issues with compiling Orbiter so far, which must be good news.
So, is this build on r90 in the svn repository or it branches earlier?

Also, how will future releases be handled?
It is based on my last svn snapshot, which is probably a bit past r90 but certainly not earlier.
I have no immediate plans for releases, but whenever it feels that something worthwhile has been added and the code is in a stable condition I may push a release on github. Possibly more frequently than in the past.
@martins Can you maybe create a project at Github for the migration to x64 and DX11? Then it would be easier to group issues related to this and sort the work to be done.

I am all for a very conservative approach to extending Orbiter, but migrating to x64 will likely also break some older add-ons. In this case, the open-source approach might be really good for also making sure the add-on developers are heard and can contribute to the next generation API.
Done. I've never used that feature before, so let's see how it goes.
Could the Orbiter tickets posted in the previous OF version be inserted in github?
Not automatically. I don't know where they are, but if you can access them, feel free to add github issues for any that are still relevant.
Could you maybe update the official Orbiter website with news of this?
Probably. I just realised that I currently don't have access to the server hosting the Orbiter website. I'll try to sort something out with UCL and maybe move the site to a different host.
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,305
Reaction score
411
Points
123
Location
Vienna
Nobody has reported issues with compiling Orbiter so far, which must be good news.

On that note, I can report that I managed to compile it on my Win7 machine. However, it was far from being easy, because CMake presented itself as being a bit of a rabbit hole. My main stumbling point was the lack of installed documentation tools to compile PDFs and HTML files, so I used the DOC flag to disable the appropriate steps. Unfortunately, the if-clause was not present in subsequent CMake lists, so I had to add it in order to get a successful build run. This is the patch: https://github.com/Face-1/orbiter/commit/fcfee6b0f2a4d0a19438c43717848a641b705458 .
 

rodion_herrera

Moonwatcher
Addon Developer
Joined
Nov 4, 2007
Messages
223
Reaction score
3
Points
18
Location
Muscat, Oman
Website
astronomicalsolutions.com
It's been a while ...

Dear Orbiter users and developers,

I haven't been around this place in quite some time, and for personal reasons haven't been able to push Orbiter development along for a few years now. In order to keep Orbiter alive and allow others to work on it, I have decided to publish the sources under an open source license:


This is essentially the 2016 Edition with some minor (and at least one major) fixes. I hope this is of use to somebody. The code is somewhat unorganised and sparsely documented, but it should compile and leave you with a working Orbiter installation. Note that the repository doesn't include all the required planetary textures, so you need to install those separately (e.g. by reusing an existing Orbiter 2016 installation - this is explained in the Readme and only requires setting a CMake option before configuring the build).

I am still hoping to work on future enhancements of Orbiter, but I can't make any promises or commitments. One of the most pressing issues is switching the code over to 64-bit, but this requires ditching the DX7 dependency (and ideally replacing it with DX11), but that is a major undertaking which I may or may not be able to do).

Please let me know of any compilation problems or any other issues with the repository, either here or by raising an issue on github. I am also happy to consider merge requests.

Happy coding!
Awesome news! Not really a programmer here, but as someone who has followed Orbiter's development/evolution for over 20 years, this is just fantastic news! Thank you Martin!

-RODION
 

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
9,808
Reaction score
652
Points
203
Location
between the planets
Thank you so much for everything, Martin! Orbiters influence is still keeping my family fed today! And seeing it go open source, under the MIT license no less, makes me suspect that there are great things ahead for Orbiter yet.

@anybody who may know: I have almost zero experience when it comes to graphics APIs (in fact, DIrectX7 is the last time I've directly used one...), do you think there is a chance the whole graphics layer could be moved to Vulcan? It's kind of becoming an industry standard, and it runs almost everywhere...

Also, direct support for a more common mesh format... That would be huge!

CMake presented itself as being a bit of a rabbit hole.
I thought "rabbit hole" was CMakes official nickname... 😬
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,335
Reaction score
378
Points
83
Website
users.kymp.net
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.

Also there is a possibility to go with Vulkan instead of DX11. Vulkan "might" offer better long term stability regarding the API but the implementation would be much more complicated. There already exists plenty of code and experience for DX11 where as the Vulkan would be a fresh start from scratch therefore not the easiest choice. Since, time is a limited resource the DX11 might have a better chance of success.

Now I just have to start learning Git and how to work with it.
 

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
9,808
Reaction score
652
Points
203
Location
between the planets
If the inline engine is replaced with DX11 then this would likely mean letting go the OVP and a physics/graphics separation.
Many architects would give an arm and a leg to have this level of backend-frontend separation in a realtime application, it would seem kind of a pitty to spend additional effort to avoid it. If anything, I would let go of the inline engine, and distribute with a default client instead...

Now I just have to start learning Git and how to work with it.
Oh... Best of luck. May God have mercy on your soul! 🤣
 

kalral

New member
Joined
Nov 22, 2020
Messages
23
Reaction score
13
Points
3
Location
Germany
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.

Also there is a possibility to go with Vulkan instead of DX11. Vulkan "might" offer better long term stability regarding the API but the implementation would be much more complicated. There already exists plenty of code and experience for DX11 where as the Vulkan would be a fresh start from scratch therefore not the easiest choice. Since, time is a limited resource the DX11 might have a better chance of success.

Now I just have to start learning Git and how to work with it.
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.

I kind of like github. I never had any problems with it and we can also set up CI too for every Pull-Requests. If you could use GUI then I guess you dont have to learn anything except pushing buttons (which we are really good at ;) )

Gui Clients :
1) https://www.syntevo.com/smartgit/
2) https://www.sourcetreeapp.com/

Both are good client IMO.

Interested how the orbiter development continues from here. Thanks @martins for all the wonderful work.
 

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
9,808
Reaction score
652
Points
203
Location
between the planets
I don't think you can hold a kickstarter without a company, and an upfront sum would be a bad idea for this use case anyways. If anything, a patreon-supported team might work, but you can't organise things like that. In general, it's a good idea to let things grow by themselves for a while before you throw money at it. Money makes everything... complicated.
 

Fabri91

Donator
Donator
Joined
Jun 2, 2008
Messages
2,107
Reaction score
93
Points
63
Location
Valmorea
Website
www.fabri91.eu
Many architects would give an arm and a leg to have this level of backend-frontend separation in a realtime application, it would seem kind of a pitty to spend additional effort to avoid it. If anything, I would let go of the inline engine, and distribute with a default client instead...
This.

What advantage does the version with integrated graphics client have over just shipping a client with orbiter_ng.exe by default?

Just maintaining the core server and a default client would seem to be both less work and more robust should a change to Vulkan or whatever other API of choice be desired in the future.
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,305
Reaction score
411
Points
123
Location
Vienna
This.

What advantage does the version with integrated graphics client have over just shipping a client with orbiter_ng.exe by default?

Just maintaining the core server and a default client would seem to be both less work and more robust should a change to Vulkan or whatever other API of choice be desired in the future.
I second that. In addition, it would help with x64 porting if only the core server is taken into account.
 
Top