openvrml-develop — OpenVRML developers mailing list

[openvrml-develop] script-modules branch merged to trunk

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

The script-modules branch has been merged to the trunk. This adds a
couple of significant features...

First, the Script node Java binding has been resurrected (and nearly
completely rewritten in the process). Bugs 1900214, 1900215, and 1900216
note known shortcomings; though a lot of the code has not been heavily
tested. I encourage anyone with an interest in this to check out the
trunk, test it, and file bugs. 0.18 is still some ways off and there's
plenty of time to fix stuff.

Second, scripting backends are now distinct modules and there's a pretty
well-defined API in place for creating them. This, really, was the main
thrust of the work on the script-modules branch; I only resuscitated the
Java backend because I felt bad about moving that much dead code around
(and I would have felt worse about deleting it). I'll be tweaking this
API a bit and adding documentation prior to the 0.18 release. The upshot
is that there will be a clear path for anyone motivated to provide a
scripting backend for Perl, Python, or whatever. It also has the effect
of isolating some dependencies from libopenvrml.

Next, I'm gonna see if I can knock out a couple of longstanding bugs
(that don't have API impact) and release 0.17.6 sometime in March.
Following that, I want to move the trunk to a point where coverage tests
for the JavaScript and Java bindings can be run in "make check". The
first thing that involves is ensuring that an openvrml::browser can run
the simulation "headless" (i.e., without rendering anything).

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

[openvrml-develop] Status: script modules and the Script node Java binding

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

Over on branches/script-modules, I have both the JavaScript and Java
Script node bindings loading as dlopen'd modules. As that implies, the
Java binding has been resuscitated. It is not complete; however, I
believe it is in a state of better-than-parity to where it was before I
opted to disable it by default.

I have also built the JavaScript stuff on Windows (using the Windows
XULRunner SDK distribution); though I haven't run it there yet. The
introduction of DLLs loaded with LoadLibrary may mean it's time to start
thinking about the hard (for me) problem of what an "installed" OpenVRML
looks like on Windows.

Anyway, I think it's time to go ahead and merge this stuff back to the
trunk and address further issues there.

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

[openvrml-develop] A note to packagers re: 0.17.5

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

The 0.17.5 release of OpenVRML changes the --disable-gecko-rpath
configure flag that was added in 0.17.3 to --enable-gecko-rpath. In
other words, the -rpath flag no longer gets added by default.

The motivation for this is that Linux distributions appear to be moving
toward configurations where the dynamic linker knows about the location
of the Gecko runtime libraries. In such cases, the -rpath flag is
unnecessary (and can introduce complications).

For configurations where the dynamic linker does *not* know about the
location of the Gecko runtime libraries, OpenVRML should be configured
with --enable-gecko-rpath. In most such scenarios, configure should be
able to figure out the appropriate -rpath argument to apply. Where it
cannot, the precious variable GRE_PATH should be set to the location of
the Gecko runtime libraries at configure time.

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

[openvrml-develop] ANN: OpenVRML 0.17.5

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

OpenVRML 0.17.5 is now available.  The distribution can be obtained
from

  <http://downloads.sourceforge.net/openvrml/openvrml-0.17.5.tar.gz>

OpenVRML is a C++ runtime library for VRML97 and X3D worlds.  It is
capable of reading and displaying VRML/X3D; it can be used for creating
loaders, file converters, and VRML/X3D browsers.

OpenVRML includes an out-of-process viewer component for use in X11
environments along with hosts for this component in the form of a
Mozilla browser plug-in and a stand-alone player.

You can find OpenVRML on the Web at

  <http://openvrml.org>


New in OpenVRML 0.17.5:

- Fixed PROTO instantiation not to clone non-default initial values.
  In addition to improving performance, this fixes a crash that
  occurred when an initial value was or contained a Script node.

- Fixed parsing of PROTO definitions with multiple IS mappings from
  different components of the same exposedField/inputOutput.

- Changed the build configuration to default not to apply an -rpath
  argument for the Gecko runtime library directory to executables that
  link with libopenvrml.

[openvrml-develop] ANN: OpenVRML 0.17.4

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

OpenVRML 0.17.4 is now available.  The distribution can be obtained
from

  <http://downloads.sourceforge.net/openvrml/openvrml-0.17.4.tar.gz>

OpenVRML is a C++ runtime library for VRML97 and X3D worlds.  It is
capable of reading and displaying VRML/X3D; it can be used for creating
loaders, file converters, and VRML/X3D browsers.

OpenVRML includes an out-of-process viewer component for use in X11
environments along with hosts for this component in the form of a
Mozilla browser plug-in and a stand-alone player.

You can find OpenVRML on the Web at

  <http://openvrml.org>


New in OpenVRML 0.17.4:

- Fixed a crash in the Mozilla plug-in.

- Fixed EXTERNPROTO instances to apply default field values declared
  in the PROTO definition.

Re: [openvrml-develop] Is openvrml still developed?

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

On Mon, 2008-01-07 at 11:09 +0100, Josip Almasi wrote:

[snip]

> I'm afraid that plugin thing was a bad idea... for 10 years now, I'm 
> working on workarounds for web browser and vrml plugin bugs. Like, a 
> javascript Script node hangs works well on exploter but hangs mozilla or 
> vice versa, etc.

There is nothing about the plug-in context that makes a VRML/X3D player
more or less buggy. The fact that players have had--and continue to
have--in general, various Issues has nothing to do with plug-ins.

A reasonably full-featured VRML/X3D player is a very complex piece of
software that has dependencies on several other software layers (e.g.,
JavaScript, Java, audio and movie playback, network transport, etc.). As
such, ensuring a reasonable level of reliability across the myriad use
cases that touch the various subsystems takes a *huge* amount of effort.

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

[openvrml-develop] ANN: OpenVRML 0.17.3

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

OpenVRML 0.17.3 is now available.  The distribution can be obtained
from

  <http://downloads.sourceforge.net/openvrml/openvrml-0.17.3.tar.gz>

OpenVRML is a C++ runtime library for VRML97 and X3D worlds.  It is
capable of reading and displaying VRML/X3D; it can be used for creating
loaders, file converters, and VRML/X3D browsers.

OpenVRML includes an out-of-process viewer component for use in X11
environments along with hosts for this component in the form of a
Mozilla browser plug-in and a stand-alone player.

You can find OpenVRML on the Web at

  <http://openvrml.org>


New in OpenVRML 0.17.3:

- Fixed a crash in openvrml-xembed caused by a race during
  initialization.

- Fixed a bug in the Mozilla plug-in that prevented external resources
  from loading.

[openvrml-develop] ANN: OpenVRML 0.17.2

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

OpenVRML 0.17.2 is now available.  The distribution can be obtained
from

  <http://downloads.sourceforge.net/openvrml/openvrml-0.17.2.tar.gz>

OpenVRML is a C++ runtime library for VRML97 and X3D worlds.  It is
capable of reading and displaying VRML/X3D; it can be used for creating
loaders, file converters, and VRML/X3D browsers.

OpenVRML includes an out-of-process viewer component for use in X11
environments along with hosts for this component in the form of a
Mozilla browser plug-in and a stand-alone player.

You can find OpenVRML on the Web at

  <http://openvrml.org>


New in OpenVRML 0.17.2:

- Fixed a crash in relative URL resolution.

- Added support for gzip-encoded resources to openvrml-player.

Re: [openvrml-develop] Is openvrml still developed?

[Nicholas F. P. <np...@vt...>]

Hi Dirk~

Yes indeed this codebase is actively developed. Our fearless and talented leader Braden has continued to improve on this
multi-platform codebase over many years and I consider it a strong dark horse in terms of open C++ toolkits... thanks everyone!


 Indeed the inclusion in Fedora and the new parser and X3D support shows this is a project with growing momentum. While X3D provides
some great new features, all over the world people are still innovating on and deploying VRML. My vrml from '98 still runs and
faster than ever! :->

We have just done a project here @ Virginia Tech running openVRML in our CAVE wrapped by the DIVERSE codebase... we are working on a
UI / interaction handler next.

Hope you continue your work on open standards!

best regards,

	_n_polys



> -----Original Message-----
> From: ope...@li...
> [mailto:ope...@li...]On Behalf Of Dirk
> Sent: Sunday, January 06, 2008 2:09 PM
> To: ope...@li...
> Subject: [openvrml-develop] Is openvrml still developed?
>
>
> Hello,
>
> I tried to compile openvrml for Linux but deleted everything when it
> required me to install udev and hal (which is obviously more a bug than
>  a dependency, right?).
>
> So, as there is practically no plugin for VRML or X3D available and
> people, desperately, start to write VRML players in flash
> http://www.opensourcery.net/x3d/ , I'd like to know if it makes sence to
> wait further for VRML (more than 10 years have already passed) or if
> web3d is dead?
>
> VRML is even worse than Duke Nukem Forever :D
>
>
> Dirk
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> openvrml-develop mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvrml-develop

Re: [openvrml-develop] Rotation with "complex" axis problem in VRML

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

Eric Cazeaux wrote:
> I don't know if it's the correct mailing list but anyway.

[snip]

It is.

> The problem is that for each call of r.x(), r.y(),r.z(), the axis is 
> renormalized. So, I think it should be fixed using this new code :

[snip]

> At the same time, we save 2 normalizations!
> Let me know if I'am right or not and you will be able to fixe it.

You are right. However, this code has been completely replaced in 
OpenVRML 0.17. The current parsing code doesn't do any normalization. 
See openvrml::rotation_parser<>::operator() in vrml97_grammar.h.

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

[openvrml-develop] Rotation with "complex" axis problem in VRML

[Eric C. <eri...@c-...>]

Hi,

I don't know if it's the correct mailing list but anyway. I found a 
strange behavior of the parser when parsing rotation axis in VRML in 
some cases.

/Transform
{
   rotation 0.55735 0.55735 0.55735 1.571
    children []
}
/
Looking forward, I found that the axis for the rotation is currently 
initialized like this (in /Vrml97Parser.cpp line 3536/) :
/
x = floatValue();
y = floatValue();
z = floatValue();
angle = floatValue();

r.x(x);
r.y(y);
r.z(z);
r.angle(angle);/


The problem is that for each call of r.x(), r.y(),r.z(), the axis is 
renormalized. So, I think it should be fixed using this new code :
/
x = floatValue();
y = floatValue();
z = floatValue();
angle = floatValue();

r.axis(vec3f(x,y,z).normalize());
r.angle(angle);/

At the same time, we save 2 normalizations!
Let me know if I'am right or not and you will be able to fixe it.

Regards,

Eric

Re: [openvrml-develop] Is openvrml still developed?

[Josip A. <jo...@vr...>]

Dirk wrote:
> Hello,
> 
> I tried to compile openvrml for Linux but deleted everything when it
> required me to install udev and hal (which is obviously more a bug than
>  a dependency, right?).

OpenVRML is available in fedora extras and works out of the box.
For other distros easiest way might be xj3d. Though its pretty far from 
easy, not due to xj3d itself, but because of install jthis install jthat...
Either way, no need to compile anything.

> So, as there is practically no plugin for VRML or X3D available and

I'm afraid that plugin thing was a bad idea... for 10 years now, I'm 
working on workarounds for web browser and vrml plugin bugs. Like, a 
javascript Script node hangs works well on exploter but hangs mozilla or 
vice versa, etc.

> VRML is even worse than Duke Nukem Forever :D

Well I often feel like that:))
There isn't even a single vrml browser available on any platform that's 
fully compliant to spec.
Likewise, there's no a single RDBMS that's fully compliant with SQL 
spec... so let's wait a few decades more;)

Regards...

Re: [openvrml-develop] Status update: modularization

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

On Fri, 2006-10-20 at 17:40 -0400, Braden McDaniel wrote:
> As I mentioned in a previous update, the primary feature I want to have 
> in place for 0.17 is the fragmentation of libopenvrml into dynamically 
> loaded modules. I've started some work on this.

Well, obviously that didn't quite happen...

> There will be two kinds of modules: node components and scripting 
> engines. I've started with the latter because it is more obvious to me 
> how scripting engine modules should work; node component modules are 
> going to require an XML descriptor and inter-component dependencies and 
> it's not yet clear to me what the desirable mechanics are for that.
> 
> At this point I have successfully ported the JavaScript scripting 
> backend to a dynamically loaded module; it seems to be working just 
> fine. I would like to take this opportunity to fix the long-ailing Java 
> scripting engine. I'm just now getting an idea of what I'm in for.

[snip]

Damn... It's hard for me to believe that it's been more than a year
since I started on this--before getting sidetracked with creating the
stand-alone player and replacing the parsers.

I have resurrected this work and put it in svn. It can be found at

        <http://openvrml.svn.sourceforge.net/svnroot/openvrml/branches/script-modules>

I'm pressing forward with bringing the Script node Java stuff online.

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

Re: [openvrml-develop] Is openvrml still developed?

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

On Sun, 2008-01-06 at 20:08 +0100, Dirk wrote:
> Hello,
> 
> I tried to compile openvrml for Linux but deleted everything when it
> required me to install udev and hal (which is obviously more a bug than
>  a dependency, right?).

OpenVRML doesn't directly depend on either of those things. It is
conceivable that they are indirect dependencies; but the particulars of
that are going to be distribution specific. You'll need to do a bit more
investigating to see exactly why these are being pulled in.

And, yes, OpenVRML is under pretty active development. There was a
fairly major release last month and a minor one yesterday.

> So, as there is practically no plugin for VRML or X3D available and
> people, desperately, start to write VRML players in flash
> http://www.opensourcery.net/x3d/ , I'd like to know if it makes sence to
> wait further for VRML (more than 10 years have already passed) or if
> web3d is dead?
> 
> VRML is even worse than Duke Nukem Forever :D

I don't think it makes sense to wait for anything. Either assist with
making the things you want happen, or move on to something else.

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

[openvrml-develop] Is openvrml still developed?

[Dirk <no...@gm...>]

Hello,

I tried to compile openvrml for Linux but deleted everything when it
required me to install udev and hal (which is obviously more a bug than
 a dependency, right?).

So, as there is practically no plugin for VRML or X3D available and
people, desperately, start to write VRML players in flash
http://www.opensourcery.net/x3d/ , I'd like to know if it makes sence to
wait further for VRML (more than 10 years have already passed) or if
web3d is dead?

VRML is even worse than Duke Nukem Forever :D


Dirk

[openvrml-develop] ANN: OpenVRML 0.17.1

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

OpenVRML 0.17.1 is now available.  The distribution can be obtained
from

  <http://downloads.sourceforge.net/openvrml/openvrml-0.17.1.tar.gz>

OpenVRML is a C++ runtime library for VRML97 and X3D worlds.  It is
capable of reading and displaying VRML/X3D; it can be used for creating
loaders, file converters, and VRML/X3D browsers.

OpenVRML includes an out-of-process viewer component for use in X11
environments along with hosts for this component in the form of a
Mozilla browser plug-in and a stand-alone player.

You can find OpenVRML on the Web at

  <http://openvrml.org>


New in OpenVRML 0.17.1:

- Fixed a crash when parsing Script nodes with eventIns or eventOuts
  declared.

- Fixed a problem compiling with gcc 4.2 and later.

[openvrml-develop] Subversion migration complete

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

It took me longer than I'd hoped to get cvs2svn to do what I want; but I
think I've finally got something satisfactory.

At the root of the repository are

        /branches
        /tags
        /trunk
        /htdocs

"trunk" is the openvrml package (and what most svn users will want to
check out); "branches" and "tags" are what you'd expect them to be.
"htdocs" is the Web site.

I have deliberately not imported any of the *lookat projects. These have
not seen development activity for some years now. In the (extremely
unlikely) event that someone wants to pick one of them up, I think it is
appropriate that further development continue outside the OpenVRML
SourceForge project.

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

[openvrml-develop] Toward 0.18...

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

With 0.17.0 finally out, here are a few notes regarding where I'll be
expending energy next...

      * Factoring platform-independent parts of openvrml-xembed into a
        helper library. The idea is to make the stream handling code
        accessible to non-X11 front-ends which may require this code to
        run in-process. In other words, lay the groundwork for porting
        the player/plug-in to other platforms. This work is likely to
        appear in 0.17.x releases. As a first step toward this
        refactoring, I'm investigating using D-Bus for openvrml-xembed's
        IPC.
      * Modularization. This is a huge, multifaceted task; it's the
        meat-and-potatoes of 0.18. It will start with moving the
        scripting engines into modules (hopefully coupled with the
        resurrection of the Java scripting engine) and finish with
        moving the node implementations into modules accompanied by XML
        descriptors. I expect code reorganization associated with these
        changes to alleviate some of OpenVRML's longstanding issues with
        compile times (and related compiler memory growth).
      * Support for model/x3d+xml. It's entirely possible--perhaps
        likely--that this is something that will get pushed to 0.19; but
        for now I'll optimistically schedule it for 0.18. The XML
        descriptors associated with the modularization work will require
        an XML parser; and depending on one of those puts model/x3d+xml
        support easily within reach. Whether this makes the cut for 0.18
        will depend on whether I feel like that release can be held for
        it once the modularization work is done.

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

[openvrml-develop] ANN: OpenVRML 0.17.0

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

OpenVRML 0.17.0 is now available.  The distribution can be obtained
from

  <http://downloads.sourceforge.net/openvrml/openvrml-0.17.0.tar.gz>

OpenVRML is a C++ runtime library for VRML97 and X3D worlds.  It is
capable of reading and displaying VRML/X3D; it can be used for creating
loaders, file converters, and VRML/X3D browsers.

OpenVRML includes an out-of-process viewer component for use in X11
environments along with hosts for this component in the form of a
Mozilla browser plug-in and a stand-alone player.

You can find OpenVRML on the Web at

  <http://openvrml.org>


New in OpenVRML 0.17.0:

- New parsers using Spirit, including a new parsing interface that
  accommodates hooking user code directly into the parsing process.

- OpenVRML no longer uses ANTLR for parsing.

- Numerous concurrency improvements and other bug fixes.

[openvrml-develop] LGPL/GPL v3

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

The forthcoming release of OpenVRML, 0.17.0, will be placed under the
terms of version 3 of the LGPL and GPL licenses.

The breakdown of how these licenses are applied to the different parts
of OpenVRML will not change: libopenvrml and libopenvrml-gl will remain
available under the LGPL, while openvrml-xembed, openvrml-player, the
Mozilla plug-in, and the example programs remain available under the
GPL.

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

[openvrml-develop] Visual C++ 9.0 project files added; Visual C++ 8.0 project files EOL

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

I've added Visual C++ 9.0 project files (and attendant source code
changes) to the trunk in CVS.

Since the Boost build system does not know about this compiler and is
not smart enough to Just Work with a new compiler version, I have built
OpenVRML with this compiler using the release branch from Boost's svn
repository that will become 1.35. Anyone wishing to build OpenVRML with
this compiler may find it convenient to do the same.

Unless someone would like to take over maintenance of the Visual C++ 8.0
project files, they will be going away prior to the 0.17.0 release.

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

[openvrml-develop] Spirit parser work nearing completion

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

As of my most recent checkin to the OpenVRML-Spirit-BRANCH, I think the
Spirit-based parsers are as good as or better than the ANTLR-based ones.
That is, as far as correctness is concerned, anyway. The Spirit-based
parsers are slower. I think it will be possible to improve their
performance; however, I am inclined to defer such optimizations until
after 0.17.0 is released.

I suspect my next checkin to the branch will remove all the ANTLR stuff
(which is presently just #ifdef'd out), after which I'll proceed to
merge this stuff onto the trunk.

Once that's done, the only thing I consider blocking the 0.17.0 release
is bug 1718762 (USE'd instances are not rendered on Windows).

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

Re: [openvrml-develop] Browser. Waiting for the parsing completion.

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

Jessica wrote:
> Could you tell me please, how could I understand that the document is loaded and parsed correctly or an error has occured after browser object initialization and calling "load_uri"?
> 
> vrmlBrowser browser(out, err);
> 
> std::vector< std::string > uri(1, fileName);
> std::vector< std::string > parameter;
> browser.load_url(uri, parameter);
> 
> //.... ???
> 
> // using browser

Using browser:load_url, the only way to see if an error occurred would 
be to inspect the error stream.

What you probably want to do is use browser::set_world instead. Unlike 
load_url, set_world blocks; and set_world throws an exception if it fails.

> Is it possible to make parser to continue parsing ignoring occuring errors?

It is not.

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

[openvrml-develop] Browser. Waiting for the parsing completion.

[Jessica <jw...@ma...>]

Could you tell me please, how could I understand that the document is loaded and parsed correctly or an error has occured after browser object initialization and calling "load_uri"?

vrmlBrowser browser(out, err);

std::vector< std::string > uri(1, fileName);
std::vector< std::string > parameter;
browser.load_url(uri, parameter);

//.... ???

// using browser


Is it possible to make parser to continue parsing ignoring occuring errors?

[openvrml-develop] ANN: OpenVRML 0.16.7

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

OpenVRML 0.16.7 is now available.  The distribution can be obtained
from

  <http://downloads.sourceforge.net/openvrml/openvrml-0.16.7.tar.gz>

OpenVRML is a C++ runtime library for VRML97 and X3D worlds.  It is
capable of reading and displaying VRML/X3D; it can be used for creating
loaders, file converters, and VRML/X3D browsers.

OpenVRML includes an out-of-process viewer component for use in X11
environments along with hosts for this component in the form of a
Mozilla browser plug-in and a stand-alone player.

You can find OpenVRML on the Web at

  <http://openvrml.org>


New in OpenVRML 0.16.7:

- Fixed crash when failing to resolve a URI for a image.

- Fixed bug in the uri copy constructor that caused optimized builds
  using the Microsoft compiler to crash.

- Updates to compile with Visual C++ Express and the Windows SDK.

- Look for pkg-config metadata provided by XULRunner.

- Various resiliency improvements to configure tests.