hardwareScalingLevel and focal postprocess

Hi everyone! I hope you are all doing well.

I have one question concerning how is managed the focal when going HD.
As you can see in these images the blur due to the focal is really changing depending on the hardware scaling level.
HardwareScalingLevel = 0.5:

HardwareScalingLevel = 1:

I guess the quality of the rendering makes the focal more precise and thus there is less blur.
First, is it a normal behavior? And how could I avoid that change when going to HardwareScalingLevel = 0.5.

1 Like

nope it relates only to the chosen size of the blur texture. I guess here the texture is not a fixed size but using a ratio from the main screen.

Ok thanks! So I should tell the blur texture to keep a fixed size whatever the hardwareScaling right ?

Can you tell me how could I do that ?

Please, share a playground and we ll try to demo it in :slight_smile: It would be much easier as it might depend on how you implemented it.

Here you go @sebavan: https://www.babylonjs-playground.com/#Y3C0HQ#364

I added “Hadrware Scaling Level” input in this playground in order to quickly see the difference.
And the depthOfField is enabled by default.

Hi @sebavan, how are you ?

I tried to dig in on that subject. In the github project, I didn’t find anything to simply update the size of the blur texture as you suggested.

I found one dirty fix though by simply updating kernel of both X and Y blur effect as you can see here line 145: https://www.babylonjs-playground.com/#Y3C0HQ#366

Although it is working, I am not sure this is the best way to do it? I will be happy to help you change the code if I can of course. ( If this not on the shader side :sweat_smile: )

Cheers :wink:

Actually, I think your fix is the right one, except if @sebavan thinks the texture blur size should be corrected by the current hardware level by the engine itself (but in that case, there are a lot of locations to update in the engine).

As your blur texture is twice as big in 0.5 hardware level scale as it is when the scale is 1.0, a fixed amount of blur won’t yield the same results in both cases. You indeed have to double the blur value in the 0.5 case to get the same result than in the 1.0 scale.

The thing is blur is always screen size based so the bigger the screen the slower it would be to blur as big.

We chose to be constant on time so not in blur size here which the prefered way in most cases.

I would prefer to not change the code to handle it as it would reduce the performances by relying on a bigger kernel.

Also, you could consider simply switching the blur level in the DOF to obtain similar results.

pipeline.depthOfFieldBlurLevel = DepthOfFieldEffectBlurLevel.High when you are relying on scaling level

Hello thanks for your answers.

I understand why you want to keep it that way. I just feel it is too bad that all the defaultRenderingPipeline postprocesses stay constant whatever the scaling level except the depthoffield.

I guess we will have the same result with the highlightLayer or glowLayer?

I tried to change the DepthOfFieldEffectBlurLevel but it is less precise than my previous fix as you can see here: https://www.babylonjs-playground.com/#Y3C0HQ#367

Maybe we could multiply the blur size by the scaling level in the depth of field effect ? could you try locally and if that works we PR it ???

I want to import my BabylonJS local version to my project in order to make sure we have the expected result. I am using the npm packages of BABYLONJS so I expected something like "@babylonjs/core": "file:../BABYLONJS/Babylon.js", to work but it doesn’t.

Do you know how I could do that?

yup build locally with npm run build and then in your project do npm link @babylonjs/core

And Voila you ll be using your local build.

I continued my tests with the depthOfField, in my project I realized my previus solution in the playground was not working in every case depending on the focalDistance so I tried to play with both depthOfFieldBlurLevel and kernel to end up with this mix which works great almost all the time:

@sebavan do you think we can still make it work with how the depthOfField is managed right now?
The funny thing to see is that keeping a kernel size of 15 in every blur process make it work and you just have to change depthOfFieldBlurLevel from LOW to MEDIUM when changing the ScalingLevel.

Changing depthOfFieldBlurLevel is equivalent to a kernel size change from 15 to 30 here :slight_smile: that is why.

Hello everyone, I come back with a related issue to this topic.

We have a weird behavior with the DepthOfField which create aliasing!
Even when we push hardwareScalingLevel to 0.5, defaultPipeline.samples to 4 and defaultPipeline.fxaaEnabled to true as you can see in this playground: https://www.babylonjs-playground.com/#Y3C0HQ#375

It seems like the DepthOfField is still not following the new ScalingLevel. I tried to activate the option enablePixelPerfectMode (in order to push the rendering width and height) of all the DepthOfField postprocesses but with no result.

Have a good day, cheers :wink:

Pinging @sebavan

1 Like

The issue does not seem related to hardware scaling level here as even the default is aliasing:



The main issue here is coming from the mix of blending and DOF. Basically, for DOF need a proper depth to know how to blur I guess in your case you could try to force the blend mode of the pbr to BlendAndTest to limit the issue.

Bleeding like this is definitely the hardest part of DOF.

Hi @sebavan, I tried every blend stuff on the PBR to see if it changes something but I have no positive result. See line 305 - 310 : https://www.babylonjs-playground.com/#Y3C0HQ#377
Is it what you meant ?

The weird thing is that we manage to have a smooth edge with hardwarescalingLevel, multisamples and fxaaEnabled with this model. But I guess the DOF is not impacted by these other postprocesses and that is why we see bad aliasing showing again?

The DOF really brings reality in our scene and we are close to have a perfect and clean rendering except for this stuff haha!

I am pretty sure DOF is not correctly working due to the fact that the geometry is really thin. I ll check if we can find smthg but I am totally not sure.

Thanks @sebavan, tell me if I can help! Will be happy to. :wink: