New Release D3D9Client Development

[BruceJohnJennerLawso]

It appears that Orulex crashes the D3D9 client. Can anyone else confirm this?

 

[Cras]

You can find SF here: http://simviation.com/1/browse-Orbiter+Addons-142-1

and yes, I have Orbiter installed on a different hard drive, not C: but rather I:

and it seems this is only a Windows 7 issue. I didnt see the warning testing in Windows Xp x64

---------- Post added at 12:34 PM ---------- Previous post was at 12:34 PM ----------

It appears that Orulex crashes the D3D9 client. Can anyone else confirm this?

Orulex never has and never will work with the D3D9 client.

 

[jarmonik]

You can find SF here: http://simviation.com/1/browse-Orbiter+Addons-142-1
and yes, I have Orbiter installed on a different hard drive, not C: but rather I:

Oh, Thanks. I am happy to see it's still available. I thought I lost it forever.

Looks like the link problem is related to a drive letter. I belive I can find a way to fix that.

 

[Felipi1205]

I'm having problems with NormalMap.fx! What is wrong? What can I do?

---------- Post added at 03:09 PM ---------- Previous post was at 03:04 PM ----------

NormalMap.fx : Error X5608: Compiled shader code uses too many arithmetic instruction slots (70).
...
Mesh.fx ID3DXEffectCompiler: Compilation Failed

When I changed the NormalMap.fz to an older version, the problem disappeared, but some problems happened in Saturn (The Ring's shadow)

 

[jarmonik]

I'm having problems with NormalMap.fx! What is wrong? What can I do?
NormalMap.fx : Error X5608: Compiled shader code uses too many arithmetic instruction slots (70).
When I changed the NormalMap.fz to an older version, the problem disappeared, but some problems happened in Saturn (The Ring's shadow)

Looks like the NormalMap.fx has grown too big to fit in Shader Model 2.0

Here is a replacement file that should work. Mesh debugger features won't work with this file with a normal mapped meshes.

 

[Tschachim]

Hi Jarmo,

did you change anything related to surface base config files? R1 doesn't find the config file for the NASSP Canaveral base, with RC47 and earlier it was fine:

(525: 42.43s 83084us)(0x36B8) New Base Visual(0x14D672D8) Cape Canaveral hBase=0x242B3E0, nsbs=8, nsas=1
(526: 42.43s 83118us)(0x36B8)[ERROR] Configuration file not found for object 0x242B3E0
(527: 42.43s 83546us)(0x36B8)[ERROR] Configuration file not found for object 0x242B3E0

If I need to change the config files, I can do that, of course.

Thanks in advance
Tschachim

 

[jarmonik]

Hi Jarmo,

did you change anything related to surface base config files? R1 doesn't find the config file for the NASSP Canaveral base, with RC47 and earlier it was fine:

(525: 42.43s 83084us)(0x36B8) New Base Visual(0x14D672D8) Cape Canaveral hBase=0x242B3E0, nsbs=8, nsas=1
(526: 42.43s 83118us)(0x36B8)[ERROR] Configuration file not found for object 0x242B3E0
(527: 42.43s 83546us)(0x36B8)[ERROR] Configuration file not found for object 0x242B3E0

If I need to change the config files, I can do that, of course.

Thanks in advance
Tschachim

No, I haven't touched that code section since RC45. Atleast not intentionally. It's a problem in the file parser section. It's better to find a reason for that because the problem may appear with many other add-ons as well.

Could you post the log from the file parser section. It might help a bit.

(351: 10.76s 1us)(0xE2C) ================ clbkPostCreation ===============
(352: 10.76s 139us)(0xE2C) Parsing a planet Config\Sun.cfg
(353: 10.76s 177us)(0xE2C) Default Path Sun\Base
(354: 10.76s 205us)(0xE2C) Scanning bases from Config\Sun\Base
(355: 10.76s 241us)(0xE2C) Parsing a planet Config\Mercury.cfg
(356: 10.76s 276us)(0xE2C) Default Path Mercury\Base
(357: 10.76s 317us)(0xE2C) Scanning bases from Config\Mercury\Base
(358: 10.76s 350us)(0xE2C) Parsing a planet Config\Venus.cfg
(359: 10.76s 386us)(0xE2C) Default Path Venus\Base
(360: 10.76s 431us)(0xE2C) Scanning bases from Config\Venus\Base
(361: 10.76s 462us)(0xE2C) Parsing a planet Config\Earth.cfg
(362: 10.76s 496us)(0xE2C) Default Path Earth\Base
(363: 10.76s 549us)(0xE2C) Scanning bases from Config\Earth\Base
(364: 10.76s 597us)(0xE2C) Parsing a base Config\Earth\Base\Alcantara.cfg
(365: 10.76s 652us)(0xE2C) Parsing a base Config\Earth\Base\Al_Anbar.cfg
(366: 10.76s 701us)(0xE2C) Parsing a base Config\Earth\Base\Ascension.cfg
....

 

[jedidia]

It appears that Orulex crashes the D3D9 client. Can anyone else confirm this?

Now that is hardly surprising...

 

[Tschachim]

No, I haven't touched that code section since RC45. Atleast not intentionally. It's a problem in the file parser section. It's better to find a reason for that because the problem may appear with many other add-ons as well.

Could you post the log from the file parser section. It might help a bit.

Yes, it happens with Quickstart Mode scenarios only, Virtual AGC scenarios work fine, so I don't know since when this happens. Both use different Sols/Earths/Canaverals, I'll check the log and investigate...

EDIT: Found it, NASSP still used the old base file system (bases in the planet file instead of base dirs), with the new system the crash went away. I'll fix that on my side.

 

[jarmonik]

New version for testing

Here is a new version for testing.

- Symbolic link issue should be fixed
- Shuttle Fleet animation issue should be fixed and DGIV should be still working.
- Configuration file parser improved. Let's hope it works.
- Moon rendering should be fixed.
- New folder added for Shader Model 2.0 specific files.

Could you confirm that the issues are fixed or if any new one has appeared. I also noticed that a link to the client has been added to the Orbiter Website.

EDIT: I may need to change the PAPI configuration so that a scenarios are more compatible with inline engine and D3D9Client. Current setup is causing some problems.

 

[Enjo]

So far, the open source environment haven't proven very beneficial for the project, it allows the code to be ripped off but there is nothing to be ripped back so it works only in one way and not much motivation can be found from there.

You never know when somebody ambitious joins your project. When it happens, you won't regret it.

 

[Face]

Not everything has gone according to the plan but since we made-it this far I hope we get through the rest. It was somewhat my intention to convert the D3D9Client to use the DX11, after completing the R1, for more advanced features. But since it's already converted by a group of people, that plan is no longer so obvious. I don't know how many D3D11Clients there are in the making so I am going to wait and see since there are no rush.

I can't speak for Asmi and Glider, but from my point of view there is only one D3D11Client. It might come in different versions (O2010P1, Beta, Terrain), but the code base is the same.

As for conversion of D3D9Client to D3D11Client: that never really happened. I might have started from there, but before I even reached a functioning point in development, Asmi and Glider came in and took the lead with an independent code base. My work has stopped completely.

So as you see, your original plan (conversion of D3D9 code base to D3D11) is still open. Nobody said that the folks working on D3D11Client are the be-all-end-all to that. You can still do the conversion and compare results. In the process of doing so, you could even take solutions from the current D3D11Client code base. THAT'S the point of open source.

I don't know how this project is going to continue since my inspiration and motivation to work with this project is somewhat low at a moment. So far, the open source environment haven't proven very beneficial for the project, it allows the code to be ripped off but there is nothing to be ripped back so it works only in one way and not much motivation can be found from there.

One possible way to continue is to go to a closed source renderer which would include some core functions like a mesh class since it would need to be re-written anyway. A better implementation would allow a three times higher frame-rates in an environments those are including complex (i.e. large) meshes with a better shading techniques. Most of the client would still remain open.

In open source environments, "ripping off" is the normal operation. I'd use terms like "taking solutions" instead, though. It is not so much about suddenly having workers that code away on a centralized code base. It is more that nobody stops you from taking solutions from projects that took solutions from your project previously. Free as in speech, so to say.

I think your idea of a closed source renderer is not an option. OVP is GPL'ed, and as such you can't create derived work without putting it itself under GPL. I am not a lawyer, though.

D3D9Client web site is located here http://koti.mbnet.fi/jarmonik/D3D9Client/
It's pretty primitive but it should do the job.

Nice and clean layout, perfect for the job.

Great work, Jarmo!

 

[Ripley]

Here is a new version for testing...
- Shuttle Fleet animation issue should be fixed and DGIV should be still working...

I'm going to make some DGIV tests as time permits (I'm at work, shhhh).
But to avoid confusion: when you say DGIV you mean the good ol' DGIV-2, don't you?

I'm in the beta test group of the the new, D3D9 compliant, DGIV-3 (not released yet), and that is the DG I'm going to test.

The old DGIV-2 shouldn't be working at all with your client...or did I miss/forget something?

 

[asmi]

I think your idea of a closed source renderer is not an option. OVP is GPL'ed, and as such you can't create derived work without putting it itself under GPL. I am not a lawyer, though.

Just want to comment on this thing. GPL specifically permits non-GPL extensions for GPL products, and so is Martin - I remember he specifically mentioned somewhere that extensions can have whatever license developers want - they can even be commercial. There are tons of non-GPL addins out there (OrbiterSound, DGIV, XR to name a few).

---------- Post added at 09:19 ---------- Previous post was at 07:28 ----------

I can't speak for Asmi and Glider, but from my point of view there is only one D3D11Client. It might come in different versions (O2010P1, Beta, Terrain), but the code base is the same.

As for conversion of D3D9Client to D3D11Client: that never really happened. I might have started from there, but before I even reached a functioning point in development, Asmi and Glider came in and took the lead with an independent code base. My work has stopped completely.

So as you see, your original plan (conversion of D3D9 code base to D3D11) is still open. Nobody said that the folks working on D3D11Client are the be-all-end-all to that. You can still do the conversion and compare results. In the process of doing so, you could even take solutions from the current D3D11Client code base. THAT'S the point of open source.

And I also would like to say a few words on this. This "conversion" is how the D3D11 project has started. But once I've started introducing more advanced effects, I realized that this is not a best way. The reason is pretty simple - DX10/11 is different from DX9 in many ways, and so approaches that are good for DX9 are not neccessary good for DX10/11. Of course if your goal is to simply port DX9 app to DX11 - that will work, but the whole point of using DX11 in my mind is to introduce advanced effects and more detailed graphics so the visual experience will be immersive.
Now as DX11 development progressed, I've realized that the whole approach have to be changed in order to keep good FPS while introducing more visual FXs. One example is "classic" (or forward) lighting vs deferred with light pre-pass. Forward lighting is good as long as lighting models are relatively simple (Phong, Blinn-Phong models) AND amount of lights on the scene is low, but the major downside is overdraw - the fact that pixel that have rendered for object 1 can be overwritten by object 2 that happened to be closer to the camera, so the first work is wasted. While the workload is low this is acceptable, but as shader complexity rises, there losses become a serious performance concern. Also forward lighting computes only direct illumination (light coming directly from light source) and there is no easy way to add indirect illumination (light that bounces from other surfaces and then lights up the pixel). Indirect lighting in forward renderer is very coarsely simulated using uniform "ambient" light. And here is another problem - the rationale for ambient light is that it approximates light scattered by the medium. But in space there is NO medium, so ambient lighting is inadequate.
So the farther we are going into DX11 development, the more obvious it becomes that we need to change renderer from forward to deferred. But the problem is that these renderers are fundamentally different, so this move will essentially be a serious change if not a complete rewrite. I've spent months trying to brainstorm a way to make that change without complete rewrite but failed to come up with a solution. I'm still thinking it through and once I'll figure this out I'll go ahead and implement that.

So with all of that said, I don't think simple port to DX11 is a good idea, but of course one is welcomed to try - maybe I'm just missing something important and/or simply not smart enough to figure it out, but the fact that vast majority of modern engines are using deferred lighting sort of gives me confidence that my conclusions are right...

 

[SolarLiner]

I'm going to make some DGIV tests as time permits (I'm at work, shhhh).
But to avoid confusion: when you say DGIV you mean the good ol' DGIV-2, don't you?

I'm in the beta test group of the the new, D3D9 compliant, DGIV-3 (not released yet), and that is the DG I'm going to test.

The old DGIV-2 shouldn't be working at all with your client...or did I miss/forget something?

Old DGIV-2 isn't working, because of a function that doesn't work with orbiter_ng.exe and returns a "null" ... That makes Orbiter NG CTD. But, and that is the good point, Dan has the new DGIV-3 in beta ... And he will release it with the "patches" of all his other add-on ...

 

[Enjo]

I think your idea of a closed source renderer is not an option. OVP is GPL'ed, and as such you can't create derived work without putting it itself under GPL. I am not a lawyer, though.

That's true. Any form of linking with GPL code or directly copying code from it must end up in an GPLed product. Only LGPL doesn't enforce this but only when linking dynamically.

Just want to comment on this thing. GPL specifically permits non-GPL extensions for GPL products, and so is Martin.

Martin may permit it, but I wouldn't be so sure about the GPL itself. Even if somebody permits me something, he may change his mind later. Having clear rules helps.

 

[asmi]

Martin may permit it, but I wouldn't be so sure about the GPL itself. Even if somebody permits me something, he may change his mind later. Having clear rules helps.

Please check that: http://orbit.medphys.ucl.ac.uk/faq.html

Note that third-party Orbiter addons may be distributed under different license terms

De-jure this can be interpreted as different license, so GPL rules no longer apply. And GC doesn't have to contain any part of OVP code (actually my client that I've started to develop before I've joined D3D11Client project was totally free of OVP code). So technically it COULD be done. However in practice if I'd start doing something like that I would contact Martin and ask him for an explicit permission. I don't see any reasons Martin would be against it, since, well, as I've said, there are a lot of non-GPL closed-source addons, and everyone (apparently Martin included) seems to be perfectly fine with that.

 

[Enjo]

I don't see any reasons Martin would be against it, since, well, as I've said, there are a lot of non-GPL closed-source addons, and everyone (apparently Martin included) seems to be perfectly fine with that.

That's true, but Orbiter.lib is not GPL, but a custom license.

And GC doesn't have to contain any part of OVP code (...). So technically it COULD be done.

That's a different thing then.

 

[jarmonik]

I think your idea of a closed source renderer is not an option. OVP is GPL'ed, and as such you can't create derived work without putting it itself under GPL. I am not a lawyer, though.

The first part is false and the second part is true. Any code that's been published under a GPL lisence can not be closed. However, the GPL lisence applies only in a forward direction. For an example if I take a code section from a book and I publish some code using it under a GPL, the book doesn't need to be published under a GPL because that would be backwards direction. If it would work like that, then the GPL it-self might be illegal.

It is true that if some functionalities of a client is provided by a closed code then code can't be derived from the client it-self but it can be still derived from many other sources. Of course, one possibility is to write it from scratch.

I have no intention to violate any lisences and I have no need to. If the things would become that difficult then I would quit the project and do something else.

---------- Post added at 22:17 ---------- Previous post was at 21:55 ----------

Now as DX11 development progressed, I've realized that the whole approach have to be changed in order to keep good FPS while introducing more visual FXs. One example is "classic" (or forward) lighting vs deferred with light pre-pass. Forward lighting is good as long as lighting models are relatively simple (Phong, Blinn-Phong models) AND amount of lights on the scene is low, but the major downside is overdraw - the fact that pixel that have rendered for object 1 can be overwritten by object 2 that happened to be closer to the camera, so the first work is wasted. While the workload is low this is acceptable, but as shader complexity rises, there losses become a serious performance concern. Also forward lighting computes only direct illumination (light coming directly from light source) and there is no easy way to add indirect illumination (light that bounces from other surfaces and then lights up the pixel). Indirect lighting in forward renderer is very coarsely simulated using uniform "ambient" light. And here is another problem - the rationale for ambient light is that it approximates light scattered by the medium. But in space there is NO medium, so ambient lighting is inadequate.
So the farther we are going into DX11 development, the more obvious it becomes that we need to change renderer from forward to deferred. But the problem is that these renderers are fundamentally different, so this move will essentially be a serious change if not a complete rewrite. I've spent months trying to brainstorm a way to make that change without complete rewrite but failed to come up with a solution. I'm still thinking it through and once I'll figure this out I'll go ahead and implement that.

I am very well aware of that. I got quite many books about advanced GPU computing in my bookshelf. There do exists very fantastics shading techniques but what does fit for a user who's running the orbiter with a medium priced laptop computer. Also noting that the user is interested about a spaceflight and not so much of a scenery.

Ambient light distribution can be pre-computed in some cases, no need to compute for every frame so it is ok.

Currently, I'm not planing to make a DX11 port of the DX9 client.

 

[asmi]

Also noting that the user is interested about a spaceflight and not so much of a scenery.

One doesn't preclude another. I'm interested in spaceflight, yet I'd prefer to have a realistically looking image of the background. And since medium-ranged systems are very well covered by your client, I'm focused on latest and greatest