---------------------------------------------------------------------- -- | -- Module : Graphics.FieldTrip.Vertex -- Copyright : (c) Conal Elliott 2008 -- License : BSD3 -- -- Maintainer : conal@conal.net -- Stability : experimental -- -- Experiment with vertex specs ---------------------------------------------------------------------- -- I'm torn about using this coding trick. HOpenGL has a 'Vertex' -- class. I added instances for normals and colors, and for pairs. Then -- surfaces over any nested pairing of such things can be rendered. -- Moreover, one can do interpolation and differentiation generically, if -- the components support those operations. However, it's not really -- safe, given the order-sensitivity of processing of these components, and -- specifically that the real vertex must come last. Perhaps provide a -- type of vertex-with-adornment, and give it a 'VectorSpace' instance. I -- could play the tuple game on the adornments. Even represent the -- vertex-with-adornment as a newtype around a pair, deriving the -- 'VectorSpace' instance. module Graphics.FieldTrip.Vertex where import Graphics.Rendering.OpenGL -- Pairs as vertices, processed left-to-right. -- The real vertex then must be given last! instance (Vertex v, Vertex v') => Vertex (v,v') where vertex (v,v') = vertex v >> vertex v' vertexv = error "vertexv: undefined on pairs" newtype NormalV n = NormalV n instance Normal n => Vertex (NormalV n) where vertex (NormalV n) = normal n vertexv = error "vertexv: undefined on NormalV" newtype ColorV n = ColorV n instance Color n => Vertex (ColorV n) where vertex (ColorV n) = color n vertexv = error "vertexv: undefined on ColorV" -- The pairing trick provides 'VectorSpace' and 'Num' operations for free, -- including derivatives and interpolation. I think we could get a lot of -- genericity out of this trick. -- -- However, it's not really safe, given the order-senstivity, and -- specifically that the real vertex must come last.