Are there plans to support more extensions anytime soon? Specifically those that deal with fragment and vertex programs (ARB_vertex_program, ARB_fragment_program) as well as rendering to off-screen rendertargets and such (EXT_framebuffer_object). Pretty significant stuff if you want to do anything half-way serious with modern hardware. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862
Sebastian Sylvan wrote:
Are there plans to support more extensions anytime soon?
Yes, definitely.
Specifically those that deal with fragment and vertex programs (ARB_vertex_program, ARB_fragment_program) as well as rendering to off-screen rendertargets and such (EXT_framebuffer_object).
My main development platform is x86 Linux and today is the first day that glxinfo shows that the latest & greatest NVIDIA drivers claim that they are OpenGL 2.0 compliant. Hooray! :-) I am very interested in the extensions you've mentioned, but before implementing anything I wanted to have a more or less stable and conformant driver, which seems to be the case now. The first two extensions are rather large ones, so I could need some help here: The most difficult part is how to map these extensions into something "Haskellish" without losing flexibility and/or too much performance. Some API proposals would be highly appreciated. BTW: I still fail to see a good "Haskellish" API for NURBS. Again, API proposals are highly welcome. As a general rule: If you want an extension to be implemented soon, propose an Haskell API for it here on this list, and after we've settled the details I will happily implement it. Of course patches, examples, etc. are welcome, too.
Pretty significant stuff if you want to do anything half-way serious with modern hardware.
Even more significant for non-serious stuff like impressing your friends with the graphical capabilities of Haskell. ;-) Cheers, S.
On 6/11/05, Sven Panne
Sebastian Sylvan wrote:
Are there plans to support more extensions anytime soon?
Yes, definitely.
Specifically those that deal with fragment and vertex programs (ARB_vertex_program, ARB_fragment_program) as well as rendering to off-screen rendertargets and such (EXT_framebuffer_object).
My main development platform is x86 Linux and today is the first day that glxinfo shows that the latest & greatest NVIDIA drivers claim that they are OpenGL 2.0 compliant. Hooray! :-) I am very interested in the extensions you've mentioned, but before implementing anything I wanted to have a more or less stable and conformant driver, which seems to be the case now.
The first two extensions are rather large ones, so I could need some help here: The most difficult part is how to map these extensions into something "Haskellish" without losing flexibility and/or too much performance. Some API proposals would be highly appreciated.
Just a quick reply before I have to go. How about just starting out with a simiple 1:1 mapping (as close as possible to the C-API) so you can work with a while in Haskell and see what is needed. Then you could do cool things like incorporate Conal Elliots Vertigo for writing shaders in Haskell (edsl). Shouldn't be too diffictult to get some basic version up and running. The problem is more like on the fly generating asm-code for various shader versions etc. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862
Sven Panne wrote:
BTW: I still fail to see a good "Haskellish" API for NURBS. Again, API proposals are highly welcome.
The obvious Haskellisation would seem to be along the lines of:
newtype NurbsRendererObj = NurbsRendererObj (Ptr ()) -- GLUnurbsObj*
withNurbsRendererObj :: (NurbsRendererObj -> IO a) -> IO a -- gluNewNurbsRenderer, gluDeleteNurbsRenderer
renderCurve :: NurbsRendererObj -> IO a -> IO a -- gluBeginCurve, gluEndCurve
renderSurface :: NurbsRendererObj -> IO a -> IO a -- gluBeginSurface, gluEndSurface
trimNurbs :: NurbsRendererObj -> IO a -> IO a -- gluBeginTrim, gluEndTrim
pwlCurve :: NurbsRendererObj -> [GLfloat] -- vertices -> MapTarget -- type -> IO () -- gluPwlCurve
nurbsCurve :: NurbsRendererObj -> [GLfloat] -- knots -> [GLfloat] -- control points -> MapTarget -- type -> IO () -- gluNurbsCurve
nurbsSurface :: NurbsRendererObj -> [GLfloat] -- s knots -> [GLfloat] -- t knots -> [[GLfloat]] -- control points -> MapTarget -- type -> IO () -- gluNurbsSurface
[The control points would arguably better as an Array, but the above matches how 2D evaluators are handled.]
various :: NurbsRendererObj -> StateVar a -- gluNurbsProperty, gluGetNurbsProperty
samplingMatrices :: Matrix m => NurbsRendererObj -> SettableStateVar (m GLfloat, m GLfloat, (Position, Size)) -- gluLoadSamplingMatrices
data NurbsCallbackTarget = ...
nurbsCallback :: NurbsRendererObj -> NurbsCallbackTarget -- which -> SettableStateVar (IO ()) -- gluNurbsCallback
For the functions which can only be called within a begin/end pair,
you might want to stuff the NurbsRendererObj into an IORef rather than
having to pass it around .
--
Glynn Clements
participants (3)
-
Glynn Clements -
Sebastian Sylvan -
Sven Panne