<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Jeff-</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">This would be easily done and could be added as an option to the filter. What happens now is that the "t" is computed for each edge tuple (v0,v1) and then used to interpolate attributes and points (the points where the contour intersects each edge). So the t value and edge tuple array (I suppose a 2-component vtkIdArray) could just be output. It's probably best if a new filter were created to do the interpolation from t and (v0,v1) arrays. </div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Does that make sense / is that what you had in mind?</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Best,</div><div class="gmail_default" style="font-family:verdana,sans-serif">W</div><br><div class="gmail_quote"><div dir="ltr">On Fri, Nov 2, 2018 at 8:39 AM Jeff Lee <<a href="mailto:jlee1549@gmail.com">jlee1549@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-family:verdana,sans-serif">Nice work Will,</div><div style="font-family:verdana,sans-serif">I was thinking that there should be a vtk way to associate edges/weights with their input mesh for faster attribute interpolation (when contour value is not changing).  The times where it is useful depends on the workflow, but its cheap enough to store intersected edges and the weights somewhere (as field data in the contour).  I haven't looked at the code yet so you may have already done this.  I did this in my prior work but could (probably will) repeat but contribute to vtk.</div><div style="font-family:verdana,sans-serif">Best,</div><div style="font-family:verdana,sans-serif">Jeff</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Nov 2, 2018 at 6:34 AM Will Schroeder <<a href="mailto:will.schroeder@kitware.com" target="_blank">will.schroeder@kitware.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-family:verdana,sans-serif">If you are interested in a new class for fast contouring of 3D unstructured grids, read on.</div><div style="font-family:verdana,sans-serif"><br></div><div style="font-family:verdana,sans-serif">The class VTK/Filters/Core/vtkContour3DLinearGrid is a threaded, high-performance filter for generating isocontours from unstructured grids. It is specialized for 3D linear cells: any combination of tetrahedra, hexahedra, voxels, pyramids, and/or wedges. (Other cell types are skipped.)</div><div style="font-family:verdana,sans-serif"><br></div><div style="font-family:verdana,sans-serif">In practice we routinely see 10-20x speed ups. In an extreme case we saw a 1000x speedup (a customer's tetrahedral mesh with over 500millions tets). Of course this depends on the number of threads and the particulars of the data so YMMV.</div><div style="font-family:verdana,sans-serif"><br></div><div style="font-family:verdana,sans-serif">By default the class has a fast path where it just generates output triangles and points, and the points are not merged (i.e., coincident points exist in the output). Other available features, at the cost of some speed, are point merging, attribute interpolation, and/or point normal generation. (Note that for dense input meshes the fast path often produces acceptable results; other options can be enabled as needed or in a progressive rendering approach.)</div><div style="font-family:verdana,sans-serif"><br></div><div style="font-family:verdana,sans-serif">The speed comes from 1) threading, 2) a new edge locator (vtkStaticEdgeLocatorTemplate.h/.txx) which identifies coincident points by sorting edge tuples (v0,v1), 3) templating, and 4) better and more efficient algorithm design.</div><div style="font-family:verdana,sans-serif"><br></div><div style="font-family:verdana,sans-serif">In particular,#2) above: contouring in VTK typically relies on point locators to merge coincident points. This is not only a parallel computing bottleneck, but the locator binning can execute very slowly when lots of points fall into the same locator bin. (For example: an unstructured mesh that resolves tiny flow features like a boundary layer etc.) The edge locator eliminates this behavior. Furthermore, duplicate points are identified by using a parallel sort of edge tuples using vtkSMPTools:Sort() - much faster than the point locator's InsertUniquePoint().</div><div style="font-family:verdana,sans-serif"><br></div><div style="font-family:verdana,sans-serif">The effect of threading on performance is modest - it doesn't scale all that well on the tests we've tried. My guess is that the data bus is saturated as the algorithm does a small amount of computation which can produce a large amount of output. (Set the CMake variable VTK_SMP_IMPLEMENTATION_TYPE to something other than Sequential- I use TBB - to enable threading. See this <a href="https://blog.kitware.com/simple-parallel-computing-with-vtksmptools-2/" target="_blank">blog</a> for more information.) </div><div style="font-family:verdana,sans-serif"><br></div><div style="font-family:verdana,sans-serif">Like any new algorithm I'm sure there are issues. If you are so inclined, please try the filter and provide feedback. At some point we'll integrate the algorithm into ParaView but it may be awhile as we are swamped :-)</div><div style="font-family:verdana,sans-serif"><br></div><div style="font-family:verdana,sans-serif">Best,</div><div><br></div>-- <br><div dir="ltr" class="m_-4756053908882202596m_8283320776346163650gmail-m_3539709767685385340gmail_signature"><div dir="ltr"><div>William J. Schroeder, PhD<br>Kitware, Inc. - Building the World's Technical Computing Software<br>28 Corporate Drive<br>Clifton Park, NY 12065<br><a href="mailto:will.schroeder@kitware.com" target="_blank">will.schroeder@kitware.com</a><br><a href="http://www.kitware.com" target="_blank">http://www.kitware.com</a><br>(518) 881-4902</div></div></div></div></div></div>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the VTK FAQ at: <a href="http://www.vtk.org/Wiki/VTK_FAQ" rel="noreferrer" target="_blank">http://www.vtk.org/Wiki/VTK_FAQ</a><br>
<br>
Search the list archives at: <a href="http://markmail.org/search/?q=vtkusers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=vtkusers</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="https://public.kitware.com/mailman/listinfo/vtkusers" rel="noreferrer" target="_blank">https://public.kitware.com/mailman/listinfo/vtkusers</a><br>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>William J. Schroeder, PhD<br>Kitware, Inc. - Building the World's Technical Computing Software<br>28 Corporate Drive<br>Clifton Park, NY 12065<br><a href="mailto:will.schroeder@kitware.com" target="_blank">will.schroeder@kitware.com</a><br><a href="http://www.kitware.com" target="_blank">http://www.kitware.com</a><br>(518) 881-4902</div></div></div></div>