New Release D3D9Client Development

[Face]

I see we have different opinions regarding the work mode of the OVP license. To clarify, mine is like so:

1. The OVP project itself - including the interface stubs to orbiter_ng - is under GPL V2+ (+ meaning V3 is also permitted). This is different to the core Orbiter project that is using Martin's proprietary license.
2. D3D9Client is part of this project, at least since the first "official" SVN revision. It is also not a "normal" add-on like OrbiterSound or one of the DG/XR vessels.
3. GPL does not allow closed source to link to GPL binaries, this even includes dynamic linking. Well, actually it just talks about derived work, but the FSF showed often enough that dynamic linking is still "derived" enough for them. A rule of thumb is: if your program is nothing without that GPL'ed lib you link to, you are violating the GPL if making it closed source. If you don't believe me, google "loadable kernel modules GPL" - strong opinions ahead!

With this points at hand, I think it is not OK to create a single graphics client DLL for D3D9Client that is closed source.


It might be OK to create a kind of "glue-DLL" that gets loaded by Orbiter and implements all the callbacks and function callers to be forwarded to a white-room implementation of a renderer DLL, since you can hardly argue that the interface itself is under GPL. I just don't see a point in such an undertaking, though. The purpose of this could only be to circumvent the GPL's requirement of making the code publicly visible. And I see no reason for that, especially with volunteer work.


A different thing is of course USING a closed source rendering engine (DX itself is such a thing IMHO)! But you would have to code a whole bunch of glue for that, anyway (and TBH, D3DxClients are nothing but glue code to the DX interfaces).


But as said in the beginning: this is only my opinion. In the end it is Martin's call, as he still is the OVP project leader AFAIK.


regards,
Face

 

[Cras]

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

I fall into this catagory. I am greedy. I want the best of both worlds. I want the sim to behave as if I am flying in space as realistically as possible, and at the same time look as realistic as possible.

 

[jarmonik]

I see we have different opinions regarding the work mode of the OVP license. To clarify, mine is like so:

1. The OVP project itself - including the interface stubs to orbiter_ng - is under GPL V2+ (+ meaning V3 is also permitted). This is different to the core Orbiter project that is using Martin's proprietary license.
2. D3D9Client is part of this project, at least since the first "official" SVN revision. It is also not a "normal" add-on like OrbiterSound or one of the DG/XR vessels.
3. GPL does not allow closed source to link to GPL binaries, this even includes dynamic linking. Well, actually it just talks about derived work, but the FSF showed often enough that dynamic linking is still "derived" enough for them. A rule of thumb is: if your program is nothing without that GPL'ed lib you link to, you are violating the GPL if making it closed source. If you don't believe me, google "loadable kernel modules GPL" - strong opinions ahead!

With this points at hand, I think it is not OK to create a single graphics client DLL for D3D9Client that is closed source.

Yes, I belive that's true and I have no intention to close the client. Just to provide an utility functions in a closed library. We have a good examples about this. One is the d3dx9_42.dll, do you think that it's violating the GPL ? No, I don't think so. Then does d3d9.dll violate GPL ? D3D9Client is using these closed libraries and without them the client would be nothing. Then why would an other utility library comparable to d3dx9_42.dll violate the lisence ? GPL based D3D9Client would link into the library not vice versa. The library would be independend from the orbiter and from the D3D9Client as is the d3dx9_42.dll

---------- Post added at 01:19 ---------- Previous post was at 00:57 ----------

A different thing is of course USING a closed source rendering engine (DX itself is such a thing IMHO)! But you would have to code a whole bunch of glue for that, anyway (and TBH, D3DxClients are nothing but glue code to the DX interfaces).

Oh, yes, there you go. Well, just a small extension for those libraries.

 

[Face]

Yes, I belive that's true and I have no intention to close the client. Just to provide an utility functions in a closed library. We have a good examples about this. One is the d3dx9_42.dll, do you think that it's violating the GPL ? No, I don't think so. Then does d3d9.dll violate GPL ? D3D9Client is using these closed libraries and without them the client would be nothing. Then why would an other utility library comparable to d3dx9_42.dll violate the lisence ? GPL based D3D9Client would link into the library not vice versa. It would be independend from the orbiter and from the D3D9Client.

Correct. The DX interfaces are closed source libraries that are used by the "glue" graphics client.

So as long as the D3D9Client.dll itself stays open, I do not see a problem.

But again: this is only my opinion. Depending on the way the utility functions are interfaced, it may spark discussion again. Or not. And it may be completely irrelevant if they do, because there might be no legal activity involved, anyway. I'm just saying how I see things here.

With this I'd like to end the discussion here, as I feel like it has potential to invoke debates that are certainly off-topic to this thread. If you want to continue this - or any other topics privately - please let me know, so we can head over to IRC or PM or whatever you like.

regards,
Face

 

[asmi]

I see we have different opinions regarding the work mode of the OVP license. To clarify, mine is like so:

1. The OVP project itself - including the interface stubs to orbiter_ng - is under GPL V2+ (+ meaning V3 is also permitted). This is different to the core Orbiter project that is using Martin's proprietary license.

Now this statement is not completely true. There are no "interface stubs to orbiter_ng". There is class oapi::GraphicsClient, that is part of standard Orbiter SDK, and this SDK is everything you ever need to build a graphics client - there is no "special" SDK for GC development. Technically GC is simply a special case of orbiter's module - same as vessels, planets, atmospherical models, etc. Since neither SDK nor Orbiter are GPL'ed, GC implementation doesn't need to be GPL'ed either.

 

[jarmonik]

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 haven't given much thought for that before but unfortunately you are right. Ideas and solutions are much more valuable than a code. Almost anyone can write a code but creating a solution for some specific problem can be a lot harder. The GPL doesn't apply in ideas or solutions only to the code. That, somehow, makes me feel that the GPL is a complete garbage.

 

[BruceJohnJennerLawso]

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 ----------



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

Hate to rain on the parade, but I dont see much use in freeing that extra 20-40 FPS if I cant use Orulex. To me, terrain generation & landing should be the next item on the agenda in terms of orbiter development, as the major hole remaining in Orbiters ability to simulate spaceflight. A better looking, faster graphics client is nice, but it doesnt really contribute to making flying in orbiter an accurate sim of the real challenges in flying in space. Case in point-Armstrong took manual control on the first lunar landing to avoid landing on a rocky area. Can orbiter simulate that?

 

[Cras]

go to D3D11 client. It has terrain. Very good terrain too.

 

[BruceJohnJennerLawso]

go to D3D11 client. It has terrain. Very good terrain too.

Thankyou, will there be landing support for it?

 

[jarmonik]

To me, terrain generation & landing should be the next item on the agenda in terms of orbiter development, as the major hole remaining in Orbiters ability to simulate spaceflight.

I have never tried Orulex so I don't know much about it. But the D3D9Client will have a proper terrain in the future, not necessarely similar to DX11 but a terrrain anyway. Better or worse I don't know. I'll try to proceed consistently in the client development. I don't jump into a step 576 while we are in a step 204. There are may issues conserning the 3D terrain.

- First of all there are no collision support in the orbiter it self. I would prefer to have a terrain with a proper collisions.
- 3D terrain has a high risk to break every existing base add-on until a few problems related to them are solved.
- There are problems with a large scale data distribution. Therefore I would prefer a solution that would allow a high quality terrain with a small amount of data. We need an advanced data packing algorithm.

Of course, the client could rip-off the solution from some other project that has already implemented that feature but that would not be the best for a long run. Don't forget that OGLA Client already had a 3D terrain about a three years ago and it don't seem to mean anything.

 

[BruceJohnJennerLawso]

I have never tried Orulex so I don't know much about it. But the D3D9Client will have a proper terrain in the future, not necessarely similar to DX11 but a terrrain anyway. Better or worse I don't know. I'll try to proceed consistently in the client development. I don't jump into a step 576 while we are in a step 204. There are may issues conserning the 3D terrain.

- First of all there are no collision support in the orbiter it self. I would prefer to have a terrain with a proper collisions.
- 3D terrain has a high risk to break every existing base add-on until a few problems related to them are solved.
- There are problems with a large scale data distribution. Therefore I would prefer a solution that would allow a high quality terrain with a small amount of data. We need an advanced data packing algorithm.

Of course, the client could rip-off the solution from some other project that has already implemented that feature but that would not be the best for a long run. Don't forget that OGLA Client already had a 3D terrain about a three years ago and it don't seem to mean anything.

I really do think hardcoded 3d terrain does need to be the focus for future development, but I do understand the issues behind data size (100 megs for orulex heightmaps. It just seems to me that orbiter is good, but falling behind where it should be in that area, while the graphics development is approaching a bottleneck in just how far it can go. Thankyou for being understanding, my original post was a little rude

 

[jarmonik]

- First of all there are no collision support in the orbiter it self. I would prefer to have a terrain with a proper collisions.
- 3D terrain has a high risk to break every existing base add-on until a few problems related to them are solved.
- There are problems with a large scale data distribution. Therefore I would prefer a solution that would allow a high quality terrain with a small amount of data. We need an advanced data packing algorithm.

Just to add in my previous post that there are in a magnitude of 3-4 different kind of techniques/methods those could be used to make a high quality terrain but which one fits best for the Orbiter is somewhat unclear. I'll consider different options before making decisions.

I'll tried to find a hires textures for the Mars to view the Gale creater add-on with it's full magnitude but I wasn't able to find any. Most of the orbiter download sites seems to be no-longer in order. So, if a bad implementation is taking GB:s of data then who's going to host the files ?

 

[kuddel]

Hi jarmonik,

first of all, thanks for the new updates!
I have been on a hiking holiday in the alps and could not follow the last development steps in real time, so I have to catch up a bit

I have here on my local working copy several changes that should be merged into the "main" development branch (trunk?!).
- Store and restore of the "bodyforce" and "axes" config parameters (Orbiter_NG.cfg).
- Some documentation updates (doxygen file to create API-Docs, D3D9Client.chm, like in D3D7 client).
- An optimized OapiExtension class, using less CPU cycles.
- OapiExtension including scale- and opacity-gauge readout and store.
- Some minor code-cleanups (like exchange of D3D7 names into D3D9).

So my question here is: Should I try to merge it into the R1b version or better based on the "official" R1?
Or do you have a (SVN-)repository link that you could provide, so I can merge it there once I have write access?

You can also PM me anytime, for further questions/answeres or we can comunicate via e-mail directly if you prefer.

Cheers, thanks and :tiphat:
Kuddel

 

[jarmonik]

I have been on a hiking holiday in the alps and could not follow the last development steps in real time, so I have to catch up a bit

It's great to hear. I hope it was a nice holiday.

No, I don't have SVN. So, here are the latest sources if you want to merge the code, I won't be making any changes during the next few days. After that we can launch the R2 unless someone finds a bug.

 

[BruceJohnJennerLawso]

Just to add in my previous post that there are in a magnitude of 3-4 different kind of techniques/methods those could be used to make a high quality terrain but which one fits best for the Orbiter is somewhat unclear. I'll consider different options before making decisions.

I'll tried to find a hires textures for the Mars to view the Gale creater add-on with it's full magnitude but I wasn't able to find any. Most of the orbiter download sites seems to be no-longer in order. So, if a bad implementation is taking GB:s of data then who's going to host the files ?

Out of interest, would you be able to describe our possible options for the terrain system? Im curious as to the ins and outs, pros and cons of each option.

With regards to the download issues, I know what youre getting at. Sourceforge would object to the size and the purpose, and Orbithangar would probably be an issue as well, but I think there are ways that we could compress terrain data into manageable packages. I dont claim to understand the particulars of it, but the original Orulex distribution used fractal equations to create terrain details where heightmaps werent available, and could create a crater at any given coordinates. With some work, a future terrain system could simply read a list of identifiers,like crater, ridge, hill, mountain, etc plot them to lon/lat coordinates, all without ever needing a heightmap. Think that could work?

 

[kuddel]

It's great to hear. I hope it was a nice holiday.

Yes it was!

No, I don't have SVN. So, here are the latest sources if you want to merge the code, I won't be making any changes during the next few days. After that we can launch the R2 unless someone finds a bug.

O.K. attached you will find the complete package based on your last attachment.
Here's the changelist:

• Integrated new OapiExtension class.
• Added opacity and scale to rendering of axes/force-vectors.
• Fixed array size (VideoTab.cpp)
• Updated README.txt (removed D3D7 references)
• Added "DisableVisualHelperReadout" config switch to disable all 'hooking' functionality (debug feature to measure CPU impact)
• Generated D3D9Client.chm
• Took the liberty to increase the "version number" to R1d
• Removed .suo file (not a source file)
• Added Project files for Visual Studio 2010 (D3D9ClientVS2010)

This ZIP does not contain the DLL itself, cause I don't have the NVIDIA API installed and therefore are not able to create a "3D-able" Module.
Apart from that, it should be complete

Kuddel

 

[jarmonik]

This ZIP does not contain the DLL itself, cause I don't have the NVIDIA API installed and therefore are not able to create a "3D-able" Module.
Apart from that, it should be complete

Thanks about the new modifications. It seems to be working pretty well, I'll try to improve the scaling and I'll should be able to release R2 in a two or three days. I just got a pretty long PM and the next 6 hours goes in replying it, so, no code writing today.

BTW, Even if you don't have the nVidia API you should be able to compile without errors.

Also, thanks about the docs. I don't have doxygen right now. I lost an other harddrive during the summer and new drives are pretty much empty.

 

[Enjo]

Also, thanks about the docs. I don't have doxygen right now. I lost an other harddrive during the summer and new drives are pretty much empty.

Cygwin should get you going in no time.

 

[DaveS]

I hope this isn't off-topic or anything but how hard would it be to implement vessel self-shadowing? So far only Artlav's OGLAClient has implemented that.

 

[asmi]

I hope this isn't off-topic or anything but how hard would it be to implement vessel self-shadowing? So far only Artlav's OGLAClient has implemented that.

I have this in plans for both terrain and vessels. The problem for me is more complicated though as we've got local lights that needs to be taken into account.