Menu

#254 Freeglut 3.x : glutSolidSphere and glutSolidTorus Error

open
nobody
3.x version (1)
5
2021-09-30
2020-02-28
No

Ther is an "error" in Freeglut 3.x (at least 3.0 or 3.2.1) when using glutSolidSphere and/or glutSolidTorus. The behavior is not compatible with original glut32 or even freeglut 2.8.1. See images. The points to build faces are not the same.
Note : no such problem with wire version.
The test program, AccumAntialias is from : http://bankslab.berkeley.edu/members/chris/AntiAliasing/AntiAliasingInOpenGL.html compiled on Windows with MinGW64 8.1, in 64 bits.
gd_on

2 Attachments

Discussion

  • Gerard DURAND

    Gerard DURAND - 2020-03-02

    Note : if you reduce the numbers of slices, stacks, sides and/or rings, the effect is bigger with freeglut 3.2.1 but with freeglut 2.8.1 it's still acceptable. I have seen that with freglut 3.x, the facets are all triangulars though in version 2.8.1 there are facets with 4 points. But I don't feel it's sufficient to explain the différences. I have the feeling that there is something wrong with the normals...

     

    Last edit: Gerard DURAND 2020-03-02
  • John Tsiombikas

    John Tsiombikas - 2020-03-03

    This looks like a regression, probably introduced during the primitive rewrite to make them GL3-friendly. I'll try to remember to take a look through the code and see what's going on.

     
  • Gerard DURAND

    Gerard DURAND - 2021-09-28

    Small pop up ...
    and further remarks.
    This strange behavior happens only when glShadeModel is GL_FLAT. All is OK in GL_SMOOTH.
    If I display normals, they look OK, because located at vertices. But when you use GL_FLAT, none of the built normals correspond to the normal of the flat surface. In freeglut 2.8.1 and old glut 3.7, sphere and torus are build as quads face. It's also true in freeglut 3.2.1 but they are triangulated internally if I understand well. May be the problem is somewhere there.
    More, with cylinder or cone, everything seems OK in each shade model type. May, it's not correct too, because the real normal of the different triangles are not computed, but it's not visible (we are lucky !).

     
  • John Tsiombikas

    John Tsiombikas - 2021-09-29

    The problematic primitives don't draw quads any more, rather they are rendered as a series of triangle strips. In GL_FLAT mode, for the two triangles of the "quad" to share the same normal and look correct, one of their shared vertices need to be the provoking vertex for both of them (i.e. the first vertex of both triangles). I don't think this is possible with triangle strips. These primitive functions will have to be re-written to fix the issue.

     
  • Gerard DURAND

    Gerard DURAND - 2021-09-29

    I understand your remarks, but why does it seems to work with a cylinder ? (and for the quad parts of a cone)... Sure, the normal used is certainly not the right one (a vertex normal is not the real normal of a triangle)... but may be reorganizing the order of the stripped indices (stripIdx array) should do the work for the torus and the sphere... but until now, I have not found a solution (if it exists !).

     
  • John Tsiombikas

    John Tsiombikas - 2021-09-29

    The obvious difference with the cylinder is that columns of vertices have identical normals.

    I skimmed through the code and I don't have a complete picture of how the strips are formed in this case, but I don't see how we can control the provoking vertex, when each time we can only specify the next vertex in the strip. Maybe some trick with forcing degenerate triangles every two triangles, but then what's the point in using a triangle strip in the first place?

    Frankly I'm not a fan of triangle strips in general. If it comes down to me to fix this, it will be by rewriting it to use indexed triangles instead. I will not attempt to salvage the existing code. Of course if someone else steps up to fix the existing code, so much the better.

     
  • Gerard DURAND

    Gerard DURAND - 2021-09-30

    Hi,
    I have found that if I replace GL_TRIANGLE_STRIP by GL_QUAD_STRIP at line 267 in fg_geometry.c (in fghDrawGeometrySolid11, used in my case), I obtain, apparently, the same behavior than with freeglut 2.8.1 (or original glut).
    Of course triangulation is lost and the normal used is still not the real normal of a flat surface, but the look seems better.
    It's just a workaround, and probably needs other adjustments for other cases. May be adding a specific use for sphere and torus to limit border effects !

    PS: Oups ! not totally correct for the bottom or the top of the sphere !

     

    Last edit: Gerard DURAND 2021-09-30

Log in to post a comment.