bugGNU Octave - Bugs: bug #44503, 'set (gca, camera.......)' doesn't...


bug #44503: 'set (gca, camera.......)' doesn't update 3D plots

Submitter:  Philip Nienhuis <philipnienhuis>
Submitted:  Tue 10 Mar 2015 08:57:53 PM UTC
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  None
Originator Name:  Philip Nienhuis Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

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.

Markus Mützel <mmuetzel>
Group administrator
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?

Pantxo Diribarne <pantxo>
Group Member
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.

Rik <rik5>
Group administrator
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)

Markus Mützel <mmuetzel>
Group administrator
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 camera*mode properties that call "update_camera" when the respective camera*mode is "auto"? Does this resolve the remaining issue?

Markus Mützel <mmuetzel>
Group administrator
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":

>> sphere()
>> camtarget([0.3 0.6 0.9])
>> camtarget('mode')
ans = manual
>> camtarget('auto')
>> camtarget()
ans =

   0.30000   0.60000   0.90000

>> % but that is not right, nor is the figure updated.

>> % now use the mouse to resize the figure...

>> camtarget()
ans =

   0   0   0
>> % now its correct (and the figure looks right)

Maybe that is a different bug because the return of camtarget() is wrong, not just the figure window...

(file #37840)

Colin Macdonald <cbm>
Wed 06 Jul 2016 11:50:08 PM UTC, comment #11: 

Done, thanks.

Colin Macdonald <cbm>
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).

Rik <rik5>
Group administrator
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:

close all
hax = gca;
surf (peaks)
get (gca, 'cameraposition')

ans =   -203.286  -272.508    86.603

get (gca, 'camerapositionmode')

ans = auto

set (gca, 'cameraposition', [-910, -420, -20])
get (gca, 'camerapositionmode')

ans = manual

% not sure about the rotate3d stuff so I won't comment.
% but one additional thing: setting back to auto sets it to the original position:

set (gca, 'camerapositionmode', 'auto')
get (gca, 'cameraposition')

ans =   -203.286  -272.508    86.603

Colin Macdonald <cbm>
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.

Philip Nienhuis <philipnienhuis>
Group Member
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?

close all
hax = gca;
surf (peaks)
get (gca, 'camerapositionmode')
set (gca, 'cameraposition', [-910, -420, -20])
get (gca, 'camerapositionmode')
rotate3d off
rotate3d on
get (gca, 'camerapositionmode')

Rik <rik5>
Group administrator
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 ?

Philip Nienhuis <philipnienhuis>
Group Member
Sun 15 Mar 2015 04:15:10 PM UTC, comment #5: 

I tried the other camera functions and indeed they all need similar treatment.

Philip Nienhuis <philipnienhuis>
Group Member
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?

Philip Nienhuis <philipnienhuis>
Group Member
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.

Pantxo Diribarne <pantxo>
Group Member
Sat 14 Mar 2015 10:32:40 AM UTC, comment #2: 


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.

Pantxo Diribarne <pantxo>
Group Member
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?

Rik <rik5>
Group administrator
Tue 10 Mar 2015 08:57:53 PM UTC, original submission:  

Maybe I overlook something, but:

get (gca, "cameraposition")
ans =

   -91.3142  -119.0030     6.3622

>> set (gca, "cameraposition", [-910, -420, -20])
>> drawnow

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.

Philip Nienhuis <philipnienhuis>
Group Member


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #33335:  campos.diff added by rik5 (1012B - text/x-diff)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by cbm (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by philipnienhuis (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.


    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-10-21 mmuetzel StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2017-10-07 mmuetzel StatusPatch Submitted Ready For Test
    2017-01-30 mmuetzel StatusNone Patch Submitted
    2016-09-21 mmuetzel Attached File- Added bug44503_camera_mode_auto.patch, #38584
    2016-07-13 cbm Attached File- Added call_update_transform_on_camera_prop_change_44503.patch, #37840
    2015-03-13 rik5 Attached File- Added campos.diff, #33335

    Back to the top

    Powered by Savane 3.13-9c15.
    Corresponding source code