Hi ,
I got an error message when trying to do volume rendering on the output
of the ResampleToImage filter:
ERROR: In
/home/user/apps/paraview5.2.0-build/superbuild/paraview/src/VTK/Rendering/OSPRay/vtkOSPRayVolumeMapperNode.cxx,
line 107
vtkOSPRayVolumeMapperNode (0x68c2ad0):
Upon loading an annotated .vtu file with TimeStep annotations such as this into
Paraview 5.2.0 (under 64 bit SUSE Linux):
I see the following:
[cid:image001.png@01D27342.72FDFF10]
such that a maximum of 4095 time steps are available, as opposed to the
expected 10,560 time steps.
When the
Hi Claude,
I'm glad you like our doc and code. If you feel we are missing something
that is not obvious, please report it so we can fix it.
Regarding your issue, you had a good reflex in fixing apache and the
launcher config, as with PV5.2 we use a second ws connection for streaming
the images
Sounds like a bug? Could you create a dataset that replicates the issue, that
is reasonably small in size? I.e., with one cell or point?
Alan
> -Original Message-
> From: ParaView [mailto:paraview-boun...@paraview.org] On Behalf Of
> Adam Hill
> Sent: Wednesday, January 18, 2017
thank you very much for the hint. I solved it via
set(CTEST_BUILD_COMMAND „/usr/bin/make")
in the .ctest file.
Fabian
> Am 19.01.2017 um 17:26 schrieb Ben Boeckel :
>
> On Thu, Jan 19, 2017 at 11:35:30 +0100, Fabian Wein wrote:
>> I have a strange error. The issue is
It is legal to create an exodus file with no nodes and no elements. If that
file is part of a parallel set (using file-per-processor mode), then that
“empty” file should have consistent metadata (block counts, sideset counts, …),
but it is allowed to have zero nodes and elements.
..Greg
--
That is rather unfortunate - I guess that I misunderstood what the commits were
doing.
On the bright side: at least I have a definitive statement about what works and
what doesn't.
Many thanks for the quick answer.
/mark
From: Utkarsh Ayachit
To the best of my knowledge, that's not possible, it's not possible to
have GPU accelerated OpenGL and OSMesa in the same build of ParaView.
You have to do separate builds. ParaView does support using osmesa and
libGL provided by Mesa itself in the same build, but that won't be
using GPU, in that
Hi Niklas,
unfortunately sampling distance is currently not exposed as a UI setting.
You could make the
following changes in order to decrease the sampling distance,
VTK/Rendering/VolumeOpenGL2/vtkSmartVolumeMapper.cxx
ln. 91 -- comment
Mark,
Can you elaborate? When you say opengl + osmesa, do you mean as in
Mesa+X and OSMesa ?
Utkarsh
On Thu, Jan 19, 2017 at 10:34 AM, Mark Olesen wrote:
> From commits it looks like
> http://www.paraview.org/Wiki/ParaView/ParaView_And_Mesa_3D isn't up-to-date.
>
>From commits it looks like
>http://www.paraview.org/Wiki/ParaView/ParaView_And_Mesa_3D isn't up-to-date.
>Can someone offer the cmake variable combinations that I need to compile a
>combined build with both opengl + osmesa? If this works well, I'd like to be
>using that sooner rather than
Dear Paraview,
I tried to extend my VTU writer to write into binary format. I have tried
either writing floats using Float32 format and doubles using Float64 format,
both fail the same way. I write into binary by using
file.write( (char*) , sizeof(BinaryType));
In both cases, Paraview
Hello,
I have a strange error. The issue is not very important, just a nice
to have.
I have a simple project building paraview-superbuild as external
project which includes applying two simple patches
(add building of the libs boost_filesystem and hdf5_cpp) and our
external plugin.
When
13 matches
Mail list logo