gl4java-usergroup

[gl4java-usergroup] error : swap does not get the window

[Enrique D. <enr...@ya...>]

Hi,
 
Well I wrote an app with gl4java using GAnimCanvas and sometimes I get "swap does not get the window" in the msdos window and my app can't run any more
 
I looked at the sources of gl4java and I found that it means that the handle to the window is lost
 
So how can I fix it ?
 
Thx !




---------------------------------
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.

[gl4java-usergroup] error : swap does not get the window

[Enrique D. <enr...@ya...>]

Hi,
 
Well I wrote an app with gl4java using GAnimCanvas and sometimes I get "swap does not get the window" in the msdos window and my app can't run any more
 
I looked at the sources of gl4java and I found that it means that the handle to the window is lost
 
So how can I fix it ?
 
Thx !



---------------------------------
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.

[gl4java-usergroup] error : swap does not get the window

[Enrique D. <enr...@ya...>]

Hi,
 
Well I wrote an app with gl4java using GAnimCanvas and sometimes I get "swap does not get the window" in the msdos window and my app can't run any more
 
I looked at the sources of gl4java and I found that it means that the handle to the window is lost
 
So how can I fix it ?
 
Thx !


---------------------------------
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.

Re: [gl4java-usergroup] OpenMind 0.7.2 released

[kaffiene <kaf...@xt...>]

Openmind looks really great, Alban.

I think I'll evaluate using it rather than my own (currently small) 
codebase.

Nice work. :)

Peter.

>Dear GL4Java users,
>
>Today, we are proud to bring a new release of the OpenMind scenegraph
>for GL4Java featuring first MacOSX support. This new release also brings
>better compatibility with old graphic adapters, and above all features
>the first release of AL4Java, a Java binding to the OpenAL
>cross-platform 3D sound library that was brought by Pepijn Van
>Eeckhoudt. 
>
>As usual, OpenMind can be downloaded from http://www.mind2machine.com
>
>AL4Java official website can be found at http://al4java.sourceforge.net/
>
>Enjoy !
>
>Alban Cousinié
>MIND2MACHINE
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: ObjectStore.
>If flattening out C++ or Java code to make your application fit in a
>relational database is painful, don't do it! Check out ObjectStore.
>Now part of Progress Software. http://www.objectstore.net/sourceforge
>_______________________________________________
>gl4java-usergroup mailing list
>gl4...@li...
>https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup
>
>  
>

[gl4java-usergroup] OpenMind 0.7.2 released

[<aco...@mi...>]

Dear GL4Java users,

Today, we are proud to bring a new release of the OpenMind scenegraph
for GL4Java featuring first MacOSX support. This new release also brings
better compatibility with old graphic adapters, and above all features
the first release of AL4Java, a Java binding to the OpenAL
cross-platform 3D sound library that was brought by Pepijn Van
Eeckhoudt.=20

As usual, OpenMind can be downloaded from http://www.mind2machine.com

AL4Java official website can be found at http://al4java.sourceforge.net/

Enjoy !

Alban Cousini=E9
MIND2MACHINE

[gl4java-usergroup] New developers added on Sourceforge

[<aco...@mi...>]

Hi everybody,

It took time, but Sven finally gave me admin rights on GL4Java
sourceforge project, so we should be able to advance on GL4java 3.0
development.

I have added pepijnve, kaffiene and azidhouse as sourceforge developers.
Pepijnve, being the base developer of the new release has extended
rights, like authority to publish new release or to admin trakers and
forums. All Developers have authority to update the CVS.

I couldn't find other developer names in my emails (I receive something
like 15 emails a day), so if you believe you should be added as a
developer and I forgot you, just send me an email with your developer
name.

Long live to GL4Java !

Alban Cousini=E9=20
MIND2MACHINE
http://www.mind2machine.com

[gl4java-usergroup] bitmap fonts in gl4java for os x

[Daniel B. <db...@if...>]

Hi all,

I'm currently struggling to get the NeHe Tutorials to work that deal 
with fonts: lesson 13 and 14. The gl4java versions of these tutorials 
keep producing Bus errors on my machine (os x 10.2.6, java 1.3.1). I 
tracked down the cash point to the function call glut = new 
GLUTFuncLightImplWithFonts(gl, glu); Has anybody an idea how to get 
these tutorials to work on os x?

Thanks a lot and best regards

      Daniel

[gl4java-usergroup] CVS - GL4Java2

[kaffiene <kaf...@xt...>]

Hi

There doesn't seem to be anonymous CVS access to the GL4Java2 module.  I 
was wanting to start working on the new code base but I can't get at it 
;-)  Could someone either add me as a developer or enable anonymous CVS?

Cheers,

Peter.

[gl4java-usergroup] Meeting ? ? ?

[Tobias L. G. <tg...@ul...>]

Is there a meeting today guys ? ? ?

I'm on the gl4java channel now 12 PM  GMT-6 . . .

Please join whenever you can . . .

                              -TOBY

[gl4java-usergroup] gluUnProject

[Sara T. <st...@st...>]

I'm having trouble getting gluUnProject to work using gl4java. I can't
seem to find any gl4java examples online that use gluUnProject. Can
someone please recommend a source I can use? I've already gone through the
example in the OpenGL Programming Guide, Ch 3: Viewing pp 152 but not much
luck getting it to work using gl4java libraries. Thanks!

Sara

Re: [gl4java-usergroup] Re: OpenGL extensions : the solution

[Pepijn V. E. <pep...@lu...>]

Alban Cousinié wrote:
> According to the article on Java 1.5 features
> http://java.sun.com/features/2003/05/bloch_qa.html
> We should be able to call OpenGL commands without prefix in Java 1.5 !!!

Should the opengl methods all be static as well? They're not in the 
current version of GL4Java either, so moving to java 1.5 with the 
current version would only remove the GLEnum and GLUEnum prefixes.
It is feasible to make all the opengl methods static, but personally I 
would prefer the oop approach. I don't really mind the prefixes.
Maybe we can discuss this further or vote on it tomorrow (if there is a 
meeting tomorrow)...

Pepijn

> 
> Static import - Lets you avoid qualifying static members with class
> names, without the shortcomings of the Constant Interface antipattern
> (Effective Java, Item 17).
> 
> Alban
> 
> 
> 
> 
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
> 
> _______________________________________________
> gl4java-usergroup mailing list
> gl4...@li...
> https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup
> 

[gl4java-usergroup] Re: OpenGL extensions : the solution

[<aco...@mi...>]

According to the article on Java 1.5 features
http://java.sun.com/features/2003/05/bloch_qa.html
We should be able to call OpenGL commands without prefix in Java 1.5 !!!

Static import - Lets you avoid qualifying static members with class
names, without the shortcomings of the Constant Interface antipattern
(Effective Java, Item 17).

Alban

Re: RE : [gl4java-usergroup] OpenGL Extensions

[Max G. <gi...@ye...>]

Pepijn Van Eeckhoudt wrote:

> Hmm I hadn't thought about the prefix stuff yet. Good point.
> You could call your object 'gl' which gives you gl.ProgramEnv... :) 

Personally I like methods to be called in traditional way: glSomething. 
I don't mind two extra letters before.

My 2c,
Max

Re: [gl4java-usergroup] RE :OpenGL Extensions

[Pepijn V. E. <pep...@lu...>]

Alban Cousinié wrote:
> 
> 
> 
> If you have 3 extensions, you can't instantiate the 3 classes under the
> same name "gl" if this what you mean. So it remains a problem.

No of course not. It wasn't really a serious suggestion ;)

Pepijn

[gl4java-usergroup] RE :OpenGL Extensions

[<aco...@mi...>]

>Hmm I hadn't thought about the prefix stuff yet. Good point.
>You could call your object 'gl' which gives you gl.ProgramEnv... :)
>The only way I know to dynamically get all these methods into one
object
>is to use Proxy, but I don't think this would be very efficient.
>So, so far we have:
>+ Small memory saving
>+ No noop methods
>+ Flexible extensibility
>- Prefixes before methods


If you have 3 extensions, you can't instantiate the 3 classes under the
same name "gl" if this what you mean. So it remains a problem.


Alban Cousini=E9 wrote:
> Hi Pepijn,
>=20
> This mechanism is interesting as it is allowing to save memory while
> avaoiding loading the extensions not needed. The only thing that
annoys
> me is the fact that we would have to prefix every call to a
> vertexProgram function by the variable name "vertProg.", so in your
> sample, we'd have code like :
> vertProg.ProgramEnvParameter4dvARB(args);
> On the other hand, the memory saved (a few Kilobytes) is not very
> interesting on personal computer context. On a PDA or a global phone,
> the gain would be much more interesting.
>=20
> If we are using, say, 8 different extensions, we'd have to keep in
mind
> every prefix, which is not easing the programming task. The current
> mechanism is more ergonomic because you always prefix your function
> calls by "gl" and nothing else, thus you don't have to remember these
> extensions class names.
>=20
> Ideally, removing any prefix would be the best solution as it would
> allow easier porting from c++ OpenGL code (that has no prefix) to
> gl4java code, but I don't think this is possible with Java, as a class
> cannot be declared static (except if it is an inner class : see
article
> http://www.javaworld.com/javaworld/javaqa/1999-08/01-qa-static2.html)
>=20
> Anyone have any idea if this could possibly be achieved?
>=20
> Alban

Re: RE : [gl4java-usergroup] OpenGL Extensions

[Pepijn V. E. <pep...@lu...>]

Hmm I hadn't thought about the prefix stuff yet. Good point.
You could call your object 'gl' which gives you gl.ProgramEnv... :)
The only way I know to dynamically get all these methods into one object
is to use Proxy, but I don't think this would be very efficient.
So, so far we have:
+ Small memory saving
+ No noop methods
+ Flexible extensibility
- Prefixes before methods

Pepijn

Alban Cousinié wrote:
> Hi Pepijn,
> 
> This mechanism is interesting as it is allowing to save memory while
> avaoiding loading the extensions not needed. The only thing that annoys
> me is the fact that we would have to prefix every call to a
> vertexProgram function by the variable name "vertProg.", so in your
> sample, we'd have code like :
> vertProg.ProgramEnvParameter4dvARB(args);
> On the other hand, the memory saved (a few Kilobytes) is not very
> interesting on personal computer context. On a PDA or a global phone,
> the gain would be much more interesting.
> 
> If we are using, say, 8 different extensions, we'd have to keep in mind
> every prefix, which is not easing the programming task. The current
> mechanism is more ergonomic because you always prefix your function
> calls by "gl" and nothing else, thus you don't have to remember these
> extensions class names.
> 
> Ideally, removing any prefix would be the best solution as it would
> allow easier porting from c++ OpenGL code (that has no prefix) to
> gl4java code, but I don't think this is possible with Java, as a class
> cannot be declared static (except if it is an inner class : see article
> http://www.javaworld.com/javaworld/javaqa/1999-08/01-qa-static2.html)
> 
> Anyone have any idea if this could possibly be achieved?
> 
> Alban
> 
> 
> -----Message d'origine-----
> De : gl4...@li...
> [mailto:gl4...@li...] De la part de
> Pepijn Van Eeckhoudt
> Envoyé : dimanche 11 mai 2003 12:10
> À : gl4...@li...
> Objet : [gl4java-usergroup] OpenGL Extensions
> 
> I've been trying to come up with a clean mechanism to handle extensions 
> in OpenGL. The current solution is to throw all methods and tokens 
> (core OpenGL and extensions) into one big class. This leaves you with a 
> class that has many methods that simply do nothing. I'm hoping we can 
> do better than this.
> The best solution I've been able to come up with is the following:
> - We keep the GLFunc class but it only contains the core OpenGL 
> functions and tokens
> - For each extension we provide a class that contais the necessary 
> methods and tokens. This extension class can then be loaded if a user 
> needs it. I've made a dummy example for the vertex program extension 
> (not 100% correct, but it's a good illustration.
> If this is the way to go it might be a good idea to do the same loading 
> type mechanism for the core functions as well, for consistency's sake. 
> You're application would then be responsible for creating an instance 
> of GL, GLU, and any other extension objects and maintaining them. This 
> would have to be done in the init method, because the GLContext object 
> must already have been created.
> 
> Example:
> private GL gl;
> private GLU glu;
> private ARBVertexProgram vertProg;
> 
> public void init(GLDrawable gld) {
> 	GLContext context = gld.getContext();
> 	gl = GL.createNewInstance(context);
> 	glu = GLU.createNewInstance(context);
> 	vertProg = ARBVertexProgram.loadExtension(context);
> }
> 
> I would love to here some other ideas and feedback about this.
> 
> Pepijn
> 
> P.S. Maybe we should move our development discussions to the devel 
> list...
> Alex: sorry I ended up playing Metroid Prime all night. Damn Nintendo :)
> 

Re: [gl4java-usergroup] OpenGL Extensions

[<jen...@ag...>]

Hi Pepijn, hi ng,

i'm followed your discussions about extending gl4java to the future since
i'm using gl4java now for more than a year.

The extension mechanism you've described should be the right way. Anyway
maybe it makes sense to not redefine
the init(...)-methods because as you know there is a difference in the
init()-methods coming from the subclassing model and the GLEventListener
model.
in GLCanvas: init() just without arguments
in GLEventListener: init(GLDrawable)

What you think about something like this:
preGLinit()    -- former preInit() in GLCanvas
postGLinit(GLContext)    -- for the extension instanciation you've described

GLCanvas.init()/GLEventListener.init(GLDrawable) left untouched for backward
compatibility

regards,
Jens


----- Original Message -----
From: "Pepijn Van Eeckhoudt" <pep...@lu...>
To: <gl4...@li...>
Sent: Sunday, May 11, 2003 12:09 PM
Subject: [gl4java-usergroup] OpenGL Extensions


> I've been trying to come up with a clean mechanism to handle extensions
> in OpenGL. The current solution is to throw all methods and tokens
> (core OpenGL and extensions) into one big class. This leaves you with a
> class that has many methods that simply do nothing. I'm hoping we can
> do better than this.
> The best solution I've been able to come up with is the following:
> - We keep the GLFunc class but it only contains the core OpenGL
> functions and tokens
> - For each extension we provide a class that contais the necessary
> methods and tokens. This extension class can then be loaded if a user
> needs it. I've made a dummy example for the vertex program extension
> (not 100% correct, but it's a good illustration.
> If this is the way to go it might be a good idea to do the same loading
> type mechanism for the core functions as well, for consistency's sake.
> You're application would then be responsible for creating an instance
> of GL, GLU, and any other extension objects and maintaining them. This
> would have to be done in the init method, because the GLContext object
> must already have been created.
>
> Example:
> private GL gl;
> private GLU glu;
> private ARBVertexProgram vertProg;
>
> public void init(GLDrawable gld) {
> GLContext context = gld.getContext();
> gl = GL.createNewInstance(context);
> glu = GLU.createNewInstance(context);
> vertProg = ARBVertexProgram.loadExtension(context);
> }
>
> I would love to here some other ideas and feedback about this.
>
> Pepijn
>
> P.S. Maybe we should move our development discussions to the devel
> list...
> Alex: sorry I ended up playing Metroid Prime all night. Damn Nintendo :)
>

[gl4java-usergroup] OpenGL Extensions

[Pepijn V. E. <pep...@lu...>]

I've been trying to come up with a clean mechanism to handle extensions 
in OpenGL. The current solution is to throw all methods and tokens 
(core OpenGL and extensions) into one big class. This leaves you with a 
class that has many methods that simply do nothing. I'm hoping we can 
do better than this.
The best solution I've been able to come up with is the following:
- We keep the GLFunc class but it only contains the core OpenGL 
functions and tokens
- For each extension we provide a class that contais the necessary 
methods and tokens. This extension class can then be loaded if a user 
needs it. I've made a dummy example for the vertex program extension 
(not 100% correct, but it's a good illustration.
If this is the way to go it might be a good idea to do the same loading 
type mechanism for the core functions as well, for consistency's sake. 
You're application would then be responsible for creating an instance 
of GL, GLU, and any other extension objects and maintaining them. This 
would have to be done in the init method, because the GLContext object 
must already have been created.

Example:
private GL gl;
private GLU glu;
private ARBVertexProgram vertProg;

public void init(GLDrawable gld) {
	GLContext context = gld.getContext();
	gl = GL.createNewInstance(context);
	glu = GLU.createNewInstance(context);
	vertProg = ARBVertexProgram.loadExtension(context);
}

I would love to here some other ideas and feedback about this.

Pepijn

P.S. Maybe we should move our development discussions to the devel 
list...
Alex: sorry I ended up playing Metroid Prime all night. Damn Nintendo :)

[gl4java-usergroup] gl4java on Mac OS X

[Scott V. <vo...@cs...>]

Hello, all,

I'm delighted to see new life in gl4java.  I've been lurking on the list for nearly a year now, since adopting gl4java as my only hope for getting Java3d on Mac OS X.

I have built a fairly useable application on top of the somewhat cobbled together combination of gl4java and Gerard Ziemski's last version of JFree-D.  There are *many* j3d functions I cannot use, but, happily, the basic polyhedron rendering seems to work well.  If you want to see ZomeWorks, feel free to grab a copy, for either Mac OSX (using gl4java) or Windows (NOT using it), from:

http://www.vorthmann.org/zome/

(I am self-hosting (some would say self-serving), so the link will usually cease to function between midnight and 8AM Eastern US, roughly.)

Early on, I did attempt to understand the gl4java build process, and even make changes, but I don't recall having any success.  I think the version that I distribute with ZomeWorks is the original OS X version that I downloaded, not one that I built.

I've had slightly more success modifying JFree-D, but only slightly... getting it to happily ignore some gl4java issues, IIRC.  If you run ZomeWorks on Mac OS X, you'll see lots of seemingly harmless messages to the console:

Canvas3d.render(): unsatisfied link error: lockJAWT
Canvas3D.display(): render() returned false

When things started to work, I stopped messing with either gl4java or JFree-D.  At this point I'm afraid to touch either.  I'm unable to create more than once canvas, canvases that are not square, and canvases larger than 600x600.

So I hope you can see why I'm happy to see gl4java getting some TLC... I can hope that some of my problems / limitations are in gl4java (rather than JFree-D), and may get fixed as a result of your efforts.  At the very least, I can hope that your planned build simplifications will let me work with gl4java in a more informed, even involved, fashion.

I'm happy to offer my assistance in whatever capacity I can manage, certainly testing builds on Mac OS X.  I have no knowledge of OpenGL, and no deep experience with doing 3D graphics, so I probably cannot be much help with the real work.  For starters, I can probably closely approximate a gl4java novice, to help determine if your simplified project and build process are more approachable.

So, having made all my ulterior motives overt, is there anything I can do?

Scott

Re: [gl4java-usergroup] Wednesday meeting

[Pepijn V. E. <pep...@lu...>]

Yes we had a little meeting. With a bit of luck my irc proxy will have 
logged everything. I'll check tonight.

Pepijn

Alban Cousinié wrote:
> Hi all,
> 
> Sorry I couldn’t manage to be present at the Wednesday IRC meeting. 
> I was on a MacOSX computer which isn’t my regular PC and faced some
> issues while attempting to connect to the IRC network (servers wouldn’t
> be found).
> This may have been a problem with the firewall, and I couldn’t manage to
> solve it in the given time since I connected too late.
> 
> Anyway, has there been a meeting ? Has anyone created a log of it ? 
> If so, could you send it to me so I set up a web page for the chat
> transcript ?
> 
> Regards,
> 
> Alban
> 
> 
> 
> 
> 
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
> 
> _______________________________________________
> gl4java-usergroup mailing list
> gl4...@li...
> https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup
> 

[gl4java-usergroup] Sourceforge developer names

[<aco...@mi...>]

Hi have just posted a mail to Sven so he registers Kaffiene and pepijnve
as gl4java developers.
I was waiting for the other=92s names to send the mail, but haven=92t
received any.=20
So if you want to be registered, tell me.=20

Alban

MIND2MACHINE
http://www.mind2machine.com

[gl4java-usergroup] Wednesday meeting

[<aco...@mi...>]

Hi all,

Sorry I couldn=92t manage to be present at the Wednesday IRC meeting.=20
I was on a MacOSX computer which isn=92t my regular PC and faced some
issues while attempting to connect to the IRC network (servers =
wouldn=92t
be found).
This may have been a problem with the firewall, and I couldn=92t manage =
to
solve it in the given time since I connected too late.

Anyway, has there been a meeting ? Has anyone created a log of it ?=20
If so, could you send it to me so I set up a web page for the chat
transcript ?

Regards,

Alban

Re: [gl4java-usergroup] Re : The new project...

[kaffiene <kaf...@xt...>]

Pepijn Van Eeckhoudt wrote:

> A meeting is fine for me. Same time as last week?
>
> Pepijn
>

I'll be there, but can we please not start the meeting early as happened 
last week, otherwise there's no point me getting up early for it.

Cheers

Peter.

Re: [gl4java-usergroup] Re : The new project...

[Pepijn V. E. <pep...@lu...>]

A meeting is fine for me. Same time as last week?

Pepijn

On dinsdag, mei 6, 2003, at 21:31 Europe/Brussels, Tobias L. George 
wrote:

> Are we having another meeting tomorrow, or should I deliver the new 
> build environment to Pepijn offline ? ? ?
>
> Or both ? ? ?
>
>                                                                -TOBY
>
> Kevin Nardi wrote:
>
>> I disagree.  I don't want to have to use your (or any specific) 
>> engine just
>> to get some useful utility functions for file loading.  Parsing a 3D 
>> Studio
>> file is difficult on your own, and if someone could write a method to 
>> parse
>> it and stick it in a wrapper class (like 3DStudioFileWrapper) with 
>> get()
>> methods for all the important data, that would be a HUGE help.  That 
>> doesn't
>> have anything to do with storing polygons, etc.  It just exposes the 
>> file's
>> important information for reading in a much more object-oriented 
>> fashion.
>> This of course could be done with many major file formats.
>>
>> Thoughts?
>>
>> -nano
>>
>> ----- Original Message -----
>> From: <aco...@mi...>
>> To: <gl4...@li...>
>> Sent: Friday, May 02, 2003 5:08 AM
>> Subject: [gl4java-usergroup] Re : Then new project...
>>
>>
>>
>>> Things I would like to see also.
>>>
>>> 1) parsers for many standard 3d file formats.  Maybe JavaCC or one of
>>>
>> the
>>
>>> other java based lex/yacc's
>>>
>>
>> My opinion is that it is not the role of an OpenGL Binding to handle
>> file loading, because it requires to set up specific data structures 
>> to
>> handle the storage of polygons, to manage matrix transformations of
>> objects, textures and cameras (I assume if you want to load an object,
>> you also want to rotate around and examinate it) : this the purpose 
>> of a
>> 3D engine and it goes beyond the scope of gl4java.
>>
>> This is why I have started the OpenMind project : it is a 3D engine on
>> top of gl4java. It actually features most of the functionalities you 
>> are
>> looking for and the code is also open source. It currently loads 
>> 3dsMAX
>> ASE files, and soon parsers will be developed to handle .md3, .3ds and
>> .obj files. We always need open source developers I want to code a
>> parser :)
>>
>> So if you want to give it a look : http://www.mind2machine.com
>>
>> Regards,
>>
>> Alban
>>
>>
>>
>>
>> -------------------------------------------------------
>> This sf.net email is sponsored by:ThinkGeek
>> Welcome to geek heaven.
>> http://thinkgeek.com/sf
>> _______________________________________________
>> gl4java-usergroup mailing list
>> gl4...@li...
>> https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup
>>
>>
>>
>> -------------------------------------------------------
>> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
>> The only event dedicated to issues related to Linux enterprise 
>> solutions
>> www.enterpriselinuxforum.com
>>
>> _______________________________________________
>> gl4java-usergroup mailing list
>> gl4...@li...
>> https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup
>>
>>
>>
>
>
>
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise 
> solutions
> www.enterpriselinuxforum.com
>
> _______________________________________________
> gl4java-usergroup mailing list
> gl4...@li...
> https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup
>

[gl4java-usergroup] Re : The new project...

[Tobias L. G. <tg...@ul...>]

Are we having another meeting tomorrow, or should I deliver the new 
build environment to Pepijn offline ? ? ?

Or both ? ? ?

                                                                -TOBY

Kevin Nardi wrote:

>I disagree.  I don't want to have to use your (or any specific) engine just
>to get some useful utility functions for file loading.  Parsing a 3D Studio
>file is difficult on your own, and if someone could write a method to parse
>it and stick it in a wrapper class (like 3DStudioFileWrapper) with get()
>methods for all the important data, that would be a HUGE help.  That doesn't
>have anything to do with storing polygons, etc.  It just exposes the file's
>important information for reading in a much more object-oriented fashion.
>This of course could be done with many major file formats.
>
>Thoughts?
>
>-nano
>
>----- Original Message -----
>From: <aco...@mi...>
>To: <gl4...@li...>
>Sent: Friday, May 02, 2003 5:08 AM
>Subject: [gl4java-usergroup] Re : Then new project...
>
>
>  
>
>>Things I would like to see also.
>>
>>1) parsers for many standard 3d file formats.  Maybe JavaCC or one of
>>    
>>
>the
>  
>
>>other java based lex/yacc's
>>    
>>
>
>My opinion is that it is not the role of an OpenGL Binding to handle
>file loading, because it requires to set up specific data structures to
>handle the storage of polygons, to manage matrix transformations of
>objects, textures and cameras (I assume if you want to load an object,
>you also want to rotate around and examinate it) : this the purpose of a
>3D engine and it goes beyond the scope of gl4java.
>
>This is why I have started the OpenMind project : it is a 3D engine on
>top of gl4java. It actually features most of the functionalities you are
>looking for and the code is also open source. It currently loads 3dsMAX
>ASE files, and soon parsers will be developed to handle .md3, .3ds and
>.obj files. We always need open source developers I want to code a
>parser :)
>
>So if you want to give it a look : http://www.mind2machine.com
>
>Regards,
>
>Alban
>
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>gl4java-usergroup mailing list
>gl4...@li...
>https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup
>
>
>
>-------------------------------------------------------
>Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
>The only event dedicated to issues related to Linux enterprise solutions
>www.enterpriselinuxforum.com
>
>_______________________________________________
>gl4java-usergroup mailing list
>gl4...@li...
>https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup
>
>
>  
>