[Paraview] patch for 9485 Save camera position
burlen
burlen.loring at gmail.com
Fri Feb 26 13:48:05 EST 2010
Hi Utkarsh,
I hadn't heard back from you in a couple weeks & I saw you asking about
usability improvements, I think saving camera configuration as in the
patch I sent in with this thread is a good one :)I'm hoping not to let
this slip through the cracks. What can I do to make this happen
(assuming you still like the idea) ?
Thanks
Burlen
burlen wrote:
> Hi Utkarsh,
>
> finally I have a chance to take a look at this in depth and get back
> to you.
>> What can't configuration merely be a subset of
>> the state i.e. same as the state xml for that proxy except with only
>> the required properties?
> The difference between state and configuration goes beyond the latter
> being a simple subset of the proxy's properties.
>
> One substantial difference is that connection id is central in the
> state implementation. however not only is it not needed for
> configuration but it cannot be used with configuration. So for
> configuration the lack of a connection id is a central feature.
>
> Another distinction is that the state of domains aren't needed by
> configuration.
>
>> The main advantage will be that we don't have
>> another serialization "format" to handle.
> Yes, that's a fair point. We could pretty easily make use of the
> lowest level of the state implementation,
> vtkSMXXVectorProperty::SaveChildState and
> vtkSMXXVectorProperty::LoadState, if they were public methods. Why
> aren't these public methods? Will it be OK to make them public? And
> what about the name SaveChildSate, why not just SaveState?
>
> I didn't go down this road in large part because I know how important
> state is to PV, know changing the implementation is sensitive and
> involved task, and didn't want to tackle it without your input. But
> there were also a couple other motivations for a new format and
> implementation.
>
> In regard to the current state implementation and file format, the
> file format is fairly inefficient for example each value in a property
> vector is written to disk as a nested xml element (ie a vector with
> 256 values, requires 257 xml elements). Also in terms of the
> implementation it's very fragile , you modify a state file by hand and
> make a mistake and it crashes PV during the load. I've also seen PV
> crash loading state across major PV versions. All of these facts
> dampened my enthusiasm for making use of the current state
> implementation and motivated to me to provide the new format and fault
> tolerant implementation.
>
> I implemented validate methods
> (vtkSMXXVectorProperty::ValidateConfiguration) that will parse the XML
> and validate it without making any changes to the property. This is
> key to a fault tolerant implementation, the manager can then validate
> the configuration before applying it. I specifically wanted to prevent
> a partial load that will leave the property in an indeterminate state.
>
> I think these features are important, nothing is more frustrating
> than going to load a state file and having PV crash. If we make use of
> the current state vtkSMXXVectorProperty::SaveChildState and
> vtkSMXXVectorProperty::LoadState for reading and writing the
> configuration XML we'll still want the validate function don't you think?
>> Plus, you can directly use
>> the state loading infrastructure to load the configuration without
>> having to write the configuration loader classes.
> My implementation in its current form one does indeed have to
> implement two classes, one reader and one writer. But this involves a
> minimal effort of implementing the following methods from
> vtkSMProxyConfigurationReader/Writer to return various cstrings.
>
> virtual const char *GetFileExtension()=0;
> virtual const char *GetFileIdentifier()=0;
> virtual const char *GetFileDescription()=0;
> virtual const char *GetReader/WriterVersion(){ return "1.0"; }
>
> I think it makes sense to require an implementor to provide this meta
> data. These are mostly used for high level file validation and to
> make the file dialog work and error reporting meaningful, but also
> make the file format more human friendly. Beyond implementing these
> three methods no coding is needed, because one can can provide a list
> of property names to operate on at any time using the
> vtkSMPropertyConfigurationManager base class interface.
>
> In the case of the camera configuration, it made sense to have a
> specialized reader implementation vtkSMCameraConfigurationReader that
> could also handle updating the view after a configuration was loaded
> and it was convenient to provide the list of property names in the
> constructor. Providing this list in the constructor is the simplest
> way for specialized implementations. That doesn't neccessarilly
> preclude a more general use case. For example for something more
> general like a reader writer pair for PV's geometric sources, only the
> three pure virtual mothods mentioned above would be implemented, and
> we would provide property names on the fly as the panels are decorated.
>
> The current implementation makes it possible for custom panel
> implementors to simply implement their own configuration reader writer
> pair as needed. I think that's an important feature of any solution
> that we come up with.
>
> Not to get too far ahead of myself, here, just want to explain some of
> my thinking in more depth than I did originally.
>
>> Also, one of the reasons for the existence
>> vtkSMProxyConfigurationManager seems to be the fact that state loading
>> results in creating of new proxies, but then, that's not necessarily
>> true. State can be loaded on existing proxies as well -- we do that
>> for undo-redo.
> I think we still have the issues surrounding the connection id which
> is not used in configuration.
>
> OK, let me know what you think, thanks for working with me on this.
>
> Burlen
>
> Utkarsh Ayachit wrote:
>> Burlen,
>>
>> That's really cool. I like the the notion of "configuration", but I
>> have a few questions. What can't configuration merely be a subset of
>> the state i.e. same as the state xml for that proxy except with only
>> the required properties? The main advantage will be that we don't have
>> another serialization "format" to handle. Plus, you can directly use
>> the state loading infrastructure to load the configuration without
>> having to write the configuration loader classes.
>>
>> Also, one of the reasons for the existence
>> vtkSMProxyConfigurationManager seems to be the fact that state loading
>> results in creating of new proxies, but then, that's not necessarily
>> true. State can be loaded on existing proxies as well -- we do that
>> for undo-redo. The trick is provide the right vtkSMProxyLocator (or a
>> subclass) (if I remember correctly).
>>
>> What do you think?
>>
>> Utkarsh
>>
>> On Mon, Jan 25, 2010 at 2:40 AM, burlen <burlen.loring at gmail.com> wrote:
>>
>>> Sorry to resend this, but the attachments were too big for the list.
>>> I put
>>> them here: http://nashi-submaster.ucsd.edu/movies/PV/save-cam-config/
>>>
>>>
>>> Hi all,
>>>
>>> The attached patch is for fetaure 9485 Save camera position(
>>> http://public.kitware.com/Bug/view.php?id=9485 ) . This solution
>>> provides a way of converting the camera configuration into an XML
>>> stream
>>> which can then be either: stored in PV's internal settings to be later
>>> accessed by one of 4 camera dialog buttons; or written to a file to be
>>> later read back in. I attached screen shots of the modified camera
>>> dialog and custom view button configuration dialog so you can take a
>>> quick look and see what this is all about. Is this something I can
>>> commit as is? If not what needs to change?
>>>
>>> A little about the implementation follows and I'd like to propose
>>> adding
>>> a related feature, the ability to individually save and load
>>> configuration of PV's geomtry sources (point, line, plane, sphere
>>> etc...).
>>>
>>> Saving and loading the camera configuration is a special case of a more
>>> general missing feature, that of saving and loading a subset of an
>>> individual proxy's properties. I am calling this configuration.
>>> Something like state but much simpler, lighter and more portable. With
>>> that in mind, rather than make a one off camera configuration
>>> reader/writer, I took a more general approach in my solution and
>>> implemented camera configuration reader/writer pair from abstract
>>> "proxy
>>> configuration" reader/writer base classes. A simple way to use these
>>> proxy configuration classes is to implement a derived class, and in the
>>> constructor initialize the list of properties that will comprise the
>>> configuration. The base classes can then handle the validation and
>>> IO of
>>> the XML hierarchy. Using these classes one could also do something
>>> similar to save and load any subset of any proxy's vector properties
>>> pretty easily.
>>>
>>> My intentions is that configuration can step in for state in the cases
>>> where state is overkill, or doesn't work. For instance when trying to
>>> reproduce a figure on a different cluster the most crucial aspects are
>>> often the positioning of geometric sources and the camera. these are
>>> also often the most difficult to recreate by hand since they require
>>> precise positioning. unlike state, configuration is not tied to a
>>> specific cluster or connection. It also provides a quick way to
>>> duplicate a source in the same session. A configuration file depends
>>> only on a single proxy minimizing the risk of backward incompatibility
>>> over time.
>>>
>>> the gist of the approach I have in mind to expose this functionality
>>> for
>>> PV's geometry sources would be by way of a qt widget containing a load
>>> and a save button placed in the object inspector auto generated panels.
>>> The widget would only be added if the SM XML requested it. The XML
>>> would
>>> be something like this:
>>> <SourceProxy ...>
>>> ...
>>> <ConfigurationManagerProperty>
>>> <PropertyDomain name="managed_properties" values="..."
>>> </ConfigurationManagerProperty>
>>> ...
>>> </SourceProxy>
>>> The XML would be added to each of the geometry sources. The properties
>>> that make up the configuration of an individual source would be
>>> explicitly listed in the managed_properties attribute and passed into
>>> the geometry source configuration reader/writer objects which would be
>>> derived from vtkSMProxyConfigurationReader/Writer in the attached
>>> patch.
>>>
>>> Is this going to be a committable feature? Comments and feedback are
>>> much appreciated. I know its a really small feature, but I think it
>>> will
>>> improve the user's experience, and resolve some frustrations with
>>> state.
>>>
>>> Thanks
>>> Burlen
>>>
>>>
>>> Scott, W Alan wrote:
>>>
>>>> I just wrote this one up as bug number 9805. We really should have
>>>> this
>>>> functionality in ParaView.
>>>>
>>>> Thanks for catching this one.
>>>>
>>>> Alan
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: paraview-bounces at paraview.org
>>>>> [mailto:paraview-bounces at paraview.org] On Behalf Of Utkarsh Ayachit
>>>>> Sent: Friday, October 30, 2009 4:25 AM
>>>>> To: Bam Ting
>>>>> Cc: Bastil2001 at yahoo.de; ParaView
>>>>> Subject: Re: [Paraview] Save camera setting paraview 3.6.1
>>>>>
>>>>> I agree. We lost this functionality in transition to ParaView 3.0
>>>>> from
>>>>> 2.6. Please feel free to add it to the bug tracker so that we
>>>>> consider it
>>>>> for the next major release.
>>>>>
>>>>> Utkarsh
>>>>>
>>>>> On Wed, Oct 28, 2009 at 6:35 PM, Bam Ting <bampingting at gmail.com>
>>>>> wrote:
>>>>>
>>>>>
>>>>>> Why no option to save/restore a camera state by click a
>>>>>>
>>>>> button? I want
>>>>>
>>>>>> use this many time!! My feeling--It a little silly to make us use a
>>>>>> python feature for idea so basics.
>>>>>>
>>>>>>
>>>>>> On Wed, Oct 28, 2009 at 11:26 AM, Bastil2001 at yahoo.de
>>>>>> <Bastil2001 at yahoo.de>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>> Thanks. However, since I have Paraview 3.6.1 this is not
>>>>>>>
>>>>> possible for
>>>>>
>>>>>>> me. Maybe I will have to switch since this python state
>>>>>>>
>>>>> files seem to
>>>>>
>>>>>>> be very helpful. What is the difference betwwen the curren
>>>>>>>
>>>>> cvs and 3.6.2?
>>>>>
>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> BastiL
>>>>>>>
>>>>>>> pat marion schrieb:
>>>>>>>
>>>>>>>
>>>>>>>> Try this (assuming you have paraview cvshead or 3.6.2):
>>>>>>>>
>>>>>>>> build your pipeline
>>>>>>>> open python dialog
>>>>>>>> click on trace tab
>>>>>>>> click start trace
>>>>>>>> move the camera how you want it
>>>>>>>> click stop trace
>>>>>>>> click save trace
>>>>>>>> click on the directory view tab, you should see a new python
>>>>>>>> script,
>>>>>>>> you can select it and click Run Selected
>>>>>>>>
>>>>>>>> Pat
>>>>>>>>
>>>>>>>> On Wed, Oct 28, 2009 at 2:12 PM, Bastil2001 at yahoo.de
>>>>>>>> <Bastil2001 at yahoo.de> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Maybe - however I do not know how to get the trace and
>>>>>>>>>
>>>>> what to do
>>>>>
>>>>>>>>> with the output?
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>>
>>>>>>>>> BastiL
>>>>>>>>>
>>>>>>>>> Adriano Gagliardi schrieb:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Does the trace functionality not output the camera
>>>>>>>>>>
>>>>> settings for
>>>>>
>>>>>>>>>> you in python?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ===================================
>>>>>>>>>>
>>>>>>>>>> Adriano Gagliardi MEng PhD
>>>>>>>>>> Project Scientist
>>>>>>>>>> Computational Aerodynamics
>>>>>>>>>> Aircraft Research Association Ltd.
>>>>>>>>>> Manton Lane
>>>>>>>>>> Bedford
>>>>>>>>>>
>>>>>>>>>> Tel: 01234 32 4644
>>>>>>>>>> E-mail: agagliardi at ara.co.uk
>>>>>>>>>> Url: www.ara.co.uk
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: paraview-bounces at paraview.org
>>>>>>>>>> [mailto:paraview-bounces at paraview.org]
>>>>>>>>>> On Behalf Of Bastil2001 at yahoo.de
>>>>>>>>>> Sent: 28 October 2009 17:38
>>>>>>>>>> To: 'ParaView'
>>>>>>>>>> Subject: [Paraview] Save camera setting paraview 3.6.1
>>>>>>>>>>
>>>>>>>>>> This has been discussed some time before but I have no
>>>>>>>>>>
>>>>> solution
>>>>>
>>>>>>>>>> so far.
>>>>>>>>>> I think lookmarks are intended to do this, right?
>>>>>>>>>>
>>>>> However, for me
>>>>>
>>>>>>>>>> they always re-create certain parts of the pipe and I
>>>>>>>>>>
>>>>> only want
>>>>>
>>>>>>>>>> to restore a view. How can this be done? Thanks.
>>>>>>>>>>
>>>>>>>>>> BastiL
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------
>>>>>>>>>> This email contains information that is private and
>>>>>>>>>>
>>>>> confidential
>>>>>
>>>>>>>>>> and is intended only for the addressee. If you are not the
>>>>>>>>>> intended
>>>>>>>>>> recipient please delete it and notify us
>>>>>>>>>>
>>>>> immediately by e-mailing the sender.
>>>>>
>>>>>
>>>>>>>>>> Note: All email sent to or from this address may be
>>>>>>>>>>
>>>>> accessed by
>>>>>
>>>>>>>>>> someone other than the recipient, for system management and
>>>>>>>>>> security
>>>>>>>>>> reasons.
>>>>>>>>>> Aircraft Research Association Ltd. Registered in England,
>>>>>>>>>> Registration No 503668 Registered Office: Manton Lane,
>>>>>>>>>> Bedford MK41 7PF
>>>>>>>>>> England VAT No GB 196351245
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>
>>>
>
More information about the ParaView
mailing list