July 2002 - HOpenGL - Haskell.org

ANNOUNCE: HOpenGL 1.03 released
by Sven Panne 31 Jul '02

31 Jul '02

HOpenGL, a Haskell binding for OpenGL and GLUT version 1.03 I am pleased to announce the fourteenth release of the Haskell binding for GL 1.2.1 / GLU 1.3 / GLUT 3.7beta. It offers easy access to *the* industrial strength 3D graphics API and a GUI toolkit. More details about HOpenGL can be found at http://haskell.org/HOpenGL It is yet another compatibility release, which fixes a few bugs in the configuration process and makes installation a bit more flexible. If you are happy with the previous version, you don't need this release, as there are no new features. What's new: * Fixed GLUT version test, so GLUT API version 4 features like game mode and key-up callbacks are correctly detected. * The automatic test for -split-objs works again. * Added support for installing HOpenGL in user-specified locations. * The values of CPPFLAGS and LDFLAGS during configuration are remembered. * The paths to build tools can contain spaces. * The test for GLX has been improved. * Added workaround for buggy SUN OpenGL header. * Renamed --with-Mesa and --with-efence configure options to --enable-Mesa and --enable-efence. As always, feedback and/or patches are highly welcome. Have fun! Sven

1 0

I now know why there's no binding to FTGL nor to GLTT
by Nick Name 24 Jul '02

24 Jul '02

I wanted to make a binding to FTGL or GLTT, or the other one, I don't remember the name. Those all are for C++, not for C. Is there a way? I really don't know anything about calling C++ from C. Is there some way to make haskell bindings for a C++ library? Am I stuck in a dead end? Already? Vincenzo

2 2

GL utilities, toolkits, and questions..
by C.Reinke 23 Jul '02

23 Jul '02

Hi again, given GL's separation of low-level features and other useful stuff, there are a lot of GL utilities around that make GL life less painful. I've been wondering whether anyone is working on making some of those available or willing to share their own hacks in those areas. Typical examples: 1. fonts.. there are n+1 ways to make fonts with GL, so of course none of them are part of the standard fortunately, GLUT has some minimal support, but there must be GL bindings to/converters from free fonts (or at least system fonts:-( around. * aside: there's something odd with GLUT's stroke font width. * HOpenGL returns that as an Int, which seems to match the spec, * but doesn't make sense to me.. "width in pixels" of a stroke * font??? is that a copy and paste error from the preceding * section on bitmap fonts? * oh, and why is the default stroke font size so huge? I have * to scale it down by a factor of 100, it seems, to get into * natural proportions.. 2. snapshots/printing.. again, GL provides only the foundations we all want to show what we do to people who don't have GHC, GLUT, .. of course, you can snapshot static scenes using system tools, but it would be nicer to produce snapshots, preferredly animated (what format, though?), from within HOpenGL. using feedback from the framebuffer, that seems possible. The GL pages also talk about printer-resolution printing by rendering the scene in tiles. could one export 2d-vector graphics (postscript/SVG) from HOpenGL, or always just pixmaps? 3. scene graph libraries.. who wants to play with all the low-level details all the time? as it happens, I'm working on this part;-) work in progress, but see http://www.cs.ukc.ac.uk/people/staff/cr3/FunWorlds/ for outlines of where I'm headed with this. no screen shots yet (see 2 for why), so here's a brief summary of the state of things - static scene graphs and translation to HOpenGL: are relatively straightforward, and I had some experience with VRML-style scene graphs, so that part only grows on demand - dynamic scene graphs: if you've seen my earlier experiments with FunWorlds/VRML, you know that I'm playing with Fran concepts here, but I've now made some modifications to Fran basic, with which I'm quite happy so far (that's the research aspect and hence the current focus) 4. shadows? there seem to be several techniques - is any of them generally applicable (not just shadows on static planes) and portable? 5. GUIs? Sven mentioned several a while ago, one of which looked quite reasonable. 6. others?-) And while we're at it (some have started already): what are you doing/hoping to do with HOpenGL (not just dozens of private versions of Haskell DOOM, I hope?-)? Claus

6 17

Re: [HOpenGL] GL utilities, toolkits, and questions..
by C.Reinke 23 Jul '02

23 Jul '02

> Well, I guess the size itself is not a bug, but a feature of GLUT. But > there is an inconsistency: The spec for glutStrokeCharacter > > http://www.opengl.org/developers/documentation/glut/spec3/node78.html > > talks about "units" (of magnitude 100, as you've already noticed), > while the spec for glutStrokeWidth > > http://www.opengl.org/developers/documentation/glut/spec3/node79.html > > talks about "pixels". The latter is probably a cut-n-paste bug from > the spec for glutBitmapWidth. Just as I suspected. And here's what the glutStrokeWidth and glutStrokeLength man pages in the GLUT sources say: int glutStrokeWidth(void *font, int character); int glutStrokeLength(void *font, const unsigned char *string); glutStrokeWidth returns the width in modeling units of a stroke character in a supported stroke font glutStrokeLength returns the length in modeling units of a string (8-bit characters). This length is equivalent to summing all the widths returned by glutStrokeWidth for each character in the string. So the "int" return type (instead of GLdouble, as I expected) seems possible because of that "units" talk, and the "pixel" talk doesn't seem to belong there in the spec. Sigh, one just needs to know how to read the spec (and the source).. Okay, that gives me another chance to try silly things (centered or right-justified text blocks, in this case;-). Looking forward to "real" font add-ons to HOpenGL, of course, if Vincenzo gets round to it. Btw, while we are sharing tricks and plans - using feedback to output vectorized snapshots wasn't as difficult as I thought (as usual, the redbook_HS examples, here "Feedback.hs", were helpful). A dummy fragment for exporting SVG (http://www.w3.org/TR/SVG/) from HOpenGL is appended (just dealing with lines and polygons, just output the polygons as they come -> possibly incorrect output), and the more complete original for exporting EPS from OpenGL (output polygons in back-to-front order and emulate flat shading) can be found at: Mark Kilgard Achieving Quality PostScript output for OpenGL http://www.opengl.org/developers/code/mjktips/Feedback.html Unfortunately, the resulting vector graphics can be quite large, certainly larger that a JPEG snapshot:-(. They are scalable, which is nice, and with a bit of hacking, one could put several of them into an SVG file, and animate through the snapshots, but then the size problem becomes a real headache. Haven't tried compression yet, nor hidden polygon removal, but I'm currently not inclined to fill in the missing bits in the code, simply because I'm not using it - it was worth a try, though.. Cheers, Claus ----------------------------------- a little HOpenGL to SVG hack import Numeric(showGFloat) .. -- extract x and y coordinates from feedback info, ignore rest svgXYproject (ThreeDColor (Vertex3 x y z) (Prelude.Right (Color4 r g b a))) = (showGFloat (Just 2) x . showString "," . showGFloat (Just 2) (-y) . showString " ") "" -- extract rgb values from feedback info, ignore rest svgRGBproject (ThreeDColor (Vertex3 x y z) (Prelude.Right (Color4 r g b a))) = (showGFloat Nothing (r*100) . showString "%," . showGFloat Nothing (g*100) . showString "%, " . showGFloat Nothing (b*100) . showString "%") "" -- incomplete, as usual.. -- svg (PassThroughToken (PassThroughValue n)) = -- svg (PointToken i) = svg (LineToken i j) = "<polyline stroke=\"rgb("++svgRGBproject i++")\" " ++"points=\""++(concatMap svgXYproject [i,j])++"\"/>" -- what's this? svg (LineResetToken i j) = "<polyline stroke=\"rgb("++svgRGBproject i++")\" " ++"points=\""++(concatMap svgXYproject [i,j])++"\"/>" -- colour the polygon by its first vertex.. svg (PolygonToken is) = "<polygon fill=\"rgb("++svgRGBproject (head is)++")\" " ++"points=\""++(concatMap svgXYproject is)++"\"/>" svg _ = error "Author is too lazy for a complete svg FeedbackToken" -- Write contents of entire buffer. printBuffer :: GLint -> FeedbackBuffer -> IO () printBuffer size buffer = do Just tokens <- getFeedbackTokens size buffer (WindowPosition x y, WindowSize w h) <- get VarViewport putStrLn "<?xml version=\"1.0\" standalone=\"no\"?>" putStrLn "<!DOCTYPE svg PUBLIC \"-//W3C//DTD SVG 20010904//EN\"" putStrLn " \"http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd\">" putStrLn $ "<svg width=\""++show ((fromIntegral w)/50)++"cm\" " ++"height=\""++show ((fromIntegral h)/50)++"cm\" " ++"viewBox=\"0 0 "++show w++" "++show h++"\"" putStrLn " xmlns=\"http://www.w3.org/2000/svg\"" putStrLn " xmlns:xlink=\"http://www.w3.org/1999/xlink\">" putStrLn $ "<g transform=\"translate(0,"++show h++")\">" mapM_ (putStrLn . svg) tokens putStrLn "</g>" putStrLn "</svg>" -- main function, call this in your display callback instead of -- the direct rendering part (here assumed to be executing a -- display list) when you want to output a single scene as SVG. -- feedback buffer overflow tends to be the main error source, -- but I've got no idea how to estimate the size correctly.. printDisplay :: DisplayList -> DisplayAction printDisplay dl = do feedBuffer <- makeFeedbackBuffer 1048576 ThreeDColor' feedbackBuffer feedBuffer renderMode Feedback callList dl size <- renderMode Render printBuffer size feedBuffer freeFeedbackBuffer feedBuffer

1 0

more on FunGEn feedback
by Andre W B Furtado 22 Jul '02

22 Jul '02

BTW, Ronald Legere sent me some nice feedback. Sorry for not mentioning him. -- Andre

1 0

Hi all
by Nick Name 09 Jul '02

09 Jul '02

Just wanted to tell anybody that I am here. Is this list active? Bye Vincenzo Ciancia

3 6

Makefile for the examples
by patrick scheibe 02 Jul '02

02 Jul '02

Hi there. I think I installed HOpenGL successfully. But if I try to compile an example by myself the ghc breaks up. I tried that with ghc -i/usr/lib/ghc-5.02.3/imports/HOpenGL/ -i/usr/lib/ghc-5.02.3/imports/lang/ Hello.hs and got error-messages like Module `GL' is located in package `Main' but its interface file claims it is part of package `HOpenGL' and much of linker-errors. Is there somebody who can give me a short makefile to see what was wrong. I am new in Haskell and use OpenGl in C only. thanx Patrick

2 1

HOpenGL1.2 configure on cygwin & a GLUT scheduling question
by C.Reinke 02 Jul '02

02 Jul '02

had to upgrade from ghc-5.02.2 to ghc-5.02.3 because of an access violation bug, and ghc upgrades "naturally" mean HOpenGL rebuilds.. 1. there's a slight problem with HOpenGL's configure on cygwin: GreenCard installs (as expected) in c:/Program\ Files/GreenCard/ (note the space), and is found there by configure. By default, however, configure seems to lose the escape for the space in the path, so I explicitly give the path as something like: ./configure -with-green-card=c:/Program\\\ Files/GreenCard/green-card.exe That kind of works, but for the test for GreenCard's comma bug, where the executable isn't found, which configure then misinterprets by setting ..bug="yes", which then leads to errors while GreenCarding in make depend. I used to think I understood shell escapes, but that was long ago, and this one has me baffled for the moment - the value of $green_card in configure seems ok when echoed, and cygwin's bash can find the GreenCard executable with the path echo gives for $green_card, but when configure tries to call $green_card, it fails to find the executable (quite unlike later calls during make depend).. For the moment, I override the result of the GreenCard comma bug test to "no", and things seem to work okay, but there has to be a better way to set this right.. An annoying new feature are lots of warnings whenever I compile any HOpenGL stuff, of the kind: Module `GL_BeginEnd' is located in package `Main' but its interface file claims it is part of package `HOpenGL' This is easily rectified by doing make install, and the ghc package option is really nice, so I won't complain;-) but what about people who don't have permission to install the package by adding to ghc's imports? Is it possible to have local packages with central ghc installations? Apart from that, nice work!-) 2. What, if anything, do we know about the scheduling of the GLUT callbacks? Thanks to GLUT's per-thread system, there seems to be only one OS-thread doing all the GLUT/GLU/GL-code for a given window (?), which translates into a single Haskell thread in ghc's (current) default configuration. Can I assume that callbacks will always run to completion, or could keyboard input or redraws come in during a call to display (and potentially trigger a redisplay before the old one has run through?). What about stuff in idleFunc? Claus

2 1