openvrml-develop — OpenVRML developers mailing list

[openvrml-develop] 64MB limit

[Damian M. <da...@er...>]

I have a large VRML file that I am trying to display with GTKLOOKAT.  It
core dumps before it seriously displays anything.  It reads the files OK.
However, I suspects some system setting as it dumps a core file of size

	67186688 Nov 25 15:40 core

This factors to 65536 * ( 65536 + 76 ) which is too close to 64MB and too
neat for my liking.  I am quite happy to send the ( 13MB uuencoded ) file
to somebody else if you want to try it.

On a Windows Box with Blaxxun, the model needs about 90MB.  I have also
tried this VRML file on at least one other PC VRML browser. This is a
multi-file model with lots of external images and was created using
Alias|Wavefront Maya 2.5.

On a Mandrake 7.2 LINUX machine with

$ limit
cputime         unlimited
filesize        unlimited
datasize        unlimited
stacksize       8MB
coredumpsize    97MB
memoryuse       unlimited
maxproc         2048
descriptors     1024
memorylocked    unlimited
addressspace    unlimited

The program dumps core where a 'where' in gdb with OpenVRML 0.11.2 and
GTKlookat 0.9.1 compiles with '-g',  shows up

	#0  0x405b6f7a in malloc () from /lib/libc.so.6
	#1  0x405b6d3e in malloc () from /lib/libc.so.6
	#2  0x404c4a78 in gluTessVertex () from /usr/X11R6/lib/libGLU.so.1

Any ideas.

Is it just some system setting?

Thanks - Damian (McGuckin)

Pacific Engineering Systems International, 22/8 Campbell St, Artarmon NSW 2064
Ph:+61-2-99063377 .. Fx:+61-2-99063468   | unsolicited email not wanted here !
Views and opinions here are mine and not those of any past or present employer

Re: [openvrml-develop] Re: OpenVRML EAI support?

[Thomas F. <tf...@us...>]

Hi Mike,

As of right now there is no EAI support in OpenVRML. There is an open 
task for adding the support though, 
http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=40667&group_id=7151&group_project_id=2579 
, but unfortunately no one has grabbed it yet :-(

Some time back (August-September 2000), SpizKapa was working on adding 
this to OpenVRML but that effort seems to have died. (Implementation 
discussions can be found on the old libvrml97 mailing list archived at 
http://groups.yahoo.com/group/libvrml97/ )

FreeWRL, another open source VRML browser found at 
http://freewrl.sourceforge.net , currently supports EAI if you're 
interested.

Later,
Tom

Christopher M Morley wrote:

>Mike, I'm not aware of any EAI support in openvrml.
>Perhaps some one on the developers list knows more.
>
>Chris
>
>----- Original Message ----- 
>From: "michael tsang" <mic...@ma...>
>To: <cm...@ve...>
>Sent: Tuesday, November 20, 2001 4:57 AM
>Subject: OpenVRML EAI support?
>
>
>>Hello!
>>I'm interested in researching using your OpenVRML software.
>>
>>I'm wondering if you have support for EAI yet in OpenVRML.
>>
>>Or if you have any other suggestions for an open browser that allows me to 'paint' geometry  into the scene with a mouse
>>
>>
>>Thanks muchly,
>>
>>Mike
>>-- 
>>

Re: [openvrml-develop] Using OpenVRML

[Thomas F. <tf...@us...>]

Hi Sashidhar,

See comments inline.

Sashidhar Dandamudi wrote:

>Hi all,
>	I am in the process of moving from Windows to Linux and thus am
>struggling to get a Linux compatible VRML viewer. I have managed to
>perform the operations as specified in the INSTALL file( ./configure,
>make, make install) . Everything seems to go just fine and I finally get
>the
>directory structure under /usr/local/vrml/. However at this point of time
>I am totally stumped as to how to begin running the application. I tried 
>typing lookat, .lookat etc at the promot to no avail. Will somebody tell
>me how to use it??
>
Have you been able to find the executable? If you installed into 
/usr/local/vrml, I'm guessing lookat can be found in 
/usr/local/vrml/bin. You should be able to start it by entering 
/usr/local/vrml/bin/lookat at the prompt or by adding 
/usr/local/vrml/bin to your PATH and typing lookat at the prompt...does 
this help at all? If not can you post some more details...

>
>	This apart I also have a few questions about the capabilities of
>OpenVRML, does it support PROTOS and EXTERNPROTOS? And can I manipluate
>the scene graph using EAI??
>
OpenVRML supports PROTOs and EXTERNPROTOs pretty well for the most part 
but unfortunately EAI is not currently supported. SpizKapa's made a stab 
at adding this a while back but I'm not sure what became of the code...

Tom

[openvrml-develop] Re: OpenVRML EAI support?

[Christopher M M. <cm...@ve...>]

Mike, I'm not aware of any EAI support in openvrml.
Perhaps some one on the developers list knows more.

Chris

----- Original Message ----- 
From: "michael tsang" <mic...@ma...>
To: <cm...@ve...>
Sent: Tuesday, November 20, 2001 4:57 AM
Subject: OpenVRML EAI support?


> Hello!
> I'm interested in researching using your OpenVRML software.
> 
> I'm wondering if you have support for EAI yet in OpenVRML.
> 
> Or if you have any other suggestions for an open browser that allows me to 'paint' geometry  into the scene with a mouse
> 
> 
> Thanks muchly,
> 
> Mike
> -- 

[openvrml-develop] Using OpenVRML

[Sashidhar D. <sa...@is...>]

Hi all,
	I am in the process of moving from Windows to Linux and thus am
struggling to get a Linux compatible VRML viewer. I have managed to
perform the operations as specified in the INSTALL file( ./configure,
make, make install) . Everything seems to go just fine and I finally get
the
directory structure under /usr/local/vrml/. However at this point of time
I am totally stumped as to how to begin running the application. I tried 
typing lookat, .lookat etc at the promot to no avail. Will somebody tell
me how to use it??

	This apart I also have a few questions about the capabilities of
OpenVRML, does it support PROTOS and EXTERNPROTOS? And can I manipluate
the scene graph using EAI??


Thanks
Sashi



Sashidhar Dandamudi
Georgia Institute of Technology
School of Industrial and Systems Engineering
E-mail address:   sa...@is...

[openvrml-develop] Fw: OpenVRML now categorized as MacOS 9 on SourceForge.net

[Chris M. <cm...@ve...>]

----- Original Message -----
From: <joh...@so...>
To: <cm...@us...>
Sent: Thursday, November 15, 2001 7:52 PM
Subject: OpenVRML now categorized as MacOS 9 on SourceForge.net


>
> Dear SourceForge.net user,
>
> You are receiving this because you have a project in the MacOS trove
> category
> (http://sourceforge.net/softwaremap/trove_list.php?form_cat=221). This is
> to
> inform you that in order to facilitate better categorization, we will move
>
> your project to the MacOS 9 category, which is a subcategory of MacOS. If
> your project is actually specific to MacOS X, please change it to the
> MacOS X
> category in the trove map as soon as possible. If you are happy to have
> your
> project in the MacOS 9 category, then you need not do anything.
>
> We simply do not want any projects to categorize themselves generically as
>
> MacOS, since OS 9 and OS X are radically different from the developers'
> viewpoint.
>
> Thanks for your patience and cooperation.
>
> -John Mark Walker
> SourceForge.net
> joh...@sf...
>

[openvrml-develop] bounding boxes

[Dirk H. <dar...@gm...>]

Hi

I am working with openvrml and need to get the bounding boxes of an vrml
model. Is there any possibility to get this from a scene ?
Has anybody done this allready and give me some hints ?

Dirk Harms

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

Re: [openvrml-develop] MisLeading Message with Relative Path problems

[S.K.Bose <bo...@pa...>]

On Sat, 10 Nov 2001, Damian McGuckin wrote:

> On Fri, 9 Nov 2001, S.K.Bose wrote:
> 
> I tried win32Lookat.  I loaded the required-libraries file of DLLs but it
> still asks me for a GDi32.dll.
> 
Sorry for delay in reply. I was out of town for four days.
I use Microsoft Windows NT version 4.00 and Microsoft Visual
studio 6.0 for creating binary version of win32Lookat and also for
openvrml.dll.
In my system Gdi32.dll is in WINNT\system32

Thanks,

Bose 

Re: [openvrml-develop] MisLeading Message with Relative Path problems

[Damian M. <da...@er...>]

On Fri, 9 Nov 2001, S.K.Bose wrote:

> I spent time on win32Lookat development long back. Now I spend time only
> to see that it is compatible with current release of OpenVRML lib. not on
> further development on it. Now a days I am mainly busy with WIN32
> compatible issues related to  OpenVRML lib and further development of its
> graphics aspects.

I tried win32Lookat.  I loaded the required-libraries file of DLLs but it
still asks me for a GDi32.dll.

I have one on the system in the Windows directory but maybe it is the
wrong version.

While I would like to think I know a lot about Unix and Linux, by
comparison I am a windows novice.

Any ideas?

Thanks - Damian (McGuckin)

Pacific Engineering Systems International, 22/8 Campbell St, Artarmon NSW 2064
Ph:+61-2-99063377 .. Fx:+61-2-99063468   | unsolicited email not wanted here !
Views and opinions here are mine and not those of any past or present employer

Re: [openvrml-develop] MisLeading Message with Relative Path problems

[S.K.Bose <bo...@pa...>]

On Fri, 9 Nov 2001, Damian McGuckin wrote:

> 
> Same question, but win32lookat?
> 

I spent time on win32Lookat development long back. Now I spend time only
to see that it is compatible with current release of OpenVRML lib. not on
further development on it. Now a days I am mainly busy with WIN32 
compatible issues related to  OpenVRML lib and further development of its
graphics aspects.

Thanks,

S. K. Bose

Re: [openvrml-develop] MisLeading Message with Relative Path problems

[Damian M. <da...@er...>]

On 5 Nov 2001, Braden McDaniel wrote:

> > Does gtklookat get any development or is everybody Windows centric and
> > working only on win32lookat?
>
> I'm on Linux, but I don't spend time on gtklookat.

Who spends time on gtklookat?

Same question, but win32lookat?

I have a patch sort of working but I need to tidy it up and make it robust
relative to multiple operating systems.  I'm out of town for a week but
I'll sort it out when I get back.  If I sort out Windows and Unix, is
there somebody who knows Mac.

Thanks - Damian (McGuckin)

Pacific Engineering Systems International, 22/8 Campbell St, Artarmon NSW 2064
Ph:+61-2-99063377 .. Fx:+61-2-99063468   | unsolicited email not wanted here !
Views and opinions here are mine and not those of any past or present employer

Re: [openvrml-develop] MisLeading Message with Relative Path problems

[Damian M. <da...@er...>]

On 5 Nov 2001, Braden McDaniel wrote:

> > but relative to itself.  It failed.  I am misreading the VRML 2.0
> > standard or should the path for included files have been reset to
> > match the file that was actually pulling in these included files.
>
> I think we have an open bug on this. A patch would be welcome.

I'll fix today nor tomorrow.

> > By the way, the traffic seems to have slowed recently.
> >
> > I am using all this from 'gtklookat' although that appears irrelant.
> >
> > Does gtklookat get any development or is everybody Windows centric and
> > working only on win32lookat?
>
> I'm on Linux, but I don't spend time on gtklookat.

Who does?  I can spend some time on it.

Thanks - Damian (McGuckin)

Pacific Engineering Systems International, 22/8 Campbell St, Artarmon NSW 2064
Ph:+61-2-99063377 .. Fx:+61-2-99063468   | unsolicited email not wanted here !
Views and opinions here are mine and not those of any past or present employer

Re: [openvrml-develop] MisLeading Message with Relative Path problems

[Braden M. <br...@en...>]

On Mon, 2001-11-05 at 13:49, Damian McGuckin wrote:
> 
> How does one get read access to the CVS tree?

    <http://sourceforge.net/cvs/?group_id=7151>

> How does one suggest changes that actually make it?

    <http://sourceforge.net/docman/display_doc.php?docid=7254&group_id=7151>

>  E.g. I just tried to
> read a file from a relative directory that failed. The error messages I
> got was along the lines of
> 
> 	Couldn't read ImageTexture
> 
> which was strictly wrong.  It couldn't even OPEN the file, so it stood
> no hope of even READing it.  The code has enough hooks to distinguish
> the two problems.  This is inside Image.cpp called from vrml97node.cpp.
> 
> Anyay, the reason why the relative file open failed was in a MASTER
> directory, so
> 
> 	original VRML file	/home/vrml/new.wrl
> 
> This then wanted to do 'url model/fred.wrl', i.e.
> 
> 				/home/vrml/model/fred.wrl
> 
> It worked.
> 
> Now in the directory model, there existed a directory 'image', i.e.
> 
> 				/home/vrml/model/image
> 
> and fred.wrl wanted to do 'url image/2400.jpg', i.e open
> 
> 				/home/vrml/model/image/2400.jpg
> 
> but relative to itself.  It failed.  I am misreading the VRML 2.0
> standard or should the path for included files have been reset to
> match the file that was actually pulling in these included files.

I think we have an open bug on this. A patch would be welcome.

> By the way, the traffic seems to have slowed recently.
> 
> I am using all this from 'gtklookat' although that appears irrelant.
> 
> Does gtklookat get any development or is everybody Windows centric and
> working only on win32lookat?

I'm on Linux, but I don't spend time on gtklookat.

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>

[openvrml-develop] MisLeading Message with Relative Path problems

[Damian M. <da...@er...>]

How does one get read access to the CVS tree?

How does one suggest changes that actually make it?  E.g. I just tried to
read a file from a relative directory that failed. The error messages I
got was along the lines of

	Couldn't read ImageTexture

which was strictly wrong.  It couldn't even OPEN the file, so it stood
no hope of even READing it.  The code has enough hooks to distinguish
the two problems.  This is inside Image.cpp called from vrml97node.cpp.

Anyay, the reason why the relative file open failed was in a MASTER
directory, so

	original VRML file	/home/vrml/new.wrl

This then wanted to do 'url model/fred.wrl', i.e.

				/home/vrml/model/fred.wrl

It worked.

Now in the directory model, there existed a directory 'image', i.e.

				/home/vrml/model/image

and fred.wrl wanted to do 'url image/2400.jpg', i.e open

				/home/vrml/model/image/2400.jpg

but relative to itself.  It failed.  I am misreading the VRML 2.0
standard or should the path for included files have been reset to
match the file that was actually pulling in these included files.

By the way, the traffic seems to have slowed recently.

I am using all this from 'gtklookat' although that appears irrelant.

Does gtklookat get any development or is everybody Windows centric and
working only on win32lookat?

Thanks - Damian (McGuckin)

Pacific Engineering Systems International, 22/8 Campbell St, Artarmon NSW 2064
Ph:+61-2-99063377 .. Fx:+61-2-99063468   | unsolicited email not wanted here !
Views and opinions here are mine and not those of any past or present employer

Re: [openvrml-develop] OpenVRML on Darwin/MacOSX

[Oliver S. <oli...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 05 November 2001 09:40, Michael Louka wrote:
> On Monday, November 5, 2001, at 02:47 , Braden McDaniel wrote:
> > What prompts the dependency on the Objective C library?
>
> I'm not sure whether "Foundation" or objc are needed. I didn't need them
> to compile OpenVRML and Lookat under Mac OS X 10.0.4. I believe, that the
> compiler (a modified? gcc 2.95.2) includes the System framework
> transparently, which should handle any other "wierd" dependencies Mac OS X
> may have. I haven't tried with Mac OS X 10.1, though.

They were not needed with OS X 10.0.4, but are needed with the latest release 
10.1. (There are various postings on the Mac OpenGL list describing this 
problem => lists.apple.com)

> Frameworks are bundles of header files and libraries (and documentation).
> -framework is a bit like -l and -L rolled into one where the developer
> just needs to supply the name of the API/Framework. This means that -lgl
> and -lglut need to be replaced with -framwork GL and -framework GLUT on
> Mac OS X.

> Also, for some reason, Oliver has the OpenGL framework declared twice in
> the same line in his "Diff for macros/gl.m4".

No reason for that. It's a mistake.

- -- 
_____________________________________________________________________
 Oliver Strutynski                      oli...@cs...
                                                    oli...@gm...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE75lf2uUAlUEFqtKYRAqU7AJ9mttWBrL9N//eQ1RxWAX8FkjrDiACeIDLY
LMyhOjjCg/SMGJA507iP/yU=
=uXuW
-----END PGP SIGNATURE-----

Re: [openvrml-develop] OpenVRML on Darwin/MacOSX

[Michael L. <Mic...@hr...>]

On Monday, November 5, 2001, at 02:47 , Braden McDaniel wrote:

> On Sun, 2001-11-04 at 16:51, Oliver Strutynski wrote:
>> Anyway, I think it should be mostly clear from the patch what needs to be
>> added for OpenVRML to compile on MacOSX (the additional frameworks + 
>> modified
>> checks for glut/opengl). I hope this information proves useful for you.
>
> I can try adapting your changes, but I'd like to know a little bit more
> about them first...
>
> What prompts the dependency on the Objective C library?

I'm not sure whether "Foundation" or objc are needed. I didn't need them 
to compile OpenVRML and Lookat under Mac OS X 10.0.4. I believe, that the 
compiler (a modified? gcc 2.95.2) includes the System framework 
transparently, which should handle any other "wierd" dependencies Mac OS X 
may have. I haven't tried with Mac OS X 10.1, though. I guess this is 
something we need to test. OpenGL and GLUT are needed however. In fact, to 
link Lookat, only GLUT is needed, since declaring that you want to use 
GLUT "automatically" gives you OpenGL, since GLUT depends on OpenGL.

For example (under 10.0.4), this links Lookat to the static libraries from 
the command-line:

c++ -Wall -g -O2 -o lookat -framework GLUT lookat.o ViewerGlut.o 
../lib/libopenvrml-gl.a libopenvrml.a ../../jpeg-6b/libjpeg.a 
../../libpng-1.0.5/libpng.a  -lz

(of course, if I'd "installed" OpenVRML, JPEG, and PNG, then I could have 
just used -L/usr/local/lib and -llibopenvrml-gl, etc.).

If it makes modifying the build system easier, OpenGL and GLUT are 
standard installs under Mac OS X, so you could skip testing them under Mac 
OS X, and just replace -lglut with -framework GLUT and -lgl with 
-framework GL when compiling under Mac OS X.

> What exactly does the -framework compiler flag do?

Frameworks are bundles of header files and libraries (and documentation). 
-framework is a bit like -l and -L rolled into one where the developer 
just needs to supply the name of the API/Framework. This means that -lgl 
and -lglut need to be replaced with -framwork GL and -framework GLUT on 
Mac OS X.

Also, for some reason, Oliver has the OpenGL framework declared twice in 
the same line in his "Diff for macros/gl.m4".

I guess an interesting long-term goal for OpenVRML on Mac OS X, would be 
to package the Mac OS X distribution as a Framework.

Mike.

Re: [openvrml-develop] OpenVRML on Darwin/MacOSX

[Braden M. <br...@en...>]

On Sun, 2001-11-04 at 16:51, Oliver Strutynski wrote:
> Anyway, I think it should be mostly clear from the patch what needs to be 
> added for OpenVRML to compile on MacOSX (the additional frameworks + modified 
> checks for glut/opengl). I hope this information proves useful for you.

I can try adapting your changes, but I'd like to know a little bit more
about them first...

What prompts the dependency on the Objective C library?

What exactly does the -framework compiler flag do?

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>

Re: [openvrml-develop] OpenVRML on Darwin/MacOSX

[Oliver S. <oli...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 04 November 2001 22:34, Braden McDaniel wrote:
> On Sun, 2001-11-04 at 15:26, Oliver Strutynski wrote:
> > I had to add some small patches to OpenVRML 0.11.2 to make it compile and
> > link on Mac OSX 10.1. Here are the diffs
>
> I'm definitely interested in patches to get the GNU build working on Mac
> OS X, but the source files for configure have changed substantially in
> the main branch in CVS. Your patches are not applicable to the current
> version.
ok
...

> LDFLAGS, CFLAGS, ands CXXFLAGS are user variables which should not be
> set in configure.

I'm not an automake expert. Problem was that I needed to add some flags to 
all compiler runs so I decided to add these flags in configure in. Might not 
be a good idea, but I don't know how to do it any better.

> Also, I don't see anything in your patches that
> modifies the automake makefiles, so I'm not sure why you're using an
> automake conditional here.

I did not (need to) touch the .am files. That was just the first way I was 
able to get a conditional to work.

Anyway, I think it should be mostly clear from the patch what needs to be 
added for OpenVRML to compile on MacOSX (the additional frameworks + modified 
checks for glut/opengl). I hope this information proves useful for you.

Regards, Oliver


- -- 
_____________________________________________________________________
 Oliver Strutynski                      oli...@cs...
                                                    oli...@gm...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE75bhzuUAlUEFqtKYRAjXIAKCd8oEko4eqih681AZyEBSLJ1rBUACdFbpe
cuRZBogQa7szUl6nBvBr1i8=
=EvLu
-----END PGP SIGNATURE-----

Re: [openvrml-develop] OpenVRML on Darwin/MacOSX

[Braden M. <br...@en...>]

On Sun, 2001-11-04 at 15:26, Oliver Strutynski wrote:
> I had to add some small patches to OpenVRML 0.11.2 to make it compile and 
> link on Mac OSX 10.1. Here are the diffs

I'm definitely interested in patches to get the GNU build working on Mac
OS X, but the source files for configure have changed substantially in
the main branch in CVS. Your patches are not applicable to the current
version.

> Add to configure.in:
> 
> dnl
> dnl Some additional Darwin stuff
> dnl
> AM_CONDITIONAL(DARWIN, test "$host" = "powerpc-apple-darwin1.4")
> if test "DARWIN"; then
> LDFLAGS="${LDFLAGS} -lobjc -framework OpenGL -framework Foundation"
> CFLAGS="${CFLAGS} -lobjc -framework OpenGL -framework Foundation"
> CXXFLAGS="${CXXFLAGS} -lobjc -framework OpenGL -framework Foundation"
> fi

LDFLAGS, CFLAGS, ands CXXFLAGS are user variables which should not be
set in configure. Also, I don't see anything in your patches that
modifies the automake makefiles, so I'm not sure why you're using an
automake conditional here.

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>

[openvrml-develop] OpenVRML on Darwin/MacOSX

[Oliver S. <oli...@gm...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I had to add some small patches to OpenVRML 0.11.2 to make it compile and 
link on Mac OSX 10.1. Here are the diffs

Add to configure.in:

dnl
dnl Some additional Darwin stuff
dnl
AM_CONDITIONAL(DARWIN, test "$host" = "powerpc-apple-darwin1.4")
if test "DARWIN"; then
LDFLAGS="${LDFLAGS} -lobjc -framework OpenGL -framework Foundation"
CFLAGS="${CFLAGS} -lobjc -framework OpenGL -framework Foundation"
CXXFLAGS="${CXXFLAGS} -lobjc -framework OpenGL -framework Foundation"
fi

Diff for macros/gl.m4
127,136c127,129
<       if test "$target" = "powerpc-apple-macosx"; then
<         GL_CFLAGS=""
<         GL_LIBS="-framework OpenGL -framework OpenGL -framework Foundation 
- -lm"
<         dnl we assume glut always works on mac osx. does it?
<         have_gl=yes
<       else
<         GL_CFLAGS=""
<         GL_LIBS=""
<         ifelse([$2], , :, [$2])
<      fi
- ---
>       GL_CFLAGS=""
>       GL_LIBS=""
>       ifelse([$2], , :, [$2])


diff for macros/glut.m4:

61a62
>
69,76c70,71
<       if test "$host" = "powerpc-apple-darwin1.4"; then
<         GLUT_CFLAGS="${GL_CFLAGS}"
<         GLUT_LIBS="${GL_LIBS} -framework GLUT"
<         glut__temp__include=GL/glut.h
<       else
<         GLUT_LIBS=""
<         ifelse([$2], , :, [$2])
<       fi
- ---
>       GLUT_LIBS=""
>       ifelse([$2], , :, [$2])
78c73
<
- ---
>

In macros/jpeg.m4:
65,66c65
<           # we are looking for libjpeg, so png is definitely wrong here
<           CPPFLAGS="${CPPFLAGS} ${jpeg__Idir}"
- ---
>           CPPFLAGS="${CPPFLAGS} ${png__Idir}"


That should do the job.

Regards, Oliver

- -- 
_____________________________________________________________________
 Oliver Strutynski                      oli...@cs...
                                                    oli...@gm...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE75aRguUAlUEFqtKYRAjJrAJ9HHVvv0iVW2RveSfBtaPj2YE4dcwCgkq7O
a92s8obNImEEAepP8GbY8tc=
=CjJ/
-----END PGP SIGNATURE-----

[openvrml-develop] Re: openvrml-develop digest, Vol 1 #130 - 2 msgs

[Damian M. <da...@er...>]

On Sun, 21 Oct 2001 ope...@li... wrote:

>    1. Re: prob compiling openvrml  0.11.2 (Braden McDaniel)
>    2. Re: prob compiling openvrml  0.11.2 (clayton)

> From: Braden McDaniel <br...@en...>
> To: Clayton Cottingham aka drfrog <dr...@sm...>
> Cc: OpenVRML Developers Mailing List <ope...@li...>
> Date: 20 Oct 2001 17:21:56 -0400

> If you have a GtkLookat version compiled against 0.11.x, it should still
> work with 0.11.2; API changes are denoted by a change to the "minor"
> version number (the middle number).

> > [drfrog@nomad drfrog]$ uname -a
> > Linux nomad.localdomain 2.2.18 #2 Tue Apr 17 22:55:04 PDT 2001 i686 unknown
> >
> > [drfrog@nomad drfrog]$ gcc -v
> > Reading specs from /usr/lib/gcc-lib/i586-mandrake-linux/2.95.3/specs
> > gcc version 2.95.3 19991030 (prerelease)

I appear to have the same system but


I have compiled 0.11.2 and linked against GtkLookat 0.9.1.

Unfortunately, I get a core-dump from a malloc which comes from

	gluTessVertex ()

Probably some version incompatability but

MY QUESTION IS ...

	where can I find a gtklookat suitable for 0.11.2.

> It's been a while since I used gcc 2.95, but I thought it had a
> functional auto_ptr. I'd first try using the actual 2.95.3 release
> rather than the prerelease you apparently have. If that doesn't work,
> you can try gcc3.
>
> I'm using Red Hat's massively patched gcc 2.96 here; and I think newer
> Mandrake releases (8.x?) include this compiler, too.

We have had problems with RedHat's massively patched 2.96 in other
software.  It has to do with unitialized values.  It gave internal
compiler errors.

Thanks - Damian (McGuckin)

Pacific Engineering Systems International, 22/8 Campbell St, Artarmon NSW 2064
Ph:+61-2-99063377 .. Fx:+61-2-99063468   | unsolicited email not wanted here !
Views and opinions here are mine and not those of any past or present employer

Re: [openvrml-develop] Re: OpenVRML in commercial software

[Braden M. <br...@en...>]

Like Chris, I'm not a lawyer, and my interpretation of the LGPL is not
authoritative. But one of the reasons this license was chosen for
OpenVRML was the allowance for use with closed-source projects.

> ----- Original Message ----- 
> From: "Raphael Auf der Maur" <rm...@ii...>
> To: <cm...@ve...>
> Sent: Friday, October 19, 2001 7:09 AM
> Subject: OpenVRML in commercial software
> 
> 
> > Hello,
> > 
> > I've a question regarding your great OpenVRML library which is under Lesser
> > GNU licence.
> > 
> > I don't fully understand this licence, mainly paragraph 5. If I got it
> > right, it is allowed to use the library in commercial, not open-sourced
> > software as long as all modifications on the library are published and open
> > sourced too. But in paragraph 5 there are other restrictions mentioned.
> > 
> > -----------

[snipped LGPL quotation]

> > -----------
> > 
> > I'm honestrly not sure what this means. In my software, it is not possible
> > to link a compiled dll dynamicly, so I think I would have to include the
> > h-files of your library in my commecial, not open-sourced software in order
> > to use your library. Is that allowed? You might explain me the restrictions
> > in this paragraph?

It sounds to me like pertinent text is in paragraph 2 of section 5.
Unfortunately the paragraph delimiters were lost in your quotation, so
instead here's that paragraph:


    However, linking a "work that uses the Library" with the Library
    creates an executable that is a derivative of the Library (because
    it contains portions of the Library), rather than a "work that uses
    the library". The executable is therefore covered by this License.
    Section 6 states terms for distribution of such executables.

So your project may use OpenVRML as you describe and the distributed
binary may be licensed under the terms of your choosing, but those terms
and the distribtion must follow the restrictions described in section 6.
Now, in section 6 we have:

    You must give prominent notice with each copy of the work that the
    Library is used in it and that the Library and its use are covered
    by this License. You must supply a copy of this License. If the work
    during execution displays copyright notices, you must include the
    copyright notice for the Library among them, as well as a reference
    directing the user to the copy of this License. Also, you must do
    one of these things:
    
            A. Accompany the work with the complete corresponding
               machine-readable source code for the Library including
               whatever changes were used in the work (which must be
               distributed under Sections 1 and 2 above); and, if the
               work is an executable linked with the Library, with the
               complete machine-readable "work that uses the Library",
               as object code and/or source code, so that the user can
               modify the Library and then relink to produce a modified
               executable containing the modified Library. (It is
               understood that the user who changes the contents of
               definitions files in the Library will not necessarily be
               able to recompile the application to use the modified
               definitions.)
            B. Use a suitable shared library mechanism for linking with
               the Library. A suitable mechanism is one that (1) uses at
               run time a copy of the library already present on the
               user's computer system, rather than copying library
               functions into the executable, and (2) will operate
               properly with a modified version of the library, if the
               user installs one, as long as the modified version is
               interface-compatible with the version that the work was
               made with.
            C. Accompany the work with a written offer, valid for at
               least three years, to give the same user the materials
               specified in Subsection 6a, above, for a charge no more
               than the cost of performing this distribution.
            D. If distribution of the work is made by offering access to
               copy from a designated place, offer equivalent access to
               copy the above specified materials from the same place.
            E. Verify that the user has already received a copy of these
               materials or that you have already sent this user a copy.

Now, since you say you can't do B, do A, C, D, or E instead.

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>

Re: [openvrml-develop] Navigation Patch

[S.K.Bose <bo...@pa...>]

On Wed, 24 Oct 2001, luc...@li... wrote:

> Substituting the implementation of rot in ViewerOpengl.cpp with the
> following one:
> 
> ///////////////////////////////////////////////////////////////////////
> void
> ViewerOpenGL::rot(float x, float y, float z, float a)
> {
> 
> float rot_quat[4];
> 	float vec[3];
> 	
> 	
> 	vec[0]=x;
> 	vec[1]=y;
> 	vec[2]=z;
> 
> 	// normalizing vector
> 
> 	int i;
>     float module;
> 
>     module = (vec[0]*vec[0] + vec[1]*vec[1]+vec[2]*vec[2] );
> 	module=sqrt(module);
>     for (i = 0; i < 3; i++) vec[i] /= module;
> 
> 	// computing quaternion
> 	
> 	float q=sin(a*0.01/2);
> 	rot_quat[0]= vec[0]*q;
> 	rot_quat[1]= vec[1]*q;
> 	rot_quat[2]= vec[2]*q;
> 	rot_quat[3]=cos(a*0.01/2);
> 
> 	add_quats(rot_quat,d_curquat,d_curquat);
> 
> 	d_rotationChanged=true;
> 
> 	wsPostRedraw();
> 
> }
> //////////////////////////////////////////////////////////////////////
> 
> 
> will solve issue number 1. as described in the bug report regarding
> Navigation submitted by Greg Roelofs.
> I can work to improve the navigation interface.
> It would be useful if i can get in touch with Greg or with someone else
> to discuss possible improvements.
> 
> Luca

Have you seen the current CVS. This problem is solved.

Bose

[openvrml-develop] Re: OpenVRML in commercial software

[Christopher M M. <cm...@ve...>]

Hi -
I am copying this reply to one of the openvrml mailing lists, some one
there might be better able to answer your question.

Although I originally developed LibVRML97, which was used as the basis
for OpenVRML, I am not actively involved in OpenVRML anymore. I am
not clear on the licensing either, but for whatever it is worth, I was always
supportive of commercial uses of the code (under the theory that any
support of vrml was better than none).  If it meets your needs you
can still find older versions of libvrml97 around that are covered by
BSD-style licenses.   

I *think* the intent of the LGPL is that as long as you make the OpenVRML
sources available to your users, your changes to OpenVRML available to 
everyone, and your users are able to replace the OpenVRML DLL with 
any new or improved version of their choice, you are OK.  

But nobody pays me for legal advice.

Good luck,
Chris

----- Original Message ----- 
From: "Raphael Auf der Maur" <rm...@ii...>
To: <cm...@ve...>
Sent: Friday, October 19, 2001 7:09 AM
Subject: OpenVRML in commercial software


> Hello,
> 
> I've a question regarding your great OpenVRML library which is under Lesser
> GNU licence.
> 
> I don't fully understand this licence, mainly paragraph 5. If I got it
> right, it is allowed to use the library in commercial, not open-sourced
> software as long as all modifications on the library are published and open
> sourced too. But in paragraph 5 there are other restrictions mentioned.
> 
> -----------
> "A program that contains no derivative of any portion of the Library, but is
> designed to work with the Library by being compiled or linked with it, is
> called a "work that uses the Library". Such a work, in isolation, is not a
> derivative work of the Library, and therefore falls outside the scope of
> this License. However, linking a "work that uses the Library" with the
> Library creates an executable that is a derivative of the Library (because
> it contains portions of the Library), rather than a "work that uses the
> library". The executable is therefore covered by this License. Section 6
> states terms for distribution of such executables. When a "work that uses
> the Library" uses material from a header file that is part of the Library,
> the object code for the work may be a derivative work of the Library even
> though the source code is not. Whether this is true is especially
> significant if the work can be linked without the Library, or if the work is
> itself a library. The threshold for this to be true is not precisely defined
> by law. If such an object file uses only numerical parameters, data
> structure layouts and accessors, and small macros and small inline functions
> (ten lines or less in length), then the use of the object file is
> unrestricted, regardless of whether it is legally a derivative work.
> (Executables containing this object code plus portions of the Library will
> still fall under Section 6.) Otherwise, if the work is a derivative of the
> Library, you may distribute the object code for the work under the terms of
> Section 6. Any executables containing that work also fall under Section 6,
> whether or not they are linked directly with the Library itself. However,
> linking a "work that uses the Library" with the Library creates an
> executable that is a derivative of the Library (because it contains portions
> of the Library), rather than a "work that uses the library". The executable
> is therefore covered by this License. Section 6 states terms for
> distribution of such executables. "
> -----------
> 
> I'm honestrly not sure what this means. In my software, it is not possible
> to link a compiled dll dynamicly, so I think I would have to include the
> h-files of your library in my commecial, not open-sourced software in order
> to use your library. Is that allowed? You might explain me the restrictions
> in this paragraph?
> 
> Sincerly,
> Raphael
> 
> 
> 

[openvrml-develop] Re: Navigation Patch

[Greg R. <ne...@po...>]

Luca wrote:

> I can work to improve the navigation interface.
> It would be useful if i can get in touch with Greg or with someone else 
> to discuss possible improvements.

I'm on the list (in digest mode) and can discuss some of this stuff,
but my time is extremely limited at the moment, and today I'm sick.

Bose has also been working on navigation issues and knows considerably
more about the code than I do.

Regards,
-- 
Greg Roelofs            ne...@po...             http://pobox.com/~newt/
Newtware, PNG Group, Info-ZIP, AlphaWorld Map, Philips Semiconductors, ...