New Release D3D9Client Development

[jarmonik]

Thanks for reporting the bug and I can confirm it. It is caused by a fact that Direct3DDevice9::StretchRect() can't use stretching between two plain-surfaces. It should be possible to create a GDI workaround for this. Also it's possible to convert the target surface type to rendering target texture to allow the scaling to work properly.

I haven't had any time to work with this project during the last 4-6 weeks. But anyway, you can get the Map working by setting the paramater "MemAllocLogic = 0" to "1". As an side effect it may reduce a frame rates.

 

[-Apollo-]

Are you running any other applications? I have some applications that force themselves on top of other windows and they can have this sort of effect in Win XP (Yahoo Widgets, Timeleft, Panasonic Phone Assistant come to mind).

No Sir, i don't use anything else except the orbiter..

 

[Disconnect]

Hi!

Will be any graphical improvements over the dx7 client functionality in dx9 client?
Is it possible to use different atmospheric haze textures for planets? Because ogla knows it, and the earth looks more better with a realistic blueish haze, than default, but other planets good with default.

And two problems:
http://dl.dropbox.com/u/5862163/orbiter_dx7.png
http://dl.dropbox.com/u/5862163/orbiter_dx9.png

These dark spots are on all outer planets, but not on inner planets.
And as you can see the planetarion mode indicators aren't the same too. Some indicators only appear at certain angles.

And i don't see any distant planet/moon "white dots". Is it a bug, or aren't implemented yet?

 

[jarmonik]

Will be any graphical improvements over the dx7 client functionality in dx9 client?

Most likely yes.

Is it possible to use different atmospheric haze textures for planets?
Because ogla knows it, and the earth looks more better with a realistic blueish haze, than default, but other planets good with default.

Current implementation doesn't support alternative textures. But you can change the haze color from the Earth.cfg. Also a "raytraced" atmospheric rendering technique is under work which may change everything.

These dark spots are on all outer planets, but not on inner planets.

Interesting. I haven't been able to reproduce this. Do you have high resolution textures installed above lvl 8 ? I suppose this could be caused by the micro-texture used in the Earth's oceans or clouds.

And as you can see the planetarion mode indicators aren't the same too. Some indicators only appear at certain angles.

I can reproduce this one. Must be caused by a graphics culling algorithm.

And i don't see any distant planet/moon "white dots". Is it a bug, or aren't implemented yet?

Not yet implemented.

 

[Disconnect]

On planets i'm using the highest resolution "official" textures, from here: http://downloadorbitersim.com/?page_id=42
So for moon and earth, mars i use lvl14 and 11 textures, but there is no problems with those, only with the outer planets.

And for outer planets im using outer planets addon, with it's hi-res extensions (level7-8 texture).

There are no any errrors in logs. os is win7 x64 with an radeon hd3870 video card, and not too old catalyst (last year winter-fall). I've switched off anisotropic filtering, but doesn't change it.

 

[luki1997a]

Hey!
What's the progress with the client:blink:? I've seen D3D9_d2 and it's very cool. I wish you nice programming :thumbup:

Please add bumpmapping:thumbup:

 

[Poscik]

Please add bumpmapping:thumbup:

Where do you need bump mapping? Adding it is waste of time in my opinion.

 

[luki1997a]

Where do you need bump mapping? Adding it is waste of time in my opinion.

I think, the planets look much better with this. Eg. moon looks better with bumpmapping, because it has a lot of craters. Look at the picture:
http://www.shatters.net/~claurel/celestia/mars-bump.jpg
You can think, that it's 3d terrain, but it isn't. With bumpmapping, craters, mountains or e.g. Valles Marineris looks better. Adding bumpmaps to vessels, can make them more "natural". Look for bumpmapping in OGLA.

I'm just propositioning:thumbup: If you want[Jarmonik], you can write a code, which will allow to add bumpmaps. It will be good 3d terrain simulation from space:thumbup:
Good luck:thumbup:

 

[jarmonik]

The top priority is to maintain a compatibility between different add-ons. Therefore, an add-on breaking improvements like 3d-terrain won't be implemented. It is possible to improve a high altitude planet rendering with a normal maps but there are a lot of work. It's not as easy to implement as you might think.

My current priorities in a D3D9Client project are:

1. Fix known bugs and issues from RC10
2. Finish the implementation of atmospheric scattering.

 

[theflyingfish]

IMHO, a large change in Orbiter (like 3D-Terrain, FSX-Style) will require change in the core programming in Orbiter, a change that only Martin can make. Any addon, like Orulex, will either be very unstable or have to make compromises, because the current Orbiter installation (Or Orbiter in general) was not designed from the ground up with 3D-Terrain in mind.

I am fine with the current goals. I think that the performance gains from D3D9 will be very useful for the more demanding addons that are now being released, and who can say no to atmospheric scattering, or to atmosphere rendering improvements in general?

 

[jarmonik]

And as you can see the planetarion mode indicators aren't the same too. Some indicators only appear at certain angles.

This seems to appear in the D3D7Client in a same way. It seems that the Orbiter will disable a celestial body markers when the body becomes small enough which will make them disapear. If this is very annoying then it might be good idea to write a bug report for the Orbiter_ng.

 

[Disconnect]

This seems to appear in the D3D7Client in a same way. It seems that the Orbiter will disable a celestial body markers when the body becomes small enough which will make them disapear. If this is very annoying then it might be good idea to write a bug report for the Orbiter_ng.

The scene is saved and loaded in dx9 mode without any modifications. so tha camera hasn't moved. But as you can see on screenshots(larissa is exactly on same point of the picture), the markers are not the same. If i move the camera, and move it away from the bodies, i always see that the markers disappear more earlier in dx9 than in dx7.

 

[jarmonik]

The scene is saved and loaded in dx9 mode without any modifications. so tha camera hasn't moved. But as you can see on screenshots(larissa is exactly on same point of the picture), the markers are not the same. If i move the camera, and move it away from the bodies, i always see that the markers disappear more earlier in dx9 than in dx7.

In the screen shot you are running the Orbiter with it's internal dx7 engine not with external D3D7Client. I can confirm that the markers will disapear much earlier from the D3D9Client when compared to Orbiter's internal dx7 engine.

So, can you confirm that D3D7Client and D3D9Client will behave differently in this matter ?

---------- Post added at 12:53 ---------- Previous post was at 12:24 ----------

Ok, problem solved. I found a way to match the behaviour with the inline engine. Planet and vessel markers are handled differently than the rest of the markers.

 

[jarmonik]

Here is RC11 for testing. I have splitted the project into a two different clients. A basic client has only the features of inline engine and has a lower system requirements. An advanced client will be implemented with atmospheric scattering and some other features in the future.

Here is a list of recent changes:

- Water specular reflection bug fixed
- Some camera lag issues fixed
- Celestial body marker issue fixed
- Celestial body dots implemented
- New Fullscreen mode implemented
- Vessel shadow bug on the Moon fixed
- Old style MapMFD bug fixed

There are still some orbital sunrise/lighting issues and building/vessel lighting issues. Looks like the lighting calculations must be reimplemented. I was thinking about creating a color lookup lable (texture) for the sunlight color and ambient light intensity as an function of sun-horizon angle and vessel altitude. It cloud be then photo-shopped to match user´s needs.

 

[jarmonik]

There seems to be one troublesome issue. When I test the client with nVidia GF9600 Hardware, a creation of a mesh is very fast but releasing a mesh will take very long time (somewhere around 0.1 to 1s per mesh) and that will cause a very long delay when closing down a simulation especially when using AMSO.

However, when testing the client with nVidia GTX460 hardware it will work in the opposite way, a creation of a mesh will take very long time (0.1 to 1s per mesh) causing a very long and slow startup of simulation but the release operation is very fast.

Anyone having similar issues with the client ?

 

[dbeachy1]

FWIW, it works great on my ATI 5970 on both startup and shutdown. :tiphat:

 

[N_Molson]

Works fine, there are animation issues with Thornton's SoyuzTMA, tough (that was the case in previous releases).

 

[jarmonik]

Works fine, there are animation issues with Thornton's SoyuzTMA, tough (that was the case in previous releases).

Could you be little more specific, what kind of issues and where ? I don't recall anyone reporting that before.

 

[N_Molson]

Here what's happen when I jettison the BO, seems that the meshgroups are messed in some way :

The LES abort animations are messy too, the meshes that move aren't the right ones.

Does the same scenario & test work fine with the default DX7 client?

Yes, it does.

 

[dbeachy1]

Does the same scenario & test work fine with the default DX7 client?