thanks Dave I will pass along the info and see what they want to do...
-simon
From: David E DeMarle [dave.dema...@kitware.com]
Sent: Wednesday, September 17, 2014 12:24 PM
To: Su, Simon M CTR USARMY ARL (US)
Cc: Ben Boeckel; paraview@paraview.org
Subject: Re: [P
Ron,
Here's a fix that makes ParaView use remote-rendering irrespective of
remote-rendering threshold when volume rendering:
http://review.source.kitware.com/#/t/4672
It'd be great if you could give it a try to confirm that it works.
Thanks
Utkarsh
On Wed, Sep 17, 2014 at 10:09 AM, Utkarsh Aya
I briefly looked at that a couple of weeks ago. Sorry I didn't get back to
you before now.
My findings were:
1) xdm3writer performs the same as xdmf2writer
2) I didn't find a compression option.
So, in other words, I don't have a quick fix and someone needs to put some
development time in to impr
thanks Dave. We will remember that when we do the compile after 4.2 release...
I tried xdmf3 writer using the File->Save Data option in PV
v4.2.0-RC1-75-gf64ee7a and the 82M pvd file still turn into a 4.4G h5 file. Not
sure if something that I am not doing right? Is there like a compression flag
There are some annoying and minor differences in the XDMF xml format in the
new and old versions.
For example case sensitivity and changes in treatment of default values. My
first intuition is that these are the cause.
Jean if you can provide me with a minimal example that demonstrates the
problem
I had similar config problems in the DoD HPC machines I tested on. The root
cause was that the system boost was CMakefied and find boost didn't like it
but insisted on using it.
To get around it I downloaded my own boost (no need to compile it) and made
the my PV build use it by:
In cmakecache.txt
> All of the above work, except the ScaleFactor setter. The scale factor is
> odd anyway: in the GUI a value of 1.8 appears by default (even though
> according to the doc it should be 1.0) . Any clue ?
Certain properties update their default values based on runtime data
values. This is done by wha
Ron,
Those are good observations. I has been on my todo list to clean up
the remote-local rendering issue. I want ParaView to automatically
switch to remote rendering, if possible when volume rendering. I'll
see what I can do for that. The volume rendering code is currently
being revamped. I'd exp
Dear Utkarsh,
Thanks. That did help.
So I am having now:
...
vtkSMPropertyHelper(glyph, "Source").Set(getSphereSource(glyph));
// "scalar" = 0
// "vector" = 1
// "vector_comp" = 2
// "off" = 3
vtkSMPropertyHelper(glyph, "ScaleMode",true).Set(0);
vt
Click on the "?" button on the ParaView UI with the filter active.
That'll take you a page that will list all such "properties" available
on the filter. Additionally, you can look at these xml files[1].
Locate the proxy using the group/name and then you'll have the details
for properties on it.
Ut
Hi,
A post by Robert Atwood in June mentioned a problem with client server volume
visualisation in PV4.1, and I have also seen problems in this case both on
Linux and Windows systems.
Fixes (0014794 and 0014792) have been added to 4.2RC1 which allow correct
rendering of the wavelet test case. I
Dear Utkarsh,
thanks a lot. I made a small mistake during cmake configuration. It
works fine.
Question: Where can I find the "keywords" for
vtkSMPropertyHelper(...)
For example you used:
vtkSMPropertyHelper(cylinder,"Resolution").Set(18);
I would like to setup the glyph's settings in a si
thanks for the tip. I got the new reader compiled, but I am disappointed to see
that it crashes immediately on my existing data (which can be read in parallel,
with the old xdmf2 reader).
ERROR: In
/apps/pilatus/ParaView/src/ParaView/VTK/Common/Core/vtkDataArrayTemplate.txx,
line 148
vtkFloat
I'd recommend you use the Trace tools to see how to write the python code.
Get your data, apply the slice filter, and see how its arguments are set.
you'll end up with something like:
data = PhastaReader(FileName="view.pht")
Show(data)
slice = Slice(Input=data)
slice.SliceType = 'Plane'
slice
14 matches
Mail list logo