[Paraview] Extra camera reset in python macro

Thu May 20 13:01:53 EDT 2010

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 <emonson at 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 <emonson at 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 <emonson at 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
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20100520/de371204/attachment-0001.htm>