Hi Eric, I just committed a change to trace so that it inserts this line at the top of all generated scripts:
paraview.simple._DisableFirstRenderCameraReset() It's not the ideal solution, but it resolves the problem for now. Maybe we'll come up with something better in the future. Pat On Mon, Apr 19, 2010 at 4:43 PM, Eric E. Monson <emon...@cs.duke.edu> wrote: > 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