Re: Why are my 3D plots blue?
- To: mathgroup at smc.vnet.net
- Subject: [mg114288] Re: Why are my 3D plots blue?
- From: John Fultz <jfultz at wolfram.com>
- Date: Tue, 30 Nov 2010 04:03:02 -0500 (EST)
On Mon, 29 Nov 2010 06:07:39 -0500 (EST), Joseph Gwinn wrote:
> In article <ictfvj$mi6$1 at smc.vnet.net>, John Fultz <jfultz at wolfram.com>
> wrote:
>
>> If you can move the Dynamic inside of the Graphics3D[], you'll have a
>> much
>> better experience. I.e., instead of...
>>
>> Dynamic[stuff; Graphics3D[{dirs}, opts]]
>>
>> do this...
>>
>> Graphics3D[Dynamic[stuff; {dirs}], opts]
>>
> I will try this.
>
> Will something like:
>
> DynamicModule[{local variables},
> Dynamic[stuff];
> Graphics3D[ Dynamic[graphic directives], opts]
> ]
>
> also work? I've tried some similar approaches, but the graphics didn't
> respond to mouse motion, don't know exactly why. I would have thought
> that a local variable x would be linked by the Dynamic functions. I
> assume I didn't quite do it right.
No, that won't work. To understand why, read through my post here...
http://forums.wolfram.com/mathgroup/archive/2009/Feb/msg00424.html
For a further library of stuff that I've written about Dynamic, see here...
http://forums.wolfram.com/mathgroup/archive/2010/May/msg00440.html
>> and if the options should be dynamically updated, put individual
>> Dynamics in the option values.
>>
> Will this allow me to track the current value of for instance
> ViewMatrix? I have tried Dynamic[ViewMatrix] to no effect, getting an
> unchanging empty list {} in response.
Alas, there's a bug here. You're the first to uncover this, it appears. I've
made a report to the appropriate developers.
>> The basic problem here is that the Graphics3D is being recreated over
>> and over again and Mathematica is getting confused about what exactly
>> should be selected. In typical examples, this kind of thing works fine,
>> but your code, for reasons I haven't investigated, stresses this enough
>> to expose the problem. By preventing the Graphics3D wrapper from being
>> recreated, you can avoid the problem entirely.
>>
> OK. Sounds like it will be faster too.
Yes, but probably only marginally so.
> Another perhaps related effect discovered by accident is that moving the
> 3D mouse while Mathematica is doing the initial evaluation of the
> notebook can cause Mathematica to crash with a SEGFAULT error. This
> happened a few days ago, and I allowed MacOS to send the crash report to
> Apple.
This might require further investigation of the specific notebook you're working
with. I suggest starting a dialog with technical support about this.
Sincerely,
John Fultz
jfultz at wolfram.com
User Interface Group
Wolfram Research, Inc.
> The tricky thing is that if one merely puts one's elbow down on the
> table, the 3D mouse jiggles, and will emit a burst of data, so one could
> cause the problem by unlucky timing without touching the mouse. It would
> appear to the perplexed that Mathematica crashes at random while starting
> up on this notebook.
>
> I've also seen a less dramatic variation in a document that appears to
> be immune to being saved, as the unsaved-changes marker ignores multiple
> save commands - it's the mechanical vibration from typing the save
> command that jiggles the mouse and thus causes a new unsaved change so
> quickly that it seems that the save command was ignored. (The solution
> here is probably simply telling people that this can happen and not to
> worry.)
>
>
> Regards,
>
> Joe Gwinn
>
>
>> Sincerely,
>>
>> John Fultz
>> jfultz at wolfram.com
>> User Interface Group
>> Wolfram Research, Inc.
>>
>>
>> On Sat, 27 Nov 2010 03:36:43 -0500 (EST), Joseph Gwinn wrote:
>>> I've noticed an apparently harmless but mystifying oddity.
>>>
>>> I have some Graphics3D plots that contain an object that is being
>>> moved
>>> and rotated by a 3D mouse (a SpaceNavigator). If the view as
>>> initially
>>> determined by Graphics3D does not change, one can move the object
>>> around
>>> forever with no blue.
>>>
>>> If the view is changed (either by direct mouse click-and-drag action
>>> to
>>> rotate the bounding box, or automatically as Graphics3D computes a
>>> better view), the entire plot window will become see-through pastel
>>> blue, the same shade as is used to mark the bracket of a selected
>>> cell.
>>>
>>> If one selects the cell manually before using the 3D mouse to spin the
>>> object, the plot does not go blue.
>>>
>>> In all cases, this is within a DynamicModule and ControllerState is
>>> being used to obtain the datastream from the 3D mouse. There are no
>>> messages or errors reported when the plot goes blue.
>>>
>>> Does anyone know what's going on? Somehow, the plot is being
>>> selected.
>>> One assumes that once the cause is understood, it will be obvious how
>>> to
>>> prevent this annoyance.
>>>
>>> Thanks,
>>>
>>> Joe Gwinn
>>>
>>>
>>> For the record, here is the code of one miscreant:
>>>
>>> DynamicModule[{qd=Q[1,0,0,0],qxr,qyr,qzr,xr,yr,zr,xd,yd,zd,xp=0,yp=0,zp=0
>>> },
>>>
>>> Dynamic[{xp,yp,zp}+=3{-1,1,1}*
>>> ControllerState["SpaceNavigator",{"X","Z","
>>> Y"}]^3;
>>> {xr,yr,zr}=-5ControllerState["SpaceNavigator",{"X Rotation","Z
>>> Rotation","Y Rotation"}]^3;
>>> qxr=Q[Cos[xr/2],Sin[xr/2],0,0]; (* Generate the X-axis rotation
>>> quaternion *)
>>> qyr=Q[Cos[yr/2],0,Sin[yr/2],0]; (* Generate the Y-axis rotation
>>> quaternion *)
>>> qzr=Q[Cos[zr/2],0,0,Sin[zr/2]]; (* Generate the Z-axis rotation
>>> quaternion *)
>>> qd=qzr**qyr**qxr**qd; (* Apply the composite rotation to the current
>>> direction *)
>>> {xd,yd,zd}=SWproduct[{0,0,1},qd]; (* Sandwich product computes the
>>> direction vector *)
>>> Graphics3D[{Sphere[{xp,yp,zp},0.3],Arrow[Tube[{{xp,yp,zp},{xp,yp,zp}+7{xd
>>> ,yd,zd}},0.1]],Text["Log10 Abs Q Norm error=
>>> "<>ToString[Log[10,Abs[Norm[qd]-1]]]/2,{0,0,-11.5}]
>>> ,Text[ToString[qd],{0,0,-10}] ,Text["DirVec=
>>> "<>ToString[{xd,yd,zd}],{0,0,-13}],Text["Loc=
>>> "<>ToString[{xp,yp,zp}],{0,0,-14.5}]}
>>> ,PlotRange->{{-10,+10},{-10,+10},{-10,+10}},PlotLabel->"Translation
>>> plus
>>> Quaternion
>>> rotation",ViewPoint->Front,ViewVertical->{0,0,1},ViewCenter-
>>> >{0,0,0},View
>>> Vector->{{0,25,0},{0,-1,0}},ControllerLinking->False]]]
>>>
>>> End code. SWproduct[] uses a quaternion to rotate an ordinary vector.