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.