New Release D3D9Client Development

[jarmonik]

I made a new build using a static linking, it shouldn't require VC++ 2008 runtimes anymore. (Debug runtimes actually). That might have been the problem.

 

[Cras]

Ok that did the trick, the new Dx9ExtMFD showed up.

I loaded up the DGIV on the KSC runway, ready to go to ISS scenario that comes with the DGIV package. I opened 5 maps on Dx9ExtMFDs, made some huge, covered the whole screen. Before it took only two open with the default to crash my framerate, now with this overkill usage of MapMFD, I saw only a 5-10 fps drop, so I say things are working good here. With only one and two open in Dx9ExtMFD the frame rate penalty was practically zero.

Again this is with an MFD refresh rate of 0.01s

 

[jarmonik]

Thanks for testing the client. Sound like we are good to proceed forward with the release. I'll wait a while and I'll test the client with my laptop before uploading R15.

 

[Fra123X]

Hello everyone.
I'm encountering some weird graphical glitches in the D3D9 versions of the Orbiter 2015's beta.
Using the last version of the beta, in random spots and random times these things start appearing:

And they keep standing there until I move the camera away and then look back.
This happens both on the Earth and on the Moon, I can't tell if the issue is present on mars too, because I'm experiencing the Black mars bug too.

If I Roll back to the Revision 8 version, I don't seem to encounter the glitch anymore, but everytime I start any HUD in any 3d cockpit, it looks like this:

Is it an actual bug, or is there anything I can do to resolve it?
Thanks

 

[Frankynov]

Hello Jarmonic,

Since the latest betas I can't seem to be able to launch Orbiter anymore...
Here is the error message, complaining about procedures entry points not available in dynamic links library.



I'm using the latest AMD driver on 8.1 on a R9 280 3GB.

Thanks for the hard work !

 

[jedidia]

Hmmm... any chance you're using the non-Beta dll? missing entry points usually indicate that you have a dll of the right name but not the right version.

 

[Disconnect]

I've just installed beta 10 with the latest d3d9 (rev 9), but i seeing graphical glitches like missing tiles when looking from certain angles, mars is totally black just like phobos and deimos, and spacecraft are illuminated by sun from the opposite direction of what should be when on the ground, lot of flickering, misaligned elevation tiles.
Is this because of the version difference or something else?

PS: it happens if i use revision 9 orbiter

 

[jarmonik]

Hello everyone.
I'm encountering some weird graphical glitches in the D3D9 versions of the Orbiter 2015's beta.

Sorry, I can't see the images you have posted. But I do have a pretty good idea of the issues you have reported.

---------- Post added at 09:15 ---------- Previous post was at 09:06 ----------

I've just installed beta 10 with the latest d3d9 (rev 9), but i seeing graphical glitches like missing tiles when looking from certain angles, mars is totally black just like phobos and deimos, and spacecraft are illuminated by sun from the opposite direction of what should be when on the ground, lot of flickering, misaligned elevation tiles.
Is this because of the version difference or something else?

PS: it happens if i use revision 9 orbiter

I don't know exactly. All those issues you have reported did exists in Beta 9 but should be fixed from Beta 10.

If the mars is black then do you see Mars.atmo.cfg and Mars.atms.cfg files in your /Config/GC/ folder ? Are these files present in the Beta 10 distribution package you have ?

I have already mostly merged the recent changes from R15 into the Orbiter Beta Client. R15 is mostly ready for release. When I get it out of my hands then I have time to look in the Orbiter Beta issues.

 

[Fra123X]

Sorry, I can't see the images you have posted. But I do have a pretty good idea of the issues you have reported.

Oh, sorry, here are the images links in order:

First
Second
Third

If you still don't see them I may upload them using another image hosting site.

I've just installed beta 10 with the latest d3d9 (rev 9), but i seeing graphical glitches like missing tiles when looking from certain angles, mars is totally black just like phobos and deimos, and spacecraft are illuminated by sun from the opposite direction of what should be when on the ground, lot of flickering, misaligned elevation tiles.
Is this because of the version difference or something else?

PS: it happens if i use revision 9 orbiter

I think you are experiencing just the same thing of me.

 

[Disconnect]

If the mars is black then do you see Mars.atmo.cfg and Mars.atms.cfg files in your /Config/GC/ folder ? Are these files present in the Beta 10 distribution package you have ?

No, i have Mars.atm.cfg only, no others for mars for earth i have atmo, atms and atm too. (the svn update did not find missing files).
However as i wrote, phobos and deimos neither visible.

Here is a video with some bugs around the Moon.
https://www.dropbox.com/s/wpr1xwqx1y3t4hh/orbiter 2015-01-10 01-22-00-398.avi?dl=0

 

[jarmonik]

D3D9Client R15 Released

All right, here's D3D9Client R15 for Orbiter2010-P1 and there are many new things in it. The R15 is now available from the CodePlex site.

- The 2D surface interface is redesigned. This was not exactly planned nor scheduled for R15. But we created a new cleanded up interface for the Orbiter Beta and it was tested and approved there. After that it was brought back to P1 to replace it's messy interface. After being put in a serious stress tests on P1 some very fundamental flaws was discovered. So, we had to redesign it and it should be now better then we have had before. It appears that lockable-render targets do not work very well with the GDI, in-fact none of a video memory surfaces works. Would it be possible that PCI-express bus is designed for a mass transfer of data not to execute random read-modify-write operations in a video memory ?

- There is also DX9ExtMFD plugin in the distribution package that should work much better with some hardware. It is also compatible with the inline engine and should not be needed on Orbiter Beta after the base class of ExtMFD is fixed. Source code is in the first post.

- R15 includes an experimental mesh group instancing implementation. It should allow more efficiently to transfer vertex data for a graphics hardware for rendering. Rendering of shadows should be able to take the best advantage of it. Instancing will make some changes in the rendering order of mesh groups but it should be able maintain the initial order when it counts.

- Proof-of-concept implementation of graphics client interface is also included in R15. This is something that should be discussed about, how to proceed with the interface or if to proceed at all. So, what are the pros, cons ? The idea is to provide some additional features for add-on developers so that Martin wouldn't need to implement every feature. One problem is that interface like this could make add-on features more depend on clients. But if the inline engine isn't going to be upgraded to use a new DX then I don't know...

- Currently the client interface includes a custom camera interface that can be used to create a docking and payload bay cameras, etc... Pre-build binary and a sample code included in the first post.

- The client interface also includes some Sketchpad goodies. Well, there are a few problems: In DX10 and DX11 there exists no blitter capable of scaling, color-keying nor alpha blending. All these actions must be executed with the primary GPU. Therefore, it would be practical to have these features included in the Sketchpad since it's using the GPU anyway. So, it could be possible to turn the Sketchpad into a future all-in-one 2D drawing interface for the Orbiter. Of course, it would be possible to have at-least scaling and color-keying included in the GDI version of the Sketchpad as well.

Now that the R15 is out, I should have more time to look into the Orbiter Beta Client.

 

[SolarLiner]

[HEAVY BREATHING]
Is that for real? POST PROCESSING? :woohoo:

 

[Donamy]

Can you explain more about the mesh grouping issues. I use a transparent group, sandwitched between the fuselage, and the startrackers, of the SSU Orbiter mesh. It blocks out the section of the fuselage, to see the startracker underneath. With the newest R15 release, you can't see the startrackers.

 

[jarmonik]

Can you explain more about the mesh grouping issues. I use a transparent group, sandwitched between the fuselage, and the startrackers, of the SSU Orbiter mesh. It blocks out the section of the fuselage, to see the startracker underneath. With the newest R15 release, you can't see the startrackers.

The algorithm is pretty simple.

1. It will take the first mesh group that is not yet rendered.
2. It will check what material and texture ID:s are used by the group.
3. It will render the group and the next 7 groups after that using the same ID:s

So, the rendering "position" of a mesh group depends on when is the group's material/texture combination used the first time.

I checked the SSU Mesh and it's likely a Material 6 that is causing the problem. Unless I am mistaking Material 6 is used first time in a mesh group 58 and that will define where at-least 8 mesh groups using the Material 6 are rendered. So, to make sure that the startrackers are visible through transparent material, the material must not be used before rendering the startrackers. I hope this makes some sense and doesn't cause too much trouble.

 

[Donamy]

I understand, but don't know what the solution is. :shrug:

 

[jarmonik]

I understand, but don't know what the solution is. :shrug:

Currently there are two solutions:

A) Create a new Material for transparent groups those are blocking something.
B) Raise the mesh group index numbers of all transparent mesh groups above all non-transparent.


Also, I have been thinking that we should have a post rendering pass for a transparent mesh groups.

1.) Render Main rendering pass for all vessels and meshes.
2.) Render a post rendering pass for all vessels and meshes with distance sorting.

That strategy should fix all transparency issues/problems we are having in the Orbiter.

 

[kuddel]

Also, I have been thinking that we should have a post rendering pass for a transparent mesh groups.

1.) Render Main rendering pass for all vessels and meshes.
2.) Render a post rendering pass for all vessels and meshes with distance sorting.

That strategy should fix all transparency issues/problems we are having in the Orbiter.

We should go for this "third option".
To quote Scott Meyers: "Make interfaces easy to use correctly and hard to use incorrectly."
Unless this would mean a substantial performance drop.

 

[jarmonik]

I think there could be a fourth option as well a quick fix of a sort. If the instancing algorithm is modified in a way that it will first browse through all non-transparent mesh groups then a transparent mesh groups on a second pass. That should fix the SSU mesh problem. But it wouldn't fix vessel to vessel transparency problems like the third option would. Also, the third option would require a post render mesh groups flag (which does not yet exists) for a groups using semi-transparent textures since the material alpha could still be 1.0

 

[jarmonik]

Here's a hot fix that should fix the SSU mesh transparency problem. Beyond that I haven't had time to test it.

The Hot Fix is for R15 for Orbiter 2010-P1

 

[Donamy]

Did not fix the problem.

The first screenshot is no client, the second is R15 with hotfix.
the third shows the transparent group, that acts as a window to show the trackers underneath the fuselage skin.

the group order is

first= trackers
second=transparent group
third= fuselage