New Release D3D9Client Development

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
@jarmonik : I think I fixed the problem with the black elevation grid labels. It seems that the texture needed to be reapplied. I also slightly modified the label tech to use the grid colour for the labels, and only pull the alpha channel from the texture. Having grid and labels in the same colour makes it visually easier to connect them, than having all labels in white.

It would be good if you checked my edits to the shader file. It seems to work, but I just guessed the syntax, so maybe there is a better way of doing this.

When you are happy, I think it's ready to merge.
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
@martins I didn't notice earlier that texture was set to a device instead of an effect. It's ok that way but one must ensure a correct index bind from a shader side so that c++ and fx use the same index. Therefore added "register (s0)" in the shader file.

Go for merge.
 

BrianJ

Addon Developer
Addon Developer
Joined
Apr 19, 2008
Messages
1,676
Reaction score
900
Points
128
Location
Code 347
Hi,
can anyone tell me how D3D9 Graphics Client is currently handling meshes for celestial bodies? e.g. asteroids, comets, etc.
Default Orbiter2016 rendering requires a 1m radius mesh and scales it by the size in the body's .cfg.
The D3D9 Graphics Client I'm using (very old I think, R1) requires a full-scale mesh.
Any change to that these days? Or planned?
Many thanks,
BrianJ
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
I can't speak for the D3D9 client with any authority, but since the source data (meshes, tile elevation files) are shared between all clients, it stands to reason that they must have compatible scaling strategies.

Currently, there are two separate ways of defining non-spherical celestial object surfaces: either by defining a single mesh for the entire body, or by using the multi-level quad-tree tile strategy described in Doc/PlanetTextures.pdf. The former is mainly used for small bodies which don't need a scalable approach (and which are not landed on, since there is no collision mechanism in place other than a virtual sphere at the mean radius). The latter is used for larger bodies, where rendering the entire surface even when in close proximity would be prohibitively inefficient, and where vessel-surface interaction handling is important.

I am assuming you are referring to the whole-mesh version - is that correct? The data format for the quad-tree approach should be reasonably well described in the documentation, but let me know if anything is unclear.

As regards the whole-mesh approach, you are correct - the vertex coordinates are expected in units of the planet 'Size' parameter (as defined by its config file). This was originally done for internal reasons (to make the transformation matrices used by the renderer compatible with the other planet render mechanisms), but it also has the added benefit of allowing to change (or correct) the planet size by changing just a single config parameter, rather than having to scale the entire mesh. This is how the DX7-based engines (inline and D3D7 client) are handling it. If the D3D9 client is doing something different I am unaware. Maybe to test it you could try the latest Orbiter development build from the github page. This should minimise the risk of using an out-of date D3D9 client.

In general, I would discourage the use of whole-mesh rendering strategies for new projects, for the above mentioned limitations. Using the quad-tree approach is a bit more complex, but is more versatile. In any case, I have no plans of changing the way the whole-mesh rendering works (other than maybe eventually phasing it out).
 

Abloheet

Addon Developer
Addon Developer
Joined
Apr 18, 2009
Messages
212
Reaction score
40
Points
43
Location
Kolkata,West Bengal
Is there anyway one can convert the meshes for asteroids and minor gas giant moons(available as add-ons) into the quad tree format to get Landable surfaces?
 

BrianJ

Addon Developer
Addon Developer
Joined
Apr 19, 2008
Messages
1,676
Reaction score
900
Points
128
Location
Code 347
Hi martins :)
I am assuming you are referring to the whole-mesh version - is that correct?
that's correct.
For any celestial body that has a real-world height map, or for anything that will be landed on, I would definitely go with the elevation quad-tree option. But, since I'm too dim to figure out how to automate the required image processing (resizing, chopping into squares, adding pixel rows and columns, etc.), making a whole-mesh is only about 5% of the work, just for a bit of eye-candy.
Anyhow, I find the most recent D3D9 GC that I have, version 4.11 (07 Sep 2020) does indeed use the same mesh-scaling-method as default Orbiter2016 (unlike the old D3D9 GC version 2.1 that I have in my main Orbiter2016 installation). Very good! I can go with the "unit radius" mesh.

Many thanks,
Brian
 

n72.75

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,687
Reaction score
1,337
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
I can't speak for the D3D9 client with any authority, but since the source data (meshes, tile elevation files) are shared between all clients, it stands to reason that they must have compatible scaling strategies.

Currently, there are two separate ways of defining non-spherical celestial object surfaces: either by defining a single mesh for the entire body, or by using the multi-level quad-tree tile strategy described in Doc/PlanetTextures.pdf. The former is mainly used for small bodies which don't need a scalable approach (and which are not landed on, since there is no collision mechanism in place other than a virtual sphere at the mean radius). The latter is used for larger bodies, where rendering the entire surface even when in close proximity would be prohibitively inefficient, and where vessel-surface interaction handling is important.

I am assuming you are referring to the whole-mesh version - is that correct? The data format for the quad-tree approach should be reasonably well described in the documentation, but let me know if anything is unclear.

As regards the whole-mesh approach, you are correct - the vertex coordinates are expected in units of the planet 'Size' parameter (as defined by its config file). This was originally done for internal reasons (to make the transformation matrices used by the renderer compatible with the other planet render mechanisms), but it also has the added benefit of allowing to change (or correct) the planet size by changing just a single config parameter, rather than having to scale the entire mesh. This is how the DX7-based engines (inline and D3D7 client) are handling it. If the D3D9 client is doing something different I am unaware. Maybe to test it you could try the latest Orbiter development build from the github page. This should minimise the risk of using an out-of date D3D9 client.

In general, I would discourage the use of whole-mesh rendering strategies for new projects, for the above mentioned limitations. Using the quad-tree approach is a bit more complex, but is more versatile. In any case, I have no plans of changing the way the whole-mesh rendering works (other than maybe eventually phasing it out).

Would it be possible, in practice, to adjust Earth's elevation such that terrain height is above an ellipsoid rather than a sphere? Intuitively it seems like this would work.
 
  • Like
Reactions: GLS

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,870
Reaction score
2,867
Points
188
Website
github.com
Would it be possible, in practice, to adjust Earth's elevation such that terrain height is above an ellipsoid rather than a sphere? Intuitively it seems like this would work.
I think that would be "easy" for the terrain, but maybe not so easy for the atmosphere. Still, a correctly-shaped Earth would be a nice thing to have.


Not to derail the D3D9 thread, maybe this topic should be moved to the existing thread? https://www.orbiter-forum.com/threads/shape-of-the-earth-and-earth-atmosphere-in-orbiter-2016.34568/
 

ZacharyS41

Donator
Donator
Joined
Sep 9, 2013
Messages
125
Reaction score
10
Points
33
Location
Roanoke
Website
www.zachsellinger.com
Is there a download link within this thread for the most up-to-date D3D9 Client? I'm not referring to the one on the download page; is it somewhere in the most recent thread pages?
 

BrianJ

Addon Developer
Addon Developer
Joined
Apr 19, 2008
Messages
1,676
Reaction score
900
Points
128
Location
Code 347
Hi,
I wonder if someone could check on the way the newer versions of D3D9 GC are handling the rendering of small celestial bodies with elevation tiles, e.g. asteroid Bennu (included in Osiris-Rex add-on). Or try Vesta.

The latest version I tried r4.25 (on the D3D9 GC download website) does not render heightmaps until you are quite close to the object. (This also happens for r4.1). And rendering with Planetarium mode on [F9] is....not quite right?

Here are comparison screenshots of Bennu at 30km distance, 10deg FoV, 1600 x 900 pixel window.
Normal view on left, Planetarium Mode on right..........

Default Orbiter2016 graphics:
bennu_default_orbiter.jpg

D3D9 GC r2.1:
bennu_d3d9_r2_1.jpg

D3D9 GC r4.25
bennu_d3d9_r4_25.jpg

Many thanks,
BrianJ
 

jacquesmomo

Addon Developer
Addon Developer
Joined
Jun 14, 2008
Messages
611
Reaction score
449
Points
78
Location
FRANCE
Website
francophone.dansteph.com
Hi BrianJ :salute:

So, I (nearly) followed your instructions :
  • screen 1900 1068 with and without D3D6 (version 4.25)
  • FOV = 10
  • Planetarium or normal view is same for me.

and here is what I have :

03.jpg

And at 3.5 km without D3D9 :

01-3-35-noD3D9.jpg

with D3D9 :

01-3-35-noD3D9.jpg

so we can see that at some distance, Bennu becomes spherical with D3D9
I hope that can help you. 🤔
 

BrianJ

Addon Developer
Addon Developer
Joined
Apr 19, 2008
Messages
1,676
Reaction score
900
Points
128
Location
Code 347
Thanks jacquesmomo.
NOTE: I can't reproduce the "Planetarium-lighting" thing with any other body/viewpoint.
But the "Spherical-at-a-distance" thing persists.
Cheers,
BrianJ
 

jacquesmomo

Addon Developer
Addon Developer
Joined
Jun 14, 2008
Messages
611
Reaction score
449
Points
78
Location
FRANCE
Website
francophone.dansteph.com
Ah yes, I hadn't understood (and especially not seen) I have the same problem as you in "normal" view and in "planetarium" view
(the shadow "jumps"....)
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
The rework of atmospheric and planet rendering has reached a point where it's ready for testing. I have made a pull request https://github.com/orbitersim/orbiter/pull/324 it should be tested very well because the number of changes are huge. There are some problems with sun glare appearance during sunset/sunrise. Also I still need to do something for the clouds because they don't look that good when viewed from below and against a sunset. This has taken awfully lot of work so let's hope it was worth it.

EDIT:
Sun and sun-glare textures are mathematically generated and the code is located in a bottom of Glare.hlsl feel free to tune it to your liking. Graphics controls dialog has a re-compile button so the code can be modified/recompiled while the Orbiter is running.
 
Last edited:

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
Hi Jarmo,
thanks for your work on the atmospheric rendering! I had a few problems getting the PR to run on my machine (details on the PR discussion page), so applied some quick patches to get past the errors.
One thing I noticed is that the planet surface brightness seems to drop quite significantly as you move the camera up away from the surface (see picture for comparison at 50km and 250km altitude). Is this expected? Note that my shader patches may well have screwed up something, so this report should be taken with a grain of salt ...
d3d9atm_a.jpg
I guess the mechanisms by which brightness could be expected to drop with altitude are atmospheric absorption and scattering, but I wouldn't expect this to affect the net albedo by this amount. Also, at 50km altitude I would expect atmospheric effects already nearly fully applied, so there shouldn't be any more significant change between 50 and 250km.
 
Last edited:

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
One thing I noticed is that the planet surface brightness seems to drop quite significantly as you move the camera up away from the surface (see picture for comparison at 50km and 250km altitude). Is this expected? Note that my shader patches may well have screwed up something, so this report should be taken with a grain of salt ...
This is very likely a configuration issue and not a code/math problem. There are three configuration points Surface level, Low Orbit and High Orbit so the Earth appearance can be customized for each viewing condition separately. There's been a lot of trouble/headache with the relatively high dynamic range of the atmosphere and how to fit it properly on screen. Also the so called eye adaption is a problem, there's no easy simulation for that. I guess that the habit for a darker Earth from a higher altitudes comes from the famous Apollo era photographs. I'll check the configurations and I guess that it's more important to focus on a daytime consistency than a twilight rendering.
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
Ah, ok, that makes sense. I am starting to play around with the settings in the Atmospheric controls. I think for my personal use I'll tone the surface brightness down a bit and the orbit brightness up a bit, so that the transitions are less pronounced.
 

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
Hey Jarmo,

I can not start a session (Delta-glider\DG Mk4 in orbit.scn of course ;) ) without it crashing.

First I found some errors when loading the microtextures:
Code:
...
000008.627: D3D9: [3DDevice Initialized]
000011.790: D3D9ERROR: Failed to read microtexture [Textures/D3D9Moon_A.dds] for [Ð]c»´]
000011.791: D3D9ERROR: Failed to read microtexture [Textures/D3D9Moon_B.dds] for [Ð]c»´]
000011.791: D3D9ERROR: Failed to read microtexture [Textures/D3D9Moon_C.dds] for [Ð]c»´]
000011.792: D3D9ERROR: Failed to read microtexture [Textures/D3D9Mars_A.dds] for [ÀYc»´]
000011.793: D3D9ERROR: Failed to read microtexture [Textures/D3D9Mars_B.dds] for [ÀYc»´]
000011.794: D3D9ERROR: Failed to read microtexture [Textures/D3D9Moon_C2.dds] for [fc»´]
000023.779: D3D9: [D3D9Client Initialized]
...
which looks like UTF-8 / ANSI mixup (I'll look into that).
EDIT: It was just missing .dds files in Textures folder (the ugly error output however is not nice ;) )

Then it crashes (I think when trying to render the first time) at this point:
Code:
...
000029.088: D3D9: [Scene Initialized]
000029.556: Finished initialising panels
000030.491: D3D9: NewShader [DG\deltaglider_ns]=4
000030.503: D3D9: NewShader [DG\deltaglider_ns]=4

I am currently unable to run Orbiter_ng in Debug mode (so a thrown exception might pop up) but that's another issue.
On another machine an exception was thrown at the end of D3D9Effect::Render2DPanel.
 

Attachments

  • Orbiter.log
    6.9 KB · Views: 1
  • D3D9ClientLog.zip
    6.5 KB · Views: 0
Last edited:

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
I am currently unable to run Orbiter_ng in Debug mode (so a thrown exception might pop up) but that's another issue.
On another machine an exception was thrown at the end of D3D9Effect::Render2DPanel.
In case this is to do with the debugger not attaching to the spawned Orbiter process, here is a tip that might help: instead of running Orbiter_ng.exe, you can run Modules/Server/Orbiter.exe directly, also from within VS (just pick "Orbiter.exe (Modules\Server\Orbiter.exe)" as the debugging target from the list). The Orbiter server version automatically switches its working directory to ..\.. - I did this specifically to help with debugging.
 
Top