Hi, A picture of my quadgame is atached. I need a kind of hitdetection for knowing where the player want's to set the next stone. I copied for testing the code of Sven but it doesn't work in the right way... As shown in the PickDepth or PickSquare example I added some hitrecord names to each grey square on the picture. When you click on the window, the same code like in the examples is executed. Except of the ortho2D call after the pickMatrix... I do not exactly know, what I have to fill there.. I tried it in the following way: justifyCamera :: GamePackage -> IO () justifyCamera gp = do let C {cp = camPers, cla=camLook} = gpGetCam gp (a,r,n,f) = camPers (e,c,u) = camLook -- matrixMode $= Projection -- loadIdentity GLU.perspective a r n f -- matrixMode $= Modelview 0 -- loadIdentity GLU.lookAt e c u I just commented out the change of the matrixMode. But that isn't right.. I have hits anywhere in the space but not on the planes :( Any good ideas? Or is there a good tutorial except of the gluSpec? My problem is that I don't understand how it should work in all details. Best regards Patrick
Patrick Scheibe wrote:
[...] Any good ideas? Or is there a good tutorial except of the gluSpec? My problem is that I don't understand how it should work in all details.
The FAQs starting at http://www.opengl.org/resources/faq/technical/selection.htm#sele0020 might help to set up and debug your picking code, furthermore there is a rather lengthy tutorial at http://www.lighthouse3d.com/opengl/picking/ Do the PickSquare and PickDepth examples in Haskell work for you? They do for me, but one never knows which bugs might be hidden... :-) Cheers, S.
Hi, I wasn't able to find my problem. So I did some debug stuff. I killed ALL camera justification and made only one rotation and one scale. I did the same in den display method (all stuff only on a projection matrix). I saw my game board from above and everything works fine. (_,maybeHitRecords)<- getHitRecords 128 $ withName (Name 0) $ do preservingMatrix $ do loadIdentity pickMatrix (fromIntegral winx, fromIntegral (500-winy)) (5, 5) vp rotate 90 $ Vector3 1 0 (0::GLfloat) scale 0.3 0.3 (0.3::GLfloat) drawBoardSelection flush So my problem is: in the display func I set the gluperspective on the projection matrix and the gluLookAt, board transformations, ... on the modelview matrix. Isn't it wrong to make all this things on one projectionmatrix when I make the hitdetection?? I'm very sure that my hitrecord method has not the same view of my board like I have. Thats probably the reason why I have hits where I shouldn't have them. In the RedBook they did it on one projection matrix and I works. The opengl guys really know what they do, but could it be that I have to make it a bit different? I will be very gratefull for any good suggestions. Best regards Patrick
Hi, I got it. After reading much stuff, the NeHe Tutorial gave me the one hint I needed. Now it is clear to me that the whole thing is really intuitive. The first thought I have had from the beginning was the right one. In the selection mode (introduced by the getHitRecords) you have to perform all transformations you did by drawing the scene. My problem was that I called loadIdentity above my glupersepective and load a identity matrix into the projection stack. That cleared the pickMatrix stuff. In this case the RedBook is not really helpful for someone who never did those things before. One can come to the conclusion that all actions in selection rendermode must be performed on the projection stack. Nonetheless all my thanks goes to Sven who gave me some important hints with his links to the tutorials. Cheers Patrick
- could it be that the home page has not quite kept up with recent developments?-) I was trying to point some folks on c.l.f towards HOpenGL, to make your good work more widely known, and they quite rightly pointed out that the state of documentation is somewhat confusing (yes, I gave them some newer pointers, but still). - could this list please be covered by the same spam-checkers as the other haskell.org lists? or is it already? cheers, claus ps. if you want to join in, it's burried in the "Re: Reminder: Links meeting imminent" thread: http://groups.google.com/groups?selm=d2epjf%24cci%241%40titan.btinternet.com
Claus Reinke wrote:
- could it be that the home page has not quite kept up with recent developments?-) I was trying to point some folks on c.l.f towards HOpenGL, to make your good work more widely known, and they quite rightly pointed out that the state of documentation is somewhat confusing (yes, I gave them some newer pointers, but still).
I admit being guilty of not updating the pages for a long time... *sigh* Having up-to-date web pages is quite important for a project, I know, so I'll improve this when I find some time in the near future. A lot of Haddock comments wait to be written, either... :-[
- could this list please be covered by the same spam-checkers as the other haskell.org lists? or is it already?
I have no idea about that. SimonM? Cheers, S.
I admit being guilty of not updating the pages for a long time... *sigh* Having up-to-date web pages is quite important for a project, I know, so I'll improve this when I find some time in the near future.
if you're short on time, a few minor changes might help - cvs HOpenGL was ahead of its time, and Haskell implementation releases have caught up, so the main problem is just to remove caveats and future plans that no longer hold or have already been implemented. examples: - home page and README refer explicitly to old version numbers. that's the first stop for anyone browsing for a binding, so perhaps remove these numbers and refer to some part of the source/haddocks that automatically has the correct numbers? eg http://www.haskell.org/ghc/docs/latest/html/libraries/OpenGL/Graphics.Render... http://www.haskell.org/ghc/docs/latest/html/libraries/GLUT/Graphics.UI.GLUT.... also, is there a HOpenGL function that returns the version numbers of current installations one could refer to? lest they try to compile new versions of examples with old haskell installations. - change references to "current" and "new" API to "old" and "current" (links to tutorials, tar-balls vs cvs packages, ghc-only vs ghc&hugs) - as a stop-gap: just stating explicitly on the home page that the web pages lag behind actual development would help, eg. refer to your HOpenGL entry in the current Haskell Communities report, which is already written and clarifies some of the issues (and there's a new one coming up soon;-): http://www.haskell.org/communities/11-2004/html/report.html#sect4.6.2 - docs page: yes, the GLUT docs are more extensive, and the GL/GLU docs may be terse, but even those are a lot better than nothing, especially since you've invested a lot of time on - keeping a close match (and cross links) between HOpenGL structure and OpenGL specs - translating red book examples so, instead of only admitting the current state of docs and pointing to an old (?) tutorial, why not provide the interim strategy all your users have followed more or less successfully: 1. start with opengl docs (red book and online specs) 2. use examples to find translation of red book concepts 3. use haddocks to find translation of spec concepts 4. if there's anything one still can't find, ask on the mailing list, which might (a) give one an answer and (b) lead to an incremental improvement of the docs oh, and link to the current haddocks for GLUT/HOpenGL (see above), as well as the examples dir in GLUT cvs: http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/GLUT/examples/ - releases page: this should all be marked as *old*, with pointers to cvs (cvs.haskell.org nowadays has access instructions, so you can point to that and the OpenGL/GLUT dirs) and ghc haddocks instead http://cvs.haskell.org http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/OpenGL/ http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/GLUT/ - status page: i think you've done much of what you describe as goals here? so many of the comments on this page are misleading and could simply be removed. hmm, okay, there are a few of these minor changes. but perhaps this list will help anyway (if only because it will show up in the list archive;-) cheers, claus
participants (3)
-
Claus Reinke -
Patrick Scheibe -
Sven Panne