@paraview.org
Objet
Re: [Paraview] Concept: A world without the Apply button
Sam,
Please note that this proposal does not preclude the user from
choosing which array to load from the reader's properties panel. That
indeed will be supported. This proposal in fact allows you go back the
reader
A
samuel...@bresnan.net
cc
paraview@paraview.org
Objet
Re: [Paraview] Concept: A world without the Apply button
Sam,
Please note that this proposal does not preclude the user from
choosing which array to load from the reader's properties panel. That
indeed will be supported
: [Paraview] Concept: A world without the Apply button
Stephane,
Yes, that'd indeed be a path forward, but like you alluded to, it would need a
planning of its own especially adding support to the executive, being smart
about when to re-execute, and even possibly, cache arrays.
Utkarsh
On Wed
One thing that strikes me about this proposal, is that it relies a lot on
VTK readers/filters providing the necessary meta data, particularly about
fields. For example, the elevation filter would have to report in its
meta data that it will be adding a scalar field named Elevation. That
sounds
All--
Technical reasons aside, my own simulation efforts (software that relies
on ParaView for post-processing) span a great variety of solid and
structural mechanics applications. The software is not a
single-formulation, single-solution, one-off problem solver.
Put briefly, I find the
Sam,
Please note that this proposal does not preclude the user from
choosing which array to load from the reader's properties panel. That
indeed will be supported. This proposal in fact allows you go back the
reader change it's array selection, and then go the properties panel
for a contour
Is there a way to mitigate the issues with the meta data mismatching what
is actually generated? Perhaps there could be a check to make sure that
the data generated matches the meta data previously reported and issue a
warning if there are any mismatches. This would not solve the problem per
Folks,
I have been investigating the ability to create pipelines in ParaView
without having to hit Apply at every single stage in the pipeline.
This would make it much easier to deal with really large data in a
usage scenario where the scientist is fairly familiar with the
visualization pipeline
Hi Utkarsh,
I like the idea. One possible problem that comes to mind is filters
that produce different output types based on the input. Will enough of
the metadata be passed through the pipeline before Execute() is called
for those filters to hint at their output type? Otherwise, you'll be
I like the idea. One possible problem that comes to mind is filters
that produce different output types based on the input. Will enough
of the metadata be passed through the pipeline before Execute() is
called for those filters to hint at their output type? Otherwise,
you'll be forced to
Dave,
Output types become a problem only for composite-datasets, for others
data-types are known after RequestDataObject pass which happens before
RequestData(). I am still not sure how (or if) to deal with composite
datasets in this case. We can expect the reader to give meta-data for
composite
Utkarsh,
I agree that composite readers (and probably other composite filters)
can provide the dataset structure in the RequestDataObject pass, but I
don't know that many currently do. Certainly the ExodusIIReader
doesn't. It would be easy enough to provide an empty hierarchy of *all
the
12 matches
Mail list logo
