Roadmap proposal - Orbiter development

[Max-Q]

I was thinking more to massive Martian dust storms, Venusian global thunderstorms like a neverending flak barrage and alien Titan ethane-chemistery, but yeah, that too

The only difference is scale… some new API functions could take care of both large and small scale weather.
However, I think small-scale earth weather is a better short term goal, launch WX is something to be dealt with on every mission, and something like global mars WX only really matters if you are going to the Martian surface…

 

[jedidia]

Please be careful with dependencies. Make sure theres a good reason not to just write our own.

True, dependencies have to be carefully evaluated.
However, if they're open source, license compatible and simple enough to integrate, and are considered beneficial enough, there's not really a reason to reinvent the wheel. Bullet fulfills the first 2 criteria, the third one needs to be looked into, and the fourth one needs to be discussed.

 

[Urwumpe]

True, dependencies have to be carefully evaluated.
However, if they're open source, license compatible and simple enough to integrate, and are considered beneficial enough, there's not really a reason to reinvent the wheel. Bullet fulfills the first 2 criteria, the third one needs to be looked into, and the fourth one needs to be discussed.

I think the other key questions for any dependency, that could really be an improvement, should still be:

What are the alternatives?
How much effort will it be to switch to another?
How can we gradually degrade our functionality, should we have to remove a dependency for a while?
How good is the support of the development team of that dependency?

 

[N_Molson]

Perhaps the most important thing we should not forget (which is always very easy) is that the project has to move forward. Rules are necessary and a good thing but they are not themselves the objective, they are means to help reaching that goal.

I'd say in the end do what you can with the time you have, releasing a new iteration every year quarter with a few fixes would already put the project on the road, and I'm pretty sure it would speed things up. People are interested to participate to living projects, and then they can contribute to development, and so on... virtuous circle. ?

 

[Urwumpe]

Yeah, or as we evil cultists say in our creed:

Manifesto for Agile Software Development​

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

 

[jedidia]

Of course, you have to really watch it that you don't drift into the corporate version of it:

Manifesto for Half-Arsed Agile Software Development​

We have heard about new ways of developing software by
paying consultants and reading Gartner reports. Through
this we have been told to value:

Individuals and interactions over processes and tools -
and we have mandatory processes and tools to control how those
individuals (we prefer the term ‘resources’) interact

Working software over comprehensive documentation -
as long as that software is comprehensively documented

Customer collaboration over contract negotiation -
within the boundaries of strict contracts, of course, and subject to rigorous change control

Responding to change over following a plan -
provided a detailed plan is in place to respond to the change, and it is followed precisely

That is, while the items on the left sound nice
in theory, we’re an enterprise company, and there’s
no way we’re letting go of the items on the right.

 

[N_Molson]

Yeah, but Orbiter is not a buisness and makes no money, that's other thing to keep in mind.

 

[4throck]

It would be good to adopt a more standard mesh format, like FBX.
It's supported by Blender (so we'd have an open-source 3D editor) and handles animations...
We might even use it to import camera, thruster and light placements, and perhaps collision blocks later on.
If the goal is really to create a new Orbiter, then this is the way forward, as the existing mesh format is a dead end.

 

[Max-Q]

It would be good to adopt a more standard mesh format, like FBX.

NO NO NO!
A modern mesh converter with a GUI and more options/features would be a lot easier to make!

Meshes are the one thing that aren’t broken by core updates! This would keep EVERY addon created for older versions from EVER working/being updated!
Cameras and animations should be handled by the dll, not an external file!
However, since meshes are just plain text, more sections could be added at the end to allow increased functionality. (This is how X-Plane models work)

 

[jedidia]

Meshes are the one thing that aren’t broken by core updates! This would keep EVERY addon created for older versions from EVER working/being updated!

There can be support for multiple mesh formats. I agree that removing the native mesh format would be a very bad idea, but I also agree that introducing support for a modern standard would be extremely beneficial.

 

[Max-Q]

There can be support for multiple mesh formats. I agree that removing the native mesh format would be a very bad idea, but I also agree that introducing support for a modern standard would be extremely beneficial.

Totally agree! I have nothing against new features (I actually really love ‘em) but keeping backward compatibility is very important.

 

[n72.75]

I think the other key questions for any dependency, that could really be an improvement, should still be:

What are the alternatives?
How much effort will it be to switch to another?
How can we gradually degrade our functionality, should we have to remove a dependency for a while?
How good is the support of the development team of that dependency?

That is essentially what I mean by "be careful". Something like Boost or Eigen (license permitting) would be okay. But don't put anything in that you don't want to take out later, if support drops, incompatibilities arise, etc..

 

[Urwumpe]

That is essentially what I mean by "be careful". Something like Boost or Eigen (license permitting) would be okay. But don't put anything in that you don't want to take out later, if support drops, incompatibilities arise, etc..

I think Boost is a rock solid dependency in C++, but of course always working on making itself obsolete.

Anything that could be more fleeting should better be put into external modules. I really prefer some more "microkernel" like architecture of Orbiter over a big bloated monolith. Especially since it could make supporting Linux versions easier, since Orbiter could still ship with modules, that might be better or worse in Linux then their windows counterparts.

 

[supersonic71]

1. Create "virtual filesystem" support, so an addon (vessel, textures) can be installed to a separate directory without polluting the root
2. Support packaged addons (e.g. zip or custom format)

This is a brilliant idea and would make addon management much simpler and easier for new and experienced users alike!

Here are some of my additional suggestions for future roadmap (after the initial release of OpenOrbiter) :

Realism
1. Artemis missions are going to be the highlight of this decade. The Gateway would be in NHRO orbit. So I think improving accuracy around lunar region (mascons) would be very useful, after all realism is one of Orbiter's main selling points.
More discussion here : <Edit : I can't find the thread! Does anyone remember what the title was? >
Since GMAT is also open source, is it possible to borrow some code from that?
2. Improved aerodynamics for addons, perhaps a common library each addon creator can use? https://www.orbiter-forum.com/threads/does-orbiter-really-have-realistic-aerodynamics.40390/

Graphics
1. We can rework the models to a higher quality and upscale many of the old textures. Check out screenshots section in the Discord, Oval has made a very impressive model of the Dragonfly.
2. I agree with supporting more model formats.
3. Texture streaming for Planets (I assume this will take a lot of work, so maybe after some release cycles).


Personally - I can help with QA, I'm also good at aerodynamics and learning C++ so I'll try to contribute to that and also texture upscaling.
Maybe we could divide ourselves into teams and the Orbiter council will give us tasks ?

PS : If I have feature requests or Bug reports, should I post it in the forum or Github issues?

 

[jedidia]

1. Artemis missions are going to be the highlight of this decade. The Gateway would be in NHRO orbit. So I think improving accuracy around lunar region (mascons) would be very useful, after all realism is one of Orbiter's main selling points.

I agree. Something like having a thing in-between a celestial body and a vessel might be beneficial here. Appears mostly as a vessel in sim, but like a celbody can have a static trajectory either defined by orbital elements, or an ephemeris. Would need some tooling to create an ephemris, I guess...

We can rework the models to a higher quality and upscale many of the old textures. Check out screenshots section in the Discord, Oval has made a very impressive model of the Dragonfly.

The dragonfly would need somewhat of a rewrite anyways, I'm afraid. It's not fully functional in Orbiter 2016...

 

[4throck]

Totally agree! I have nothing against new features (I actually really love ‘em) but keeping backward compatibility is very important.

Well, I defended backward compatibility (with Orbiter 2010), but people don't seem to be interested...
So I thought about moving forward and what would make me go back to 3D modeling for Orbiter (and eventually new addons).

Working with standard game development tools/formats is a necessity.

I don't want to downgrade a 3D model in order to export it to Orbiter with primitive texturing, normal problems, etc. It's better to simply save it using a standard format.
Also, it makes no sense to add lights by code, when you can add them on the 3D program. The same for animations. The artist can do all that perfectly using a 3D modeling program (ex. Blender).
It's irrational to make the programmer mess with a 3D model, noting down spatial coordinates and angles to hard-code animations... That's just dumb.

But I'll repeat myself - it would be good to actually ask the community about what people want, before wasting time with stuff that no one will use.

 

[Face]

But I'll repeat myself - it would be good to actually ask the community about what people want, before wasting time with stuff that no one will use.

You are right. I get the impression that the people here are the only one left from the community, though. The question is: how do we reach out to the "community" to ask what they want, if they are not on the forums to discuss it like in this thread?

 

[Urwumpe]

Does anybody here have the time to act as an active community builder? I doubt, I could do this job, since I am the worst kind of character for it and don't really know if I could take that commitment, especially since I know what this job would require to be done well:

• Continuous improvement
• Visible work
• Offered help
• an established rhythm

But maybe thats a chance to get more people into Orbiter development, produce more content to show. Maybe we even really just should play with our underdog status and offer some playful rebellion against KSP. Leaving the playground. We need to attract younger people, because I think we are all too adult now and behave way too adult at times.

I doubt that for the next five years, we can offer a real technological superiority to KSP or what is planned to come with KSP2. And thats OK, we are no commercial game studio, we have all other jobs to do. But KSP is a business now, it can be owned by somebody who might even one day be outside the community, while Orbiter is now our "Common Land".

Nobody can now take Orbiter from us.

 

[n72.75]

Realism
1. Artemis missions are going to be the highlight of this decade. The Gateway would be in NHRO orbit. So I think improving accuracy around lunar region (mascons) would be very useful, after all realism is one of Orbiter's main selling points.
More discussion here : <Edit : I can't find the thread! Does anyone remember what the title was? >

Thread 'Improved (Tesseral) Gravity Model' https://www.orbiter-forum.com/threads/improved-tesseral-gravity-model.40266/

It needs a little help with loading (the actual function that loads the coefficients works fine, but Orbiter doesn't call it.) Probably a dumb typo.

The perturbation function itself works well and gives identical results to the paper it references. Need to make sure theres no sign error going to Orbiter's weird coördinate system.

 

[4throck]

A good way to reach out to the community might be to place a link to Google Forms on all orbiter sites.
The form could be very simple, with just a few questions to know how the sim is used (version, how much time spent per week, what type of flights, what add-ons).
It could be a nice introduction for the Council.