New Release D3D9Client Development

[DaveS]

How about glare instead of flares? That would add something better in my mind.

 

[SolarLiner]

How about glare instead of flares? That would add something better in my mind.

The lens flare shader is "modular", so you could simply delete all the flares and keep the glare only if you wanted. But the glare you see is the glare from the lens flare shader.
Though, since the cockpit is, technically, seen from eyes instead of cameras, I could have a conditions that would change the flare to a simple glare when in internal views.

EDIT: Here's a quick fix. Lens flare stays the same as before on external view.

 

[SolarLiner]

And for the grand finale:
[ame="http://www.youtube.com/watch?v=Zq-0HTmmSOc"]Orbiter 2016 D3D9 Client Lens Flare Test - YouTube[/ame]

I got the ray casting method to work, after realizing that one was already implemented for the D3D9 Debug Window. The sunrise colors are based on the colors in D3D9Util::OrbitalLighting() like I first implemented, but this time uses oapiCameraProxyGbody() which returns the closest planet to the camera instead of iterating through all planets.

 

[jarmonik]

And for the grand finale:

That looks absolutely stunning. Great work there.:tiphat:

---------- Post added at 10:14 ---------- Previous post was at 10:06 ----------

Also the lens flare seems to also be happening in the opposite direction the sun is at. And there, I have no idea why.

It is due to this equation float2 vPos = (pos.xy / pos.w)*.5; It should be clipped if pos.w is negative. Might be a good idea to compute the vPos in the Scene.cpp which would allow clipping the effect if the sun is behind the camera. Of course, there are many other ways to do the sun behind camera check.

---------- Post added at 11:29 ---------- Previous post was at 10:14 ----------

Also, if you want Xyon can give you a write access to the SVN and you can create your work branch. It would be easier to migrate the changes to the trunk from there.

 

[SolarLiner]

Thank you!
But now every transparent surface blocks the lens flare (for example, the glass panes in the DG VC), which means I'll need to make many more checks and calculations based on materials... Which means my work here isn't done. :lol:

I multiplied the brightness by saturate(pos.z) after figuring out what was going on, so that is all good now.

And I'll be happy to gain access.

 

[SolarLiner]

I changed the IsSunVisible() function to a more general GetSunScreenVisualState() function that returns brightness, size, and color - and that allows the sun to shine through transparent objects.

The impact on framerate is kinda big on virtual cockpit - optimization surely can be done on that.

Here's a build that I hope will work for everyone. (Not a complete zip, only the new files, overwrite over an existing D3D9Client for Beta installation)

 

[jarmonik]

The impact on framerate is kinda big on virtual cockpit - optimization surely can be done on that.

I am working on that. I'll try to get a better visibility check system for the Sun and local light sources. The ray-check system used by debug controls is certainly slow and only meant to be used to check mouse clicks.

I also sent a PM to Xyon regarding the SVN access.

---------- Post added at 18:56 ---------- Previous post was at 18:08 ----------

That package doesn't work. I had to edit/revert PBR.fx and Vessel.fx to get it working. Folder name "Plugins" is miss-spelled it's supposed to be "Plugin".

There's something really strange going on it's like it's creating a new Earth visual for every frame.

Orbital sunrise and glares looks great. The glare/flare of the sun itself is a bit too big in my taste.

 

[SolarLiner]

There's something really strange going on it's like it's creating a new Earth visual for every frame.

I didn't touch the atmosphere, nor the planetary rendering code, so I shouldn't have changed anything...

Orbital sunrise and glares looks great. The glare/flare of the sun itself is a bit too big in my taste.

I was thinking we could add a brightness slider, which would also change the size in a way... But if the glare itself is too big, with the other elements being fine, then that can be changed in the Lens Flare shader - hopefully everything's simple enough so that pretty much everyone could make its own flare configuration.

 

[Marg]

I haven't posted here for some time, but followed thread every couple of days... I was waiting for flare effect for a very long time, it is great to have it.

 

[SolarLiner]

Another showcase / feature demo here, for the color grading process:

(skip to 3:10 for the actual how to, my demo skills aren't the best :uhh: )

 

[Marg]

It would be interesting to try it out... I mean newest d3d9 client version...

 

[DaveS]

I'm in need of GC lib that were built for an earlier VS version as the one included with the package in this post seems to have been built for VS 2015.

 

[Fabri91]

Odd issue in the latest RC1 which happens only with the D3D9 client (or at least not with the embedded D3D7 one - didn't try with the separate D3D7 client): upon opening the target selection window from an MFD (e.g. Orbit or Map): it is very narrow.

 

[kuddel]

Odd issue in the latest RC1 which happens only with the D3D9 client (or at least not with the embedded D3D7 one - didn't try with the separate D3D7 client): upon opening the target selection window from an MFD (e.g. Orbit or Map): it is very narrow.

I can confirm this. Might be a client issue, but I have to check the D3D7Clients behavior too. Not much time though...any volunteers? The code is public you know :thumbup:
svn://mirror.orbiter-radio.co.uk/D3D9client/trunk

---------- Post added at 00:24 ---------- Previous post was at 00:15 ----------

By the way: Can anyone provide a binary build of D3D7Client?

 

[SolarLiner]

I can confirm this. Might be a client issue, but I have to check the D3D7Clients behavior too. Not much time though...any volunteers? The code is public you know :thumbup:
svn://mirror.orbiter-radio.co.uk/D3D9client/trunk

I could try to take on that tomorrow.

 

[Mojave]

Odd issue in the latest RC1 which happens only with the D3D9 client (or at least not with the embedded D3D7 one - didn't try with the separate D3D7 client): upon opening the target selection window from an MFD (e.g. Orbit or Map): it is very narrow.

I can confirm as well this is happening in the D3D9 client when running the Release Candidate.

 

[kuddel]

Thanks SolarLiner.

And for all that like to help but hesitate to use subversion, here's the current build (HEAD revision) of D3D9Client including sources.

 

[SolarLiner]

I can confirm this. Might be a client issue, but I have to check the D3D7Clients behavior too.

I'm on a linux laptop right now, with my windows computer on remote control - transferred myself through Pushbullet the API Reference, and it doesn't seem to have anywhere a callback function for when an input/list box is rendered. Maybe this is handled by the core after the graphics client render?

Actually...

17.20.3.82 void oapi::GraphicsClient::Render2DOverlay ( ) [protected]
Notifies Orbiter to to initiate rendering of the 2D scene overlay.
The 2D overlay is used to render 2D instrument panels, HUD, the info boxes at the top left and right of the screen,
etc. This function should typically be called at the end of clbkRenderScene, after the 3D scene has been rendered,
but before the rendering environment is released. During the execution of this function, Orbiter will call the clbk←-
Render2DPanel function several times to allow the client to build up the 2D layer.

The core takes care of 2D panel rendering. So it might as well handle those selection boxes.
Does it happen inline (I'd think not, it'd have been reported already) as well? An in the D3D7 Client?

---------- Post added at 00:08 ---------- Previous post was at 00:01 ----------

The D3D7 Client, despite being very slow and almost non working, at least has the selection box behaving normally.

 

[jarmonik]

Looks like Orbiter passes a zero length in Sketchpad::GetTextWidth() causing an error condition. So, apparently zero length means whole line up to the NULL terminator.

It's fixed now.

 

[kuddel]

D3D9Client Beta 24.1.1 for BETA r57 (r733)

Looks like Orbiter passes a zero length in Sketchpad::GetTextWidth() causing an error condition. So, apparently zero length means whole line up to the NULL terminator.

Just like the API documentation says

It's fixed now.

I can confirm.
And attached a new build (this time build with Visual Studio 2012, 'cause I'm not at home) cause the previous one is not really usable now.