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
How is the new exhaust system coming along? Or the reflection system?
I am currently working on the "Terrain Toolkit". I am adding a mesh and elevation import tools and some terrain flattening tools. I'll try to finish that before starting to work any other features.
 

4throck

Enthusiast !
Joined
Jun 19, 2008
Messages
3,502
Reaction score
1,008
Points
153
Location
Lisbon
Website
orbiterspaceport.blogspot.com
Terrain editing is very much welcome, but the current terrain seams bug is pretty nasty.
I know it's not your fault but it got worse today after updating Nvidia drivers.
I just tried the Alps 2016 scenario and the black seams become visible as soon as the terrain loads....
 

clipper

Well-known member
Joined
Feb 27, 2018
Messages
256
Reaction score
388
Points
63
The lens flare should be re-implemented. Personally I don't really like it due to being too bright and large. Also, it's mathematically heavier that everything else we have all together. With the time used for that effect we could have SSAO running. Also, the sun and other light sources are usually visualized as sharper and spikier not as a smooth "flowers". I suppose we could use simple textures for flares and glares. and some math to control size and intensity. That's what most games do.
I played around a little bit with the LensFlare.hlsl file some time ago and ended up removing the diffraction spikes altogether and thought it looked really good IMO to the point where i just replaced the usual sun texture (Star.dds) with a blank transparent one (not really viable beyond the asteroid belt region tho as it pretty much disappears altogether at that distance unlike the standard sun texture).

LensFlareC.png

One minor thing i'd like to point out tho for future reference is that the current lens flare implementation has this somewhat contrary effect on the stars as well as the celestial sphere background where they both seem to be considerably brighter when they're overlaid by any of the lens flare elements; but then again i'm completely ignorant on how this would actually behave in reality so it might just be a misconception on my behalf.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
I played around a little bit with the LensFlare.hlsl file some time ago and ended up removing the diffraction spikes altogether and thought it looked really good IMO to the point where i just replaced the usual sun texture (Star.dds) with a blank transparent one (not really viable beyond the asteroid belt region tho as it pretty much disappears altogether at that distance unlike the standard sun texture).

View attachment 26091

One minor thing i'd like to point out tho for future reference is that the current lens flare implementation has this somewhat contrary effect on the stars as well as the celestial sphere background where they both seem to be considerably brighter when they're overlaid by any of the lens flare elements; but then again i'm completely ignorant on how this would actually behave in reality so it might just be a misconception on my behalf.
It is just too smooth, it looks more like a comet than a star. I have attached three photos of the sun taken during various ISS and shuttle missions.
 

Attachments

  • s125e012372.jpg
    s125e012372.jpg
    71.4 KB · Views: 20
  • sunearthpanel_sts129_big.jpg
    sunearthpanel_sts129_big.jpg
    83.4 KB · Views: 20
  • 36497504031_24c6270d62_b.jpg
    36497504031_24c6270d62_b.jpg
    37 KB · Views: 17
Last edited:

dgatsoulis

ele2png user
Donator
Joined
Dec 2, 2009
Messages
1,924
Reaction score
340
Points
98
Location
Sparta
I have been using the terrain flattening feature lately with pretty good results, combined with astrogull's ElvTile Splitter.
I was wondering though, is it possible to set the elevation of an area, without having it rendered?
It might be handy for creating elevated platforms, or bases that hang on the edge of a cliff or even bridges that one can walk on (just don't try to go under it).
 

n72.75

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,687
Reaction score
1,337
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
New "stable" Build for Orbiter 2016 is available
New build for Orbiter Beta is also available


I haven't done much testing with Orbiter Beta due to limited time, so, it might be good idea to run some tests with the Metalness shader to see if everything is working properly.
I'll give Orbiter Beta a thorough test with the update and make sure it doesnt break anything in NASSP.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
Quick Q: What does SHADOW_THRESHOLD in Common.hlsl do? Currently it is set to 0.1 but the comment suggests the lowest limit is 0.3 and the highest limit is 7.0.
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
Terrain editing is very much welcome, but the current terrain seams bug is pretty nasty.
I know it's not your fault but it got worse today after updating Nvidia drivers.
I just tried the Alps 2016 scenario and the black seams become visible as soon as the terrain loads....
Due to nature of the problem I can't imagine how a driver update could make things worse. Does there exists a version of the client where the seams won't exists ? I tried revision 787 which is the oldest we got for Orbiter 2016 (September-2016) and it did have the seams. As far as I can remember the seems have been there.

You can reduce the seams by moving the "Texture Bias" slider higher but it comes with a performance cost.
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
Quick Q: What does SHADOW_THRESHOLD in Common.hlsl do? Currently it is set to 0.1 but the comment suggests the lowest limit is 0.3 and the highest limit is 7.0.
If I recall it should set the threshold where vessel self shadows appear. The math that controls the shadows may have changed and the comment is outdated.
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
I was wondering though, is it possible to set the elevation of an area, without having it rendered?
Possible but problematic. We should have an official way to do something like that. Client side hack doesn't sound like a good idea. It's getting too messy. Lot of things are already too messy.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,877
Reaction score
2,869
Points
188
Website
github.com
In todays Orbiter source code dive I found information on all the mesh flags that MOGE uses, and maybe the D3D9 folks could take a look and implement some (or all) of them. It all begins in file Mesh.cpp:958, where the mesh file is parsed.
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
We probably should create a branch for Orbiter r.90 and repurpose the trunk for Orbiter x64. I tried to compile the client as x64 and the amount of errors was much less than I feared.
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
We probably should create a branch for Orbiter r.90 and repurpose the trunk for Orbiter x64. I tried to compile the client as x64 and the amount of errors was much less than I feared.
Replacing the libs, casting DLGPROC and refactoring the CPU context logging was all I had to do (besides adding an x64 target, of course). Very well crafted code-base!
 

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
Unfortunately I can not get enough time to work on this as I would like to....
But here's the changes I've made to the D3D9Client (2016.branch based).
You might take a look if these fit your changes. A proper merging is beyond my time limit unfortunately. But I try to sneak some time in.

Regarding "branching for r90" and make 'trunk' the main x64 development branch: It's fine with me. Should we name the branch "2016-P1"[*] "2019"[**] ?

[*] calling it "something BETA" seems odd now ;)
[**] "2019" would be appropriate as r90 was from September 14th 2019
 

Attachments

  • D3D9Client.x64.zip
    793 KB · Views: 4
Last edited:

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
I've created the '2019' branch (svn://mirror.orbiter-radio.co.uk/D3D9client/branches/2019) so 'trunk' might become the main x64 development place.

But his means that we "break" existing working copies out there, referencing 'trunk' which expect it to be for 32-bit Orbiter BETA!
Those will update and suddenly have a complete mess on their working-copy....
Only if they know that this happened and they switch to the new branch before doing an update will they prevent pain!

It might be better to do the x64 development in a branch. This way we don't break already checked-out working copies.

Nothing has changed on 'trunk' yet, so we can still go any direction.
 

dbeachy1

O-F Administrator
Administrator
Orbiter Contributor
Addon Developer
Donator
Beta Tester
Joined
Jan 14, 2008
Messages
9,214
Reaction score
1,560
Points
203
Location
VA
Website
alteaaerospace.com
Preferred Pronouns
he/him
We could also do the x64 build using #ifdef's and #typedef's to keep the changes all in the same branch (that's how we did it at work in a previous life) so we don't have to constantly merge two branches to keep changes in sync. But either way would work.
 
Top