<div dir="ltr">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.<div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>Thanks</div><div>Ken</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 11:39 AM, Adam Lyon <span dir="ltr"><<a href="mailto:lyon@fnal.gov" target="_blank">lyon@fnal.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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</div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div><div style="font-size:12.8000001907349px"><i><font color="#999999">------</font></i></div></div><div><i><font color="#999999"><br></font></i></div><div><b><font color="#3d85c6">Adam L. Lyon</font></b></div><div><i><font color="#999999">Scientist; Associate Division Head for Systems for Scientific Applications</font></i></div><div><span style="font-family:Arial;font-size:9pt"><font color="#999999"><i><br></i></font></span></div><div><font color="#3d85c6">Scientific Computing Division & Muon g-2 Experiment</font></div><div><font color="#999999">Fermi National Accelerator Laboratory</font></div><div><font color="#999999"><a href="tel:630%20840%205522" value="+16308405522" target="_blank">630 840 5522</a> office</font></div><div><font color="#999999"><a href="http://www.fnal.gov" target="_blank">www.fnal.gov</a></font></div><div><font color="#999999"><a href="mailto:lyon@fnal.gov" target="_blank">lyon@fnal.gov</a></font></div><div><font color="#999999"><br></font></div><div><font color="#999999">Connect with us!</font><br><font color="#9fc5e8"><span style="font-size:12.8000001907349px"><a href="http://www.fnal.gov/pub/today/" target="_blank">Newsletter</a></span><span style="font-size:12.8000001907349px">  |  <a href="https://www.facebook.com/Fermilab" target="_blank"><span>Facebook</span></a>  |  <a href="https://twitter.com/Fermilab" target="_blank"><span>Twitter</span></a></span></font></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Fri, Nov 20, 2015 at 1:48 PM, Ken Martin <span dir="ltr"><<a href="mailto:ken.martin@kitware.com" target="_blank">ken.martin@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div>
<div dir="ltr">You could maybe have an actor per LOD and then swap actors in and out.
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>
<div>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 :-)</div>
<div><br>
</div>
<div>Thanks</div><span><font color="#888888">
<div>Ken</div>
<div><br>
</div>
</font></span></div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><div><div><br>
<div class="gmail_quote">On Fri, Nov 20, 2015 at 1:57 PM, Utkarsh Ayachit <span dir="ltr">
<<a href="mailto:utkarsh.ayachit@kitware.com" target="_blank">utkarsh.ayachit@kitware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> I did notice PV is forcing the actor to be modified every time the LOD<br>
> changes (which is a lot). Modifying the actor causes the VBO/IBOs to rebuild<br>
> so it would be better not to do that unless you really need to and in this<br>
> case I'm not sure why it is being done. Specifically I think it is in<br>
> vtkPVLODActor::Modified where it calls this->Device->Modified() . The LOD<br>
> actor is being modified as a result of calling SetEnableLOD constantly<br>
> flipping between true and false. That is not the cause of this issue but it<br>
> is something I noticed that will be a pain for large datasets.<br>
<br>
Ken, currently, there's no way around it. vtkPVLODActor works by<br>
changing the mapper on the internal vtkActor aka Device when LOD mode<br>
is toggled. That will indeed change the Device's MTime even if we stop<br>
calling this->Device->Modiied() in the vtkPVLODActor::Modified(). The<br>
question is why are VBO/IBOs rebuild if actor MTime changes? VBOs<br>
would be data dependent right? Most of data-dependent properties are<br>
on  the Mapper, not the actor. Shouldn't the code that re-creates<br>
VBO/IBOs only depend on Mapper's MTime?<br>
<span><font color="#888888"><br>
Utkarsh<br>
</font></span></blockquote>
</div>
<br>
<br clear="all"><span class="HOEnZb"><font color="#888888">
<div><br>
</div></font></span></div></div><span class="HOEnZb"><font color="#888888"><span>
-- <br>
<div>Ken Martin PhD
<div>Chairman & CFO<br>
Kitware Inc.<br>
28 Corporate Drive<br>
Clifton Park NY 12065<br>
<a href="tel:518%20371%203971" value="+15183713971" target="_blank">518 371 3971</a>
<div><br>
</div>
<div><span style="font-size:10pt;font-family:Tahoma,sans-serif">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.</span></div>
</div>
</div>
</span></font></span></div>
</div>

</blockquote></div><br></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Ken Martin PhD<div>Chairman & CFO<br>Kitware Inc.<br>28 Corporate Drive<br>Clifton Park NY 12065<br>518 371 3971<div><br></div><div><span style="font-size:10pt;font-family:Tahoma,sans-serif">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.</span></div></div></div>
</div>