rotationGizmo the rotation results abnormally when the parent node scales the three axes unequally。

There is this forum thread : Object3D.userData Three.JS equivelent in BabylonJS

Excuse me, I have a question. The setting of renderingGroupId for mesh in the scene created by babylon viewer is invalid. Is this a bug or a requirement?

This is the code:
import { computed, nextTick, onMounted, reactive, ref } from ‘vue’;
import { Scene, Engine, FreeCamera, Vector3, HemisphericLight, MeshBuilder } from ‘@babylonjs/core’
import { DefaultViewer } from “@babylonjs/viewer”;
import * as BabylonViewer from “@babylonjs/viewer”;
import TriphasicTransformControls from “xuanjing/controls/triphasicTransformControls”
// let canvas = ref()
let container = ref()
var createScene = function () {

let configMapper = BabylonViewer.mapperManager.getMapper("dom");
const config = configMapper.map(container.value);
let viewer = new DefaultViewer(container.value, config)
console.log(viewer)

BabylonViewer.viewerManager.addViewer(viewer);
BabylonViewer.viewerManager
    .getViewerPromiseById("testcontainer")
    .then((viewer: BabylonViewer.AbstractViewer) => {
        setTimeout(() => {
            var scene = viewer.engine.scenes[0];

            // Our built-in 'sphere' shape.
            var sphere = MeshBuilder.CreateSphere("sphere", { diameter: 2, segments: 32 }, scene);

            // Move the sphere upward 1/2 its height
            sphere.position.y = 1;

            // Our built-in 'ground' shape.
            var ground = MeshBuilder.CreateGround("ground", { width: 6, height: 6 }, scene);
            ground.renderingGroupId = 2

            viewer.hideLoadingScreen();
            let triphasicTransformControls = new TriphasicTransformControls(scene)
        }, 3000)

    });

};
If it is your new engine and scene renderingGroupId rendering is correct.
version:5.24.0

Is there any setting that will cause the clearCoat of PBRMaterial to have no rendering effect? There is no effect after the material in my program opens clearCoat, but the test environment I opened separately is normal. I currently have no way to locate the problem in the code.

ping @Evgeni_Popov

I don’t know the viewer in depth but renderingGroupId=2 is a valid value: why do you say it’s not? Have you an example with this setting that would not render correctly?

As for the clear coat, if you enable it it should work (see the docs).

Have you enabled an environment map in your scene?

I guess it would be easier to see what’s going on with a repro or a live link. Also, you should probably create another thread as these problems are not related to rotation gizmo.

Thanks for your reply, I created a link to renderingGroupId and attached a sample code project with screenshots.

The problem of clearCoat failure, I did not reproduce in the test environment, only in our project, the light has this problem

HemisphericLight and environmentTexture. Metal rough can work normally.
This is our project:


this is sandbox:

This is the renderingGroupId problem link:
Viewer causes renderingGroupId to become invalid - Bugs - Babylon.js (babylonjs.com)

I think this problem is the problem of our project, but I can’t locate the reason, so I would like to ask which may cause the failure of clearCoat.

I really don’t know why clearcoat would not work… Do you have a live link which shows the problem?

I found that THE varnish works in THE version deployed on the Internet!! Can pull the version to locate the problem!

1 Like

Hello babylon, I have noticed that this problem has been modified on github and tested. I found this problem when only the parent of the mesh scales unevenly. Modified will updateGizmoRotationToMatchAttachedMesh = false, mesh itself rotation after a non-uniform scale can cause mesh scale was modified to uniform scale.
This is the test page, first change the ball to non-uniform scale and then rotate, the ball will be changed to uniform scale.
A Basic Scene | Babylon.js Playground (babylonjs.com)

Rotation does work for me in your Playground even after I have scaled the sphere in one direction:

Need more rotation Angle will appear problem, can use because the gizmo. Gizmos. RotationGizmo. UpdateGizmoRotationToMatchAttachedMesh = false, If the gizmo gizmos. RotationGizmo. UpdateGizmoRotationToMatchAttachedMesh = true will not be used.

I see! No idea why it’s doing that…

Summoning the king of Gizmo @Cedric, but be patient as it is vacation time these days.

@xiehangyun
Rotation with non uniform scaling is limited. instead of producing wrong orientation, it’s just disabled with a warning in the console.
This comes from the fact that it’s impossible to decompose properly a world matrix in that case with quaternion/scale/translation.
A solution would be to use translation/scale/rotation quaternion all along but it would be a nightmare and very, very bug prone when generalizing to Node and not only TransformNode.
Moreover, non uniform scaling and not a common case and adding a lot of potential bugs/back compatibility break for that case doesn’t seem like a win to me.
So, either set UpdateGizmoRotationToMatchAttachedMesh to the correct value or try to limit the potential to have non uniform scaling.

1 Like

Thank you for your recovery. I know, but previously it was only the parent node that caused the problem, but now the node itself has been disabled. And there is no problem with rotation first and then scaling, so is there another solution?

I would set the gizmo node to be the last one in hte hierarchy with uniform scaling.
Basically, transforming a non uniform scaling is not allowed depending on UpdateGizmoRotationToMatchAttachedMesh value.

Or, maybe even simpler, create a transform node at the absolute position of the node you want to transform and with the observables, set the rotation value of the node from that transient nodeTransform.
Basically, use a proxy transformNode.

1 Like

If the non-uniform scaling of the node itself (the parent node is uniformly scaled) can be rotated properly, then creating a proxy node in world coordinates can be a good solution。

1 Like