Version: 7.6.2
Playground:
Desc:
using this code to create physics body of mesh, but resulting physics body is on different position with source mesh, not that not all PhysicsShapeTypes testes, but the same happens with BABYLON.PhysicsShapeType.MESH
var b = new BABYLON.PhysicsAggregate(model, BABYLON.PhysicsShapeType.CONVEX_HULL, {
mass: 1,
});
Step to reproduce:
Screenshot:
Hi @kzhsw
Is it the correct PG?
I don’t see any reference to convex hull and mesh is different.
Sorry for the mistake, I’ve updated the main thread and corrected link to the playground
I think it is the same problem as here.
Baking may be a solution: https://playground.babylonjs.com/#112FXI#17
Hi @Cedric , I’ve updated the link to pg in the main thread, any new ideas?
I think it’s related to Incorrect size of physics body - #3 by sebavan I’ll check both issues at the same time, later this week.
The mesh that is used for computing the convex hull has a negative X scaling value. It’s not possible to decompose the scaling in order to transform the positions.
Fix is to modify the asset and set positive values for all scaling components.
It’s the same internal pipeline with same constraints.
Physics engines should be able to handle all types of meshes, it’s unacceptable to modify the asset everytime
Using words like ‘unacceptable’ will not help.
Some engines do not support negative scales or non uniform scaling. We are doing our best to allow most types of assets with minimal modification. And don’t forget the engine is open source. If you think the engine should do something, then do it and open a PR!
@kzhsw it is all open source if you have a great way of addressing it not requiring the mesh changes ? we ll be glad to help in the review process
@sebavan @Cedric I’m quite confusing about “open source”, as far as I know, the havok engine in babylon.js is binary only distribution, where users can only use the per-built wasm binary. It’s really hard to find if the issue it within the wasm binary itself, or somewhere in the babylon.js havok plugin. Also, the docs is very few for both using and developing, and I don’t think external developer have the ability to fix this without more info about the internals of the engine.
Also, for the negative scale thing, every gltf model imported to babylon.js will contain an negative scale by default, how can users fix something like this?
Your case is different: there are negative scales in various part of the mesh hiearchy. In addition to rotations. At the end of the transform chain, it’s not possible to determine the resulting scaling when decomposing the world matrix.
This is not part of Havok but inside Babylon. Havok doesn’t know about gltf at all.
I’ll add documentation on baking.
By decomposing the world matrix, does it mean the negative scales will be applied to quaternion instead of scaling? How can it affect the result since decomposing and composing should make almost the same matrix?
To make it simple: when decomposing scaling, it’s impossible to make the difference between a negative value or a 180deg rotated one.
Simple example: a vector value of (-1,0,0). is it (0,0,1) with 90deg rotation on Y or (1,0,0) with a scale of -1?
It’s possible to deduce some cases but not all.
The composition of all scaling value (absoluteScaling) is always positive and that value is need when initiating Shapes from mesh with a transform hierarchy.
One solution is to replace local transform/worldmatrix by decomposed values. Keeping translation/orientation/scaling all along the transform hierarchy, everywhere in the engine from the scene graph, to the skeletal animation,… up to the rendering where you can compose a worldmatrix. This means rewriting a LOT. Or you can eliminate negative, non uniform scaling. Other users managed to do it and released production.
