[gl2ps] [patch] Enable use without an OpenGL context

[Christophe Geuzaine]

Looks good: merged in SVN.

Thanks,

Christophe

> On 14 Jan 2016, at 22:00, David Lonie <david.lonie at kitware.com> wrote:
> 
> Hi Christophe,
> 
> I realized I wasn't very happy with the patch I'd made earlier and
> made a few more changes that I think make the feature easier to
> use/maintain.
> 
> Instead of passing 0 as the buffersize to disable OpenGL queries
> (which was rather hacky), I've added a new option,
> GL2PS_NO_OPENGL_CONTEXT that more clearly indicates the intended
> effect.
> 
> I also added a runtime check that ensures the supplied options will
> work without surprises. If NO_OPENGL_CONTEXT is set, the following
> conditions are enforced:
> 
> - DRAW_BACKGROUND is off (can't query OpenGL for the clear color.
> Users can manually draw a background rectangle as part of their
> geometry).
> - USE_CURRENT_VIEWPORT is off (can't query OpenGL for the viewport).
> - NO_BLENDING is on (can't query OpenGL for the blending parameters).
> - colormode is GL_RGBA (can't query OpenGL for the color map).
> 
> I've attached a new patch that implements this and adds the
> restrictions to the documentation. It is based off of current SVN
> trunk. Let me know if there are any concerns with this patch.
> 
> Thanks,
> Dave
> 
> On Wed, Jan 13, 2016 at 9:31 AM, David Lonie <david.lonie at kitware.com> wrote:
>> On Wed, Jan 13, 2016 at 2:46 AM, Christophe Geuzaine
>> <cgeuzaine at ulg.ac.be> wrote:
>>> 
>>> Hi David,
>>> 
>>> This is a very good idea - I've merged the patch in SVN.
>> 
>> Great!
>> 
>>> Do you think it would be doable to incorporate the parsing of the transform feedback buffers directly in GL2PS?
>> 
>> It would be possible. One of the issues I see is that the new buffers
>> aren't annotated like the old feedback buffer -- there's no
>> GL_POINT_TOKEN, etc. The captured attributes (and their ordering) are
>> dependent on how each feedback transform buffer is configured.
>> 
>> What I've done is keep a list of "roles" around with the feedback
>> buffer to identify the attributes that are captured, e.g. "Vertex Clip
>> Coordinates" or "RGBA color". The order of the roles specifies the
>> order of the attributes in the buffer to make generic parsing
>> possible. Something similar could be implemented in GL2PS.
>> 
>> For instance, I encapsulate transform feedback buffers in the
>> vtkTransformFeedback class:
>> https://gitlab.kitware.com/dlonie/vtk/blob/opengl2-gl2ps/Rendering/OpenGL2/vtkTransformFeedback.h
>> https://gitlab.kitware.com/dlonie/vtk/blob/opengl2-gl2ps/Rendering/OpenGL2/vtkTransformFeedback.cxx
>> 
>> And parse them here in vtkOpenGLGL2PSHelperImpl::ProcessTransformFeedback:
>> https://gitlab.kitware.com/dlonie/vtk/blob/opengl2-gl2ps/Rendering/GL2PSOpenGL2/vtkOpenGLGL2PSHelperImpl.cxx#L73
>> 
>> So generic parsing is possible by providing role information or having
>> a convention in place.
>> 
>> But then, there are some complicated edge cases to worry about. For
>> example, VTK tends to do coloring in the fragment shader, which cannot
>> be captured into the transform feedback buffer, and the vert/geo
>> shaders know nothing about colors. In situations like these, it's
>> easier to insert the primitives manually since the feedback vertices
>> can be combined with a separate color array.
>> 
>> So I think it could be done, but it would add a lot of API bloat to
>> cover all of the possibilities.
>> 
>> Another idea to simplify this would be to add higher level
>> "gl2psAdd[Point|Line|Triangle]" methods that are more straightforward
>> to use than gl2psAddPolyPrimitive, but I found the latter easy enough
>> to use.
>> 
>> Dave
> <gl2ps-nogl-update.diff>

-- 
Prof. Christophe Geuzaine
University of Liege, Electrical Engineering and Computer Science 
http://www.montefiore.ulg.ac.be/~geuzaine

Tetrahedron V, July 4-5 2016: http://tetrahedron.montefiore.ulg.ac.be
Free software: http://gmsh.info | http://getdp.info | http://onelab.info