New Release D3D9Client Development

Sorry if this is a dumb question, but is there any possibility of having bump maps in the future? I've noticed that bump maps can make something look twice as detailed with almost no performance loss, and considering that this is designed more for the mid-high range computers it would make a great addition.

Is this something that can be done by a graphic client or would there need to be some change to Orbiter itself?
 
Hi All,

my first post here, so I greet this wonderful Community!

Hope not to post a question that has already been raised before, I searched a bit and didn't find anything related.

I've just tried the D3D9 Client on my laptop (Dell Studio 15, Core i5, AMD Radeon Mobile HD 5470, Windows 7 x64) and works just fine, except for a trivial glimpse in the display of the introductory splash screen: a light and narrow vertical band appears there, and the overall display quality of the splash screen is lower than the default renderer (colors appear "dithered", as if the display was set to a mere 256 colors).

Here is my question: could it be possible to add the possibility to choose the antialiasing mode in future releases of the D3D9 Client? Not using the AA at all is quite sad to me, but enabling the Multisampling 4x AA hurts the poor Radeon 5470 (I barely get around 30 fps in cockpit views, dropping to 20 fps or less in exterior camera views).

Best regards
 
Is this something that can be done by a graphic client or would there need to be some change to Orbiter itself?
This can be done in a graphics client. For example when a texture referenced by mesh file is going to be loaded, another texture with a similar name (or the same name, but for example .tga extension) can be searched for, which would be used for a bump or normal map.
 
This can be done in a graphics client. For example when a texture referenced by mesh file is going to be loaded, another texture with a similar name (or the same name, but for example .tga extension) can be searched for, which would be used for a bump or normal map.
So it would be possible. :hmm:
It'd be a nice feature to see, I'm sure we can all agree on that. :thumbup:
 
You have to persuade addon writers to use this feature before Jarmo can be persuaded to program it. I'd say if you manage to get Altea Aerospace team to support this featreq, you've already assembled a critical mass... Just 2 cents and no guarantees as ever...
 
If this feature is applicable to this I think it would perhaps be most useful for hires planet textures. If I'm not mistaken Celestia already uses bump maps to increase planet resolution.
 
To answer this question

Hi All,

Here is my question: could it be possible to add the possibility to choose the antialiasing mode in future releases of the D3D9 Client?

Best regards

I would recommend a program like Nvidia Inspector for antialiasing, with that, you can set any 3d application to any AA mode (MS, SS, Combined, etc).

Note: I currently have Orbiter set to 8xSQ [Combined: 2x2 SS + 2x MS] and it works perfectly.
 
You have to persuade addon writers to use this feature before Jarmo can be persuaded to program it. I'd say if you manage to get Altea Aerospace team to support this featreq, you've already assembled a critical mass... Just 2 cents and no guarantees as ever...
Who should I contact then? Coolhand, dbeachy, or the two of them?

Edit:
If this feature is applicable to this I think it would perhaps be most useful for hires planet textures. If I'm not mistaken Celestia already uses bump maps to increase planet resolution.
That hadn't crossed my mind, great idea! :thumbup:
 
Sorry if this is a dumb question, but is there any possibility of having bump maps in the future?

I belive that "Normal Map" is the right term to use. Speaking of bump maps could be a little misleading since a bump map is a single channel texture containing only a height information. This kind of map would need to be converted into a Normal Map by the D3D9Client.


If we wan't to create a normal mapped planet surface then I would suggest that we place the normal map information into the "_lmask.tex" file. I don't think we need R G B channels for the night lights. We could use just a monochromatic night lights and the intensity level would be stored in the blue channel which would free R and G channels for the normal map. Having a three channels for a normal map would be better but two channels are just fine, since we can compute the third channel from sqrt(1-x2-y2) or we can use a 2D lookup table to get the complete normal vector.

To do this, we need a normal map or a bump map for a planet and a proper texture tool that can pack the normal map and the night lights in the "_lmask2.tex" file. (Of course we need to preserve the original file for the inline D3D7 engine).

There is also a problem with a diffuse texture. We would need a diffuse texture that doesn't contain a high-lighted regions or a shadow regions. This problem is especially pad near the polar regions of the moon. Where the texture is mostly black and grey.
 
I belive that "Normal Map" is the right term to use. Speaking of bump maps could be a little misleading since a bump map is a single channel texture containing only a height information. This kind of map would need to be converted into a Normal Map by the D3D9Client.


If we wan't to create a normal mapped planet surface then I would suggest that we place the normal map information into the "_lmask.tex" file. I don't think we need R G B channels for the night lights. We could use just a monochromatic night lights and the intensity level would be stored in the blue channel which would free R and G channels for the normal map. Having a three channels for a normal map would be better but two channels are just fine, since we can compute the third channel from sqrt(1-x2-y2) or we can use a 2D lookup table to get the complete normal vector.

To do this, we need a normal map or a bump map for a planet and a proper texture tool that can pack the normal map and the night lights in the "_lmask2.tex" file. (Of course we need to preserve the original file for the inline D3D7 engine).

There is also a problem with a diffuse texture. We would need a diffuse texture that doesn't contain a high-lighted regions or a shadow regions. This problem is especially pad near the polar regions of the moon. Where the texture is mostly black and grey.
So... is that a maybe...? :P
 
I belive that "Normal Map" is the right term to use. Speaking of bump maps could be a little misleading since a bump map is a single channel texture containing only a height information.
Would it be possible to implement "Normal Maps" for regular meshes?
 
Houston, i got a problem.

Not sure it's the D3d client.

I made a clean installation of orbiter 2010 + patch + d3d client + dx runtime june 2010.

It works like a breeze at 1366 * 768, but only for stock vessels and Arrow Freighter.

XR vessels are completely INVISIBLE.

Not only: the same XR scenario sometimes freezes computer, keyboard, anything. I have to make a cold restart.

Configuration: i-5, 4GB ram, Nvidia 410 1GB, Win 7 Home.

Any suggestion on next try?
 
It works like a breeze at 1366 * 768, but only for stock vessels and Arrow Freighter.
XR vessels are completely INVISIBLE.
Not only: the same XR scenario sometimes freezes computer, keyboard, anything. I have to make a cold restart.

Could you zip and post the D3D9ClientLog file located in /Modules/D3D9Client/ After running a XR scenario that fails to work properly.

---------- Post added at 01:23 ---------- Previous post was at 01:10 ----------

Would it be possible to implement "Normal Maps" for regular meshes?
It is possible but to do so I would need a practical normal map for some vessel. I have done some normal mapping with DirectX 9 before so it wouldn't be the first time.
 
Could you zip and post the D3D9ClientLog file located in /Modules/D3D9Client/ After running a XR scenario that fails to work properly....

Sorry, I didn't find any log file in that folder, just *.fx files, where am I wrong?

However, here a more precise description of the problem:

1) XR-1 seems fine;
2) XR-2 crashes Orbiter, if can be useful, when it comes the sign" loading supportmodules.dds" or something similar.
3) XR-5 starts, but completely invisible.
 
Sorry, I didn't find any log file in that folder, just *.fx files, where am I wrong?
No .html file either? The log is named "D3D9ClientLog.html".
 
I would recommend a program like Nvidia Inspector for antialiasing, with that, you can set any 3d application to any AA mode (MS, SS, Combined, etc).

The NVidia Control panel or (ATI) Catalyst Control Centre allow you to set all these values on a per-application basis. That covers pretty much all of the consumer graphics card market, so just go to the ATI/nVidia website.

---------- Post added at 15:28 ---------- Previous post was at 14:10 ----------

Are there any plans for the D3D9 client to have vessel-on-vessel shadows and self-shadows?
 
No .html file either? The log is named "D3D9ClientLog.html".

No such file is present in Orbiter & subfolders. No html or log, except "DeltagliderXR1.log", in orbiter folder.
 
Last edited:
No such file is present in Orbiter & subfolders.
In "%USERPROFILE%\AppData\Local\VirtualStore" and subfolders maybe?

Where have you installed Orbiter?
 
Back
Top