# New ReleaseD3D9Client Development

#### kuddel

##### Donator
Donator
Have you linked with Orbitersdk\lib\gcAPI.lib ?
Apart from that, there are mainly 3 reasons why SetupCustomCamera would return NULL:
1. hSurf is NULL (I don't think this is the case here)
2. Config->CustomCamMode==0 (I don't think this is the case here, as you've checked that)
3. hSurf is not a 3DRenderTarget (Also, I don't think this is the case here)

#### jarmonik

Beta Tester
I'll write a better reply when I got more time available pretty soon. But have you called gcInitialize() ? Also, the gcSetupCustomCamera() is a part of an old API but of course it's still supported.

To use a new API you can write: (does not require any link libraries)
Code:
gcCore *pCore = gcGetCoreInterface();  // Defined in gcConst.h
if (pCore) {
pCore->SetupCustomCamera(....);
}
else {
// Running DX7
}

#### n72.75

Tutorial Publisher
Donator
This something I'm might be interested in using eventually for NASSP optics, but I have no idea how to do the implementation.

#### igel

But have you called gcInitialize() ?
No, I did not (know I have to call it) Will try later today, or, more likely, tomorrow. All other suggested things - checked them out, all look OK (lib is linked, CustomCamMode=1, etc.)

Second version of API - did not even see it before, also have to check it out...

#### Felix24

##### Active member
To keep the sun glint from disappearing completely at full smoothness, try this at line 285 of Metalness.fx:

float fD = GGX_NDF(dHN, lerp(0.01f, 1.0f, fRgh3));

#### igel

I'll write a better reply when I got more time available pretty soon. But have you called gcInitialize() ? Also, the gcSetupCustomCamera() is a part of an old API but of course it's still supported.

To use a new API you can write: (does not require any link libraries)
Code:
gcCore *pCore = gcGetCoreInterface();  // Defined in gcConst.h
if (pCore) {
pCore->SetupCustomCamera(....);
}
else {
// Running DX7
}
Two big thanks!
a) it was missing gcInitialize() indeed;
b) second interface is indeed cleaner.

Now, I hope for the answer to the second question, about the expected lifecycle of the internal mirrors in 2016 client.

#### igel

Now, I have a third question - about the vessel's Size value.

In Orbiter 2010, you can approach vessel pretty much indefinitely, regardless of what Size is set for it. In Orbiter 2016, Size is the hard limit - you cannot get your view any closer to the vessel than that. What's worse, the speed of view movement (with mouse wheel) is not linear when you are close to the Size limit, so when you start close, it takes forever to distantiate.

Is there a way to get to previous 2010 behaviour for that in 2016? I've checked and checked, experimented with Size and ClipRadius but did not find any client option or configuration or API.

#### jarmonik

Beta Tester
To keep the sun glint from disappearing completely at full smoothness, try this at line 285 of Metalness.fx:

float fD = GGX_NDF(dHN, lerp(0.01f, 1.0f, fRgh3));
Ok, Thanks. I'll commit the change to SVN. Have you made any progress with the heat effect ?

#### jarmonik

Beta Tester
Now, I hope for the answer to the second question, about the expected lifecycle of the internal mirrors in 2016 client.
Sorry, I don't know.

Metallic parts inside a virtual cockpit should reflect the cockpit interior by default. We should improve the existing mesh/visual editor/debugger so that it can handle reflection camera setups and would allow to bind a specified mesh groups to a specified reflections. After this modification is made the mirror you need would be officially possible.

Of course, one possibility is that we keep reflecting the exterior world by default at-least with the old shader. It's hard to say how it's going to work better from the implementation point of view before it's been implemented.

#### jarmonik

Beta Tester
In Orbiter 2010, you can approach vessel pretty much indefinitely, regardless of what Size is set for it. In Orbiter 2016, Size is the hard limit - you cannot get your view any closer to the vessel than that. What's worse, the speed of view movement (with mouse wheel) is not linear when you are close to the Size limit, so when you start close, it takes forever to distantiate.
Many have complained about that and I am not aware of any work-a-rounds. Camera behavior is part of the Orbiter. We can't override the camera behavior from the client side without causing lots of unintended side effects.

#### igel

Sorry, I don't know.

Metallic parts inside a virtual cockpit should reflect the cockpit interior by default. We should improve the existing mesh/visual editor/debugger so that it can handle reflection camera setups and would allow to bind a specified mesh groups to a specified reflections. After this modification is made the mirror you need would be officially possible.

Of course, one possibility is that we keep reflecting the exterior world by default at-least with the old shader. It's hard to say how it's going to work better from the implementation point of view before it's been implemented.
Good, thanks! I can then keep the current implementation for now, and simply document to use Beta client for this feature. At least for now. And concentrate on other things to fix. And can explore custom camera implementation at my leisure, without urgency.

#### igel

Many have complained about that and I am not aware of any work-a-rounds. Camera behavior is part of the Orbiter. We can't override the camera behavior from the client side without causing lots of unintended side effects.
I see. Well, another problem of changing a feature and causing side effects. :-(. In Orbiter 2010, camera was not tied to Size - so Size value choice for the vessel could be influenced by other, more subtle considerations. For example, for a 3-stage rocket, it often helps to select same Size for all stages (and even for payloads) to avoid camera/view jumping radically upon each separation. With same sizes, you get smoother visual experience through the flight. And, as stages get smaller, you just move the view closer manually - but only when you want it, on your conditions. But now single Size selected for the biggest stage prevents you from zooming in later.

Then, there is a lock-in effect. My full collection is now over 100 individual vessels. Tweaking Size value for each of them is daunting. But worse, I have about 500 scenarios - each carefully set for comfortable and pleasant initial camera placement. Changing Size for focused vessels will hopelessly screw these starting views.

I think, the only way for me is to address it programamtically, in the library. I already have a deferred sizing change after pilot ejection on Vostok, that I was already planning to make common for all vessels. Now I'll have to somehow protect initial scenario sizing and resize to a tweaked Size (or maybe Size2) at some convenient point later in simulation... or leave it fully to the user action (whenever he wants) by some key combination... We'll see - that's likely for later, not for the current installment. Except maybe for launchpads - I want to shrink their Size after launch saw they'll disappear from view faster.

#### Felix24

##### Active member
Have you made any progress with the heat effect ?
Yes! Still might need some tweaking, but here's the effect:

Line 173 & 174 in Metalness.fx:
if (gCfg.Heat) fHeat = saturate((tex2D(HeatS, frg.tex0.xy).g) - 1.0f + (gMtrl.specialfx.x * gMtrl.specialfx.x * gMtrl.specialfx.x)); else fHeat = (gMtrl.specialfx.x * gMtrl.specialfx.x * gMtrl.specialfx.x);

New lines starting at 343:
// Add heat glow float3 cHeat = float3(pow(abs(fHeat), 0.5f),pow(abs(fHeat), 1.5f),pow(abs(fHeat), 8.0f)); cDiff.rgb = cDiff.rgb + cHeat;

#### jarmonik

Beta Tester
Yes! Still might need some tweaking, but here's the effect:

That looks fantastic. Great work there.

#### DaveS

##### Space Shuttle Ultra Project co-developer
Donator
Beta Tester
That looks fantastic. Great work there.
Agree fully with this reply. Any chance of adding the wake effect that was actually seen by the crew through the forward windows? This a video from STS-114 that shows the Entry and landing through the Pilot Point of View (PLT PoV) camera, AKA HUD camera) so it shows the wake effect nicely as it was a night entry and landing at Edwards AFB after four scrubbed landing attempts at KSC (two the day before, August 8 2005 and two on the landing day, August 9 2005): https://www.dropbox.com/s/s58vqcv5t1wdvr9/STS-114-HUD-Entry.wmv?dl=0

The wake effect starts at 33:25.

#### Attachments

• STS114_HUDcam_entry.jpg
85.8 KB · Views: 15

#### DaveS

##### Space Shuttle Ultra Project co-developer
Donator
Beta Tester
Yes! Still might need some tweaking, but here's the effect:

View attachment 24830
View attachment 24831
View attachment 24832

Line 173 & 174 in Metalness.fx:
if (gCfg.Heat) fHeat = saturate((tex2D(HeatS, frg.tex0.xy).g) - 1.0f + (gMtrl.specialfx.x * gMtrl.specialfx.x * gMtrl.specialfx.x)); else fHeat = (gMtrl.specialfx.x * gMtrl.specialfx.x * gMtrl.specialfx.x);

New lines starting at 343:
// Add heat glow float3 cHeat = float3(pow(abs(fHeat), 0.5f),pow(abs(fHeat), 1.5f),pow(abs(fHeat), 8.0f)); cDiff.rgb = cDiff.rgb + cHeat;
Could you upload a sample package? I'd like to try this with SSU.

#### Felix24

##### Active member
The translucent glow through the forward windows is the re-entry plasma, and not heating on the orbiter's surface itself. I think it would need some custom effect modeling, either specific to the spacecraft itself, or an upgrade to the generic re-entry effects already provided by Orbiter.

If there could be a re-entry plasma mesh around the orbiter, that would be cool. And then you could control its material values based on dynamic pressure, velocity, etc. Something like the picture at the link below:

I got the heating map from this NASA paper on infrared observations of the Shuttle heat shield during re-entry:
https://ntrs.nasa.gov/citations/20120007110

For a more realistic Shuttle heat shield texture, we'd need to modify the Shuttle mesh to use a single dedicated heatshield texture, instead of loading only half of the heat shield and then mirroring it.

Here's a Dropbox link to the MGAtlantis_heat.dds that I am using.

#### DaveS

##### Space Shuttle Ultra Project co-developer
Donator
Beta Tester
If there could be a re-entry plasma mesh around the orbiter, that would be cool. And then you could control its material values based on dynamic pressure, velocity, etc. Something like the picture at the link below:
SSU actually has an entry mesh, it's called SSU_entry.msh. I've attached an archive that contains it and its texture.

#### Attachments

• SSU_entry.zip
1.4 MB · Views: 3

#### Felix24

##### Active member
Jarmonik, would it be possible to add a button to the D3D9 debug window that forces a reload of all of the vessel's textures? I don't know how easy that would be. But it would help a lot while doing texture development. I know VesselBuilder can do it after some configuration.

#### jarmonik

Beta Tester
Jarmonik, would it be possible to add a button to the D3D9 debug window that forces a reload of all of the vessel's textures? I don't know how easy that would be. But it would help a lot while doing texture development. I know VesselBuilder can do it after some configuration.

Yes, Texture reload modification commited to SVN.

I was also experimenting with the heat effect and came up with this, it's different but can't say if it's better or worse.
Code:
// Fetch Heat map
//
if (gCfg.Heat) {
float fH = (gMtrl.specialfx.x * gMtrl.specialfx.x * gMtrl.specialfx.x);
float iH = 1.0f / max(fH, 0.001f);
fHeat = pow(abs(tex2D(HeatS, frg.tex0.xy).g), iH) * pow(abs(fH), 0.02f * iH);
}
else fHeat = (gMtrl.specialfx.x * gMtrl.specialfx.x * gMtrl.specialfx.x);