Re: [HOpenGL] Specialized versions of renderPrimitives?
On Fri, 27 Oct 2006, Sven Panne wrote:
One thing I don't fully understand: What is not type safe in the current API? The only thing I see is that one could use a different monad within renderPrimitive to enforce that only correct OpenGL command could be issued there.
There are several OpenGL commands that make no sense in renderPrimitive like glViewport, glEnd, glFlush ... For modes like Lines, where pairs of vertices are needed, it could be enforced by types, that you can only pass pairs of vertices.
But having direct access to the IO monad is more important to access e.g. IORefs etc.
I think it is enough to access them outside renderPrimitive.
Am Freitag, 27. Oktober 2006 13:25 schrieb Henning Thielemann:
On Fri, 27 Oct 2006, Sven Panne wrote:
One thing I don't fully understand: What is not type safe in the current API? The only thing I see is that one could use a different monad within renderPrimitive to enforce that only correct OpenGL command could be issued there.
There are several OpenGL commands that make no sense in renderPrimitive like glViewport, glEnd, glFlush ... For modes like Lines, where pairs of vertices are needed, it could be enforced by types, that you can only pass pairs of vertices.
That's correct, but the problem is that the type system can only catch those simple kind of errors you've mentioned, which are rarely a problem in practice. What's much trickier to debug are semantic issues like the requirement that all polygons have to be convex, the order in which vertices are specified (for front/back determination), etc. In those cases, the type system is of no help at all. Furthermore, one has to consider that it's perfectly legal to specify things like the current color, the current normal etc. outside glBegin/glEnd. And finally, OpenGL simply discards any vertices which are "left over" for the primitive in question without signalling an error. This seems to be a very deliberate design decision, so I don't want to be stricter on the Haskell side.
But having direct access to the IO monad is more important to access e.g. IORefs etc.
I think it is enough to access them outside renderPrimitive.
For most cases it is, but people sometimes have strange ideas how to use an API. :-) In a nutshell: I understand the desire to make things slighty more typesafe, but I don't think that exclusively providing the proposed functions would be a good tradeoff for "real" programs. The things you've mentioned can easily be implemented on top of the current binding. A question would be: Should utility functions like the ones you've mentioned be included in the Haskell binding, too? And if yes, what would be their exact types? What do other people on this list think? Cheers, S.
On 10/28/06, Sven Panne
In a nutshell: I understand the desire to make things slighty more typesafe, but I don't think that exclusively providing the proposed functions would be a good tradeoff for "real" programs. The things you've mentioned can easily be implemented on top of the current binding. A question would be: Should utility functions like the ones you've mentioned be included in the Haskell binding, too? And if yes, what would be their exact types? What do other people on this list think?
I agree. I think HOpenGL should be a fairly straight wrapper on top of OpenGL. For several reasons, one of them being that people are familiar with OpenGL and shouldn't have to unlearn all of that just to use the Haskel binding. If the wrapper is light weight then the original OpenGL reference manual can be enough documentation, if there's too much stuff stacked on top of OpenGL then we need new manuals. If someone wants to write their own Haskell based renderer, then please do and let us know where to find it, but IMO it's definately a good idea to expose the "straight" wrapper (that way everyone could write their own renderer the way they want it). I'd much rather effort is spent trying to support some of the newer features of OpenGL (shaders!), as that is kind of a deal-breaker for me. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862
Am Samstag, 28. Oktober 2006 14:56 schrieb Sebastian Sylvan:
[...] I'd much rather effort is spent trying to support some of the newer features of OpenGL (shaders!), as that is kind of a deal-breaker for me.
"Listen to your customers!" :-) OK, I've started to make a binding of the GLSL API in the OpenGL package. It currently still misses the parts to specify uniform variables and user-defined vertex attributes, but apart from that it should be complete: http://haskell.org/HOpenGL/newAPI/OpenGL/Graphics-Rendering-OpenGL-GL-Shader... Haddock comments are still missing, but the module should be self-explaining for people who know the latest OpenGL spec. A few remarks about the design: * Shaders are only dynamically typed in OpenGL itself, but the Haskell binding statically distinguishes vertex shaders and fragment shaders, and a type class is used for common operations. Apart from being a bit cleaner, this enables both kind of shaders to be an instance of ObjectName. * compileShader, linkProgram and validateProgram return () and not Bool, although probably most of the time the correspoding getter will be used immediately afterwards to check the result of the operation. This is done to keep "the spirit" of OpenGL and enables easy checks in a completely different part of the program. * glAttachShader, glDetachShader and glGetAttachedShaders are unified into a single state variable, because the attached shaders are semantically simply a part of the program state in question. Separate API entries are very probably not needed just because of performance reasons. I hope that I'll implement the missing GLSL API parts soon, including some examples from the Yellow Book, but it would be great to get some feedback at this early stage already. Cheers, S.
participants (3)
-
Henning Thielemann -
Sebastian Sylvan -
Sven Panne