On 1/16/06, Wolfgang Jeltsch <wolfgang@jeltsch.net> wrote:
Am Freitag, 6. Januar 2006 22:17 schrieb Wolfgang Jeltsch:
Hello,
what's the reason behind the HOpenGL gears only being about 2/3 as fast as glxgears on my computer? Since I don't use any 3D acceleration, I thought that most of the CPU's time is spend for rendering and displaying so that speed differences between Haskell and C shouldn't matter that much.
Best wishes, Wolfgang
Hmm, no reply until now. :-(
A related question: I plan to let "my" students write some HOpenGL based applications in a practical course whose intend is to train them in functional and logic programming. One of these applications should simulate a flight over a landscape whose surface is modelled via fractal brownian motion. So the program needs to display a rather large amount of geometric primitives and needs to do this rather fast because the thing is animated. Now my question: Is Haskell in conjunction with HOpenGL overstrained with this problem or can I expect the application to run fast enough to not make the students laugh about Haskell's speed. :-) Of course, the program should be run only on graphic cards with 3D acceleration.
I'd be happy about quick replies. :-)
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, or (better) vertex buffer objects. Furthermore you should do some hierarchical culling on the terrain (using, e.g. a quad-tree) to avoid drawing things which are not visible. Also, some sort of level-of-detail-scheme is probably a good idea (blocks of terrain far away have lower level of detail). To summarize: Drawing vast terrains quickly has much more to do with algorithmic cleverness rather than miniscule overheads from library bindings. You may want to find a good terrain-rendering library rather than implementing it yourself. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862