- Joined
- Apr 14, 2012
- Messages
- 2,585
- Reaction score
- 0
- Points
- 36
It appears that Orulex crashes the D3D9 client. Can anyone else confirm this?
It appears that Orulex crashes the D3D9 client. Can anyone else confirm this?
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:
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)
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
It appears that Orulex crashes the D3D9 client. Can anyone else confirm this?
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.
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.
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 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.
D3D9Client web site is located here http://koti.mbnet.fi/jarmonik/D3D9Client/
It's pretty primitive but it should do the job.
I'm going to make some DGIV tests as time permits (I'm at work, shhhh).Here is a new version for testing...
- Shuttle Fleet animation issue should be fixed and DGIV should be still working...
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.
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.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'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?
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.
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 said:Just want to comment on this thing. GPL specifically permits non-GPL extensions for GPL products, and so is Martin.
Please check that: http://orbit.medphys.ucl.ac.uk/faq.htmlMartin 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.
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.Note that third-party Orbiter addons may be distributed under different license terms
That's true, but Orbiter.lib is not GPL, but a custom license.asmi said: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 a different thing then.asmi said:And GC doesn't have to contain any part of OVP code (...). So technically it COULD be done.
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.
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.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.
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 greatestAlso noting that the user is interested about a spaceflight and not so much of a scenery.