[Paraview] patch for 9485 Save camera position
burlen
burlen.loring at gmail.com
Mon Feb 15 13:39:37 EST 2010
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