New Release D3D9Client Development

[jarmonik]

I work with an important change of a setting: I have set the Panel scale to 2.

Thanks, I see it now. I'll forward it to Martin.

 

[DaveS]

Could the rate of loading of the terrain be sped up? Currently very slow and that's with all settings at default.

 

[jarmonik]

Could the rate of loading of the terrain be sped up? Currently very slow and that's with all settings at default.

If that's Orbiter Beta you are talking about then disable Surface Tile Mipmaps. They are auto-generated during loading... I just got an idea will check it out...

No go. There appears to be no hardware mipmap auto-generation for DXT1 format. Mipmaps are generated by software and then compressed to DXT1 and that will take some time and that will cause the low loading speed. Only work-a-round that works is to patch all surface textures from a hard drive to have mipmaps. It would require a patch utility and likely a several hours of time.

 

[jroly]

Wow, the improvement in visual quality and performance is a great improvement on the previous versions, my GPU fan for the first time in Orbiter went bonkers. On maximum everything, it is smooth and stable, only part when it drops below 60fps is when landing at KSC and it is just after landing and slowing down on the runway. I have Surface Tile Mipmaps enabled and have not noticed poor terrain loading, infact it is better than ever.

I might make a youtube video soon....

Sorry I know what you mean, it is very slow directly after Orbiter launches, but after it loads it is fine

 

[kuddel]

Could the rate of loading of the terrain be sped up? Currently very slow and that's with all settings at default.

What I've experienced several times is this:
The first time I ran a Scenario (e.g. "Delta-glider\Brighton Beach.scn") it loads the terrain terribly slow...but
after everything is loaded (rendered) and then Orbiter is shut down, at any subsequent start of Orbiter it seems way faster.

Don't ask me if it's the OS caching something, or the DirectX drivers or whatever...it's just something I've experienced.

/Kuddel

 

[DaveS]

What I've experienced several times is this:
The first time I ran a Scenario (e.g. "Delta-glider\Brighton Beach.scn") it loads the terrain terribly slow...but
after everything is loaded (rendered) and then Orbiter is shut down, at any subsequent start of Orbiter it seems way faster.

Don't ask me if it's the OS caching something, or the DirectX drivers or whatever...it's just something I've experienced.

/Kuddel

This is my experience as well. And jarmonik: Yes, my question was for the beta of Orbiter/D3D9Client. And it seems you're right about the mipmaps being the issue. Turn those off and things on subsequent runs speed up quite a bit.

 

[Ripley]

After updating to latest D3D9 22 for OrbiterBeta rev53, I have this error in XP:

(it says: cannot find entry point in...)

 

[jarmonik]

We got "GetModuleInformation" in D3D9Client.cpp line 106, but it has been there 2-3 years already, no changes there.

Although, version 22 is the first one build with VS2015 where as the rest are build with VS2008. Also, could it be LARGEADDRESAWARE issue ? I am currently in a middle of something else so it needs to wait a lil while.

 

[orb]

could it be LARGEADDRESAWARE issue ?

No. It's much more likely because of VS2008 to VS2015 switch.

The minimum required OS to use the client is now Windows 7.

PSAPI_VERSION needs to be defined as 1 for earlier OS compatibility (#define PSAPI_VERSION 1), and psapi.lib added to the linker dependencies.

 

[Ripley]

No. It's much more likely because of VS2008 to VS2015 switch.

I had the same impression and installed this:
https://www.microsoft.com/en-US/download/details.aspx?id=48145
but I still get the same error.

The minimum required OS to use the client is now Windows 7.

I know I have to upgrade my prehistoric rig "soon", but this kind of sucks ATM.

PSAPI_VERSION needs to be defined as 1 for earlier OS compatibility (#define PSAPI_VERSION 1), and psapi.lib added to the linker dependencies.

So I still have a chance?

 

[kuddel]

Ripley, as you have an XP-System available...
can you check if the attached build still has the problem?

It's just a test if Orbs suggestion (defining PSAPI_VERSION as 1
[*]) fixes your issue.

/Kuddel

[*] psapi.lib was in the linker dependencies all the time.

 

[jarmonik]

We have also a problem with dialog windows going outside of the screen space becoming unavailable. Like this "DlgCamPos = 1951 267 2131 714" in Orbiter_NG.cfg, inline engine seems to check and fix the faulty position. There's no rush, but could you take care of that when you got time. Thanks.

 

[Ripley]

Ripley, as you have an XP-System available...
can you check if the attached build still has the problem?

You make me feel like a dinosaur :rofl: ...mmmhhh...maybe I AM one!
YES! It works! Good job!

 

[kuddel]

We have also a problem with dialog windows going outside of the screen space becoming unavailable. Like this "DlgCamPos = 1951 267 2131 714" in Orbiter_NG.cfg, inline engine seems to check and fix the faulty position. There's no rush, but could you take care of that when you got time. Thanks.

Hi Jarmo, I think you're talking to me, right?

Does r564 (trunk) fix this?
I don't have a multi-monitor setup so *that* is not well tested.

 

[Felix24]

I got back into playing around with Orbiter textures the other day, and I discovered that mipmaps are no longer being auto-generated for vessel textures. I'm seeing this when I have texture mipmaps set to either "Autogen missing" or "Autogen all" in the graphics options section of the video setup window.

Textures I made a year ago in March and April with no mipmaps looked fine then, as if they had mipmaps. I was using D3D9 beta 12 with Orbiter Beta 150306. I am now using D3D9 Beta 22 for Rev 53, and Orbiter Beta rev. 53, and I can only get the same quality by exporting my textures with mipmaps.

Is the "Texture Mipmaps" setting in the video setup window supposed to affect vessel textures, or is it for something else?

 

[jarmonik]

Is the "Texture Mipmaps" setting in the video setup window supposed to affect vessel textures, or is it for something else?

It is supposed to effect vessels and base buildings only. It was a quick implementation without any major testing. Seems to be working at least with stock delta glider.

The reason for the setting is to reduce Orbiter startup times while doing development where a texture quality is no concern. The problem is that when mipmaps are auto-generated during loading they are compressed to DXT1 or DXT5 by software, which will take awfully lot of time.


Also, what would be your opinion about moving into a deferred or light-prepass deferred architecture somewhere after an official Orbiter 2016 release ?

---------- Post added at 07:39 ---------- Previous post was at 07:32 ----------

Does r564 (trunk) fix this?

I don't have multi-monitor setup but, Yes it seems to fix the problem in single-monitor setup at least. Thanks about taking care of that.

---------- Post added at 08:21 ---------- Previous post was at 07:39 ----------

I got back into playing around with Orbiter textures the other day....

BTW, did you notice our new lunar micro textures ?
http://www.orbiter-forum.com/showthread.php?p=528862&postcount=3569

 

[Felix24]

It is supposed to effect vessels and base buildings only. It was a quick implementation without any major testing. Seems to be working at least with stock delta glider.

After some testing with the Deltaglider, it seems that the automatic mipmaps work properly for the diffuse map and specular map, but not for the normal map. I see lots of moire patterns from a distance if I have a non-mipmapped normal map and the setting is "autogen missing" or "autogen all", and the moire patterns go away if I create the normal map with mipmaps included.

I'm not sure about the reflection map, because its moire patterns aren't as severe but don't change regardless of mipmaps.

BTW, did you notice our new lunar micro textures ?
http://www.orbiter-forum.com/showthread.php?p=528862&postcount=3569

They are amazing! You guys did a really good job getting it to look right. It adds tremendously to the realism when operating near the lunar surface.

I did notice one thing wrong in my case. The detail textures only show up on the first simulation, if I don't completely close Orbiter between simulations. If I hit Ctrl+Q and then re-open the scenario, the detail textures are no longer there. If I set the Orbiter shutdown debug option to "respawn Orbiter process", then the detail textures don't go away on subsequent runs.

 

[Felix24]

Also, what would be your opinion about moving into a deferred or light-prepass deferred architecture somewhere after an official Orbiter 2016 release ?

I know very little at all about 3D rendering, but after some research, it seems the main benefit of deferred rendering would be inexpensive multiple light sources. I assume D3D9 currently uses a forward rendering approach.

It seems that ordinary deferred rendering has problems with multiple material types within a scene, whereas light-prepass rendering doesn't. Would this be a problem for scenes containing multiple vessels having parts with different material definitions?

Currently the only light sources in Orbiter I can think of are the sun, planet, and vessel lights. Could new visual effects be realized if a few hundred light sources were available?

Three major visual effects I'm hoping for in future versions are self-shadowing, realtime irradiance mapping (sunlight reflected off clouds, ocean sunglint, and land, also glow from planet night lights), and blurred reflections (a cross between mirror reflections and specular lighting, like reflections from smooth but not shiny metallic surfaces). Would using deferred or light-prepass architecture make any of these effects easier to realize?

A while back I found an article about realtime calculation of irradiance environment maps. I thought I linked to it in a D3D9 related thread, but I can't find it anymore. Here is the article: http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter10.html. It sounds similar to the realtime reflection maps already in the D3D9 client, except a special blurring algorithm is applied. This technique might hold some promise even if it is a bit computationally expensive, since the lighting environment changes relatively slowly compared to the reflection environment. The lighting environment could be recalculated at 1Hz or even slower, once every two or five seconds, whereas the reflection environment looks bad if the updates are not much slower than the frame rate.

If a realtime irradiance map can be calculated in near real-time, a blurred reflection map may also be possible using a similar (less) blurring algorithm, also recalculated at a slow rate.

 

[Nikogori]

I found a strange blue dome on Deimos using Beta r54 and D3D9Client. I put a DG in it but nothing happened...:lol: It can't be seen with default inline client.

 

[kuddel]

Nice find! It also appears on some other bodies (e.g.the Moon) in daylight.
By the looks of it it seems like a 'pick' globe used by D3D9Client Debug Controls.
You can move the outer 'dome' (actually a globe) when opening D3D9 Debug Controls Dialog an select the 'pick' feature...
I think this is something like "0,0 position should normally remove that globes", but something went wrong somewhere