New Release D3D9Client Development

[GLS]

Attached is the current build of D3D9Client (trunk)

New features:
- linked against Orbiter BETA r69
- added quadtree-based surface labels
- enabled "regular" (billboard) sun rendering in "Postprocessing Lensflare" mode when distance to sun is > 150e9 meters.
- fixed ring lighting issue (https://www.orbiter-forum.com/showthread.php?p=563383&postcount=4408)
- Documentation update (updated DirectX runtimes URL to link to the current (June 2010) version).

Note, that this has only been tested on my machine, so if you find some weird characters in the "new" surface labels, please compare them with the inline client rendering and see if they are shown correct there.
The UTF-8 rendering is not done "full featured" currently, but maybe it's enough :thumbup:

..and as always: have fun!

Problem: Martian features are being indicated both on Earth and on the Moon, and some features are indicated on Mars when camera is on Earth.
On the Moon, enabling "Astronaut-named features" appears to show Earth airports...
Unlike with MOGE, I don't see any difference with the cache vs archive options.

Also (probably not related) I'm getting a CTD when reloading a just saved scenario (only DG in it). After I restart, it loads fine. Nothing (obvious) shows up on the logs.

 

[kuddel]

Problem: Martian features are being indicated both on Earth and on the Moon, and some features are indicated on Mars when camera is on Earth

Ups :blush:

Never noticed / tried that, but you're right! I'll take a look at this.

That's why it is so nice to present pre-releases here in the developer thread!
Thanks a lot,
Kuddel

---------- Post added at 01:30 ---------- Previous post was at 01:25 ----------

...actually I find it kind of nice to have a feature on Mars named after my very small home-town suburb

 

[kuddel]

D3D9Client (Beta/trunk) for Orbiter BETA r69

And here's another one

The fix was easy ("what a difference a wrong 'static' makes :blush


---------- Edit:----------
...removed the attachment, 'cause here's a slightly better one

 

[GLS]

And here's another one

The fix was easy ("what a difference a wrong 'static' makes :blush

Yes, that fixes the Martian features everywhere issue :thumbup:, but the features on Mars are still visible if you look at Mars from Earth.

 

[jarmonik]

I stupidly never even considered that adding TextW would break compatibility :facepalm:

I'd be happy to put it into a Sketchpad2 extension. Would that interfere with your own Sketchpad2 version, if you already have one?

If I do create a new Sketchpad2 class, are there any other functions that should be added to it while I'm at it?

I did a little more testing regarding the compatibility issue and it would seem that functions declared before the TextW are working but functions appearing after the TextW are causing a CTD. If the TextW would be the last function on a list then it might work or it could cause some other problems, I don't know.

We have a Sketchpad2 in use but we can easily rename it to SketchpadEx. As far as I can tell, there's just one application (under active development) using it, so, no problems in renaming it.

GetVersion() function could be added in it. Also, we have a virtual void SetGlobalLineScale(float width = 1.0f, float pattern = 1.0f) function in our implementation that could be some use but we will do just fine without it, so it's not really an issue. Little background...:

A problem is that when drawing a virtual cockpit MFDs in a textures in sizes of 512 or 1024 pixels, a hairlines are becoming too thin causing them to dissappear from the screen. But unfortunately the functions it self doesn't really solve the whole problem. Technically, we could automatically pre-apply a proper line-scale factor when a sketchpad is created for MFD drawing based on a surface size. But we can't identify MFD drawing surfaces from the rest and the same applies to the textures used in rendering the VC. Could we use the upper 8-bits of the flags passed to oapiCreateSurfaceEx() for the identification purpose ?

Having the SetGlobalLineScale() in the Sketchpad2 would allow a user to override the automated line-width scaling if necessary without linking to a client API. But, there's probably no need to implement the actual functionality for the GDI wrapper. That could get complicated.

Also, we have no control over the stock SurfaceMFD due to use of an additional rendering surfaces. SurfaceMFD would need to set the pen with on it's own for those parts.

Here are screen shots with a pen-width scaling 1.0f and 3.0f, texture size 1024x1024

 

[jarmonik]

Thanks for the note on the fresnel maps. Isn't including a fresnel map the only way to enable PBR? I disabled them with no change. After taking a closer look, it seems that the specular maps isn't disabled but rather have had their effects dialed back alot.

The fresnel map is independent from both modes. It's still unknown how it's going to be implemented in the future. I purchased some literature during the summer that should cast some light into a light/material interaction issues/behavior but I haven't had time to read it yet.

The _spec map will force the pipeline in legacy mode. _rghn and _refl maps are required for PBR (_spec must not exists). If all three are present then the pipeline will operate in mixed more where _spec controls the sunlight and _rghn, _refl controls the environment reflections. (Note: No testing is done in this mode)

I downloaded the SSU 4.2 binaries and the latest textures from the SVN and it didn't work. After tuning the textures it started to work reasonably well. The shader code needs some work there are a few problems.

The most reflective parts in _refl map should be somewhere around 210 and 230 (almost white not entirely). _rghn map is fine. Radiator brightness in a diffuse texture was increased so that blue channel was about 200. If there were a way to tell the client to assume a proper diffuse texture then the original texture would be mostly fine. So, maybe that should be added on a todo-list.

 

[kuddel]

D3D9Client (Beta/trunk) for Orbiter BETA r69

Yes, that fixes the Martian features everywhere issue :thumbup:, but the features on Mars are still visible if you look at Mars from Earth.

It took me while to reproduce the issue, but this version should fix that!

@Jarmo: I fixed this at revision 887, but I have the strange feeling that this should have been handled different :hmm: I though that CameraDirection2Viewport() would have handled this case...
maybe you could take a smarter look at all the stuff I copied from "OVP DX7 reference implementation" in and around TileLabel.cpp :thumbup:

Anyway: Have fun!

 

[kuddel]

D3D9Client (Beta/trunk) for Orbiter BETA r69

Here's another build (trunk r892) of D3D9Client.
This time with full UTF-8 support for the new labels

Have fun!

 

[Donamy]

I'm having an issue with R2.1 making some groups transparent. Has anyone else seen this issue ?

 

[kuddel]

D3D9Client (Beta 25.3) for Orbiter BETA r70

Hi,

although there has been no API changes between Orbiter r69 and Orbiter r70, for all who like to be "as current as possible":
Here's the current build of D3D9Client for Orbiter BETA linked against r70.

No major changes except for the handling of the new Tree-Tile-Labels that have multiple names.
For places having more than 3 names, the names will simply be "rotated" so every single name will be presented (sooner or later[*]).
Other changes are pure internal (like optimized memory usage and/or speed).


Have fun,
Kuddel


[*] Since there's for example one place having 62! different names, this might take a while

 

[kuddel]

D3D9Client (Beta 25.4) for Orbiter BETA r71

Hi,

although there has been no API changes between Orbiter r69 and Orbiter r71, for all who like to be "as current as possible":
Here's the current build of D3D9Client for Orbiter BETA linked against r71.

- No major changes except for "smooth scrolling" (proof of concept) for the handling of the new Tree-Tile-Labels that have multiple names.
For places having more than 3 names, the names will simply be "scrolled" so every single name will be presented.
- And the documentation files (PDFs) had missing graphics -sorry-, they should be present again.

Have fun,
Kuddel

 

[Kyle_E]

Not sure if this is a documented bug or not, but with all clients for the official Orbiter 2016 build after R2-Beta1, the atmosphere looks like this (this is a clean install).

 

[N_Molson]

That red cloudlet is really weird. Given the shadows of the buildings, the Sun isn't setting or rising above the horizon. And yes there's something with that white/blueish horizon "glow"...

 

[PA328]

Perhaps this question was already asked, but I did not find it. Do reflections work in D3D9 R2.1? As I understand, reflection maps of type _refl are not supported?

 

[DaveS]

Perhaps this question was already asked, but I did not find it. Do reflections work in D3D9 R2.1? As I understand, reflection maps of type _refl are not supported?

Reflections work just fine in R2.1.

 

[PA328]

Reflections work just fine in R2.1.

Hmm. I created a texture "x.dds", I created a reflection map "x_refl.dds" , and I did not observe the reflection effect.

 

[jarmonik]

Hmm. I created a texture "x.dds", I created a reflection map "x_refl.dds" , and I did not observe the reflection effect.

You need additional _rghn.dds map for reflections to work. It will tell how rough or smooth the surface is and therefor effects in a look of the reflections. Don't use _spec.dds map unless you are absolutely sure you know what you are doing.

_frsl.dds map isn't properly implemented and shouldn't be used.

Here's some more information:

https://www.orbiter-forum.com/showthread.php?p=557146&postcount=4338

(Dev Note: Maybe we should include that in a distribution)

---------- Post added at 15:42 ---------- Previous post was at 15:38 ----------

Not sure if this is a documented bug or not, but with all clients for the official Orbiter 2016 build after R2-Beta1, the atmosphere looks like this (this is a clean install).

That looks awful. It that an installations problem or something else. Anyone else having that ?

Looks like the atmosphere configuration files might be out-dated or shader file is incorrect.

---------- Post added at 15:45 ---------- Previous post was at 15:42 ----------

I haven't had any luck getting the planetary labels to work in Inline nor D3D9. I might be missing label database files or something. It that publicly available ?

 

[DaveS]

Any updates on fixing this problem: https://www.orbiter-forum.com/showthread.php?p=563865&postcount=4424

 

[GLS]

I noticed that, unlike in MOGE, when I zoom out "to the other side of the universe" and back, the vessel visual isn't destroyed and created... is this by design or one of those "unintended features"?
Using the latest version for Orbiter beta.

 

[GLS]

Bug: the text cursor of the input box (Ctrl+R for example) shows up as an oversized black rectangle.