Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter Visualization Project
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Orbiter Visualization Project Orbiter external graphics development.

Reply
 
Thread Tools
Old 08-24-2012, 04:57 AM   #1531
Enjo
Mostly harmless
 
Enjo's Avatar


Default

Quote:
Originally Posted by jarmonik View Post
 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.
Enjo is offline   Reply With Quote
Old 08-24-2012, 07:04 AM   #1532
Face
Beta Tester
 
Face's Avatar

Default

Quote:
Originally Posted by jarmonik View Post
 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.

Quote:
Originally Posted by jarmonik View Post
 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.

Quote:
Originally Posted by jarmonik View Post
 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!
Face is offline   Reply With Quote
Old 08-24-2012, 10:03 AM   #1533
Ripley
Tutorial translator
 
Ripley's Avatar
Default

Quote:
Originally Posted by jarmonik View Post
 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?
Ripley is offline   Reply With Quote
Old 08-24-2012, 01:19 PM   #1534
asmi
Addon Developer
Default

Quote:
Originally Posted by Face View Post
 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 ----------

Quote:
Originally Posted by Face View Post
 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...

Last edited by asmi; 08-24-2012 at 03:05 PM.
asmi is offline   Reply With Quote
Thanked by:
Old 08-24-2012, 01:28 PM   #1535
SolarLiner
It's necessary, TARS.
 
SolarLiner's Avatar
Default

Quote:
Originally Posted by Ripley View Post
 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 ...
SolarLiner is offline   Reply With Quote
Old 08-24-2012, 04:44 PM   #1536
Enjo
Mostly harmless
 
Enjo's Avatar


Default

Quote:
Originally Posted by Face View Post
 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.

Quote:
Originally Posted by asmi
 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.

Last edited by Enjo; 08-24-2012 at 04:48 PM.
Enjo is offline   Reply With Quote
Old 08-24-2012, 05:04 PM   #1537
asmi
Addon Developer
Default

Quote:
Originally Posted by Enjo View Post
 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
Quote:
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.
asmi is offline   Reply With Quote
Old 08-24-2012, 06:21 PM   #1538
Enjo
Mostly harmless
 
Enjo's Avatar


Default

Quote:
Originally Posted by asmi
 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.

Quote:
Originally Posted by asmi
 And GC doesn't have to contain any part of OVP code (...). So technically it COULD be done.
That's a different thing then.
Enjo is offline   Reply With Quote
Old 08-24-2012, 07:17 PM   #1539
jarmonik
Beta Tester

Default

Quote:
Originally Posted by Face View Post
 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 ----------

Quote:
Originally Posted by asmi View Post
 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.

Last edited by jarmonik; 08-24-2012 at 07:21 PM. Reason: Someone made typos in my writing
jarmonik is offline   Reply With Quote
Thanked by:
Old 08-24-2012, 07:23 PM   #1540
asmi
Addon Developer
Default

Quote:
Originally Posted by jarmonik View Post
 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
asmi is offline   Reply With Quote
Old 08-24-2012, 08:58 PM   #1541
Face
Beta Tester
 
Face's Avatar

Default

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
Face is offline   Reply With Quote
Thanked by:
Old 08-24-2012, 09:44 PM   #1542
Cras
Spring of Life!
 
Cras's Avatar
Default

Quote:
Originally Posted by asmi View Post
 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.
Cras is offline   Reply With Quote
Thanked by:
Old 08-24-2012, 10:19 PM   #1543
jarmonik
Beta Tester

Default

Quote:
Originally Posted by Face View Post
 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 ----------

Quote:
Originally Posted by Face View Post
 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.

Last edited by jarmonik; 08-24-2012 at 10:12 PM.
jarmonik is offline   Reply With Quote
Thanked by:
Old 08-24-2012, 10:28 PM   #1544
Face
Beta Tester
 
Face's Avatar

Default

Quote:
Originally Posted by jarmonik View Post
 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
Face is offline   Reply With Quote
Thanked by:
Old 08-25-2012, 01:04 AM   #1545
asmi
Addon Developer
Default

Quote:
Originally Posted by Face View Post
 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.
asmi is offline   Reply With Quote
Thanked by:
Reply

  Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter Visualization Project

Tags
d3d9client, graphicsclient


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 09:55 PM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.