openvrml-develop — OpenVRML developers mailing list

Re: [openvrml-develop] A few Questions

[Christian L. <chr...@vd...>]

> Perhaps it was not set correctly.
>    
I think it was, because the 0.17.12 version worked fine. Could it be 
that blanks in the path are a problem?
I'll try around more tomorrow.
>> (By the way there were some minor issues, too:
>> - in some project folders (like
>> openvrml-0.18.5\ide-projects\Windows\VisualC9_0\OpenVRML\x3d-cad-geometry)
>> the *.vcproj file had an incorrect or missing file ending
>> - in openvrml-0.18.5\src\node\x3d-cad-geometry (and only there) was the
>> register_node_metatypes.cpp missing, which i got by a google query
>>      
> Whoops. :-(
>
> I suspect these two bullet points are the same problem.  (If they
> aren't, could you be more specific about what's going on with the first
> one?)
>
> I will commit a fix to ensure that this file gets distributed in 0.18.6.
>    
I was wrong about the first one: in x3d-cad-geometry the vcproj file is 
alright. But:
(in the following lines i will refer to subolders of 
openvrml-0.18.5\ide-projects\Windows\VisualC9_0\OpenVRML)

in \x3d-environmental-effects it is "x3d-environmental" instead of 
"x3d-environmental-effects.vcproj"
in \x3d-event-utilities it is "x3d-event-utilities.vcp" instead of 
"x3d-event-utilities.vcproj"
in \x3d-key-device-sensor it is "x3d-key-device-sensor" instead of 
"x3d-key-device-sensor.vcproj"

This applies to 
http://sourceforge.net/projects/openvrml/files/openvrml/0.18.5/openvrml-0.18.5.tar.gz/download

In the current svn revision the filenames are correct, as i noticed today.

> You built the wrong configuration of FreeType.  Did you build the one
> specified on the BuildOpenvrmlOnWindows wiki page? (It's possible that
> page is incorrect; but I can't check it at the moment.)
>    
I built the LIB Debug Multithreaded and LIB Release Multithreaded as 
specified on the wiki page.
This produces the freetype2312MT_D.lib whereas openvrml wants the 
freetype2312_D.lib.

Besides, in version 0.17.12 openvrml requires the freetype239MT_D.lib 
and not the freetype239_D.lib.

> [snip]
>
> Hm... Any chance you could use the debugger to check the value of the
> "urn" variable right before this happens?  (In the
> openvrml::local::component::add_scope_entry function.)
>    
I'll try that tomorrow hopefully.
> I suspect what has happened here is that OpenVRML has read a component
> descriptor corresponding to a module that, for some reason, wasn't
> loaded.  What do you have OPENVRML_NODE_PATH set to?
>    
to [blabla]\openvrml-0.18.5\openvrml-0.18.5\src\node
> This could be related to the problem you had with
> x3d-cad-geometry/register_node_metatypes.cpp.  Can you try the svn
> sources?
>
>          http://svn.openvrml.org/svnroot/openvrml/branches/0.18
>    
What is the difference between

http://svn.openvrml.org/svnroot/openvrml/branches/0.18

and

http://svn.openvrml.org/svnroot/openvrml/trunk
?


Greets

Re: [openvrml-develop] A few Questions

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

On Wed, 2010-04-28 at 11:18 +0200, Christian Lang wrote: 
> Hi
> 
> i had trouble building openvrml 0.18.5 in Visual C++.
> First i got the newest releases from boost, freetype and the other 
> required stuff and tried to run openvrml but it resulted in an error:
> 
> The application failed to initialize property (0xE06D7363)
> 
> The guide says this is because OPENVRML_DATADIR is not set, but it was set.

Perhaps it was not set correctly.

> (By the way there were some minor issues, too:
> - in some project folders (like 
> openvrml-0.18.5\ide-projects\Windows\VisualC9_0\OpenVRML\x3d-cad-geometry) 
> the *.vcproj file had an incorrect or missing file ending
> - in openvrml-0.18.5\src\node\x3d-cad-geometry (and only there) was the 
> register_node_metatypes.cpp missing, which i got by a google query

Whoops. :-(

I suspect these two bullet points are the same problem.  (If they
aren't, could you be more specific about what's going on with the first
one?)

I will commit a fix to ensure that this file gets distributed in 0.18.6.

> - when building freetype 2.3.12 the libraries have an "MT" included in 
> the name, which had to be removed for openvrml to find them)

You built the wrong configuration of FreeType.  Did you build the one
specified on the BuildOpenvrmlOnWindows wiki page? (It's possible that
page is incorrect; but I can't check it at the moment.)

> So i tried openvrml 0.17.12 which worked well.
> But i encountered another problem: to load a 3MB wrl-file it takes quite 
> a long time. Is this normal or is it caused by some wrong configuration 
> or something?
> (other vrml-viewers load this file on my machine way faster so i hope 
> there is a fault on my side)

OpenVRML's parser does some fairly rigorous checking of the input, so
it's probably going to be consistently slower than some other parsers.
However, I am hopeful that the forthcoming rewrite of the parser using
Spirit2 will improve the situation.

> Later i gave 0.18.5 a second try. This time i used the versions of 
> boost, freetype and so on that were mentioned in the guide.
> And i set the OPENVRML_NODE_PATH and OPENVRML_SCRIPT_PATH this time, too.
> 
> I don't remember if i did something in addition to that but in the end 
> it worked to the point that the error mentioned above did not occure any 
> more.
> But another one did :-)
> 
> Now it says
> "
> Assertion failed!
> 
> Program: ...
> File: c:\....\component.cpp
> Line: 264
> 
> Expression: class_
> "
> 
> Here the output:

[snip]

Hm... Any chance you could use the debugger to check the value of the
"urn" variable right before this happens?  (In the
openvrml::local::component::add_scope_entry function.)

I suspect what has happened here is that OpenVRML has read a component
descriptor corresponding to a module that, for some reason, wasn't
loaded.  What do you have OPENVRML_NODE_PATH set to?

This could be related to the problem you had with
x3d-cad-geometry/register_node_metatypes.cpp.  Can you try the svn
sources?

        http://svn.openvrml.org/svnroot/openvrml/branches/0.18

-- 
Braden McDaniel <br...@en...>

[openvrml-develop] A few Questions

[Christian L. <chr...@vd...>]

Hi

i had trouble building openvrml 0.18.5 in Visual C++.
First i got the newest releases from boost, freetype and the other 
required stuff and tried to run openvrml but it resulted in an error:

The application failed to initialize property (0xE06D7363)

The guide says this is because OPENVRML_DATADIR is not set, but it was set.

(By the way there were some minor issues, too:
- in some project folders (like 
openvrml-0.18.5\ide-projects\Windows\VisualC9_0\OpenVRML\x3d-cad-geometry) 
the *.vcproj file had an incorrect or missing file ending
- in openvrml-0.18.5\src\node\x3d-cad-geometry (and only there) was the 
register_node_metatypes.cpp missing, which i got by a google query
- when building freetype 2.3.12 the libraries have an "MT" included in 
the name, which had to be removed for openvrml to find them)

So i tried openvrml 0.17.12 which worked well.
But i encountered another problem: to load a 3MB wrl-file it takes quite 
a long time. Is this normal or is it caused by some wrong configuration 
or something?
(other vrml-viewers load this file on my machine way faster so i hope 
there is a fault on my side)

Later i gave 0.18.5 a second try. This time i used the versions of 
boost, freetype and so on that were mentioned in the guide.
And i set the OPENVRML_NODE_PATH and OPENVRML_SCRIPT_PATH this time, too.

I don't remember if i did something in addition to that but in the end 
it worked to the point that the error mentioned above did not occure any 
more.
But another one did :-)

Now it says
"
Assertion failed!

Program: ...
File: c:\....\component.cpp
Line: 264

Expression: class_
"

Here the output:
""
sdl-viewer.exe": "C:\Dokumente und 
Einstellungen\Administrator\Desktop\temp\openvrml-0.18.5.tar\openvrml-0.18.5\ide-projects\Windows\VisualC9_0\OpenVRML\Debug\bin\sdl-viewer.exe" 
geladen, Symbole wurden geladen.
"sdl-viewer.exe": "C:\WINDOWS\system32\ntdll.dll" wurde geladen
"sdl-viewer.exe": "C:\WINDOWS\system32\kernel32.dll" wurde geladen
"sdl-viewer.exe": "C:\WINDOWS\system32\winmm.dll" wurde geladen
"sdl-viewer.exe": "C:\WINDOWS\system32\advapi32.dll" wurde geladen
"sdl-viewer.exe": "C:\WINDOWS\system32\rpcrt4.dll" wurde geladen
"sdl-viewer.exe": "C:\WINDOWS\system32\secur32.dll" wurde geladen
"sdl-viewer.exe": "C:\WINDOWS\system32\gdi32.dll" wurde geladen
"sdl-viewer.exe": "C:\WINDOWS\system32\user32.dll" wurde geladen
"sdl-viewer.exe": "C:\Dokumente und 
Einstellungen\Administrator\Desktop\temp\openvrml-0.18.5.tar\openvrml-0.18.5\ide-projects\Windows\VisualC9_0\OpenVRML\Debug\bin\openvrml.dll" 
geladen, Symbole wurden geladen.
"sdl-viewer.exe": "C:\WINDOWS\system32\shlwapi.dll" wurde geladen
"sdl-viewer.exe": "C:\WINDOWS\system32\msvcrt.dll" wurde geladen
"sdl-viewer.exe": "C:\WINDOWS\system32\xmllite.dll" wurde geladen
"sdl-viewer.exe": 
"C:\WINDOWS\WinSxS\x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_f863c71f\msvcp90d.dll" 
wurde geladen
"sdl-viewer.exe": 
"C:\WINDOWS\WinSxS\x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_f863c71f\msvcr90d.dll" 
wurde geladen
"sdl-viewer.exe": "C:\Dokumente und 
Einstellungen\Administrator\Desktop\temp\openvrml-0.18.5.tar\openvrml-0.18.5\ide-projects\Windows\VisualC9_0\OpenVRML\Debug\bin\openvrml-gl.dll" 
geladen, Symbole wurden geladen.
"sdl-viewer.exe": "C:\WINDOWS\system32\glu32.dll" wurde geladen
"sdl-viewer.exe": "C:\WINDOWS\system32\opengl32.dll" wurde geladen
"sdl-viewer.exe": "C:\WINDOWS\system32\ddraw.dll" wurde geladen
"sdl-viewer.exe": "C:\WINDOWS\system32\dciman32.dll" wurde geladen
"sdl-viewer.exe": "C:\WINDOWS\system32\imm32.dll" wurde geladen
"sdl-viewer.exe": "C:\WINDOWS\system32\wxvault.dll" geladen, Die 
Binärdaten wurden nicht mit Debuginformationen erstellt.
"sdl-viewer.exe": "C:\WINDOWS\system32\psapi.dll" wurde geladen
"sdl-viewer.exe": "C:\WINDOWS\system32\mpr.dll" wurde geladen
"sdl-viewer.exe": "C:\WINDOWS\system32\version.dll" wurde geladen
"sdl-viewer.exe": "C:\WINDOWS\system32\detoured.dll" wurde geladen
"sdl-viewer.exe": "C:\WINDOWS\system32\shell32.dll" wurde geladen
"sdl-viewer.exe": 
"C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.5512_x-ww_35d4ce83\comctl32.dll" 
wurde geladen
"sdl-viewer.exe": "C:\WINDOWS\system32\comctl32.dll" wurde geladen
Eine Ausnahme (erste Chance) bei 0x7c812afb in sdl-viewer.exe: Microsoft 
C++-Ausnahme: `anonymous namespace'::no_registry_key an Speicherposition 
0x0012f528..
Eine Ausnahme (erste Chance) bei 0x00000000 in sdl-viewer.exe: 
0xC0000005: Zugriffsverletzung beim Lesen an Position 0x00000000.
Eine Ausnahme (erste Chance) bei 0x00000000 in sdl-viewer.exe: 
0xC0000005: Zugriffsverletzung beim Lesen an Position 0x00000000.
"sdl-viewer.exe": "C:\WINDOWS\system32\msctf.dll" wurde geladen
"sdl-viewer.exe": "C:\WINDOWS\system32\msctfime.ime" wurde geladen
"sdl-viewer.exe": "C:\WINDOWS\system32\ole32.dll" wurde geladen
"sdl-viewer.exe": "C:\WINDOWS\system32\kbdus.dll" wurde geladen
"sdl-viewer.exe": "C:\WINDOWS\system32\kbdus.dll" entladen.
"sdl-viewer.exe": "C:\WINDOWS\system32\kbdgr.dll" wurde geladen
"sdl-viewer.exe": "C:\WINDOWS\system32\kbdgr.dll" entladen.
"sdl-viewer.exe": "C:\WINDOWS\system32\nvoglnt.dll" wurde geladen
Der Thread 'Win32 Thread' (0x11cc) hat mit Code 0 (0x0) geendet.
"sdl-viewer.exe": "C:\WINDOWS\system32\mcd32.dll" wurde geladen
"sdl-viewer.exe": "C:\WINDOWS\system32\mcd32.dll" entladen.
Eine Ausnahme (erste Chance) bei 0x7c812afb in sdl-viewer.exe: Microsoft 
C++-Ausnahme: `anonymous namespace'::no_registry_key an Speicherposition 
0x0012e470..
Eine Ausnahme (erste Chance) bei 0x7c812afb in sdl-viewer.exe: Microsoft 
C++-Ausnahme: 
boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::filesystem::basic_filesystem_error<boost::filesystem::basic_path<std::basic_string<char,std::char_traits<char>,std::allocator<char> 
 >,boost::filesystem::path_traits> > an Speicherposition 0x0012e390..
Eine Ausnahme (erste Chance) bei 0x7c812afb in sdl-viewer.exe: Microsoft 
C++-Ausnahme: `anonymous namespace'::no_registry_key an Speicherposition 
0x0257f5b4..
Eine Ausnahme (erste Chance) bei 0x7c812afb in sdl-viewer.exe: Microsoft 
C++-Ausnahme: 
boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::filesystem::basic_filesystem_error<boost::filesystem::basic_path<std::basic_string<char,std::char_traits<char>,std::allocator<char> 
 >,boost::filesystem::path_traits> > an Speicherposition 0x0257f4d4..
Der Thread 'Win32 Thread' (0x658) hat mit Code 3 (0x3) geendet.
Der Thread 'Win32 Thread' (0x710) hat mit Code 3 (0x3) geendet.
Der Thread 'Win32 Thread' (0x109c) hat mit Code 3 (0x3) geendet.
Das Programm "[692] sdl-viewer.exe: Systemeigen" wurde mit Code 3 (0x3) 
beendet.
"
I cancelled the program through the error window.

That's it so far. I hope you understand my english :-)

Greets Christian

Re: [openvrml-develop] material-rendering bug (was ANN: OpenVRML 0.18.5)

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

On 3/29/10 4:58 PM, Braden McDaniel wrote:
> I'm still trying to get a handle on exactly what's going on
> here.  I'm getting closer; I think I'm looking at a race between some
> stream handling threads.  But I haven't isolated it yet.

This may or may not be the case.  Regardless, there is definitely
something screwy going on in the PNG decoder.  I think what's happening
is that for some images, the decoder is not detecting the number of
pixel components correctly and consequently isn't giving libpng a big
enough buffer to work with.  libpng calls then proceed to stomp all over
memory (which on my machine appears consistently to be the browser's
node_metatype_registry); hilarity ensues.

-- 
Braden McDaniel <br...@en...>

Re: [openvrml-develop] Viewpoint change

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

On Wed, 2010-03-31 at 04:14 -0700, cheribhai wrote: 
> I agree. I think viewpoint jumps and animations can be quite useful at times.
> In my case I need to actually perform the 'bind' to another viewport, so
> isBound is not good enough. 
> 
> But do you propose exposing the 'bind' method only for the viewpoint_node
> (which I think should be enough, since this is probably the only bindable
> node that the browser is allowed to manipulate) or are you thinking about a
> more general approach?

If that's what you want, why not just send an event to the Viewpoint
node's "set_bind" eventIn?

If we do start exposing the bound node stack via libopenvrml's API, this
is something that ought to be done generally and consistently for all
bindable nodes.  An approach I'm thinking of would have bindable types
registering themselves somehow with the browser (or possibly the scene),
which would provide (and expose) the actual bound node stack logic.

-- 
Braden McDaniel <br...@en...>

Re: [openvrml-develop] Viewpoint change

[cheribhai <cha...@gm...>]

I agree. I think viewpoint jumps and animations can be quite useful at times.
In my case I need to actually perform the 'bind' to another viewport, so
isBound is not good enough. 

But do you propose exposing the 'bind' method only for the viewpoint_node
(which I think should be enough, since this is probably the only bindable
node that the browser is allowed to manipulate) or are you thinking about a
more general approach?

cheers - cherian


Braden McDaniel wrote:
> 
> On Fri, 2010-03-26 at 08:48 -0700, cheribhai wrote: 
>> 
>> 
>> Hello,
>>        A couple of questions concerning change in viewpoint.
>> (1) The VRML97 spec says that 'The jump field specifies whether the
>> user's
>> view "jumps" to the position and orientation of a bound Viewpoint node or
>> remains unchanged.'
>> The way I see it, if jump is true the viewpoint user view transform
>> should
>> by set to identity, which the following code does.
>> 
>> void openvrml_node_vrml97::viewpoint_node::bind(const bool val,
>>                                                 const double timestamp)
>>     OPENVRML_THROW1(std::bad_alloc)
>> {
>>     this->is_bound_.value(val);
>>     last_user_view_transform_ = user_view_transform_;
>>     if(this->jump_.value())
>>         this->user_view_transform_ = openvrml::make_mat4f();
>>     node::emit_event(this->is_bound_emitter_, timestamp);
>> }
>> 
>> Am I right on this?
> 
> Yes, I think that looks good.
> 
> I thought I remembered getting this stuff working.  I was certainly
> thinking about it when I wrote the user_view_transform stuff; maybe I
> just didn't quite finish the idea.
> 
>> (2) I am trying to implement viewpoint change animation in a custom
>> browser.
>> For this it seems that I need the attribute value of
>> viewpoint_metatype::bind function  to be set to visible (OPENVRML_API). 
>> 
>> Is this the way to go about what I want to do or is there another way
>> around
>> this?
> 
> Well, it's not going to be that simple.  viewpoint_metatype lives in a
> dynamically loaded module; it's not something you'd link against.
> 
> Is openvrml_node_vrml97::viewpoint_node::is_bound_ what you really want?
> Of course, openvrml_node_vrml97::viewpoint_node lives in the same
> dynamically loaded module; but in this case, it's not to hard to expose
> functionality by pushing it up to the openvrml::viewpoint_node
> interface.
> 
> There was a time that I was trying to avoid committing the libopenvrml
> interface to the bindable node stack concepts; I was hoping that X3D
> would evolve away from that brain damage.  But it didn't.  So there's a
> compelling argument to be made that there's no point in continuing to
> run from this.
> 
> -- 
> Braden McDaniel <br...@en...>
> 
> 
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> openvrml-develop mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvrml-develop
> 
> 

-- 
View this message in context: http://old.nabble.com/Viewpoint-change-tp28044359p28094392.html
Sent from the openvrml-develop mailing list archive at Nabble.com.

Re: [openvrml-develop] Viewpoint change

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

On Fri, 2010-03-26 at 08:48 -0700, cheribhai wrote: 
> 
> 
> Hello,
>        A couple of questions concerning change in viewpoint.
> (1) The VRML97 spec says that 'The jump field specifies whether the user's
> view "jumps" to the position and orientation of a bound Viewpoint node or
> remains unchanged.'
> The way I see it, if jump is true the viewpoint user view transform should
> by set to identity, which the following code does.
> 
> void openvrml_node_vrml97::viewpoint_node::bind(const bool val,
>                                                 const double timestamp)
>     OPENVRML_THROW1(std::bad_alloc)
> {
>     this->is_bound_.value(val);
>     last_user_view_transform_ = user_view_transform_;
>     if(this->jump_.value())
>         this->user_view_transform_ = openvrml::make_mat4f();
>     node::emit_event(this->is_bound_emitter_, timestamp);
> }
> 
> Am I right on this?

Yes, I think that looks good.

I thought I remembered getting this stuff working.  I was certainly
thinking about it when I wrote the user_view_transform stuff; maybe I
just didn't quite finish the idea.

> (2) I am trying to implement viewpoint change animation in a custom browser.
> For this it seems that I need the attribute value of
> viewpoint_metatype::bind function  to be set to visible (OPENVRML_API). 
> 
> Is this the way to go about what I want to do or is there another way around
> this?

Well, it's not going to be that simple.  viewpoint_metatype lives in a
dynamically loaded module; it's not something you'd link against.

Is openvrml_node_vrml97::viewpoint_node::is_bound_ what you really want?
Of course, openvrml_node_vrml97::viewpoint_node lives in the same
dynamically loaded module; but in this case, it's not to hard to expose
functionality by pushing it up to the openvrml::viewpoint_node
interface.

There was a time that I was trying to avoid committing the libopenvrml
interface to the bindable node stack concepts; I was hoping that X3D
would evolve away from that brain damage.  But it didn't.  So there's a
compelling argument to be made that there's no point in continuing to
run from this.

-- 
Braden McDaniel <br...@en...>

Re: [openvrml-develop] material-rendering bug (was ANN: OpenVRML 0.18.5)

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

>> Oh, and one other gotcha with sdl-viewer:  it appears that any X events
>> (e.g., mouseover) while it's setting up the initial scene will lock up X
>> input in a way reminiscent of the old Motif menu-focus-grab lockups.  The
>> mouse still moves, but focus doesn't change, and neither mouseclicks nor
>> keyboard input are accepted.  Since modern X no longer supports the old
>> AllowDeactivateGrabs option, I can't verify that it's actually a grab
>> issue, but that's what it feels like.  (Logging in from another machine
>> and killing the sdl-viewer process takes care of it.)

> I'll give this a looksee once I've resolved the crasher bugs; but an
> sdl-viewer specific bug might not get a very high priority from me.

I was mistaken about the X events part--it occurs even without any mouse
or keyboard activity at all (in fact, sole X event is initial expose, I
think).  It seems to be simply a one-in-20 (or so) error condition.  I'm
not certain, but I _think_ I saw it in freewrl yesterday, which may suggest
a driver bug rather than either app.

Newly seen rendering-model issue:  with a half-transparent covering (a roof
in this case), visibility of the underlying stuff depends entirely on the
objects' order in the world file.  This order...

	aerial-view ground texture (square)
	50% tranparent roof
	house geometry
	house objects (more monitors :-) )

...resulted in a completely invisible house and objects when seen from above;
the texture is all that showed through the roof.  This order, on the other
hand...

	house geometry
	50% tranparent roof
	house objects (monitors)
	aerial-view ground texture

...caused only the monitors and portions of the ground texture at the edges
of the roof (i.e., without house geometry intervening) to disappear.  Thus
the only workable place for the roof is as the last geometry element in the
file--unless one _wants_ the other stuff to go away, that is, which briefly
proved useful when aligning the model with the aerial texture.

Greg

Re: [openvrml-develop] material-rendering bug (was ANN: OpenVRML 0.18.5)

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

On Fri, 2010-03-19 at 10:31 -0700, Greg Roelofs wrote: 
> >> Are the other problem worlds publicly available?
> 
> > I've just uploaded a tarball here:
> 
> The weird brown desktop in the cubicles model in the tarball was bothering
> me, but I thought it must have been due to some subtle alignment issue
> between that specific bit of geometry and my light source(s).  Doesn't
> look like it, though:
> 
> 	http://gregroelofs.com/test/cubicles-moved-DeskCorner.wrl
> 
> (Note that the textures aren't there, so copy that file wherever you
> unpacked the tarball for complete parity with cubicles.wrl.  The relevant
> "feature" isn't dependent on the textures, though.)
> 
> Anyway, that's an identical file except that the specific instance of the
> DeskCorner proto that was brown in cubicles.wrl has been moved in front of
> all the other desk-related instances (about 20-30 lines up).  Now it works
> correctly, i.e., it matches all the other desktop surfaces.
> 
> I'm wondering of this is another manifestation of the apparent memory
> corruption seen in the crashes.

Could be.  I'm still trying to get a handle on exactly what's going on
here.  I'm getting closer; I think I'm looking at a race between some
stream handling threads.  But I haven't isolated it yet.

> Oh, and one other gotcha with sdl-viewer:  it appears that any X events
> (e.g., mouseover) while it's setting up the initial scene will lock up X
> input in a way reminiscent of the old Motif menu-focus-grab lockups.  The
> mouse still moves, but focus doesn't change, and neither mouseclicks nor
> keyboard input are accepted.  Since modern X no longer supports the old
> AllowDeactivateGrabs option, I can't verify that it's actually a grab
> issue, but that's what it feels like.  (Logging in from another machine
> and killing the sdl-viewer process takes care of it.)

I'll give this a looksee once I've resolved the crasher bugs; but an
sdl-viewer specific bug might not get a very high priority from me.

-- 
Braden McDaniel <br...@en...>

[openvrml-develop] Viewpoint change

[cheribhai <cha...@gm...>]

Hello,
       A couple of questions concerning change in viewpoint.
(1) The VRML97 spec says that 'The jump field specifies whether the user's
view "jumps" to the position and orientation of a bound Viewpoint node or
remains unchanged.'
The way I see it, if jump is true the viewpoint user view transform should
by set to identity, which the following code does.

void openvrml_node_vrml97::viewpoint_node::bind(const bool val,
                                                const double timestamp)
    OPENVRML_THROW1(std::bad_alloc)
{
    this->is_bound_.value(val);
    last_user_view_transform_ = user_view_transform_;
    if(this->jump_.value())
        this->user_view_transform_ = openvrml::make_mat4f();
    node::emit_event(this->is_bound_emitter_, timestamp);
}

Am I right on this?

(2) I am trying to implement viewpoint change animation in a custom browser.
For this it seems that I need the attribute value of
viewpoint_metatype::bind function  to be set to visible (OPENVRML_API). 

Is this the way to go about what I want to do or is there another way around
this?


cheers - cherian
-- 
View this message in context: http://old.nabble.com/Viewpoint-change-tp28044359p28044359.html
Sent from the openvrml-develop mailing list archive at Nabble.com.

Re: [openvrml-develop] Vector Assignment

[cheribhai <cha...@gm...>]

Hi Braden,
             Sorry about this. Figured out why it didn't work. Then tried to
edit the post but couldn't.

cheers - Cherian


Braden McDaniel wrote:
> 
> On Tue, 2010-03-23 at 09:58 -0700, cheribhai wrote: 
>> Hello Braden,
>>                   The problem seems to be occurring when the field of an
>> external node is changed in a script node. I have attached an example
>> where
>> I try to toggle between the  binding of two viewpoints from a script. The
>> bind values remain unchanged when using simple assignment.
>> 
>> Cheers - Cherian
>> 
>> http://old.nabble.com/file/p28003831/jsassign.wrl jsassign.wrl
> 
>         $ wget http://old.nabble.com/file/p28003831/jsassign.wrl
>         --2010-03-23 20:35:00-- 
> http://old.nabble.com/file/p28003831/jsassign.wrl
>         Resolving old.nabble.com... 216.139.236.162
>         Connecting to old.nabble.com|216.139.236.162|:80... connected.
>         HTTP request sent, awaiting response... 410 Gone
>         2010-03-23 20:35:00 ERROR 410: Gone.
> 
> :-(
> 
> -- 
> Braden McDaniel <br...@en...>
> 
> 
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> openvrml-develop mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvrml-develop
> 
> 

-- 
View this message in context: http://old.nabble.com/Vector-Assignment-tp27742867p28044275.html
Sent from the openvrml-develop mailing list archive at Nabble.com.

Re: [openvrml-develop] Vector Assignment

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

On Tue, 2010-03-23 at 09:58 -0700, cheribhai wrote: 
> Hello Braden,
>                   The problem seems to be occurring when the field of an
> external node is changed in a script node. I have attached an example where
> I try to toggle between the  binding of two viewpoints from a script. The
> bind values remain unchanged when using simple assignment.
> 
> Cheers - Cherian
> 
> http://old.nabble.com/file/p28003831/jsassign.wrl jsassign.wrl

        $ wget http://old.nabble.com/file/p28003831/jsassign.wrl
        --2010-03-23 20:35:00--  http://old.nabble.com/file/p28003831/jsassign.wrl
        Resolving old.nabble.com... 216.139.236.162
        Connecting to old.nabble.com|216.139.236.162|:80... connected.
        HTTP request sent, awaiting response... 410 Gone
        2010-03-23 20:35:00 ERROR 410: Gone.

:-(

-- 
Braden McDaniel <br...@en...>

Re: [openvrml-develop] Vector Assignment

[cheribhai <cha...@gm...>]

Hello Braden,
                  The problem seems to be occurring when the field of an
external node is changed in a script node. I have attached an example where
I try to toggle between the  binding of two viewpoints from a script. The
bind values remain unchanged when using simple assignment.

Cheers - Cherian

http://old.nabble.com/file/p28003831/jsassign.wrl jsassign.wrl 


Braden McDaniel wrote:
> 
> On Mon, 2010-03-01 at 04:40 -0800, cheribhai wrote: 
>> 
>> Hello,
>>        A quick question on vector asssignment using openvrml. I have a
>> javascript function where I am dynamically changing the key values of a
>> position interpolator, but the assignment does not seem to work.
>> I have tried 
>>   PosInter.keyValue[1][0] = targetPosition[0]; // x
>>   PosInter.keyValue[1][0] = targetPosition[1]; // y
>                          ^
>                          a typo, presumably.  :-)
> 
>>   PosInter.keyValue[1][2] = targetPosition[2]; // z
> 
> First off, you need to be using directOutput TRUE in order to set the
> node field like this.
> 
> But assuming you've done that, I think this still doesn't work because
> you end up setting the elements of a temporary SFVec3f that keyValue[1]
> returns.  I think there's an argument to be made that this syntax should
> work; but I haven't found a good way to do that with SpiderMonkey.
> 
> It should work to set the entire SFVec3f element at once:
> 
>         PosInter.keyValue[1] = targetPosition;
> 
>> and also 
>> 
>>   PosInter.keyValue = [0 0 0,  targetPosition[0] targetPosition[1]
>> targetPosition[2]]; 
>> 
>> but both don't work.
> 
> MF* types are not JavaScript arrays; so I wouldn't expect that to work.
> 
> -- 
> Braden McDaniel <br...@en...>
> 
> 
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> openvrml-develop mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvrml-develop
> 
> 

-- 
View this message in context: http://old.nabble.com/Vector-Assignment-tp27742867p28003831.html
Sent from the openvrml-develop mailing list archive at Nabble.com.

Re: [openvrml-develop] Viewpoint in PROTO

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

On Mon, 2010-03-22 at 01:56 -0700, cheribhai wrote: 
> Hello,
>        Attached an example with a viewpoint in a proto. On loading it, the
> viewpoint node 'do_relocate' function throws out an assert failure for 
> '!path.empty()'. Seems that it cannot find the viewpoint node in the scene
> graph.
> 
> Cheers - Cherian http://old.nabble.com/file/p27983668/vpproto.wrl
> vpproto.wrl 

Well, that's definitely not supposed to happen.  Can you please go to

        https://sourceforge.net/apps/trac/openvrml/newticket

and file a bug with this example attached?

-- 
Braden McDaniel <br...@en...>

[openvrml-develop] Viewpoint in PROTO

[cheribhai <cha...@gm...>]

Hello,
       Attached an example with a viewpoint in a proto. On loading it, the
viewpoint node 'do_relocate' function throws out an assert failure for 
'!path.empty()'. Seems that it cannot find the viewpoint node in the scene
graph.

Cheers - Cherian http://old.nabble.com/file/p27983668/vpproto.wrl
vpproto.wrl 
-- 
View this message in context: http://old.nabble.com/Viewpoint-in-PROTO-tp27983668p27983668.html
Sent from the openvrml-develop mailing list archive at Nabble.com.

Re: [openvrml-develop] Routes in PROTO

[cheribhai <cha...@gm...>]

Hello Braden,
                  Thanks for the example. The routing actually works (shot
the gun too quickly on that). There seems to be some other problem, but I
will have to look a bit more to figure out the problem and also provide you
with  an example.

Thanks again- Cherian


Braden McDaniel wrote:
> 
> On Mon, 2010-03-08 at 04:56 -0800, cheribhai wrote: 
>> 
>> Hello,
>>         It seems that routes declared inside PROTO definitions do not
>> seem
>> to be working as expected.
>> e.g. I have a time sensor and a script in a PROTO definition. When I try
>> to
>> route the 'time' of the time sensor to a function of the script which
>> simply
>> prints out the value of the time, it doesn't work. Quick debugging in the
>> time sensor node tells me that the time update is being done (and
>> consequently emitted), but somehow the script node does not receive this
>> event.
>> 
>>          Am I missing something?
> 
> Maybe; but I'll need a concrete example to know whether you are or
> you've found a bug.
> 
> The attached example works for me; that is, I see "Ouch!" printed to the
> console when I click the sphere.
> 
> -- 
> Braden McDaniel <br...@en...>
> 
> 
>  
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> openvrml-develop mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvrml-develop
> 
> 

-- 
View this message in context: http://old.nabble.com/Routes-in-PROTO-tp27819866p27983573.html
Sent from the openvrml-develop mailing list archive at Nabble.com.

[openvrml-develop] material-rendering bug (was ANN: OpenVRML 0.18.5)

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

>> Are the other problem worlds publicly available?

> I've just uploaded a tarball here:

The weird brown desktop in the cubicles model in the tarball was bothering
me, but I thought it must have been due to some subtle alignment issue
between that specific bit of geometry and my light source(s).  Doesn't
look like it, though:

	http://gregroelofs.com/test/cubicles-moved-DeskCorner.wrl

(Note that the textures aren't there, so copy that file wherever you
unpacked the tarball for complete parity with cubicles.wrl.  The relevant
"feature" isn't dependent on the textures, though.)

Anyway, that's an identical file except that the specific instance of the
DeskCorner proto that was brown in cubicles.wrl has been moved in front of
all the other desk-related instances (about 20-30 lines up).  Now it works
correctly, i.e., it matches all the other desktop surfaces.

I'm wondering of this is another manifestation of the apparent memory
corruption seen in the crashes.  There are similar color oddities on all
of the rectangular portions of desktop (Desk_2x2 protos), but only on the
(exposed) sides and undersurfaces.  I haven't completely verified that
that's not a real artifact/oversight in the model, but I've got some old
screenshots from other browsers that suggest it's not normal (so to speak).

Btw, note that the weird brown color is almost identical to that of the
cubicle sides visible from the second viewpoint.  This is more apparent if
you mouse-rotate the first (top down) viewpoint a bit.

Oh, and one other gotcha with sdl-viewer:  it appears that any X events
(e.g., mouseover) while it's setting up the initial scene will lock up X
input in a way reminiscent of the old Motif menu-focus-grab lockups.  The
mouse still moves, but focus doesn't change, and neither mouseclicks nor
keyboard input are accepted.  Since modern X no longer supports the old
AllowDeactivateGrabs option, I can't verify that it's actually a grab
issue, but that's what it feels like.  (Logging in from another machine
and killing the sdl-viewer process takes care of it.)

Greg

Re: [openvrml-develop] Cannot build OpenVRML 0.17.12

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

On Tue, 2010-03-16 at 18:11 -0700, Rich Cook wrote:
> Thanks,
> Newer glib -- oh noes!  The sysadmins will never go for it.  I can  
> compile it, but what's next I wonder...  I don't know what dbus-glib  
> is.  Is it included with glib?

No; it's a Glib-aware wrapper for libdbus.  It's (somewhat) more closely
associated with D-Bus than Glib.  See:

        http://www.freedesktop.org/wiki/Software/DBusBindings

-- 
Braden McDaniel <br...@en...>

Re: [openvrml-develop] Cannot build OpenVRML 0.17.12

[Rich C. <rc...@ll...>]

Thanks,
Newer glib -- oh noes!  The sysadmins will never go for it.  I can  
compile it, but what's next I wonder...  I don't know what dbus-glib  
is.  Is it included with glib?

On Mar 16, 2010, at 5:57 PM, Braden McDaniel wrote:

> On Tue, 2010-03-16 at 16:57 -0700, Rich Cook wrote:
>> I can't build 0.18 because of a dependency on GTK+ which I cannot
>> resolve here, so I'm reduced to trying to build 0.17.12.  I hope
>> someone cares.  :-)
>>
>> When I build, I get the following error:
>> g++ -DHAVE_CONFIG_H -I. -I..  -I../src/openvrml-xembed -I../lib/
>> gtkglext -I../lib/gtkglext -I../lib/gtkglext/gdk -I../src/ 
>> libopenvrml -
>> I../src/libopenvrml -I../src/libopenvrml-gl -I../src/libopenvrml-gl  
>> -I
>> -DGTK_DISABLE_DEPRECATED -I/usr/global/tools/VRML/OpenVRML/0.17.12/
>> chaos_4_x86_64_ib/boost_1_42_0/boost -I/usr/global/tools/VRML/ 
>> OpenVRML/
>> 0.17.12/chaos_4_x86_64_ib/include -pthread -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   -pthread -I/usr/include/gtk-2.0 -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   -pthread  
>> -I/
>> usr/global/tools/VRML/OpenVRML/0.17.12/chaos_4_x86_64_ib/ 
>> boost_1_42_0/
>> boost -I/usr/global/tools/VRML/OpenVRML/0.17.12/chaos_4_x86_64_ib/
>> include -MT openvrml-xembed/openvrml_xembed_openvrml_xembed-main.o - 
>> MD
>> -MP -MF openvrml-xembed/.deps/openvrml_xembed_openvrml_xembed- 
>> main.Tpo
>> -c -o openvrml-xembed/openvrml_xembed_openvrml_xembed-main.o `test -f
>> 'openvrml-xembed/main.cpp' || echo './'`openvrml-xembed/main.cpp
>> openvrml-xembed/main.cpp: In function
>> 'DBusGConnection*<unnamed>::bus_get(GMainContext*, DBusBusType,
>> GError**)':
>> openvrml-xembed/main.cpp:71: error:  
>> 'dbus_connection_get_g_connection'
>> was not declared in this scope
>
> Hm... What version of dbus-glib do you have installed?  Unfortunately,
> odds are you need a newer one.
>
>> openvrml-xembed/main.cpp: In function 'int main(int, char**)':
>> openvrml-xembed/main.cpp:203: error: 'boost::function' has not been
>> declared
>> openvrml-xembed/main.cpp:216: error: 'function' was not declared in
>> this scope
>> openvrml-xembed/main.cpp:216: error: 'dbus_thread_func' was not
>> declared in this scope
>> make[3]: *** [openvrml-xembed/openvrml_xembed_openvrml_xembed-main.o]
>> Error 1
>
> This one is probably because you're compiling with a *newer* Boost  
> than
> was used when 0.17 was designed for.  There have been some changes to
> the Boost headers such that stuff that used to be included  
> incidentally
> no longer is.  Try adding
>
>        #include <boost/function.hpp>
>
> to main.cpp.
>
> -- 
> Braden McDaniel <br...@en...>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://*p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> openvrml-develop mailing list
> ope...@li...
> https://*lists.sourceforge.net/lists/listinfo/openvrml-develop
>


/* A function that takes a single integer argument and returns
    a pointer to a function that takes two integer arguments and
    returns a floating-point number. */
float (*func2(int a))(int, int);
Rich Cook
rc...@ll...

Re: [openvrml-develop] Cannot build OpenVRML 0.17.12

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

On Tue, 2010-03-16 at 16:57 -0700, Rich Cook wrote:
> I can't build 0.18 because of a dependency on GTK+ which I cannot  
> resolve here, so I'm reduced to trying to build 0.17.12.  I hope  
> someone cares.  :-)
> 
> When I build, I get the following error:
> g++ -DHAVE_CONFIG_H -I. -I..  -I../src/openvrml-xembed -I../lib/ 
> gtkglext -I../lib/gtkglext -I../lib/gtkglext/gdk -I../src/libopenvrml - 
> I../src/libopenvrml -I../src/libopenvrml-gl -I../src/libopenvrml-gl -I  
> -DGTK_DISABLE_DEPRECATED -I/usr/global/tools/VRML/OpenVRML/0.17.12/ 
> chaos_4_x86_64_ib/boost_1_42_0/boost -I/usr/global/tools/VRML/OpenVRML/ 
> 0.17.12/chaos_4_x86_64_ib/include -pthread -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   -pthread -I/usr/include/gtk-2.0 -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   -pthread -I/ 
> usr/global/tools/VRML/OpenVRML/0.17.12/chaos_4_x86_64_ib/boost_1_42_0/ 
> boost -I/usr/global/tools/VRML/OpenVRML/0.17.12/chaos_4_x86_64_ib/ 
> include -MT openvrml-xembed/openvrml_xembed_openvrml_xembed-main.o -MD  
> -MP -MF openvrml-xembed/.deps/openvrml_xembed_openvrml_xembed-main.Tpo  
> -c -o openvrml-xembed/openvrml_xembed_openvrml_xembed-main.o `test -f  
> 'openvrml-xembed/main.cpp' || echo './'`openvrml-xembed/main.cpp
> openvrml-xembed/main.cpp: In function  
> 'DBusGConnection*<unnamed>::bus_get(GMainContext*, DBusBusType,  
> GError**)':
> openvrml-xembed/main.cpp:71: error: 'dbus_connection_get_g_connection'  
> was not declared in this scope

Hm... What version of dbus-glib do you have installed?  Unfortunately,
odds are you need a newer one.

> openvrml-xembed/main.cpp: In function 'int main(int, char**)':
> openvrml-xembed/main.cpp:203: error: 'boost::function' has not been  
> declared
> openvrml-xembed/main.cpp:216: error: 'function' was not declared in  
> this scope
> openvrml-xembed/main.cpp:216: error: 'dbus_thread_func' was not  
> declared in this scope
> make[3]: *** [openvrml-xembed/openvrml_xembed_openvrml_xembed-main.o]  
> Error 1

This one is probably because you're compiling with a *newer* Boost than
was used when 0.17 was designed for.  There have been some changes to
the Boost headers such that stuff that used to be included incidentally
no longer is.  Try adding

        #include <boost/function.hpp>

to main.cpp.

-- 
Braden McDaniel <br...@en...>

[openvrml-develop] Cannot build OpenVRML 0.17.12

[Rich C. <rc...@ll...>]

I can't build 0.18 because of a dependency on GTK+ which I cannot  
resolve here, so I'm reduced to trying to build 0.17.12.  I hope  
someone cares.  :-)

When I build, I get the following error:
g++ -DHAVE_CONFIG_H -I. -I..  -I../src/openvrml-xembed -I../lib/ 
gtkglext -I../lib/gtkglext -I../lib/gtkglext/gdk -I../src/libopenvrml - 
I../src/libopenvrml -I../src/libopenvrml-gl -I../src/libopenvrml-gl -I  
-DGTK_DISABLE_DEPRECATED -I/usr/global/tools/VRML/OpenVRML/0.17.12/ 
chaos_4_x86_64_ib/boost_1_42_0/boost -I/usr/global/tools/VRML/OpenVRML/ 
0.17.12/chaos_4_x86_64_ib/include -pthread -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   -pthread -I/usr/include/gtk-2.0 -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   -pthread -I/ 
usr/global/tools/VRML/OpenVRML/0.17.12/chaos_4_x86_64_ib/boost_1_42_0/ 
boost -I/usr/global/tools/VRML/OpenVRML/0.17.12/chaos_4_x86_64_ib/ 
include -MT openvrml-xembed/openvrml_xembed_openvrml_xembed-main.o -MD  
-MP -MF openvrml-xembed/.deps/openvrml_xembed_openvrml_xembed-main.Tpo  
-c -o openvrml-xembed/openvrml_xembed_openvrml_xembed-main.o `test -f  
'openvrml-xembed/main.cpp' || echo './'`openvrml-xembed/main.cpp
openvrml-xembed/main.cpp: In function  
'DBusGConnection*<unnamed>::bus_get(GMainContext*, DBusBusType,  
GError**)':
openvrml-xembed/main.cpp:71: error: 'dbus_connection_get_g_connection'  
was not declared in this scope
openvrml-xembed/main.cpp: In function 'int main(int, char**)':
openvrml-xembed/main.cpp:203: error: 'boost::function' has not been  
declared
openvrml-xembed/main.cpp:216: error: 'function' was not declared in  
this scope
openvrml-xembed/main.cpp:216: error: 'dbus_thread_func' was not  
declared in this scope
make[3]: *** [openvrml-xembed/openvrml_xembed_openvrml_xembed-main.o]  
Error 1

Any help?  Thank you!

/* A function that takes a single integer argument and returns
    a pointer to a function that takes two integer arguments and
    returns a floating-point number. */
float (*func2(int a))(int, int);
Rich Cook
rc...@ll...

Re: [openvrml-develop] ANN: OpenVRML 0.18.5

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

On Mon, 2010-03-15 at 23:09 -0700, Greg Roelofs wrote:
> > You're installing OpenVRML under /usr/local while you have D-Bus
> > installed under /usr.  So, openvrml-xembed's service descriptor is going
> > to wind up in /usr/local/share/dbus-1/services.
> 
> Doh!  I completely missed the "local" difference there.  Sorry, pilot error.
> I'll either figure out how to configure the /usr/local directory into D-Bus
> or else move the openvrml file into /usr.

It would be nice if there were some environment variable one could set
to tell D-Bus about other directories.  If that exists, I don't know
what it is. :-/

> > The 330 is a quirky little beast.  Even though it supports x86_64, it
> > can only see 4 GB of memory.  (Well, really more like 3.5.)
> 
> Really?  Dang, you'd think that would the kind of thing Intel would actually
> document somewhere, but there's no mention of it on this page...
> 
>     http://ark.intel.com/Product.aspx?id=35641&processor=330&spec-codes=SLG9Y

Yeah, you'd think.

> ...nor in their datasheet:
> 
>     http://download.intel.com/design/processor/datashts/320528.pdf
> 
> (unless it's _really_ obscure, like some implicit FSB signalling or pinout
> restriction).  How annoying.

The closest the datasheet comes to making this clear is Table 4-13 in
the description of the A[32:3]# signal.

To say it could be clearer would be quite an understatement.

-- 
Braden McDaniel <br...@en...>

Re: [openvrml-develop] ANN: OpenVRML 0.18.5

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

> You're installing OpenVRML under /usr/local while you have D-Bus
> installed under /usr.  So, openvrml-xembed's service descriptor is going
> to wind up in /usr/local/share/dbus-1/services.

Doh!  I completely missed the "local" difference there.  Sorry, pilot error.
I'll either figure out how to configure the /usr/local directory into D-Bus
or else move the openvrml file into /usr.

> sdl-viewer also only knows how to load local files.

I'm not saying I prefer it over openvrml-player (aside from the not-crashing
part); it's simply what I got working, and I can make some progress now.  I
would totally love a supported in-browser or browser-like player, though.

> The 330 is a quirky little beast.  Even though it supports x86_64, it
> can only see 4 GB of memory.  (Well, really more like 3.5.)

Really?  Dang, you'd think that would the kind of thing Intel would actually
document somewhere, but there's no mention of it on this page...

    http://ark.intel.com/Product.aspx?id=35641&processor=330&spec-codes=SLG9Y

...nor in their datasheet:

    http://download.intel.com/design/processor/datashts/320528.pdf

(unless it's _really_ obscure, like some implicit FSB signalling or pinout
restriction).  How annoying.

(I see they do now mention it explicitly for their newer Atom processors,
though.)

Thanks,
  Greg

Re: [openvrml-develop] ANN: OpenVRML 0.18.5

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

On Mon, 2010-03-15 at 10:20 -0700, Greg Roelofs wrote: 
> >> - D-Bus does _not_ automatically start openvrml-xembed on my box.  No clue
> >>    how that's supposed to work.  The workaround mentioned on the list works,
> >>    but the README is slightly misleading.
> 
> > You do have to install it for this to work.
> 
> Sorry, I meant to note that this was after I installed it (openvrml) via
> "make install" as root.  Or did you mean D-Bus itself?

Presumably D-Bus is already installed on a reasonably modern Linux.

> > It works (when it does)
> > because OpenVRML installs a descriptor to a place that D-Bus knows
> > about.  On Fedora, that's:
> 
> >         /usr/share/dbus-1/services/org.openvrml.BrowserControl.service
> 
> > If D-Bus is looking somewhere different on Debian, that would be a
> > problem.
> 
> I have that directory, but there's no openvrml file in there.  Very strange.
> I do see the relevant test and install command in my log, but it didn't work:
> 
>  [...]
> ----------------------------------------------------------------------
> test -z "/usr/local/include/openvrml" || /bin/mkdir -p "/usr/local/include/openvrml"
>  /usr/X11R6/bin/install -c -m 644 libopenvrml/openvrml-config.h libopenvrml/openvrml-common.h libopenvrml-gl/openvrml-gl-config.h libopenvrml-gl/openvrml-gl-common.h '/usr/local/include/openvrml'
> test -z "/usr/local/share/dbus-1/services" || /bin/mkdir -p "/usr/local/share/dbus-1/services"
>  /usr/X11R6/bin/install -c -m 644 openvrml-xembed/org.openvrml.BrowserControl.service '/usr/local/share/dbus-1/services'
> make[4]: Leaving directory `/util/3D/openvrml-0.18.5/src'
> make[3]: Leaving directory `/util/3D/openvrml-0.18.5/src'
> make[2]: Leaving directory `/util/3D/openvrml-0.18.5/src'
> make[1]: Leaving directory `/util/3D/openvrml-0.18.5/src'
> Making install in data
>  [...]
> 
> Not installed and later removed, either:
> 
> % ll -d /usr/share/dbus-1/services
> drwxr-xr-x 2 root 4096 Aug  1  2009 /usr/share/dbus-1/services/
> 
> Weird.

You're installing OpenVRML under /usr/local while you have D-Bus
installed under /usr.  So, openvrml-xembed's service descriptor is going
to wind up in /usr/local/share/dbus-1/services.

> > Are the other problem worlds publicly available?
> 
> I've just uploaded a tarball here:
> 
> 	http://gregroelofs.com/test/grr-openvrml-0.18.5-test.tgz

Thanks.  I'll check these out.

> > sdl-viewer doesn't use openvrml-xembed.  The idea behind openvrml-xembed
> > is to have a single viewer backend that is usable as either a
> > stand-alone viewer or a browser plug-in.
> 
> Huh...I completely missed that.  OK, that explains it.

sdl-viewer also only knows how to load local files.

libopenvrml is network-agnostic; and this extends to openvrml-xembed.
openvrml-xembed actually relies on its container to provide resource
fetching services.  openvrml-player uses libcurl for that part, while
the Web browser plug-in uses NPAPI services.

> > Fixable. :-)  But if you plan on using this to build software, I'd
> > recommending 4 GB of RAM if you want to use x86_64 Linux.  gcc can
> > consume a lot of memory; and IME, x86_64 can really nearly double its
> > memory consumption.
> 
> Good to know, thanks.  If the box is capable of it, I may go straight to 8.

The 330 is a quirky little beast.  Even though it supports x86_64, it
can only see 4 GB of memory.  (Well, really more like 3.5.)

-- 
Braden McDaniel <br...@en...>

Re: [openvrml-develop] ANN: OpenVRML 0.18.5

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

>> - D-Bus does _not_ automatically start openvrml-xembed on my box.  No clue
>>    how that's supposed to work.  The workaround mentioned on the list works,
>>    but the README is slightly misleading.

> You do have to install it for this to work.

Sorry, I meant to note that this was after I installed it (openvrml) via
"make install" as root.  Or did you mean D-Bus itself?

> It works (when it does)
> because OpenVRML installs a descriptor to a place that D-Bus knows
> about.  On Fedora, that's:

>         /usr/share/dbus-1/services/org.openvrml.BrowserControl.service

> If D-Bus is looking somewhere different on Debian, that would be a
> problem.

I have that directory, but there's no openvrml file in there.  Very strange.
I do see the relevant test and install command in my log, but it didn't work:

 [...]
----------------------------------------------------------------------
test -z "/usr/local/include/openvrml" || /bin/mkdir -p "/usr/local/include/openvrml"
 /usr/X11R6/bin/install -c -m 644 libopenvrml/openvrml-config.h libopenvrml/openvrml-common.h libopenvrml-gl/openvrml-gl-config.h libopenvrml-gl/openvrml-gl-common.h '/usr/local/include/openvrml'
test -z "/usr/local/share/dbus-1/services" || /bin/mkdir -p "/usr/local/share/dbus-1/services"
 /usr/X11R6/bin/install -c -m 644 openvrml-xembed/org.openvrml.BrowserControl.service '/usr/local/share/dbus-1/services'
make[4]: Leaving directory `/util/3D/openvrml-0.18.5/src'
make[3]: Leaving directory `/util/3D/openvrml-0.18.5/src'
make[2]: Leaving directory `/util/3D/openvrml-0.18.5/src'
make[1]: Leaving directory `/util/3D/openvrml-0.18.5/src'
Making install in data
 [...]

Not installed and later removed, either:

% ll -d /usr/share/dbus-1/services
drwxr-xr-x 2 root 4096 Aug  1  2009 /usr/share/dbus-1/services/

Weird.

>> Build:
>> 
>>  - AFAICT, it is flat out impossible to do a full openvrml build on reasonably
>>    modern Debian/Ubuntu.  Both xulrunner 1.9.1 (required due to some unique
>>    header file, according to configure) and 1.8.1 (the source of libmozjs)
>>    are required, and they cannot be installed simultaneously due to some
>>    unspecified conflict.  Ergo, no JS.

> That sounds like something you should complain to Debian's xulrunner
> package maintainers about.

Yes, this next section was more as a reference for others than explicit
bug-reporting.  Ubuntu has version 1.9.2 for either Karmic or Lucid, but
I don't have sufficient deb-fu to be able to pick that apart and see if
whatever conflict they saw has been resolved.  (xulrunner's dependency
list is even bigger than openvrml's, apparently, so I'm not inclined to
try building it manually.  The 44MB source tarball is none too inviting,
either.)

> This could probably be narrowed a bit.  But Boost upstream is
> distributed en masse; Debian has divided it up.

Not a complaint; I can use a modern Boost (and Java, doxygen, and even
ant) for other stuff, so I wanted a reasonably complete set.  But someone
working on Slackware, for example, would be feeling some serious pain at
all of the dependencies and sub-dependencies.  It's useful to have some
idea of what a "complete" list looks like.

>> sudo apt-get install xulrunner-1.9.1 xulrunner-1.9.1-dev xulrunner-1.9.1-gnome-support
>>    - [13.5MB of archives, 25.3MB of disk space]
>>    - [xulrunner-1.9.1 xulrunner-1.9.1-dev xulrunner-1.9.1-gnome-support]
>>    - [REMOVE libmozjs-dev xulrunner-1.9-dev]

> I don't think you can blame me or mozilla.org for this.  And ordinarily
> I really enjoy blaming mozilla.org for stuff.

Don't we all, don't we all...

Without knowing the nature of the putative incompatibility, it's hard to
judge.  The Debian/Ubuntu changelog wasn't much help.

> > The (single-threaded) first, non-JS build took 102 minutes on one of two
> >    1.6 GHz Atom 330's; build directory was 820 MB afterward.  Still chugging
> >    away on the second build to work around:

> Atoms are, of course, targeted at power efficiency rather than
> performance.  I have an Atom 330 myself.  It's a neat little machine.
> But I don't use it to build software.

Again, that wasn't a complaint, just a reference point for others.  I had
a (slightly) beefier machine but turned it off in favor of this sub-30W,
fanless wonderbox.  (I ended up adding a quiet, external USB fan last summer
since internal temps were approaching the hard drive's stated limits, but
it's still virtually inaudible.)

> FWIW, though, OpenVRML's build parallelizes well.  You should see some
> performance benefit from "make -jN" since the 330 has two cores with
> hyperthreading.  Of course, you may find yourself memory-limited.  But
> if you've installed 4 GB in the machine, I think you should be able to
> use -j4 safely.

Very good to know, thanks.  It's got only 2 GB and HT is disabled, but
there are two real cores in it, so I'll give -j2 a shot next time around.

> By comparison, an i7 920 using -j8 can build all of OpenVRML in about
> five minutes.

Nice.

> Are the other problem worlds publicly available?

I've just uploaded a tarball here:

	http://gregroelofs.com/test/grr-openvrml-0.18.5-test.tgz

Note that the hypnosphere one is _not_ mine; I believe someone in Europe,
possibly Austria, created it, but he didn't leave a name in the comments,
and I didn't keep a download reference.  Hopefully he won't mind...

> sdl-viewer doesn't use openvrml-xembed.  The idea behind openvrml-xembed
> is to have a single viewer backend that is usable as either a
> stand-alone viewer or a browser plug-in.

Huh...I completely missed that.  OK, that explains it.

> OpenVRML's renderer really needs a near-complete rewrite at this
> point. :-/

Ah, I thought maybe that had already happened in the last few years. :-)

>>  - dual Intel Atom 330 1.6 GHz, 2 GB RAM, Intel 945G graphics

> Ah, 2 GB.  Well, since you're using i686 instead of x86_64, "make -j4"
> is probably still doable.

I've got both Firefox and SeaMonkey resident and no swap, so I'll be a
bit conservative there....  It's just time, and the little box is happy
to chug away all night if need be.

>> - Ubuntu 2009.04 32-bit (64-bit box shipped that way, argh...)

> Fixable. :-)  But if you plan on using this to build software, I'd
> recommending 4 GB of RAM if you want to use x86_64 Linux.  gcc can
> consume a lot of memory; and IME, x86_64 can really nearly double its
> memory consumption.

Good to know, thanks.  If the box is capable of it, I may go straight to 8.

> Thanks for taking the time to hammer on OpenVRML.

Likewise. ;-)  It's great to have a working VRML viewer again; time to
start modeling the house.

Greg