As exemplified at https://jsfiddle.net/bcha0fr7/4/, computing positions with Object3D.worldToLocal() on each frame causes the result vector to jitter. Is this expected, and if so is there a better way to position the mesh?
What result are you aiming for 
? What you do seem a bit unnecessarily complex and unpredictable for moving a circle around (by transforming the vector to circle-space you make it inherit also rotation and scale, which you probably don’t want to do in global positioning)
I’m trying to move the circle to an arbitrary location in world coordinates. In my actual use case the shape is comprised of points that aren’t centered so I’m trying to account for the offset by converting the world coordinates to local ones.
Isn’t putting all these shapes within a group and then moving the group an option?
const group = new Three.Group();
scene.add(group);
group.add(meshes);
group.position.add(new Three.Vector(5, -10, 0)); // This will move all shapes within a group, in world space, by the same distance
I’m afraid the way you use worldToLocal() and then process the resulting vector does not make sense. I suggest you carefully debug the following fiddle and then you will see the difference:
The shapes I’m working with are comprised of points that aren’t centered, so adding the position vector without converting to local coordinates leaves them offset. For example, this shape is moved lower than the result vector in world coordinates. https://jsfiddle.net/e8Lqmb61/
Could you clarify this?
To be honest, I didn’t get why you want things that overcomplicated way with translated points of geometry, when you simply can use offset for position of a mesh.
Have a look at this example and play with useOffset checkbox:
1 Like
It means that the shape is drawn with points that aren’t centered. For example a square might be drawn with points at (1, 0), (1, 1), (2, 1), and (2, 0) in which case the shape itself is visually centered at (1.5, 0.5) but three js considers it to be centered at the origin.
It isn’t that I “want” the shapes to be drawn this way. I’m reading data from another program where lines and positions are being specified in world coordinates and I’m looking for a way to show that in three.js.
If someone could explain why the jittering occurs, or the proper use for Object3D.worldToLocal(), or a better way to position things in world coordinates that’d be a big help. I also stumbled across the getBoundingBox methods for geometries but those as well are in local coordinates.
Have a look at this example: https://jsfiddle.net/prisoner849/tdk6nhcz/
It uses THREE.Box3() and its .getCenter() method.
Translating the geometry warps lines drawn with THREE.MeshLine https://jsfiddle.net/bxnrufd8/. I don’t know enough about either to know which is at fault, but I had to switch to THREE.MeshLine since THREE.Line has a problem with curved lines with opacity https://github.com/mrdoob/three.js/pull/16570#issuecomment-496235146. Is there any workaround that doesn’t involve translating the geometry?
Taking a birds-eye perspective of this problem, I keep getting the feeling that people are uncomfortable with the idea of explaining why using Object3D.worldToLocal() is a bad idea. Code examples are great for specific problems, but an explanation would go a lot further toward solving future problems that come up.
You offset geometry’s vertices with -10 on y-axis (local coordinates system). And then you also set mesh’s position -10 on y-axis (world coordinates system). Thus, geometry’s points are 20 units low in world coordinates.
Getting of unpredictable and weird results.
To say why it’s bad, one needs at least to understand why you use .worldToLocal() and what you expect from the using of that function.
So far I see no single reason for using of .worldToLocal().
I know why it leads to the wrong position, I was just explaining why that jsfiddle didn’t solve the problem.
It fixed the problem outlined above, but also led to jittering that I couldn’t explain at the time.
I’ve debugged what I needed to, so thanks to everyone for the help with that. I found that the jittering was caused because worldToLocal() would alternate between first returning the offset of the mesh, then after copying that vector to the mesh’s position the next call would return a vector near the origin in the mesh’s local coordinates.
FWIW, being repeatedly told that I’m using the library incorrectly while simultaneously not being offered any explanation as to why the problem occurs or what the expected behavior is makes for a pretty bad developer experience, especially when the result is “unpredictable and weird” even to experienced users.
Just out of curiousity, do you plan to rotate a mesh, while moving from one point to another?
Yes, and I know that it’ll be preventatively difficult to do this way. I’m planning to center the points before drawing the mesh to make it work without distorting the geometry.
1 Like