Specialized versions of renderPrimitives?

[Henning Thielemann-2]

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?
_______________________________________________
HOpenGL mailing list
HOpenGL@...
http://www.haskell.org/mailman/listinfo/hopengl

[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-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
_______________________________________________
HOpenGL mailing list
HOpenGL@...
http://www.haskell.org/mailman/listinfo/hopengl

[Sven Panne]

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.
_______________________________________________
HOpenGL mailing list
HOpenGL@...
http://www.haskell.org/mailman/listinfo/hopengl

[Henning Thielemann-2]

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.
_______________________________________________
HOpenGL mailing list
HOpenGL@...
http://www.haskell.org/mailman/listinfo/hopengl

[Sven Panne]

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.
_______________________________________________
HOpenGL mailing list
HOpenGL@...
http://www.haskell.org/mailman/listinfo/hopengl

[Sebastian Sylvan-2]

On 10/28/06, Sven Panne <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
[phone]
UIN: 44640862
_______________________________________________
HOpenGL mailing list
HOpenGL@...
http://www.haskell.org/mailman/listinfo/hopengl

[Sven Panne]

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-Shaders.html

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.

_______________________________________________
HOpenGL mailing list
HOpenGL@...
http://www.haskell.org/mailman/listinfo/hopengl