Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Look-at point is not being saved in the vZome file after "Use Copied View" has been invoked. #438

Open
david-hall opened this issue Aug 5, 2021 · 3 comments

Comments

@david-hall
Copy link
Contributor

This was noticed in version 7.0.61. I'm not sure how long this problem has been present.

@david-hall
Copy link
Contributor Author

In case it matters, I didn't directly use look-at-this to reposition the camera. I had previously used look-at-this on a panel far from the origin then copy-this-view then look-at-origin then drag out a strut and ball from the origin then delete the new ball and strut then use-copied-view then save-file. LookAtPoint is 0,0,0 in the file or with the show.vZome-xml command in my custom menu.
So in short, I last repositioned the camera with use-copied-view, not with look-at-this.

@david-hall
Copy link
Contributor Author

Another related possibility that I have not investigated would be if the camera angle is being saved correctly when the last action to move the camera is to activate "snap". This wouldn't affect the look-at-point, but it could change the camera angle. In short, in would expect the XML to read the current camera data whenever the XML is generated, not just when edits occur or the symmetry changes or something sets the "dirty" flag. that way, moving the camera doesn't set the dirty flag, but it does get saved to the XML on demand.

@david-hall david-hall changed the title Look-at point is not being saved in the vZome file. Look-at point is not being saved in the vZome file after "Use Copied View" has been invoked. Oct 17, 2021
@david-hall
Copy link
Contributor Author

I finally found a way to reliably reproduce this problem so I've changed the title of this issue here on github.

  1. Open any new model. RootTwo is nice because its symmetry data is minimal, leaving the ViewModel section close to the bottom of the XML.
  2. Invoke "show.vZome-xml" from the custom menu. Noting the values in the ViewModel section of the XML shown in stdout.
  3. Move the trackball in any direction and Invoke "show.vZome-xml" noting that some values have changed as expected.
  4. Invoke "Use Copied View" noting that the original camera position is restored on-screen.
  5. Invoke "show.vZome-xml" again, noting that the ViewModel values have NOT been restored to their original values as expected, but rather retains the value shown in step 3.
  6. Subsequent invocations of "Use Copied View" behave correctly on-screen, but after even a single invocation, the actual Camera data will no longer be updated in the vZome file.

I did a little digging and found the underlying reason, but for now I'm going to leave it for Scott to address.

DocumentModel.serialize() uses "this.defaultCamera" instead of serializing the actual Camera object used by the DocumentController via its CameraController. When a document is initially created, the Document's defaultCamera and the CameraController (normally) reference the same Camera object so they are in sync, but after "Use Copied View" has been invoked, the Camera Controller uses a new Camera object and DocumentModel.defaultCamera is no longer updated by the CameraController so it's basically meaningless. I think that the DocumentModel.defaultCamera variable should be completely eliminated and replaced with calls to the CameraContoller which should be the official keeper of any and all Camera objects including any that are to be saved and restored on command or when switching to and from Article mode.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant