Robot Simulation / Rotation issues

A few days ago I started working with Three.js. You might have seen my stackoverflow - question that was based on my issues in understanding how to properly rotate a hierachy of objects in Three.js.

My first attempt that partly solved the problem is available at:

In the meantime I made some progress with my main project which is published on github at

It is far from where i’d like to be but nevertheless it might be a good starting point for discussing some Three.js issues. This topic is based on the commit 8f430a08024682c4e2323ce8bd87f3f18ee977cc - if you’d like to reproduce it you might want to check out / clone exactly that state of affairs.

The content in this project is loaded from json files with a format that I came up with myself.
See for the definition of the quadruped robot that I’d like to simulate which is described in

Buggy behavior of current state of affairs
The options boxwires=false and debug=true are important at this point - otherwise the examples might give errors and misbehave - it’s one of the things I’d love to get support for to get things fixed.
If you’d like to try things out locally just follow the installation hints on github and use localhost:5002 as the base url

three Part example

This example is described by and derived from

If you move the Piece1.ry , Piece2.ry and Piece3.ry sliders you’ll see the effect i’d like to get for rotating around pivots.

Three.js Issues: XYZ-Cubes example
shows some rotational issues that I am having with Three.js and that well might be intrinsic to Three.js.

The robot description is loaded from and is based on the XYZ-Calibration cube from Thingiverse

As outlined in the coordinate system of Three.js will not display the cube as shown in

Cube0 is the unrotated version of that cube.

To make the cube render with Three’s coordinate system it needs to be rotated. Cubes A1 to C3 are all rotated so that the X,Y,Z text on it is aligned with the corresponding axes of Three.js

Now as in the previous example you can rotate the stack of Cubes by moving
the C1.ry slider the C1.1.1.rx slider and the C1.1.1.ry slider - again things work as expected.

You’ll be able to rotate the other Cubes in this way. Except for CubeC3.
It will not rotate around it’s pivot axis and I assume this is a nice example of a Gimbal Lock

It would be great if someone could point out how the third rotation option “Quarternion” would be able to solve this issue.

NiryoOne example

is described by and is based on

This example shows how difficult it is to position things correctly in the current way rotation and position are specified. There are currently two modes “absolute” and “relative”. But even absolute mode is not fully “absolute” - the rotations e.g. lead to axes being redefined which makes it hard to define positions.

General issues

Proprietary format
I hate to have a propietary format for this. On the other hand the export shows that the glb files exported are multi-megabyte files. I like the approach of specifiying the URLs files to be loaded better. There are some issues with this approach at this time e.g. CORS limitations and only stl is supported. Given that this is open source i hope for some issues being added to and PRs that might improve the situation.

Limited editing
It would be great to integrate this approach with a proper editor instead of the limited editing functionality provided at this time. There is not even a “save” functionality at this time - the json files need to be manipulated directly.


lead to many days and lots of hours of frustration. I think it would be great if Three.js would offer a PivotGroup functionality which like in my approach allows to specify a pivot and it’s part at the same time. Then it should be possible to decide how positions and rotations should be specified for the children - world or local coordinates should be useable as specified on every hierarchy level.

I am looking forward to your feedback, comments and collaboration.


A save option is now implemented see
The recursion in the exports and save is now avoided. See for solving the issue of null values that shouldn’t show up in the json export see

Do you ever tried CCD IK?