Textures: Fix clearing of textures with integer type

[Popov72]

See https://forum.babylonjs.com/t/support-custom-outputs-for-shadermaterial/42835/3

It also fixes a couple of small bugs with WebGPU.

PG for WebGL: https://playground.babylonjs.com/#XSNYAU#47
PG for WebGPU: https://playground.babylonjs.com/#XSNYAU#50

WebGPU has a stricter limitation for the total number of components for the target render textures (it's limited to 32 bytes), so I had to make a different PG.

[bjsplat]

Please make sure to label your PR with "bug", "new feature" or "breaking change" label(s).
To prevent this PR from going to the changelog marked it with the "skip changelog" label.

[bjsplat]

Snapshot stored with reference name:
refs/pull/14112/merge

Test environment:
https://babylonsnapshots.z22.web.core.windows.net/refs/pull/14112/merge/index.html

To test a playground add it to the URL, for example:

https://babylonsnapshots.z22.web.core.windows.net/refs/pull/14112/merge/index.html#WGZLGJ#4600

Links to test babylon tools with this snapshot:

https://playground.babylonjs.com/?snapshot=refs/pull/14112/merge
https://sandbox.babylonjs.com/?snapshot=refs/pull/14112/merge
https://gui.babylonjs.com/?snapshot=refs/pull/14112/merge
https://nme.babylonjs.com/?snapshot=refs/pull/14112/merge

To test the snapshot in the playground with a playground ID add it after the snapshot query string:

https://playground.babylonjs.com/?snapshot=refs/pull/14112/merge#BCU1XR#0

[sebavan]

Sounds expensive and creating GC ? should we always call clearColor and clearBuffer ? But only on color change ?

[Popov72]

I have removed the GC. I'm not sure to understand this part:

should we always call clearColor and clearBuffer ? But only on color change ?

?

[sebavan]

I have removed the GC. I'm not sure to understand this part:

should we always call clearColor and clearBuffer ? But only on color change ?

?

To limit the branching within the function, as well as the gl calls, I was wondering whether we should check the current state (value wise) and always call clearColor… in this case so we end up with only one if preventing extra gl calls instead of the one branching on type. I am not sure it is necessary tbh :-)

[Popov72]

I don't think there are currently extra gl calls(?)

We could call clearColor even in the integer texture case, but we will still have a condition because we should not update mode if we called clearBuffer previously.

Note that clearBuffer actually clears the texture (contrary to clearColor which only updates the gl state), so we must call it each time ThinEngine.clear is called, and not only when the color changes.

We could make the test for an integer texture lighter if we add a getter property in InternalTexture like isIntegerTexture that would be precomputed when the format is set (but we would need to transform the InternalTexture.format property to a getter/setter...).

[sebavan]

I don't think there are currently extra gl calls(?)

We could call clearColor even in the integer texture case, but we will still have a condition because we should not update mode if we called clearBuffer previously.

Note that clearBuffer actually clears the texture (contrary to clearColor which only updates the gl state), so we must call it each time ThinEngine.clear is called, and not only when the color changes.

We could make the test for an integer texture lighter if we add a getter property in InternalTexture like isIntegerTexture that would be precomputed when the format is set (but we would need to transform the InternalTexture.format property to a getter/setter...).

Makes sense ! Thanks