New Release D3D9Client Development

[DaveS]

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]

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.

 

[Felix24]

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]

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.

 

[jarmonik]

New version (4.22) is uploaded.

• 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]

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]

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

 

[Mr. Residuals]

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]

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.

 

[Mr. Residuals]

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.

 

[Mr. Residuals]

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.

 

[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

 

[Mr. Residuals]

reflections disabled

Wait how to do you enable and disable reflections since I don't know.

 

[Mr. Residuals]

Wait how to do you enable and disable reflections since I don't know.

Another random question, so when you enable the Metal PBR Shade for one mesh it remains for that mesh right?

 

[n72.75]

So I'm running into a weird problem with [--I think--] D3D9 client.

This morning I was using both Orbiter Beta for some NASSP dev stuff, and Orbiter 2016, checking out Igel's Vostok.
In all cases Orbiter abruptly closed without an error message, however application logs show some details.

It's very strange that I'm getting similar [looking] errors in two separate instances and versions of Orbiter/D3D9 client.

Hopefully the offset values give some insight. Let me know if there is a way I can help gather more data.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Orbiter 2016, running the March 20 D3D9 client version (updating it now, I know it's old. I mostly use the BETA)

Faulting application name: orbiter.exe, version: 0.0.0.0, time stamp: 0x57c23356
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x00accb4c
Faulting process id: 0x5280
Faulting application start time: 0x01d76b4dc57fc40d
Faulting application path: C:\Orbiter\Orbiter2016\modules\server\orbiter.exe
Faulting module path: unknown
Report Id: 94fb29fd-62bf-444b-a67b-a567b9303a63
Faulting package full name:
Faulting package-relative application ID:

Faulting application name: orbiter.exe, version: 0.0.0.0, time stamp: 0x57c23356
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc000041d
Fault offset: 0x00accb4c
Faulting process id: 0x5280
Faulting application start time: 0x01d76b4dc57fc40d
Faulting application path: C:\Orbiter\Orbiter2016\modules\server\orbiter.exe
Faulting module path: unknown
Report Id: a6cc5d32-e7f0-47a8-b030-8d57cc545d63
Faulting package full name:
Faulting package-relative application ID:

Orbiter BETA running r1356. I was using Apollo 7 to generate and log telemetry data over TCP (I'm 99% sure this is unrelated)

Faulting application name: orbiter.exe, version: 0.0.0.0, time stamp: 0x5d7c2f68
Faulting module name: OrbiterSound.dll, version: 0.0.0.0, time stamp: 0x5f31ea23
Exception code: 0xc0000005
Fault offset: 0x00015a2e
Faulting process id: 0x5174
Faulting application start time: 0x01d76b615704ff50
Faulting application path: C:\Orbiter\OrbiterBeta\modules\server\orbiter.exe
Faulting module path: C:\Orbiter\OrbiterBeta\Modules\Plugin\OrbiterSound.dll
Report Id: 40d2c04e-e8f5-45fe-8fa9-5298c3815120
Faulting package full name: 
Faulting package-relative application ID:

Faulting application name: orbiter.exe, version: 0.0.0.0, time stamp: 0x5d7c2f68
Faulting module name: D3D9Client.dll, version: 30.1.0.0, time stamp: 0x5f55d06b
Exception code: 0xc0000005
Fault offset: 0x000291a0
Faulting process id: 0x30d0
Faulting application start time: 0x01d76b63df7b0d6a
Faulting application path: C:\Orbiter\OrbiterBeta\modules\server\orbiter.exe
Faulting module path: C:\Orbiter\OrbiterBeta\Modules\Plugin\D3D9Client.dll
Report Id: 67e1902c-7afa-4e6d-9f32-b50d2d007909
Faulting package full name:
Faulting package-relative application ID:

 

[kuddel]

Exception code 0xc0000005 usually indicates (a) memory access violation.
But whether it's caused by D3D9Client or OrbiterSound, or if it happened at D3D9Client rsp. OrbiterSound (due to be given a invalid memory address, for example) is not clear.

As you can reproduce this "so nicely": Is there any other addon that is running in all those instances?

 

[DaveS]

I have been doing some experiments with existing atmosphere renderer, in a bid to get the best look overall. So far all my experiments have confirmed this, that the best solution for now is to tie horizon haze color and intensity to the actual solar angle. All my experiments have shown that the atmospheric color should start low (currently for Earth that is -1.500) and as the sun gets higher in the sky, the horizon color should track it at a specified rate to a specified maximum (for Earth that should be 0.5).

If this could be implemented with the current atmosphere renderer, it would be great.

 

[Mr. Residuals]

All my experiments have shown that the atmospheric color should start low (currently for Earth that is -1.500) and as the sun gets higher in the sky, the horizon color should track it at a specified rate to a specified maximum (for Earth that should be 0.5).

So basically that means like in the D3D9 Atmosphere Controls it should look like this right for the Horizon thing.: (See photo below)


In terms of the appearance, it should look like what is shown below, right?
(Here's the photo)

 

[DaveS]

Try the config files in the attached archive. Just extract it into Orbiter folder and overwrite the original files.

 

[jarmonik]

I have been doing some experiments with existing atmosphere renderer, in a bid to get the best look overall.

Could you post the modified shader ?