# New ReleaseD3D9Client Development

#### DaveS

##### Space Shuttle Ultra Project co-developer
Donator
Beta Tester
Now, the only problem seems to be that instead of a flat grey, the GOX Vent Arm has this weird yellow color. I've attached a photo of how it supposed to look.

#### Attachments

• D3D9Client_yellow_GVA.jpg
627.3 KB · Views: 35
• DF-ST-86-12045.jpg
736.5 KB · Views: 34

#### DaveS

##### Space Shuttle Ultra Project co-developer
Donator
Beta Tester
Another item: A code sample that shows the shows the "SpecialFX" parameter in action. Felix24 posted his heatmap texture in post for the default Atlantis so it could be a good starting point.

#### DaveS

##### Space Shuttle Ultra Project co-developer
Donator
Beta Tester
The issue remains with R4.20. And the terrain and flickering problems are at KSC with the BC add-on installed.
I now experience it at BC as well. I can reliably reproduce the problem by just using the "BocaChica 10km Hop" scenario from this add-on: https://www.orbithangar.com/showAddon.php?id=f134e80a-f13e-4599-93e7-50ba8e744f01
Another part of the same problem is that base elements are floating midair.

Edit:
After just moving the ground observer location down to absolute ground level and reloading the (Current state) scenario, the issue is gone, even in the "BocaChica 10km Hop" scenario. This is on a fresh Orbiter 2016 installation, with the high-res Earth package installed.

Last edited:

#### Felix24

##### Active member
A couple of issues I'm having:

1. I'm having trouble again with the Reload Textures button. This time the textures aren't reloading while Orbiter is running. The simulation does hang for 3 seconds which is normal, but the textures don't change at all. But the textures do update if I close and restart the scenario. I am experimenting with BrianJ's Crew Dragon DM-2 (https://www.orbithangar.com/showAddon.php?id=06e64e6a-53e0-45ba-8aa4-2adf6a7fa792). I confirmed that the texture reload button does work with the DeltaGlider.

2. When using the D3D9 Debug Controls on a vessel that has no materials config file, setting the default shader to Metalness and then clicking "Save materials" doesn't save the setting. It creates a new materials config file with a single line that says
CONFIG_VERSION 3

The shader setting is not remembered when restarting Orbiter. However, when I set the default shader and then change a random material property and then click "Save materials", it saves everything correctly. So it seems that changes in the default shader setting don't get saved, but do if you also change something else in the same meshgroup in the same session.

CONFIG_VERSION 3 ; ============================================= MESH DG\deltaglider_ns SHADER Metalness SAFEGUARD 0 ; --------------------------------------------- MATERIAL 11 SMOOTHNESS 1.000000 1.000000

Any ideas?

#### jarmonik

Beta Tester
A couple of issues I'm having:
1. I'm having trouble again with the Reload Textures button......
2. When using the D3D9 Debug Controls on a vessel that has no materials config file, setting the default shader to Metalness and then clicking "Save materials" doesn't save the setting.....

Thanks for the reports, I will look into it.

#### jarmonik

Beta Tester
Another item: A code sample that shows the shows the "SpecialFX" parameter in action. Felix24 posted his heatmap texture in post for the default Atlantis so it could be a good starting point.
C++:
gcCore *pCore = gcGetCoreInterface();
if (pCore) {
COLOUR4 value = { heat, 0, 0, 0 };
pCore->MeshMaterial(hMesh, material_idx, MESHM_SPECIALFX, &value, true);
}

The "COLOUR4" will be replaced with "FVECTOR4" in the near future.
See API_Guide.pdf for further details. (page 14, "re-entry flames")

#### DaveS

##### Space Shuttle Ultra Project co-developer
Donator
Beta Tester
C++:
gcCore *pCore = gcGetCoreInterface();
if (pCore) {
COLOUR4 value = { heat, 0, 0, 0 };
pCore->MeshMaterial(hMesh, material_idx, MESHM_SPECIALFX, &value, true);
}

The "COLOUR4" will be replaced with "FVECTOR4" in the near future.
See API_Guide.pdf for further details. (page 14, "re-entry flames")
Could you put this in a actual vessel's source code like the default Atlantis?

#### DaveS

##### Space Shuttle Ultra Project co-developer
Donator
Beta Tester
Maybe wrong thread ask this in, but anyone know any way to improve or eliminate entirely, the gaps in particle streams around the source? I've attached a screenshot of what I mean indicated by the red arrows.

#### Attachments

• MPS_GOX_vent.jpg
1.5 MB · Views: 39

#### Felix24

##### Active member
Maybe wrong thread ask this in, but anyone know any way to improve or eliminate entirely, the gaps in particle streams around the source? I've attached a screenshot of what I mean indicated by the red arrows.
Maybe we need a new type of particle stream, like a continuous billboard texture that flows from the origin point. It would start out narrow and then scale up as it gets further away.

Or maybe it could be an animated billboard texture using sprites. Is it already possible to make an animated texture in Orbiter this way?

#### DaveS

##### Space Shuttle Ultra Project co-developer
Donator
Beta Tester
Maybe we need a new type of particle stream, like a continuous billboard texture that flows from the origin point. It would start out narrow and then scale up as it gets further away.

Or maybe it could be an animated billboard texture using sprites. Is it already possible to make an animated texture in Orbiter this way?
There's a related discussion going here: https://www.orbiter-forum.com/threads/overexpanded-exhaust-plumes.39710/post-582483

This is a quote from me in that thread:
"I think the problem really stems from Orbiter's antiquated particle stream system. It was first implemented in the November 5 2003(!!) build. So, like a lot of things in Orbiter, it's old, outdated and in serious need of replacement with something more modern. So the PSS we're accustomed to is nearly 18 years old and should have been replaced a long time ago."

D3D9Client is just rehashing a lot of Orbiter's outdated graphics with better frame rates on modern systems. And this is in an effort to maintain backwards compatibility when it is sad and painfully obvious that Orbiter is being left in the dust. In the best of worlds and circumstances, the next version of Orbiter would completely detach itself from the graphics and only handle the actual physics. The DX7 client would be just an open source reference example of how to implement a graphics client and attach to Orbiter.

Last edited:

#### jarmonik

Beta Tester
• Cleaned up material manager. This should fix the faulty config generation in a case if no materials are modified. Hopefully the cleanup haven't caused any new issues.
• Texture reload "fix". Some safeguard have been removed from the reload function to allow it to reload more forcefully but the reload will now remove any dynamic changes made to a textures during runtime.
• COLOUR4 has been replaced with FVECTOR4 in MeshMaterial() to be more flexible in type casting and color/math operations.

#### jarmonik

Beta Tester
I believe that the caps are due to insufficient particle density compared to a velocity. There's been discussion before that we could have an alternative particle system side by side with the legacy particle system to allow more configuration options.

#### DaveS

##### Space Shuttle Ultra Project co-developer
Donator
Beta Tester
I believe that the caps are due to insufficient particle density compared to a velocity. There's been discussion before that we could have an alternative particle system side by side with the legacy particle system to allow more configuration options.
That is exactly what is needed. The stock PSS doesn't provide enough options to really nail down the varying behaviors of particle streams. I think the core of the issue isn't really the availability of options as much it is one of assumed logic. The assumed logic I referring to is that gas clouds behave the same in space as they do in atmosphere. This isn't really true. Both NASA and the USAF have dedicated multiple missions, both orbital and suborbital, to understanding gas cloud behavior in a vacuum. Several of these orbital missions involved the space shuttle (two major ones were the Ram Burn Observations (RAMBO) and Shuttle Ionospheric Modification with Pulsed Localized Exhaust Experiments (SIMPLEX)).

And we can't forget STS-39 an unclassified DOD shuttle mission dedicated to the investigation of exhaust plumes in a vacuum: https://science.ksc.nasa.gov/shuttle/missions/sts-39/mission-sts-39.html

#### DDasng1352

This should be the latest D3D11Client package, including the sources.
Ain't working for me. For some reason it doesn't and when I open O2016 it shows this.

#### DaveS

##### Space Shuttle Ultra Project co-developer
Donator
Beta Tester
Ain't working for me. For some reason it doesn't and when I open O2016 it shows this.
The D3D11Client isn't in active development anymore and I think you need one of the pre-2016 betas to run it. And I only linked it because jarmonik was interested in it, not to suggest it as a viable alternative to D3D9Client.

#### DDasng1352

The D3D11Client isn't in active development anymore and I think you need one of the pre-2016 betas to run it. And I only linked it because jarmonik was interested in it, not to suggest it as a viable alternative to D3D9Client.
Oh alright, whelp now I'm back to looking for interesting shade like things.

#### DDasng1352

Oh alright, whelp now I'm back to looking for interesting shade like things.

Anyone got any suggestions for any interesting sharers that are comparable with D3D9.

Last edited:

#### Abloheet

The D3D11Client isn't in active development anymore and I think you need one of the pre-2016 betas to run it. And I only linked it because jarmonik was interested in it, not to suggest it as a viable alternative to D3D9Client.
Here's to hoping jarmonik gets some ideas!

Not much use though, as he himself said before, that d3d9client at the moment is just a wrapper for very old DX7 api calls. Which can't do a lot of modern advanced stuff anyway. Just that the wrapper enables better performance for modern operating systems