[Paraview] Differences between OpenGL and OpenGL2 versions of ParaView

[Adam Lyon]

Hi - Just thought I'd let you all know that I've finally made progress on
this problem. To recap, I have a MultiBlockDataSet (MBDS) containing
PolyData objects. The PolyData objects don't all have the same attributes
(some have Normals, some don't; some have particular FieldData, others
don't). This "heterogeneous" MBDS reflects the visualization data I get
from the Geant4 simulation program - some things have particular attributes
and others don't.

As you (Ken & Utkarsh) pointed out, such a heterogenous MBDS triggers a
generic renderer in ParaView v5/OpenGL2 unless every block within the MBDS
has the same structure. The generic renderer is extremely slow, and it
makes interacting with the visualization in ParaView painful (e.g. a few
frames per second or less).

I now have a filter (I should fix my ParaView Source that creates the MBDS
- but that'll be for later) that runs through the MBDS and makes it
homogeneous - that is it removes Normals and TCoords (only a very few
PolyData have them) and adds missing FieldData with defaults. This triggers
the fast renderer - and boy it's *a lot* faster. 30x - 200x faster frame
rates compared to the generic renderer.  The fast renderer is at least many
times faster than the OpenGL1 renderer in ParaView v4.4.

I'm quite happy with this solution and am glad I can finally use the new
features in ParaView v5/OpenGL2. Woohoo!

I'm wondering if other people are going to hit this generic renderer
slowness.. I added some code to my build of ParaView v5 in
vtkCompositePolyDataMapper2.cxx that std::cout's a message when the generic
renderer is triggered and why (e.g. heterogeneous Normals, TCoords,
Scalars, etc). I found that to be very helpful. Perhaps the render
annotation could show such a message (e.g. in vtkPVRenderView).

Thanks again for your help!!  And Happy New Year!! -- Adam

*------*

*Adam L. Lyon*
*Scientist; Associate Division Head for Systems for Scientific Applications*

Scientific Computing Division & Muon g-2 Experiment
Fermi National Accelerator Laboratory
630 840 5522 office
www.fnal.gov
lyon at fnal.gov

Connect with us!
Newsletter <http://www.fnal.gov/pub/today/>  |  Facebook
<https://www.facebook.com/Fermilab>  |  Twitter
<https://twitter.com/Fermilab>

On Wed, Dec 16, 2015 at 1:46 PM, Ken Martin <ken.martin at kitware.com> wrote:

> 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 10000 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 everything out into a displaylist and the OpenGL
> driver handled optimizing it and dealing with any inconsistencies. The new
> backend has to build vertex buffer objects and we currently only collapse
> all the blocks together into one VBO if the VBO structure is the same for
> every block.
>
> Thanks
> Ken
>
>
> On Wed, Dec 16, 2015 at 2:22 PM, Adam Lyon <lyon at fnal.gov> wrote:
>
>> 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 setting points and cells). The latter won't have normals. Maybe
>> some of the former do.  I'll look into this.
>>
>> 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!!
>> -- Adam
>>
>> *------*
>>
>> *Adam L. Lyon*
>> *Scientist; Associate Division Head for Systems for Scientific
>> Applications*
>>
>> Scientific Computing Division & Muon g-2 Experiment
>> Fermi National Accelerator Laboratory
>> 630 840 5522 office
>> www.fnal.gov
>> lyon at fnal.gov
>>
>> Connect with us!
>> Newsletter <http://www.fnal.gov/pub/today/>  |  Facebook
>> <https://www.facebook.com/Fermilab>  |  Twitter
>> <https://twitter.com/Fermilab>
>>
>> On Wed, Dec 16, 2015 at 11:47 AM, Ken Martin <ken.martin at kitware.com>
>> wrote:
>>
>>> 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
>>> triangles. Currently there are two paths for rendering multiblock data.
>>>
>>> 1) every block has the same properties (normals, tcoords, triangles)  In
>>> that case we use a fast path, the actual values of course may be different,
>>> but if one block has texture coordinates then all of them will.
>>>
>>> 2) blocks can be different, meaning that one block may be triangles with
>>> normals while the next could be lines with texture coordinates. In that
>>> case we fall back on just giving each block its own mapper. That is the
>>> slow path.
>>>
>>> What would benefit your case is a third path (or a better slow path)
>>> where the blocks can be different, but we combine the ones that are the
>>> same so that hopefully we end up with maybe 4 or 5 mappers each with 1000
>>> or so triangles. Implementing that is not trivial though so I don't think
>>> anyone has plans for it yet.
>>>
>>> Another approach would be to look at what is generating your data and
>>> try to determine why some blocks have normals while others do not. because
>>> if you can get the blocks to be homogeneous then you will get the fast path.
>>>
>>> Thanks
>>> Ken
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Dec 16, 2015 at 11:39 AM, Adam Lyon <lyon at fnal.gov> 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
>>>> Holidays!!!  I really appreciate you all looking at this problem. -- Adam
>>>>
>>>> *------*
>>>>
>>>> *Adam L. Lyon*
>>>> *Scientist; Associate Division Head for Systems for Scientific
>>>> Applications*
>>>>
>>>> Scientific Computing Division & Muon g-2 Experiment
>>>> Fermi National Accelerator Laboratory
>>>> 630 840 5522 office
>>>> www.fnal.gov
>>>> lyon at fnal.gov
>>>>
>>>> Connect with us!
>>>> Newsletter <http://www.fnal.gov/pub/today/>  |  Facebook
>>>> <https://www.facebook.com/Fermilab>  |  Twitter
>>>> <https://twitter.com/Fermilab>
>>>>
>>>> On Fri, Nov 20, 2015 at 1:48 PM, Ken Martin <ken.martin at kitware.com>
>>>> wrote:
>>>>
>>>>> You could maybe have an actor per LOD and then swap actors in and out.
>>>>>
>>>>> Actor owns the property, backface property, and texture. Changes to
>>>>> those objects can cause VBO/IBO rebuilds (switching from surface to
>>>>> wireframe, adding a texture map, flat versus phong shading, edge
>>>>> visibility, line width, etc.) The old backend only looked at the actor's
>>>>> property which is sort of broken.
>>>>>
>>>>> For example in the old backend: create two properties, one set to
>>>>> wireframe, one set to surface. Then create an actor and mapper set to use
>>>>> display lists. Switching between the two properties will cause an actor
>>>>> mtime change, but the properties themselves would still have low mtimes I
>>>>> believe. In that case the old backend will end up stuck in one
>>>>> representation because it only looks at the property mtime not actor.
>>>>>
>>>>> To make the VBO/IBO rebuild safely (but less often than currently) I
>>>>> think the solution is to check the mtimes as is done currently, if those
>>>>> are modified then collect up the parameters that require a VBO or IBO
>>>>> rebuild and compare them to a stored value from the last build. If
>>>>> different force a rebuild. That is the best solution IMO just takes some
>>>>> time. I sort of wanted to do that anyhow but now I can say you forced me
>>>>> into it :-)
>>>>>
>>>>> Thanks
>>>>> Ken
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Nov 20, 2015 at 1:57 PM, Utkarsh Ayachit <
>>>>> utkarsh.ayachit at kitware.com> wrote:
>>>>>
>>>>>> > I did notice PV is forcing the actor to be modified every time the
>>>>>> LOD
>>>>>> > changes (which is a lot). Modifying the actor causes the VBO/IBOs
>>>>>> to rebuild
>>>>>> > so it would be better not to do that unless you really need to and
>>>>>> in this
>>>>>> > case I'm not sure why it is being done. Specifically I think it is
>>>>>> in
>>>>>> > vtkPVLODActor::Modified where it calls this->Device->Modified() .
>>>>>> The LOD
>>>>>> > actor is being modified as a result of calling SetEnableLOD
>>>>>> constantly
>>>>>> > flipping between true and false. That is not the cause of this
>>>>>> issue but it
>>>>>> > is something I noticed that will be a pain for large datasets.
>>>>>>
>>>>>> Ken, currently, there's no way around it. vtkPVLODActor works by
>>>>>> changing the mapper on the internal vtkActor aka Device when LOD mode
>>>>>> is toggled. That will indeed change the Device's MTime even if we stop
>>>>>> calling this->Device->Modiied() in the vtkPVLODActor::Modified(). The
>>>>>> question is why are VBO/IBOs rebuild if actor MTime changes? VBOs
>>>>>> would be data dependent right? Most of data-dependent properties are
>>>>>> on  the Mapper, not the actor. Shouldn't the code that re-creates
>>>>>> VBO/IBOs only depend on Mapper's MTime?
>>>>>>
>>>>>> Utkarsh
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Ken Martin PhD
>>>>> Chairman & CFO
>>>>> Kitware Inc.
>>>>> 28 Corporate Drive
>>>>> Clifton Park NY 12065
>>>>> 518 371 3971
>>>>>
>>>>> This communication, including all attachments, contains confidential
>>>>> and legally privileged information, and it is intended only for the use of
>>>>> the addressee.  Access to this email by anyone else is unauthorized. If you
>>>>> are not the intended recipient, any disclosure, copying, distribution or
>>>>> any action taken in reliance on it is prohibited and may be unlawful. If
>>>>> you received this communication in error please notify us immediately and
>>>>> destroy the original message.  Thank you.
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Ken Martin PhD
>>> Chairman & CFO
>>> Kitware Inc.
>>> 28 Corporate Drive
>>> Clifton Park NY 12065
>>> 518 371 3971
>>>
>>> This communication, including all attachments, contains confidential and
>>> legally privileged information, and it is intended only for the use of the
>>> addressee.  Access to this email by anyone else is unauthorized. If you are
>>> not the intended recipient, any disclosure, copying, distribution or any
>>> action taken in reliance on it is prohibited and may be unlawful. If you
>>> received this communication in error please notify us immediately and
>>> destroy the original message.  Thank you.
>>>
>>
>>
>
>
> --
> Ken Martin PhD
> Chairman & CFO
> Kitware Inc.
> 28 Corporate Drive
> Clifton Park NY 12065
> 518 371 3971
>
> This communication, including all attachments, contains confidential and
> legally privileged information, and it is intended only for the use of the
> addressee.  Access to this email by anyone else is unauthorized. If you are
> not the intended recipient, any disclosure, copying, distribution or any
> action taken in reliance on it is prohibited and may be unlawful. If you
> received this communication in error please notify us immediately and
> destroy the original message.  Thank you.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20160105/9630dd4c/attachment.html>