3

I'm working on an OpenGL project, and I'm looking for a triangulation/tessellation functionality. I see a lot of references to the GLUtessellator and related gluTess* functions (e.g., here).

I'm also using GLFW, which repeats over and over again in its guides that:

GLU has been deprecated and should not be used in new code, but some legacy code requires it.

Does this include the tessellation capability? Would it be wise to look into a different library to create complex polygons in OpenGL?

Neal Kruis
  • 2,055
  • 3
  • 26
  • 49

3 Answers3

2

GLU is a library. While it makes OpenGL calls, it is not actually part of OpenGL. It is not defined by the OpenGL specification. So that specification cannot "deprecate" or remove it.

However, GLU does most of its work through OpenGL functions that were removed from core OpenGL. GLU should not be used if you are trying to use core OpenGL stuff.

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
  • 2
    You didn't really answer my question. From what you've written I imagine the GLUtessellator is not considered core OpenGL and, therefore, it would be fine to use GLU for this purpose? The GLFW statements seem to be much broader: the entire GLU library is deprecated. Hence my confusion. – Neal Kruis Jan 11 '17 at 00:31
  • 1
    @NealKruis: I thought "*GLU should not be used if you are trying to use core OpenGL stuff.*" was pretty clear. GLUtessellator is not *and has never been* core OpenGL; like all GLU stuff, it comes from an *external* library that *calls* OpenGL. But the calls it makes are to functions that have been removed from core OpenGL. So you cannot use GLU stuff with core OpenGL. I don't see where the confusion comes in here. – Nicol Bolas Jan 11 '17 at 00:41
  • Sorry, I meant to say "I imagine the GLUtessellator does not use core OpenGL." I recognize the difference between OpenGL and the GLU library. So it sounds to me like your answer to my question is: "Yes, the GLUtesselation functionality should be considered deprecated along with the rest of the GLU library. You should look elsewhere for a tessellation/triangulation library." – Neal Kruis Jan 11 '17 at 15:07
  • 1
    @NealKruis: People keep getting the definition of the word "deprecated" wrong, including the GLFW people apparently. "Deprecated" means "still perfectly legal, but likely to go away soon, so stop using it." But that's not the case here. The OpenGL functions that GLU rely on are not "deprecated"; they *have been removed* from core OpenGL. They're not legal core OpenGL functions anymore. So calling it "deprecated" is wrong. It is simply non-functional in core OpenGL environments. – Nicol Bolas Jan 11 '17 at 16:06
2

Here follows a little addition. It should be noted here that there exist in regard to the original gluTess* implementation also more modern alternatives which follow the original concept in terms of simplicity and universality.

A notable alternative is Libtess2, a refactored version of the original libtess.

https://github.com/memononen/libtess2

It uses a different API which loosely resemble the OpenGL vertex array API. However, libtess2 seems to outperform the original GLU reference implementation "by order of magnitudes". ;-)

The current official OpenGL 4.0 Tessellation principle requires GPU hardware which is explicitly compatible. (This is most likely true for all DirectX 11 and newer compatible hardware.) More information regarding the current OpenGL Tessellation concept can be found here:

https://www.khronos.org/opengl/wiki/Tessellation

Clemens
  • 171
  • 1
  • 3
-3

This new algorithm is better when it needs mesh quality, robustness, Delauney and other optimisations.

It generates mesh and outline in one loop for cases where gluTess needs several. It supports many more modes, but is 100% compatible with the gluModies. It is programmed and optimised for C++ x86/x64 with an installable COM interface. It can also be used from C# without COM registration. The same implementation is also available as a C# version which is about half as fast on (state of the art NET Framwork 4.7.2).

It computes with a Variant type that supports different formats: float, double and Rational for unlimited precision and robustness. In this mode, the machine Epsilon = 0, no errors can occur. Absolute precision.

If you want to achieve similar qualities with the gluTess algorithm, you need 3 times longer, including complex corrections to remove T-junctions and optimise the mesh.

The code is free at:

https://github.com/c-ohle/CSG-Project

Christian Ohle
  • 143
  • 1
  • 4