This code is all new hence the change. On the plus side if you moved from
4000 blocks of 10 triangles each to 4000 blocks of 1 triangles each the
rendering performance would probably not slow down. The overhead is all in
starting and stopping each of those 4000 mappers.
The old backend wrote
Hi Ken and Utkarsh, Checking back in with this issue... I still find that
interaction with the g-2 ring in ParaView v5rc2 is very slow compared to
v4.4. It looks like you all have a solution in mind. I'm happy to build
from master to try it if the solution is there. Thanks again and Happy
Sadly it still crashes immediately after showing the splash screen without
much information.
I tried the -dr argument in the command line, but without success either.
Any idea of what could be wrong? I also have issues displaying axes labels
on Paraview 4.4. I suspect some video driver problem,
Hi Ken - thanks for your reply. It's looking like the last approach - I
figure out why I'm getting different blocks - is the way to go. It's
already clear that not all of the blocks have colors. Some of the blocks
are created by vtk sources (e.g. VtkConeSource) and others are created by
hand (me
I don't really have a solution planned for that case. The data size is
trivially small but it falls into the slow path because each block of data
may or may not have normals or colors or tcoords. The nature of the blocks
is heterogeneous. So you end up with 4000 mappers each rendering 10
Folks,
I am trying to see if there are any objections to dropping 32 bit
Windows binaries for the 5.0 release. We'll still distribute the 64
bit Windows binaries.
Thanks
Utkarsh
___
Powered by www.kitware.com
Visit other Kitware open-source projects
On Wed, Dec 16, 2015 at 13:22:09 -0600, Adam Lyon wrote:
> I'm curious as to why I didn't have any of these problems in v4.4 -- or is
> this two path multiblock rendering code all new for v5? Thanks again!! --
4.4 defaults to the OpenGL1 backend (glBegin/glEnd); 5.0 is using the
OpenGL2 backend
The issue is indeed that your OpenGL drivers are old. We're working on
something that will catch this and report it in a more graceful way.
Utkarsh
On Wed, Dec 16, 2015 at 3:12 PM, Fernando G. del Cueto wrote:
> Sadly it still crashes immediately after showing the splash
It isn't easy to get the the values, because the client only accesses
proxies for the filters and data objects, which often exist on remote
distributed memory parallel machines.
Three strategies:
1) write a python programmable filter. That runs in parallel on remote
machines and has access to the
On Tue, Dec 15, 2015 at 6:58 AM, Anton Shterenlikht
wrote:
> At first glance, yes, this is what I'm after.
> I'll read the manuals, but briefly, is this just
> paraview functionality via library calls?
>
Roughly yes. A "full" catalyst installation is just ParaView's
Last time this came up to my knowledge was:
http://markmail.org/thread/pbghkrm2zbubkj54
od = self.GetOutput()
od.ShallowCopy(self.GetInput())
cta = vtk.vtkIntArray()
cta.SetName("cell types")
cta.SetNumberOfComponents(1)
cta.SetNumberOfTuples(od.GetNumberOfCells())
od.GetCellData().AddArray(cta)
Hello,
the Python VTK script below gives results, like a expect. Now I'm trying to
reproduce it in Paraview and I fail.
I get rather confused as soon I give it a source with more than one scalar
component.
Paraview creates one color map; I would expect 3 color maps, 1 for every
component.
What
Axel
We were just discussing this few days ago. Do you have to use paraview gui? Or
paraview python will work? There might be a way in pv python route.
Thanks
Sent from my iPhone
> On Dec 16, 2015, at 5:01 AM, Axel Kittenberger wrote:
>
> Hello,
>
> the Python VTK
Thanks for the helpful tips.
First approach has the disadvantage that I need to specify the underlying
points in each of the separate files, which leads again to some redundancy. But
good to know.
EnSight format looks promising though, I didn't know about it before.
Thanks again,
Viktor
14 matches
Mail list logo