[Paraview] Differences between OpenGL and OpenGL2 versions of ParaView

[Ken Martin]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20151120/bcd9ff4a/attachment.html>