New Release D3D9Client Development

[jarmonik]

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

 

[Trekkie]

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

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]

@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]

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 :

FrameRate = 200
EnableLimiter = 0
CustomCamMode = 1
PlanetPreloadMode = 0
PlanetTexLoadFreq = 50
Anisotrophy = 12
SceneAntialias = 8
SketchpadFont = 1
PreLoadBaseVisuals = 0
EnableNormalMapping = 1
NearClipPlaneMode = 0
RwyLightAnimate = 1
RwyLightAngle = 120
RwyBrightness = 1
NightLightsAngle = 10
BumpMapAmplitude = 1
PlanetGlow = 0.7
EnvMapSize = 256
EnvMapMode = 2
EnvMapFaces = 3
ShadowMapMode = 3
ShadowMapFilter = 2
ShadowMapSize = 2048
TerrainShadowing = 0
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
DisableVisualHelperReadout = 0
LODBias = -0.2
MeshRes = 1
MicroMode = 1
MicroFilter = 4
BlendMode = 1
MicroBias = 3
CloudMicro = 1
PostProcess = 1
ShaderDebug = 0
PresentLocation = 1
PlanetTileLoadFlags = 3
LabelDisplayFlags = 3
GDIOverlay = 0
gcGUIMode = 0
AbsoluteAnimations = 1
NormalmappedClouds = 1
TerrainFlats = 1
OrbitalShadowMult = 0.85
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

 

[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 :

FrameRate = 200
EnableLimiter = 0
CustomCamMode = 1
PlanetPreloadMode = 0
PlanetTexLoadFreq = 50
Anisotrophy = 12
SceneAntialias = 8
SketchpadFont = 1
PreLoadBaseVisuals = 0
EnableNormalMapping = 1
NearClipPlaneMode = 0
RwyLightAnimate = 1
RwyLightAngle = 120
RwyBrightness = 1
NightLightsAngle = 10
BumpMapAmplitude = 1
PlanetGlow = 0.7
EnvMapSize = 256
EnvMapMode = 2
EnvMapFaces = 3
ShadowMapMode = 3
ShadowMapFilter = 2
ShadowMapSize = 2048
TerrainShadowing = 0
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
DisableVisualHelperReadout = 0
LODBias = -0.2
MeshRes = 1
MicroMode = 1
MicroFilter = 4
BlendMode = 1
MicroBias = 3
CloudMicro = 1
PostProcess = 1
ShaderDebug = 0
PresentLocation = 1
PlanetTileLoadFlags = 3
LabelDisplayFlags = 3
GDIOverlay = 0
gcGUIMode = 0
AbsoluteAnimations = 1
NormalmappedClouds = 1
TerrainFlats = 1
OrbitalShadowMult = 0.85
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]

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]

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]

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]

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.

 

[Face]

Ah, I see. Well, the collision and shadow thing you mentioned would indeed indicate that the "start-at-lowest-level" method to model the base is not a good approach. What about the other idea? Create simple high-res tiles for the area, dig the high-res trench with the flattening method (or even built-in to the high-res tile), then place the mesh over it. You don't have to create the trenches perfectly fine, just good enough to make way for the mesh not being filled up.

I think the show-stopper here is the stock (or even "high-res") earth terrain being too coarse at your add-ons location (Baikonur?).

 

[igel]

Hm. I did not think... maybe indeed the coarsness of .flt override is caused by the resolution of the tiles at that place? Which may be increased? Good idea to check.
What is the "minimum" size of the individual ground "cell-pixel" (in meters) on Earth-size planet? What ultimate accuracy can I realistically expect with the trench in the most fine tile resolution?

 

[Face]

Well, I know that the flattening feature is not changing the rendering operation, it just changes the data before it is used for the rendering (and collision checking). Therefore, if not more data is present, it can't create more details.
If my calculation is right, you can have - at max. level 17 - the resolution of 16384 tiles with 256 height points each. On the equator of earth, that would mean a resolution of approx. 10m. At Baikonur latitude (ca. 45°) the longitudinal resolution is approx. 7m, but the lateral resolution stays at 10m.

So, realistically I'd say the minimal trench you can dig is a quadratic pyramidal one with approx. 14 meters side length. But this only if the point you want to lower happens to fall right on a grid point of the terrain. In the general case, I'd calculate with double the size, so say maybe 30m.

 

[GLS]

Well, I know that the flattening feature is not changing the rendering operation, it just changes the data before it is used for the rendering (and collision checking). Therefore, if not more data is present, it can't create more details.
If my calculation is right, you can have - at max. level 17 - the resolution of 16384 tiles with 256 height points each. On the equator of earth, that would mean a resolution of approx. 10m. At Baikonur latitude (ca. 45°) the longitudinal resolution is approx. 7m, but the lateral resolution stays at 10m.

So, realistically I'd say the minimal trench you can dig is a quadratic pyramidal one with approx. 14 meters side length. But this only if the point you want to lower happens to fall right on a grid point of the terrain. In the general case, I'd calculate with double the size, so say maybe 30m.

So level 19 would be a quarter of that?

 

[4throck]

In the general case, I'd calculate with double the size, so say maybe 30m.

Small areas don't work visually because, as Face mentioned, they are not aligned with the terrain "grid".
So your hole will be uneven.
But you should still do it because of shadows and exhaust renderning.

II think it might work if you lower a larger area than the pit, then add a mesh for the entire Pad. Perhaps 500m all around.

Also, you can have multiple flatten areas if I'm not mistaken.
So you can have a large area for the entire base if needed, and a smaller one just for the Pad/pit depression.

 

[Face]

AFAIK, Orbiter supports elevation data only up to level 17. It is what the documentation says, at least.