feature request: transform origin (or "pivot point")

[trusktr]

Description of the problem

As an example, Babylon has this feature built in, called pivot points. CSS has it in the form of the transform-origin property.

These features enable rotation about a pivot point with a one-liner.

Here's an implementation idea: https://jsfiddle.net/mmalex/hd8ex0ok/ (thanks @nmalex).

I believe ideally this would be implemented inside Matrix4, and the Matrix4.compose( position, quaternion, scale ) signature would be changed to Matrix4.compose( position, quaternion, scale[, origin] ), with the origin parameter being optional for backwards compatibility.

An origin property would be added to Object3D, so that we can for example write object.origin.set(1,2,3).

updateMatrixWorld would then call this.matrix.compose( this.position, this.quaternion, this.scale, this.origin ).

Just bike shedding, but pivot could also be another name in place of origin, but I like origin better because "pivot" doesn't seem to align with "scale" (I'm thinking that scale would also happen about the origin).

Three.js version

• Dev
• r102
• ...

Browser

• All of them
• Chrome
• Firefox
• Internet Explorer

OS

• All of them
• Windows
• macOS
• Linux
• Android
• iOS

Hardware Requirements (graphics card, VR Device, ...)

N/A

[WestLangley]

Can you please provide a simple fiddle demonstrating your use case?

Also, please explain in the context of your demo why the existing three.js capabilities are not adequate.

[Mugen87]

TBH, I always thought that the existing approaches in three.js feel more like workarounds. I mean using an instance of THREE.Object3D that acts as a pivot point or translating the geometry is in some sense the utilization of a practical side effect. But it's not usable in all scenarios. Sometimes, you don't want to change your scene graph or the geometry data. Having a pivotMatrix that defines the pivot point is a solution without such ramifications.

[Mugen87]

Related: https://stackoverflow.com/questions/55116131/how-can-we-change-the-rotation-origin-pivot-point-of-a-three-js-object-without/55138754#55138754

I think it might be worth to consider this issue as a valid feature request.

[looeee]

I agree with @Mugen87 here. I spent way to long using these hacks to get pivot points from the FBX format working, and I still think that there are edge cases that are not covered since the format has the concept of geometric pivot (i.e. transformed geometry relative to the mesh) and also object level pivot points (what @trusktr means here).

Both currently are shoe-horned into the geometric pivot, but it would have been a lot easier and less error prone if threejs had native pivot points.

Since most other 3D apps seem to have this concept, the only reason I can think of for NOT adding them is if there are major caveats for doing so, such as reduced performance.

[donmccurdy]

Having a pivotMatrix that defines the pivot point is a solution without such ramifications.

There are some ramifications here. The new matrix will have to be recursively updated and updateMatrixWorld will likely become slower. I think we'd want to measure that effect on a CPU-constrained example before proceeding.

Since most other 3D apps seem to have this concept, ...

Any non-DCC examples? I know all modeling tools have this, but they have a lot of concepts that aren't reasonable to include in a realtime rendering library. I think Unity's editor allows you to set pivot points, but they're baked when you build the project and a pivot point cannot be changed at runtime without using parent nodes.

From the authors of the Godot Engine:

Some 3D DCCs support an extra object Pivot (e.g. 3DS MAX). Collada exports this as an extra node and most likely if a glTF 2.0 exporter [for 3DS MAX] existed, the same would be done. ... I don't think any mainstream 3D engine supports extra object pivots either.

[arodic]

The new matrix will have to be recursively updated and updateMatrixWorld will likely become slower.

Perhaps the new matrix can be calculated only if pivot point is specified, as it is optional.

[looeee]

I think we'd want to measure that effect on a CPU-constrained example before proceeding.

Yes, this seems like the obvious next step. If this can only be achieved by reduced performance, then it's a non-starter and we'll have to continue with the hacks.

In Babylon.js it looks like the pivot is a simple pre-transform matrix. If we implement it in a similar way, such that the pivot matrix is undefined by default, then updateMatrixWorld should only be slower if the pivot is present.

On the other hand, Babylon.js is the only non-DCC tool I can find that implements pivot points in real time (with 5 minutes of research, anyway).

This would be useful for the FBX loader, and I can imagine other situations such as manually building objects with hinges where since this would be useful. But on the other hand, we've got this far using just the hacks and I don't personally have a strong need for this.

@truskr if you want to champion this idea, could you do some more research and see whether other tools beside Babylon offer real time pivots? Also, if you can identify some use cases and see if other people besides you are requesting this feature then that would help strengthen the case.

object.origin.set(1,2,3)

My preference would be to call this object.pivot.

[WestLangley]

@looeee Please stop referring to the existing code as hacks.

[WestLangley]

I would like the OP to answer my questions above before considering adding such a feature.

Note, a user can do the following at the application level. I would not expect it to have a measurable performance impact.

THREE.Object3D.prototype.updateMatrix = function () {

	this.matrix.compose( this.position, this.quaternion, this.scale );

	if ( this.pivot && this.pivot.isVector3 ) {

		var px = this.pivot.x;
		var py = this.pivot.y;
		var pz = this.pivot.z;

		var te = this.matrix.elements;

		te[ 12 ] += px - te[ 0 ] * px - te[ 4 ] * py - te[ 8 ] * pz;
		te[ 13 ] += py - te[ 1 ] * px - te[ 5 ] * py - te[ 9 ] * pz;
		te[ 14 ] += pz - te[ 2 ] * px - te[ 6 ] * py - te[ 10 ] * pz;

	}

	this.matrixWorldNeedsUpdate = true;

};

and then define the object pivot only when needed:

mesh.pivot = new THREE.Vector3( 5, 5, 5 );

With this approach, children of objects having a defined pivot are still located relative to the object's origin.

[trusktr]

Basic example: Using origin/pivot to define the hinge of a door in a game. Here's a fiddle, using CSS transform-origin, but you get the idea.

[Mugen87]

Instead of asking the user to monkey-patch library code, I would prefer to include Object3D.pivot into the library.

[trusktr]

		te[ 12 ] += px - te[ 0 ] * px - te[ 4 ] * py - te[ 8 ] * pz;
		te[ 13 ] += py - te[ 1 ] * px - te[ 5 ] * py - te[ 9 ] * pz;
		te[ 14 ] += pz - te[ 2 ] * px - te[ 6 ] * py - te[ 10 ] * pz;

@WestLangley How does that part work? Can you explain (or share the link if you found one)? Sorry, I'm not the best at the maths!

[mrdoob]

Sometimes, you don't want to change your scene graph or the geometry data.

I spent way to long using these hacks to get pivot points from the FBX format working

I think these are fair points.

We should measure what's the performance impact of modifying updateMatrix() so it looks like this.

THREE.Object3D.prototype.updateMatrix = function () {

	this.matrix.compose( this.position, this.quaternion, this.scale );

	var pivot = this.pivot;

	if ( pivot !== null ) {

		var px = pivot.x, py = pivot.y,  pz = pivot.z;
		var te = this.matrix.elements;

		te[ 12 ] += px - te[ 0 ] * px - te[ 4 ] * py - te[ 8 ] * pz;
		te[ 13 ] += py - te[ 1 ] * px - te[ 5 ] * py - te[ 9 ] * pz;
		te[ 14 ] += pz - te[ 2 ] * px - te[ 6 ] * py - te[ 10 ] * pz;

	}

	this.matrixWorldNeedsUpdate = true;

};