headers
ronni montoya | 28 Nov 04:13
Picon
Gravatar

save 3d scene as .obj file

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,
Permalink | Reply | 0 comments |
headers
ronni montoya | 24 Sep 13:03
Picon
Gravatar

mouse-driven camera

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
Permalink | Reply | 1 comment |
headers
Simon Ortiz | 25 Jun 11:55
Picon

CL-OpenGL ES?

dear cl-opengl people,

I'm working on a project to make games on Android and iPhone using
Lisp. Thanks to the work of R. Krishnan and S. Ageneau ECL runs on
these devices.

I'm taking it from there and I'm trying to draw to the screen from
Lisp. So far, I've achieved modest results using my own (very small
and rudimentary) OpenGL ES 1.1 interface, which uses ECL's low-level
FFI facility.

But I think that it would be a waste to come up with another OpenGL
interface. I'm thinking, why not better use cl-opengl?

So, I would like to ask you some questions:

- what versions of OpenGL does cl-opengl support?

- say I want to contribute to the project and adapt cl-opengl into
cl-opengl-es11 (and in the far future cl-opengl-es20), how should I do
it? From where can I take it? Is there a similar project I can join?
Is anyone interested in joining efforts?

Thank you very much in advance for your advice.

Sincerely,

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

Permalink | Reply | 15 comments |
headers
Luke Crook | 9 Apr 23:48
Gravatar

Re: cl-opengl-devel Digest, Vol 50, Issue 2

{Apologies to the group for top-posting}

It looks like a substantial application. It was built using Common
Lisp and OpenGL. Now you know it can be done. Isn't that sufficient?

-Luke

On Apr 9, 2011, at 9:00, "cl-opengl-devel-request <at> common-lisp.net"
<cl-opengl-devel-request <at> common-lisp.net> wrote:

> Send cl-opengl-devel mailing list submissions to
>    cl-opengl-devel <at> common-lisp.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>    http://common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel
> or, via email, send a message with subject or body 'help' to
>    cl-opengl-devel-request <at> common-lisp.net
>
> You can reach the person managing the list at
>    cl-opengl-devel-owner <at> common-lisp.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cl-opengl-devel digest..."
> Today's Topics:
>
>   1. Re: a substantial Windows app (Brandon Van Every)
> On Thu, Apr 7, 2011 at 7:21 PM, Luís Oliveira <luismbo <at> gmail.com> wrote:
>>
>> The most substantial app I'm aware of is Perfectstorm:
>> <http://erleuchtet.org/2008/03/project-overview-perfectstorm.html>.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brandon Van Every | 7 Apr 18:53
Picon

a substantial Windows app

Hi, I'm pretty new to Common Lisp, Clozure CL, Quicklisp, and
cl-opengl.  I'm looking for a substantial open source app that uses
cl-opengl and builds on Windows.  By "substantial" I mean more than a
very basic game or tutorial or demo.  Something that really puts
cl-opengl to work, preferably with relatively modern OpenGL API
functionality, such as vertex arrays and shaders and not glBegin glEnd
semantics.  Like, a First Person Shooter would be substantial, or a
medical visualization would be substantial.  The purpose is to
understand how the substantial app is built, how robust or buggy the
app is on this platform, and to evaluate the OpenGL performance of the
app.

Is there some easy way in Quicklisp to find all the packages that use
cl-opengl?  (ql:system-apropos "cl-opengl") only lists cl-opengl
itself.  I've been Googling about cl-opengl but that method is proving
to be slow.

"Builds on Windows" is important because sometimes packages want
things that don't readily exist on Windows.  For instance,
until-it-dies makes use of FTGL, an obsolete library that hasn't been
worked on since 2008.  It doesn't have any Windows binaries for the
foreign .dlls.  Although I could go through the pain of modernizing an
old VC8 .sln file, and renaming dependencies to FreeType per some
other website I read, it's just not worth it to me.  I want to look at
a substantial app under active development that actually works on
Windows.

Generally I can handle foreign .dll dependencies as long as those
foreign .dlls are under active development.  I've been shoving various
"SDKs" into C:\Program Files\ and adding their .dll directories to my
(Continue reading)

Permalink | Reply | 3 comments |
headers
Mason Smith | 16 Feb 09:39
Picon

Bug in MAKE-NULL-GL-ARRAY

The current make-null-gl-array fails to run as currently defined. When called with (gl:make-null-gl-array :unsigned-short), SBCL gives the following error:


0 fell through CTYPECASE expression.
Wanted one of (SYMBOL FUNCTION).
   [Condition of type SB-KERNEL:CASE-FAILURE]

The problem seems simply to be that the arguments when calling MAKE-GL-ARRAY-FROM-POINTER are reversed.

Specifically, instead of 

(make-gl-array-from-pointer (null-pointer) 0 type)

the body of MAKE-NULL-GL-ARRAY should be

(make-gl-array-from-pointer (null-pointer) type 0)


Mason

_______________________________________________
cl-opengl-devel mailing list
cl-opengl-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel
Permalink | Reply | 0 comments |
headers
Greg Bennett | 29 Jan 18:23
Picon
Gravatar

Invoking cl-opengl under ubuntu

Good afternoon from Greg Bennett
I an venturing into graphics in cl undet linix.
Specifically I am running ccl 64-bit under Ubuntu 10.04 using emacs+slime as
an interface; but my lisp experience is from Allegro under Windows. Perhaps
it is not surprising that I am (slightly) baffled by some of the set-up activities.

I  downloaded cl-opengl and read the .asd files for it, and for glu, glut, glut-examples too.
I saw that all depended on cffi, so I used Ubuntu's apt-get install to do just that - fetch and
install cffi - which went smoothly. It took me a while to find out where it was located (!)
so I could fix up asdf:*central-registry* with a path to cffi.asd

[Off-topic: is there an easy way to find where packages are installed ? The poking about
I have done has yielded noting useful. Should I have 'known' cl-cffi would wind up in
/usr/share/common-lisp/systems ?]

Having twiddled the registry, I used (asdf:operate 'asdf:load-op 'cffi) which started cheerfully
but then stopped with an simple-file error. For all the .lisp files in, for example,
 /usr/share/common-lisp/systems/source/alexandria
are owned by root. It was in trying to process alexandria.lisp that things halted.

I am the sole user of the linux box, but it seems that I need a way to tell ccl that it should run
as root.

If I am to build cl-opengl I have to get past this block, so I hope that someone can provide a magic
incantation or two.

Thanks for all assistance and advice
Cheers /Greg Bennett
_______________________________________________
cl-opengl-devel mailing list
cl-opengl-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel
Permalink | Reply | 1 comment |
headers
Brian Taylor | 1 Nov 17:13
Picon
Gravatar
Subject: thanks from a happy developer!

thanks from a happy developer!

Greetings all!


I just wanted to say thank you for all your work making cl-opengl such a fantastic bridge between cl and opengl. I'm constantly delighted to see how lispy it feels to use this library and how easy it is to be productive while referring to opengl documentation geared towards other languages. This is a really nice library to work with.

-wubo
_______________________________________________
cl-opengl-devel mailing list
cl-opengl-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel
Permalink | Reply | 0 comments |
headers
Nikodemus Siivola | 28 Oct 13:58
Gravatar

Using idle events to drive Slime

I define

(defmethod glut:idle ((window glut:window))
  (swank::process-requests t))

to keep Slime responsive while the event-loop runs (when running
single-threaded)  -- which is nice enough, but a tad inelegant not
just because of the double-colon, but because it causes __every__
window to call PROCESS-REQUESTS.

I'm wondering if there should be a single global *IDLE-HOOK* (or maybe
REGISTER-IDLE-HOOK) in addition to the per-window method approach --
something which causes windows to automatically subscribe to Idle
events without registering themselves in *WINDOWS-WITH-IDLE-EVENTS*.

Cheers,

 -- Nikodemus
Permalink | Reply | 1 comment |
headers
Luís Oliveira | 22 Oct 16:31

Fwd: CL-OPENGL has conflicts with Alexandria

--
Luís Oliveira
http://r42.eu/~luis

---------- Forwarded message ----------
From: "Nikodemus Siivola" <nikodemus <at> random-state.net>
Date: 14 Oct 2010 06:32
Subject: CL-OPENGL has conflicts with Alexandria
To: "Oliver Markovic" <entrox <at> entrox.org>, "Luis Oliveira" <loliveira <at> common-lisp.net>

I just added

 #+sbcl
 (:lock t)

to Alexandria's package definition. Turns out CL-OPENGL has the
following conflicts:

 STARTS-WITH
 ONCE-ONLY
 ROTATE

Cheers,

 -- Nikodemus
_______________________________________________
cl-opengl-devel mailing list
cl-opengl-devel <at> common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cl-opengl-devel
Permalink | Reply | 0 comments |
headers
Tomislav Tomsic | 14 Oct 22:53
Picon

Hi to all :). Does anyone else have problems with ASDF2 and cl-opengl?

This being my first message here, greetings to you all :).
I've just updated my sbcl on version 1.0.48.58,, and cl-opengl doesn't
work. I am using it via clbuild on the Ubuntu 10.04 (64).

This is the error message:

  0: ((SB-PCL::FAST-METHOD ASDF:PERFORM (ASDF:COMPILE-OP
ASDF:CL-SOURCE-FILE)) ..)
  1: ((SB-PCL::EMF ASDF:PERFORM) #<unavailable argument> #<unavailable
argument> #<ASDF:COMPILE-OP NIL {10045D16F1}> #<ASDF:CL-SOURCE-FILE
"cl-opengl" "gl" "util">)
  2: ((SB-PCL::FAST-METHOD ASDF::PERFORM-WITH-RESTARTS
(ASDF:COMPILE-OP ASDF:CL-SOURCE-FILE)) ..) and so on.

As I am able to discern, thanks to the numerous tries with various
sbcl versions, yesterday and today, suddenly there is a problem with
the file/resource locking, during the compilation. According to the
sbcl documentation, that "feature" is in somewhat volatile state, and
is the responsibility of the client software.
To cut the story short, I think it is because of the new ASDF 2, that
sbcl is starting to ship with. As such, I trust it will be resolved,
sooner or later.

In the meantime, does anyone have an idea for a workaround?
Perhaps all that is needed is a slight change in the cl-opengl.asd,
but I have no idea which one. At this moment, I am both unfamiliar
with the newest asdf, as well as with the cl-opengl architecture.

Once again, greetings to you all :)

Respectfully
Tomislav Tomsic
Permalink | Reply | 0 comments |

Gmane