[vtkusers] Is interaction between Polygon Offset and Line Offset parameters allowed?

Thu Sep 14 13:34:14 EDT 2017

Yes, if they are not coincident then it does get a bit tricky.

If it helps, the range of values for the units can go all the way up to
+-65000 which would be enough to pull something from the far clipping plane
all the way up to the front clipping plane. So while we normally talk about
small values such as +-2 for coincident topology the actual range can be
quite a bit larger if needed.

On Thu, Sep 14, 2017 at 12:55 PM, Luca Pallozzi Lavorante <
lplavorante at gmail.com> wrote:

> Hi Ken, thank you very much for your reply.
> In my application, some of the surfaces are not exactly coincident, due to
> their build process, so I'll have to test the best set of factor/units
> values. These values will have to be high.
>
>    Best regards
>
>      Luca
>
> On Thu, Sep 14, 2017 at 11:43 AM, Ken Martin <ken.martin at kitware.com>
> wrote:
>
>> In this example Surf1 and Surf2 are NOT (just emphasizing not yelling :-)
>> coincident as you have shifted surf2 by 10 world units in Z. So depending
>> on the geometry of surf and the viewing direction surf2 may be in front of
>> or behind surf1 by up to 10 world coordinates. The relation between world
>> coordinates and polygon offset is complex and non-linear so it will be hard
>> to pick values for surf2 that ALWAYS place it in front of surf1 given that
>> they are NOT coincident and the user can rotate the camera etc.
>>
>> But if you go with a large enough set of values you can probably force it
>> to be in front for most all viewpoints.
>>
>> If surf1 and surf2 are really supposed to be coincident then leave them
>> at the same position and just use the Polygon offsets to do what you want.
>> And yes with different sets of factor/unit values you should be able to
>> have many sets of surfaces/lines, all coincident, but yet shown with the
>> order you desire. Just leave them all coincident and adjust the factor
>> offset by say -3, -3 for each layer would be my guess.
>>
>>
>>
>>
>>
>>
>> On Thu, Sep 14, 2017 at 10:12 AM, Luca Pallozzi Lavorante <
>> lplavorante at gmail.com> wrote:
>>
>>> Hi vtkusers,
>>>
>>> I am trying to visualize several (almost) coincident surfaces and
>>> wireframe objects using VTK 8.0 and OpenGL2 on Linux. I am providing a code
>>> snippet in Python, in which I have created two Mappers from the same object
>>> and then the corresponding Actors. One of the two actors is slighty shifted
>>> in order to simulate geometries which are not exactly coincident. Also note
>>> that I had to perform a relatively high Z scaling because the objects are
>>> geologic regional surfaces, which would appear nearly flat without proper
>>> scaling.
>>>
>>> # Surface 1 (Red)
>>> surf1Mapper = vtk.vtkPolyDataMapper()
>>> surf1Mapper.SetInputData(surf)
>>> surf1Mapper.SetResolveCoincidentTopologyToPolygonOffset()
>>> surf1Mapper.SetRelativeCoincidentTopologyPolygonOffsetParameters(-2.0,
>>> -2.0)
>>>
>>> surf1Actor = vtk.vtkActor()
>>> surf1Actor.SetMapper(surf1Mapper)
>>> surf1Actor.GetProperty().SetColor(1, 0, 0)
>>> surf1Actor.SetScale(1, 1, 100)
>>>
>>> # Not necessary. Only used to clarify things.
>>> surf1Actor.SetPosition(0, 0, 0)
>>>
>>> # Surface 2 (Blue)
>>> surf2Mapper = vtk.vtkPolyDataMapper()
>>> surf2Mapper.SetInputData(surf)
>>> surf2Mapper.SetResolveCoincidentTopologyToPolygonOffset()
>>> surf2Mapper.SetRelativeCoincidentTopologyPolygonOffsetParameters(-4.0,
>>> -9.0)
>>>
>>> surf2Actor = vtk.vtkActor()
>>> surf2Actor.SetMapper(surf2Mapper)
>>> surf2Actor.GetProperty().SetColor(0, 0, 1)
>>> surf2Actor.SetScale(1, 1, 100)
>>> # Perform small shift in order to simulate interaction between
>>> non-coincident geometries.
>>> surf2Actor.SetPosition(0, 0, 10)
>>>
>>> # Edges from surface 1. Observe that this object is not translated, so
>>> that its geometry is coincident with surface1's (which has a lower polygon
>>> offset priority compared to surface2).
>>> edges = vtk.vtkExtractEdges()
>>> edges.SetInputData(surf)
>>> edges.Update()
>>>
>>> edgesMapper = vtk.vtkPolyDataMapper()
>>> edgesMapper.SetInputData(edges.GetOutput())
>>> edgesMapper.SetResolveCoincidentTopologyToPolygonOffset()
>>> edgesMapper.SetRelativeCoincidentTopologyLineOffsetParameters(-20.0,
>>> -20.0)
>>>
>>> edgesActor = vtk.vtkActor()
>>> edgesActor.SetMapper(edgesMapper)
>>> edgesActor.GetProperty().SetColor(0, 0, 0)
>>> edgesActor.SetScale(1, 1, 100)
>>>
>>> # Again, this is not necessary.
>>> edgesActor.SetPosition(0, 0, 0)
>>>
>>> To avoid Z-fighting between the surfaces' faces, I used vtkMapper::
>>> SetResolveCoincidentTopologyToPolygonOffset() and then provided
>>> different values for the parameters factor and units, using each mapper's
>>> SetRelativeCoincidentTopology PolygonOffset Parameters() method. Surface 1
>>> has (factor, units) = (-2, -2), whereas Surface 2 (which has drawing
>>> priority) uses (-4, -9). I had to use units = -9 because lower values would
>>> end up showing some polygons from surface 1.
>>> Then I tried to add a wireframe object, whose geometry is the same as
>>> surface1's.
>>> You can see in the code that I had to use high values (-20, -20) for
>>> factor and units (via the SetRelativeCoincidentTopology LineOffset
>>> Parameters() method). This was necessary because I wasn't able to see all
>>> the edges on surface2.
>>>
>>> I have read Ken Martin's post explaining the difference between the
>>> factor and units parameters:
>>> http://markmail.org/search/?q=vtkusers+polygonoffset#query:v
>>> tkusers%20polygonoffset+page:1+mid:lpucqjdjbjz3hy53+state:results
>>>
>>> I verified that to avoid Z-fighting issues between polygons, the factor
>>> and units parameters must have the same order of magnitude (e.g. -2,  -2).
>>> Also, I have tried, whenever possible, to follow Ken's advice not to use
>>> values with magnitudes higher than (minus or plus) 10. But in the case  of
>>> the wireframe object, my parameters had to be higher. And even so, I
>>> couldn't assure the visualization of all the edges, as you can see in the
>>> attached image.
>>> Moreover, the problem persists even when I use exactly coincident
>>> surfaces (e.g., removing the vtkActor::SetPosition() methods.
>>>
>>> If you have had the patience of following me until this point, I'd like
>>> to ask these questions:
>>>
>>> 1. Is is possible to specify priorities between polygon/polygon and
>>> line/polygon parameters? For example, surface 1 used (factor, units) = (-2,
>>> -2), surface 2 used (-4, -9) (PolygonOffset parameters), whereas edges used
>>> (-20, -20), the highes priority among the three objects, set using
>>> LineOffset parameters. Is this consistent?
>>> In my application, I have Z-fighting issues among 3-4 coincident
>>> surfaces (each with its own geologic meaning provided by different CellData
>>> values) and also among 8-9 coincident lines. And the two groups interact,
>>> in the sense that lines must always be drawn correctly on any surface. Can
>>> I achieve this using VTK's Polygon Offset approach?
>>>
>>> 2. Would it be possible to do what I am trying to achieve using
>>> different approaches? I have tried using vtkMapper::SetResolveCoincidentTopologyZShift(),
>>> but with little success.
>>>
>>> I know this is a very long post and apologize for that, but I have been
>>> struggling with this issue for  the last two weeks. So I tried to add as
>>> much information as possible.
>>>
>>> Thank you very much for any advice.
>>>
>>>     Luca
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>>
>> --
>> Ken Martin PhD
>> Distinguished Engineer
>> Kitware Inc.
>> 28 Corporate Drive
>> <https://maps.google.com/?q=28+Corporate+Drive+Clifton+Park+NY+12065&entry=gmail&source=g>
>> Clifton Park NY 12065
>> <https://maps.google.com/?q=28+Corporate+Drive+Clifton+Park+NY+12065&entry=gmail&source=g>
>>
>> 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.
>>
>
>

-- 
Ken Martin PhD
Distinguished Engineer
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20170914/b347114e/attachment.html>