New Release D3D9Client Development

Hello developers,

I have downloaded the new version of the D3D9Client a view days ago and I would like to express my appreciation of it. It's has become amazing! All the colors, everything.
I also like the LensFlare feature very much.

Furthermore, I have posted a suggestion for Eclipse shadows in Orbiter under the "ORBITER: 2010-P1 and newer" forum section.
I think this may also be applicable to the D3D9Client, with all of it's beautiful visual effects.
Eclipse simulation like in Space Engine would be amazing.
 
Hi,
I was just putting together a scenario for Cassini at Saturn today (30 Aug) and noticed that Saturn's rings look a bit dark on the "lit" side and bright on the "shadowed"side (using D3D9 Client). Is it meant to look like this?
sat_rings_d3d9.jpg
 
@BrianJ: Funny thing you've discovered :thumbup:
I couldn't reproduce your issue at first, while running default scenarios (Year 2001).
But changing the date to "now" (Year 2017) the issue comes up!

What a difference half an orbit makes :P
 
Here's a fix for the ring issue: Mesh.fx line 138:
if ((dot(frg.nrmW, frg.CamW)*dot(frg.nrmW, gSun.Dir))>0) return float4(color.rgb*0.35f, color.a);


There's a problem with the SVN, I can't commit:
Can't open file '/svn/D3D9client/db/txn-current-lock': Permission denied
 
I'm actually talking about sunlight reflections, not actual environment reflections (those work great). I have already tried playing around with the Tuning with no success whatsoever. This is what everything looks like right now: https://www.dropbox.com/s/342as8a4oq0wvmq/D3D9Client_no_sunlight_reflections.jpg?dl=0
From that angle and with the sun directly above, there should be sunlight reflections on the payload bay radiator panels.
Anything on this? Either the textures are set up wrong, or I have discovered a bug with the PBR implementation.
 
Any news about a d3d9 client for r69 beta orbiter 2017? Will it contain all the updates and features of release 2016 version d3d9client alongwith the new features?
 
I keep updating forgetting about the DX9 client :facepalm:
 
Any news about a d3d9 client for r69 beta orbiter 2017? Will it contain all the updates and features of release 2016 version d3d9client alongwith the new features?

Almost ;) But as the current code[1] can not (yet) render the UTF-8 character set used in the labels, this is not ready to be released.


[1] trunk rev. 875
 
Last edited:
D3D9Client (Beta/trunk) for Orbiter BETA r69

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!

---------- Edit:----------
...removed the attachment, 'cause here's a slightly better one ;)
 
Last edited:
Almost ;) But as the current code[1] can not (yet) render the UTF-8 character set used in the labels, this is not ready to be released.
[1] trunk rev. 875

Ok, thanks. I have been occupied by "real" life so I haven't had much time to look into a client development.

I'll look into the PBR problem when I got time.

The UTF-8 (extended charter set) has been on a todo-list for a while but I haven't had time to do anything for it since it hasn't been a priority.

I think, we would need a configuration file containing a code ranges for an additional charters. We can't pre-render all of them so we need to narrow down what is needed and what is not. So that we can use lookup tables for charter translations.

If the UTF-8 is the way to go (and not the WCHAR) then a string length issues might appear since number of charters and bytes in a string would no-longer match.
 
Hi Jarmao,
as far as I can see, WCHAR methods for Text might be enough, since orbiter core seems to use them, too.
Regarding the LUT for the character-data (width, etc) we could pre calculate the "most used" characters and implement a GetCharacterMetrics() method that would calculate (and cache) them if an not-yet-known character is requested.
a std::map<WCHAR, FontData*> kind of LUT...



...and as usual: "real" life first!
 
Well, it actually looks like there are WCHAR versions of the Text() functions added. Does this addition break the compatibility with existing sketchpad applications. At-least LTMFD seems to be crashing.

We have already defined Sketchpad2 class in D3D9, Martin might need that too. Should we rename the Sketchpad2 ?

---------- Post added at 01:58 ---------- Previous post was at 01:52 ----------

Regarding the LUT for the character-data (width, etc) we could pre calculate the "most used" characters and implement a GetCharacterMetrics() method that would calculate (and cache) them if an not-yet-known character is requested.
a std::map<WCHAR, FontData*> kind of LUT...

That sounds great. :thumbup:
 
IIRC Sketchpad2 is an extension of the default Sketchpad, right?
So if there's Sketchpad::Text() and Sketchpad:.TextW() we might just have to override them accordingly.
By the way, I don't see why the WCHAR version is named "TextW". With it's different parameter signature it should have also been named "Text", too....but that's minor.

I'll hit the hay, good night :salute:
 
IIRC Sketchpad2 is an extension of the default Sketchpad, right?

Yes, it is. But, if the TextW addition in Sketchpad does indeed break the compatibility with an existing addons then Martin might need to create a Sketchpad2 of his own to add TextW in it.

There is one other problem in sketchpad: SetFont(), SetPen() and SetBeush() are declared as "const" which is a major headache. Because a change in those properties would require a Sketchpad to flush a drawing queues and do most of the drawing in Set* functions. "const" functions can't alter Sketchpad state, everything would need to be "mutable". But there's probably nothing we can do about it. One possibility is to create an other interface for actual rendering/drawing and use the Sketchpad as a wrapper to access it, like it's used with the GDI... Well, maybe an other time...

Good night
 
Last edited:
I'll look into the PBR problem when I got time.
Thanks. I have been some further investigations into this and it seems like specular reflections are disabled for all textures not just PBR ones. Even the normal _spec textures doesn't work. I rolled back to RC1 of D3D9Client and everything worked. So something is definitely broken in RC2 and subsequent releases as far as specular reflection textures and PBR is concerned.

Edit:
These two screenshots show the problem in action:
https://www.dropbox.com/s/704g5wbjft88d9f/Spec_reflections_RC1.jpg?dl=0 (RC1, working)
https://www.dropbox.com/s/hqz2hvarsa79c1s/Spec_reflections_RC2.jpg?dl=0 (RC2.1, not working)
 
Last edited:
Thanks. I have been some further investigations into this and it seems like specular reflections are disabled for all textures not just PBR ones. Even the normal _spec textures doesn't work. I rolled back to RC1 of D3D9Client and everything worked. So something is definitely broken in RC2 and subsequent releases as far as specular reflection textures and PBR is concerned.

Edit:
These two screenshots show the problem in action:
https://www.dropbox.com/s/704g5wbjft88d9f/Spec_reflections_RC1.jpg?dl=0 (RC1, working)
https://www.dropbox.com/s/hqz2hvarsa79c1s/Spec_reflections_RC2.jpg?dl=0 (RC2.1, not working)

Ok, Thanks. I'll try to find some time to look into it. I saw something about a fresnel map mentioned somewhere in your posts. Fresnel map is an experimental feature used by developers to run tests. It can cause weird side effects if used. It's not a good idea to use it, the fresnel behavior will be re-written/re-implemented and the map format might change in a near future.
 
Ok, Thanks. I'll try to find some time to look into it. I saw something about a fresnel map mentioned somewhere in your posts. Fresnel map is an experimental feature used by developers to run tests. It can cause weird side effects if used. It's not a good idea to use it, the fresnel behavior will be re-written/re-implemented and the map format might change in a near future.
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.
 
Yes, it is. But, if the TextW addition in Sketchpad does indeed break the compatibility with an existing addons then Martin might need to create a Sketchpad2 of his own to add TextW in it.

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?
 
Back
Top