New Release D3D9Client Development

D3D9ClientRC28

I was able to reproduce a CTD with that addon. Here is RC28 for testing.:thumbup:
 
Last edited:
I was looking at the code and... oh my God ! This is a real bible to learn D3D9 !

During my exploration, I found out that you use a big vertex and index buffer to store the mesh, and that you call the offset of it to draw the primitives (I don't know if my sentence is clear...).

I wonder why you didn't use the ID3DXMesh interface to do that. It handles a part of the job for you and it has functions like OptimizeInplace which can reorder the faces and vertices for better performance (maybe a performance increase for big meshes like the XR2).

By the way, you did a really great job, :tiphat:

Edit:

Oh, just read on your post #14 :

"The D3D9Mesh class should be rewritten to use a ID3DXMesh interface and HW vertex processing. Also, that would probably reduce the code lines in half."

So you plan to do it ?
 
Last edited:
During my exploration, I found out that you use a big vertex and index buffer to store the mesh, and that you call the offset of it to draw the primitives (I don't know if my sentence is clear...).

I wonder why you didn't use the ID3DXMesh interface to do that. It handles a part of the job for you and it has functions like OptimizeInplace which can reorder the faces and vertices for better performance (maybe a performance increase for big meshes like the XR2).
I did use the ID3DXMesh interface at first but it was a bad idea so I removed it.

1. For some reason a vertex buffer (ID3DXMesh) is very slow to create. It takes about 10ms per vertex buffer. If a mesh has 100 mesh groups and a vertex buffer for each group then the allocation of the mesh will freeze the computer for a one second which is very bad especially during staging of multi stage rocket.

2. Calling ID3DXMesh::DrawSubset() is also very slow and inefficient. I don't know why.

3. 3D Modelling software will do all necessary optimizations for a meshes so there is nothing left to be optimized.
 
Thank you for the explanations jarmonik. :) A good advice for me if I ever create a complete program using Direct3D.

Direct3D is pretty hard to work with... I managed to create my Orbiter Mesh Viewer using OpenGL, but I'm stuck with the Direct3D version...
 
Just a heads up, for me Spacecraft3.dll addons work without problems, I've been using quite a few space station parts etc. and I haven't any problems so far. :shrug:
 
This may be the wrong thread for this, but has anyone had any success in getting Orulex to work in the D3D9client? For pure space to space applications D3D9 is wonderful, but I'm having trouble going back to the old "billiard ball" planets...

:cry:
 
D3D9ClientRC27 - Strange lines

Anyone else having strange vertical lines with RC27?

First time I've tried the D3D9 version, running with Orbiter_NG, with the D3D9 client enabled. I'm running a ATI Radeon 5700. The graphics are an obvious improvement over the current release, but there are these annoying vertical lines, and some tearing. This is when viewing in external mode.
 
I don't recall anyone reporting anything about vertical lines before. Could you provide a screen shot. Unchecking the "Disable vertical sync" from video tab might help with the tearing.
 
D3D9ClientRC29

RC29 is now uploaded.
 
RC29 shows white letterboxes instead of "PAUSED", and loading takes inordinate amount of time. This on NVIDIA card with GDI compatibility on.
 
RC29 shows white letterboxes instead of "PAUSED", and loading takes inordinate amount of time. This on NVIDIA card with GDI compatibility on.

Could you turn off the "PreLoadBaseVisuals" from D3D9Client.cfg by setting it zero. You probably have a high number of large surface bases installed which would explain the inordinate loading time. Also the "PAUSED" failure could be explained by system running out of memory or something like that.

EDIT: What will happen if you start the simulation from the Mars or the Moon with PreLoadBaseVisuals = 1 ?
 
Last edited:
I'm currently at my parents home, 600 km away from my PC.

They use an aged PC I owned about... 10 years ago or so ! But I upgraded it a little bit in the past... I don't really remember ! :lol:

Still, it runs Orbiter 2010 rather smoothly (well, 30-50 FPS with all options on, default planetary textures).

However, I had no luck in trying the D3D9 Client RC29. D3D 9.0c is installed and everything is fine in "DxDiag". The problem is that I can activate the "D3D9 Client" module in the Launchpad, but the "Video" options tab doesn't appear. And Orbiter_ng runs as if there was no client (even though the D3D9 client is activated in the modules box).

Here's the config I use :

- COMPAQ Presario 6142EA
- AMD Athlon XP 1800+, MMX, 3DNOW
- 768 MB RAM
- NVIDIA GeForce4 Ti 4200 (64 MB)
- NVIDIA nForce AGP Host to PCI Bridge
- Windows XP Pro SP3

The driver used is called "GeForce 4 Ti 4200 (Microsoft Corporation)", v 5.6.7.3, provided by NVIDIA, 07/04/2004. I tried newer ones from NVIDIA site but though they are stated as "GeForce 4 Ti 4200 compatible", I get the lowest resolution with 4 colors. The resolution slider under Desktop Properties is there and shows various resolutions, but "Apply" just does nothing.

So, if you had an idea, I'm curious... Is that GeForce 4 Ti 4200 (64 MB) just too old ?
 
Re: PreloadBaseVisuals - it did the trick, load time was all right on Earth, and there were no letterboxes! Thanks Jarmo!
 
So, if you had an idea, I'm curious... Is that GeForce 4 Ti 4200 (64 MB) just too old ?

GeForce 4 Ti is D3D8 graphics card and simply has no required shader support (according to Wikipedia there's Pixel Shader 1.3 & Vertex Shader 1.1). D3D9 client requires D3D9 graphics card with full support for Shader Model 3.0 (DX 9.0c).
 
D3D9Client also requires SSE2 support from the CPU which is lacking from the Athlon XP.
But since the source is included, it can be compiled without "/arch:SSE2".

BTW, what is "D3D9ClientMk2" project included in the solution but missing from the sources?
 
BTW, what is "D3D9ClientMk2" project included in the solution but missing from the sources?

Nothing important. The idea was to create two different clients. One client containing just the default features of the Orbiter with lower system specs requirements and an other client with more advanced features. Current project goal is to get the client fully operational and stable before starting to implement any additional features. I am also waiting for a new beta of the Orbiter in a hope that it would address some known problems.

The LTMFD project will need my attention for a while so there will be a small brake in this project.
 
The Universal RMS seems to be only partially working - I can move the hand with the "external" controller, but the HUD does not change and there is no object highlighting, as well as any grapple attempts result in "object too far" message.

Is it a known issue?
 
The Universal RMS seems to be only partially working - I can move the hand with the "external" controller, but the HUD does not change and there is no object highlighting, as well as any grapple attempts result in "object too far" message.

Is it a known issue?

I havent tried this myself, but using GDI Compatability mode usually fixes HUD issues. Agian I havent tried URMS but with UCGO it fixes the missing HUD.
 
Enabled GDI. Yep, it fixed the HUD on UMMU (although there still is an always-on yellow filter), but the cargo, that should have been (in the save) attached to the RMS appears attached to it's base point.
In native renderer it worked ok.
 

Attachments

  • orbiter 2011-08-04 21-56-02-55.jpg
    orbiter 2011-08-04 21-56-02-55.jpg
    32.3 KB · Views: 45
Back
Top