Re: [Paraview] patch for 9485 Save camera position

Fri, 26 Feb 2010 10:46:23 -0800 

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.lor...@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-boun...@paraview.org
[mailto:paraview-boun...@paraview.org] On Behalf Of Utkarsh Ayachit
Sent: Friday, October 30, 2009 4:25 AM
To: Bam Ting
Cc: bastil2...@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 <bampingt...@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, bastil2...@yahoo.de
<bastil2...@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, bastil2...@yahoo.de
<bastil2...@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: agaglia...@ara.co.uk
Url: www.ara.co.uk
-----Original Message-----
From: paraview-boun...@paraview.org
[mailto:paraview-boun...@paraview.org]
On Behalf Of bastil2...@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


      



    




_______________________________________________
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