Roadmap proposal - Orbiter development

[Urwumpe]

I think most people are. As far as I can see, most references to KSP are not about mechanics, but about interface, and that's not strongly coupled to the purpose. Maybe it would be fair to say that it would be great for the orbiter core to provide a solid UI layer?

Yeah. How much effort would it take to replace all C++ and Windows specific code with something operating on the GPU? Like allowing different themes or window managers inside Orbiter, and UI plugins are defined in Lua?

 

[jedidia]

Yeah. How much effort would it take to replace all C++ and Windows specific code with something operating on the GPU? Like allowing different themes or window managers inside Orbiter, and UI plugins are defined in Lua?

An unholy amount of effort I'm afraid...

 

[Urwumpe]

An unholy amount of effort I'm afraid...

I found a hotfix for that.

Depart, then, transgressor.
Depart, seducer, full of lies and cunning, foe of virtue, persecutor of the innocent.
Give place, abominable creature, give way, you monster, give way to Christ, in whom you found none of your works.
For he has already stripped you of your powers and laid waste your kingdom, bound you prisoner and plundered your weapons.
He has cast you forth into the outer darkness, where everlasting ruin awaits you and your abettors.

Maybe we can get a bishop for this task, to compile & run those old sources.

 

[Kyle]

Ditto the desire not to turn Orbiter into a more niche version of KSP RO/RSS.

@Felix24 mentioned "bringing in more users should be the top priority": do you think that increasing the visibility of Orbiter would help? Most new players usually hear of Orbiter second hand or google "Spaceflight simulators" and stumble across Orbiter. Maybe stable builds can be posted on Steam.

 

[N_Molson]

I found a hotfix for that.

Depart, then, transgressor.
Depart, seducer, full of lies and cunning, foe of virtue, persecutor of the innocent.
Give place, abominable creature, give way, you monster, give way to Christ, in whom you found none of your works.
For he has already stripped you of your powers and laid waste your kingdom, bound you prisoner and plundered your weapons.
He has cast you forth into the outer darkness, where everlasting ruin awaits you and your abettors.

Maybe we can get a bishop for this task, to compile & run those old sources.

So, you have better than "those old sources" ? I'm not sure cynism helps a lot...

 

[n72.75]

imgui?

Never worked with it but I've heard it's easy to work with and cross-platform.

 

[Gondos]

imgui?

Never worked with it but I've heard it's easy to work with and cross-platform.

Yeah, ImGui is an option but the result may not be as sexy as you think :

 

[Urwumpe]

So, you have better than "those old sources" ? I'm not sure cynism helps a lot...

It isn't meant to be cynism. Rather not seeing unholy efforts as a showstopper at all. Just as a problem to think more about.
(Because if the effort is unholy, you maybe did not begin with the best plan)

imgui?

Never worked with it but I've heard it's easy to work with and cross-platform.

And it supports multiple different renderers by different backends. Maybe really a good option to try. Who should be responsible for it, Orbiters core or the Rendering client?

 

[jarmonik]

Yeah. How much effort would it take to replace all C++ and Windows specific code with something operating on the GPU? Like allowing different themes or window managers inside Orbiter, and UI plugins are defined in Lua?

I was developing a Sketchpad based GUI running on a GPU long ago but since it received no interest from the community it got abandoned. It's difficult for a one developer to push any core features without proper support/approval from the community. https://www.orbiter-forum.com/threads/d3d9client-development.16787/post-262584

Also we would need a vessel editor that could be used to configure different aspects of a vessel (physics and graphics) when things evolve it becomes too complicated to configure everything with mere API calls. As an example a particle effect that could be customized by modifying s-pline curves via mouse, granting a higher level of freedom for customization. Editor with a proper GUI is required. A GUI that often seen in a 3D modelling softwares.

 

[Urwumpe]

I was developing a Sketchpad based GUI running on a GPU long ago but since it received no interest from the community it got abandoned. It's difficult for a one developer to push any core features without proper support/approval from the community. https://www.orbiter-forum.com/threads/d3d9client-development.16787/post-262584

Yeah, it really was ahead of its time - nobody expected Orbiter to become FOSS then.

Also we would need a vessel editor that could be used to configure different aspects of a vessel (physics and graphics) when things evolve it becomes too complicated to configure everything with mere API calls. As an example a particle effect that could be customized by modifying s-pline curves via mouse, granting a higher level of freedom for customization. Editor with a proper GUI is required. A GUI that often seen in a 3D modelling softwares.

Where would you draw the line (in terms of features) between such a vessel editor and modelling tools like Blender?

I agree that especially composing larger visuals and planning more complex animations could really profit from such a tool. But I don't think we could for example edit all possible physical features of a spacecraft that way. It might solve many problems with touchdown points or placing thrusters onto a mesh. Maybe also for VCs or 2D panels. But doing subsystems or dedicated displays might become weird. Could be done inside such an editor of course, but especially also supporting frameworks or larger mods (OrbiterSound, UCGO, UMMU) might require some more complexity.

 

[DaveS]

Also we would need a vessel editor that could be used to configure different aspects of a vessel (physics and graphics) when things evolve it becomes too complicated to configure everything with mere API calls. As an example a particle effect that could be customized by modifying s-pline curves via mouse, granting a higher level of freedom for customization. Editor with a proper GUI is required. A GUI that often seen in a 3D modelling softwares.

Fred18's VesselBuilder is a great step in this direction as it allows you to test everything related to your vessel directly in-game at the moment without having to exit and reload.

 

[jedidia]

I found a hotfix for that.

What's that, exorcist ipsum??

Yeah, ImGui is an option but the result may not be as sexy as you think :

In my experience, how sexy a UI looks mostly depends on how much time you spend on making it sexy, not on the framework...

Who should be responsible for it, Orbiters core or the Rendering client?

Yeah, that's where I really start wondering a bit... Rendering it is obviously the clients job, since, well, rendering, but if we outsource it to the client entirely, you'll need to pull in the client into every project that wants to use it, which seems a bit overkill. So I'd say the core should at least provide an interface for it. Also, because if there was a decent UI layer, then there's lots of occasions where it will be advantageous to use it directly in a vessel panel or virtual cockpit...

 

[supersonic71]

1. Cut off "release/2022/01" branch, focus backward compatibility work there

Hi, was wondering if someone is working on this? aka the final dx7 release
(Hope I'm not being rude, I understand many have busy day jobs)


Quite exciting to read all the ideas!
Regarding if popular spacecraft should be addon or in-built, I do think there should be atleast one popular rocket by default (maybe Falcon9). Also in-built ISS can be replaced by one of the ISS add-ons (with the authors permission/license).

 

[Face]

Hi, was wondering if someone is working on this?

I am. But of course this is not "official" work. No clue if anybody else is doing something at all currently.

 

[Gondos]

In my experience, how sexy a UI looks mostly depends on how much time you spend on making it sexy, not on the framework...

I couldn't agree more

Yeah, that's where I really start wondering a bit... Rendering it is obviously the clients job, since, well, rendering, but if we outsource it to the client entirely, you'll need to pull in the client into every project that wants to use it, which seems a bit overkill. So I'd say the core should at least provide an interface for it. Also, because if there was a decent UI layer, then there's lots of occasions where it will be advantageous to use it directly in a vessel panel or virtual cockpit...

ImGui nicely splits the backend (D3D/OpenGL...) and the framework (glfw/WinAPI/SDL...) so you can put the backend specifics in the OVP Client and the addons will only need to work with the ImGui API in a generic way.
The really nice thing about ImGui is in the docking/viewport branch : widgets are drawn on the GPU in the main window context, but if you drag an ImGui window outside the boundaries of the main window, it will seamlessly create a new window and render in it. That's very useful for things like External MFDs.
Immediate mode rendering really make dialogs easy to work with. For example you can do :

void XR1PayloadDialog::Show() {
...
    if(ImGui::Button("Empty Payload Bay")) {
            // Remove all items of the currently-selected payload.
            m_pDGXR1->m_pPayloadBay->DeleteAllAttachedPayloadVessels();
            m_pDGXR1->PlaySound(m_pDGXR1->SwitchOff, DeltaGliderXR1::ST_Other, MED_CLICK);  // medium click
    }
...
}

in the core you ask the client to draw the UI after the 3D scene:

int Orbiter::Run () {
...
        if (bRenderOnce && bVisible) {
            Render3DEnvironment();
            RenderGUI();
            DisplayFrame();
            bRenderOnce = false;
        } else {
            RenderGUI();
            DisplayFrame();
        }
...
}
void Orbiter::RenderGUI ()
{
    if (gclient) {
        gclient->clbkRenderGUI ();
    }
}

and in the client you do the actual work of calling the dialogs display method :

void OGLClient::clbkRenderGUI ()
{
    ImGui_ImplOpenGL3_NewFrame();
    ImGui_ImplGlfw_NewFrame();
    ImGui::NewFrame();
    for(auto &ctrl: g_pOrbiter->m_pGUIManager->m_GUICtrls) {
        if(ctrl->show) {
            ctrl->Show();
        }
    }
    ImGui::Render();
    ImGui_ImplOpenGL3_RenderDrawData(ImGui::GetDrawData());
    ImGuiIO &io = ImGui::GetIO();
    if(io.ConfigFlags & ImGuiConfigFlags_ViewportsEnable) {
        GLFWwindow* backup_current_context = glfwGetCurrentContext();
        ImGui::UpdatePlatformWindows();
        ImGui::RenderPlatformWindowsDefault();
        glfwMakeContextCurrent(backup_current_context);
    }
}

It's far from perfect but it's a start.
The bad thing is that the ImGui library becomes a de facto part of the OrbiterSDK and it's really an active project so keeping a stable ABI may be a problem if we want to keep it up to date. Also if you want to do some UI work in lua, it's going to be a problem (is it not already the case?).
A solution would be to abstract the ImGui API behind oapi calls but it would require some extensive work...
The same is true with the Windows API in the current Orbiter version but obviously its ABI is far more stable

 

[jarmonik]

I have looked at the ImGui GitHub page and it could be a good candidate to solve the GUI problem. Although, I haven't studied to code yet or it's integration to the Orbiter.

Where would you draw the line (in terms of features) between such a vessel editor and modelling tools like Blender?

In the Vessel Editor user would NOT modify vertices or create meshes. There are plenty of tools for that including the Blender.

• In the editor one could create and attach a particle effects to a vessel, test fire and tune them in a real time.
• Configure and attach reflection cameras into a vessel and bind the reflections to a mesh groups.
• Configure other visual effects that we have discussed (i.e. "condensation effect", "volumetric engine exhaust").
• Material properties and mesh-group flags could be edited.
• Naming a mesh groups so that a group could be identified my it's name instead of index alone.
• Attaching and configuring local light-sources and shadowing behavior.

Later future:

• Attaching grapple-points, docking-ports, etc... into a vessel.
• Creating animation components and attaching mesh-groups into them.
• Editing collision parameters for mesh-groups.

Also we could improve rendering efficiency and enable higher level of detail in meshes by a use of LOD control. This would require having a poly reduction algorithm build in to the Orbiter. Mesh poly count would reduce by distance (maybe 3 or 4 LOD levels would be needed). Startup times could be improved by storing the meshes in a client specific binary format in a mesh cache folder. No need to read/reprocess a text based mesh file if a binary file is up-to-date.

 

[jarmonik]

I have been working on overhaul of the atmospheric rendering. Earth, Mars and Moon are done already but gas-giants are still pending. Orbital rendering haven't changed much but low-altitude rendering looks much better.

 

[Urwumpe]

I have been working on overhaul of the atmospheric rendering. Earth, Mars and Moon are done already but gas-giants are still pending. Orbital rendering haven't changed much but low-altitude rendering looks much better.

What are you changing? Are there any new parameters for add-on developers for tweaking the rendering?

 

[n72.75]

Sodium layer?

 

[Sword7]

I agree 100%. How about macOS platform?