That sounds great, Pat -- thanks for letting me know.

Talk to you later,
-Eric


On May 20, 2010, at 1:01 PM, pat marion wrote:

> 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

Reply via email to