Yeah, that's a tough call... One issue is that with VTK you don't _have_ to call ResetCamera() most of the time for simple visualizations, so it may be that Berk's worry about newbie usage may come up off and on if people coming from VTK to ParaView are used to that behavior.
I guess, ideally, it would behave something like this: If no camera settings were altered after calling the render view constructor it would automatically reset the camera, but if a users sets them explicitly then an internal flag is set not to do the reset. I don't know how feasible that would be, or how you would decide which things to auto-set if only a subset of the camera parameters were specified... In some ways your Disable...() or Reset...=False solutions would work just fine since the current behavior works well for people just playing around on the command line, while anyone who did a Start Trace or Trace State would see the command or flag there, and it would be descriptive enough that they wouldn't just delete it without knowing what it was doing there. It would only be the people who were writing a script from scratch and adding camera controls that might not know about those commands or flags and be surprised. But, with all of the Trace functionality built in now, how big a percentage will be doing that? Talk to you later, -Eric On Apr 19, 2010, at 3:25 PM, pat marion wrote: > We could add a call such as 'DisableResetCameraOnFirstRender()' to the top of > all trace scripts. Or I could add the flag to the view constructor- view = > CreateRenderView(ResetCameraOnFirstRender=False). My first preference would > be to just get rid of the reset camera behavior. I'd have to update some of > the python tutorials to add calls to ResetCamera(). > > Pat > > On Mon, Apr 19, 2010 at 3:02 PM, Eric E. Monson <emon...@cs.duke.edu> wrote: > Hey Pat, > > I just ran up against this same problem, but with my evidently sieve-like > brain I totally forgot that you had told me the answer less than two months > ago... > > I think something really needs to be done about the "first Render() causes a > camera reset" default. I was telling my users how easy it is to set up batch > animation scripts now that there is the Trace State functionality. But, as we > were working on it I couldn't figure out why the camera wasn't being > positioned correctly even though the camera configuration gets saved right at > the beginning of the state trace with the render view parameters. > > Eventually I did an extra Render() in the command window and then things were > set up correctly after that, and I remembered... > > If the default is going to stay like this (I still completely understand the > original reasoning), then could the Trace State give an extra Render and then > the camera parameters and Render again? This falls through the cracks when a > saved state trace is run with "Run selected"... > > Thanks, > -Eric > > > On Jan 27, 2010, at 5:06 PM, Eric E. Monson wrote: > > > Hey Pat, > > > > Thanks a lot for the explanation. If all it takes is a Render() before > > setting the camera position I can handle that for now. > > > > It does seem a little inconsistent as-is, but I can understand the logic. I > > think the main disconnect for me is if that newbie user is doing what I did > > and records a trace, saves it as a macro and then plays it back next time, > > they're not going to get what they expect. > > > > Thanks again, > > -Eric > > > > On Jan 27, 2010, at 4:57 PM, pat marion wrote: > > > >> Hi Eric, > >> > >> This is by design. When calling Render() from python, if this is the > >> _first_ render for this render window, ResetCamera() is called > >> automatically. Your script will work if you insert a Render() before > >> you set the camera position. > >> > >> When Berk first wrote the paraview.simple api he wanted to avoid this > >> scenario: > >> > >> Newbie user creates their data and calls Render(), but sees a black > >> screen because he/she forget to call ResetCamera(). > >> > >> But now we have this scenario: > >> > >> Advanced user carefully sets the camera properties and calls > >> Render() only to find the camera reset :( > >> > >> > >> I vote we change behavior. > >> > >> Pat > >> > >> > >> > >> On Wed, Jan 27, 2010 at 4:33 PM, Eric E. Monson <emon...@cs.duke.edu> > >> wrote: > >>> Hello, > >>> > >>> First of all, I've been playing around with the new python interface and > >>> trace functionality in PV, and it's really a great improvement! > >>> > >>> But... :) It seems like the first time I run a macro (from the PV python > >>> shell "Run selected" button) which contains some camera adjustments, the > >>> camera gets reset at the end. If I delete all of the pipeline elements > >>> and run it again without restarting PV or pressing Disconnect, the scene > >>> ends up with the correct camera settings. If I disconnect before running > >>> it again, the "reset at end" behavior is repeated. The same thing happens > >>> when running in ipython, outside of PV. > >>> > >>> Here's a sample script -- if the camera settings are correct you should > >>> not see space around the group of glyphed points (it is zoomed in a bit > >>> on the cluster): > >>> > >>> # ============================= > >>> try: paraview.simple > >>> except: from paraview.simple import * > >>> > >>> PointSource2 = PointSource() > >>> PointSource2.Radius = 200.0 > >>> PointSource2.NumberOfPoints = 100 > >>> > >>> Glyph1 = Glyph( GlyphType="Sphere" ) > >>> Glyph1.MaskPoints = 0 > >>> Glyph1.RandomMode = 0 > >>> Glyph1.SetScaleFactor = 1.0 > >>> Glyph1.ScaleMode = 'off' > >>> Glyph1.Orient = 0 > >>> Glyph1.GlyphType.Radius = 5.0 > >>> > >>> DataRepresentation2 = Show() > >>> > >>> RenderView1 = GetRenderView() > >>> RenderView1.CameraViewUp = [0.01, 1.0, -0.06] > >>> RenderView1.CameraPosition = [37.0, 190.5, 640.7] > >>> RenderView1.CameraClippingRange = [91.9, 1018.7] > >>> > >>> Render() > >>> # ============================= > >>> > >>> The main problem is that this keeps me from using the python macros like > >>> the old lookmarks because I don't get a repeatable camera view right > >>> after starting up PV. > >>> > >>> I'm using CVS ParaView from Jan 19 on OS X 10.6.2 built with CMake > >>> 2.9.20100113. > >>> > >>> Thanks, > >>> -Eric > >>> > >>> ------------------------------------------------------ > >>> Eric E Monson > >>> Duke Visualization Technology Group > >>> > >>> > >>> > >>> _______________________________________________ > >>> Powered by www.kitware.com > >>> > >>> Visit other Kitware open-source projects at > >>> http://www.kitware.com/opensource/opensource.html > >>> > >>> Please keep messages on-topic and check the ParaView Wiki at: > >>> http://paraview.org/Wiki/ParaView > >>> > >>> Follow this link to subscribe/unsubscribe: > >>> http://www.paraview.org/mailman/listinfo/paraview > >>> > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Please keep messages on-topic and check the ParaView Wiki at: > > http://paraview.org/Wiki/ParaView > > > > Follow this link to subscribe/unsubscribe: > > http://www.paraview.org/mailman/listinfo/paraview > >
_______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
