Agent13's picture

Changes in 0.3.9 - possibly a bug


I'm using OpenTK in my project since version 0.3.7 and after moving to 0.3.9 I'm experiencing some weird behavior of GL.Color3 and GL.Normal3 functions. Particularly, overloads taking integer parameters don't work properly, while those taking double or float are OK.

For example, if I try to set the normals like this: GL.Normal3(0, 0, 1) the scene looks like there would be no lighting at all, while GL.Normal3(0f, 0f, 1f) works perfectly.

Likewise, GL.Color3(color.R, color.G, color.B) where color is a System.Drawing.Color structure, produces uncolored objects. When colors are given as floats, everything is OK.

So it seems like a bug... or I'm doing something wrong :)


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler.'s picture

Not a bug, this strange behavior is perfectly normal! :)

The range of possible values differs between the integer and floating points of the Vertex*/Color*/Normal* families of functions. The float and double versions take values between 0.0 and 1.0, whereas the integer versions take between 0 and MAX_INT (255 for the byte version, 65535 for the ushort, and 4294967295 for the int version). The integer values are mapped linearly to a float between 0.0 and 1.0: an int value of 1 corresponds to a float value of (1/4294967295 - very dark indeed!)

The System.Drawing.Color problem on the other hand is a bug (the unsigned byte is cast to a signed byte internally) - thanks for reporting, I'll fix it in the next release! (which is just around the corner)

Edit: Just fixed the Color3 bug, which affects functions with both 'ub' and 'b' versions (unsigned/signed byte respectively). System.Drawing.Color works correctly now.

Agent13's picture

Thanks for the explanation!

I was aware of mapping integer values to floats when setting colors, but I didn't know that is also the case with other functions such as Normal*. I was actually using Normal3d with earlier versions of OpenTK, so all the integer parameters were treated as doubles and that's why I didn't notice such behavior before.

As for the fixed Color3 bug - I'll definitely try it out when the next version arrives :)

And one more question - what about GLU library functions? Currently OpenTK exposes only a subset of Glu routines, do you plan to add the rest of them or maybe there are any problems? Particularly, I'm interested in GLU quadric drawing functions. I tried to modify OpenTK myself by copying the required code from the Tao framework. It worked on Windows, but made my program hang on Linux...

Anyway, I wouldn't call those routines absolutely crucial as I've already implemented the missing functionality in other ways...

the Fiddler.'s picture

what about GLU library functions?
They are planned (see the 'roadmap'). How long they will take to implement depends on how difficult it will be to make the generator understand callback functions, but otherwise they aren't far away.

I'll release the new version today, unless some severe bug shows up while testing - it contains complete WGL bindings and fixes several bugs (not much in the way of new features, but is much more stable here).