[vtk-developers] OpenGL backend differences

[Ken Martin]

Yes, that used to be a common problem in the early days of graphic
libraries as they often would render quads differently depending on
implementation.

I added it to the running list of regressions/todos which is included below:



Changes/ToDos/Regressions



   1. Gouraud shading dropped, actors set to Gouraud now render using Phong
   shading



2.            Wireframe polygons without normals are now lighted
differently than before. Previously VTK would generate vertex normals from
the polygon and use those to light the wireframe line. The new code lights
the lines in the fragment shader by generating a normal that is
perpendicular to the line and maximally aligned with the camera view
direction. That normal is then used for lighting calcs. This results in
different images but arguably just as intuitive as the prior approach.



3.            currently when picking, only 16,777,215 primitives per mapper
are supported, could extend this up to 2^31 without too much grief, beyond
that gl_PrimitiveID will not work and we would just have to loop in the
mapper rendering a batch of prims at a time



4.            SetZBuffer data function in RenderWindow is currently not
working, have to take the same approach as SetRGBA functions and have a
shader do this.



5.            ImageSliceMapper and ImageMapper should be modified to
directly use TextureObject instead of vtkTexture, saving some pipeline
overhead etc.



6.            triangle cell data passed into strips via field data does not
work, and I would say we do not support this odd case. Maybe modify
stripper to complain if PassCellDataAsFieldData is turned on.



vtkStripper stripper

stripper PassCellDataAsFieldDataOn



vtkPolyDataMapper sphereMapper

sphereMapper SetColorModeToMapScalars

sphereMapper SetScalarModeToUseFieldData



7.            When no lights are on, the old backend would still apply
lighting equations just with no lights (mostly, the valid image for
NoLightGeneration is missing the line, seems wrong).  The new backend does
not apply lighting equations in that case, rather it treats it like the 2d
mapper, rendering without a lighting model.  The old approach can be
achieved simply by having a light that has it’s intensity set to zero (as
opposed to being turned off) if that is what you are after.



8.            Need to cache VBOs, so that if multiple mappers are using the
same VBO they share it. Related to that, right now we rebuild the VBO even
if just the IBO is changing, a VBO cache would handle that case as well and
is s step towards sharing gl buffers data between actors/mappers.



9.            When a texture map modulates the color on a fragment, the old
code limited the color to 1.0 before modulating against the texture.  In
the new code the color of a fragment may exceed 1.0 and then be modulated
by a texture and finally truncated to 1.0. This can produce different
results when the fragment is overlit (e.g. diffuse = 1.0 ambient = 1.0 and
then modulated by a texture.)



10.          Should try fixing the math in texture object, it is using
texture size when it should be destination size when doing the 0.5 thing.
Mostly is not caught as the texture is often the same size as the
destination.



11.          Quads and higher degree polygons are converted to triangles by
the OpenGL backend prior to being sent to OpenGL. This can result in
different interpolation versus the old backend.





Ken Martin PhD

Chairman & CFO

Kitware Inc.

28 Corporate Drive

Clifton Park NY 12065

ken.martin at kitware.com

518 881-4901 (w)

518 371-4573 (f)



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.



*From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On Behalf
Of *Joachim Pouderoux
*Sent:* Tuesday, April 28, 2015 5:57 AM
*To:* VTK Developers
*Cc:* Mathieu Westphal
*Subject:* [vtk-developers] OpenGL backend differences



Hi,

Mathieu and I were facing a tricky situation when adding a new VTK test.


We basically tried to render a piece of a RTAnalyticSource. We generated
the baseline image with the legacy backend and tests were failing with the
OpenGL 2 backend. Attached are the images we obtained with the two backends
- you can see that the color spots have not the same orientation.

We finally found the origin of the problem: as the grid is made of
hexahedron, the geometry filter generates a surface made of quads.
For the legacy backend, rendering quads is not an issue as OpenGL allows to
render (non-convex) polygons directly, so the legacy painter-mapper
directly sends the quad to OpenGL for rendering.
With the new backend, only triangles are transferred to the graphic board
and a triangulation is implicitly performed by the mapper (actually by
vtkglVBOHelper.cxx:338 - vtkgl::AppendTriangleIndexBuffer function). Note
that this function respects the order of the triangulation performed by
vtkQuad::Triangulate() but it seems like it is not the one implicitly
performed by OpenGL (or some OpenGL implementations at least) when you
render quad primitives.

To fix the issue we inserted a vtkTriangleFilter between the GeometryFilter
and the Mapper so that both mapper implementations end up with the same
triangulated mesh to render.



I think this behaviour should be documented somewhere (may be it is
already? anyway now at least it is here) as I am sure this should cause
problems later.



Best,


*Joachim Pouderoux*

*PhD, Technical Expert*
*Kitware SAS <http://www.kitware.fr>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20150428/0f2c5d15/attachment.html>