New Release D3D9Client Development

[Marg]

Just started to think is there a way to make water less transparent? Looking from KSC - away from the sun (so no reflections) water seems dirty greenish, etc... it is depicted in tiles this way...

 

[jarmonik]

Just started to think is there a way to make water less transparent? Looking from KSC - away from the sun (so no reflections) water seems dirty greenish, etc... it is depicted in tiles this way...

Probably, but if the water is less transparent then it would need to have a color (and that's not a constant). Right now the color comes from the background texture like you said. Are you saying that water color in the tiles is incorrect ? I suppose it would should be possible to shift it a bit towards a cleaner blue but is that correct ?

EDIT: Hmmm.. Maybe the problem is how much light the texture receives through the water.

 

[jarmonik]

Just started to think is there a way to make water less transparent? Looking from KSC - away from the sun (so no reflections) water seems dirty greenish, etc... it is depicted in tiles this way...

I played around with water setting. It's possible to tune it so that the dirt looks like floating but it's probably not any better. The dirty greenish color is real as far as I can tell so I leave it be as it is at-least for now.

 

[jacquesmomo]

Hello

So I have a problem ...(with my add-on Kourou-CSG)

Since the latest version of D3D9 (D3D9ClientR4.7-forOrbiter2016 (r1335)
my Kourou track is in the air: (bottom image)

With the previous version (D3D9ClientR4.4-forOrbiter2016 (r1306)
everything was fine (top image)

 

[kuddel]

That should not happen.

Can you try selecting "linear interpolation" vs. "cubic interpolation" in the Visual effects tab? This might help.



I know this is not a solution, but maybe a work-around

 

[jacquesmomo]

Ah yes ! thank you very much: that solves the problem

 

[4throck]

May I ask for this https://www.orbiter-forum.com/threads/area-flattening-experiment-success.37074/post-570818 to be incorporated into the official D3D9 ?

Local terrain flattening defined by configs is well suited for addons covering small areas.
Editing the entire terrain tree is overkill when you just want a few meters of flat terrain to land or to place a landed mesh.

I don't see any undesired side effects, or any compatibility problems. It would only work on the client, but we already have some client only features (ex: microtextures) so I don't think that's a problem.

 

[llarian]

Just to add my two cents worth ... I agree on 4throck on this one. I believe it needs to be added. It is a very useful tool.

 

[jarmonik]

There is a new build 4.8 uploaded with this feature (for Orbiter 2016). I guess that the code hack wouldn't work with beta. I haven't done any extensive testing but it did create a flat circle on the moon, so, I guess it's working.

- There is on/off toggle in the setup/config dialog.

 

[Face]

Thanks for putting it in. I remember that the hooking failed in beta Orbiter versions, but if there is a specific version that most people use, I can try to check the numbers for that as well. I don't think that the code changed significantly at that position, only the absolute addresses might be off.

 

[4throck]

There is a new build 4.8 uploaded with this feature (for Orbiter 2016). I guess that the code hack wouldn't work with beta. I haven't done any extensive testing but it did create a flat circle on the moon, so, I guess it's working.

- There is on/off toggle in the setup/config dialog.

Thank you ! I'll try to put together a some test scenarios so that we are all looking at the same place

 

[gattispilot]

So got a question about reflections. I have the reflector of the shuttle set to reflect. But it seems it reflects the back side. If you have the reflectors shut in the shuttle. It really should reflect the inside. But it reflects the outside

 

[DaveS]

So got a question about reflections. I have the reflector of the shuttle set to reflect. But it seems it reflects the back side. If you have the reflectors shut in the shuttle. It really should reflect the inside. But it reflects the outside

Are you talking about the radiator panels? If so, in order for them to reflect the interior properly, you need to have the following in config file named whatever the class name of your vessel is with the suffix _ecam in the Config/GC subfolder:

BEGIN_CAMERA 0
LPOS 0.0 0.0 0.0
DO_NOT_OMIT_FOCUS
END_CAMERA

So, since the class name for SSU is SpaceShuttleUltra, the name for the config file is "SpaceShuttleUltra_ecam.cfg". But then you get this since D3D9Client only uses one source for the reflections: https://www.orbiter-forum.com/threads/d3d9client-development.16787/post-262882

 

[4throck]

Here's a test scenario for terrain flattening.

https://drive.google.com/file/d/1OGMt5uo-1Jhyb2C-EVaNop9K1xqBjj3q/view?usp=sharing

It requires VesselBuilder for the landed mesh of Mars Pathfinder and surrounding area.
The lander displays as expected centered on the flattened area (if used with moderation flattening can be is seamless).

I added a DG to test driving around and the logical terrain drops of quite fast, not following the visual display.
Yet at the center the DG does climb into the flat area.



Other than that is seems to work!
The pathfinder mesh is free to use for more tests or to include on the D3D9 package as an example.

 

[Face]

I added a DG to test driving around and the logical terrain drops of quite fast, not following the visual display.
Yet at the center the DG does climb into the flat area.

Other than that is seems to work!

It would be interesting to see how it is without the flattening. Would the DG then stay level with the visual terrain? What happens if you change the falloff percentage towards zero?

I noticed that the implementation changed to use float instead of integer for the visual part. Perhaps this is affecting the visual vs. logical relation.

 

[kuddel]

Thanks for putting it in. I remember that the hooking failed in beta Orbiter versions, but if there is a specific version that most people use, I can try to check the numbers for that as well. I don't think that the code changed significantly at that position, only the absolute addresses might be off.

Revision 90. It's from September 14th 2019, so 'kind of stable and people using the BETA would always take the HEAD revision (which is rev. 90).

 

[jarmonik]

I looked into that and found some problems:

Ellipse -3659 -33.220001 19.129999 2000 2000
Xllipse -6182 -33.220001 19.129999 200 200  0 50

The elevation -6182 ? Where is this coming from ? Isn't the -3659 more correct ?

Since there are no high resolution tiles, the physics engine doesn't go any higher than the highest available tile resolution which is 9 if I recall. At that resolution 200m circle is too small to be meaningful.

I have also detected some issues with int16 to float conversion... will look into it tomorrow.

 

[jarmonik]

Ok, here's new build. Does this work any better ? BTW, check that "linear interpolation" is selected. The "cubic" doesn't work.

 

[Face]

Revision 90. It's from September 14th 2019, so 'kind of stable and people using the BETA would always take the HEAD revision (which is rev. 90).

I have checked that binary and found the hook point again. However, the implementation changed from using the ALU to MMX registers, so I need to refactor the trampoline code a bit. Other than that it shows the same structure, so chances are good that it will work with the beta as well. Would be nice to have a proper callback there, though. The FilterElevation signature is a good starting point, I think.

 

[4throck]

Ok, here's new build. Does this work any better ? BTW, check that "linear interpolation" is selected. The "cubic" doesn't work.

Thanks!
Some test results:

» Changed elevation to -6172 to make the flat area more visible (about 10 meters higher than the existing terrain). Slight adjustment to Pathfinders's location.
Correct visual altitude at the center of the area, incorrect visual as you move off center (drop off).



» Changed falloff from 50 to 100.
Displayed terrain above the logical terrain.



» Changed falloff to 0. Slight adjustment to Pathfinders's location.
Same as the first test. Correct visual altitude at the center of the area, incorrect visual as you move off center (drop off).




The mismatch seems to be affect displayed terrain only.
On all cases the DG drives around the same: climbs to center of the raised area, then drops gently. No noticealbe change to computed terrain when I changed falloff.

I understand that tile level (resolution) might be a factor here. Will test with larger ellipses.


__________________________________________________________________________________________________


» Changed syntax to Ellipse -6172 -33.220001 19.129999 2000 2000 (are drop off and angle values not used ?)
Good match between visual and computed altitude (DG is at the edge of the ellipse, Pathfinder is in the distance to the right)!
Works as expected




PS: -6172 is the altitude in meters, shown on the DG MFDs