From haskell at henning-thielemann.de Thu Oct 26 12:39:48 2006 From: haskell at henning-thielemann.de (Henning Thielemann) Date: Thu Oct 26 11:46:59 2006 Subject: [HOpenGL] Specialized versions of renderPrimitives? Message-ID: Things like renderPrimitive LineLoop $ do vertex v1 ; vertex v2; vertex v3; vertex v4 renderPrimitive Lines $ do vertex v1 ; vertex v2; vertex v3; vertex v4 are indeed close to the OpenGL interface. But we lose a lot of type safety. It would be more concise and safer to write lineLoop [v1, v2, v3, v4] lines [(v1, v2), (v3, v4)] Is this implemented somewhere? From basvandijk at home.nl Thu Oct 26 18:04:14 2006 From: basvandijk at home.nl (Bas van Dijk) Date: Thu Oct 26 17:08:49 2006 Subject: [HOpenGL] Specialized versions of renderPrimitives? In-Reply-To: References: Message-ID: <200610270004.14287.basvandijk@home.nl> On Thursday 26 October 2006 18:39, Henning Thielemann wrote: > It would be more concise and safer to write > lineLoop [v1, v2, v3, v4] > lines [(v1, v2), (v3, v4)] If I understand the following correctly: http://www.haskell.org/ghc/dist/current/docs/libraries/OpenGL/Graphics-Rendering-OpenGL-GL-BeginEnd.html#v%3ArenderPrimitive With renderPrimitive you can also add additional properties per vertex. Like: renderPrimitive LineLoop $ do color c1 texCoord t1 vertex v1 color c2 texCoord t2 vertex v2 color c3 texCoord t3 vertex v3 color c4 texCoord t4 vertex v4 It would be possible to do it in a type safe manner by having a data type Vertex that has a list of VertexProperties: type Vertex = [VertexProperty] data VertexProperty = Coordinate ... | Color ... | TextureCoordinate ... ... then you can have something like: v1, v2, v3, v4 :: Vertex lineLoop [v1, v2, v3, v4] Regards, Bas van Dijk From sven.panne at aedion.de Fri Oct 27 03:49:39 2006 From: sven.panne at aedion.de (Sven Panne) Date: Fri Oct 27 02:54:13 2006 Subject: [HOpenGL] Specialized versions of renderPrimitives? In-Reply-To: <200610270004.14287.basvandijk@home.nl> References: <200610270004.14287.basvandijk@home.nl> Message-ID: <200610270949.40013.sven.panne@aedion.de> Am Freitag, 27. Oktober 2006 00:04 schrieb Bas van Dijk: > On Thursday 26 October 2006 18:39, Henning Thielemann wrote: > > It would be more concise and safer to write > > lineLoop [v1, v2, v3, v4] > > lines [(v1, v2), (v3, v4)] > > If I understand the following correctly: > http://www.haskell.org/ghc/dist/current/docs/libraries/OpenGL/Graphics-Rend >ering-OpenGL-GL-BeginEnd.html#v%3ArenderPrimitive > > With renderPrimitive you can also add additional properties per vertex. > Like: [...] Yes, exactly. In http://www.haskell.org/ghc/dist/current/docs/libraries/OpenGL/Graphics-Rendering-OpenGL-GL-VertexSpec.html you can see all the attributes a vertex has when using the traditional fixed function pipeline. When using GLSL (not yet implemented in my binding), a vertex can have an arbitrary number of additional attributes. > It would be possible to do it in a type safe manner by having a data type > Vertex that has a list of VertexProperties: > > type Vertex = [VertexProperty] > > data VertexProperty = Coordinate ... > > | Color ... > | TextureCoordinate ... > > ... This doesn't cover arbitrary attributes used by GLSL, but of course we could have a few more alternatives in VertexProperty for this. And of course you would need different alternatives for e.g. Color3, Color4, TextureCoordinate1, etc. What makes this a little bit ugly is the fact that one would have to use different constructors for places in the API where e.g. exactly a color value with 4 floating point components is expected. A VertexProperty would be much too general in those cases, therefore I've chosen to use type classes. 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. But having direct access to the IO monad is more important to access e.g. IORefs etc. within the action passed to renderPrimitive than a marginally safer typing. There are tons of places in OpenGL where the caller can do something wrong which can't be detected by type inference. And a final hint: No serious OpenGL program will make heavy use of renderPrimitive, vertex arrays and/or buffer objects are the way to go for larger sets of data: http://www.haskell.org/ghc/dist/current/docs/libraries/OpenGL/Graphics-Rendering-OpenGL-GL-VertexArrays.html http://www.haskell.org/ghc/dist/current/docs/libraries/OpenGL/Graphics-Rendering-OpenGL-GL-BufferObjects.html The renderPrimitive way of throwing data at the OpenGL pipeline is not even included in OpenGL ES, and it is on the death row for future versions of the full OpenGL, too. Cheers, S. From haskell at henning-thielemann.de Fri Oct 27 07:25:21 2006 From: haskell at henning-thielemann.de (Henning Thielemann) Date: Fri Oct 27 06:31:41 2006 Subject: [HOpenGL] Specialized versions of renderPrimitives? Message-ID: 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. From sven.panne at aedion.de Sat Oct 28 05:09:23 2006 From: sven.panne at aedion.de (Sven Panne) Date: Sat Oct 28 04:13:52 2006 Subject: [HOpenGL] Specialized versions of renderPrimitives? In-Reply-To: References: Message-ID: <200610281109.23678.sven.panne@aedion.de> 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. From sylvan at student.chalmers.se Sat Oct 28 08:56:02 2006 From: sylvan at student.chalmers.se (Sebastian Sylvan) Date: Sat Oct 28 08:00:31 2006 Subject: [HOpenGL] Specialized versions of renderPrimitives? In-Reply-To: <200610281109.23678.sven.panne@aedion.de> References: <200610281109.23678.sven.panne@aedion.de> Message-ID: <3d96ac180610280556n3aa6a909me538f2d20372e49c@mail.gmail.com> On 10/28/06, Sven Panne wrote: > 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