<div dir="ltr">+1 Ken. The global has caused some surprises in the past. I guess if we have the global and instance specific setting, then the instance setting overrides the global setting is what I am assuming you have. Does it reset to global for the next mapper? </div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 1, 2015 at 1:29 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 dir="ltr"><div><br></div>I wanted to take a second to write up a recent change I made to how VTK (on the OpenGL2 backend) can handle coincident geometry.  Previously VTK supported global values for specifying a polygonal offset to push surfaces forward or back in the zbuffer. This was often used to draw a surface back a bit in the zbuffer, and then draw the same surface in wireframe mode at the normal z location. The result was a wireframe overlaid on top of the surface. This approach faced a couple limitations. Every surface was offset the same amount and there was no way to offset points from lines.  To address this I have added a few methods to vtkMapper to specify global line and point offsets as well as ivars to hold local offsets per mapper. The global methods look like:<div><br></div><div><div>  static void SetResolveCoincidentTopologyLineOffsetParameters(</div><div>    double factor, double units);</div><div><br></div><div>while the instance methods look like:</div><div><br></div><div><div>  void SetRelativeCoincidentTopologyLineOffsetParameters(</div><div>    double factor, double units);</div></div><div><br></div><div>Both signatures use two parameters which are worth mentioning. The first factor is how much to shift the zbuffer based on how quickly the z values of the surface or line changes. This may seem complicated but it addresses a simple issue.  Due to rasterization issues, surfaces and lines with sharp zvalue slopes are more prone to noise in the zvalues they produce. To combat that, we offset them by an amount that is based on their z slope. If the surface is perpendicular to the view direction the factor is irrelevant, but the more the surface is at a sharp angle to the view direction, the more the factor comes into play. A value of 1.0 to 2.0 is fairly typical for the factor. The second parameter is the units, a constant offset to the zbuffer. It is currently specified conservatively in terms of a 16bit zbuffer for the OpenGL backend so a value of 1.0 to 2.0 is a good place to start. For rendering points we do not have a slope so those methods only take the units argument.</div><div><br></div><div>I have changed the global defaults so that surfaces are offset at 2.0,2.0, lines are offset at 1.0,1.0, and points are at 0.0. There is a new test in OpenGL2/Testing/CXX/TestCoincident.cxx that renders points on top of lines on top of a surface while rendering the points first and the surface last (the opposite order of their visibility). </div><div><br></div><div>Thanks</div><span class="HOEnZb"><font color="#888888"><div>Ken</div><div><br></div><div><br></div>-- <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>
</font></span></div></div>
<br>_______________________________________________<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="http://public.kitware.com/mailman/listinfo/vtkusers" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/vtkusers</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><font face="trebuchet ms, sans-serif"><i>| Aashish Chaudhary <br>| Technical Leader         <br>| Kitware Inc.            <br></i></font><div><i><font face="trebuchet ms, sans-serif">| </font><a href="http://www.kitware.com/company/team/chaudhary.html" target="_blank">http://www.kitware.com/company/team/chaudhary.html</a></i></div></div></div>
</div>