New Release D3D9Client Development

[jedidia]

Huh... any idea why it doesn't seem to happen on the IntelHD card?

Also, is this preventable/configurable somehow? I can see how this would be desirable if you're making a lot of changes in the mesh a lot of times, but basically IMS2 just rotates them to their proper alignement and then doesn't touch them anymore, so less performance when writing to the mesh wouldn't really be an issue.

 

[jarmonik]

Huh... any idea why it doesn't seem to happen on the IntelHD card?

It probably just has one generic vertex buffer type.

Also, is this preventable/configurable somehow?

Right now it's not. But it would be possible to control it using a mesh group flags.

I can see how this would be desirable if you're making a lot of changes in the mesh a lot of times, but basically IMS2 just rotates them to their proper alignement and then doesn't touch them anymore, so less performance when writing to the mesh wouldn't really be an issue.

That would be a job for a matrix but right now there's no way of setting one directly on a mesh. It would be possible to implement gcSetMeshMatrix() function but it wouldn't work with the inline engine.

Conversion to dynamic mesh was implemented due to performance problems in a VC of stock delta glider and some other vessels. Since, they require mesh changes in a per frame basis.

 

[jedidia]

Right now it's not. But it would be possible to control it using a mesh group flags.

That would be great! consider it a feature request.

That would be a job for a matrix but right now there's no way of setting one directly on a mesh.

Yeah, EditMeshGroup was pretty much the only possibility since MeshgroupTransform isn't supported by D3D9client.

 

[GLS]

I don't know if its just me, but the runway lights at Edwards are being show at about 700m above the runway, and in some scenarios they are still up in the clouds but not above the runway.

 

[jarmonik]

I don't know if its just me, but the runway lights at Edwards are being show at about 700m above the runway, and in some scenarios they are still up in the clouds but not above the runway.

Yes, I have noticed that too. Something is messing up with the runway lights in Orbiter Beta. However, they appear correctly on Orbiter 2016.

---------- Post added at 07:15 ---------- Previous post was at 07:04 ----------

That would be great! consider it a feature request.

It would work on D3D9 but we don't know if it's a valid solution on DX11, 12 or OpenGL. That would also impact in rendering optimizations like instancing.

If the Orbiter API would allow a user to specify a mesh transform matrix then that would be better solution in my opinion. There's no way of getting that to 2010-P1 but maybe to 2016-P1.

 

[GLS]

Yes, I have noticed that too. Something is messing up with the runway lights in Orbiter Beta. However, they appear correctly on Orbiter 2016.

Yes, I forgot to say that I'm using all the latest versions.

 

[jedidia]

It would work on D3D9 but we don't know if it's a valid solution on DX11, 12 or OpenGL. That would also impact in rendering optimizations like instancing.

If the Orbiter API would allow a user to specify a mesh transform matrix then that would be better solution in my opinion. There's no way of getting that to 2010-P1 but maybe to 2016-P1.

In other words, a feature request for the Doctor would be in order. Before I do that, I wanted to ask about MeshgroupTransform. The docs say it's "not yet supported by orbiter_ng", but I remember that it was the method used to rotate the meshes in the original IMS, a long while ago, before it started to support D3D9client.
Using EditMeshGroup became neccessary simply because it was the only option when using a graphics client, and if I'm not entirely mistaken, UCGO does the exact same thing.

So, if MeshgroupTransform were supported by Orbiter_ng, would that solve the problem, or do you explicitly need a matrix setable for the entire mesh? I just want to make sure that I'm not requesting the wrong thing. If MeshgroupTransform could do the job, it would make more sense to request its implementation rather than a completely new method.

 

[jarmonik]

In D3D9 we have 4 matrices those are used to specify a transform for a mesh group.

a) Vessel's world matrix.
b) Mesh offset matrix.
c) Mesh animation matrix.
d) Group animation matrix.

All these transforms are pre-multiplied by CPU into a final world matrix which is then sent to render hardware for each rendered mesh group.

The D3D7Client also has the same "mesh offset matrix" that is currently used by ShiftMesh() call. So, the only thing that is missing is an API call to fully specify the "mesh offset matrix". That would not cause conflicts with animations applied to the mesh or meshgroups. So, the mesh would retain it's animation behavior. Even if shifted, rotated or scaled.

It would be possible to provide a support for MeshGroupTransform() function by directly setting the "group animation matrix" but it would not work together (at the same time) with meshgroup animations. And I don't really like an idea of adding a fifth matrix into the sequence especially if it's applied in per group basis.

 

[jedidia]

Say, is it possible that reflection maps and specular reflections are broken in the latest revision? I have weeded through all my NVidia settings and am confident that there is no configuration for this instance of Orbiter_ng that would somehow suppress them.
Yet they don't show up, and if I run the same tests in an Orbiter 2016 release installation with D3D9client R1, they work without a hitch.

EDIT:

Almost forgot, there also seems to be an issue with down-scaling of cockpit panels that is not present in the inline client. Read from here downward:

http://orbiter-forum.com/showthread.php?p=552478&postcount=12

 

[kuddel]

D3D9Client (Beta 25.2) for BETA r61 & 2016

Hello (Fort),

as I am unable to attach files in PMs, I'll post 'em here:

Attached are two builds of the current HEAD revision of D3D9Client trunk (which is Version 25.2).
Both were build with Visual Studio 2012 and should be "XP ready"(TM).
If you really need a Visual Studio 2015 build (I doubt), you have to wait until this evening...

• D3D9ClientBeta25.2-for2016(r821).zip linked against Orbiter 2016 [160828] (official release)
• D3D9ClientBeta25.2-forBETA r65(r821).zip linked against Orbiter BETA revision 65 [161125]

Hello kuddel,

You had very kindly realized, last year, a version of the D3D9 client of Jarmonik for users of Windows XP and Orbiter 2010 ( me and also formerly Ripley ), called "XP ready" (TM), this with VS2015. I still use XP ( and I continue testing nightlights ) and I would be interested to see the result of my trys with the last stable official d3d9 client
( http://d3d9client.codeplex.com/ ) and orbiter 2016.

I am a little embarrassed to ask you for this, but have you kept your installation of VS 2015 and if so, would you have some time to realize a new D3D9 XP ready for Orbiter 2016 ?

good day

fort

..hope this helps,
/Kuddel

 

[fort]

Hello Kuddle,

Thank you again. Is the 25.2 different of the D3D9Client 2016 Edition R1 or is it only a different naming ?

good day.

note:at least, it's a good idea to put your XP Ready here instead that in a private message.

note2: VS2012...VS2015 ?

 

[kuddel]

Thank you again. Is the 25.2 different of the D3D9Client 2016 Edition R1 or is it only a different naming ?

Yes it is! The "D3D9Client 2016 Edition R1" was a build of r781, while "D3D9Client 25.2" is a build of r821 (...D3D9Client revision numbers those are).

The "D3D9Client 2016 Edition R1" was build to work with Orbiter 2016. My "D3D9Client 25.2" was build to work with latest Orbiter BETA (revision 65).

I know it's getting more and more confusing with all these numbers, right? :lol:

note2: VS2012...VS2015 ?

What? You asked for it...
But maybe it's just another confusion here:

• VS2012 means : ...build with Visual Studio 2012
• VS2015 means : ...build with Visual Studio 2015

...indicating the build environment under which these versions were build.
Usually this should not make any difference to the end-user, but we've had different results with different build-environments, so therefore I noted that here.

Long story cut short:
I think you should use D3D9ClientBeta25.2-for2016(r821).zip (linked against Orbiter 2016 [160828], build with Visual Studio 2012)

/Kuddel

 

[fort]

Hello Kuddel,

Back at my office now. So, i'll experiment this evening with the D3D9 XP Ready. But, for sûre,
once again, "it's getting more and more confusing with all these numbers":facepalm:

 

[jarmonik]

Say, is it possible that reflection maps and specular reflections are broken in the latest revision? I have weeded through all my NVidia settings and am confident that there is no configuration for this instance of Orbiter_ng that would somehow suppress them.
Yet they don't show up, and if I run the same tests in an Orbiter 2016 release installation with D3D9client R1, they work without a hitch.

They are working here as expected. But we have done some changes in the code so something could be broken. Nothing to worry about.

Almost forgot, there also seems to be an issue with down-scaling of cockpit panels that is not present in the inline client. Read from here downward:
http://orbiter-forum.com/showthread.php?p=552478&postcount=12

Is there a way to display the panel with the recent test scenarios you have provided ?
Is a colorkey in use there ?

 

[fort]

Hello kuddel

Marcogavazzeni found a difficulty with a recent version of D3D9 ( D3D9ClientBeta25_2-for Rev65 i think ) and the nightlights for the ASVI base that it realizes.

http://www.orbiter-forum.com/showthread.php?p=551103&postcount=4247

He asked the question to Jarmonik but it seems that it has not had an answer at the moment and has remained at an earlier version ( 25_1 i suppose ). I just addressed some minutes ago a question to him to let me know which version was problematic and whether it was a problem with ASVI alone or with all Orbiter's night lights.

I do not have the ability at this moment to do tests and maybe not before Thursday. But I also await the answer of marcogavazzeni.

In all respects I just need a 'standard', 'public', version of D3D9 (although this is not the latest revision) running with a 'standard', 'public', version of Orbiter (Orbiter 2016) even though this is not the latest revision. On XP.

I wait for the answer of marcogavazzeni.

good day and thank you again.

 

[jedidia]

Is there a way to display the panel with the recent test scenarios you have provided ?

No problem. Launch any of the two scenarios in a 1280x800 window (not fullscreen window), press F1 to enter cockpit, then press ctrl-down to get to the engineering panel. The issue should be immediately apparent.

Is a colorkey in use there ?

Nope. Though using color keys would have made a lot of things a lot easier, as far as I remember orbiter_ng doesn't support them.

 

[kuddel]

Hello kuddel

Marcogavazzeni found a difficulty with a recent version of D3D9 [...]
He asked the question to Jarmonik but it seems that it has not had an answer at the moment and has remained at an earlier version ( 25_1 i suppose ). I just addressed some minutes ago a question to him to let me know which version was problematic and whether it was a problem with ASVI alone or with all Orbiter's night lights.

I saw his post, but I am not really into this issue. I would wait a little longer, maybe Jarmo has some more to say :thumbup:

If he is really desperate, I can take a look into it (but not in the near future, sorry).

In all respects I just need a 'standard', 'public', version of D3D9 (although this is not the latest revision) running with a 'standard', 'public', version of Orbiter (Orbiter 2016) even though this is not the latest revision. On XP.

In that case you can use use D3D9ClientBeta25.2-for2016(r821).zip linked against Orbiter 2016 [160828] (wich is for the latest official Orbiter release).
It is NOT the same as the Version available at Codeplex! it has some more features/fixes (and bugs) that that

I'll try to build the "2016-R1" Version and post it as soon as I have it (although that "codeplex-version" should be "XP-ready"(TM) too...but who knows).

/Kuddel

 

[jarmonik]

I saw his post, but I am not really into this issue. I would wait a little longer, maybe Jarmo has some more to say :thumbup:

Fixed in 822

---------- Post added at 23:22 ---------- Previous post was at 23:18 ----------

Nope. Though using color keys would have made a lot of things a lot easier, as far as I remember orbiter_ng doesn't support them.

Color-keys are working in _ng but not with stretching. We have already an alpha-blend support in D3D9 via SketchPad2 interface but it's not compatible with the inline engine.

But anyway, the panel scaling issue is fixed in r.823

 

[fort]

In that case you can use use D3D9ClientBeta25.2-for2016(r821).zip linked against Orbiter 2016 [160828] (wich is for the latest official Orbiter release).

Good. But is not it this version ( D3D9ClientBeta25.2-for2016 (r821)) wich give a problem for marcogavazzenihttp://www.orbiter-forum.com/member.php?u=1994 for nightlights ? And: was it local (ASVI alone) or global ? I'm waiting for his answer.

I see nevertheless that Jarmonik, that I thanks here, seems to have given a solution with the version 822, also ...

I'll try to build the "2016-R1" Version and post it as soon as I have it (although that "codeplex-version" should be "XP-ready"(TM) too...but who knows).

Yes.I would actually be interested in a simple 2016-R1 for Orbiter 2016 official and XP. There is no urgency.

Very ashamed to ask you all this. I have almost all the processes to make interesting nightlights on Orbiter 2016 (roads, buildings ...) but I would like before to finish get an idea of what I can obtain with a D3D9 classic.

good day (or night) kuddel and thank you to you Jarmonik.

 

[kuddel]

D3D9Client (2016-R1++) for Orbiter 2016

Hi Fort et al,

here's a build for Orbiter 2016 (...that should be "XP-ready"(TM) )
This is a D3D9Client build that is NOT the most recent version!
It is a build from the 2016 branch of D3D9Client and only includes bug-fixes (no new features).

Changes (compared to the "codeplex" 2016-R1 version):

• Mars horizon flicker bug fixed
• Particle effect position bug fixed.
• Reverted particle lighting to defaults. In a hope to address reported "dark" particles issue.
• Particle streams: gravitational acceleration reduced as a function of atmospheric density (see http://www.orbiter-forum.com/project.php?issueid=1214)
• Fixing Texture-path issues...
• adjusted build_release.bat & get_orbiter_libs.bat to fit Orbiter 2016 release.
• Minor bug fixes.

Those changes have already found their way into the 2016 branch and I don't think they should be left out!

/Kuddel