Reentry - An Orbital Simulator

[Ouacaze]

Hello Orbiter people,
I wondered if some of you have already tried this ?
https://store.steampowered.com/app/882140/Reentry__An_Orbital_Simulator/

 

[Urwumpe]

I tried it, its really nice done, but it has some flaws as well, from small nitpicking (Rendezvous-Radar range is in ft, not kft as it should be) to really inaccurate state vectors (docking is pretty glitchy)

 

[4throck]

I tried an older version and it was good for switch flipping and cockpit views.
The cockpit models are great!
But I couldn't do much actual flying.

The external visuals were a bit poor, with unrealistic mirror like metal materials.
It looks a bit better now, but still, for a commercial game I expect better ...

 

[petriw]

Hi everyone, I'm the developer of Reentry.

First of all, thanks for good feedback here. I'm making most of the code, textures and models myself but in no way an expert on 3D modelling. I do try to revisit the models from time to time, and update them as my skills progress but mostly been focused on the orbital mechanics and the system integrations for Mercury, Gemini and Apollo. Hopefully the graphics will continue to improve as the project continues.

The state vectors itself should be quite realistic as far as I understand, but the docking flow, from a technical perspective, has been a hard nut to solve and is in the works.

I hope to create a good and fun simulator that is easy to start with, and can get more players interested in realistic space flight simulators such as Orbiter, NASSP etc.

I really appreciate all the feedback I can get as I wish to make a good game, so feel free to reach out as you try Reentry.

 

[IronRain]

and thank you for the feedback.

 

[Urwumpe]

The state vectors itself should be quite realistic as far as I understand, but the docking flow, from a technical perspective, has been a hard nut to solve and is in the works.

As I observed it, its mostly rounding errors. The position jumped about 20 cm instead of moving smoothly when approaching the target. The behaviour persisted after docking. Orbiter uses 64 bit doubles there, but you can observe a similar problem with docking in deep space at far distances to the sun.

 

[jedidia]

As I observed it, its mostly rounding errors. The position jumped about 20 cm instead of moving smoothly when approaching the target. The behaviour persisted after docking. Orbiter uses 64 bit doubles there, but you can observe a similar problem with docking in deep space at far distances to the sun.

32 bits should be plenty for orbital altitude, though... ?

 

[Urwumpe]

32 bits should be plenty for orbital altitude, though... ?

Not for orbital radius. Also a float does not have 32 bit for matisse, but just 23 bits. Just as example:


7000000 m radius (approx 350 km Alt) would be translated to



sign = 1
exponent = 1001 0101
fraction = 101 0101 1001 1111 1000 0000


If you add one to its fraction, the next radius would be


sign = 1
exponent = 1001 0101
fraction = 101 0101 1001 1111 1000 0001


Or 7000000.5 m



0.5 meter difference. Thats the issue there. (With a double, the next higher value would be 7000000.000000001)



A 32 fixed point number would fare better in that situation.

 

[jedidia]

7000000 m radius (approx 350 km Alt) would be translated to

Dammit, I had done a quick-check in my brain for orbital altitude, and completely forgot that the earth has a radius too! :rofl:

Depending on the engine used by the game, that could be a real killer...

 

[4throck]

I'm making most of the code, textures and models myself but in no way an expert on 3D modelling.

Your models are OK, it is really a matter of time!
You need to spend more time on external visuals, specially on materials and on those pads. They don't "sell" the product.

The VCs are very good and they "sell", because you clearly spent more time there .
Perhaps you should consider hiring someone just for tweaking the externals. I wouldn't mind working on that :lol:

 

[Urwumpe]

Depending on the engine used by the game, that could be a real killer...

It could be especially annoying if you render just one scene - GPUs use floats most of the time. Orbiter avoids this by rendering in multiple passes.

 

[petriw]

Ah, exactly, this is correct, and dealing with those floats is a big issue for me. The physics is custom and is using doubles now, but the engine is float based, so a conversion happens before rendering. Being honest, my game won't be as realistic and good as the Orbiter engine is - I'm a long time Orbiter player and I have a huge respect for what Orbiter has made, including this community. Once I get support for doubles, a lot of my issues will be solved but it will take a while to get there I assume.

I have a few dev-phases in mind, where I'm currently focusing on the core features of the engine and the planned mission flow (such as landing on the Moon). Once I have these I will revisit the internal systems again, before starting on content, polish and graphics.

At one point I was thinking that these panels I have been making (the models) could be used for an Orbiter add-on. I know it's possible to create working 3D panels in Orbiter, but I don't know the details.

 

[HarvesteR]

Indeed, before KSP had a floating origin implementation, you'd start to see FP jitter really quick. IIRC, about 10k out from the scene origin is enough to start seeing some shaking.

Cheers

 

[jedidia]

Indeed, before KSP had a floating origin implementation, you'd start to see FP jitter really quick. IIRC, about 10k out from the scene origin is enough to start seeing some shaking.

I'm still afraid to think about what you had to do to Unity to get that to work... :blink:

 

[Urwumpe]

At one point I was thinking that these panels I have been making (the models) could be used for an Orbiter add-on. I know it's possible to create working 3D panels in Orbiter, but I don't know the details.

Its fairly easy actually. But doing it without C++ code behind might be a bit limited. All you need is a mesh in Orbiters format. The rest is just animations, meshgroup manipulation and some event areas. You can decide which meshes of the full visual should be visible in VC mode, and you can fine tune the view frustrum to permit a lower minimal distance to the camera.



But I still recommend you to keep on working on your own engine - you have come pretty far, it looks great, the "gameplay" is enjoyable despite some issues and you could do things without fighting to fit them to Orbiters engine.



For example from my own work with a Gemini add-on: Integrating a mission control feature in the background into Orbiter without breaking immersion isn't really easy. Many classic manual control modes require some tricks. Sound is of course missing in vanilla Orbiter and the sound add-ons are often not doing what you really want.



And of course - Orbiters mesh file format isn't really made for modern graphics. You have more freedom outside Orbiter.



And after all - some more work smoothing the edges some more, and you would have a game that can be sold well... And if you can improve the quality enough that complaints of the gamers about bugs are not leaving you sleepless and further development not ending in lava cake. I had seen 25€ games at Steam that are really worse than Reentry.

 

[boogabooga]

Hi everyone, I'm the developer of Reentry.

First of all, thanks for good feedback here. I'm making most of the code, textures and models myself but in no way an expert on 3D modelling. I do try to revisit the models from time to time, and update them as my skills progress but mostly been focused on the orbital mechanics and the system integrations for Mercury, Gemini and Apollo. Hopefully the graphics will continue to improve as the project continues.

The state vectors itself should be quite realistic as far as I understand, but the docking flow, from a technical perspective, has been a hard nut to solve and is in the works.

I hope to create a good and fun simulator that is easy to start with, and can get more players interested in realistic space flight simulators such as Orbiter, NASSP etc.

I really appreciate all the feedback I can get as I wish to make a good game, so feel free to reach out as you try Reentry.

Thank you for being honest and not shilling the forum!

 

[Ouacaze]

Thanks everyone for your comments.
Petriw, that's some nice work for a single developer. Keep it up :thumbup:
Have you ever using a graphics engine like https://www.ogre3d.org/ ? I guess it could save some time.

 

[4throck]

At one point I was thinking that these panels I have been making (the models) could be used for an Orbiter add-on. I know it's possible to create working 3D panels in Orbiter, but I don't know the details.

As Urwumpe mentioned, you would soon start to fight Orbiter itself.
Orbiter has major problems with clipping and lights on the cockpit views, advanced materials, etc, etc.
The mesh format is TXT based so you can't really have big meshes.


So I'd focus on your own simulator. It only needs more work and eye candy for more sales. :thumbup:

 

[thammond]

One of the features I like most in a simulator is how accurate and complete are all the various systems of the vehicle modeled. I haven't seen any mention of that aspect in this thread. Could anyone who has used both comment on that aspect of Reentry vs the Mercury, Gemini, and/or Apollo addons for orbiter.

What I've seen in reviews and videos of the product look impressive.