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 l...@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.mar...@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.ayac...@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. >
_______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Search the list archives at: http://markmail.org/search/?q=ParaView Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/paraview