Project Orbiter-Unity Virtual Reality Simulator

[miquelbb]

In the Institute of Space Systems (IRS) of the University of Stuttgart we are currently upgrading our Soyuz Simulator (which is based on Obriter) to a new Virtual Reality simulator developed with the Unity game engine. The new simulator should offer a realistic cockpit interface of the new Russian Spacecraft PTK-Federatsiya (3D Model offered by Scorpius) and perform Earth, lunar and martian missions, mostly docking procedures to the LOP-G.
This thread should open up a discussion on how to develop such a simulator.
The new simulation will be a combination of Unity and Orbiter softwares. We base the orbital mechanics and overall physical simulation on Orbiter, and the spacecraft parameters (Positions, attituted, subsystem status, etc) are sent via an Orbiter Add-on to Unity. The respective client in Unity reads the data and updates the VR environment with the needed values.
As of today, we are still developing the cockpit interfaces and improving the visualization of planets, spacecraft and general lighting.
I look forward to your ideas, recommendations and critics. Soon I'll post some images/videos of the development. If this works, Orbiter will become a VR-Ready Software (for some parts of the flight :thumbup: )

 

[Urwumpe]

How are you planning to design the interactivity in VR?

 

[jedidia]

Unity's coordinate system is in floats, if I'm not mistaken. How are you planning to address the precision issue arising from that?

 

[Urwumpe]

Unity's coordinate system is in floats, if I'm not mistaken. How are you planning to address the precision issue arising from that?

Actually, the rendering in Orbiter is already done with just floats... Most GPUs are very bad in processing doubles....

 

[Face]

Why going through the troubles of sending values between processes if there already is a graphics client infrastructure that could be used (aka OVP)? I think it would be better to have e.g. a UnityClient OVP module that supports VR instead of a com module that sends data to a completely different project.

Is it to keep the VR system closed source?

 

[Urwumpe]

Is it to keep the VR system closed source?

 

[Face]

I actually missed that XKCD, thanks for linking it.

Besides the pathetic attempt on ridiculing an honest question, do you actually KNOW the reason why the described design is not using OVP?

 

[jedidia]

I think it would be better to have e.g. a UnityClient OVP module that supports VR instead of a com module that sends data to a completely different project.

Is that even possible, though? I'm not sure at all whether you can just squeeze its runtime into another process, as Unity appears to be more of a framework rather just an engine.

 

[Face]

Is that even possible, though? I'm not sure at all whether you can just squeeze its runtime into another process, as Unity appears to be more of a framework rather just an engine.

It is not about squeezing it into another process, but whether or not you implement the OVP interface to interact with it. Iˋve experimented with Unity embedded in WPF applications already, and it looked promising, thus my first question.

If - for whatever reason .- OVPs license is a problem, Iˋd of course understand the need to forward the values to a separate project. Thus my other question.

 

[jedidia]

Ah, I misunderstood. You're talking about the use of OVP specifically, not about the server/client approach in general.

 

[Face]

Ah, I misunderstood. You're talking about the use of OVP specifically, not about the server/client approach in general.

We already had OVP clients that send data to lean render clients (AFAIK Artlav did that with some OGLA experiment). The point is that there is already a separation interface with OVP.

BTW: I just checked, I can load and start the UnityPlayer.dll of a standalone build just fine inside a custom executable. As it appears, the whole engine is running inside this process. Granted, there is no API as such, but it should be much easier to exchange data between script land and the Orbiter module with such an approach.

 

[palebluedot]

Hi Face,

I am interested in this too. Are you using -parentHWND as mentioned here: https://stackoverflow.com/questions/44059182/embed-unity3d-app-inside-wpf-application

One of the reasons I want to develop a Unity renderer that's a separate process and communicates through a socket/shared memory/named pipe with a OVP module in the Orbiter process, is to allow the Orbiter process to be stopped and restarted with a different planetary system or scenario

Probably the OVP module would simply forward the callback arguments to Unity via a socket and accept the return values. I think local sockets use shared memory anyway, so it will be fast enough for rendering. Using Unity does give access to a great editor and physics, collisions etc, though properly handling them can be tricky.

 

[Face]

Hi Face,

I am interested in this too. Are you using -parentHWND as mentioned here: https://stackoverflow.com/questions/44059182/embed-unity3d-app-inside-wpf-application

No, it is in-process. No second process I steal the window handle from or somesuch.

 

[bjsikkem]

In the Institute of Space Systems (IRS) of the University of Stuttgart we are currently upgrading our Soyuz Simulator (which is based on Obriter) to a new Virtual Reality simulator developed with the Unity game engine. The new simulator should offer a realistic cockpit interface of the new Russian Spacecraft PTK-Federatsiya (3D Model offered by Scorpius) and perform Earth, lunar and martian missions, mostly docking procedures to the LOP-G.
This thread should open up a discussion on how to develop such a simulator.
The new simulation will be a combination of Unity and Orbiter softwares. We base the orbital mechanics and overall physical simulation on Orbiter, and the spacecraft parameters (Positions, attituted, subsystem status, etc) are sent via an Orbiter Add-on to Unity. The respective client in Unity reads the data and updates the VR environment with the needed values.
As of today, we are still developing the cockpit interfaces and improving the visualization of planets, spacecraft and general lighting.
I look forward to your ideas, recommendations and critics. Soon I'll post some images/videos of the development. If this works, Orbiter will become a VR-Ready Software (for some parts of the flight ? )

I know I'm resurrecting a very old thread here, but hoping you may still be online. Very curious to hear more about your project!

 

[Sbb1413]

The project is dormant, probably because the Stuttgart University is closed due to the COVID-19 pandemic. I am pinging to @miquelbb to get a response.

I have read the explanation of this xkcd at here. Richard did a good job on initiating the GNU Project.

 

[Urwumpe]

The project is dormant, probably because the Stuttgart University is closed due to the COVID-19 pandemic. I am pinging to @miquelbb to get a response.

I have read the explanation of this xkcd at here. Richard did a good job on initiating the GNU Project.

Yeah, but at the same time, the comic is a smart parody of a certain attitude among the free software world, that still sees itself under threat from closed-source and "not really free" software licences. And lots of flamewars about what actually free open-source software is and that the other licence is not following the true path.

Thus that reference as reaction to asking the already alert question of wether a certain design choice was made to keep things closed-source, instead of maybe being less assuming and maybe just ask, why it can't use a certain existing component there to solve a problem. There can be millions of design choices and factors. Not knowing that a certain library provides a certain functionality is even a more likely than any well-thought design decision against it. Maybe being open yourself is wiser than already searching your katanas under the bed.

But what do I know? I am not caring enough about FOSS to really matter, me little heretic.

 

[bjsikkem]

See, I'm sitting here thinking that if one's goal was VR, then using Unity to do the visuals makes a lot of sense because there's tons of VR support readily available. Rather than trying to bake something from complete scratch with OVP. I am but a programming peon and I've made functional VR apps in Unity!

Which is what interested me about this thread. I actually had been working a few years back on a VR Mercury simulator (mainly for my own purposes - someone else already has built a full Mercury VR sim in Steam) using Unity. But I was baking my orbital simulation completely from scratch. The idea of using Orbiter to run the math and Unity to do the visuals had never occurred to me!

Katana fights can be fun sometimes, though.