New Release D3D9Client Development

SolarLiner

It's necessary, TARS.
Addon Developer
Joined
Jun 14, 2010
Messages
1,847
Reaction score
2
Points
0
Location
404 ROAD NOT FOUND
I can do that. Here's the Earth viewed from Cupola. Now, what's wrong in it that could be fixed with tonemapping ?

Because HDR isn't really implemented yet, there's nothing really wrong that could be corrected with tonemapping. But the problem is that right now everything is "faked" to be correctly exposed and look more or less good. To achieve results like in the photo, we'd need to have a more physically based approach to it than just using 20 years old techniques to get out a forward rendering engine. Maybe having a deffered pipeline would help? I have actually no idea here, and there really isn't any walkthrough tutorial that would explain the process to get to a solid implementation of a HDR graphics engine.

But if we want to get a more realistic render of our simulated universe, I believe that PBR and HDR are the two ways to go.

---------- Post added at 11:16 ---------- Previous post was at 11:13 ----------

I'd add too that I really want to help in getting towards that goal of PBR/HDR, but after taking a look at the client code I didn't really get the spirit of how things worked together. But that didn't stop me from making several local versions of the code to try things, that all didn't work. /:
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
Because HDR isn't really implemented yet...

What makes you think that ? And what would make it implemented ? There are some details those aren't implemented in HDR yet but the Earth and the meshes are pretty well in HDR. Although, it is normalized so that white plain diffuse surface lit by direct sunlight equals 1.0f by it's illuminance. That works as a point of reference for everything else. Sunlight reflection from a reflective metallic/fresnel surface can go up to 3.14f (Should be verified if that's actually what it should be)

But the problem is that right now everything is "faked" to be correctly exposed and look more or less good....

There are a few things like the celestial sphere background images those are faked and the Earth surface brightness on a cloudy day is likely too high and there are no easy ways to change that. I am not exactly aware of anything else being faked.

To achieve results like in the photo...

We would need high quality models and textures with accurate material specifications, shadows. Next in-line could be ambient occlusion and irradiance and possibly some level of tonemapping to tweak the balance between highlights and shadows.

Maybe having a deffered pipeline would help?
No, it won't.

I'd add too that I really want to help in getting towards that goal of PBR/HDR, but after taking a look at the client code I didn't really get the spirit of how things worked together. But that didn't stop me from making several local versions of the code to try things, that all didn't work. /:

That sounds too familiar. A while back I spend a lot of time to implement a geometry instancing in a hope of +200% frame rate gain but in a reality it merely reduced it. Had to scrub it. Just a few weeks ago I tried rendering local lights in a pixel shader and it did not work as expected. Had to scrub it too. Lot of work wasted. Most things related to GPU computing aren't easy and that's why we are lacking a lot of features those would be nice to have like shadows. Not giving up and taking one thing at a time then maybe one day we have shadows.
 

SolarLiner

It's necessary, TARS.
Addon Developer
Joined
Jun 14, 2010
Messages
1,847
Reaction score
2
Points
0
Location
404 ROAD NOT FOUND
There are a few things like the celestial sphere background images those are faked and the Earth surface brightness on a cloudy day is likely too high and there are no easy ways to change that. I am not exactly aware of anything else being faked.

You just said right before this that the sunlight is normalized. It shouldn't be. The graphics engine should be able to diffuse as much light as necessary, and it is with exposure control and tonemapping that the scene gets correctly rendered to the screen. Even if the intensities and numbers are more or less guesswork. Say the sun has an intensity of 30, and from there multiply this diffuse value by the albedo to get the relative intensities of the diffuse reflections of every object in the scene. That would mean having a pretty bright image that would need to be toned down quite a bit, but it would be less fake than having a normalized sun light intensity.

But after that, getting a full and solid HDR/PBR implementation would mean rewriting the core with the newer rendering techniques in mind, I'm afraid. I guess I could try, but I don't have even the 1/1000th of D3D knowledge that you have.
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
It shouldn't be.

Based on what facts ?


The graphics engine should be able to diffuse as much light as necessary, and it is with exposure control and tonemapping that the scene gets correctly rendered to the screen.

Conversation of energy, surface can't reflect more light than it receives. In current implementation it receives 3.14 units from where a maximum diffuse surface intensity is 1.0.

If we would have a dark cave then the intensity range in that cave would likely be around 0.0 and 0.02, which would need to be tonemapped closer to 1.0 to make it a practical for the display.

Even if the intensities and numbers are more or less guesswork. Say the sun has an intensity of 30....

The mean distance of the Earth from the Sun is one astronomical unit [AU]. It's simple and accurate, no guess work required. This case is pretty much like arguing that distance should be let's say 30 units or so, to be mathematically valid or enough.
 

4throck

Enthusiast !
Joined
Jun 19, 2008
Messages
3,502
Reaction score
1,008
Points
153
Location
Lisbon
Website
orbiterspaceport.blogspot.com
The important thing is to remain compatible with the current models+textures, while supporting more advanced materials (and with that necessarily a higher dynamic range).

Until he have proper terrain»mesh and mesh»mesh shadows, thinking about exposure compensation or transfer function for those cases is just theoretical. :hmm:

So don't loose much time with that for now.



I've been thinking that planet textures also need to have their reflection and roughness maps.
The data exists for roughness (at least for Mars and the Moon) and reflection can be derived from geology.
 

SolarLiner

It's necessary, TARS.
Addon Developer
Joined
Jun 14, 2010
Messages
1,847
Reaction score
2
Points
0
Location
404 ROAD NOT FOUND
Based on what facts ?

That distance affects the intensity received. Mercury is way more lit than Saturn is. It isn't receiving 1 unit of light on both cases. It appears to, though, because our eye is adapting.

Conversation of energy, surface can't reflect more light than it receives. In current implementation it receives 3.14 units from where a maximum diffuse surface intensity is 1.0.

But sun light intensity is still 1.0, which would means that diffuse intensity is the same as direct light, and that specular light intensity is greater than direct light intensity?

If we would have a dark cave then the intensity range in that cave would likely be around 0.0 and 0.02, which would need to be tonemapped closer to 1.0 to make it a practical for the display.

That's exactly how it would work... for eye adaptation. Tonemapping takes a high dynamic range and "converts" it to a low dynamic range. Eye adaptation changes the exposure to best show the scene. Both are independent and could work together, but can be used separately.
But this is how post-processing would behave in general.

The mean distance of the Earth from the Sun is one astronomical unit [AU]. It's simple and accurate, no guess work required. This case is pretty much like arguing that distance should be let's say 30 units or so, to be mathematically valid or enough.
That's actually a good scale to take here. As long as distance attenuation is implemented then sure, it's actually a great scale because it still leaves our assumptions correct while correcting for the distance still accurately.
 

4throck

Enthusiast !
Joined
Jun 19, 2008
Messages
3,502
Reaction score
1,008
Points
153
Location
Lisbon
Website
orbiterspaceport.blogspot.com
Some experiments with Moon textures (small sphere in LEO of course).
I'm using a reflection map based on surface roughness and a real albedo map with no shadows.

There are many problems due to uncalibrated textures, but it's a step on the right direction. Earthshine is there, and the light falls on the surface just right.

View attachment 14520View attachment 14521View attachment 14522
The last image looks quite HDR to me. Sun to shadow, all with visible details ;-)


One useful possibility would be for the material editor to work on textured meshes.

As it is, I can set the values if I don't supply the extra textures, but once they are there, I can't change them.
A nicer approach would be to offset or multiply the texture values by editor's amount.
 
Last edited:

SolarLiner

It's necessary, TARS.
Addon Developer
Joined
Jun 14, 2010
Messages
1,847
Reaction score
2
Points
0
Location
404 ROAD NOT FOUND
Until he have proper terrain»mesh and mesh»mesh shadows, thinking about exposure compensation or transfer function for those cases is just theoretical. :hmm:

So don't loose much time with that for now.

I actually have to agree here. I think shadows are more important here.
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
The important thing is to remain compatible with the current models+textures, while supporting more advanced materials

Yes, that's the biggest headache we have. Implementing something new while maintaining compatibility with old models can make thing a bit tricky and chaotic.

Here's a new build, should fix a few issues, not much new there.
 

Attachments

  • D3D9ClientBeta23_8-forRev55.zip
    1.8 MB · Views: 37

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
A nicer approach would be to offset or multiply the texture values by editor's amount.

It was originally implemented that way, but due to some opposition the feature received, I decided to removed it. So, values comes from material or from a textures but not from both.

It could be possible to have a debugger mode that would allow to fine tune the textures from a material editor, but then the correction factors would need to be applied to textures themselves to allow them to run without debug mode.

---------- Post added at 22:58 ---------- Previous post was at 22:43 ----------

Tonemapping takes a high dynamic range and "converts" it to a low dynamic range.

I suppose that might work to increase the display range by 25-50% in some cases if done properly but pushing it too far will result a fake image where the sense of reality is lost like in this fake:

Old_saint_pauls_1.jpg


What kind of whether is outside ?
How dark is the room exactly ?
Isn't the contrast kinda low ?

---------- Post added at 23:03 ---------- Previous post was at 22:58 ----------

But sun light intensity is still 1.0, which would means that diffuse intensity is the same as direct light, and that specular light intensity is greater than direct light intensity?

Not exactly, but I have reorganized the variables to make them less confusing.

---------- Post added at 23:14 ---------- Previous post was at 23:03 ----------

That distance affects the intensity received.

True, but it still needs to be mapped to screen space with an inverse of that to get a well visible image. Only thing that is actually effected by distance is the intensity of local lights compared to sunlight.
 

DaveS

Addon Developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
9,429
Reaction score
680
Points
203
It was originally implemented that way, but due to some opposition the feature received, I decided to removed it. So, values comes from material or from a textures but not from both.

It could be possible to have a debugger mode that would allow to fine tune the textures from a material editor, but then the correction factors would need to be applied to textures themselves to allow them to run without debug mode.

---------- Post added at 22:58 ---------- Previous post was at 22:43 ----------



I suppose that might work to increase the display range by 25-50% in some cases if done properly but pushing it too far will result a fake image where the sense of reality is lost like in this fake:

Old_saint_pauls_1.jpg


What kind of whether is outside ?
How dark is the room exactly ?
Isn't the contrast kinda low ?

---------- Post added at 23:03 ---------- Previous post was at 22:58 ----------



Not exactly, but I have reorganized the variables to make them less confusing.

---------- Post added at 23:14 ---------- Previous post was at 23:03 ----------



True, but it still needs to be mapped to screen space with an inverse of that to get a well visible image. Only thing that is actually effected by distance is the intensity of local lights compared to sunlight.
Is an iris behavior implemented? Currently the amount of light is fixed due to the lack of a proper iris behavior implementation. This could go under the title of Automatic Lighting Control.
 

4throck

Enthusiast !
Joined
Jun 19, 2008
Messages
3,502
Reaction score
1,008
Points
153
Location
Lisbon
Website
orbiterspaceport.blogspot.com
It could be possible to have a debugger mode that would allow to fine tune the textures from a material editor, but then the correction factors would need to be applied to textures themselves to allow them to run without debug mode.

All I need is to preview how the texture values need to be changed / what's the result of a change.
Admitting that we are using non-ideal textures (compatibility, etc, etc) just using values from material charts won't do, so we need to see how things look in Orbiter :thumbup:

But I don't need the values or textures to be saved :) let's keep it simple!
 

4throck

Enthusiast !
Joined
Jun 19, 2008
Messages
3,502
Reaction score
1,008
Points
153
Location
Lisbon
Website
orbiterspaceport.blogspot.com
Last edited:

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
Is an iris behavior implemented? Currently the amount of light is fixed due to the lack of a proper iris behavior implementation. This could go under the title of Automatic Lighting Control.

Not yet. I'll look into it, let's see what I can figure out.

---------- Post added at 22:51 ---------- Previous post was at 22:39 ----------

The results in Orbiter are more subdued than viewing the same model in Sketchfab.

Sketchfab could be using RGB for reflection/specular color instead of sRGB or it's could be due to different shading technique like "Ward" instead of "Phong". "Ward" is currently disabled from D3D9, only "Phong" is in use.

If using sRGB then the reflectivity of the solar panels is out of scale according to the material values chart

---------- Post added at 22:56 ---------- Previous post was at 22:51 ----------



Also the backside roughness is very rough like a "brick". Close to a diffuse only material.

I'll try to implement the tuning controls for textures. That should make it easier to test textures. Being able to see the effect in realtime.
 

4throck

Enthusiast !
Joined
Jun 19, 2008
Messages
3,502
Reaction score
1,008
Points
153
Location
Lisbon
Website
orbiterspaceport.blogspot.com
jarmonik, Thanks for that (being able to see the effect in realtime).

I actually think that your implementation is the correct one.

But from all that we discussed above (LDR, HDR, etc) there will always be some artistic license to make the materials look "better".
Specially if we are using (for compatibility) an "albedo" map that's just a regular texture. That one is certainly not normalized, has shadows etc.


Anyway, I what to stress that the current support for PBR is good, and fits well with the existing modeling+texturing pipeline and retains backward compatibility.
:cheers:
 

Hlynkacg

Aspiring rocket scientist
Addon Developer
Tutorial Publisher
Donator
Joined
Dec 27, 2010
Messages
1,870
Reaction score
3
Points
0
Location
San Diego
The mean distance of the Earth from the Sun is one astronomical unit [AU]. It's simple and accurate, no guess work required.

The problem with normalized sunlight is that as far as the inline client (and as far as I know this one as well) is concerned The mean distance of Jupiter from the Sun is also one astronomical unit which is simple but a whole lot less accurate.
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
The problem with normalized sunlight is that as far as the inline client (and as far as I know this one as well) is concerned The mean distance of Jupiter from the Sun is also one astronomical unit which is simple but a whole lot less accurate.

Not really. Have a piece of white paper and expose it to a direct sunlight and then call it's illuminance a 1.0, a reference value. Describe everything else relative to that. I guess it should be pretty accurate everywhere.
 

4throck

Enthusiast !
Joined
Jun 19, 2008
Messages
3,502
Reaction score
1,008
Points
153
Location
Lisbon
Website
orbiterspaceport.blogspot.com
I don't think we would like a grey Jupiter. :hmm:
So I agree that white paper should be 1.0 regardless of location.

That being said, it's the sun sprite that could be brighter/darker depending on location :hmm:
 

Cras

Spring of Life!
Donator
Joined
Apr 13, 2011
Messages
2,215
Reaction score
0
Points
36
Location
Los Angeles
Website
www.youtube.com
I made two hours long test run at LEO at 10x acceleration and I experienced a frame rate drop form 1200 fps to 600 fps. It looks like surface tiles aren't unloaded from memory after they become obsolete. In my case there was 200MB of unnecessary tiles loaded, not a problem really but with a high resolution textures installed it could become a problem. I'll try to find some time to fix it. No other problems detected. 200MB of textures shouldn't cause a framerate impact so the exact reason remains unknown. The framerate was restored after restarting the scenario.

There is still something going on with external MFDs. I have a few open in prep for a deorbit with the XR-2. At start of the scenario I am near 500 fps. By the time I am ready to deorbit burn, which was about 7 orbits later, most done at x100 time accel, I am down to under 150. That is a huge performance loss. I am wondering if I am seeing an accelerated loss due to my settings, I use the GeForce drivers to use more aggressive Antialiasing and Anisotropic filtering.

16.05.11%2021-13-58%20Constitution%20png.png


I am not going that over the top with ext mfds, and yes I made sure I was using the Dx9 version of the ext mfd. I use this same flow with external mfds back in R12 of the client and never saw such performance loss. R12 still seems to be the most stable build for 2010p1.
 

SolarLiner

It's necessary, TARS.
Addon Developer
Joined
Jun 14, 2010
Messages
1,847
Reaction score
2
Points
0
Location
404 ROAD NOT FOUND
The problem with normalized sunlight is that as far as the inline client (and as far as I know this one as well) is concerned The mean distance of Jupiter from the Sun is also one astronomical unit which is simple but a whole lot less accurate.

Not really. Have a piece of white paper and expose it to a direct sunlight and then call it's illuminance a 1.0, a reference value. Describe everything else relative to that. I guess it should be pretty accurate everywhere.

What he's saying is that the light intensity is constant with distance.
If we take a sun intensity of 1.0 at 1 AU, then Jupiter being 5.44 AU away from the Sun, and intensity following the inverse squared law, Jupiter would be illuminated with a light intensity of 1/5.44^2 = 0.034; which is 3.4% of the intensity at Earth distance.

In the inline client, and currently in the D3D9 client as well, light intensity is the same at Earth and at Jupiter, which is another "cheat" to get a proper picture at all distances. (Neptune receives 0.1% of the intensity compared to Earth, while Mercury gets 470% of intensity compared to Earth)
 
Top