# New ReleaseD3D9Client Development

#### Ripley

##### Tutorial translator
Donator
...between the keyboard and the screen again...
Do you type with your back to the screen???

#### 80mileshigh

Donator
Do you type with your back to the screen???

I'm just updating the phrase for the age of wireless peripherals which permit such contortion

#### Trekkie

##### Starfleet Head of Ship Design
Donator
i found a bug when i want to load my upcoming Star Trek universe add-on into the D3d9 client.. i use Custom mesh as a Planet which represents a Sun, now the problem i have is that it dissapears when i zoom out and it does not appear untill i am very close.. i dont know if this is fixable, i would like to continue development in the D3D9 client.. but this prohibits me from doing so.. when i have the time i will upload some example pictures.

hope somebody can help/resolve this issue with Custom Mesh planets

#### macVsog

##### Well-known member
this is an experimental solar system rather, on the contrary, it won't work without D3d9 if you used a blender, you are limited only by the speed of the computer please provide a screenshot or more information

#### Trekkie

##### Starfleet Head of Ship Design
Donator

This is the Sun Proxima Centauri as a .MSH in the Normal D3D7 Orbiter 2016, i do use Blender to export them to a .MSH file

And this is the same Sun .MSH in the D3D9 Client

it like dissapears and when you get very close it returns to normal.. i dont know if its because of my mesh or if its a client bug..

#### jarmonik

Beta Tester
Is the "Size" parameter correct in a config file ? What happens if you increase it by a factor of ten.

#### Trekkie

##### Starfleet Head of Ship Design
Donator
Is the "Size" parameter correct in a config file ? What happens if you increase it by a factor of ten.

Here its increased by a Factor of 10

here is the config file

Code:
Name = Proxima_Centauri
EllipticOrbit = TRUE           ; ignore perturbations
HasElements = TRUE             ; orbital elements follow

; === Planetary Mean Orbits ===
;***cfgBatchDataCalculator
Epoch =  2005.41409993155
SemiMajorAxis = 899879400000  ; in metres
Eccentricity =  0.000           ;
Inclination =  80.84444
LongAscNode =  4.65     ;??
LongPerihelion =  3.0  ;??
MeanLongitude = 7  ;??

; === Physical Parameters ===
Mass = 6.18801e27
Size = 1.04e10                ; mean radius
AlbedoRGB = 1 0 0

; === Atmospheric Parameters ===
AtmPressure0 = 000e1          ; Pa
AtmDensity0 = 0.00001              ; kg/m^3
AtmAltLimit = 200e3
AtmColor0 = 1 0.95 0.8
AtmHorizonAlt = 110e3           ; horizon rendering altitude [m]
AtmHazeExtent = 0.01           ; horizon haze extent
AtmHazeColor = 1 0.6 0.6

; === Visualisation Parameters ===
MaxPatchResolution = 0         ; highest sphere patch level
MinCloudResolution = 1                    ; cloud layer from this resolution
MaxCloudResolution = 8                    ; highest cloud resolution level

#### Trekkie

##### Starfleet Head of Ship Design
Donator
@jarmonik does the D3D9 client support the way level 8 planetary textures are created by the Pltex with night lights included? my planets do not show the nightlights in D3D9 client, maybe they are not supported?

#### yitianetie

##### Member
Hi,

You talk about planet rendering. I have found a small flickering (sorts of blue and white pixels on the attached picture) on the edge of the planet, especially the Earth while looking it from far. This flickering occurs after loading the scene and while moving the camera.

I don't know if we have the same flickering with other planets. But it only appears with D3D9 client, not with DXD7 "in-stock" client.

Below, those are my settings for the last release of D3D9 client (r. 1355) for Orbiter 2016 :

Code:
FrameRate = 200
EnableLimiter = 0
CustomCamMode = 1
Anisotrophy = 12
SceneAntialias = 8
EnableNormalMapping = 1
NearClipPlaneMode = 0
RwyLightAnimate = 1
RwyLightAngle = 120
RwyBrightness = 1
NightLightsAngle = 10
BumpMapAmplitude = 1
PlanetGlow = 0.7
EnvMapSize = 256
EnvMapMode = 2
EnvMapFaces = 3
EnableGlass = 1
EnableMeshDbg = 1
TileMipmaps = 1
TextureMips = 1
TileDebug = 0
StereoSeparation = 65
StereoConvergence = 0.2
DebugLvl = 1
VCNearPlane = 0.1
LightConfiguration = 4
DisableDrvMgm = 0
NVPerfHUD = 0
DebugLineFontSize = 18
LODBias = -0.2
MeshRes = 1
MicroMode = 1
MicroFilter = 4
BlendMode = 1
MicroBias = 3
CloudMicro = 1
PostProcess = 1
PresentLocation = 1
LabelDisplayFlags = 3
GDIOverlay = 0
gcGUIMode = 0
AbsoluteAnimations = 1
NormalmappedClouds = 1
TerrainFlats = 1
SolCfg = Sol
DebugLineFont = Fixed

I don't know which setting could solve that. Actually, it's not a very annoying detail but I just let you know about this small glitch.

Kind regards

#### Attachments

• glitch_edge_earth.png
477 KB · Views: 25

#### Abloheet

Hi,

You talk about planet rendering. I have found a small flickering (sorts of blue and white pixels on the attached picture) on the edge of the planet, especially the Earth while looking it from far. This flickering occurs after loading the scene and while moving the camera.

I don't know if we have the same flickering with other planets. But it only appears with D3D9 client, not with DXD7 "in-stock" client.

Below, those are my settings for the last release of D3D9 client (r. 1355) for Orbiter 2016 :

Code:
FrameRate = 200
EnableLimiter = 0
CustomCamMode = 1
Anisotrophy = 12
SceneAntialias = 8
EnableNormalMapping = 1
NearClipPlaneMode = 0
RwyLightAnimate = 1
RwyLightAngle = 120
RwyBrightness = 1
NightLightsAngle = 10
BumpMapAmplitude = 1
PlanetGlow = 0.7
EnvMapSize = 256
EnvMapMode = 2
EnvMapFaces = 3
EnableGlass = 1
EnableMeshDbg = 1
TileMipmaps = 1
TextureMips = 1
TileDebug = 0
StereoSeparation = 65
StereoConvergence = 0.2
DebugLvl = 1
VCNearPlane = 0.1
LightConfiguration = 4
DisableDrvMgm = 0
NVPerfHUD = 0
DebugLineFontSize = 18
LODBias = -0.2
MeshRes = 1
MicroMode = 1
MicroFilter = 4
BlendMode = 1
MicroBias = 3
CloudMicro = 1
PostProcess = 1
PresentLocation = 1
LabelDisplayFlags = 3
GDIOverlay = 0
gcGUIMode = 0
AbsoluteAnimations = 1
NormalmappedClouds = 1
TerrainFlats = 1
SolCfg = Sol
DebugLineFont = Fixed

I don't know which setting could solve that. Actually, it's not a very annoying detail but I just let you know about this small glitch.

Kind regards
Yeah, I have noticed this a long time ago. Didn't think this to be a bug or an issue, though. It seems to be a side effect of the new atmosphere rendering shaders of dx9 client. It manifests as aliasing effects on the edge of the planet's night side, when it has a shaded atmosphere

#### igel

Terrain flattening only works if "Surface elevation, using" in the "Visual effects" tab is set to linear interpolation instead of cubic. Also flattening is not doing anything on its own, instead you have to author *.flt files in the planet's tree "Flat" layer to actually flatten certain areas.
Is there any documentation anywhere on the format of .flt files? I am starting to play with them, but so far I only was able to find one short one-liner sample for Pathfinder site. I figured out some parameters to successfully flatten a few most important areas on Baikonur, but I'd like to understand what other values in the file revcords are. And what other are possible, that are not in the file. For example, can there be anything but 'Ellipse"?

#### Face

Beta Tester
If the terrain flattening was incorporated in D3D9Client the way it was implemented in the experiment (which I think it was), the format description done here should still hold.

#### n72.75

Tutorial Publisher
Donator
I know it's probably been asked a dozen times, and posted before, but where is the repository for D3D9 Client? Could we add a link to the post #1 in this thread.

#### igel

If the terrain flattening was incorporated in D3D9Client the way it was implemented in the experiment (which I think it was), the format description done here should still hold.
Thanks a lot - exactly what I was looking for! And yes, same format hods in the last release. Somehow did not spot this description in my search, though I saw that thread... guess I did not check all pages

#### DaveS

##### Space Shuttle Ultra Project co-developer
Donator
Beta Tester
I know it's probably been asked a dozen times, and posted before, but where is the repository for D3D9 Client? Could we add a link to the post #1 in this thread.
If you're talking about the SVN repository, it can found found here: svn://mirror.orbiter-radio.co.uk/D3D9client/

#### igel

Another 2016 question. In the last 2010 client, mirror surfaces (full-reflection materials) are rendered as such both in outside and cockpit views. In the latest 2016 client, they render as mirrors only in the outside view. Or is there some flag-setting somewhere that triggers this internal rendering on/off? Did not find any...
This had sucker-punched me with new Vostok release - where I re-implemented Vzor (optical orienting device) with true mirrors, and just prior to release - way too late - discovered that is is useless in 2016. Any way to activate it or get it back in the next versions?

#### igel

I just realized that if I use something like tooledit to dig any "true" small pit in the Orbiter's space fabric, I'll have to forgo any use of this "flattening" feature and will lave to do all flattening "hard way" in the same tooledit. Otherwise the flattening will override the pit (which is always right in the centre of the flattened area area).

I already considered the 4throck's suggested way: to dig a bigger pit and cover it with custom mesh, and elevate all base objects to new "virtual" surface. But here is the (likely incomplete) list of what has to be considered or done for that in my case:

• My pack of bases contains over 50 individual files for bases, and the number of carefully placed objects in them is close to 2000. So, such update of height of every object can only be scripted.
• These base files are often copied between 2010 and 2016 instances, so height update script should be added to the (already automated) copy process, back and forth. (Note: I can't have two separate development sets for two versions, and can't abandon 2010 until I am sure the 2016 version looks and feels at least not worse than 2010... and until I abandon 2010, I can't benefit from any new 2016 APIs and features in the common codebase).
• "Live" launchpad "vessels" in scenarios have also to be updated for touchdown point heights (and also selectively only for 2016 version).
• In my scenarios, especially in LES/emergency scenarios, a lot of vessels land in the nearest vicinity of the launchpad. With this approach, they will sink through the "virtual" surface and end up deep down on the real one. I'll have to implement watching their flight and "sticking" (attaching?) them to the virtual surface (already doing this for Vostok pilot ejected on the pad, so it is possible to do). But if you take off or fly, say, in DG over the area (I have such scenario) - reported altitudes will be all miscalibrated. (Well, who of us had never ever taken off with miscalibrated altimeter )
• I already use "skirts" around the launchpad meshes to blend with the surroundings. However, with big dugouts (few kilometres across) the skirts should be extended really wide to cover them. And with close proximity of several bases on Baikonur, their overlapping may become messy...
• Not sure how shades will be rendered on "virtual" surfaces. Rendering from the distance is also a concern, though this part is tweakable, I guess.
• Another still outstanding issue is to convert all Baikonur meshes to a new format. As base meshes are not supported in 2016, those need to be somehow made "true" Orbiter textures, and, as they are of "old" sizes, and there are many of them, this probably also needs to be scripted... did not look in their direction yet, that's a different fish to fry... But it is still closely related to surface meshes - not much help if this converted texture gets hidden by "virtual" surface and will have to be duplicated in "virtual" surface anyway...

Most frustrating is... All this work is not to gain some new or exciting look or functionality - but to simply restore what already was there, and still works and looks almost perfectly in the previous version. Technology lock-in in its fullest...

#### Face

Beta Tester
I think I am missing something here. Orbiter 2010's earth is a flat ball with MSL 0 everywhere, right? If you have something that works for this, what is the difference to 2016 with a big flattened circle (say 20km) to MSL0 at the base coordinates, and your addon from 2010 applied as it is? Sure, you'd have that flattening while closing in to the base (which could be compensated with fall-off), but at the base itself it should be fine, no? Also, what do you mean with base meshes not supported? I converted the old WIA just fine with the idea to flatten the area completely to zero, then using unchanged base elements upon that.
If you mean old base tiles, there is a solution for that with treeman's base conversion feature.

#### igel

" base meshes not supported " - yes, I meant base tiles, sorry. I'll indeed look at base conversion tool once I solve the 3D puzzle.

The thing that changed in 2016 is, I guess, simply the rendering order. In 2010, the "underground" portion of the mesh is rendered in front, as priority, still always visible, not covered by Earth's sphere surface. It even takes extra effort to hide undergroung portions that you do NOT want to see . In 2016, planet surface always has the priority - as far as I know. And that's all the change, I think.

Of course, 2010 implementation is also not fully ideal: if something lands in the flame trench pit, it will "land" on the invisible surface on the true planet's ground level, and will look like floating in the air above the trench floor. But that's a rare localized effect, not hurting visuals much - not more than if the same object land on elevated portion of the base mesh and sinks through it to the ground level. And, when absolutely needed, both things can be fixed with "smart sticking". There are a few other things, like shadows, or fully underground objects not getting sun, but once again those are local and less damaging than the trench filled with planet's surface.