cl-opengl-devel

cl-opengl-devel@common-lisp.net

214 discussions

Re: [cl-opengl-devel] I hate windows, too, but....
by Ken Tilton 29 Apr '06

29 Apr '06

On 4/29/06, Brad Beveridge <brad.beveridge(a)gmail.com> wrote: > > Darcs binaries for windows ... > > http://darcs.net/DarcsWiki/CategoryBinaries#head-c7910dd98302946c671cf63cb6… > Is that what you're after? Brilliant, thx. Can't believe I could not Google up even the main darcs site. But now I find myself wondering, if I /do/ run darcs from the command line, I wonder what command I would enter? Most open source sites help lamers like me by suggesting the precise CVS command to enter. Or just offer a tarball of the last stable release. Meanwhile, a comrade in arms kindly put me out of my misery and sent me a tarball and I am happily running the examples. /Very/ nice bindings! Congrats to all. Thx again, brad. kt

2 1

[cl-opengl-devel] I hate windows, too, but....
by Ken Tilton 29 Apr '06

29 Apr '06

... how the hell do I get to these great bindings?!!! :) Howzabout a tarball, folks? Or did I just miss that link. tarball would work because all my win32 "zip" utilities read TAR and GZ, but I have not yet found a win32 utility that speaks Darcs. Hmmm. I will fire up my Mac and see if I have any luck over there. thx, ken

2 1

[cl-opengl-devel] Building cl-opengl require some changes in code.
by Denis Rtveliashvili 14 Apr '06

14 Apr '06

I've managed to build the cl-opengl somehow, but it required some changes in code. I am new to LISP and cl-opengl and I do not know what would be the best. Probably it is worth to change the cl-opengl a little? So I would like to share my findings with you hoping that you'll find them useful. 1. It was necessary to declare the usage of GL and GLU before GLUT. Otherwise nothing compiled. I added the following lines to glu/library.lisp on my Linux box: (define-foreign-library gl ((:not :darwin) (:default "libGL"))) (use-foreign-library gl) and the following lines to glut/library.lisp: (define-foreign-library gl (:unix (:or "libGL.so"))) (define-foreign-library glu (:unix (:or "libGLU.so"))) (use-foreign-library gl) (use-foreign-library glu) 2. The gluCheckExtension definition did not compile. I had to change the line (defcfun ("gluCheckExtension" check-extension) (:boolean gl:boolean) to (defcfun ("gluCheckExtension" check-extension) boolean in the glu/glu.lisp file. 3. Running the GLUT demos showed that "gears" froze when I pressed ESC. Further investigation have shown that at least two methods which do not exist in standard GLUT are being used in the demo and the glut bindings. They are: glutMainLoopEvent glutLeaveMainLoop According to http://freeglut.sourceforge.net/docs/api.php, they are a part of FreeGLUT and the original GLUT does not contain them. Good luck! rtvd

2 1

[cl-opengl-devel] How to build cl-opengl ?
by Denis Rtveliashvili 14 Apr '06

14 Apr '06

I'm sorry for such question, but I can't find out how to build the cl-opengl. Previously I've built cl-sdl and it was fun, but the project seem to be abandoned and I want to switch to cl-opengl. Unfortunately, I do not see any instructions on building the cl-opengl. :( I tried to build it in the following way: 1. Installed rt and cffi. I use Gentoo, so I emerged them. 2. Then I built them by running SBCL and running commands like (asdf:oos 'asdf:load-op 'cffi) in /usr/share/common-lisp/systems Everything was built without problems. 3. Then I downloaded the cl-opengl sources from the darcs repository at http://common-lisp.net/project/cl-opengl/darcs/cl-opengl/ 4. I noticed that the Makefile has only "clean" target which was strange. 5. Then I tried to build the cl-opengl by running (asdf:oos 'asdf:load-op 'cl-opengl) Everything went fine. 6. But when I tried to compile the rest (examples, etc.) I experienced a strange problem. Running (asdf:oos 'asdf:load-op 'cl-glut-examples) lead to the following error: ---- debugger invoked on a LOAD-FOREIGN-LIBRARY-ERROR: Unable to load any of the alternatives: ("libglut.so" "libglut.so.3") Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [RETRY ] Try loading the foreign library again. 1: [USE-VALUE] Use another library instead. 2: [RETRY ] Retry performing #<ASDF:LOAD-OP NIL {AC1AE89}> on #<ASDF:CL-SOURCE-FILE "library" {ABAE199}>. 3: [ACCEPT ] Continue, treating #<ASDF:LOAD-OP NIL {AC1AE89}> on #<ASDF:CL-SOURCE-FILE "library" {ABAE199}> as having been successful. 4: [ABORT ] Exit debugger, returning to top level. (CFFI::HANDLE-LOAD-FOREIGN-LIBRARY-ERROR (:OR "libglut.so" "libglut.so.3") "Unable to load any of the alternatives:~% ~S" ("libglut.so" "libglut.so.3")) ---- I do not understand, how could it be. My system does contain libglut.so and libglut.so.3 in /usr/lib. And different opengl examples compile with it. Of course, It can be a problem with CFFI, but the CFFI was built without any errors (including CFFI tests). Please, let me know if you have any information on how to fix this problem. I feel that my current LISP experience is not strong enough to fix the problem alone. Thank you beforehand, rtvd

2 1

[cl-opengl-devel] GL Evaluator Patches
by James Bielman 12 Apr '06

12 Apr '06

Hi, Here are a pair of patches that add the appropriate enums for GL-ENABLE to work with evaluators, and to convert the contents of the Lisp arrays passed to MAP-1 and MAP-2 to floats. Thanks, James

2 1

[cl-opengl-devel] Webpage update
by Luís Oliveira 11 Apr '06

11 Apr '06

Hello, Brad's e-mail reminds me that I forgot to say something about the webpage. So here it is (mostly for Oliver): I added some simple information to the webpage. -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/ Equipa Portuguesa do Translation Project http://www.iro.umontreal.ca/translation/registry.cgi?team=pt

1 0

[cl-opengl-devel] A few questions about cl-opengl
by Brad Beveridge 11 Apr '06

11 Apr '06

Hi all, I've just been taking a quick peek at the OGL bindings that have been generated for this project. The bindings look nice. 1) Are the bindings all hand generated, or is there some simple automation helping out? 2) Does this project aim to generate raw bindings, and then a Lispy layer on top? 3) I noticed the OpenGL2 logo - is that the target version? 4) Is there a design in place to handle OGL extensions? >From the quick peek that I took glDrawArrays is not yet supported. I'm guessing that this will require a bit of framework, because of the need to feed glDrawArrays (and other array based functions) data that won't move with GC. Are there any thoughts on how this will work? I would guess that using C's malloc might be an idea, but then there is potential for leaks unless you proxy the array with a Lisp object that can free the malloc'ed array when collected. I did notice something that looked like it copied a Lisp array into a foriegn array, but IMHO this will be too slow in the long term. I'm toying with the idea of writing some OGL stuff in Lisp, and it looks to me that since array operations are so common in OpenGL, that they ought to be well supported by the binding. Am I making sense here, or are there aspects of this I am not understanding? It is quite possible, I'm relatively new to Lisp :) Cheers Brad

2 1

[cl-opengl-devel] freeglut.dll + scope of cl-opengl
by Lester Vecsey 23 Feb '06

23 Feb '06

It took me some time to find a copy of freeglut.dll to place into my system folder, eventually retrieving it from http://www.turtle.dds.nl/gl4newlisp/index.html On windows the freeglut source is currently only meant to be built with MSVC, as opposed to mingw/msys, and it may be some time until thats resolved. So it might be a good idea to make a copy of the above mentioned freeglut.dll available at the common-lisp.net/project/cl-opengl page. A couple other minor notes with the redbook examples so far. With CLISP, the character #\Esc is mentioned in rb3-lines.lisp and rb4-poly.lisp, and above, and had to be changed to #\Escape As I understand it cl-opengl is currently dependent on freeglut to open a GL canvas. Is there any interest in having a few C functions to call in to, or perhaps written entirely in Lisp as CFFI to each of the required underlying functions, to generate the Windows HWND and XWindows surfaces? On windows, the WndProc functions which takes care of mouse and keyboard events would be handled with a separate package, and similarly for XWindows with its Xevents. The benefit here is that for many applications you may not need the extensive menu system of freeglut and thus can eliminate the dependency on that library. The other question I have is about the scope of cl-opengl, in terms of handling applications meant to run at 60hz frame rate in the following sense; it would seem that cl-opengl would be the place to have a compiler of sorts, to handle a common situation where conditionals are placed in the main rendering loop to draw sets of Gl primitives. Suppose in my application I toggle one of these such that now the rendering loop makes an additional call into a function that has a glDrawArrays call for some set of polygons, along with other conditionals in the function that branches for choosing between other GL primitives. An extra set of polygons may be drawn with a bright color to draw attention to some part of the visual model, and so on. This is where cl-opengl functions or macros would step in because my Lisp code thus wrapped with some opengl-with statements would effectively have these gl primatives bundled into consecutive display lists where applicable such that in the final analysis there are just a minimal set of glCallList statements being made to the hardware. Those very same calls to glCallList would persist for many frames until the application toggles additional code so that only the affected and adjacent display lists get rebuilt. The programmer would use these wrappers only around code that would benefit from having these display lists built to persist over more than a few frames. As I understand it that was one of the stated goals of the cells opengl framework though having looked through the current cl-opengl code the closest thing I can come to this is found in util.lisp, and no examples as of yet to do the above. If this can be cleanly addressed conceptually by adopting some layout when implementing applications I'd like to hear about that too. Currently for my OpenGL programs I've amassed a set of lower level C functions that take variables representing states, i.e. packed into an unsigned 32 bit value, and use display lists and just recompute the important ones where appropriate. A set of Lisp wrappers would probably dramatically change the way such code would look and is approached, making it much more compact in terms of number of lines and perhaps even packed maximally linearly efficient, so to speak, for eliminating unnecessary gl statements in the main loop, all with little effort from the programmer. As a specific example, a call to reset the glColor to white at the beginning of a functions processing that may have much more work to do, depending on its current toggles, could actually be tossed into a preexisting display list from the previous function that had its trailing end of work to do. However doing that manually is out of the question since it would involve much more code, either a dedicated display list for that one area or even more time consuming if statements in other functions so it can be tacked on. Overall, once packed into the list it would be a very minor performance win by reducing just that one call for a gl primitive, for sure, however it could add up when you consider the overlap of various functions in the main loop each of which are doing some subwork. In a C language perhaps the framework would look something like having function pointers to a heading and trailing set of gl primitive code which would be considered static for each of the subwork functions, perhaps labeled header and footer, and the actual dynamic code that the subwork function implements itself. Assuming the guts of the subwork function becomes ``static'' for at least a few frames, then all of it can be absorbed into a display list and in fact the entire function with all its conditionals effectively disappears, from a gl runtime perspective. Later that portion of the display list can be regenerated to that depth when requested by a mouse or key toggle, i.e., an outside function, and be called again down to that depth so it is fully rebuilt with current values, and re-absorbed into the current master chain or set of the minimal amount of display lists. Imagine a scenario where hundreds of frames have gone by with no changes from network, mouse, or keyboard events. Then its possible that all the gl calls can be placed into a single display list and at some point the list will have to be split so that different code can be inserted. So if the main list was previously in two sublists before, and some feature was just toggled back on then it might be a good idea to have kept those sublists around for a while so now three lists are ready to be called; the outer two sublists, and the newly recomputed feature. After many frames pass, sublists that have gone unchanged can be merged together. And again, code that is likely to change every frame would simply never be wrapped with these lisp macros to begin with.

2 2

[cl-opengl-devel] New CFFI features relevant to cl-opengl
by Luís Oliveira 22 Feb '06

22 Feb '06

Hello, I have added macroexpansion-time translators to CFFI and this is quite relevant to cl-opengl. Here's an example: CFFI> (defctype ensure-float :float) ENSURE-FLOAT CFFI> (defmethod expand-to-foreign (value (type (eql 'ensure-float))) (if (constantp value) (float (eval value)) `(float ,value))) ; Compiling LAMBDA (.PV-CELL. .NEXT-METHOD-CALL. VALUE TYPE): ; Compiling Top-Level Form: #<STANDARD-METHOD EXPAND-TO-FOREIGN (T (EQL ENSURE-FLOAT)) {4053169D}> CFFI> (macroexpand-1 '(defcfun "sqrtf" :float (x ensure-float))) (PROGN NIL (DEFUN SQRTF (X) (LET ((#:G2792 (FLOAT X))) (VALUES (%FOREIGN-FUNCALL "sqrtf" :FLOAT #:G2792 :FLOAT))))) T CFFI> I propose that we use this in cl-opengl and volunteer to do that. :-) That would mean passing some of the DEFCFUNs in funcs.lisp over to the respective <spec-section>.lisp right? Though I see some functions that are just (defun foo (...) (%foo ...)) what's up with that? -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/ Equipa Portuguesa do Translation Project http://www.iro.umontreal.ca/translation/registry.cgi?team=pt

2 3

[cl-opengl-devel] Minor style questions
by Luís Oliveira 20 Feb '06

20 Feb '06

Hello, I have two small questions: - I pushed a patch that implements a trivial WITH-PUSHED-MATRIX macro. Would WITH-MATRIX be a better name though? - Shouldn't the arguments to gl:clear have the "-bit" end stripped out? Since we're hiding the fact that they are bitmasks anyway... -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/ Equipa Portuguesa do Translation Project http://www.iro.umontreal.ca/translation/registry.cgi?team=pt

3 5

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

cl-opengl-devel