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
