New Release D3D9Client Development

[jarmonik]

Here is a new build for developers and modelers. Compiled for r.55 and normal map issue is fixed.

 

[Felix24]

I'm getting a better understanding of PBR. I take back a lot of what I said above, but I'm still trying to understand how much control over lighting effects will be lost if the shader takes over what textures currently control. I haven't had time over the last couple of days to really experiment.

 

[4throck]

Same here, for some reason the latest Beta crashes, even with the standard client and all modules disabled... And without that going I can't test anything.

In the meantime, how about something like this for a test mesh:
http://www.babylonjs.com/Demos/PBR/

 

[jarmonik]

Same here, for some reason the latest Beta crashes, even with the standard client and all modules disabled...

If it crashes with it's own inline graphics engine while all modules are disabled. Then it would be good idea to install it in a new empty folder and see if the crash is reproducible and report it to the Orbiter beta thread.

And without that going I can't test anything.

Yeah, it kinda sucks, your input would be very helpful. Although, there's no rush, we are not making any final decisions anytime soon. But we are hoping to have a stable client ready when Orbiter 2016 is ready too.

In the meantime, how about something like this for a test mesh:
http://www.babylonjs.com/Demos/PBR/

Yes, it would be a good idea to have a test mesh that could be tested in a different renderers. But, of course, a reference renderer would need to be physically accurate (not efficient or fast).

EDIT: BTW, are you using windows XP by any chance ?
.

 

[SolarLiner]

I've actually taken a look at PBR and what it means; I found this doc that I think will be helpful to some: https://docs.google.com/document/d/1Fb9_KgCo0noxROKN4iT8ntTbx913e-t4Wc2nMRWPzNk/edit

I could try and take a test scene into LuxRender to get a 'nice' reference scene, but that'd mean having a HDR environment map.

 

[4throck]

OK, I "refreshed" my Orbiter Beta and got it working!

Here's a PBR test model with a simple but effective texture, borrowed from http://opengameart.org/content/4096-scifi-hex-tiles-pbr-texture
To be honest the cube is from the Borg cube add-on :lol:

I did two additions: a painted a red hexagon on the albedo map, and another on the reflection map. That way we can see the effect of the multiple texture maps better.

I'm very pleased with the results.
Here's how it looks like on my machine:
View attachment 14432

Inline client:
View attachment 14434

And here's the ZIP file for testing:
View attachment 14433



I think it's working as intended, with minimal fuss.

I'll try to provide updated textures for Skylab B.
Since we already have that model, let's see it it looks ok just by adding the new textures.

 

[jarmonik]

How is that model supposed to look like ? How does it render in some high quality reference renderer ? The preview shows very plastic look with a high amount of ambient light.

Here are three shots rendered using phong, blinn and ward style shading. Although, the ward is currently experimental and not necessary correctly implemented. Shading model can be changed from D3D9DebugControls.

This build also includes an experimental glow effect. It's a screen space post processing effect and I am not exactly happy with it, there's too much glittering and shimmering with it. I guess it would take little more than just a back-buffer color to reliably compute the effect. It would be good to know pixel's distance and reflectivity at-least. It might be good idea to spend the GPU resources else where.

EDIT: I suppose I could save the Earth Orbital envmap in to a file. That could be useful.
EDIT2: The glow effect is located in LightBlur.hlsl there are a few parameters that can be tuned by whoever is interested.

.

 

[4throck]

From the textures used, it's supposed to look like that: plastic look with metal screws.

Reference render: I get that and it's a good question!
I'll look into that, but most PBR materials/models are geared towards realtime engines, like Unity. Any suggestion or preference?

My take on all of this is practical.
We don't need to have PBR accurate rendering.
Just being PBR compatible and offering some extra control about reflections, while at the same time looking with the current add-ons is more than enough.

Testbuild3 does that! I think it improves shadows a bit with the standard meshes (tried the KSC flyby demo).

Yes, I guess we are missing environment mapping and that's important for orbital scenarios.
But again, Orbiter is a special case, where the environment is mostly black.
So I wouldn't worry much about 100% implementation.

I'll try testbuild 4 and see if I can create some more simple cubes with standard materials (metal, plastic, mirror) for further testing!

 

[SolarLiner]

This build also includes an experimental glow effect. It's a screen space post processing effect and I am not exactly happy with it, there's too much glittering and shimmering with it. I guess it would take little more than just a back-buffer color to reliably compute the effect. It would be good to know pixel's distance and reflectivity at-least. It might be good idea to spend the GPU resources else where.

I could take a look into that bloom shader. It'd be best if we had a 32bit float output for the glowing effect to be accurate (we then only take all brightness values greated than 1, so that only light emitters and strong reflections passes through the threshold and triggers the glow effect), but a soft threshold would be best as it oul allow bright-but-not-too-bright values to be taken into account as well. For example in my ReShade config the glow effect has a threshold of 65% brightness, but the glow itself it very diffuse and kinda subtle, like here:

The shuttle is clearly "white enough" (no ethnicity puns intended) to allow some glow but it is diffuse enough to not over-bright the whole image.
It's using a implementation box blur with O, with n being the number of passes (3 passes or more approximates a Gaussian blur good enough, so the end result is pretty fast).
How the bloom effect should look is no exact science, it's an artistic effect and as such, you can control its every aspect. I like my bloom effect subtle, saturated and diffuse to add atmosphere without blowing the image.

 

[jarmonik]

Here's a small update. It will enable "Sample a backbuffer into a glow buffer" shader section and also includes another experimental glow shader.

 

[SolarLiner]

This one seems to separate the foreground from the background; as seen in the attached pic, there is a clear line denoting the contour of the Shuttle marked by the glow effect.

 

[jarmonik]

I could take a look into that bloom shader. It'd be best if we had a 32bit float output...

That would increase bandwidth quite a lot. There exists 16bit floats too. The current implementation uses X2R10G10B10 off-screen render target giving 10bits for each color component. In that coding a full white could be assumed to be 0.5 which would allow to go little beyond white. Also, one mapping possibility is:

out-color = 1 - exp(-rgb)

which would place white 1.0 somewhere around 0.63 and much higher input values would approach to 1.0. This modification is included in PBR.fx but commented out, so it's not in use.

---------- Post added at 16:01 ---------- Previous post was at 15:58 ----------

This one seems to separate the foreground from the background; as seen in the attached pic, there is a clear line denoting the contour of the Shuttle marked by the glow effect.

Yes, I noticed that too. Haven't had time to investigate where it's coming from. Could be a problem in blending the blur effect back to back-buffer.

---------- Post added at 16:35 ---------- Previous post was at 16:01 ----------

From the textures used, it's supposed to look like that: plastic look with metal screws.

Plastics usually tend to show a fresnel reflection, currently it can be applied only with material configuration not with a textures. If the reflection map is supposed to give a color for a metallic reflection then high smoothness and low reflectivity could be used to identify a need for fresnel reflection ? At-least some renderers are using a low metalness and high smoothness to enable fresnel. What are your thoughts about that ?

Also, one thing that could cause problems is a color space, there's a lot of difference between nominal RGB and sRGB.

Reference render: I get that and it's a good question! I'll look into that, but most PBR materials/models are geared towards realtime engines, like Unity. Any suggestion or preference?

No, not really. Having some kind of image showing how some specific material setups are supposed to look like would help a lot in a calibration of the renderer.

I'll write some code to gain an ability to export and import environment maps to/from the Orbiter.

Also, ambient occlusion maps could be added to the client. If the AO is baked to a diffuse/albedo maps then shadows stay there even if lit by direct sunlight.

 

[SolarLiner]

I'm used with CGI to 32bit float values, so that was the first idea that came to mind. But the exponential 16bit float seems like a good compromise too.

I finally understood the LightBlur shader and it seems you went for a one pass Gaussian blur.
A way to yield better results is using the 3 pass box blur, each one separated into a horizontal and vertical blur pass. That would require two blur render buffers to store each pass but over a large kernel would improve the performance quite a bit.

 

[jarmonik]

I finally understood the LightBlur shader and it seems you went for a one pass Gaussian blur.
A way to yield better results is using the 3 pass box blur, each one separated into a horizontal and vertical blur pass. That would require two blur render buffers to store each pass but over a large kernel would improve the performance quite a bit.

The current implementation is using 4 passes (2 horizontal and 2 vertical). The "bDir" boolean does the flip between horizontal and vertical. And there exists two buffers (currently the size is screen width/2, height/2).

EDIT:
I just found a bug:

float2 vX5 = vX4 + vX;
float2 vX6 = vX4 + vX;
float2 vX7 = vX4 + vX;

How long that's been there I wonder :facepalm: Someone's gonna need new glasses :lol:

 

[SolarLiner]

I've crafted a quick "Orbiter PBR" shader for Blender and Cycles:

(Attached is the render result)

Dielectrics and Metallics can be defined with it without too much hassle (basically leave the reflectance map white and play with the reflectance amount for a dielectric, and go wild on the refl map colors for metallics, while keeping a dark albedo map). This is what I got for 4throck's PBR cube. But that raises the question of how do we define these reflectance and roughness constants.

 

[4throck]

Plastics usually tend to show a fresnel reflection, currently it can be applied only with material configuration not with a textures. If the reflection map is supposed to give a color for a metallic reflection then high smoothness and low reflectivity could be used to identify a need for fresnel reflection ? At-least some renderers are using a low metalness and high smoothness to enable fresnel. What are your thoughts about that ?

....

Also, ambient occlusion maps could be added to the client. If the AO is baked to a diffuse/albedo maps then shadows stay there even if lit by direct sunlight.

As i understand it, you can have all materials using metalness+roughness.
I know that some renderers use variations of these maps (like specular or gloss) but the principle is the same.

Indeed, we could set metalness and reflection on the mesh material definitions. But for compatibility reasons, I'd define them only by textures. For uniform materials that means a small 8x8 uniform texture, so no problem there.

Of course I might be mistaken, correct me if that's the case :thumbup:
....

As for ambient occlusion maps we can have those, but for our usage we really need realtime shadows. In orbit the light source direction is always changing. Static AO maps work well for ground objects, where the light comes more or less from "up".

 

[SolarLiner]

Added is a naive implementation or a resizeable kernel with box blur, andd a quick and simple threshold feature that should rule the small stars out and prevent the low light parts from brightening the image (no more bloom from stars, which also removes the shimmering effect because only big and shiny parts of the image are kept by the threshold).

Current implementation is naive and operates at O(m²*2n), with m being the size (number of pixels) and n the size of the 1D kernel (n = radius)

At 1080p it gives me ~20fps but I'm working on trying to implement the optimizations that should remove the speed dependence on the kernel size altogether.

My plan once that done is to crank the size up to 256 to have a diffuse bloom effect that's easy yet beautiful. And maybe over-saturate the bloom too, a la Watch_Dogs.

 

[4throck]

Here's an updated test model with more materials, based on the Reference Chart for Specular settings (second image)
http://docs.unity3d.com/Manual/StandardShaderMaterialCharts.html
So specular»_refl.dds and smoothness»_rghn.dds

I've included that image on the textures\pbr folder for reference.

We now have metal and a non-metal (wood) materials, each in smooth and rough variations (full values). The "materials" are only defined by texturing, mesh values are unchanged. That's not correct and something to look at latter.

The cubes need to be subdivided in order to reflect properly.
As they are you get distortions. But it's a start I think.

View attachment 14445
View attachment 14446

 

[SolarLiner]

New version of LightBlur.hlsl: Implemented a screen add which gives much smoother and pleasant results.

 

[4throck]

Tried some new texturing for the default base objects, since I think that those windows would benefit from the new rendering.

But no luck, from what I can see one of the new maps gets rendered on a different texture (ceiling), and normal maps are also only used in one material.
View attachment 14450


View attachment 14451



(original source textures from:
http://texturelib.com/texture/?path=/Textures/buildings/buildings/buildings_buildings_0051
http://texturelib.com/texture/?path=/Textures/buildings/buildings/buildings_buildings_0076)