Roadmap proposal - Orbiter development

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
36,873
Reaction score
1,533
Points
203
Location
Langendernbach
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

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,297
Reaction score
1,487
Points
203
Location
between the planets
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

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
36,873
Reaction score
1,533
Points
203
Location
Langendernbach
An unholy amount of effort I'm afraid...

I found a hotfix for that.

Code:
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

Armchair Astronaut
Addon Developer
Joined
Mar 17, 2008
Messages
3,902
Reaction score
306
Points
123
Website
orbithangar.com
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

Addon Developer
Addon Developer
Donator
Joined
Mar 5, 2010
Messages
8,865
Reaction score
2,610
Points
203
Location
Toulouse
I found a hotfix for that.

Code:
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...
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
36,873
Reaction score
1,533
Points
203
Location
Langendernbach
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

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

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
36,873
Reaction score
1,533
Points
203
Location
Langendernbach
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

Space Shuttle Ultra Project co-developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,282
Reaction score
563
Points
203
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.
 
Last edited:

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,297
Reaction score
1,487
Points
203
Location
between the planets
I found a hotfix for that.
What's that, exorcist ipsum?? :ROFLMAO:

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

Member
Joined
Sep 20, 2021
Messages
59
Reaction score
82
Points
18
Location
Asia Pac
Website
github.com
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! :giggle:
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).
 

Gondos

Member
Joined
Apr 18, 2022
Messages
84
Reaction score
73
Points
18
Location
On my chair
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:LOL:

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 :
Code:
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:
Code:
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 :
Code:
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

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

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

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
36,873
Reaction score
1,533
Points
203
Location
Langendernbach
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?
 
Top