Menu
▾
▴
openvrml-develop — OpenVRML developers mailing list
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(25) |
Dec
(46) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(3) |
Feb
(23) |
Mar
(6) |
Apr
(15) |
May
(16) |
Jun
(24) |
Jul
(16) |
Aug
(92) |
Sep
(31) |
Oct
(40) |
Nov
(24) |
Dec
(32) |
| 2002 |
Jan
(22) |
Feb
(4) |
Mar
(38) |
Apr
(52) |
May
(38) |
Jun
(61) |
Jul
(44) |
Aug
(9) |
Sep
(15) |
Oct
(13) |
Nov
(34) |
Dec
(25) |
| 2003 |
Jan
(26) |
Feb
(10) |
Mar
(10) |
Apr
(5) |
May
(30) |
Jun
|
Jul
(2) |
Aug
(22) |
Sep
(29) |
Oct
(12) |
Nov
(18) |
Dec
(14) |
| 2004 |
Jan
(18) |
Feb
(23) |
Mar
(17) |
Apr
(17) |
May
(9) |
Jun
(10) |
Jul
(1) |
Aug
|
Sep
|
Oct
(4) |
Nov
(9) |
Dec
(29) |
| 2005 |
Jan
(37) |
Feb
(24) |
Mar
(6) |
Apr
(4) |
May
(2) |
Jun
(18) |
Jul
(3) |
Aug
(14) |
Sep
(6) |
Oct
(7) |
Nov
(25) |
Dec
(21) |
| 2006 |
Jan
(21) |
Feb
(17) |
Mar
|
Apr
(8) |
May
|
Jun
|
Jul
|
Aug
(13) |
Sep
(4) |
Oct
(22) |
Nov
(31) |
Dec
(19) |
| 2007 |
Jan
(10) |
Feb
(9) |
Mar
(8) |
Apr
(4) |
May
(1) |
Jun
(8) |
Jul
(13) |
Aug
(2) |
Sep
(7) |
Oct
(8) |
Nov
(3) |
Dec
(5) |
| 2008 |
Jan
(13) |
Feb
(5) |
Mar
(7) |
Apr
(13) |
May
(12) |
Jun
(8) |
Jul
(24) |
Aug
(25) |
Sep
(12) |
Oct
(16) |
Nov
(1) |
Dec
|
| 2009 |
Jan
(4) |
Feb
(13) |
Mar
(9) |
Apr
|
May
(2) |
Jun
|
Jul
(11) |
Aug
(6) |
Sep
(2) |
Oct
(15) |
Nov
(11) |
Dec
|
| 2010 |
Jan
(4) |
Feb
(11) |
Mar
(38) |
Apr
(7) |
May
(13) |
Jun
(4) |
Jul
(17) |
Aug
(1) |
Sep
(13) |
Oct
(10) |
Nov
(4) |
Dec
|
| 2011 |
Jan
(6) |
Feb
(1) |
Mar
|
Apr
(6) |
May
(8) |
Jun
(2) |
Jul
(10) |
Aug
(2) |
Sep
|
Oct
|
Nov
(2) |
Dec
(1) |
| 2012 |
Jan
(3) |
Feb
(1) |
Mar
(2) |
Apr
(2) |
May
(7) |
Jun
(8) |
Jul
(1) |
Aug
|
Sep
(5) |
Oct
(1) |
Nov
|
Dec
|
| 2013 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(2) |
Sep
(3) |
Oct
(4) |
Nov
(3) |
Dec
|
|
From: Raphael S. <ra...@ir...> - 2009-02-06 12:35:01
|
Frank J. R. Hanstick wrote: > Hello, > I am trying to build openvrml-0.17.10 on a PowerPC Mac running MacOS > 10.4.11 and encountered the following error: > [...] > libopenvrml-gl/openvrml/gl/viewer.cpp:2054: error: invalid conversion > from 'GLvoid (*)()' to 'GLvoid (*)(...)' > libopenvrml-gl/openvrml/gl/viewer.cpp:2054: error: initializing > argument 3 of 'void gluTessCallback(GLUtesselator*, GLenum, GLvoid (*) > (...))' [...] > Any assistance will be appreciated. This is a known problem on Mac OS X 10.4, see <http://trac.macports.org/ticket/16981 >. I'm going to submit a new OpenVRML port to MacPorts as soon as OpenVRML 0.17.11 is released. Regards, Raphael -- Raphael Straub E-Mail: ra...@ir... Universität Karlsruhe Tel. : +49 721 608-4383 Institut für Betriebs- und Dialogsysteme Fax : +49 721 608-8330 Am Fasanengarten 5, 76128 Karlsruhe Geb. 50.34, Raum 127 |
|
From: Frank J. R. H. <tr...@co...> - 2009-02-06 11:22:37
|
Hello, I am trying to build openvrml-0.17.10 on a PowerPC Mac running MacOS 10.4.11 and encountered the following error: make[3]: Entering directory `/Users/frank/FirefoxDownloads/ openvrml-0.17.10/src' /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -I../src/libopenvrml -I../src/libopenvrml -I../src/libopenvrml- gl -I../src/libopenvrml-gl -I/usr/local/spidermonkey/include/ -I/ Users/frank/FirefoxDownloads/xulrunner-sdk/sdk/include/ -DXP_UNIX -I/ usr/X11R6/include -D_THREAD_SAFE -g -O2 -MT libopenvrml-gl/openvrml/ gl/libopenvrml_gl_libopenvrml_gl_la-viewer.lo -MD -MP -MF libopenvrml- gl/openvrml/gl/.deps/libopenvrml_gl_libopenvrml_gl_la-viewer.Tpo -c - o libopenvrml-gl/openvrml/gl/libopenvrml_gl_libopenvrml_gl_la- viewer.lo `test -f 'libopenvrml-gl/openvrml/gl/viewer.cpp' || echo './'`libopenvrml-gl/openvrml/gl/viewer.cpp g++ -DHAVE_CONFIG_H -I. -I.. -I../src/libopenvrml -I../src/ libopenvrml -I../src/libopenvrml-gl -I../src/libopenvrml-gl -I/usr/ local/spidermonkey/include/ -I/Users/frank/FirefoxDownloads/xulrunner- sdk/sdk/include/ -DXP_UNIX -I/usr/X11R6/include -D_THREAD_SAFE -g -O2 -MT libopenvrml-gl/openvrml/gl/libopenvrml_gl_libopenvrml_gl_la- viewer.lo -MD -MP -MF libopenvrml-gl/openvrml/gl/.deps/ libopenvrml_gl_libopenvrml_gl_la-viewer.Tpo -c libopenvrml-gl/ openvrml/gl/viewer.cpp -fno-common -DPIC -o libopenvrml-gl/openvrml/ gl/.libs/libopenvrml_gl_libopenvrml_gl_la-viewer.o libopenvrml-gl/openvrml/gl/viewer.cpp: In function 'void<unnamed>::insertExtrusionCaps(GLUtesselator&, unsigned int, size_t, const std::vector<openvrml::vec3f, std::allocator<openvrml::vec3f> >&, const std::vector<openvrml::vec2f, std::allocator<openvrml::vec2f> >&)': libopenvrml-gl/openvrml/gl/viewer.cpp:2054: error: invalid conversion from 'GLvoid (*)()' to 'GLvoid (*)(...)' libopenvrml-gl/openvrml/gl/viewer.cpp:2054: error: initializing argument 3 of 'void gluTessCallback(GLUtesselator*, GLenum, GLvoid (*) (...))' libopenvrml-gl/openvrml/gl/viewer.cpp:2056: error: invalid conversion from 'GLvoid (*)()' to 'GLvoid (*)(...)' libopenvrml-gl/openvrml/gl/viewer.cpp:2056: error: initializing argument 3 of 'void gluTessCallback(GLUtesselator*, GLenum, GLvoid (*) (...))' libopenvrml-gl/openvrml/gl/viewer.cpp:2058: error: invalid conversion from 'GLvoid (*)()' to 'GLvoid (*)(...)' libopenvrml-gl/openvrml/gl/viewer.cpp:2058: error: initializing argument 3 of 'void gluTessCallback(GLUtesselator*, GLenum, GLvoid (*) (...))' libopenvrml-gl/openvrml/gl/viewer.cpp: In function 'void<unnamed>::insertShellTess(GLUtesselator&, const std::vector<<unnamed>::vertex_data, std::allocator<<unnamed>::vertex_data> >&, const std::vector<openvrml::int32, std::allocator<openvrml::int32> >&, bool, const std::vector<openvrml::color, std::allocator<openvrml::color> >&, const std::vector<openvrml::int32, std::allocator<openvrml::int32> >&, bool, const std::vector<openvrml::vec3f, std::allocator<openvrml::vec3f> >&, const std::vector<openvrml::int32, std::allocator<openvrml::int32> >&)': libopenvrml-gl/openvrml/gl/viewer.cpp:2906: error: invalid conversion from 'GLvoid (*)()' to 'GLvoid (*)(...)' libopenvrml-gl/openvrml/gl/viewer.cpp:2906: error: initializing argument 3 of 'void gluTessCallback(GLUtesselator*, GLenum, GLvoid (*) (...))' libopenvrml-gl/openvrml/gl/viewer.cpp:2909: error: invalid conversion from 'GLvoid (*)()' to 'GLvoid (*)(...)' libopenvrml-gl/openvrml/gl/viewer.cpp:2909: error: initializing argument 3 of 'void gluTessCallback(GLUtesselator*, GLenum, GLvoid (*) (...))' libopenvrml-gl/openvrml/gl/viewer.cpp:2912: error: invalid conversion from 'GLvoid (*)()' to 'GLvoid (*)(...)' libopenvrml-gl/openvrml/gl/viewer.cpp:2912: error: initializing argument 3 of 'void gluTessCallback(GLUtesselator*, GLenum, GLvoid (*) (...))' libopenvrml-gl/openvrml/gl/viewer.cpp:2915: error: invalid conversion from 'GLvoid (*)()' to 'GLvoid (*)(...)' libopenvrml-gl/openvrml/gl/viewer.cpp:2915: error: initializing argument 3 of 'void gluTessCallback(GLUtesselator*, GLenum, GLvoid (*) (...))' libopenvrml-gl/openvrml/gl/viewer.cpp:2917: error: invalid conversion from 'GLvoid (*)()' to 'GLvoid (*)(...)' libopenvrml-gl/openvrml/gl/viewer.cpp:2917: error: initializing argument 3 of 'void gluTessCallback(GLUtesselator*, GLenum, GLvoid (*) (...))' make[3]: *** [libopenvrml-gl/openvrml/gl/ libopenvrml_gl_libopenvrml_gl_la-viewer.lo] Error 1 make[3]: Leaving directory `/Users/frank/FirefoxDownloads/ openvrml-0.17.10/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/Users/frank/FirefoxDownloads/ openvrml-0.17.10/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/Users/frank/FirefoxDownloads/ openvrml-0.17.10' make: *** [all] Error 2 The command to configure openvrml was: ./configure BOOST_LIB_SUFFIX="-xgcc40-mt" LDFLAGS=-L/usr/local/ spidermonkey/lib/ CPPFLAGS=-I"/usr/local/spidermonkey/include/ -I/ Users/frank/FirefoxDownloads/xulrunner-sdk/sdk/include/ -DXP_UNIX" PKG_CONFIG_PATH="/opt/local/lib/pkgconfig/:/usr/local/lib/pkgconfig:/ sw/lib/pkgconfig" --with-libjs Any assistance will be appreciated. Frank J. R. Hanstick tr...@co... |
|
From: Braden M. <br...@en...> - 2009-01-22 07:14:46
|
On Wed, 2009-01-21 at 21:02 -0600, Richard Langly wrote: > Hi, > > I'm trying to learn openvrml and I've managed to build and install it. So > then I try to run openvrml-player and the gui opens up. Then I try to select > a *.wrl file and I get the following error on the console after it crashes. > > $ openvrml-player & > [1] 6069 > ** (openvrml-player:6069): CRITICAL **: Browser creation failed: Launch > helper exited with unknown return code 127 > ** > ** ERROR:(openvrml-player/curlbrowserhost.cpp:345):void > openvrml_player_curl_browser_host_load_url(OpenvrmlPlayerCurlBrowserHost*, > const char*): assertion failed: (host->priv->browser) > > > Anyone have ideas why this is? If openvrml-xembed (which runs as a D-Bus service) isn't installed where D-Bus knows about it, it won't get started on demand. You can start it manually before you start openvrml-player. -- Braden McDaniel e-mail: <br...@en...> <http://endoframe.com> Jabber: <br...@ja...> |
|
From: Richard L. <ric...@gm...> - 2009-01-22 03:02:49
|
Hi, I'm trying to learn openvrml and I've managed to build and install it. So then I try to run openvrml-player and the gui opens up. Then I try to select a *.wrl file and I get the following error on the console after it crashes. $ openvrml-player & [1] 6069 ** (openvrml-player:6069): CRITICAL **: Browser creation failed: Launch helper exited with unknown return code 127 ** ** ERROR:(openvrml-player/curlbrowserhost.cpp:345):void openvrml_player_curl_browser_host_load_url(OpenvrmlPlayerCurlBrowserHost*, const char*): assertion failed: (host->priv->browser) Anyone have ideas why this is? |
|
From: Braden M. <br...@en...> - 2009-01-13 02:20:37
|
On Mon, 2009-01-12 at 14:52 -0800, Vinay Kotamraju wrote: > Hi, > > Can anybody please confirm if there is a 64-bit (Windows Visual C++) version > of the OpenVRML C++ library ? I don't distribute binaries. But I've built OpenVRML on x86_64 Linux and 32-bit Windows; so I doubt that making it build for 64-bit Windows will be very much work. -- Braden McDaniel e-mail: <br...@en...> <http://endoframe.com> Jabber: <br...@ja...> |
|
From: Vinay K. <vin...@gm...> - 2009-01-12 22:54:34
|
Hi, Can anybody please confirm if there is a 64-bit (Windows Visual C++) version of the OpenVRML C++ library ? Thanks ! |
|
From: Braden M. <br...@en...> - 2008-11-22 05:20:11
|
I've merged the last leg of the node-modules work onto the trunk. This
moves the concrete node implementations into various dlopen'd shared
libraries (or LoadLibrary-opened DLLs on Windows).
This reduces libopenvrml to the core runtime that it should be. It also
improves the runtime's extensibility and provides a clearer path for
extending OpenVRML with new nodes.
If you're using the trunk, you now need to define another environment
variable when running from the build directories so that libopenvrml
knows where to find the node implementations:
OPENVRML_NODE_PATH=/path/to/builddir/src/node
--
Braden McDaniel e-mail: <br...@en...>
<http://endoframe.com> Jabber: <br...@ja...>
|
|
From: Braden M. <br...@en...> - 2008-10-30 18:06:13
|
On Thu, 2008-10-30 at 14:56 +0100, Raphael Straub wrote: > Hi, > > I'm trying to create an OpenVRML port for Macports and have > encountered some problems. > > The port (see <http://trac.macports.org/ticket/16981>) compiles on Mac > OS X 10.5.5, but not on 10.4.11 (which I don't have). As you can see > from the MacPorts ticket, there are some problems with the detection > of the GLU tesselator callback function type in the configure script. > The config.log on 10.5.5 shows the same error as on 10.4.11, but here > it has no negative effect because 10.5 does not have a varargs argument. Okay, I'm following up to the ticket for this one. > Another problem is openvrml-player (OpenVRML 0.17.10 on Mac OS X > 10.5.5). When I start openvrml-player, I sometimes get the following > error: > > ** (openvrml-player:1316): CRITICAL **: Browser creation failed: Did > not receive a reply. Possible causes include: the remote application > did not send a reply, the message bus security policy blocked the > reply, the reply timeout expired, or the network connection was broken. > > When I try to load a VRML file I get > > ERROR:openvrml-player/curlbrowserhost.cpp:345:void > openvrml_player_curl_browser_host_load_url > (OpenvrmlPlayerCurlBrowserHost*, const char*): assertion failed: (host- > >priv->browser) > > and the player terminates. I have to note that this is with an LDAP > user with an NFS mounted home directory. Local users don't have this > problem. I have a report of this on Linux, too; though I don't know whether a network login in involved. I don't know what the problem is; but I'll see if anyone on the D-Bus mailing list can give me a clue. -- Braden McDaniel e-mail: <br...@en...> <http://endoframe.com> Jabber: <br...@ja...> |
|
From: Raphael S. <ra...@ir...> - 2008-10-30 14:11:45
|
Raphael Straub wrote: > Another problem is openvrml-player (OpenVRML 0.17.10 on Mac OS X > 10.5.5). When I start openvrml-player, I sometimes get the following > error: > [...] Sorry, I have to correct that. I _always_ get this error when I'm a network user. Regards, Raphael -- Raphael Straub E-Mail: ra...@ir... Universität Karlsruhe Tel. : +49 721 608-4383 Institut für Betriebs- und Dialogsysteme Fax : +49 721 608-8330 Am Fasanengarten 5, 76128 Karlsruhe Geb. 50.34, Raum 127 |
|
From: Raphael S. <ra...@ir...> - 2008-10-30 13:56:13
|
Hi, I'm trying to create an OpenVRML port for Macports and have encountered some problems. The port (see <http://trac.macports.org/ticket/16981>) compiles on Mac OS X 10.5.5, but not on 10.4.11 (which I don't have). As you can see from the MacPorts ticket, there are some problems with the detection of the GLU tesselator callback function type in the configure script. The config.log on 10.5.5 shows the same error as on 10.4.11, but here it has no negative effect because 10.5 does not have a varargs argument. Another problem is openvrml-player (OpenVRML 0.17.10 on Mac OS X 10.5.5). When I start openvrml-player, I sometimes get the following error: ** (openvrml-player:1316): CRITICAL **: Browser creation failed: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. When I try to load a VRML file I get ERROR:openvrml-player/curlbrowserhost.cpp:345:void openvrml_player_curl_browser_host_load_url (OpenvrmlPlayerCurlBrowserHost*, const char*): assertion failed: (host- >priv->browser) and the player terminates. I have to note that this is with an LDAP user with an NFS mounted home directory. Local users don't have this problem. Does anybody have an idea what's going wrong here? Regards, Raphael -- Raphael Straub E-Mail: ra...@ir... Universität Karlsruhe Tel. : +49 721 608-4383 Institut für Betriebs- und Dialogsysteme Fax : +49 721 608-8330 Am Fasanengarten 5, 76128 Karlsruhe Geb. 50.34, Raum 127 |
|
From: Braden M. <br...@en...> - 2008-10-26 19:19:21
|
OpenVRML 0.17.10 is now available. The distribution can be obtained from <http://downloads.sourceforge.net/openvrml/openvrml-0.17.10.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.10: - Fixed 32-/64-bit parity and stream handling bugs in openvrml-xembed. |
|
From: Braden M. <br...@en...> - 2008-10-22 03:35:51
|
On Mon, 2008-10-20 at 11:09 +0400, Irina wrote: > I expected that Viewpoint will be applied to all objects Transform as a whole, but such effect can achieve only having concluded all Transform in a certain group element of top level. I do not understand how viewpoint works in the next example. Could you explain a viewpoint action principle? Your understanding is correct; OpenVRML is doing something wrong here. Can you please file a bug in the SourceForge tracker (and attach this example)? I'll have a look at this as soon as I can; but I'm pretty busy with other things at the moment. -- Braden McDaniel e-mail: <br...@en...> <http://endoframe.com> Jabber: <br...@ja...> |
|
From: Braden M. <br...@en...> - 2008-10-22 02:10:29
|
On Tue, 2008-10-21 at 13:16 -0400, Patrick Shinpaugh wrote: > When building 0.17.9 on CentOS 5.1 I get errors (see below). Any ideas? I can only guess that your version of D-Bus is too old; what do you you have there? I have 1.2.4 here. > Also, is there an archive of older versions (only 0.17.9 is on sf.net). All older releases are on SourceForge. You need to click on the link to view all files for the package (or something like that). -- Braden McDaniel e-mail: <br...@en...> <http://endoframe.com> Jabber: <br...@ja...> |
|
From: Patrick S. <shp...@vt...> - 2008-10-21 17:17:03
|
When building 0.17.9 on CentOS 5.1 I get errors (see below). Any ideas? Also, is there an archive of older versions (only 0.17.9 is on sf.net). Thanks, Pat g++ -DHAVE_CONFIG_H -I. -I.. -DG_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DGNOME_DISABLE_DEPRECATED -DOPENVRML_PLAYER_PKGDATADIR_=\"/usr/local/share/openvrml-player\" -DOPENVRML_LIBEXECDIR_=\"/usr/local/libexec\" -Iopenvrml-player -Ilibopenvrml -I./libopenvrml -DXP_UNIX -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -DORBIT2=1 -pthread -I/usr/include/libgnomeui-2.0 -I/usr/include/libgnome-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libart-2.0 -I/usr/include/gconf/2 -I/usr/include/libbonoboui-2.0 -I/usr/include/gnome-vfs-2.0 -I/usr/lib64/gnome-vfs-2.0/include -I/usr/include/gnome-keyring-1 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/bonobo-activation-2.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/libpng12 -I/usr/include/libxml2 -I/usr/include/libglade-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libxml2 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -g -O2 -MT openvrml-player/openvrml_player_openvrml_player-curlbrowserhost.o -MD -MP -MF openvrml-player/.deps/openvrml_player_openvrml_player-curlbrowserhost.Tpo -c -o openvrml-player/openvrml_player_openvrml_player-curlbrowserhost.o `test -f 'openvrml-player/curlbrowserhost.cpp' || echo './'`openvrml-player/curlbrowserhost.cpp /usr/include/dbus-1.0/dbus/dbus-glib-bindings.h: In function ‘void org_freedesktop_DBus_Introspectable_introspect_async_callback(DBusGProxy*, DBusGProxyCall*, void*)’: /usr/include/dbus-1.0/dbus/dbus-glib-bindings.h:28: error: invalid conversion from ‘void*’ to ‘DBusGAsyncData*’ /usr/include/dbus-1.0/dbus/dbus-glib-bindings.h: In function ‘void org_freedesktop_DBus_request_name_async_callback(DBusGProxy*, DBusGProxyCall*, void*)’: /usr/include/dbus-1.0/dbus/dbus-glib-bindings.h:71: error: invalid conversion from ‘void*’ to ‘DBusGAsyncData*’ /usr/include/dbus-1.0/dbus/dbus-glib-bindings.h: In function ‘void org_freedesktop_DBus_release_name_async_callback(DBusGProxy*, DBusGProxyCall*, void*)’: /usr/include/dbus-1.0/dbus/dbus-glib-bindings.h:109: error: invalid conversion from ‘void*’ to ‘DBusGAsyncData*’ /usr/include/dbus-1.0/dbus/dbus-glib-bindings.h: In function ‘void org_freedesktop_DBus_start_service_by_name_async_callback(DBusGProxy*, DBusGProxyCall*, void*)’: /usr/include/dbus-1.0/dbus/dbus-glib-bindings.h:147: error: invalid conversion from ‘void*’ to ‘DBusGAsyncData*’ /usr/include/dbus-1.0/dbus/dbus-glib-bindings.h: In function ‘void org_freedesktop_DBus_hello_async_callback(DBusGProxy*, DBusGProxyCall*, void*)’: /usr/include/dbus-1.0/dbus/dbus-glib-bindings.h:185: error: invalid conversion from ‘void*’ to ‘DBusGAsyncData*’ /usr/include/dbus-1.0/dbus/dbus-glib-bindings.h: In function ‘void org_freedesktop_DBus_name_has_owner_async_callback(DBusGProxy*, DBusGProxyCall*, void*)’: /usr/include/dbus-1.0/dbus/dbus-glib-bindings.h:223: error: invalid conversion from ‘void*’ to ‘DBusGAsyncData*’ /usr/include/dbus-1.0/dbus/dbus-glib-bindings.h: In function ‘void org_freedesktop_DBus_list_names_async_callback(DBusGProxy*, DBusGProxyCall*, void*)’: /usr/include/dbus-1.0/dbus/dbus-glib-bindings.h:261: error: invalid conversion from ‘void*’ to ‘DBusGAsyncData*’ /usr/include/dbus-1.0/dbus/dbus-glib-bindings.h: In function ‘void org_freedesktop_DBus_add_match_async_callback(DBusGProxy*, DBusGProxyCall*, void*)’: /usr/include/dbus-1.0/dbus/dbus-glib-bindings.h:299: error: invalid conversion from ‘void*’ to ‘DBusGAsyncData*’ /usr/include/dbus-1.0/dbus/dbus-glib-bindings.h: In function ‘void org_freedesktop_DBus_remove_match_async_callback(DBusGProxy*, DBusGProxyCall*, void*)’: /usr/include/dbus-1.0/dbus/dbus-glib-bindings.h:336: error: invalid conversion from ‘void*’ to ‘DBusGAsyncData*’ /usr/include/dbus-1.0/dbus/dbus-glib-bindings.h: In function ‘void org_freedesktop_DBus_get_name_owner_async_callback(DBusGProxy*, DBusGProxyCall*, void*)’: /usr/include/dbus-1.0/dbus/dbus-glib-bindings.h:373: error: invalid conversion from ‘void*’ to ‘DBusGAsyncData*’ /usr/include/dbus-1.0/dbus/dbus-glib-bindings.h: In function ‘void org_freedesktop_DBus_list_queued_owners_async_callback(DBusGProxy*, DBusGProxyCall*, void*)’: /usr/include/dbus-1.0/dbus/dbus-glib-bindings.h:411: error: invalid conversion from ‘void*’ to ‘DBusGAsyncData*’ /usr/include/dbus-1.0/dbus/dbus-glib-bindings.h: In function ‘void org_freedesktop_DBus_get_connection_unix_user_async_callback(DBusGProxy*, DBusGProxyCall*, void*)’: /usr/include/dbus-1.0/dbus/dbus-glib-bindings.h:449: error: invalid conversion from ‘void*’ to ‘DBusGAsyncData*’ /usr/include/dbus-1.0/dbus/dbus-glib-bindings.h: In function ‘void org_freedesktop_DBus_get_connection_unix_process_id_async_callback(DBusGProxy*, DBusGProxyCall*, void*)’: /usr/include/dbus-1.0/dbus/dbus-glib-bindings.h:487: error: invalid conversion from ‘void*’ to ‘DBusGAsyncData*’ /usr/include/dbus-1.0/dbus/dbus-glib-bindings.h: In function ‘void org_freedesktop_DBus_get_connection_se_linux_security_context_async_callback(DBusGProxy*, DBusGProxyCall*, void*)’: /usr/include/dbus-1.0/dbus/dbus-glib-bindings.h:525: error: invalid conversion from ‘void*’ to ‘DBusGAsyncData*’ /usr/include/dbus-1.0/dbus/dbus-glib-bindings.h: In function ‘void org_freedesktop_DBus_reload_config_async_callback(DBusGProxy*, DBusGProxyCall*, void*)’: /usr/include/dbus-1.0/dbus/dbus-glib-bindings.h:563: error: invalid conversion from ‘void*’ to ‘DBusGAsyncData*’ make[3]: *** [openvrml-player/openvrml_player_openvrml_player-curlbrowserhost.o] Error 1 make[3]: Leaving directory `/root/install/openvrml-0.17.9/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/root/install/openvrml-0.17.9/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/install/openvrml-0.17.9' make: *** [all] Error 2 -- Patrick Shinpaugh Virginia Tech UVAG System Administrator/Programmer 540-231-2054 |
|
From: Irina <tau...@ma...> - 2008-10-20 07:09:16
|
I expected that Viewpoint will be applied to all objects Transform as a whole, but such effect can achieve only having concluded all Transform in a certain group element of top level. I do not understand how viewpoint works in the next example. Could you explain a viewpoint action principle?
#VRML V2.0 utf8
DEF v1 Viewpoint
{
position 15, 15, 100
fieldOfView 0.5
orientation 0 0 1 -1.6
}
#DEF gg Group{
# children[
Transform{
translation 10 10 10
children[
DEF TS1 TouchSensor {}
DEF Shape1 Shape
{
appearance Appearance
{
material DEF M1 Material {
emissiveColor 0.8 0 0
transparency 0.5
}
}
geometry Sphere {}
}
]
}
Transform{
translation 11 11 10
children[
DEF TS2 TouchSensor {}
DEF Shape2 Shape
{
appearance Appearance
{
material DEF M2 Material {
emissiveColor 0 0 0.9
transparency 0.7
}
}
geometry Sphere {}
}
]
}
# ]
#}
|
|
From: Braden M. <br...@en...> - 2008-10-09 17:26:52
|
OpenVRML 0.17.9 is now available. The distribution can be obtained from <http://downloads.sourceforge.net/openvrml/openvrml-0.17.9.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.9: - Use D-Bus for communication with the OpenVRML XEmbed control. |
|
From: Braden M. <br...@en...> - 2008-10-09 15:52:04
|
On Thu, 2008-10-09 at 15:29 +0200, Johannes Brand wrote: > Hi, > > I also get the "The application failed to initialize property > (0xE06D7363)" error when trying to compile the OpenVRML trunk. Setting > the environment variable OPENVRML_DATADIR to openvrmldir/data didn't > help, as well. Does anybody have an idea, what could be the problem > instead? I don't know of a cause for that error other than not setting OPENVRML_DATADIR properly. Make sure you haven't mistyped the path to the data directory. > Btw: what's the meaning of the new preprocessor defines of PKGDATADIR > and PKGLIBDIR? ...I changed that, as well! They don't have much meaning on Windows. On POSIXy platforms, they refer, respectively, to the installation roots for OpenVRMLs architecture-independent data and its dynamically loaded modules. To complete the Windows story here, I need to define some registry keys that can be set by an installer for a similar purpose. -- Braden McDaniel e-mail: <br...@en...> <http://endoframe.com> Jabber: <br...@ja...> |
|
From: Johannes B. <jb...@te...> - 2008-10-09 13:29:24
|
Hi, I also get the "The application failed to initialize property (0xE06D7363)" error when trying to compile the OpenVRML trunk. Setting the environment variable OPENVRML_DATADIR to openvrmldir/data didn't help, as well. Does anybody have an idea, what could be the problem instead? Btw: what's the meaning of the new preprocessor defines of PKGDATADIR and PKGLIBDIR? ...I changed that, as well! Cheers, Johannes |
|
From: Braden M. <br...@en...> - 2008-10-09 09:29:43
|
On Thu, 2008-10-09 at 12:08 +0400, Irina wrote: > I'm getting an exeption message from mozilla when I'm trying to view vrml-model in openvrml plugin. After that I delete 'Tube10' element from vrml-model and this model loads normaly, but during rendering operation such exception catchs: > > > > *** glibc detected *** /usr/local/libexec/openvrml-xembed: corrupted double-linked list: 0x08760fc8 *** [snip] What version are you using? I've loaded your model using both the trunk and 0.17.9 and I haven't seen this. Is there anything in particular I need to do once it's loaded in order to trigger the crash? -- Braden McDaniel e-mail: <br...@en...> <http://endoframe.com> Jabber: <br...@ja...> |
|
From: Irina <tau...@ma...> - 2008-10-09 08:08:20
|
I'm getting an exeption message from mozilla when I'm trying to view vrml-model in openvrml plugin. After that I delete 'Tube10' element from vrml-model and this model loads normaly, but during rendering operation such exception catchs: *** glibc detected *** /usr/local/libexec/openvrml-xembed: corrupted double-linked list: 0x08760fc8 *** ======= Backtrace: ========= /lib/libc.so.6[0x753e537] /lib/libc.so.6(__libc_malloc+0x7b)[0x753fb7b] /usr/lib/libstdc++.so.6(_Znwj+0x27)[0x738aba7] /usr/local/lib/libopenvrml.so.8[0x1375721] /usr/local/lib/libopenvrml.so.8(_ZN8openvrml13geometry_node15render_geometryERNS_6viewerENS_17rendering_contextE+0x53)[0x10bc623] /usr/local/lib/libopenvrml.so.8[0x12fb7da] /usr/local/lib/libopenvrml.so.8(_ZN8openvrml10child_node12render_childERNS_6viewerENS_17rendering_contextE+0x3e)[0x10b603e] /usr/local/lib/libopenvrml.so.8[0x13364d1] /usr/local/lib/libopenvrml.so.8[0x1336971] /usr/local/lib/libopenvrml.so.8(_ZN8openvrml10child_node12render_childERNS_6viewerENS_17rendering_contextE+0x3e)[0x10b603e] /usr/local/lib/libopenvrml.so.8[0x13364d1] /usr/local/lib/libopenvrml.so.8[0x1336971] /usr/local/lib/libopenvrml.so.8(_ZN8openvrml10child_node12render_childERNS_6viewerENS_17rendering_contextE+0x3e)[0x10b603e] /usr/local/lib/libopenvrml.so.8[0x13364d1] /usr/local/lib/libopenvrml.so.8[0x1336971] /usr/local/lib/libopenvrml.so.8(_ZN8openvrml10child_node12render_childERNS_6viewerENS_17rendering_contextE+0x3e)[0x10b603e] /usr/local/lib/libopenvrml.so.8(_ZN8openvrml5scene6renderERNS_6viewerENS_17rendering_contextE+0x78)[0x1144b88] /usr/local/lib/libopenvrml.so.8(_ZN8openvrml7browser6renderEv+0x340)[0x114a540] /usr/local/lib/libopenvrml-gl.so.7(_ZN8openvrml2gl6viewer6redrawEv+0x197)[0x117e47] /usr/local/libexec/openvrml-xembed[0x805ac76] /usr/lib/libgtk-x11-2.0.so.0[0x3a5068] /lib/libgobject-2.0.so.0(g_closure_invoke+0x123)[0x7ecf83] /lib/libgobject-2.0.so.0[0x7fd48d] /lib/libgobject-2.0.so.0(g_signal_emit_valist+0x68f)[0x7fe75f] /lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0x7feb59] /usr/lib/libgtk-x11-2.0.so.0[0x530cb4] /usr/lib/libgtk-x11-2.0.so.0(gtk_widget_send_expose+0x14f)[0x530913] /usr/lib/libgtk-x11-2.0.so.0(gtk_main_do_event+0x2b5)[0x3a1cd5] /usr/lib/libgdk-x11-2.0.so.0[0x683ad0] /usr/lib/libgdk-x11-2.0.so.0(gdk_window_process_all_updates+0xe2)[0x683c41] /usr/lib/libgdk-x11-2.0.so.0[0x683881] /usr/lib/libgdk-x11-2.0.so.0[0x66194f] /lib/libglib-2.0.so.0[0x8e95e1] /lib/libglib-2.0.so.0(g_main_context_dispatch+0x17c)[0x8eb1ac] /lib/libglib-2.0.so.0[0x8ee5ef] /lib/libglib-2.0.so.0(g_main_loop_run+0x1a9)[0x8ee999] /usr/lib/libgtk-x11-2.0.so.0(gtk_main+0xe0)[0x3a1422] /usr/local/libexec/openvrml-xembed[0x80518f4] /lib/libc.so.6(__libc_start_main+0xe0)[0x74ea390] /usr/local/libexec/openvrml-xembed(_ZN8openvrml2gl6viewer15do_insert_shellEjRKSt6vectorINS_5vec3fESaIS3_EERKS2_IiSaIiEERKS2_INS_5colorESaISC_EESB_S7_SB_RKS2_INS_5vec2fESaISH_EESB_+0x34d)[0x804fbc1] |
|
From: Braden M. <br...@en...> - 2008-10-05 03:41:47
|
On Sat, 2008-10-04 at 15:22 -0700, Rick Knight wrote: [snip] > I'm RickKnight from the freenode openvrml channel. I posted this message > before I found the chat. I figured; so this was a little puzzling. It just recently showed up in my mailbox--I didn't notice until now that the send time was last Tuesday. I suspect the delay was related to some significant SourceForge infrastructure changes that have been happening lately. -- Braden McDaniel e-mail: <br...@en...> <http://endoframe.com> Jabber: <br...@ja...> |
|
From: Rick K. <ric...@rl...> - 2008-10-04 22:22:48
|
Braden McDaniel wrote: > On Tue, 2008-09-30 at 15:45 -0700, Rick Knight wrote: > >> I'm trying to build Openvrml-0.17.8 on Kubuntu 8.04 with kernel >> 2.6.24-21. I had to add some devel packages, lbiboost-dev, libcurl4-dev >> and mozilla-dev, but after adding those I was able to run configure >> without error, so I ran make. Make runs for a short time and then stops >> with this error... >> >> ../src/libopenvrml/openvrml/vrml97_grammar.h:430: error: >> 'percent_tolerance' was not declared in this scope >> ../src/libopenvrml/openvrml/vrml97_grammar.h:430: error: >> 'check_is_close' was not declared in this scope >> make[2]: *** >> [libopenvrml/openvrml/libopenvrml_libopenvrml_la-basetypes.lo] Error 1 >> make[2]: Leaving directory `/home/share/New Downloads/openvrml-0.17.8/src' >> make[1]: *** [all-recursive] Error 1 >> make[1]: Leaving directory `/home/share/New Downloads/openvrml-0.17.8' >> make: *** [all] Error 2 >> >> It doesn't look like I am missing anything, but I'm not a developer so... >> >> Can you tell me how to get past this error? >> > > What version of Boost are you using? 0.17.x requires at least Boost > 1.34.x. > > Braden, I'm RickKnight from the freenode openvrml channel. I posted this message before I found the chat. Rick |
|
From: Braden M. <br...@en...> - 2008-10-04 22:07:41
|
On Tue, 2008-09-30 at 15:45 -0700, Rick Knight wrote: > I'm trying to build Openvrml-0.17.8 on Kubuntu 8.04 with kernel > 2.6.24-21. I had to add some devel packages, lbiboost-dev, libcurl4-dev > and mozilla-dev, but after adding those I was able to run configure > without error, so I ran make. Make runs for a short time and then stops > with this error... > > ../src/libopenvrml/openvrml/vrml97_grammar.h:430: error: > 'percent_tolerance' was not declared in this scope > ../src/libopenvrml/openvrml/vrml97_grammar.h:430: error: > 'check_is_close' was not declared in this scope > make[2]: *** > [libopenvrml/openvrml/libopenvrml_libopenvrml_la-basetypes.lo] Error 1 > make[2]: Leaving directory `/home/share/New Downloads/openvrml-0.17.8/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/share/New Downloads/openvrml-0.17.8' > make: *** [all] Error 2 > > It doesn't look like I am missing anything, but I'm not a developer so... > > Can you tell me how to get past this error? What version of Boost are you using? 0.17.x requires at least Boost 1.34.x. -- Braden McDaniel e-mail: <br...@en...> <http://endoframe.com> Jabber: <br...@ja...> |
|
From: Rick K. <ric...@rl...> - 2008-09-30 22:45:14
|
I'm trying to build Openvrml-0.17.8 on Kubuntu 8.04 with kernel 2.6.24-21. I had to add some devel packages, lbiboost-dev, libcurl4-dev and mozilla-dev, but after adding those I was able to run configure without error, so I ran make. Make runs for a short time and then stops with this error... ../src/libopenvrml/openvrml/vrml97_grammar.h:430: error: 'percent_tolerance' was not declared in this scope ../src/libopenvrml/openvrml/vrml97_grammar.h:430: error: 'check_is_close' was not declared in this scope make[2]: *** [libopenvrml/openvrml/libopenvrml_libopenvrml_la-basetypes.lo] Error 1 make[2]: Leaving directory `/home/share/New Downloads/openvrml-0.17.8/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/share/New Downloads/openvrml-0.17.8' make: *** [all] Error 2 It doesn't look like I am missing anything, but I'm not a developer so... Can you tell me how to get past this error? Thanks, Rick Knight |
|
From: Braden M. <br...@en...> - 2008-09-27 06:20:27
|
The occurrence of a few particularly large source files in the OpenVRML
codebase has been a point of annoyance for several (potential) users
over the years.
My inclination toward files of such magnitude (~20k lines) had to do
with the fact that the only way really to hide a symbol in C++ was to
put it in an unnamed namespace, making it local to a particular
translation unit. So code that needs to share implementation code all
needs to share the same file in order to keep the non-public symbols
properly hidden. Inevitably, as code grows and matures under such a
scheme, commonalities push related implementation code together. And
sometimes there can be a *lot* of such related code.
There are a couple of significant downsides to large translation units:
* They parallelize poorly. While a single-processor machine might
process more code in fewer files somewhat faster, parallel
builds process multiple smaller files much more efficiently.
* They consume a lot of memory when compiling. gcc's memory
demands seem to have gone up significantly in recent years,
making this even more of a problem than it once was.
In the last few gcc releases, "symbol visibility" attributes have been
introduced. These allow library authors to inform the linker
specifically whether a symbol should be publicly exposed, rather than
relying on details that may or may not be implied by particular language
features. Using these attributes, it's no longer necessary to bury
implementation details in unnamed namespaces (or similar) to keep them
hidden in the compiled binary.
So I've been taking advantage of this feature to attack the problem.
The most egregious offender, vrml97node.cpp, was broken up some months
ago before I started converting openvrml-xembed to use D-Bus. More
recently I've broken up the other node implementation files and put a
significant dent in the second worst offender, browser.cpp.
I've added a namespace openvrml::local as a place to put things that
will have hidden symbols (i.e., the OPENVRML_LOCAL macro is applied),
yet need to be part of more than one translation unit. Note, though,
that the headers associated with this namespace *do not get installed*.
That means that no public headers are allowed to include them.
So far I've pared browser.cpp down to a little more than 6000 lines.
Compiling on my x86_64 Linux machine, its high-water mark in memory is
around 1.3 GB. If that sounds big, consider that before this surgery it
was taking at least 2.2 GB to compile. (And recall that for a 32-bit
platform, you can expect to cut this memory footprint roughly in half.)
I suspect that the better part of that 1.3 GB footprint has to do with
the fact that two big Spirit parsers get instantiated in browser.cpp.
Pushing these instantiations out to different translation units would
probably be a significant win; and that's something I'll probably pursue
before releasing 0.18.
--
Braden McDaniel e-mail: <br...@en...>
<http://endoframe.com> Jabber: <br...@ja...>
|
2 messages has been excluded from this view by a project administrator.
