openvrml-develop — OpenVRML developers mailing list

RE: [openvrml-develop] Pick_Mode

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

> -----Original Message-----
> From: ope...@li...
> [mailto:ope...@li...]On Behalf Of
> Michael Schuldt
> Sent: Thursday, March 28, 2002 1:45 PM
> To: ope...@li...
> Subject: Re: [openvrml-develop] Pick_Mode
> 
> 
> Hi,
> 
> i know how the select mode worked in opengl, but i want to know 
> which names 
> and where
> the names are loaded in the Name Stack !

Check  "checkSensitive" and "setSensitive" in ViewerOpenGL

Thanks,

Bose 

Re: [openvrml-develop] Image,Movietexture and FPS

[Michael S. <Mic...@gm...>]

>"frames per second" is one way of expressing the speed of a movie, but
>it requires that you have a movie comprising frames. The speed of a
>movie is the rate of play as expressed as a factor of the normal speed.
>What if, for example, a MovieTexture was an SVG animation?

It's a good question, I think the initial value for Frames Per Second 
should be 1.0.
If SVG animation is a Movietexture the playback speed is controlled over 
the speed,
field and the fps value should be 1.0. Other opinions on this topic ??

Micha.

Re: [openvrml-develop] Image,Movietexture and FPS

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

On Fri, 2002-03-29 at 10:45, Michael Schuldt wrote:
> Hi,
> 
> the os independent Imageloader is the Class Image, why isn't there any 
> Information about the frames per second
> of a movie, the NodeMovieTexture need this Information, but in the update 
> Method only the speed Field is
> accepted. I think the speedvalue of 1.0 indicates that the Movietexture 
> plays with her normal speed.
> Has anyone some hints for me or is this a bug ?

"frames per second" is one way of expressing the speed of a movie, but
it requires that you have a movie comprising frames. The speed of a
movie is the rate of play as expressed as a factor of the normal speed.
What if, for example, a MovieTexture was an SVG animation?

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

[openvrml-develop] Image,Movietexture and FPS

[Michael S. <Mic...@gm...>]

Hi,

the os independent Imageloader is the Class Image, why isn't there any 
Information about the frames per second
of a movie, the NodeMovieTexture need this Information, but in the update 
Method only the speed Field is
accepted. I think the speedvalue of 1.0 indicates that the Movietexture 
plays with her normal speed.
Has anyone some hints for me or is this a bug ?

Micha.

Re: [openvrml-develop] Pick_Mode

[Michael S. <Mic...@gm...>]

Hi,

i know how the select mode worked in opengl, but i want to know which names 
and where
the names are loaded in the Name Stack !

Thx Micha.

Re: [openvrml-develop] Pick_Mode

[Nigel S. <ni...@ni...>]

Michael,

Try these:
http://pages.cpsc.ucalgary.ca/~ryansc/graphics/glselection.html
http://www.opengl.org/developers/faqs/technical/selection.htm
http://home.clara.net/paulyg/prog9.htm

Cheers,

Nigel

> Hi
> 
> how does the RENDER_PICK_MODE work? In the source I see the viewer for
> OpenGL uses
> GL_SELECT, but who says me which object in scene is picked?? And how worked
> it for
> touchsensor or something else.

--
                     Nigel Stewart (ni...@ni...)    
                     http://www.nigels.com/

[openvrml-develop] Pick_Mode

[Michael S. <Mic...@gm...>]

Hi

how does the RENDER_PICK_MODE work? In the source I see the viewer for 
OpenGL uses
GL_SELECT, but who says me which object in scene is picked?? And how worked 
it for
touchsensor or something else.

Thx in advance

Micha.

Re: [openvrml-develop] Extending VRML

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

On Sat, 2002-05-25 at 02:11, Michael Schuldt wrote:
> Hi,
> 
> how and where can I extending OpenVRML for my own specified Nodes.
> I want to include some special Nodes. I think i may implement my own class
> for this node which extends the normal VrmlNode. But where can I define
> the specified token for the Parser.
> 
> Thx in advance

The Old Way was to write a static defineType method, and then call it
from VrmlNamespace::defineBuiltIns.

All that has been obsoleted by changes in the rearchitecture branch. The
New Way is to implement NodeClass, NodeType, and Node classes for your
node. Node implementations get added to an implementation repository in
VrmlScene::initNodeClassMap, and then added to the scene scope in
VrmlScene::initScope. VrmlScene::initNodeClassMap is a temporary
measure. Once the cohesion issues in the library have been resolved, a
proper component registry (and registration procedure) will be
instituted.

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

[openvrml-develop] Examiner viewer for lookat

[Nigel S. <ni...@ni...>]

> >  examiner
> > viewing for lookat.  I think I'm probably qualified enough to
> > dig into the examiner issue,
> 
> What issue is that? Bose repaired examine mode some months ago.

I'm using 0.11.2.  I suppose I'll need to wade into CVS
and see if I can get examiner mode.  Thanks for the info.

Nigel

--
                     Nigel Stewart (ni...@ni...)    
                     http://www.nigels.com/

[openvrml-develop] Extending VRML

[Michael S. <Mic...@gm...>]

Hi,

how and where can I extending OpenVRML for my own specified Nodes.
I want to include some special Nodes. I think i may implement my own class
for this node which extends the normal VrmlNode. But where can I define
the specified token for the Parser.

Thx in advance

Michael Schuldt.

Re: [openvrml-develop] Making Lookat useful

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

Quoting John Richardson <ric...@sp...>:

> Hello,
> 
> In SimVRML, the idea would be to offload "ALL" simulation ( = behaviors )
> from  the rendering system. In my favorite case, that means perform the
> simulation in Labview and then use interprocess communication to access
> OpenVRML methods to modify the virtual environment.

The core of OpenVRML isn't a renderer; it's a runtime that supports the behavior
described in the VRML97 spec (or, at least it attempts to do so).

Of course, it can be used as a renderer for something as you describe. But keep
in mind that from my perspective, OpenVRML isn't supposed to be a single black
box. It's supposed to be lots of little black boxes that work together. :-)

> The SimVRML RPT is a "VRML GUI builder". The same strategy (Macintosh)
> would be used to improve the "human factors" capabilities of SimVRMLviewer,
> which comes from MacLookat, which comes from Lookat. It is just a case of
> making a more interesting or capable SimVRML RPT. The biggest problem would
> be in performing usability testing to get the most useful set of user
> interface elements for a generic VRML viewer.   Now, one of the benifits of
> using SuperCard is that it does have some built in capabilities for
> networking. Windows users would use Director, UNIX users would use MetaCard
> for rapid VRML prototyping under the above scheme.

A big difference between the environment provided by OpenVRML and that provided
by your typical GUI builder is that the clock is running in OpenVRML while
you're building the GUI--not just while you're using it.

Aside: I'm quite fond of the notion of building world UIs with VRML. But I tend
to come at it from the direction of wanting to be able to write custom nodes to
participate in such UIs.

> So, from that standpoint, removing the code from the library is fine.
> However, since Lookat and it's descendents are standalone, we would become
> dependent on being a plug-in to a browser. Is that correct?

No. None of the *lookats is dependent on lookat. It would be completely possible
to build a standalone viewer, if someone wanted to do so. (In fact, that's along
the lines of what Semblance would be, if I ever find time for that project.)

It is accurate that all of the *lookats would be broken by this change and would
need a nontrivial amount of love to repair.

> Naturally, the
> user would not have to implement the network methods. They can have other
> systems handle the networking. Just as long as there is a method in
> OpenVRML to load a file into a standalone configuration.

The library user *would* have to implement Browser::getResource (or whatever it
ends up being called). Hypothetically speaking, this method would return an
IResStream (which is basically a std::istream with additional methods for
getting things like the URI and the media type).

If the library user isn't interested in network access, this method can be
implemented using the local filesystem API for the target environment.

> Metrowerks Codewarrior should be happy with iostreams so I see no technical
> problem.
> 
> The above comments are just that. They implement a certain strategy that
> leverages the OpenVRML work. The goal of OpenVRML is still the same. Full
> compliance with the spec. I'm not a scengraph guru.
> 
> In the meantime, I'll pass on this "network integration with OpenVRML"
> question on to the SuperCard network guru's and the Labview network guru's
> for comments. I'll also pas on this to my contacts in Template Graphics
> systems for comment. They make the commercial Open Inventor libraries.
> Their subsidiary also makes Amapi and Carrara which I believ have network
> rendering capabilities.

It would be interesting to get some feedback there, but I'm inclined to doubt
that those projects have the same priorities and problems that we have.

As far as I'm concerned, it is a given that networking code doesn't belong in
the core library.

 * There is *no way* that we will ever be able to produce networking code that
is as good or as complete as what is available in a project like Mozilla. Or
even libwww for that matter.

 * If by some blunder we allowed ourselves to be convinced that a robust,
cross-platform networking subsystem were an approachable task in the context of
this project, then other parts of OpenVRML would suffer greatly. The resources
just aren't there.

Given the above, the task at hand is to *enable* the use of robust, complete
networking facilities in conjunction with OpenVRML, while keeping those
facilities *out* of the library. The code has to go *somewhere* though; so if it
isn't in the library, it goes into lookat or whatever the client application is.

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

Re: [openvrml-develop] Making Lookat useful

[John R. <ric...@sp...>]

Hello,

In SimVRML, the idea would be to offload "ALL" simulation ( = behaviors )
from  the rendering system. In my favorite case, that means perform the
simulation in Labview and then use interprocess communication to access
OpenVRML methods to modify the virtual environment.

The SimVRML RPT is a "VRML GUI builder". The same strategy (Macintosh)
would be used to improve the "human factors" capabilities of SimVRMLviewer,
which comes from MacLookat, which comes from Lookat. It is just a case of
making a more interesting or capable SimVRML RPT. The biggest problem would
be in performing usability testing to get the most useful set of user
interface elements for a generic VRML viewer.   Now, one of the benifits of
using SuperCard is that it does have some built in capabilities for
networking. Windows users would use Director, UNIX users would use MetaCard
for rapid VRML prototyping under the above scheme.

So, from that standpoint, removing the code from the library is fine.
However, since Lookat and it's descendents are standalone, we would become
dependent on being a plug-in to a browser. Is that correct? Naturally, the
user would not have to implement the network methods. They can have other
systems handle the networking. Just as long as there is a method in
OpenVRML to load a file into a standalone configuration.

Metrowerks Codewarrior should be happy with iostreams so I see no technical
problem.

The above comments are just that. They implement a certain strategy that
leverages the OpenVRML work. The goal of OpenVRML is still the same. Full
compliance with the spec. I'm not a scengraph guru.

In the meantime, I'll pass on this "network integration with OpenVRML"
question on to the SuperCard network guru's and the Labview network guru's
for comments. I'll also pas on this to my contacts in Template Graphics
systems for comment. They make the commercial Open Inventor libraries.
Their subsidiary also makes Amapi and Carrara which I believ have network
rendering capabilities.

John F. Richardson

>It'll be some weeks before I start any development on this; but the
>ideas are bouncing around in my head, so I thought I'd go ahead and post
>them to get a reaction...
>
>The major item I'll be pursuing for the 0.13 release is a good
>asynchronous I/O story. My plan for this is to use C++ standard
>iostreams in conjunction with threads (probably Boost threads). As part
>of this change, network code will be removed from the library. There
>will be a virtual stream factory method, probably on a Browser class,
>that users of the library will need to implement.
>
>The downside of this is that OpenVRML will become more difficult to use;
>the upside is that OpenVRML will be able to leverage whatever network
>code is in place in the host environment. So if one were writing a
>browser plug-in, one could use the network functionality exposed by the
>browser's API, and presumably leverage things like the browser's cache.
>
>Because the approach to implementing the streams is not readily apparent
>to persons unfamiliar with the iostreams framework, and more importantly
>because we will need a means of testing the "upstream" code in OpenVRML,
>a sample implementation will be provided. So Lookat will be improved
>along this vector, both to provide that implementation and to keep
>Lookat functioning alongside the library.
>
>And at that point we have a choice: What network code do we use as the
>basis for the sample implementation? The code must remain
>cross-platform, and any dependencies should be widely deployed (or at
>least readily available).
>
>One obvious candidate is the W3C's libwww. This, I imagine, would be
>very good for illustrative purposes, but little else. I get the
>impression that there isn't a whole lot of nontrivial code that depends
>on libwww. And presumably there are good reasons for that. Still, if
>providing an illustration is what is called for--and that is Lookat's
>primary purpose--I am sure it would fit the bill.
>
>But there is another alternative: turn Lookat into a Mozilla plug-in. In
>this case we would, of course, use Mozilla's networking facilities. The
>disadvantage? Lookat would nolonger be a standalone viewer. I get the
>impression that a lot of folks like having a standalone viewer, but
>frankly it's lost on me. The advantage is that, IMO, a Mozilla plug-in
>would be much, much more useful than what Lookat is now.
>
>So I'd like to take the group's temperature on this. A Mozilla plug-in
>is definitely a more ambitious project; but I'd like to maximize the
>value of the development time I spend on OpenVRML, and I think it's the
>way to go in that respect.
>
>--
>Braden McDaniel                           e-mail: <br...@en...>
><http://endoframe.com>                    Jabber: <br...@ja...>
>
>
>_______________________________________________
>openvrml-develop mailing list
>ope...@li...
>https://lists.sourceforge.net/lists/listinfo/openvrml-develop

Re: [openvrml-develop] Making Lookat useful

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

On Wed, 2002-03-20 at 06:34, Nigel Stewart wrote:
> I'm very happy to hear that OpenVRML is heading towards a stable
> status.  Speaking for myself, there are two major issues with
> OpenVRML - handling of events to PROTO's (H-Anim) and examiner
> viewing for lookat.  I think I'm probably qualified enough to
> dig into the examiner issue,

What issue is that? Bose repaired examine mode some months ago.

> but the camera transformation scheme
> wasn't clear to me whan I had a (quick) look recently.  Any clues
> that can be offered here on the forum?

Look at getParentTransform and friends on Node.

The event issue with PROTOs will hopefully be resolved as part of my
rewrite of the PROTO implementation. But we have no shortage of areas
that need more love than I am able to give. It would be especially
helpful if someone were to tackle caching images inside the renderer, or
use FreeType to make our Text node support stop sucking. 

> I'm more than happy to try a snapshot, whenever that becomes
> advisable....

As I posted previously, the rearchitecture branch has stabilized and is
usable for the most part. It doesn't do PROTOs yet, but I'm working on
it. The main branch should be at least as usable as 0.11.2; hopefully
more so. So have at it. :-)

> A mozilla plug-in is certainly attractive, but my feeling is that
> compulsory dependency on extraneous libs is something to be warey of.

It would only be compulsory if you want to build lookat. If you didn't
care about building lookat, you wouldn't need Mozilla. Just like you
don't need SpiderMonkey if you don't care about JavaScript support.

> If I simply want to use OpenVRML as part of a 3D engine - do I need
> to deal with xxx.so and yyy.so?  Cygwin? Win32?  So, if there is a
> scheme that can optionally use, say, the mozilla tricks for doing
> a mozilla plugin, that would be the ideal.

Someone who wants to use the OpenVRML runtime in their application
shouldn't care about lookat except as a source of example code.

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

Re: [openvrml-develop] Making Lookat useful

[Nigel S. <ni...@ni...>]

Braden,

I'm very happy to hear that OpenVRML is heading towards a stable
status.  Speaking for myself, there are two major issues with
OpenVRML - handling of events to PROTO's (H-Anim) and examiner
viewing for lookat.  I think I'm probably qualified enough to
dig into the examiner issue, but the camera transformation scheme
wasn't clear to me whan I had a (quick) look recently.  Any clues
that can be offered here on the forum?

I'm more than happy to try a snapshot, whenever that becomes
advisable....

A mozilla plug-in is certainly attractive, but my feeling is that
compulsory dependency on extraneous libs is something to be warey of.
If I simply want to use OpenVRML as part of a 3D engine - do I need
to deal with xxx.so and yyy.so?  Cygwin? Win32?  So, if there is a
scheme that can optionally use, say, the mozilla tricks for doing
a mozilla plugin, that would be the ideal.

Boost, of course, is a good thing.(tm)

Nigel Stewart

> It'll be some weeks before I start any development on this; but the
> ideas are bouncing around in my head, so I thought I'd go ahead and post
> them to get a reaction...


--
                     Nigel Stewart (ni...@ni...)    
                     http://www.nigels.com/

[openvrml-develop] Making Lookat useful

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

It'll be some weeks before I start any development on this; but the
ideas are bouncing around in my head, so I thought I'd go ahead and post
them to get a reaction...

The major item I'll be pursuing for the 0.13 release is a good
asynchronous I/O story. My plan for this is to use C++ standard
iostreams in conjunction with threads (probably Boost threads). As part
of this change, network code will be removed from the library. There
will be a virtual stream factory method, probably on a Browser class,
that users of the library will need to implement.

The downside of this is that OpenVRML will become more difficult to use;
the upside is that OpenVRML will be able to leverage whatever network
code is in place in the host environment. So if one were writing a
browser plug-in, one could use the network functionality exposed by the
browser's API, and presumably leverage things like the browser's cache.

Because the approach to implementing the streams is not readily apparent
to persons unfamiliar with the iostreams framework, and more importantly
because we will need a means of testing the "upstream" code in OpenVRML,
a sample implementation will be provided. So Lookat will be improved
along this vector, both to provide that implementation and to keep
Lookat functioning alongside the library.

And at that point we have a choice: What network code do we use as the
basis for the sample implementation? The code must remain
cross-platform, and any dependencies should be widely deployed (or at
least readily available).

One obvious candidate is the W3C's libwww. This, I imagine, would be
very good for illustrative purposes, but little else. I get the
impression that there isn't a whole lot of nontrivial code that depends
on libwww. And presumably there are good reasons for that. Still, if
providing an illustration is what is called for--and that is Lookat's
primary purpose--I am sure it would fit the bill.

But there is another alternative: turn Lookat into a Mozilla plug-in. In
this case we would, of course, use Mozilla's networking facilities. The
disadvantage? Lookat would nolonger be a standalone viewer. I get the
impression that a lot of folks like having a standalone viewer, but
frankly it's lost on me. The advantage is that, IMO, a Mozilla plug-in
would be much, much more useful than what Lookat is now.

So I'd like to take the group's temperature on this. A Mozilla plug-in
is definitely a more ambitious project; but I'd like to maximize the
value of the development time I spend on OpenVRML, and I think it's the
way to go in that respect.

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

[openvrml-develop] ANNOUNCE: SimVRML 1.0 for the Macintosh (OS 9)

[John R. <ric...@sp...>]

Hello,

This is to announce the release of Version 1.0 of the SimVRML system for
Macintosh OS 9. SimVRML 1.0 consists of the SimVRML 1.0 viewer, the SimVRML
RPT and the SimVRML OpenVRML API. RPT stands for Rapid Prototyping Tool.
This is actually a toolset and API. The platform for this announcement is
the Macintosh G3 / G4. The OS for this announcement is Mac OS 9.

http://sourceforge.net/projects/simvrml/

There are 4 download options.
a) You can download the applications, user guide, release notes and 5 VRML
97 files.
b) You can download the Test Suite ( 16 VRML files )
c) You can download the Source. This is the C++ source for the
SimVRMLviewer along with some precompiled libraries. There is also the
SimVRML RPT project source (SuperCard).
d) You can download it all in parts. The applications, then the documents,
then the virtual environments and finally the source. This option is for
downloads over low bandwidth connections.

In the above URL, just replace simvrml with openvrml and you get to the
OpenVRML project and can download the library source code and source for
viewers for UNIX/PC.

Components of the SimVRML 1.0 System
--------------------------------------
1) SimVRML RPT1.0  --- This is a Test default GUI for SimVRMLviewer and an
API. SimVRMLviewer is a modified version of MacLookat.  SimVRML RPT is a
Macintosh application created with SuperCard 3.6. SuperCard is a multimedia
IDE with an associated programming language that is in the xTalk family of
programming languages. I like to think of it as sort of a "pidgeon english
programming language". The closest common equivalent in the PC world (and
Mac) would be the Director IDE and the Lingo programming language. SimVRML
RPT 1.0 is speech enabled. The minimum requirement for speech navigation is
a good USB microphone. See back issues of Macworld magazine for a review of
USB microphones. I use the microphone that comes with IBM ViaVoice for the
Mac which is the Andreas NC-71. The speech recognition is based upon Apples
Plaintalk discrete recognition system. The test GUI has graphical elements
related to basic navigation within a VRML based virtual environment. See
the list of MacLookat enhancements below.

2) SimVRML OpenVRML API --- This is an API for interfacing applications to
SimVRMLviewer. The API can be used by any application or programming
language that is capable of Interprocess Communications (IPC). In the
Macintosh OS, the primary focus of the API is IPC involving Apple Events.
Although the API is useful for FORTRAN, C, C++ and Pascal applications
interfacing to SimVRMLviewer, the primary focus of the API is the use of
non standard programming languages. The API discusses interfacing with
SimVRMLviewer using the SuperTalk and also the G language of Labview.
SuperTalk is an english like programming language associated with the
SuperCard IDE. G is a parallel dataflow graphics language associated with
the Labview IDE. SuperCard is usedful for multimedia GUI building. Two test
SuperCard GUI's of moderate complexity are enclosed with the SimVRML RPT.
Labview is useful for scientific data processing and real world and
sometime real time real world data acquisition. Obviously, you would need a
data acquisition card and whatever thermometer or osscilloscope or
instrument you were inputting real world data from.

3) SimVRMLviewer 1.0 --- This is a modified version of MacLookat. This is
an enhanced Viewer for Virtual Environments created using VRML 97 and
rendered using the OpenVRML libraries. The currently supported version of
OpenVRML for this announcement is 0.10.1. Enhancements relate to general
navigation. MacLookat already has basic keyboard navigation. The following
general navigation functions are supported.

+ Rotation of the Avatars (I.E., your eye) viewpoint about the x, y and z
axis with origin inside your eye.
+ Translation of the Avatars (I.E., your eye) viewpoint along the x, y and
z axis with origin inside your eye.
+ Scaling of the virtual environment (zooming)
+ Variable translation speeds and rotation angles.
+ Next and Previous viewpoints.
+ MacLookat functions such as toggling (wireframes,...), loading,...
+ Speech Input with tooltips cueing the user as to the acceptable phrases.
+ Multimedia GUI with images and tooltips helping to indicate navigational
functions. Navigation can be button based or menu based or verbal. Mouse
dragging inside the virtual environment window is not implemented beyond
MacLookat functions.
+ Accelerator keys and associated menu items. Apple-R for rotate,.....
+ Trackball rotation of the virtual environment. This is implemented but
can give unusual results

4) Auxiliary files --- Consists of a test suite of virtual environments.
There is also a 28 page SimVRML RPT User's Guide and release notes. All
documentation is in PDF format.

Future
------------------------------------
+ Enhance the API to handle EventIn's and EventOut's,....
+ Link SimVRMLLookat to OpenVRML 0.11.x (This should make trackball
navigation more predictable)
+ Enhance SimVRML RPT
+ Embed OpenVRML as an Xcmd
+ Extend the API for Real time Data Acquisition (Labview)
+ Continuous speech

John F. Richardson

Re: [openvrml-develop] Rearchitecture branch status

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

The code on the rearchitecture branch is now somewhat usable. There is
some remaining breakage (I think Inline is busted, for one), but for the
most part things seem to be working. I've started working on the new
PROTO implementation.

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

[openvrml-develop] Rearchitecture branch status

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

All the previously unimplemented methods have been implemented, and the
rearchitecture branch is compiling (and linking) just fine on Linux
using gcc 3.0.4. YMMV with other platforms/compilers.

It does not run yet. Well, not correctly, at least. Hopefully the
remaining issues will be sorted out soon.

For anyone just tuning in, the rearchitecture branch tag is
"OpenVRML-REARCH_BRANCH".

Braden

Re: [openvrml-develop] still problems compiling openvrml on aix

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

On Wed, 2002-03-13 at 07:09, Chr...@ge... wrote:
> hi
> 
> i still have few problems with compiling on rs6000 workstations. first it
> stops with error shown in this first section. maybe someone knows about
> this error. mesa 3.4 is installed and configure finds all libaries in the
> right places, but it still breaks up. so...
> 
> next thing is like shown in part 2, there are messages about a math.h.
> thought to be a compiler problem, and tried it with gcc 2.95 and gcc 2.9 (
> gcc 3.0 doesnt work at all cause it has a problem finding auto_ptr while
> configure runs ).
> 
> any help welcome ....
> 
> regards
> 
> Christian Setzer
> GE CompuNet Muenchen
> Enterprise Computing Solutions
> Hoerselbergstrasse 7, 81677 Muenchen, Germany
> Phone: +49 (0)89 / 382-47742, , Mobile: +49 (0) 171 1284997
> E-Mail : Chr...@GE...
> Visit us on the Internet: http://www.gecits-eu.com
> 
> 
> This email is confidential. If you are not the intended recipient,
> you must not disclose or use the information contained in it.
> If you have received this mail in error, please tell us
> immediately by return email and delete the document.
> 
> ----------------------------------------------------
> error 1
> ----------------------------------------------------
> 
> 
> ranlib .libs/libopenvrml-gl.a
> rm -fr .libs/libopenvrml-gl.lax .libs/libopenvrml-gl.lax
> creating libopenvrml-gl.la
> (cd .libs && rm -f libopenvrml-gl.la && ln -s ../libopenvrml-gl.la
> libopenvrml-gl.la)
> Target "all" is up to date.
> Target "all-am" is up to date.
> Target "all" is up to date.
> Target "all-am" is up to date.
> Target "all" is up to date.
> Making all in lookat
>         c++ -DHAVE_CONFIG_H -DANTLR_REALLY_NO_STRCASECMP -I. -I. -I../..
> -I../../src/openvrml -I../../src/openvrml-gl  -I/usr/local/include
> -I/usr/local/include   -I/usr/local/include   -g -O2 -c lookat.cpp
> lookat.cpp: In function `void worldChangedCB(int)':
> lookat.cpp:166: passing `const char *' as argument 1 of
> `glutSetWindowTitle(char *)' discards qualifiers
> lookat.cpp: In function `void buildViewpointMenu()':
> lookat.cpp:217: passing `const char *' as argument 1 of
> `glutAddMenuEntry(char *, int)' discards qualifiers
> lookat.cpp:219: passing `const char *' as argument 1 of
> `glutAddMenuEntry(char *, int)' discards qualifiers

Looks like your glut version is a little different from what we're
accustomed to compiling against. Looking at the glut spec, those
functions do indeed take char * rather than const char *. Please file a
bug about this.

There's no easy fix for this that doesn't involve getting into the code.
It's actually easy to fix, but you'll have to know a bit about C++ and
constness in order to patch this.

> ------------------------------------------------------------------
> error 2
> ------------------------------------------------------------------
> 
> 
>         /bin/sh ../../../../libtool --mode=compile c++ -DHAVE_CONFIG_H
> -DANTLR_REALLY_NO_STRCASECMP -I. -I. -I../../../..
> -I../../../../src/openvrml  -I/usr/local/include -I/usr/local/include
> -I/usr/local/include   -g -O2 -c ViewerOpenGL.cpp
> mkdir .libs
> c++ -DHAVE_CONFIG_H -DANTLR_REALLY_NO_STRCASECMP -I. -I. -I../../../..
> -I../../../../src/openvrml -I/usr/local/include -I/usr/local/include
> -I/usr/local/include -g -O2 -c ViewerOpenGL.cpp  -DPIC -o
> .libs/ViewerOpenGL.lo
> In file included from ViewerOpenGL.cpp:45:
> /usr/local/lib/gcc-lib/powerpc-ibm-aix4.3.2.0/2.95.3/include/math.h:238:
> warning: `M_PI' redefined
> ../../../../config.h:43: warning: this is the location of the previous
> definition

This won't be a problem in future versions of OpenVRML, as we don't use
those constant names anymore. In the meantime, I suggest you simply
delete (or comment out) the offending section of acconfig.h to get
things working.

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

[openvrml-develop] still problems compiling openvrml on aix

[<Chr...@GE...>]

hi

i still have few problems with compiling on rs6000 workstations. first it
stops with error shown in this first section. maybe someone knows about
this error. mesa 3.4 is installed and configure finds all libaries in the
right places, but it still breaks up. so...

next thing is like shown in part 2, there are messages about a math.h.
thought to be a compiler problem, and tried it with gcc 2.95 and gcc 2.9 (
gcc 3.0 doesnt work at all cause it has a problem finding auto_ptr while
configure runs ).

any help welcome ....

regards

Christian Setzer
GE CompuNet Muenchen
Enterprise Computing Solutions
Hoerselbergstrasse 7, 81677 Muenchen, Germany
Phone: +49 (0)89 / 382-47742, , Mobile: +49 (0) 171 1284997
E-Mail : Chr...@GE...
Visit us on the Internet: http://www.gecits-eu.com


This email is confidential. If you are not the intended recipient,
you must not disclose or use the information contained in it.
If you have received this mail in error, please tell us
immediately by return email and delete the document.

----------------------------------------------------
error 1
----------------------------------------------------


ranlib .libs/libopenvrml-gl.a
rm -fr .libs/libopenvrml-gl.lax .libs/libopenvrml-gl.lax
creating libopenvrml-gl.la
(cd .libs && rm -f libopenvrml-gl.la && ln -s ../libopenvrml-gl.la
libopenvrml-gl.la)
Target "all" is up to date.
Target "all-am" is up to date.
Target "all" is up to date.
Target "all-am" is up to date.
Target "all" is up to date.
Making all in lookat
        c++ -DHAVE_CONFIG_H -DANTLR_REALLY_NO_STRCASECMP -I. -I. -I../..
-I../../src/openvrml -I../../src/openvrml-gl  -I/usr/local/include
-I/usr/local/include   -I/usr/local/include   -g -O2 -c lookat.cpp
lookat.cpp: In function `void worldChangedCB(int)':
lookat.cpp:166: passing `const char *' as argument 1 of
`glutSetWindowTitle(char *)' discards qualifiers
lookat.cpp: In function `void buildViewpointMenu()':
lookat.cpp:217: passing `const char *' as argument 1 of
`glutAddMenuEntry(char *, int)' discards qualifiers
lookat.cpp:219: passing `const char *' as argument 1 of
`glutAddMenuEntry(char *, int)' discards qualifiers
make: 1254-004 The error code from the last command is 1.


Stop.
make: 1254-004 The error code from the last command is 1.


Stop.
make: 1254-004 The error code from the last command is 1.


Stop.
make: 1254-004 The error code from the last command is 2.


Stop.






------------------------------------------------------------------
error 2
------------------------------------------------------------------


        /bin/sh ../../../../libtool --mode=compile c++ -DHAVE_CONFIG_H
-DANTLR_REALLY_NO_STRCASECMP -I. -I. -I../../../..
-I../../../../src/openvrml  -I/usr/local/include -I/usr/local/include
-I/usr/local/include   -g -O2 -c ViewerOpenGL.cpp
mkdir .libs
c++ -DHAVE_CONFIG_H -DANTLR_REALLY_NO_STRCASECMP -I. -I. -I../../../..
-I../../../../src/openvrml -I/usr/local/include -I/usr/local/include
-I/usr/local/include -g -O2 -c ViewerOpenGL.cpp  -DPIC -o
.libs/ViewerOpenGL.lo
In file included from ViewerOpenGL.cpp:45:
/usr/local/lib/gcc-lib/powerpc-ibm-aix4.3.2.0/2.95.3/include/math.h:238:
warning: `M_PI' redefined
../../../../config.h:43: warning: this is the location of the previous
definition
/usr/local/lib/gcc-lib/powerpc-ibm-aix4.3.2.0/2.95.3/include/math.h:239:
warning: `M_PI_2' redefined
../../../../config.h:47: warning: this is the location of the previous
definition
/usr/local/lib/gcc-lib/powerpc-ibm-aix4.3.2.0/2.95.3/include/math.h:240:
warning: `M_PI_4' redefined
../../../../config.h:51: warning: this is the location of the previous
definition
/usr/local/lib/gcc-lib/powerpc-ibm-aix4.3.2.0/2.95.3/include/math.h:241:
warning: `M_1_PI' redefined
../../../../config.h:55: warning: this is the location of the previous
definition
mv -f .libs/ViewerOpenGL.lo ViewerOpenGL.o
(cd . && ln -s ViewerOpenGL.o ViewerOpenGL.lo)
        /bin/sh ../../../../libtool --mode=compile c++ -DHAVE_CONFIG_H
-DANTLR_REALLY_NO_STRCASECMP -I. -I. -I../../../..
-I../../../../src/openvrml  -I/usr/local/include -I/usr/local/include
-I/usr/local/include   -g -O2 -c OpenGLEvent.cpp
rm -f .libs/OpenGLEvent.lo
c++ -DHAVE_CONFIG_H -DANTLR_REALLY_NO_STRCASECMP -I. -I. -I../../../..
-I../../../../src/openvrml -I/usr/local/include -I/usr/local/include
-I/usr/local/include -g -O2 -c OpenGLEvent.cpp  -DPIC -o
.libs/OpenGLEvent.lo
In file included from OpenGLEvent.cpp:61:
/usr/local/lib/gcc-lib/powerpc-ibm-aix4.3.2.0/2.95.3/include/math.h:238:
warning: `M_PI' redefined
../../../../config.h:43: warning: this is the location of the previous
definition
/usr/local/lib/gcc-lib/powerpc-ibm-aix4.3.2.0/2.95.3/include/math.h:239:
warning: `M_PI_2' redefined
../../../../config.h:47: warning: this is the location of the previous
definition
/usr/local/lib/gcc-lib/powerpc-ibm-aix4.3.2.0/2.95.3/include/math.h:240:
warning: `M_PI_4' redefined
../../../../config.h:51: warning: this is the location of the previous
definition
/usr/local/lib/gcc-lib/powerpc-ibm-aix4.3.2.0/2.95.3/include/math.h:241:
warning: `M_1_PI' redefined
../../../../config.h:55: warning: this is the location of the previous
definition
mv -f .libs/OpenGLEvent.lo OpenGLEvent.o

Re: [openvrml-develop] Sound in OpenVRML

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

Braden McDaniel wrote:

>Quoting -oli- <ol...@fr...>:
>
>>At 09:06 12.03.2002 -0500, you wrote:
>>
>>>It [sound] was disabled a few releases ago. It was a matter of convenience
>>>
>>>then.
>>>And I intended for it to be replaced with something better. I still do;
>>>but I didn't anticipate having to wait this long. In retrospect, I wish
>>>I hadn't disabled it. However, I now have higher priorities than turning
>>>it back on.
>>>
>>Oh, I understand!
>>Was there distance attenuation, spatalizing etc.?
>>
>
>I'm not sure... All the code is still there in CVS.
>

I'm about 99% sure there's no distance attenuation, spatializing or 
anything else except for looping support...the code only works on Linux 
and I think the only things that need to be done to get it to compile is 
to define HAVE_SOUND and add the sound code back to the makefiles. If I 
can find the time, I'll generate a patch to get this readded to the 
build until we have a better solution...

>>>If you want to submit a patch to enable the sound support, it would be
>>>welcome.
>>>
>>I'm thinking about integrating OpenAL-support in OpenVRML, but there are 
>>major incompatibilities between the directivity model used in OpenAL 
>>(cones) and VRML (ellipsoids). I'm trying to find a solution here...
>>
>
>I know Tom Flynn has done some work to this end. Hopefully he'll chime in.
>

-oli- contacted me a month or so ago about this and I wasn't able to 
give him any answers as I never made it that deep into integrating OpenAL...


<snip>

>>I have also not the understanding of OpenVRML to see in which (main-?)loop 
>>the next chunk of the wave-file can be handed to the sound buffer...
>>Tips are welcome!
>>
>
>Check out the old sound code.
>

NodeAudioClip::update (in vrml97node.cpp) is called on each loop so 
that's one place where you could do it...

Tom

Re: [openvrml-develop] Sound in OpenVRML

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

Quoting -oli- <ol...@fr...>:

> At 09:06 12.03.2002 -0500, you wrote:
> >It [sound] was disabled a few releases ago. It was a matter of convenience
> 
> >then.
> >And I intended for it to be replaced with something better. I still do;
> >but I didn't anticipate having to wait this long. In retrospect, I wish
> >I hadn't disabled it. However, I now have higher priorities than turning
> >it back on.
> 
> Oh, I understand!
> Was there distance attenuation, spatalizing etc.?

I'm not sure... All the code is still there in CVS.

> >If you want to submit a patch to enable the sound support, it would be
> >welcome.
> 
> I'm thinking about integrating OpenAL-support in OpenVRML, but there are 
> major incompatibilities between the directivity model used in OpenAL 
> (cones) and VRML (ellipsoids). I'm trying to find a solution here...

I know Tom Flynn has done some work to this end. Hopefully he'll chime in.

I'm of the opinion that the spatialization/directivity code ought to be part of
OpenVRML. That approach means that

 * we have control over our consistency with the VRML97 spec.
 * we don't require much intelligence from the underlying sound library,
   meaning we can be portable to different audio renderers without too much
   hassle.

> The problem also is that do not know how to generate a patch.
> Do I need diff or something like this?

If you have a CVS working tree, "cvs diff -u". Otherwise you'll want to use
plain ol' diff. (But you really should have a CVS working tree.)

> >In terms of something better, I want to do streaming.
> 
> With OpenAL this is possible - but not trivial.

I would like to use GStreamer--for streaming both sound and video. On Windows
this would be handled with DirectX, so we need a good abstraction API.

> I have also not the understanding of OpenVRML to see in which (main-?)loop 
> the next chunk of the wave-file can be handed to the sound buffer...
> Tips are welcome!

Check out the old sound code.

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

Re: [openvrml-develop] Sound in OpenVRML

[-oli- <ol...@fr...>]

At 09:06 12.03.2002 -0500, you wrote:
>It [sound] was disabled a few releases ago. It was a matter of convenience 
>then.
>And I intended for it to be replaced with something better. I still do;
>but I didn't anticipate having to wait this long. In retrospect, I wish
>I hadn't disabled it. However, I now have higher priorities than turning
>it back on.

Oh, I understand!
Was there distance attenuation, spatalizing etc.?

>If you want to submit a patch to enable the sound support, it would be
>welcome.

I'm thinking about integrating OpenAL-support in OpenVRML, but there are 
major incompatibilities between the directivity model used in OpenAL 
(cones) and VRML (ellipsoids). I'm trying to find a solution here...

The problem also is that do not know how to generate a patch.
Do I need diff or something like this?

>In terms of something better, I want to do streaming.

With OpenAL this is possible - but not trivial.
I have also not the understanding of OpenVRML to see in which (main-?)loop 
the next chunk of the wave-file can be handed to the sound buffer...
Tips are welcome!

         -oli-
         (Oliver Baum)

Re: [openvrml-develop] Sound in OpenVRML

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

On Tue, 2002-03-12 at 06:09, -oli- wrote:
> Hi!
> 
> I've got some questions concerning sound in OpenVRML:
> 
> a) Why was sound support taken out of the current release?

It was disabled a few releases ago. It was a matter of convenience then.
And I intended for it to be replaced with something better. I still do;
but I didn't anticipate having to wait this long. In retrospect, I wish
I hadn't disabled it. However, I now have higher priorities than turning
it back on.

> b) Under which OS'es did the old sound support (sound.cpp in CVS) work?

Just Linux, I think.

If you want to submit a patch to enable the sound support, it would be
welcome.

In terms of something better, I want to do streaming. Since streaming
media APIs differ across platforms, we need to have an abstraction layer
analogous to what we have for the 3D renderer. Prerequisite for
streaming is asynchronous IO, which is something I'll be working on for
0.13.

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

[openvrml-develop] Sound in OpenVRML

[-oli- <ol...@fr...>]

Hi!

I've got some questions concerning sound in OpenVRML:

a) Why was sound support taken out of the current release?
b) Under which OS'es did the old sound support (sound.cpp in CVS) work?

Thanks for help!

	-oli-
	(Oliver Baum)