In ParaView 3.6.2 it appears to be still impossible for a filter to have
output extent different than input extent.
Here is a relatively recent post from someone with the same issue.
http://markmail.org/message/frmcm2wnce3ye6ae
Is there any suggested work-around for this?
As a demonstration, I
Following this thread: http://markmail.org/message/f25hi3bl6ldptzav , I'd just
like to add that I get exactly the same error.
Namely, we have a number of plugins that compile and load on Linux and on OS-X,
but on Windows XP we get a "is not a valid Qt plugin" error when we attempt to
load them.
Thanks. I've added a note to that effect in the wiki.
Eric.
On 2010-02-02, at 11:22 AM, Utkarsh Ayachit wrote:
>>> As a side note, I attempted to set the environment variable
>>> PV_PLUGIN_DEBUG as described at
>>> http://paraview.org/Wiki/Plugin_HowTo#Debugging_Plugins in order to obtain
>>>
dows
.
Thanks,
Eric
On 2010-02-02, at 11:08 AM, Dave Partyka wrote:
> I think you get this error if you're missing a dll at runtime? If you place
> your plugin in the bin dir of your build and load it from there does it work?
>
> On Tue, Feb 2, 2010 at 12:44 PM, Eric Nodwell
Eric,
I have a couple of questions about building paraview with x86_64 architecture
on OS-X:
1. You recommend building Qt 4.6.2 from source, but there is a binary version
build with x86_64 and Cocoa available from
http://qt.nokia.com/downloads/mac-os-cpp (the file is
qt-mac-cocoa-opensource-
When building ParaView 3.8.0 RC2 on OS-X, I run into the following:
/Users/eric/source/ParaView-3.8.0-RC2/Plugins/VisTrails/PluginMain.cxx: In
member function ‘void PluginMain::Startup()’:
/Users/eric/source/ParaView-3.8.0-RC2/Plugins/VisTrails/PluginMain.cxx:170:
error: redeclaration of ‘const
The web page with the build details,
http://www.paraview.org/Wiki/ParaView_Binaries , seems to be a bit out of date:
- In the 3.8.0 section, most of the entries are labeled as 3.6.2, for example
"paraview-3.6.2-Linux64-x86.tar.gz". I think this is probably a case of
mis-labelling, since the de
and the Cocoa
version of Qt for ParaView-3.8.0-RC2-Darwin-x86_64.dmg , but it would be nice
not to have to guess.
Eric
On 2010-05-13, at 9:50 AM, Dave Partyka wrote:
> Humm I will take a look.
>
> On Thu, May 13, 2010 at 11:49 AM, Eric Nodwell wrote:
> The web page with the b
Is there some file, distributed with ParaView binaries, that specifies the
particular versions of libraries that the ParaView binary was built with? This
would make it easier to build plug-ins that can be used with the binary
versions available from the ParaView download page.
The required inf
What is the standard way to represent image data in VTK/ParaView, where the
image data is intended to represent finite sized voxels? Here the 3D image
data represent values at the centre of voxels (or presumably some sort of
weighted value centred on the voxel centre).
This may seem like a tri
Francois,
Thank you for the reply.
Using 2x2x2 points for one voxel is fine in principle. The difficulty is, you
can't really conveniently (as far as I can tell) use a vtkImageData object for
this purpose. Because now of course our scalar image data needs to be
associated with cells, not to
ls with the
>> scalar data attached to the PointData.
> Could you use the concept of a dual grid? In other words make your vis grid
> node centered with the nodes located on the cell centers of your
> computational grid? Your arrays end up in PointData that way with no
> interpo
ve cell data, instead you have point data, which is
> what vtk needs.
>
> I am attaching an illustration from an 2d cell centered AMR grid, but the
> idea is the same for 3D cell centered data on a uniform grid. See figs a and
> d.
>
> Burlen
>
>
> Eric Nodwe
rs,
Eric
On 2010-06-02, at 10:30 AM, burlen wrote:
>
>> However, it is still necessary to use scalars on CellData to get correct
>> rendering.
> What specifically isn't correct when rendering with point vs cell data? As
> far as I know both approach are equally vali
I'm having some linking issues building our custom external libraries into
ParaView.
The background is, we have the following:
1. a custom library (vtkskiIO) , and
2. some ParaView plugins that use classes out of vtkskiIO .
These can be built, loaded and run successfully when they are built not
Thanks Michael. That did it - well 90% of it. The other 10% was also adding a
PARAVIEW_FILTERS_INCLUDE_DIRECTORIES command to specify the directory with .h
files for our plugins.
Eric
On 2010-06-07, at 11:21 AM, Michael Jackson wrote:
> SET (PARAVIEW_ADDITIONAL_LIBRARIES
>${PARAVIEW_ADDI
that should be included.
There is evidently a solution, since the official ParaView binaries for OS-X do
in fact include libQtCLucene.4.dylib in the App bundle. Anyone have any
insight how this is achieved?
Thank you in advance for any insight
x27;t copy in dependencies installed in
> system locations such as /usr/lib, otherwise it would copy in your whole
> operating system through dependency resolution ;-).
>
> If you want to make a bundle then you'll have to use/build a Qt not installed
> in /usr/blah
>
>
After unpacking ParaView-4.4.0-Qt4-Linux-64bit.tar.gz I was unable to
launch it. Attempting to launch it from the command line resulted in:
$ /opt/ParaView-4.4.0-Qt4-Linux-64bit/lib/paraview-4.4/paraview
/opt/ParaView-4.4.0-Qt4-Linux-64bit/lib/paraview-4.4/paraview: error
while loading shared libr
Oops, correction to that previous post. The actual fix (bit of a
sledgehammer) is
sudo chmod -R a+rx /opt/ParaView-4.4.0-Qt4-Linux-64bit/
On Tue, Sep 15, 2015 at 3:34 PM, Eric Nodwell
wrote:
> After unpacking ParaView-4.4.0-Qt4-Linux-64bit.tar.gz I was unable to
> launch it. Attempt
20 matches
Mail list logo
