Re: [cl-opengl-devel] a patch to add a support for the Vertex Arrays
On 02/05/07, Denys Rtveliashvili <rtvd@mail.ru> wrote:
I created a patch for adding a support for Vertex Arrays in cl-opengl.
There's been some work on that already. I've been meaning to announce this branch on this list, so here it goes. There's a cl-opengl-thomas branch in <http://common-lisp.net/~loliveira/darcs/>, which, among other things, includes some work on vertex arrays, including a macro for defining array layouts. It depends on the cffi-newtypes tree which you can find in that same directory. Please have a look at that branch and let us know what you think, how that relates to your work, etc... Thanks. -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/
Luís Oliveira пишет:
I created a patch for adding a support for Vertex Arrays in cl-opengl. There's been some work on that already. I've been meaning to announce
On 02/05/07, Denys Rtveliashvili <rtvd@mail.ru> wrote: this branch on this list, so here it goes. There's a cl-opengl-thomas branch in <http://common-lisp.net/~loliveira/darcs/>, which, among other things, includes some work on vertex arrays, including a macro for defining array layouts. It depends on the cffi-newtypes tree which you can find in that same directory. Beg your pardon, is Charlie MacMackin's vertex array patch included in cl-opengl-thomas? He sent it to the list last November, if I'm not mistaken, but not in darcs format. I resent it again together with some other changes, made by myself, in March, in darcs format this time. If not, it seems we now have three (different?) vertex array patches :) Where is the maintener? :)
Cheers, Dmitri
On 03/05/07, Dmitri Hrapof <hrapof@common-lisp.ru> wrote:
Beg your pardon, is Charlie MacMackin's vertex array patch included in cl-opengl-thomas?
Thomas pointed out some problems with Charlie's patch and came up with an alternative. Also, in that branch, the raw bindings are auto-generated from the spec files.
I resent it again together with some other changes, made by myself, in March, in darcs format this time. If not, it seems we now have three (different?) vertex array patches :) Where is the maintener? :)
Indeed. Bad maintainership on my part, sorry about that. I'll try to send an email to this list summing up the changes in that branch soon. Meanwhile, you're very welcome to play with the vertex array stuff present in that branch. -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/
Hi, I think I need to have more LISP experience to get the idea how it works :-) As far as I see, when a function like cl:vertex-pointer is called, the arguments are automatically converted to native arrays. Perhaps it's one of the features of the new CFFI library. Could you tell a few words about the things which happen behind the scenes? And how do you make sure that the native array does not get garbage-collected / moved / re-used until the next call to the ...-pointer function? ------ As for my patch, it is quite simple and does not require new CFFI. While the drawback is that it does not support interleaved arrays. On the other hand, I do not see any reason why they could be useful in LISP as their complexity seems to overweight the benefit. - According to the OpenGL specification, there are 9 types of pointers which can be used for batch-drawing with the functions like glDrawElements. Also there are 9 client states. And it is important that the arrays have to be available since their declaration to OpenGL using the functions like glVertexPointer up to the moment when they are already used and are not going to be used any more. - On LISP side the the arrays can be specified either as an array (1D or 2D, depending on the case) or as a sequence (which is treated like a 1D array). Theoretically it is possible to support a 2D list-based structure or a native representation. That is not yet implemented and can be easily added. My implementation maintains 9 native arrays. Each time a ....pointer function is called, the array is populated from the supplied data structure. There is no need to specify the "width" of the data. It is retrieved from the source data directly. The array is maintained until the moment it is declared that it not going to be used or the program terminates. This guarantees its availability to the OpenGL subsystem. ....-pointer functions are called either with a data structure or with "nil" as a parameter. If it is "nil", the respective client state is disabled. If not, the state is enabled and the data structure is mapped to the native array (the array is resized when necessary) and then advertised to OpenGL using functions like glColorPointer. So, there is no need to maintain the client state manually. So, the code for aapoly demo from the Red Book (method "draw") looks like this: (let ((colors (make-array '(8 4) :initial-contents '((0.0 0.0 0.0 1.0) (1.0 0.0 0.0 1.0) (0.0 0.0 1.0 1.0) (1.0 1.0 0.0 1.0) (0.0 0.0 1.0 1.0) (1.0 0.0 1.0 1.0) (0.0 1.0 1.0 1.0) (1.0 1.0 1.0 1.0)))) (indices (make-array '(6 4) :initial-contents '((4 5 6 7) (2 3 7 6) (0 4 7 3) (0 1 5 4) (1 5 6 2) (0 3 2 1)))) (verticles (make-array '(8 3) :initial-contents `((,x0 ,y0 ,z0) (,x1 ,y0 ,z0) (,x1 ,y1 ,z0) (,x0 ,y1 ,z0) (,x0 ,y0 ,z1) (,x1 ,y0 ,z1) (,x1 ,y1 ,z1) (,x0 ,y1 ,z1))))) (gl:vertex-pointer verticles :float) (gl:color-pointer colors :float) (gl:draw-elements :quads indices) (gl:color-pointer) (gl:vertex-pointer)) Thank you, Denis Rtveliashvili
On 02/05/07, Denys Rtveliashvili <rtvd@mail.ru> wrote:
I created a patch for adding a support for Vertex Arrays in cl-opengl.
There's been some work on that already. I've been meaning to announce this branch on this list, so here it goes. There's a cl-opengl-thomas branch in <http://common-lisp.net/~loliveira/darcs/>, which, among other things, includes some work on vertex arrays, including a macro for defining array layouts. It depends on the cffi-newtypes tree which you can find in that same directory.
Please have a look at that branch and let us know what you think, how that relates to your work, etc...
Thanks.
-- Luís Oliveira http://student.dei.uc.pt/~lmoliv/ _______________________________________________ cl-opengl-devel mailing list cl-opengl-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel
Hi Luís, Returning back to the solution for Vertex Arrays in the cl-opengl-thomas branch, could you tell a few words about it? I tried to get an idea myself, but I can't even get it working :( Does it work for you? When I compile the varray.lisp, I see this: "Symbol "VERTEX-POINTER" not found in the CL-OPENGL package." Regards, Denys
There's been some work on that already. I've been meaning to announce this branch on this list, so here it goes. There's a cl-opengl-thomas branch in <http://common-lisp.net/~loliveira/darcs/>, which, among other things, includes some work on vertex arrays, including a macro for defining array layouts. It depends on the cffi-newtypes tree which you can find in that same directory.
Please have a look at that branch and let us know what you think, how that relates to your work, etc...
Thanks.
-- Luís Oliveira http://student.dei.uc.pt/~lmoliv/ _______________________________________________ cl-opengl-devel mailing list cl-opengl-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel
Denys Rtveliashvili <rtvd@mail.ru> writes:
When I compile the varray.lisp, I see this: "Symbol "VERTEX-POINTER" not found in the CL-OPENGL package."
That example hasn't been updated yet. Try examples/misc/opengl-array.lisp instead. -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/
That example hasn't been updated yet. Try examples/misc/opengl-array.lisp instead. Thank you Luis,
The demo works for me and now it is clear how it works (in most aspects). So I can compare the implementation in the cl-opengl-thomas branch with mine. I will use "T" as an alias for the cl-opengl-thomas branch and "D" as an alias for mine. MEMORY CONTAINERS ----------------- T: Any manipulations on vertex arrays are made in native memory. The arrays are typed in a very nice manner (and I guess this is made thanks to the features from the new CFFI). D: The vertex arrays are stored in memory structures native to LISP (1D and 2D arrays, sequences). The arrays are typed at the point of the actual declaration of arrays to the OpenGL when the implementation implicitly copies the data to the native arrays. A support for direct native arrays can be added, but that's not yet ready. MEMORY MANAGEMENT ----------------- In both cases the memory management is performed correctly in the sense that the arrays are available for the OpenGL whenever it needs it. However... T: The memory must be allocated and freed explicitly. D: The memory is allocated and deallocated implicitly unless user requires something else. CLIENT STATE MANAGEMENT ----------------------- T: The client state is managed using enable/disable-client-state functions. D: The client state is managed automatically. When a vertex array is declared, the respective client state is turned on. When it is declared to be null, the client state is turned off. SUPPORT FOR DIFFERENT KINDS OF VERTEX ARRAYS -------------------------------------------- T: At least the "vertex array" is supported. It is not clear for me if the rest of arrays like color arrays and edge flag arrays are supported. Probably they are not. D: All kinds of vertex arrays are supported. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- MY CONCERNS ----------- For me, the main concern regarding the approach in cl-opengl-thomas branch is that the speed of memory access for this new kind of native arrays is questionable. You see, before implementing the support for Vertex Arrays I spent a day with the SBCL trying to figure out what is the fastest way to access the native arrays. The disassembled code does not look great even for ordinary typed LISP arrays. For simple 1D native arrays is is slightly worse. And for the memory access like this: (setf (gl:glaref (vertex-array w) i 'r) 255) The "disassemble" shows and enormous listing. That's because there is a sequence of function calls just to fill out a cell in the array. PROPOSED SOLUTION ----------------- I propose a hybrid solution which will allow for both ease of use and efficiency. MEMORY CONTAINERS & MEMORY MANAGEMENT ------------------------------------- An approach closed to solution D is used, so that it is possible to use data structures native to LISP and provide a fast way of doing things. However, the code is modified in a way that if a user wants to use a native array directly, he can do it. In such case, it is the native arrays passed to the respective function which is declared to the OpenGL. Otherwise, the data structure will be copied to the native array and managed automatically. This will give benefits of both approaches. CLIENT STATE MANAGEMENT ----------------------- I'd prefer an automatic one, but I do not insist on it in any way. :-) Please, let me know what you think. I am looking forward for the most high-performance 3D in LISP so an effective an usable support for Vertex Arrays / shaders / etc. is very interesting for me. Thank you, Denys Rtveliashvili P.S. And by the way, can the new features from cffi-newtypes be merged into the main CFFI?
On Thu, 10 May 2007 08:41:59 +0400 Denys Rtveliashvili <rtvd@mail.ru> wrote:
That example hasn't been updated yet. Try examples/misc/opengl-array.lisp instead. Thank you Luis,
The demo works for me and now it is clear how it works (in most aspects). So I can compare the implementation in the cl-opengl-thomas branch with mine. I will use "T" as an alias for the cl-opengl-thomas branch and "D" as an alias for mine.
... snip ...
Thank you, Denys Rtveliashvili
Hi all, I'd just like to chime in and say that the foremost priority here should be just to get a VA implementation out before they've gotten obsolete. If the rumblings on the opengl.org message boards are any indication of the future (I'm guessing they are, given the people who post there), it looks like support for client-side vertex arrays could be completely dropped in future OpenGL (Longs Peak). More important is a solid and flexible VBO interface (which doesn't require things to be kept in client memory), hopefully alot of the work done on VAs is already applicable to that. Sincerely yours, Mikael Lax
participants (5)
-
Denys Rtveliashvili -
Dmitri Hrapof -
Luis Oliveira -
Luís Oliveira
-
Mikael Lax