Ken,
I tested your changes and they are working for my more complicated
"production" case. I am currently running more tests and will update you
if anything goes wrong.
I'm still adjusting my lighting settings from 4.4.0 to 5.x.x to get similar
images between the two versions. In the past with
Thanks so much for the example. I have a VTK topic that I believe will fix
the issue here:
https://gitlab.kitware.com/vtk/vtk/merge_requests/2463
It fails three of the current paraview LIC tests but with images that still
look reasonable (although one looks dark to me). The changes only impact
tw
Ken,
I've attached a small example file and script that demonstrates the problem.
The example dataset is a multiblock unstructured grid with two blocks. The
script attempts to create two images of slices through the dataset. At the
first slice position data from both blocks are in the slice. A
Thanks Andy, just to make sure I understand the issue. Is the case that one
processor has no data, or is it that it has data, but it is outside the
current view?
Thanks
Ken
On Thu, Feb 2, 2017 at 5:14 PM, Andy Smith wrote:
> I've tested this with the latest ParaView and it does seem to run much
I've tested this with the latest ParaView and it does seem to run much
faster.
I am having a problem when running in parallel though. If one processor
does not have anything to display, the rendering hangs.
Related to that, what routine actually calls
vtkCompositeLICHelper::RenderPiece?
The proces
There is a VTK topic now that should fix this regression. With this change
OpenGL2 LIC seems to run much faster (at least 10X).
https://gitlab.kitware.com/vtk/vtk/merge_requests/2419
Hopefully it will test out OK and get merged into VTK and then merged into
ParaView.
On Mon, Dec 12, 2016 at 11:3
Chuck and Ken,
I really appreciate you both following up with me. I will have some time
this week to update my osmesa builds for a proper 4.4.0 vs 5.2.0 comparison
and I will try out the EGL option; I honestly forgot that it was available.
Hopefully I will have more to report back soon.
Thanks,
Hi Andy,
I realized after posting that my comparison is not exactly apples to apples
> - my build of 5.2.0 required updates to mesa (13.0.0) compared with the
> version I used for 4.4.0 (11.2.0).
> I will recompile 4.4.0 with the same mesa version I used with 5.2.0 and
> report back.
>
...
> Has
Thanks for trying it out. I do want to fix the compositeLic to be fast as
well. It just has to be reworked to use the new always fast
compositePolyDataMapper2 approach. I hope to get to it early next year.
Just wanted to let you know.
Thanks
Ken
On Mon, Dec 12, 2016 at 11:38 AM, Andy Smith
Ken,
You are correct in your assumption about my dataset; it is multiblock
unstructured data. Adding a MergeBlocks filter to my slice does improve
the 5.2.0 with OpenGL2 significantly.
With that change the performance of 5.2.0 with OpenGL2 is on the same order
of magnitude as 5.2.0 with OpenGL an
I have not had time to look into this, but my quick guess is that you have
a multiblock dataset with a lot of blocks. Can you try merging the blocks
all together somehow into one block and see if the rendering speed improves?
On Tue, Nov 15, 2016 at 5:35 AM, Stefan Melber wrote:
> Hi,
>
>
> i ha
Stefan,
I am testing out 5.2.0 with offscreen rendering and have observed similar
results. My version built with OpenGL2 is slightly faster than the OpenGL
version for non surface LIC operations, but massively slower when using
Surface LIC.
Comparing back to version 4.4.0, version 5.2.0 with Ope
12 matches
Mail list logo
