Scattering with scaling Model

Bugs
1

After setting the scale for the model, the thickness map looks wrongly sampled,not sure if this is a bug

without scaling

image
image957Ɨ823 48.6 KB

with scaling

image
image951Ɨ832 62.4 KB

PG for testing:https://playground.babylonjs.com/#N09XXI#6

2

You will have to scale the maximumThickness property accordingly if you change the scale of the mesh:

2 Likes
3

I found that commenting out the skybox dropped the framerate nearly in half straight away :thinking:

4

Thanks for your reply. I saw someone mentioned that there is a performance issue. I tried it and it is true. When skybox is commented out, the performance decreases. What is the cause of this?

6

This PR will fix the performance problem:

2 Likes
8

I found that when scaling was used, scene.enableSubSurfaceForPrePass().metersPerUnit also had an exception

9

Can you provide a PG that shows the problem?

10

here: https://playground.babylonjs.com/#N09XXI#12

You need to manually adjust the scale and change the value of metersPerUnit in the inspector to observe the effect. The displayed effect of the scaled model changes very quickly. After reaching 0.1, subsequent changes are difficult to detect.

scale:1 metersPerUnit:0.3

image
image1915Ɨ915 168 KB

scale:5 metersPerUnit:0.3

image
image1917Ɨ916 173 KB

11

Iā€™m not sure I understand. You said there was an exception, but I donā€™t see anything in the console log when I change the ā€œmetersPerUnitā€ value (?) As for the impact of ā€œmetersPerUnitā€ on the display, I donā€™t know how the algorithm works, but there are probably invalid values depending on your mesh (use the value that best renders your mesh).

1 Like
12

I donā€™t know how the algorithm works, but according to my expectation, the same parameters should show the same effect, right? But it does have differences. In the model with scale greater than 1, the rate of change is very fast. In other words, when scale=5, the parameter 0.02 may be equal to the parameter value 0.2 when scale=1. I donā€™t know if I have expressed it clearly.

13

I think itā€™s expected, maximumThickness depends on the dimension of the mesh, so the value must take into account the scale.

During my tests, the scaling of maximumThickness is (inversely) proportional to the value of scale. Compare https://playground.babylonjs.com/#N09XXI#13 where scale=1 and https://playground.babylonjs.com/#N09XXI#14 where scale=100. The result is the same, and maximumThickness is scaled by 1/100.

1 Like
14

so metersPerUnit is same to maximumThickness both are (inversely) proportional to the value of scale, right?

15

After reviewing the sources, it appears that you need to multiply maximumThickness by 1/scale, because the code multiplies the thickness by scale before passing the value to the shader:

subMesh.getRenderingMesh().getWorldMatrix().decompose(TmpVectors.Vector3[0]);
const thicknessScale = Math.max(Math.abs(TmpVectors.Vector3[0].x), Math.abs(TmpVectors.Vector3[0].y), Math.abs(TmpVectors.Vector3[0].z));
uniformBuffer.updateFloat2("vThicknessParam", this.minimumThickness * thicknessScale, (this.maximumThickness - this.minimumThickness) * thicknessScale);

It seems that the SSS algorithm requires maximumThickness to be independent of the scale, which is achieved by multiplying it by 1/scale beforehand.

2 Likes