Project D3D11Client Development

[dumbo2007]

there is a new orbiter patch coming out ?

 

[orb]

Will the new orbiter patch include the client as an option?

Neither of external graphics clients is included in Orbiter distribution package. Even the D3D7Client maintained by martins is an additional download. But there is always an option included to use graphics clients when a new patch for Orbiter is released - either already released versions, if graphics server's interface didn't change, or new versions recompiled against updated OrbiterSDK, if the interface has changed.

there is a new orbiter patch coming out ?

Yes... Of course on Tuesday.

 

[N757QQ]

Do all of the regular mods, such as those in the 'recommended mods' post from the tutorial & challenge section (I think) work as normal with this new graphics engine?

I was working, but crashed after installed the DGIV2, and stopped there.

I will save posting crash logs if it is known not to work, otherwise it is on my end & I will go from there.

I did search with no real results, other than finding that I think the xr series works

Thanks,

N

 

[Cras]

Do all of the regular mods, such as those in the 'recommended mods' post from the tutorial & challenge section (I think) work as normal with this new graphics engine?

I was working, but crashed after installed the DGIV2, and stopped there.

I will save posting crash logs if it is known not to work, otherwise it is on my end & I will go from there.

I did search with no real results, other than finding that I think the xr series works

Thanks,

N

Most things do work. And the version of the DGIV that is available at the moment is not compatible with any graphics clients, but a new version is on the way, and it is very much compatible with D3D11 and D3D9 clients.

 

[N757QQ]

Thank you Cras, and for a quick reply as well.

N

 

[dumbo2007]

actually two engines - one is based on Compute Shaders, and another one is based on Pixel Shaders

Woudnt it be easier for you if you just added an option to the configuration dialog in launchpad, instead of maintaining and releasing 2 versions ?

Same for any gfx card specific stuff.

 

[asmi]

Woudnt it b easier for you if you just addded an option to the configuration dialog in launchpad, instead of maintaining and releasing 2 versions ?

Same for any gfx card specific stuff.

That's exactly what I'm going to do I've gotta maintain both renderers though

 

[dumbo2007]

Is it possible to have global illumination in real time (GI). I was looking at this video :

I am not sure but maybe the earthshine is actually an extension of global illumination where you get this soft light bouncing off nearby objects and it looks awesome

http://msdn.microsoft.com/en-us/library/windows/desktop/bb174150(v=vs.85).aspx

 

[asmi]

Is it possible to have global illumination in real time (GI). I was looking at this video :

Radeon HD 2900 Global Illumination - YouTube

I am not sure but maybe the earthshine is actually an extension of global illumination where you get this soft light bouncing off nearby objects and it looks awesome

http://msdn.microsoft.com/en-us/library/windows/desktop/bb174150(v=vs.85).aspx

Does the word "precomputed" ring any bell?

 

[dumbo2007]

oh, so all the lighting is precomputed and not at runtime ?

Also I wonder how much work would be involved in supporting the orbiter graphics client functions in the cry 3 engine.

http://www.crydev.net/

Since a lot of the features are already there, perhaps its just a matter of translating the orbiter commands to the correct API calls in the cry3 sdk (its free by the way )
Though I guess rendering planets will be tough. Is there any fundamental restriction in integrating a proffessional grade graphics engine with orbiter ng, such as with respect to the way
Orbiter loads a client dll etc.

I am beginning to look at the features of cryengine and it looks totally cool : http://mycryengine.com/index.php?conid=2
[ame="http://en.wikipedia.org/wiki/CryEngine"]CryEngine - Wikipedia, the free encyclopedia[/ame]

Also since it has physics support so I do not need to integrate with Bullet and add yet another library to the process. There is also the support for game levels which may make it easier to support large bases without me having to hack together an adjacency graph or bsp trees from scratch.

 

[asmi]

oh, so all the lighting is precomputed and not at runtime ?

Also I wonder how much work would be involved in supporting the orbiter graphics client functions in the cry 3 engine.

http://www.crydev.net/

Since a lot of the features are already there, perhaps its just a matter of translating the orbiter commands to the correct API calls in the cry3 sdk (its free by the way )
Though I guess rendering planets will be tough. Is there any fundamental restriction in integrating a proffessional grade graphics engine with orbiter ng, such as with respect to the way
Orbiter loads a client dll etc.

Everything can be done, the questions always are - who, how long, how much.

Also:

Notes on 32-bit Support

The SDK contains a 32-bit version of Sandbox but we highly recommend to use the 64-bit version for production since it does not suffer from memory limitations. The 32-bit version is just provided as-is without any further support by Crytek. Using the 32-bit version of Sandbox might result in the application crashing when doing a lot of editing work on a level.

In short - forget it.

 

[dumbo2007]

hehe.....so orbiter is curently compiled for 32 bits , is that why the issue ?

Surely it can be compiled for 64 bits if and when levels do become big. I think they are talking about the editor here. I will be accessing the engine through the APIs anyway and of course I wont load all levels in 1 go

 

[Cras]

hehe.....so orbiter is curently compiled for 32 bits , is that why the issue ?

Surely it can be compiled for 64 bits if and when levels do become big. I think they are talking about the editor here. I will be accessing the engine through the APIs anyway and of course I wont load all levels in 1 go

It probably should be 64 bit, but there are those who dont have 64 bit processors, and they would be forever cut from Orbiter until they upgrade to a modern machine. Same as to why the default client is D3D7, more fun for everyone this way.

 

[asmi]

It probably should be 64 bit, but there are those who dont have 64 bit processors, and they would be forever cut from Orbiter until they upgrade to a modern machine. Same as to why the default client is D3D7, more fun for everyone this way.

We can't make it 64bit, since we don't have access to Orbiter source code. And even if we would manage to convince Martin to do that, ALL third-party addons and plugins will stop working, not to mention those few brave who will recompile (and fix) their plugins for 64bit client, will be cursed forever with having to support two binaries at the same time.

Right now in D3D11Client we actually do have issues with that, as all resources doesn't fit within 2Gb address space we've got, which forces us to come up with some nontrivial solutions regarding paging-in and paging-out them dynamically. Right now with introduction of heightmaps the problem has become so apparent that I can't even complete reentry from LEO without memory bleeding out, so it's one more issue on our plate before we can release anything...

 

[dumbo2007]

Hmm...I wonder why we cant have a 32 bit and a 64 bit build of orbiter and the sdk at the same time put up on the site. It should be a simple recompile I guess.

The 64 bit build would have a limited set of addons working for it for sure, but it would enable testing of more stuff for developers for the future too.


With ram being so cheap these days, I do hope a 64 bit build is available for those of us wanting to add more to Orbiter.

 

[N_Molson]

Mhh... Would an engine designed for a FPS be able to render smoothly when you fly over landscape at Mach 3 or more ? :idk:

 

[dumbo2007]

Would depend on how rich the landscape is and level of detailing. But I think there are cases of using the cry engine for such cases too :

 

[asmi]

Would depend on how rich the landscape is and level of detailing. But I think there are cases of using the cry engine for such cases too : Flyable Spitfire for Crysis - YouTube

OK guys, I think this conversation goes too far off topic here. I don't quite understand the purpose of this discussion in this topic - are you suggesting to start it all over with CryEngine? It still is off-topic since CryEngine3 does not support DX11, so in this sence our current engine is more advanced.

So let's stick to D3D11Client here, and if you want to discuss other possible engines - start another topic and let's talk there.

 

[Cras]

We can't make it 64bit, since we don't have access to Orbiter source code. And even if we would manage to convince Martin to do that, ALL third-party addons and plugins will stop working, not to mention those few brave who will recompile (and fix) their plugins for 64bit client, will be cursed forever with having to support two binaries at the same time.

Right now in D3D11Client we actually do have issues with that, as all resources doesn't fit within 2Gb address space we've got, which forces us to come up with some nontrivial solutions regarding paging-in and paging-out them dynamically. Right now with introduction of heightmaps the problem has become so apparent that I can't even complete reentry from LEO without memory bleeding out, so it's one more issue on our plate before we can release anything...

I was referring to Orbiter someday becoming 64-bit. And all those reasons about plugins is why it is not on its way soon, but it should.

But come to think of it, I cannot recall any games that are 64-bit anyway. The 64-bit programs I use are applications like Photoshop, or After Effects.

But back to the planet shine topic. I already noticed how when the HDR effects go up, there is already an iris type thing going on that crushes down the brightness, and so I guess that is what will need to be tweaked, and maybe somehow the rendering of the starfield hacked if that effect itself is not enough, because this is not only for Earth, but the other big location is when on the light side of the moon, and as those Apollo pictures famously depicted, the sky is black, not blanketed with stars.

 

[asmi]

But back to the planet shine topic. I already noticed how when the HDR effects go up, there is already an iris type thing going on that crushes down the brightness, and so I guess that is what will need to be tweaked, and maybe somehow the rendering of the starfield hacked if that effect itself is not enough, because this is not only for Earth, but the other big location is when on the light side of the moon, and as those Apollo pictures famously depicted, the sky is black, not blanketed with stars.

I think I'll stop working on a current iteration of plugin, and concentrate on a new iteration with terrain as maintaining both versions at the same time is kinda wasteful. From this discussion Martin seems to be willing to add terrain support into Orbiter core. This will take collision detection off our table, and so I will be able to release a new client without collision detection in the meantime - as I don't see reasons for implemementing stop-gap solutions. So once I'll solve this problem with resources exhausting the memory, I think we would be able to release at alpha version of terrain + new atmosphere engines. I'll also likely include new PS-based post-processing pipeline in this version (it's almost ready now and just some tuning is required), so we could start testing this out, while I work on the rest of features (shadows, tuning PP pipeline, per-pixel lighting for local lights).