Q: I have a Mesh (sphere) at 0,0,0. However when I rotate the mesh its off center. Its position is 0,0,0. It is scaled. The position reports its at 0,0,0 when I check it but its definitely not. I saw someone else with a similar issue and they posted that the geometry wasnt normalized. However, this isn’t making sense to me. Why does a scaled geometry set at WorldPosition 0,0,0 get off-center when scaled? Its not by much either but it is off. If I remove the scaling and set the geometry to a raw size will it fix the issue? I dont want to calc a normalization if I dont have to. Simplest solution.
Thank you!
P.S. - tested same mesh at world 0,0,0 in r118 (original model) wobble is not there. Both are InstancedMesh. Both scaled (3, 3, 3) after creation.
One is sized - SphereBufferGeometry( 100, 150, 150 ) - no wobble.
Hi Marquizzo, Sphere, and all other meshes are are added to a single root Object3D. The root is actually what is scaled. Its centered at 0,0,0 as well.
Ok @marquizzo I took the globe out of the root and just add it directly to the seen, for simplicity, and to make sure that the parent wasn’t the issue. Still happening.
let orbGeometry = new THREE.SphereGeometry( 60, 100, 100 );
let globeBufferInstance = new THREE.InstanceBufferGeometry( orbGeometry );
globeBufferInstance.index = orbGeometry.index;
globeBufferInstance.setAttribute( ‘position’, orbGeometry.getAttribute( ‘position’ );
globeBufferInstance.setAttribute( ‘normal’, orbGeometry.getAttribute( ‘normal’ );
let instancedGlobeMesh = new THREE.InstancedMesh(
globeBufferInstance,
globeMaterials[ globeOptions.globeMaterial ],
1
);
instancedGlobeMesh.rotateY( MATH.PI * 0.5 );
scene.add( instancedGlobeMesh );
Though the geometry is set at 0,0,0 before being converted to an instance, and the mesh itself is set at 0,0,0 the wobble still exists. You can see it on the transforms for “radial”,”sphere” and “geo”.
So @marquizzo this was an issue with using TrackballControls btw. Not with geometry or world position. Its the camera rotation itself. I figured it out. My code example likely didnt help at all (I realize now) but my model is pretty big. I’m using meshCaches and implemented the meshes in layers with keys (Thanks @prisoner849 !) . Isolating is getting harder now with so many aspects of the scene graph manipulation now built into to the 3DObject creation but the payoff is substantial. But I cant post the entire project, which now spans across custom modules, gitHub, a bundler, and a prod build configuration, so, I chalk it up to - I guess its just hard isolating the issue sometimes. I also had to modify my prod build configuration heavily so that gitHub doesnt contain the files for the actual build. I now do that locally and only publish the /dist/ folder to gitHub. Its the only “safe” way IMO.
My learning of all of the build implementation as well as the 3D coding and GPU customization has been a blistering pace. I hope to create a nice retrospective on this project when its done so I can really decompress some of this myself.
Thanks for the help anyways! Sorry about the example.
Case - Model of Rotating Sphere at scene root 0, 0, 0. Version - r132. Camera - Perspective. Geometry - InstancedBuffer. Control - TrackBall. Problem - Trackball Controls causing off-center movement (wobble) giving the appearance that objects at center were off of center.
Fix - apply: controls.target.set( 0, 0, 0 ); before initializing childObject position matrices and camera movement.
I suspect that the use of Tweens for camera movement may be the real issue. I have a feeling that if I normalize my camera positions during tween that the issue would go way without use of the control. So, I’m in essence using it to normalize. Which is lazy… but I can live with that Nobodies perfect right?
A couple of years ago I was working with a Space Navigator, also a 6DOF input device. That has a “deadzone” configuration option for each of the six axes:
You can define a minimum deflection of the puck for each axis, below which its input contribution will be discarded by the driver.
That way the user is required to make a deliberate movement exceeding that deadzone, thus shielding him from the effects of any inadverted manual jitter.
I wouldn’t be surprised if the trackball had a similar feature.
Maybe, I think its more a combination in this case that due to TweenJS having its own timer, and me using a lerp position, that is creating a floating point on the camera position. And when I send the camera back to its desired position its retaining the floating point. This is the “wobble”.
Nobodies perfect right?