[openvrml-develop] Openvrml Build Error

[Rick Knight <rick_knight@rl...>]

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 

[openvrml-develop] Status update: breaking up large files

[Braden McDaniel <braden@en...>]

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: <braden@...>
<http://endoframe.com>;                    Jabber: <braden@...>

Re: [openvrml-develop] Event 'startTime'

[Braden McDaniel <braden@en...>]

On Thu, 2008-09-18 at 09:36 +0400, Irina wrote:
> I wish to realise interactive model, using TouchSensors and TimeSensors. For this purpose, in the initial model containing TouchSensors, I dynamically add TimeSensors and I connect events 'touchTime' of TouchSensor and 'startTime' of TimeSensor. After a clique on TouchSensor, event 'touchTime' works, but 'startTime' doesn't.

It seemed to work for me in the example you posted yesterday. (That is,
clicking the sphere started the color change.)

Can you post an example that demonstrates the problem? Please describe
the behavior you're expecting as well as the behavior you're actually
seeing.

-- 
Braden McDaniel                           e-mail: <braden@...>
<http://endoframe.com>;                    Jabber: <braden@...>

[openvrml-develop] Event 'startTime'

[Irina <taurus11@ma...>]

I wish to realise interactive model, using TouchSensors and TimeSensors. For this purpose, in the initial model containing TouchSensors, I dynamically add TimeSensors and I connect events 'touchTime' of TouchSensor and 'startTime' of TimeSensor. After a clique on TouchSensor, event 'touchTime' works, but 'startTime' doesn't.



      

Re: [openvrml-develop] Cross post from Open scengraph list

[Braden McDaniel <braden@en...>]

John, please do not hijack threads.

On Wed, 2008-09-17 at 16:29 -0700, John F. Richardson wrote:
> Hello,
> 
> The following was posted on the Openscenegraph list.
> 
> Don't know if posting here will solve the problem but...... Ben is in the CC
> line so that people can contact him directly.
> 
> John F. Richardson
> 
> ================= begin OSG post =============
> 
> 
> I am trying to load a VRML file, but I get the error message:
> 
>  
> 
> Warning: Could not find plugin to read objects from file "foo.wrl".

I'm not familiar with the OSG code; so about all I can tell you is that
the above warning was not emitted by OpenVRML code.

That's not to suggest that I remember very much about 0.14.x did--it's
positively ancient.  But I do not remember it having plug-ins.

-- 
Braden McDaniel                           e-mail: <braden@...>
<http://endoframe.com>;                    Jabber: <braden@...>

[openvrml-develop] Cross post from Open scengraph list

[John F. Richardson <richards@sp...>]

Hello,

The following was posted on the Openscenegraph list.

Don't know if posting here will solve the problem but...... Ben is in the CC
line so that people can contact him directly.

John F. Richardson

================= begin OSG post =============


I am trying to load a VRML file, but I get the error message:

 

Warning: Could not find plugin to read objects from file "foo.wrl".

 

I tried this in OSG code, as well as with osgconv and osgviewer.  I have the
OSG lib and osgPlugins directories in my LD_LIBRARY_PATH.  

 

I compiled OSG 2.6.0 from src on Debian Etch.  I am using OpenVRML version
0.14.3.  Do I need a newer version of OpenVRML?  (I set the path to the
OpenVRML includes as well as libopenvrml.so during the CMake configuration).

 

I had VRML files working with OSG 2.4 a long time ago.  Back then I also set
up the Inventor library during the install.  But I forgot what that library
does, why it's needed, and even where to get it.  Do I need it here too?

 

Thanks,

-Ben

Re: [openvrml-develop] Fw: Problem with using ECMAScript

[Braden McDaniel <braden@en...>]

On Wed, 2008-09-17 at 09:25 +0400, Ирина wrote:
> Good afternoon,
>  
>  We've got a problem with using ECMAScript inside OpenVrml control. 
>  Listed below example shows this problem. The 'TimeSensor' node after activation has to call method 'act' and change value of field 'loop'. But it doesn't happen and no one exception is throwed. 
>  
>  So we've got a question, what is wrong in this situation?

Whenever a script directly changes the fields of a node as you're doing,
you must set "directOutput TRUE".

-- 
Braden McDaniel                           e-mail: <braden@...>
<http://endoframe.com>;                    Jabber: <braden@...>

[openvrml-develop] Fw: Problem with using ECMAScript

[Ирина <taurus11@ma...>]

 Good afternoon,
 
 We've got a problem with using ECMAScript inside OpenVrml control. 
 Listed below example shows this problem. The 'TimeSensor' node after activation has to call method 'act' and change value of field 'loop'. But it doesn't happen and no one exception is throwed. 
 
 So we've got a question, what is wrong in this situation?
 
 --------------------------------- 
 
 #VRML V2.0 utf8
 
 Group
 
 {
 
       children
 
       [
 
             DEF   ts0 TouchSensor
 
             {                 
 
             }
 
             Shape 
 
             {  
 
                appearance Appearance {
 
               material DEF m1 Material {
 
               emissiveColor 0.8 0 0
 
               transparency  0.5
 
               }
 
                }
                geometry Sphere {
 
                }
             }           
       ]
 }
 
  
 
 DEF colorInt0 ColorInterpolator { key [ 0 0.25 0.5 0.75 1 ]  keyValue [1 0 0, 0 1 0, 1 0 0, 0 1 0, 1 1 1]}  
 DEF timer0 TimeSensor { cycleInterval 1 startTime 0 loop FALSE }    
 
 DEF SCRIPT Script
 
 { 
 
       eventIn SFTime act  
 
       field SFNode timer0 USE timer0 
    
       url   "javascript:
      
       function act(active) 
 
       { 
          timer0.loop = TRUE;
       }
 
 "}
  
ROUTE ts0.touchTime TO SCRIPT.act
ROUTE colorInt0.value_changed TO m1.set_diffuseColor 
ROUTE timer0.fraction_changed TO colorInt0.set_fraction ROUTE ts0.touchTime TO timer0.set_startTime 
 
  
 
 

[openvrml-develop] trunk now uses XmlLite on Windows

[Braden McDaniel <braden@en...>]

A heads-up for anyone using the trunk on Windows... The dependency on
libxml (and iconv and winsock2) that got introduced some months ago has
been eliminated.  Instead, the Windows build now uses XmlLite.  Assuming
you've already pointed Visual C++ at a Windows SDK installation, this
should Just Work.

-- 
Braden McDaniel                           e-mail: <braden@...>
<http://endoframe.com>;                    Jabber: <braden@...>

Re: [openvrml-develop] openvrml-xembed D-Bustification in svn

[Braden McDaniel <braden@en...>]

This is now complete and committed both to the trunk and to the 0.17
branch.

-- 
Braden McDaniel                           e-mail: <braden@...>
<http://endoframe.com>;                    Jabber: <braden@...>

Re: [openvrml-develop] Parsing Speed

[Braden McDaniel <braden@en...>]

On Tue, 2008-08-26 at 12:00 -0400, Braden McDaniel wrote:
> On Tue, 2008-08-26 at 11:06 +0200, Johannes Brand wrote:
> > I tested the OpenVRML Parser for VRML97 files and it worked well, so 
> > far. Unfortunately it takes quite a long time to parse/load VRML files 
> > of sizes around 1 or 2Mb. Is it  normal  to have parsing times around 1 
> > Minute for file sizes of 2.3 MB when just using the 
> > "openvrml::null_vrml97_parse_actions" and the standard "parse" function 
> > of "pretty_print.cpp" ??
> 
> The parser does a good deal of semantic checking, so it's probably never
> going to be the fastest parsing solution possible. However, these times
> do sound excessive. Profiling the parse using input like you have
> available would be a very useful activity. Depending on where the
> problems lie, it may be possible to make some significant improvements.

For the benefit of anyone reading this and thinking, "Oh, God,
OpenVRML's parser must be a complete dog," let me provide a bit of an
epilog to this.

Frank was kind enough to share a 2.3 MB file for me to test. Running
tests/parse-vrml97 on this file executes in under 2 seconds on my
Opteron 285 box. Note that this execution time includes start-up costs
(which are nontrivial on the trunk openvrml I tested; libopenvrml now
opens and reads several small XML files as part of initialization) and
the time taken to emit several warnings to stderr. For this test, I
built openvrml using the configure-gcc-opt wrapper script in svn.

So while OpenVRML's parser is never going to be the fastest-possible
parser due to the design constraints I mention above, it seems to be no
slouch either. Regarding Frank's initial results, I think the moral of
the story is: use optimized builds when testing performance. :-)

(Sorry, Frank... But I needed to defend OpenVRML here. ;-)

-- 
Braden McDaniel                           e-mail: <braden@...>
<http://endoframe.com>;                    Jabber: <braden@...>

Re: [openvrml-develop] openvrml-xembed D-Bustification in svn

[Braden McDaniel <braden@en...>]

On Sat, 2008-08-30 at 16:02 -0400, Braden McDaniel wrote:
> On Mon, 2008-08-25 at 20:24 -0400, Braden McDaniel wrote:
> 
> [snip]
> 
> > What *isn't* working yet is the ability to have multiple control
> > instances within the openvrml-xembed process.  In other words, things
> > will probably go south quickly if you attempt to run more than one
> > openvrml-player process concurrently.  I'll be fixing this next.
> 
> With my latest check-in, this is now fixed.
> 
> There are a few minor bugs left to fix in openvrml-xembed and some code
> clean-up I'd like to do; but aside from that the only thing left to do
> here is to modify the Gecko plug-in to use the D-Busticated
> openvrml-xembed.

... And now that's done.

So this work is just about complete. There is a little more code
clean-up I want to do; but this stuff will be making its way onto the
trunk soon.

And, I think, the 0.17 branch. The main dependencies this work adds are
D-Bus (and the associated dbus-glib) and at least GTK+ 2.12. Some
non-ancient GTK+ was already required; and I think 2.12 has enough
penetration at this point to make this requirement pretty painless. (If
you think I'm wrong about that, please yell at me.)

-- 
Braden McDaniel                           e-mail: <braden@...>
<http://endoframe.com>;                    Jabber: <braden@...>