New Release D3D9Client Development

There are newer patches available that should work and you can compile the latest "Raytraced VC" feature branch from GitHub. There's been quite lot of progress since the patch you linked so we are not going to revert back to that revision. Latest patch should have all the functionality that the old one had. Have you done some work with ray-traced VC ? If yes, then could you share some screen shots, it would be interesting to see it in operation.
Sorry if I worded it badly, I wasn't saying go back to the old one I was just asking about the feature.
I installed this patch from a few days ago over my latest release OO x86 install, and there were no window shadows. The new options for cockpit shadows, etc were in the settings menu and the in-sim debug window, so I know it was installed.

I don't believe I have any screenshots sadly, I tested it briefly when the old patch was released here with the intent of using it with NASSP but NASSP+OO wasn't really stable then so I never pursued it.
 
The promised continuation on the report of yesterday's problems: 2016 MOGE also doesn't work with the NVIDIA in window mode... not sure how it switched GPUs in the new version. In full screen with the NVIDIA, the 2016 MOGE works well with just a few visual glitches and white image instead of splash screen. In the new version it only shows white. Both work in window mode with the iGPU.

On D3D9, comparing my "old" and "new" Orbiter_NG.cfg files, I think I found the culprit for the missing planetary textures: "PlanetTexDir = C:\Software\Orbiter2016-SVN-Clean\Textures\", which is not a path in my system.

D3D9: OK on NVIDIA and iGPU.
D3D9on12Client: kaput just after selection. Log: "Failed to create DirectX9".




One thing I've been meaning to ask for a while now: can a SURFHANDLE be saved to a JPG or PNG file? I remember seeing some functions in the code when Orbiter first went public (and there has to be something to save the scenario images that are shown in the launchpad), but I don't think that feature is "exposed" in the API. If work needs to be done, then let's leave this for a later Orbiter version.



Something that might be fixable for the current version is the glowing DIFFUSE particles in D3D9.
 
The promised continuation on the report of yesterday's problems: 2016 MOGE also doesn't work with the NVIDIA in window mode... not sure how it switched GPUs in the new version. In full screen with the NVIDIA, the 2016 MOGE works well with just a few visual glitches and white image instead of splash screen. In the new version it only shows white. Both work in window mode with the iGPU.
On D3D9, comparing my "old" and "new" Orbiter_NG.cfg files, I think I found the culprit for the missing planetary textures: "PlanetTexDir = C:\Software\Orbiter2016-SVN-Clean\Textures\", which is not a path in my system.
D3D9: OK on NVIDIA and iGPU.
D3D9on12Client: kaput just after selection. Log: "Failed to create DirectX9".
One thing I've been meaning to ask for a while now: can a SURFHANDLE be saved to a JPG or PNG file? I remember seeing some functions in the code when Orbiter first went public (and there has to be something to save the scenario images that are shown in the launchpad), but I don't think that feature is "exposed" in the API. If work needs to be done, then let's leave this for a later Orbiter version.
Something that might be fixable for the current version is the glowing DIFFUSE particles in D3D9.

D3D9on12Client shouldn't exists anymore. Likely left behind from an older release/patch. Those problems related to MOGE are likely something that nobody can do anything about it. Functions to save and load jpg and png files do exists in D3D9Client but I don't remember if those are exposed to API. I can take a look.
 
  • Like
Reactions: GLS
Sorry if I worded it badly, I wasn't saying go back to the old one I was just asking about the feature.

You need to open D3D9DebugControls select the VC mesh and then apply "This is VC Mesh" and "Cast VC Shadows" options. You may need to apply "Cast VC Shadows" to exterior mesh too. I don't know how it's going to work without ambient probe. In a stock Atlantis it's done like this: Coordinates are in a local vessel coords. Open space with good visibility to everywhere in a cockpit.

Code:
void Atlantis::clbkVisualCreated (VISHANDLE _vis, int refcount)
{
    if (refcount > 1) return; // we don't support more than one visual per object
    vis = _vis;
    SetVisualProperty(vis, VisualProp::CREATE_VC_PROBE, 0, typeid(FVECTOR3), &FVECTOR3(0.0f, 2.6f, 14.0f));
    // make sure the RMS attachment point is in sync with the animation state of the visual
    SetAttachmentParams (rms_attach, arm_tip[0], arm_tip[1]-arm_tip[0], arm_tip[2]-arm_tip[0]);
}
 
Where do we stand on getting this issue from 2020 properly addressed: https://www.orbiter-forum.com/threads/d3d9client-development.16787/post-263061
Almost there, latest VC rendering experiments could ALMOST get the job done. Interior parts of the Payload bay should be a separate mesh like the VC is. Bay doors should also belong into that mesh. There are some details that are not so clear yet. After the release of Orbiter 2024 these modifications should be made to Stock Atlantis so that I have a model I can work (experiment) with.
 
You need to open D3D9DebugControls select the VC mesh and then apply "This is VC Mesh" and "Cast VC Shadows" options. You may need to apply "Cast VC Shadows" to exterior mesh too. I don't know how it's going to work without ambient probe. In a stock Atlantis it's done like this: Coordinates are in a local vessel coords. Open space with good visibility to everywhere in a cockpit.
Ah ok, I got it to show shadows in both the DeltaGlider and NASSP.
The only issue I have now is that as soon as I set the shader to BakedVC the entire mesh goes metallic with ugly reflections.
 
Sorry, I'm just interested, could you show a couple of screenshots from Delta Glider cockpit with the default shadows and "these new ones" ("BakedVC patch" if I understand correctly) for comparison? I'm just wondering what these shadows are and how they look (I haven't tried it yet). VC means virtual cockpit, yes?
 
[...] Functions to save and load jpg and png files do exists in D3D9Client but I don't remember if those are exposed to API. I can take a look.
The GraphicsClient base class[*] has the virtual method clbkSaveSurfaceToImage (SURFHANDLE surf, const char *fname, ImageFileFormat fmt, float quality=0.7f)
Most Graphic Clients should have implemented it, so code like this is used:
C++:
gclient->clbkSaveSurfaceToImage (0, "Images\\CurrentState", oapi::IMAGE_JPG);

[*] defined in Orbitersdk\include\GraphicsAPI.h
 
It's been noted. D3D9 is falling apart, newer laptop computers can't run it anymore. New replacement is planned and we need a better GUI, before that happens, I don't think I'll start working on any new graphics features.
Isn't more a case of that Windows 11 can't run it? Also, what about the Terrain Toolkit guide?
 
Is there a way to tweak the distance haze in OpenOrbiter D3D9Client? I tried playing with the various sliders in the Atmospheric Controls dialog, but none of them had any effect on the distance haze. Is this something that needs to be from the cfg file?
 

Attachments

  • OO_D3D9_distance_haze.jpg
    OO_D3D9_distance_haze.jpg
    104.9 KB · Views: 7
It seems to be some elevation issue in the new v240310 build. Compare these two picture of an island for the prievious build and the new one (linear interpolation is used for both, but in the new build that island seems to be flat from the distance):

sun1.pngsun2.png

Also, there're texture black gaps, and here the DG is under texture (only part of the DG roof is visible), but if we zoom in a little then DG is on the runway, although these black gaps remain:

1.png2.png
3.png
 
When doing debugging I noticed a problem in a tile elevation cache and fixed it (at-least, so I thought). I did plenty of testing with the new cache and never saw any issues. So, those screen shots are pretty concerning.. Something is a miss but what exactly.

Is the flat area always under the camera ?
Could you send your D3D9Client.cfg and Orbiter_NG.cfg

Anyone else seeing that ?
I'll review the code changes again tomorrow.
 
Is the flat area always under the camera ?
Yes (if I understand correctly). The hills shown in the first picture become flat after the camera approcahing them (second picture):

1.png2.png

I also tried Mesh resolution=16, and those black gaps remain, but less often (it seems so to me), than for Mesh resolution=32. I get those black gaps even immediately after the first launch of a scenario. Firstly I thought I use the bad setting:

Без імені.png

I attach two files (I changed *.cfg to *.txt) you mentioned after these black gaps happened. And Orbiter.log, too.

The problem with immersed DG at large distances seems to be related with the elevation problem.

You could use "The Alps in 3D" scenario in "2016 Edition" folder. It's very noticeable how mountains become flat under the camera:

a.png
 

Attachments

Last edited:
cannot confirm (at least not as bad as above), I have the occasional persistant black triangle that "repairs" by zooming in and out.0006.jpg
presumeably a load cache problem
 

Attachments

I still haven't been able to reproduce the problem but I did found a memory zero initialization problem that might have cause the issue. Here's a new binary for testing, could you check if the problem is fixed. Copy the file in /Modules/Server/ folder. This is x86 binary.
 

Attachments

Back
Top