Sat 07 Oct 2017 01:59:08 PM UTC, comment #17:
Pantxo, thank you for reminding me of that bug.
I rebased Colin's patch to a current tip, merged my patch on top of it and pushed it here: https://hg.savannah.gnu.org/hgweb/octave/rev/b188be2b962b
Changing status to ready for test.
|
Thu 05 Oct 2017 06:06:11 PM UTC, comment #16:
@Markus: would you consider merging your patch upon Colin's and taking care of reviewing/pushing it?
|
Wed 21 Sep 2016 05:44:11 PM UTC, comment #15:
I think it's too late for 4.2. But we can consider adding this in to the 4.2.1 bug fix release so people don't have to wait 18 months or more for a 4.4 release.
|
Wed 21 Sep 2016 05:18:04 PM UTC, comment #14:
Colin, I applied your patch and it is working correctly for me.
Wrt the issue you describe in your last comment #12: The attached patch calls the update functions of the respective "camera.." property when the "camera..mode" property is changed to "auto".
It applies on top of your patch and should fix that issue.
I tried your example from comment #12 with your "camtarget.m" from patch #9046 and it seems to work as expected now.
Is there still a change to get this into 4.2?
(file #38584)
|
Mon 18 Jul 2016 02:47:20 PM UTC, comment #13:
Colin, your last suspicion is probably right.
Did you try to add update methods to the cameramode properties that call "update_camera" when the respective cameramode is "auto"? Does this resolve the remaining issue?
|
Wed 13 Jul 2016 06:36:33 AM UTC, comment #12:
Ok, I read over this thread and tried it. I attach my patch.
A mode change may also need to call "update_transform":
Maybe that is a different bug because the return of camtarget() is wrong, not just the figure window...
(file #37840)
|
Wed 06 Jul 2016 11:50:08 PM UTC, comment #11:
Done, thanks.
|
Wed 06 Jul 2016 11:19:11 PM UTC, comment #10:
Maybe put this bug over on the 4.2 Bug List. At least it will get reviewed that way to decide if it can be included (http://wiki.octave.org/Bug_Fix_List_-_4.2_Release).
|
Wed 06 Jul 2016 09:54:26 PM UTC, comment #9:
I'm working on adding "campos", "camtarget", et al. And I hit this.
May I upvote this for 4.2?
I don't want to run matlab during my campos work but I'm confident from memory that Matlab's behaviour in Comment #7 is the following:
|
Sun 15 Mar 2015 10:15:18 PM UTC, comment #8:
I understand the switch to "manual". Obvious I think.
ML's behavior for button clicks is reported in the original report: ML resets the mode to "auto".
As far as I could verify later on it does so for all button actions that move/rotate/zoom pictures.
|
Sun 15 Mar 2015 08:54:39 PM UTC, comment #7:
Whenever you set a property directly, the corresponding propertymode is supposed to switch to manual. Octave is doing that correctly for camperaposition.
The question is whether the GUI rotate mouse button, and the m-files rotate and rotate3d, should reset the mode to auto if they are invoked.
Can you verify what Matlab does in this regard?
|
Sun 15 Mar 2015 07:28:55 PM UTC, comment #6:
I looked around in graphics.cc and graphics-in.h but for me it is hard to follow.
Are there some pointers as to what functions need to be patched?
What/where is the function that sets the camera.....mode to "auto ?
|
Sun 15 Mar 2015 04:15:10 PM UTC, comment #5:
I tried the other camera functions and indeed they all need similar treatment.
|
Sat 14 Mar 2015 10:33:16 PM UTC, comment #4:
(On Linux)
I can confirm that the "update_transform" change indeed neatly updates the camera position and rotates the 3D plot.
A side effect is that returning to the original camera position somehow gives a slightly distorted plot.
Then "axis equal" followed by "axis normal" gave me an upside-down plot; another "axis normal" finally returned the original plot. (I tried with "sombrero".)
There's still the other issue, that either:
- 'set ("cameraposition", [...])' also sets "camerapositionmode" to "manual" (if so, why?)
or (and/or ?)
- clicking the "rotate" button doesn't reset "camerapositionmode" to "auto" => the Rotate button suggests to be active but is non-functional
How can this be fixed?
|
Sat 14 Mar 2015 10:52:52 AM UTC, comment #3:
Oh, "update_camera" is not enough, you need to call "update_tranform" instead. It will also call update_axes_layout() that is necessary to have the axes position/direction right.
|
Sat 14 Mar 2015 10:32:40 AM UTC, comment #2:
Hi,
The gl-renderer doesn't directly make use of camera* properties. Instead it retrieves modified versions of the viewport (x_gl_mat1 and x_gl_mat2) that are computed in update_camera.
When "set ..." is called, the axes is actually redraw but x_gl_mat1 and x_gl_mat2 haven't been updated so nothing seems to happen.
All this to say that Rik's change is the right thing to do for camera related properties.
|
Fri 13 Mar 2015 08:35:09 PM UTC, comment #1:
Confirmed. Neither drawnow or refresh change the plot. Only clicking and attempting to rotate the plot do it. I think the issue is that the property needs to call an update routine after it has changed the value of the property.
For example, the 'view' property does change the plot when used in a set command, but it is defined that way in graphics.in.h.
I made a trivial patch just to see if I could get 'cameraposition' to work like 'view' and it works. See the attached diff.
If this is the right strategy, do all of the camera properties need to have an update routine?
|
Tue 10 Mar 2015 08:57:53 PM UTC, original submission:
Maybe I overlook something, but:
doesn't update (rotate) the plot.
Only after I press the "rotate" button and click in the figure, the figure suddenly rotates to the new camera position property.
=> Shouldn't it rotate immediately after the set() command, or after "drawnow"?
Matlab (r2015a) does rotate a 3D plot (= adapts to new cameraposition) immediately after the "set" command.
After the above actions, trying to rotate the plot by dragging with the mouse doesn't work anymore. Apparently the "camerapositionmode" remains fixed to "manual".
That seems aother ML incompatibility; ML resets the camerapositionmode to "auto" after clicking the "rotate" button and dragging a 3D figure corner. To be honest, I'd expect user actions like clicking a button to override previous system settings; OTOH maybe it is meant this way to prevent tampering with plots?
I report the 2nd issue here as well as I suspect (gamble) the two are related. If they're not I'll gladly open a new bug report.
|