New Release D3D9Client Development

[Ripley]

There is still something going on with external MFDs...

If I was jarmonik, I'd ask you to make the same test in a vanilla Orbiter install, with just the D3D9 client and the default ships and MFDs.
:tiphat:

 

[4throck]

... light intensity is the same at Earth and at Jupiter, which is another "cheat" to get a proper picture at all distances. (Neptune receives 0.1% of the intensity compared to Earth, while Mercury gets 470% of intensity compared to Earth)

Indeed that is not simulated.

But let's imagine:
Both the planet and your vessel receive 0.1% or 470% of the light. Adapting exposure would get those values to 100% and you the same results as constant lightning (for the ship and planet).
With that setup what needs to change are local light sources, emissive material and background stars +planets+satellites intensity :lol:.

 

[SolarLiner]

Yeah with a proper light transport simulation you'd feel your local lights to not be really useful on Mercury but light things up pretty great on Triton for example. Even with a eye adaptation approximation you'd still feel the effect.

---------- Post added at 19:12 ---------- Previous post was at 19:03 ----------

At start of the scenario I am near 500 fps. By the time I am ready to deorbit burn, which was about 7 orbits later, most done at x100 time accel, I am down to under 150. That is a huge performance loss.

Remember 500 fps means a frame takes 1/500 = 2 ms to show. 1/150 is 6 ms. That's a 4 ms increase. The effect is there, but it's not the big performance loss. Someone playing usually at 60 fps avg. would end up getting 48 fps avg., which doesn't seem that costly anymore, even if the loss is still there.

That being said, there is a performance loss. I was just saying.

 

[Cras]

Remember 500 fps means a frame takes 1/500 = 2 ms to show. 1/150 is 6 ms. That's a 4 ms increase. The effect is there, but it's not the big performance loss. Someone playing usually at 60 fps avg. would end up getting 48 fps avg., which doesn't seem that costly anymore, even if the loss is still there.

That being said, there is a performance loss. I was just saying.

Normally I would agree with you but the performance loss has an additional manifestation to it. Even at 100+ fps, the sim should appear smooth since it is above my display's refresh rate of 59mhz but this is not the case, there is a clear stutter occurring. Going to an external view of the vessel and moving the camera around the movements are very choppy, far more so than one would expect at that frame rate. That is how I came to be aware of the problem in the first place.

I know the issue still lies in the use of ext mfds because you close those out and the performance appears to be totally regained. I hope to try some more testing today because I have seen some hints of a pattern that links performance loss also with alt-tabbing out of the sim with Ext MFds open as well. Not sure if that is real or just a coincidence or me just watching the FPS too closely and trying to pick things out of thin air here.

 

[SolarLiner]

Normally I would agree with you but the performance loss has an additional manifestation to it. Even at 100+ fps, the sim should appear smooth since it is above my display's refresh rate of 59mhz but this is not the case, there is a clear stutter occurring. Going to an external view of the vessel and moving the camera around the movements are very choppy, far more so than one would expect at that frame rate. That is how I came to be aware of the problem in the first place.

I know the issue still lies in the use of ext mfds because you close those out and the performance appears to be totally regained. I hope to try some more testing today because I have seen some hints of a pattern that links performance loss also with alt-tabbing out of the sim with Ext MFds open as well. Not sure if that is real or just a coincidence or me just watching the FPS too closely and trying to pick things out of thin air here.

Maybe that's because there's a mismatch between the screen refresh rate and the game refresh rate: you end up with frames not displayed at the right time and end up with stuttering even if your FPS are way higher than 60 fps.
That is why V-sync exists: it locks the framerate at your screen refresh rate (or some multiplier of it) so that you don't have tearing and your game is displaying frames exactly when your screen is awaiting for them.

 

[Cras]

It is not tearing, I know a what that looks like. This is different. And we all should know that v-sync is not what you want to go with in Orbiter. Higher frames equates to more accurate simulation.

 

[jarmonik]

There is still something going on with external MFDs. I have a few open in prep for a deorbit with the XR-2. At start of the scenario I am near 500 fps. By the time I am ready to deorbit burn, which was about 7 orbits later, most done at x100 time accel, I am down to under 150. That is a huge performance loss. I am wondering if I am seeing an accelerated loss due to my settings, I use the GeForce drivers to use more aggressive Antialiasing and Anisotropic filtering.

I am not going that over the top with ext mfds, and yes I made sure I was using the Dx9 version of the ext mfd. I use this same flow with external mfds back in R12 of the client and never saw such performance loss. R12 still seems to be the most stable build for 2010p1.

I'll try to find some time to study how the things were done in R12 if it would give some ideas. The 2D surface management is a nightmare. BTW, Is the problem reproducible with the latest Beta ? Debugging that would be little more productive than the old 2010-P1.

 

[DaveS]

The sunrise/sunset effects in the beta version are still a bit off. There's just too much yellow. This video tweeted by Jeff Williams a few hours ago shows things really well: https://twitter.com/Astro_Jeff/status/731071859211440134

 

[4throck]

About V-sync:

On some games v-sync causes me to experience 10 to 20% FPS drop!
Turning it off usually gives me better performance. Oddly enough with sync off I don't see tearing.

 

[Cras]

I'll try to find some time to study how the things were done in R12 if it would give some ideas. The 2D surface management is a nightmare. BTW, Is the problem reproducible with the latest Beta ? Debugging that would be little more productive than the old 2010-P1.

Yeah I do need to get around building an install for the new beta and try that out. Hopefully I can get that done soon and see if the same issue arises.

 

[DaveS]

I'm getting a bunch of of these error messages with SSU on the latest D3D9Client for the Orbiter beta:

D3D9Client log can be found here: https://dl.dropboxusercontent.com/u/24122088/Orbiter stuff/D3D9ClientLog.html

 

[jarmonik]

I'm getting a bunch of of these error messages with SSU on the latest D3D9Client for the Orbiter beta:

Can you change "SSU\ODSbuttons.dds" to use DXT1 instead of DXT3, DXT5 ? or does it need alpha channel ?

DXT1 is decompressed to R8G8B8 where as DXT3 and DXT5 are decompressed to A8R8G8B8, this effects in oapiBlt() compatibility. Not sure if we should decompress every surface in R8G8B8, any ideas ?

 

[DaveS]

Can you change "SSU\ODSbuttons.dds" to use DXT1 instead of DXT3, DXT5 ? or does it need alpha channel ?

Thanks, changed it to DXT1 and no more error messages. Why it was DXT3, I don't know.

Edit:
Something else for the beta:
Weird blue effect covering the shaded parts of the orbiter:

---------- Post added at 04:13 PM ---------- Previous post was at 12:01 PM ----------

This is another issue with beta D3D9Client that has been discovered:

It's that the meshes behind the transparent sections in the encircled area are not rendered as they used to be in the stable D3D9Client. You should be able to see the ARCS nozzles through the transparent sections but instead all you get is the background.

Beta:

Stable:

 

[jarmonik]

Something else for the beta:
Weird blue effect covering the shaded parts of the orbiter:

I can't really say... I'll have to install the SSU and have a closer look, do you have a download link ?

 

[DaveS]

I can't really say... I'll have to install the SSU and have a closer look, do you have a download link ?

Other than the official v3.0 link and the SVN repository, no.

 

[jarmonik]

Here's a new version for testing.

1. Reported mesh render issues should be fixed.

2. Runway lights bug fixed.

3. Texture tuning feature has been added in mesh debugger. This allows to fine tune textures and see the results in real time.

- Check "Pick" checkbox.
- Click a surface having a texture from a Mesh.
- Select some of the "Tune" features from Material Properties list
- Tune it via the slider.

Notes:
- It's not possible to tune a texture that doesn't exists.
- Tuning range is limited to 0.1x to 10x
- Tuning is not saved. Final changes need to be manually applied to the texture.
- It's possible to tune some properties out of range causing a graphics anomalies.

 

[DaveS]

I can confirm that the mesh rendering issues reported by me earlier has been fixed!

 

[Weirdo Earthtorch]

Hi Jarmonik, thanks as usual for your work on the D3D9 client, to me, the visuals look stunning.

I have a request which may or may not be a lot of work. Having recently acquired a GearVR, I have tried Orbiter with 'Tridef 3D' which, I understand, 'injects' itself into the D3D9 display at some point and forces two camera views for side-by-side display on the GearVR, using 'Trinus VR' to connect to the phone display over wifi. (TrinusVR itself can create 'faux' 3D by duplicating the single view).

The results look pretty promising, although there is an issue with the VC scale/draw order (I guess, it's pretty difficult to describe and/or record with video). I wondered if the issues might be to do with the way Tridef 3D works, and whether native side-by-side would be a) possible and b) easy/practical to implement - given that it appears there is already an option to use NVIDIA 3DVision.

Here's a screenshot of what Tridef3D does to Orbiter - all I am doing is then using Trinus VR with Orbiter as the active window. (And I did capture some of the draw issues)

Thanks, WE.

 

[jgrillo2002]

Question. Does the new atmosphere effect for the Beta version D3D9 work with 2010?

 

[SolarLiner]

No. The atmosphere effect was implemented with terrain, and thus only works with Orbiter 2015 Beta and the D3D9 client releases for it.