gmane.lisp.cl-opengl.devel

Re: Texture coordinates using vertex array

Deepak Surti — 2012-05-16T09:18:42

Hi Louis,

With some more opengl experience under the hood, I think this could be a
problem:
(I have not tried it though):

This was my array definition:

;for textures
(gl:define-gl-array-format mesh-tvertex
  (gl:vertex :type :float :components (x y z))
  (gl:tex-coord :type :float :components (u v)))

I think I should keep a separate array for vertices and textures. Then
things
should work out fine. Is this correct? This is what I currently do when
using
Lispworks with its opengl ffi library.

I will try keep a separate textures array and let you know how it goes.
Thanks,
Deepak

On Wed, May 16, 2012 at 5:13 AM, Luís Oliveira <luismbo< at >gmail.com> wrote:

Re: Texture coordinates using vertex array

Luís Oliveira — 2012-05-15T23:43:10

Hello Deepak,

On Fri, Mar 30, 2012 at 9:51 AM, Deepak Surti <dmsurti< at >gmail.com> wrote:

Did you manage to figure out a solution to your problem?

Cheers,

Re: Extension functions re-defining themselves

Nikodemus Siivola — 2012-04-01T09:01:04


Thanks!

Patch attached -- probably not something to merge as-is, since I
commented out a few extensions due to missing/bad types, but this
builds for me on x86-64 using the default 1Gb heap.

Cheers,

 -- nikodemus
_______________________________________________
cl-opengl-devel mailing list
cl-opengl-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel

Re: Extension functions re-defining themselves

Luís Oliveira — 2012-03-31T23:11:53

On Sat, Mar 31, 2012 at 5:02 PM, Nikodemus Siivola
<nikodemus< at >random-state.net> wrote:

The code is at:
<https://github.com/luismbo/cl-opengl/tree/sbcl-unfriendly-defglextfun>

The test-case is simply compiling cl-opengl. SBCL will exhaust the
heap while attempting to compile gl/funcs.lisp which contains about
2000 usages of DEFGLEXTFUN.

Cheers,

Re: Extension functions re-defining themselves

Jocelyn Fréchot — 2012-03-31T16:46:35


No I haven’t. For now I store function symbols rather than objects.
I guess the overhead of funcall-ing them is negligible in my context.

Re: Extension functions re-defining themselves

Nikodemus Siivola — 2012-03-31T16:02:52


Can you point me at right spot in cl-opengl sources, and provide a
test-case. I think I have an idea...

Cheers,

 -- nikodemus

_______________________________________________
cl-opengl-devel mailing list
cl-opengl-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel

Re: Extension functions re-defining themselves

Luís Oliveira — 2012-03-31T15:42:00

Hello Jocelyn,

I tried it out as well and got similar results. I also tried using
load-time-value for the pointer cache in the hopes that making the DEFUN a
top-level form would appease SBCL but that help too much.

Have you tried using a less smart compiler such as CCL ou CLISP?

Texture coordinates using vertex array

Deepak Surti — 2012-03-30T08:51:52

Hi,

I have written a small library using cl-opengl to do skeletal animation
which works great.
I use vertex arrays in the process. As outlined in opengl-array.lisp under
examples, I have
a gl array of vertices.

To the vertex object in the gl array I added texture coordinates:
(gl:tex-coord :type float :components (u v))

In my code, (just like enable vertex and color array); I enable tex coord
array

; all texture loading code and creating gl vertices/indices code

(gl:enable-client-state :texture-coord-array)
.......
            (gl:bind-gl-vertex-array gl-vertices)
            (gl:draw-elements :triangles gl-indices)
........
(gl:enable-client-state :texture-coord-array)

However it leads to a memory segment address error.

If I go the primitive route, rendering the  triangle vertices and texture
coordinates,
things work fine.

Obviously, as for texture coordinates with draw elements; I am missing
something. I tried
looking up into the source/examples but could not find. [PS: i am no C
expert, so am stuc

Re: Extension functions re-defining themselves

Jocelyn Fréchot — 2012-03-17T11:28:32


I tried this version:

(defmacro defglextfun ((cname lname) return-type &body args)
   (alexandria:with-unique-names (pointer)
     `(let ((,pointer (null-pointer)))
        (defun ,lname ,(mapcar #'car args)
          (when (null-pointer-p ,pointer)
            (setf ,pointer (gl-get-proc-address ,cname))
            (assert (not (null-pointer-p ,pointer)) ()
                    "Couldn't load symbol ~A~%" ,cname)
            (format t "Loaded function pointer for ~A: ~A~%" ,cname ,pointer)
            (push (lambda () (setf ,pointer (null-pointer)))
                  *gl-extension-resetter-list*))
          (foreign-funcall-pointer
           ,pointer
           (:library opengl)
           ,< at >(loop for arg in args collect (second arg) collect (first arg))
           ,return-type)))))

However, compilation of gl/funcs.lisp fails due to heap exhaustion
(using SBCL 1.0.55).

Re: Extension functions re-defining themselves

Luís Oliveira — 2012-03-17T10:01:49

On Fri, Mar 16, 2012 at 9:39 PM, Jocelyn Fréchot
<jocelyn_frechot< at >yahoo.fr> wrote:

At the end of gl/bindings.lisp there's an alternative implementation
of DEFGLEXTFUN that doesn't call compile or redefine anything. Does
that work better for you?

Extension functions re-defining themselves

Jocelyn Fréchot — 2012-03-16T21:39:59

Hello,

I’d like to report the folling issue I bumped into: in
the cl-opengl-bindings package, extension functions defined with
defglextfun will re-define themselves the first time they are called.
This is somewhat an unexpected and potentially undesirable behavior:
if you store one of those function objects before calling it, it will
compile a new object every time it is funcalled.

Thanks

save 3d scene as .obj file

ronni montoya — 2011-11-28T03:13:44

Hi, Is there is a way of saving a 3d scene into a .obj file in common lisp?

Is there any library for this, i was looking for info and i just found
a library called ply that allow only to read .obj file but not save


any idea?

thanks

R,

Re: mouse-driven camera

Luís Oliveira — 2011-09-24T23:50:08

On Sat, Sep 24, 2011 at 12:03 PM, ronni montoya <ronni.montoya< at >gmail.com>
wrote:

Here's a tutorial: <http://www.lighthouse3d.com/tutorials/glut-tutorial/>.

HTH,

mouse-driven camera

ronni montoya — 2011-09-24T11:03:11

Hello im new in this list, im learning opengl with common lisp,  i was
wondering if there is a library or example that allow to control the
perspective of the camera with tthe mouse?

Is there is an easy way of doing this?


thanks


Ronny

Re: CL-OpenGL ES?

Simon Ortiz — 2011-07-19T14:28:42

Great! I'll try to go with Clozure CL while I wait for ECL.

Thanks for the tip!

--
Simón Ortiz B., M.Sc., Ing. en Computación
Linux Registered User #388735



On Tue, Jul 19, 2011 at 22:03, Luís Oliveira <luismbo< at >gmail.com> wrote:

_______________________________________________
cl-opengl-devel mailing list
cl-opengl-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel

Re: CL-OpenGL ES?

Luís Oliveira — 2011-07-19T13:03:35

I think Clozure CL might run there as well. Their SVN repo contains
some Android references.



Cool. Thanks for your feedback.

Re: CL-OpenGL ES?

Simon Ortiz — 2011-07-19T12:14:07

hello,

I'm here reporting on my advance on cl-opengl-es-1.1.

I need a system with OpenGL ES 1.1 for testing. I decided to use
Android. The only CL implementation I know that runs on Android is
ECL.

Before jumping into cl-opengl I decided testing a simple library with
CFFI. It so happens that I stumbled upon a bug with ECL+CFFI that
prevents compiling libraries.

The bug has been acknowledged by the maintainer. As soon as he kindly
fixes the bug, I'll continue with the project.

Cheers,

--
Simón Ortiz B., M.Sc., Ing. en Computación
Linux Registered User #388735



On Wed, Jun 29, 2011 at 23:31, Bart Botta <00003b< at >gmail.com> wrote:

_______________________________________________
cl-opengl-devel mailing list
cl-opengl-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel

Re: CL-OpenGL ES?

Bart Botta — 2011-06-29T14:31:43

If I understand correctly, EGL is something like glx/wgl/etc, and
isn't actually part of OpenGL ES itself, so I'd probably lean towards
a separate cl-egl system containing just the EGL parts. If ES 1.x only
adds data types, I'd probably include them in the main cl-opengl for
now. If there are conflicting function signatures or enums things
would be more complicated... not sure what the best solution for that
would be.

-b-

_______________________________________________
cl-opengl-devel mailing list
cl-opengl-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel

Re: CL-OpenGL ES?

Luís Oliveira — 2011-06-29T14:10:17

Yes, that's my suggestion.



Cool, definitely keep us posted.

Cheers,

Re: CL-OpenGL ES?

Simon Ortiz — 2011-06-29T13:56:53

Alright!

Let me see if I got it all straight:

For our first approach, I'll do a cl-opengl-es-1.1 system which will
depend on cl-opengl as is. I'll write the CFFI definitions for the
egl* functions by hand. I guess I'll define the fixed-point data type
by hand too.

Then we see how to clean it up, if it's worth it.

I'll start working this weekend. Since I still need to understand
cl-opengl in more depth, this could take a while.

I'll keep you posted with the progress (and troubles ;-)

Thanks!

--
Simón Ortiz B., M.Sc., Ing. en Computación
Linux Registered User #388735



On Wed, Jun 29, 2011 at 00:57, Luís Oliveira <luismbo< at >gmail.com> wrote:

_______________________________________________
cl-opengl-devel mailing list
cl-opengl-devel< at >common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel

Re: CL-OpenGL ES?

Luís Oliveira — 2011-06-28T15:57:24

I thing you'd simply get an undefined function error from CFFI.



The former seems cleaner.



Not sure about nicely, but I suppose you could have a
cl-opengl-base-1.1, cl-opengl-base-2.0, etc. If one's going to think
about a layout like this in depth, it'd be interesting to take OpenGL
profiles into account too.



However, we most certainly want to avoid duplication on the GL package
since that package contains high-level abstractions that aren't
automatically generated.



I don't think adding them to the spec file is worth the trouble.
Writing the CFFI definitions by hand is probably much simpler. I
suggest you create a cl-opengl-es-1.1 system, make it depend on
cl-opengl and add the egl functions to a new EGL package.

We can then tackle the cl-opengl-base issue if it's worth the trouble.

Cheers,