Custom camera orientation does not seem to work

[moorepants]

If you run the mass_spring_damper example there is a custom camera that used to rotate the scene properly. See the first screenshot in this PR #97. But for some reason only the location of the camera seems correctly adjusted and not the orientation.

[sahilshekhawat]

This issue must be fixed in #183.

[moorepants]

It does not seemed to be fixed in #183 for me. The orientation of the camera in the mass_spring_damper should be such that the mass bobs up and down.

[moorepants]

@sahilshekhawat Would you mind looking into this issue. I don't think it is on the Python side. I haven't been able to find the bug yet in the JS.

[sahilshekhawat]

I am currently working on fixing issues with camera including this one.

[sahilshekhawat]

Okay, So I spent about one and a half day figuring out the reason and i still don't know.
camera.applyMatrix() must work as it sets the value of position, quaternions and scale but it doesn't changes quaternions only. Position is changed. Moreover, When I manually set those values e.g.

var position = new THREE.Vector3();
var quaternion = new THREE.Quaternion();
var scale = new THREE.Vector3(1, 1, 1);
initMatrix.decompose(position, quaternion, scale);
_camera.position = position;
_camera.quaternion = quaternion;
_camera.scale = scale;

then again quaternion's value is not changed.
Correct orientation works when we do

_camera.matrixAutoUpdate = false;

which doesn't changes the value of transformation matrix from incorrect quaternions but then again trackballcontrols are not working due to that.
Whenever we run camera.updateMatrix() it changes the orientation which makes it sure that the bug is in setting the value of camera.quaternions
I am leaving it until the end and moving on to fix other bugs. Will look into it later.

[moorepants]

@tarzzz Do you have any idea why this is not working? It used to work just fine (at least at the end of last summer).

Sahil is going to file an issue on threejs about this.

[sahilshekhawat]

Instead of an issue, I have asked on stackoverflow: http://stackoverflow.com/questions/30818179/rotation-does-not-change-after-setting-transformation-matrix-for-camera

[tarzzz]

When the frame is rotated 90degrees with ceiling.y as the Axis, it behaves as per the expectation.

camera_frame = ceiling.orientnew('Camera Frame','Axis', [-pi / 2, ceiling.y])

but rotating w.r.t to ceiling.z (which is desired here) does nothing. That somehow rules out the bug on the JS side (Since the initial matrix updates are working fine for ceiling.y).

[moorepants]

@sahilshekhawat What is the status here? Has the SO question and Tarun's observation helped figure out anything?

If we can't get this into the release, we may need to disable the ability to orient cameras.

[sahilshekhawat]

@tarzzz but if we do camera.matrixAutoUpdate = false it works, thus, I don't think that its on the Python side. Something is overriding our matrix and I don't know what.

[moorepants]

One way to help eliminate the python side possibility is to complete the unit tests for the cameras, see #212.

[moorepants]

@sahilshekhawat For this one, maybe we should issue a warning if the user passes in a custom camera referencing this issue. Will just have the warning for the release.

[sahilshekhawat]

Okay, I am raising a PR for the same.

[sahilshekhawat]

After #239 is merged, I am going to remove this from the milestone.

[oliverlee]

This is not a Python issue. You can change the rotation portion of the camera initial orientation transformation matrix and the rotation is not changed when displaying the scene.

[moorepants]

Yes, I agree. I'm pretty sure it is in the JS code.

[moorepants]

This bug is nasty. I spent a number of hours today trying to track it down. First off, here is a minimum example that shows camera initialization working with three.js r58 (the version we ship with PyDy):

http://jsfiddle.net/nd8q6qug/5/

Some findings:

• Three.js expects you to manipulate an Object3D's rotation (or quaternion), scale, and transformation variables and then it updates the actual transformation matrices. If you want to update the transformation matrices directly then there may be issues. This documentation says that updateMatrix will clobber the values you enter: http://threejs.org/docs/#Manual/Introduction/Matrix_transformations
• This recommends to call updateMatrix: http://stackoverflow.com/questions/17221738/three-js-chaotic-mesh-rotation-after-applymatrix
• This sounds like our error, where the init rotation gets changed back: http://stackoverflow.com/questions/23130832/three-js-update-objects-matrix-and-scale, this suggests setting matrixWorldNeedsUpdate to true.
• This says you have to be careful about whether you have global transformation matrices or relative ones: http://stackoverflow.com/questions/11320817/using-matrices-to-transform-the-three-js-scene-graph
• This advises against manipulating the matrix directly: http://stackoverflow.com/questions/17240008/three-js-how-to-apply-rotation-matrix-to-some-base-objects-state
• Suggests calling updateMatrixWorld with true: http://stackoverflow.com/questions/18470156/setting-the-camera-matrix-manually-in-threejs
• A trackballcontrols and camera example: https://github.com/josdirksen/learning-threejs/blob/master/chapter-09/04-trackball-controls-camera.html
• This says TrackballControls 60 has some fixes to bugs that were in 58.
• Here is Sahil's question: http://stackoverflow.com/questions/30818179/rotation-does-not-change-after-setting-transformation-matrix-for-camera

I have also tried updating three.js to the newest version, r73, but it fails to load THREE in the notebook and I haven't been able to figure out why. We are likely using the incorrect way to load custom js into the notebook.

[moorepants]

I've found something that could be part of the problem. The parser.js file has two AJAX calls that aren't necessarily completed before the animation function is called. It would be good to ensure that those complete before running subsequent commands.

[moorepants]

Moved this out of the 0.3.1 milestone since we haven't fixed it in time.