New Release D3D9Client Development

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,430
Reaction score
417
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,444
Reaction score
528
Points
113
Website
users.kymp.net
@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,539
Reaction score
672
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,430
Reaction score
417
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
202
Reaction score
25
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,539
Reaction score
672
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

Addon Developer
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,350
Reaction score
918
Points
128
Location
Biddeford 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,156
Reaction score
1,892
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

Active member
Joined
Sep 9, 2013
Messages
119
Reaction score
8
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,539
Reaction score
672
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
525
Reaction score
299
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,539
Reaction score
672
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
 
Top