New Release D3D9Client Development

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
One thing about the new metalness shader I'm noticing is that if I'm using a normal map, some parts can become transparent from certain angles...
Does this problem still exists in 4.16 ? Or is the report from older version ?
 

igel

Addon Developer
Joined
Mar 28, 2008
Messages
252
Reaction score
119
Points
43
Website
www.pin-plus.ca
Guys, I have a question regarding some change of viewing specular materials in internal/external view sometime between R14 and R16-5. Yes, that far back.

When I discovered that Vostok's internal reflective surface (in VZOR device) does work in cockpit view in 2010 but not in 2016, I thought there was a big time frame in between to trace that change. However, thanks to Nikogori, we've now narrowed this change down - back to 2010 era, between R14 and R16_5 (latest version for 2010).

Initially I left this request for later, but now this much narrower timeframe makes it easier to find and review, if possible. Was it an accident, that can be fixed? Was it intentional (like, heavy on performance and no one is using it anyway?) I don't know, I don't follow D3D9 code history. But, if it is found, and if it is an easy fix and does not hurt anything - Vostok will hugely benefit from it in 2016. I don't ask to fix it in 2010, as it is always easier to simply downgrade to R14 in 2010, if needed.

Here is the post that illustrates the problem very well (first two photos) in R16_5 in 2010 (exactly the same happens in any client version in 2016). The circular conic mirror is rendered reflective when seen through the window from outside - but is just an empty material when inside cockpit.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
Another issue with the new metalness shader, the ODS isn't lit up by the PLB flood lights for whatever reason.
This issue is still open I'm afraid:
 

Attachments

  • D3D9Client_new_shader9B.jpg
    D3D9Client_new_shader9B.jpg
    1,001.2 KB · Views: 17

yitianetie

Member
Joined
Mar 24, 2020
Messages
50
Reaction score
18
Points
23
Location
Brittany
Hi,

I have discovered a small glitch with the last version (r1392) of the D3D9 client. I don't know if this bug already exists with previous versions.
Some base objects, especially launchpads, can be seen through the terrain textures and elevations. Otherwise, buildings seem to not be visible through elevation. I have attached a snapshoot with a far view from Brighton base.

Kind regards,
Etienne

1616629529505.png
 

fred18

Addon Developer
Addon Developer
Donator
Joined
Feb 2, 2012
Messages
1,666
Reaction score
100
Points
78
I don't know the capabilities of Spacecraft.dll or VesselBuilder if they can swap a texture.
I just randomly ran through this, I don't even know what you guys are discussing about, but for the sake of completion: yes VB has that specific capability, it's the texture swap event:

cheers guys
 

Nikogori

Donator
Donator
Joined
Mar 14, 2015
Messages
235
Reaction score
92
Points
43
Location
Osaka
Website
orbinautjp.github.io
When I discovered that Vostok's internal reflective surface (in VZOR device) does work in cockpit view in 2010 but not in 2016, I thought there was a big time frame in between to trace that change. However, thanks to Nikogori, we've now narrowed this change down - back to 2010 era, between R14 and R16_5 (latest version for 2010).

As far as I can tell, VZOR works in cockpit view with R14, but not in R15 or higher.
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
When I discovered that Vostok's internal reflective surface (in VZOR device) does work in cockpit view in 2010 but not in 2016, I thought there was a big time frame in between to trace that change. However, thanks to Nikogori, we've now narrowed this change down - back to 2010 era, between R14 and R16_5 (latest version for 2010).
I looked at the code and it looks like the reflections were disabled due to reasons I can't remember. Also there is a small problem that parts in a virtual cockpit should reflect the virtual cockpit interior by default not the exterior. So, we would need to implement multi reflections and some kind of a way to choose what viewpoint to reflect. Due to low workforce we need to prioritize what to implement.

If the vessel is controlled by it own DLL, then there is a custom camera interface that allows you to render a view of your choice to a texture that can be place where ever you want it.
 
Last edited:

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
Hi,
I have discovered a small glitch with the last version (r1392) of the D3D9 client.
That issue has existed from the beginning and there are no easy ways to fix it, it gets complicated. Since it's a very minor glitch fixing it is not worth the trouble.
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
This issue is still open I'm afraid:
I haven't had luck reproducing the issues with SSU_v4.2r2570. The client makes bounding sphere/light cone intersections check to evaluate which meshes are lit by which lights. And it looks like the checks fail. But if the old shader works then that shouldn't be the issue, the checks and the code are the same. Can you confirm that the old shader works ?
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
I haven't had luck reproducing the issues with SSU_v4.2r2570. The client makes bounding sphere/light cone intersections check to evaluate which meshes are lit by which lights. And it looks like the checks fail. But if the old shader works then that shouldn't be the issue, the checks and the code are the same. Can you confirm that the old shader works ?
The old PBR shader also fails now. The latest 5.0 revision can be obtained here: https://www.dropbox.com/s/rbzhm14zi19vsu7/SSU_v5.0r3273.zip?dl=0
I've attached a scenario which shows the problem as well.
 

Attachments

  • ODS_light_bug.zip
    4.7 KB · Views: 1

igel

Addon Developer
Joined
Mar 28, 2008
Messages
252
Reaction score
119
Points
43
Website
www.pin-plus.ca
I looked at the code and it looks like the reflections were disabled due to reasons I can't remember. Also there is a small problem that parts in a virtual cockpit should reflect the virtual cockpit interior by default not the exterior. So, we would need to implement multi reflections and some kind of a way to choose what viewpoint to reflect. Due to low workforce we need to prioritize what to implement.

If the vessel is controlled by it own DLL, then there is a custom camera interface that allows you to render a view of your choice to a texture that can be place where ever you want it.
I see, thanks for looking. The current Vostok implementation (that relies on R14 client) actually depends on internal cockpit BOT being rendered. But that's indeed far from universal. I was already thinking of custom camera mapping. But that's a longer project, not a quick fix. Plus, if I remember correctly, it was introduced in 2016, so won;t work in 2010. And addon still need to support both 2010 and 2016 in foreseeable future - so I try as much as I can to keep versioning ifdefs to the absolute bare minimum. I'll eventually fix it with cameras for 2016 - just not sure when.
 

N_Molson

Addon Developer
Addon Developer
Donator
Joined
Mar 5, 2010
Messages
9,271
Reaction score
3,244
Points
203
Location
Toulouse
And addon still need to support both 2010 and 2016 in foreseeable future

Honestly, why ? If all addons were 2016-only compatible, more people would switch to 2016. We now have a working solution for keeping vessels grounded (see Parking Brake MFD and code sample). 2016 has 3D terrain with collision detection. I'm sorry but 2010 is a retrogaming thing for me, we have to look forward. Backwards compatibility isn't a goal in itself.

We need more intuitive tools for 2016 yes, and Jarmo's client is a huge effort in that direction.
 

igel

Addon Developer
Joined
Mar 28, 2008
Messages
252
Reaction score
119
Points
43
Website
www.pin-plus.ca
There are at this point only two (or at least two, depending on how you look at it) show-stoppers for retiring my 2010 addons.

1. Ground views of launchpads. They have deep dugouts - and in 2016, anything "below 0 mark" is filled with ground texture. Recent flattening feature improved look and feel greatly, but dugouts are still outstanding - totally ruins visual impression. Taking off may be only 1% of the mission time - but it is the percent that most people are most familiar with from launch reports.

2. 2010 touchdown points behave really unpredictably. My collection now has over hundred(!) of individual vessels with config files with defined Orbiter 2010 TDPs. About 50% of them work the same in 2016. About half of the remaining vessels work "so-so" and the "other half" - don't work at all, no matter what I try. I have an item in my plan to add 2016-style touchdown points - but then I'll have to go back and set and test those for all 100 vessels! Quite a task to just reinstate something that already used to work... chances are I won't get to it until I figure out some way to script it.

These two are the biggest. There are a couple more smaller things - for which I know solutions, but which still have to be actually solved :). Like this Vostok/Vzor issue, or ground textures conversions (which are done for my areas to about 80% of my liking, with remaining 20%, unfortunately, following the universal 80/20 effort rule).

And another purely personal obstacle - it happens so that I currently have to do my development on a non-gaming machine. For 2016, every Orbiter launch takes sometimes almost a minute to load all ground textures. If you are, for example, tweaking some geometry or placement or those touchdown points - you have to launch scenario so often it becomes impractical. You start tinkering with your environment to try to speed it up instead of thinking of what you are working on. So things are much easier done in 2010 first, then, when all is done, tested in 2016 (and, when it gets really intense, on a better machine).
 

N_Molson

Addon Developer
Addon Developer
Donator
Joined
Mar 5, 2010
Messages
9,271
Reaction score
3,244
Points
203
Location
Toulouse
Try this, it should greatly help you with the #2 issue. There's even the code samples with it (thx again @asbjos)


The issue #1 is quite interesting and I never thought about it. What we need is a convenient heightmap editor, many people have issue with those.

And another purely personal obstacle - it happens so that I currently have to do my development on a non-gaming machine. For 2016, every Orbiter launch takes sometimes almost a minute to load all ground textures. If you are, for example, tweaking some geometry or placement or those touchdown points - you have to launch scenario so often it becomes impractical. You start tinkering with your environment to try to speed it up instead of thinking of what you are working on. So things are much easier done in 2010 first, then, when all is done, tested in 2016 (and, when it gets really intense, on a better machine).

Well I wouldn't try to develop add-ons for say Fallout 4 (2015) on a 2010 machine. For such frequent big textures load you need a SSD, it helps drastically.
 
Last edited:

igel

Addon Developer
Joined
Mar 28, 2008
Messages
252
Reaction score
119
Points
43
Website
www.pin-plus.ca
Try this, it should greatly help you with the #2 issue. There's even the code samples with it (thx again @asbjos)


The issue #1 is quite interesting and I never thought about it. What we need is a convenient heightmap editor, many people have issue with those.



Well I wouldn't try to develop add-ons for say Fallout 4 (2015) on a 2010 machine. For such frequent big textures load you need a SSD, it helps drastically.
For dugouts - I don't think any elevation editing will solve the problem. Launchpad "landscapes" in my case are all artificially and sharply shaped constructs, not smooth natural features. There are even underground silos with fully vertical walls. Their accuracy goes down to a meter or even a few centimiters. Elevation maps just don't have this degree of accuracy especially with possible variable elev level sspecified. Also, there is some lock-in effect for launchpads: there are hundreds of small objects placed around them and on them, all carefully elevated according to where they should be - over the flat Earth but relative to the pad terrain mesh. Even if I get a perfect down-to-centimiter elev map for the pad - I'll have to re-elevate every such object that falls within the new height. All that - in about 50 config files for surface bases (some are repeated 3-4 times for different historical periods of the pad evolution). Seems totally unrealistic unless scripted! But I don't think elev maps will ever be that precise to even start thinking about it - they are just not the tool intended for this job. Maybe easier to fix with rendering order, if only for special mesh flags, and excluding ground collision detection?

I'll check the parking MFD code, thanks for hinting - I already spotted it in yuor previous post and got curious. Interestingly, in 2010 code, I also have "glueing" code, as default Orbiter behavior on touchdowns was not desirable in most cases :). So it is already familiar problem to me, so I'd be happy to check out 2016 solution!

...Woluld be happy to try the SSD idea (thanks - did not think of it myself). Currently I only have SSD on my boot drive, and it has only ~30 GB left, textures folder in 2016 is already over that size. But at least this is "another problem with known solution", so even if solution is not immediate, it is within reach :).
 

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
Just a thought on @igel s "problem" about the elevation: Would a reversed approach be an option?
What I mean is: Your base configuration defines all the (relative) heights of all the assets (buildings, launch-pads, etc.) and the terrain adapts to that on an interpolation / extrapolation thing?
This is just an idea popping into my mind, so no request or something like that :)

and: ...we're currently in a very dynamic change-session already, so let @jarmonik do his things in his preferred order ?
 

igel

Addon Developer
Joined
Mar 28, 2008
Messages
252
Reaction score
119
Points
43
Website
www.pin-plus.ca
Just a thought on @igel s "problem" about the elevation: Would a reversed approach be an option?
What I mean is: Your base configuration defines all the (relative) heights of all the assets (buildings, launch-pads, etc.) and the terrain adapts to that on an interpolation / extrapolation thing?
This is just an idea popping into my mind, so no request or something like that :)

and: ...we're currently in a very dynamic change-session already, so let @jarmonik do his things in his preferred order ?
No, this option did not work. One simple example: some "objects" simulate fences around the pad. A single straight section of such fence can be hundreds of meters long. It is "made" of a single rectangular shape - very thin, only 2 meters high - but big dozens or hundreds of meters long. When such long section runs along the terrain - this terrain has to be absolutely flat. Even smallest hills or dips will screw the look.

Luckily, the "localized flattening" feature of the client solved this problem completely. The look of the bases went right away from total F to B+. So, the only problem now is that it can't be anything below A :). Because the better it looks (and tose look really good :) ), the more any remaining eyesores stand out and irritate you. Contrary, when you play with the rough models just one step above wireframe, you'll be a lot more tolerant to the glitches in the other areas of simulation.
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
I can publish a new version of the Client for Orbiter 2010 with the cockpit reflections re-enabled. Also, have you noticed the surface elevation checkbox in the visual options. It will make the earth a flat sphere. As for the O2016 I try to find some ways to get the reflection camera issues sorted out for the interior and exterior reflections. It would be nice to have a better vessel configuration file interface since the amount of data will likely increase a lot.

The current work priorities are:
1. TerrainToolKit and Metalness/Specular shader fixes
2. Reflection cameras
3. Engine exhausts and condensation effects

and: ...we're currently in a very dynamic change-session already, so let @jarmonik do his things in his preferred order ?

"dynamic change session" :unsure: ? I am not aware of anything been or being changed that would effect add-on compatibility. The whole idea of the new shaders was to enable a possibility to add a new features without breaking the behavior of older add-ons. Yeah, but the priorities do tend to change.

As for the engine exhausts and condensation effects, etc... we would probably need some kind of effect composer dialog with following entries:
  • Effect type selector (Engine exhaust, condensation effect, particle effect, reentry effect)
  • A way to assign textures to a specific slots
  • Set of sliders controlling various parameters (depending on effect type of course)
  • Somewhere on a bottom a spline/bezier curve control allowing user to edit how a variable is changing over time. And a Combobox to select the variable in question.
 
Top