[Haskell] GLUT gears speed

Sebastian Sylvan sebastian.sylvan at gmail.com
Mon Jan 16 16:12:24 EST 2006


On 1/16/06, Wolfgang Jeltsch <wolfgang at jeltsch.net> wrote:
> Am Montag, 16. Januar 2006 15:16 schrieb Sebastian Sylvan:
> > [...]
>
> Hello Sebastian,
>
> thank you for your answer.
>
> > As long as you don't do it naively there should be no problems. I.e.
> > do not draw the terrain using the vertex-calls, but rather use
> > vertex-arrays,
>
> Hmm, this will make it rather complex for my students since they have not much
> experience with Haskell programming.  In addition, where can I find
> documentation about Graphics.Rendering.OpenGL.GL.VertexArrays?
>

I suppose here:
http://www.haskell.org/ghc/docs/latest/html/libraries/OpenGL/Graphics-Rendering-OpenGL-GL-VertexArrays.html

But it should correspond fairly well to any general documentation on
vertex arrays (www.opengl.org will surely have reference documentation
somwhere).

> > or (better) vertex buffer objects.
>
> What's this?
>

It's a fairly recent addition meant to be used instead of vertex
arrays in most cases. I'm not sure if HOpenGL supports them, but I
believe it does.
The main benefit as far as I can tell is that unlike vertex arrays the
data does not need to be validated everytime it's sent to the graphics
card (the implementation is prohibited from assuming that the data in
a vertex array hasn't changed, so it must be validated every time it's
referenced).
VBOs are managed by the graphics driver to a larger extent, so can be
optimized "behind the curtains".


> > Furthermore you should do some hierarchical culling on the terrain (using,
> > e.g. a quad-tree) to avoid drawing things which are not visible.
>
> Too complicated for the practical course.  Doesn't OpenGL already do something
> like this?
>

OpenGL can use scissors to clip triangles and won't perform any
rasterizing if it's outside the screen (not sure how this is set by
default, though). However, you still incur the cost of sending
everything down to the graphics card, which may very well be your
bottle-neck for a large terrain.

> I did not refer to the overheads of the binding but to "the slowness of
> Haskell" (compared to C, of course ;-) ).
>

Well I don't think it's going to be much of a problem, as most of the
heavy stuff happens in the driver and on the graphics card. Unless you
do some really heavy lifting, you should be GPU-limited.


> > You may want to find a good terrain-rendering library rather than
> > implementing it yourself.
>
> Is there one for Haskell?
>

Not that I know of, but if you find one for C it shouldn't be too hard
to create a binding...


/S

--
Sebastian Sylvan
+46(0)736-818655
UIN: 44640862


More information about the Haskell mailing list