Project Skybolt Client Development

[MattR]

I've started working on a graphics client which integrates the Skybolt engine. The code is available here: https://github.com/Piraxus/OrbiterSkyboltClient

Skybolt is an open-source OpenSceneGraph (OpenGL) based renderer I'm developing. The planet tiles in the screenshots are from Mapbox with data up to level 16. The engine uses Eric Bruneton's atmospheric scattering model. I recently did a write-up about the volumetric clouds which might be of interest.

Some early screenshots:

 

[Face]

Looks awesome, nice work! I wonder if it would be a good base for OpenXR support, so I can finally sit in the DG in VR.

Do you transform terrain data to texture tree tile, or manipulate it in memory? Just asking because Martin recently merged a proposal for a collision tile manipulation callback, perhaps this is of interest to you.

 

[MattR]

Looks awesome, nice work! I wonder if it would be a good base for OpenXR support, so I can finally sit in the DG in VR.

Yes, I'd like to support VR, that would be awesome.

Do you transform terrain data to texture tree tile, or manipulate it in memory? Just asking because Martin recently merged a proposal for a collision tile manipulation callback, perhaps this is of interest to you.

I'm not using Orbiter's terrain tiles, rather I'm using my own terrain engine which streams tiles off an online TMS server such as Bing maps or Mapbox. Tiles are organized in a quadtree structure like orbiter.

Regarding collision callback, one possibility is orbiter could query the renderer for terrain elevation when performing intersection queries. The query should be async to allow the renderer time to load the relevant tile in a background thread and respond to the query when data is available. The tiles are cached in memory in an LRU cache. If there's a cache miss it queries the hard disk cache. If that misses, it downloads from the internet. So, async is critical to avoid stutters. I haven't implemented tile deformation due to collision events, but in that case I would modify the image in memory re-upload to GPU.

 

[Face]

I'm not using Orbiter's terrain tiles, rather I'm using my own terrain engine which streams tiles off an online TMS server such as Bing maps or Mapbox. Tiles are organized in a quadtree structure like orbiter.

Regarding collision callback, one possibility is orbiter could query the renderer for terrain elevation when performing intersection queries. The query should be async to allow the renderer time to load the relevant tile in a background thread and respond to the query when data is available. The tiles are cached in memory in an LRU cache. If there's a cache miss it queries the hard disk cache. If that misses, it downloads from the internet. So, async is critical to avoid stutters. I haven't implemented tile deformation due to collision events, but in that case I would modify the image in memory re-upload to GPU.

I see. That is not possible now, I fear. Would mean quite some refactoring in the core, and it would possibly break the whole OVP chain.
What do you do for all the other planets besides Earth?

 

[MattR]

I see. That is not possible now, I fear. Would mean quite some refactoring in the core, and it would possibly break the whole OVP chain.
What do you do for all the other planets besides Earth?

I haven't solved the issue of other planets yet, but potentially I'll add orbiter's tile tree as a tile source which can be used as a baseline, with the option of switching to a different source if one is available.

 

[kalral]

I haven't solved the issue of other planets yet, but potentially I'll add orbiter's tile tree as a tile source which can be used as a baseline, with the option of switching to a different source if one is available.

If it is possible to switch between Tile sources and Online TMS server while the simulation is running, it would be super cool. When the spacecraft is near earth, the TMS server can be used to render earth and when near other planets, Orbiters tiles can be used to render the planets. What you have already is super cool. I am excited.

 

[MattR]

Here's an update showing HUD and panel elements rendering in OpenGL.

MFDs are not working yet because I haven't implemented sketchpad for OpenGL. I plan to integrate an existing GPU 2D drawing framework for that purpose. I haven't chosen the framework yet, but SDL and NanoVG look like possibilities. My only concern with using a GPU backend for sketchpad is the Sketchpad:: Pixel() call. If the user tries to paint an entire image with individual pixels, the GPU command list will get very long and inefficient. In that case it would be better to generate an image on CPU and upload to GPU, however this is hopefully not a common use case.

 

[jedidia]

My only concern with using a GPU backend for sketchpad is the Sketchpad:: Pixel() call. If the user tries to paint an entire image with individual pixels, the GPU command list will get very long and inefficient. In that case it would be better to generate an image on CPU and upload to GPU, however this is hopefully not a common use case.

It isn't. Most developers are aware that sketchpad should be used for vector drawing only.

 

[OvalDreamX]

First of all, WOW!! Those clouds and that sky look awesome!! Srry if this is a dumb question, but Idk much about graphic clients haha. Are you planning on adding proper shading for the vc? Like shadows and pseudo ambient light and such

 

[MattR]

Are you planning on adding proper shading for the vc?

The client uses modern shadowing and lighting techniques. Shadows are rendered with cascaded shadow mapping, which is standard for modern games. Lighting uses a cut-down version of the Disney BRDF physically based lighting shader. Ambient lighting approximation is provided by a spherical light probe that captures the ambient environment, which gives decent looking glossy reflections.

 

[OvalDreamX]

The client uses modern shadowing and lighting techniques. Shadows are rendered with cascaded shadow mapping, which is standard for modern games. Lighting uses a cut-down version of the Disney BRDF physically based lighting shader. Ambient lighting approximation is provided by a spherical light probe that captures the ambient environment, which gives decent looking glossy reflections.

Awesome! But idk if I expressed myself properly (im learning english still), does that mean proper shadows in the virtual cockpit/internal view?

 

[MattR]

Awesome! But idk if I expressed myself properly (im learning english still), does that mean proper shadows in the virtual cockpit/internal view?

Ah, yes virtual cockpit/internal geometry receives shadows just like in external view.

 

[DaveS]

How are reflections handled? Similar to D3D9Client with only one "environment camera? Also will it use modern rendering technologies for exhausts?

 

[Mojave]

I am absolutely astounded seeing volumetric clouds in Orbiter. What a fantastic development! I wish I knew the first thing about graphics clients, so I could ask a good question or provide something other than just "ooooo" and "aaaahhh," but my word, this is a thing of beauty I've witnessed here today. Thanks to my man @OvalDreamX for bringing this addon development up in the Discord server chatroom. What an amazing project this is.

 

[MattR]

How are reflections handled? Similar to D3D9Client with only one "environment camera? Also will it use modern rendering technologies for exhausts?

Currently I render from one hemispherical camera to capture the sky, then fill in the ground with constant albedo. In the future I want to have a second camera to capture the ground.

Exhausts are currently rendered with a basic sprite-based particle system, but I plan to move to a modern volumetric approach down the track.

 

[DaveS]

Currently I render from one hemispherical camera to capture the sky, then fill in the ground with constant albedo. In the future I want to have a second camera to capture the ground.

Exhausts are currently rendered with a basic sprite-based particle system, but I plan to move to a modern volumetric approach down the track.

OK, that sounds like the current rendering of particle streams. Will they be affected by shadows because that's something neither the inline DX7 engine or D3D9Client do, so diffuse particle streams are always lit instead of being shaded when in shadow.

 

[MattR]

Will they be affected by shadows because that's something neither the inline DX7 engine or D3D9Client do, so diffuse particle streams are always lit instead of being shaded when in shadow.

Yep they'll be affected by shadows. Shadowing by default applies to everything in the scene, but they can be filtered out on particular types of models if needed for performance.

 

[jedidia]

I am absolutely astounded seeing volumetric clouds in Orbiter.

I think Artlav actually had them way back in his OGLClient...

 

[Fabri91]

For some reason volumetric clouds seem to be in the process of being implemented in a lot of sims/flying games recently - just MSFS2020, DCS and Star Citizen all within a year.

 

[jedidia]

For some reason volumetric clouds seem to be in the process of being implemented in a lot of sims/flying games recently - just MSFS2020, DCS and Star Citizen all within a year.

Also no man's sky, though I think that's longer ago than a year now.