[vtkusers] Recent Change to Handling Coincident Geometry

[Aashish Chaudhary]

+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?

On Tue, Dec 1, 2015 at 1:29 PM, Ken Martin <ken.martin at kitware.com> wrote:

>
> 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:
>
>   static void SetResolveCoincidentTopologyLineOffsetParameters(
>     double factor, double units);
>
> while the instance methods look like:
>
>   void SetRelativeCoincidentTopologyLineOffsetParameters(
>     double factor, double units);
>
> 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.
>
> 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).
>
> Thanks
> Ken
>
>
> --
> 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 VTK FAQ at:
> http://www.vtk.org/Wiki/VTK_FAQ
>
> Search the list archives at: http://markmail.org/search/?q=vtkusers
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtkusers
>
>


-- 



*| Aashish Chaudhary | Technical Leader         | Kitware Inc.            *
*| http://www.kitware.com/company/team/chaudhary.html
<http://www.kitware.com/company/team/chaudhary.html>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20151201/1e53614c/attachment.html>