openvrml-develop — OpenVRML developers mailing list

Re: [openvrml-develop] parse-vrml97.exe crash

[Sam U. <sa...@ho...>]

Hi,

 

>>OPENVRML_NODE_PATH is where you have *compiled* node implementations
>>(e.g., vrml97.dll). OPENVRML_SCRIPT_PATH is where you have compiled
>>scripting engines (e.g., javascript.dll).

 

Ok, I'm unable to build javascript.dll, because jsapi.h is missing.
But, as you mentioned, I don't need it if I don't use scripting.

 

And, I tried to build vrml97.dll, but it says ft2build.h is missing.

 

I noticed OPENVRML_ENABLE_RENDER_TEXT_NODE was defined in the proprocessor list,
so I removed it.  But, I'm still getting compilation errors from text.cpp
still being dependent on FreeType:
c:\openvrml-0.18.6\src\node\vrml97\text.cpp(139) : error C2061: syntax error : identifier 'FT_Face'

 

Is FreeType required to build vrml97.dll?

 

And there are 3 projects missing:
x3d-environmental-effects (unavailable)
x3d-event-utilities (unavailable)
x3d-key-device-sensor (unavailable)

 

My compiled node .DLLs are located here:
set OPENVRML_NODE_PATH=C:\openvrml-0.18.6\ide-projects\Windows\VisualC9_0\OpenVRML\Debug\bin\node

 

x3d-texturing.dll
x3d-cad-geometry.dll
x3d-shape.dll
x3d-rendering.dll
x3d-nurbs.dll
x3d-networking.dll
x3d-core.dll
x3d-interpolation.dll
x3d-h-anim.dll
x3d-grouping.dll
x3d-geospatial.dll
x3d-dis.dll
x3d-geometry2d.dll

 

I was able to compile pretty-print.exe, but this crashes on me too, even after
setting OPENVRML_NODE_PATH.


 
> From: br...@en...
> To: ope...@li...
> Date: Fri, 2 Jul 2010 02:20:44 -0400
> Subject: Re: [openvrml-develop] parse-vrml97.exe crash
> 
> On Thu, 2010-07-01 at 18:43 -0400, Sam Url wrote: 
> > >>What did you set them to?
> > 
> > 
> > set OPENVRML_DATADIR=C:\openvrml-0.18.6\data 
> > set OPENVRML_NODE_PATH=C:\openvrml-0.18.6\src\node
> > set OPENVRML_SCRIPT_PATH=C:\openvrml-0.18.6\models\rotation_toy.wrl
> > 
> > 
> > 
> > It still crashes on me.
> 
> Again, note the descriptions of these variables in README.
> OPENVRML_NODE_PATH is where you have *compiled* node implementations
> (e.g., vrml97.dll). OPENVRML_SCRIPT_PATH is where you have compiled
> scripting engines (e.g., javascript.dll).
> 
> > >> I'm not 100% clear on what this means to you. The provided project
> > >> files build libopenvrml as a DLL. And the node implementations and
> > >> scripting engines all live in plug-in DLLs.
> > 
> > 
> > 
> > I would like to use OpenVRML to open and parse VRML files. Does this require a node/scripting engine?
> 
> If you provide your own semantic actions for the parser, no. (You will,
> however, still need the component descriptors--that's where the parser
> gets its information about how to parse specific nodes.) See
> pretty-print for an example that provides its own semantic actions.
> 
> The parse-vrml97 and parse-x3d test programs use the semantic actions
> that are compiled into libopenvrml--and these create a tree of
> openvrml::nodes using the node implementations.
> 
> You only need a scripting engine if you want to process scripts at
> run-time.
> 
> -- 
> Braden McDaniel <br...@en...>
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> openvrml-develop mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvrml-develop
 		 	   		  
_________________________________________________________________
The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with Hotmail. 
http://www.windowslive.com/campaign/thenewbusy?tile=multicalendar&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_5

Re: [openvrml-develop] parse-vrml97.exe crash

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

On Thu, 2010-07-01 at 18:43 -0400, Sam Url wrote: 
> >>What did you set them to?
> 
> 
> set OPENVRML_DATADIR=C:\openvrml-0.18.6\data 
> set OPENVRML_NODE_PATH=C:\openvrml-0.18.6\src\node
> set OPENVRML_SCRIPT_PATH=C:\openvrml-0.18.6\models\rotation_toy.wrl
> 
>  
> 
> It still crashes on me.

Again, note the descriptions of these variables in README.
OPENVRML_NODE_PATH is where you have *compiled* node implementations
(e.g., vrml97.dll).  OPENVRML_SCRIPT_PATH is where you have compiled
scripting engines (e.g., javascript.dll).

> >> I'm not 100% clear on what this means to you. The provided project
> >> files build libopenvrml as a DLL. And the node implementations and
> >> scripting engines all live in plug-in DLLs.
> 
>  
> 
> I would like to use OpenVRML to open and parse VRML files.  Does this require a node/scripting engine?

If you provide your own semantic actions for the parser, no.  (You will,
however, still need the component descriptors--that's where the parser
gets its information about how to parse specific nodes.)  See
pretty-print for an example that provides its own semantic actions.

The parse-vrml97 and parse-x3d test programs use the semantic actions
that are compiled into libopenvrml--and these create a tree of
openvrml::nodes using the node implementations.

You only need a scripting engine if you want to process scripts at
run-time.

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

Re: [openvrml-develop] parse-vrml97.exe crash

[Sam U. <sa...@ho...>]

>>What did you set them to?


set OPENVRML_DATADIR=C:\openvrml-0.18.6\data 
set OPENVRML_NODE_PATH=C:\openvrml-0.18.6\src\node
set OPENVRML_SCRIPT_PATH=C:\openvrml-0.18.6\models\rotation_toy.wrl

 

It still crashes on me.

 

>> I'm not 100% clear on what this means to you. The provided project
>> files build libopenvrml as a DLL. And the node implementations and
>> scripting engines all live in plug-in DLLs.

 

I would like to use OpenVRML to open and parse VRML files.  Does this require a node/scripting engine?

 

If I ever distribute my own stand-alone VRML reader/viewer based on the OpenVRML libraries,
can I do this minimalistically, without any node/scripting setup?

 

I was hoping openvrml.dll was the only file I needed to distribute.


 
> Date: Thu, 1 Jul 2010 17:13:14 -0400
> From: br...@en...
> To: ope...@li...
> Subject: Re: [openvrml-develop] parse-vrml97.exe crash
> 
> [Please follow-up to the mailing list.]
> 
> On 7/1/10 4:39 PM, Sam Url wrote:
> > Hi,
> > 
> > I didn't set any environmental variables yet.
> > But, why would that cause a crash, even if they weren't set?
> 
> Because libopenvrml uses these variables to initialize some global
> objects. If it can't find what it needs, that initialization fails;
> that is, an exception gets thrown.
> 
> On Windows, throwing an exception during static initialization appears
> to be a bit dodgy; the resulting crash gives a message that isn't
> ideally lucid. The message could probably be improved (with some
> platform specific code); but the result (a crash) will be the same.
> 
> > I thought these are stand-alone executables?
> 
> I'm not 100% clear on what this means to you. The provided project
> files build libopenvrml as a DLL. And the node implementations and
> scripting engines all live in plug-in DLLs. OPENVRML_NODE_PATH and
> OPENVRML_SCRIPT_PATH are used to find these bits. OPENVRML_DATADIR is
> used to find the component XML descriptor files.
> 
> > Ok, I added those paths to my environment with some default values,
> > and parse-vrml97.exe still crashes. I also compiled parse-x3dvrml.exe,
> > and that crashes too.
> 
> What did you set them to?
> 
> -- 
> Braden McDaniel <br...@en...>
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> openvrml-develop mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvrml-develop
 		 	   		  
_________________________________________________________________
The New Busy is not the old busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3

Re: [openvrml-develop] parse-vrml97.exe crash

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

[Please follow-up to the mailing list.]

On 7/1/10 4:39 PM, Sam Url wrote:
> Hi,
>  
> I didn't set any environmental variables yet.
> But, why would that cause a crash, even if they weren't set?

Because libopenvrml uses these variables to initialize some global
objects.  If it can't find what it needs, that initialization fails;
that is, an exception gets thrown.

On Windows, throwing an exception during static initialization appears
to be a bit dodgy; the resulting crash gives a message that isn't
ideally lucid.  The message could probably be improved (with some
platform specific code); but the result (a crash) will be the same.

> I thought these are stand-alone executables?

I'm not 100% clear on what this means to you.  The provided project
files build libopenvrml as a DLL.  And the node implementations and
scripting engines all live in plug-in DLLs.  OPENVRML_NODE_PATH and
OPENVRML_SCRIPT_PATH are used to find these bits.  OPENVRML_DATADIR is
used to find the component XML descriptor files.

> Ok, I added those paths to my environment with some default values,
> and parse-vrml97.exe still crashes.   I also compiled parse-x3dvrml.exe,
> and that crashes too.

What did you set them to?

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

Re: [openvrml-develop] parse-vrml97.exe crash

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

On Thu, 2010-07-01 at 06:46 -0400, Sam Url wrote: 
> I'm using OpenVRML for the first time, and after compiling and running the VC90 project parse-vrml97,
> it crashes on me.  I get the error message:
> 
>  
> 
> parse-vrml97.exe - Application Error
> "The application failed to initialize properly (0xe06d7363). Click on OK to terminate the application."

Have you set the environment variables OPENVRML_DATADIR,
OPENVRML_NODE_PATH, and OPENVRML_SCRIPT_PATH (as per README)?  What are
they set to?

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

[openvrml-develop] parse-vrml97.exe crash

[Sam U. <sa...@ho...>]

Hello,


I'm using OpenVRML for the first time, and after compiling and running the VC90 project parse-vrml97,
it crashes on me.  I get the error message:

 

parse-vrml97.exe - Application Error
"The application failed to initialize properly (0xe06d7363). Click on OK to terminate the application."

 

I'm using MSVS 2008 C++, openvrml-0.18.6, and boost_1_43_0.

 

I compiled boost with this line:
bjam.exe --toolset=msvc-9.0 variant=release link=static threading=multi  stage  --with-thread  --with-filesystem  --with-date_time  --with-system

 

and it gives me these libs:
libboost_date_time-vc90-mt-1_43.lib
libboost_filesystem-vc90-mt-1_43.lib
libboost_system-vc90-mt-1_43.lib
libboost_thread-vc90-mt-1_43.lib

 

Then I compiled openvrml and parse-vrml97 in Release mode.  It gave me these files:
parse-vrml97.exe
openvrml.dll


I also tried Debug mode.  I recompile boost and it gives me these files:
libboost_date_time-vc90-mt-gd-1_43.lib
libboost_filesystem-vc90-mt-gd-1_43.lib
libboost_system-vc90-mt-gd-1_43.lib
libboost_thread-vc90-mt-gd-1_43.lib

 

I recompile openvrml in debug mode, and parse-vrml97.exe still crashes.  I get same error message.

 

Any suggestions?

 		 	   		  
_________________________________________________________________
Hotmail is redefining busy with tools for the New Busy. Get more from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2

Re: [openvrml-develop] Blank Screen FC13

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

On Fri, 2010-06-25 at 12:15 -0400, Braden McDaniel wrote:

[snip]

> I'm reminded that I need to update the Fedora packages to 0.18.6.  I'll
> do that this weekend.

openvrml-0.18.6-1 is now available in the updates-testing repositories
for Fedora 12 and 13.

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

Re: [openvrml-develop] Blank Screen FC13

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

On Thu, 2010-06-24 at 19:05 -0500, Tom Smith wrote: 
> I'm running Fedora Core 13 with Firefox 3.6.3 and it is configured to
> invoke openvrml-player for any file with the suffix .wrl.  I downloaded
> http://cic.nist.gov/vrml/nistlogo.wrl to ensure I have a file
> openvrml-player can supposedly read, but when I set a link to it in my
> browser, I get a black screen, which turns white after a few seconds. I
> never see the NIST logo, and I've confirmed nistlogo.wrl is correct by
> viewing it in vrmlview, a stand-alone vrmlviewer.

What version of OpenVRML are you using?

I'm reminded that I need to update the Fedora packages to 0.18.6.  I'll
do that this weekend.

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

[openvrml-develop] Blank Screen FC13

[Tom S. <smi...@gm...>]

I'm running Fedora Core 13 with Firefox 3.6.3 and it is configured to
invoke openvrml-player for any file with the suffix .wrl.  I downloaded
http://cic.nist.gov/vrml/nistlogo.wrl to ensure I have a file
openvrml-player can supposedly read, but when I set a link to it in my
browser, I get a black screen, which turns white after a few seconds. I
never see the NIST logo, and I've confirmed nistlogo.wrl is correct by
viewing it in vrmlview, a stand-alone vrmlviewer.
        

[openvrml-develop] ANN: OpenVRML 0.18.6

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

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

  <http://downloads.sourceforge.net/project/openvrml/openvrml/0.18.6/openvrml-0.18.6.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.18.6:

- Fixed memory corruption issues in the PNG and JPEG readers when
  reading grayscale images.

- Fixed memory leaks in Text node rendering.

Re: [openvrml-develop] material-rendering bug

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

On Fri, 2010-05-28 at 00:06 -0400, Braden McDaniel wrote: 
> On Fri, 2010-05-21 at 08:33 -0700, Greg Roelofs wrote: 
> > > I did finally discover a problem in the PNG reader that was leading to
> > > memory corruption.  I've committed a fix for this on the trunk and the
> > > 0.18 branch.  This has certainly addressed a significant problem with
> > > pngboxes.wrl; though I'm not sure it was the only problem.
> > 
> > > I'll be out of town this weekend; so it will probably be sometime next
> > > week before I'm able to test things more thoroughly.  In the meantime,
> > > the changes have been committed in case anyone else is interested in
> > > taking them for a spin.
> > 
> > Many thanks, Braden!  If I can find time this weekend, I'll check out the
> > 0.18 branch and give it a spin.
> 
> It looks like there are still problems in the JPEG reader that cause a
> crash. :-/

This is now fixed.  Unfortunately, the JPEG corruption issue described
in trac ticket #29 is still a problem.  But at least it doesn't crash.

In light of these crash fixes (and some other stuff), I'll release
0.18.6 this weekend.

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

Re: [openvrml-develop] material-rendering bug

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

On Fri, 2010-05-21 at 08:33 -0700, Greg Roelofs wrote: 
> > I did finally discover a problem in the PNG reader that was leading to
> > memory corruption.  I've committed a fix for this on the trunk and the
> > 0.18 branch.  This has certainly addressed a significant problem with
> > pngboxes.wrl; though I'm not sure it was the only problem.
> 
> > I'll be out of town this weekend; so it will probably be sometime next
> > week before I'm able to test things more thoroughly.  In the meantime,
> > the changes have been committed in case anyone else is interested in
> > taking them for a spin.
> 
> Many thanks, Braden!  If I can find time this weekend, I'll check out the
> 0.18 branch and give it a spin.

It looks like there are still problems in the JPEG reader that cause a
crash. :-/

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

Re: [openvrml-develop] Text node leaks

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

On Mon, 2010-05-03 at 02:26 -0400, Braden McDaniel wrote:

[snip]

> * Fiddling with valgrind has made it clear that Text nodes are
>         leaky. But, since valgrind isn't showing a lot of the symbols in
>         its backtrace to the allocation point, tracking the leaks down
>         is difficult.  I found one spot where we were leaking FT_Glyphs
>         and fixed it; but it seems there's more.  However, it seems
>         unlikely that this is the source of the memory *corruption* that
>         appears to be happening.

I finally tracked this down to stuff leaked (more or less deliberately)
by Fontconfig.  Calling FcFini will clean it up; but FcFini cannot be
called safely from library code (since it cannot be called redundantly).
So I've modified sdl_viewer.cpp to call FcFini on shutdown, since that's
what I normally use to check for leaks in the library code.

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

Re: [openvrml-develop] material-rendering bug

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

> I did finally discover a problem in the PNG reader that was leading to
> memory corruption.  I've committed a fix for this on the trunk and the
> 0.18 branch.  This has certainly addressed a significant problem with
> pngboxes.wrl; though I'm not sure it was the only problem.

> I'll be out of town this weekend; so it will probably be sometime next
> week before I'm able to test things more thoroughly.  In the meantime,
> the changes have been committed in case anyone else is interested in
> taking them for a spin.

Many thanks, Braden!  If I can find time this weekend, I'll check out the
0.18 branch and give it a spin.

Greg

Re: [openvrml-develop] material-rendering bug

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

On Mon, 2010-05-03 at 02:26 -0400, Braden McDaniel wrote: 
> On Thu, 2010-04-01 at 15:57 -0400, Braden McDaniel wrote: 
> > 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.
> 
> This bug continues to elude me. :-(
> 
> I have discovered a few things...
> 
>       * Even if I comment out all of the texture URLs in pngboxes.wrl, I
>         get a segfault in sdl-viewer occasionally.  So there's
>         *something* screwy going on irrespective of the image loading
>         code.

I still need to investigate this further...

> * One somewhat ominous looking message I'm getting from valgrind
>         is pointing to my Spirit-based node metatype identifier parser
>         (which is just a minor augmentation of my URI parser).

I tried updating the URI parser to use Spirit2; and this did get rid of
the ominous valgrind message.  It did not, however, fix The Problem.

I did finally discover a problem in the PNG reader that was leading to
memory corruption.  I've committed a fix for this on the trunk and the
0.18 branch.  This has certainly addressed a significant problem with
pngboxes.wrl; though I'm not sure it was the only problem.

I'll be out of town this weekend; so it will probably be sometime next
week before I'm able to test things more thoroughly.  In the meantime,
the changes have been committed in case anyone else is interested in
taking them for a spin.

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

Re: [openvrml-develop] OpenVRML in MacOS - Linker Errors

[Ignacio E. <na...@gm...>]

Thanks for your help Braden.

I added :

libboost_thread-mt.dylib
libxml2.2.dylib
libopenvrml.9.dylib

as you suggested and I could successfully run pretty_print.cpp , I got
my sample wrl file very well indented ;)
It seems that Xcode does not automatically pull dylibs.

Just one more question:
Is regarding sdl_viewer.cpp example

I added SDL headers and dylibs:
libSDL-1.2.0.dylib
libopenvrml-gl.8.dylib
besides the everything needed for pretty_print.cpp and I got one last
link error:

Undefined symbols:
  "_main", referenced from:
      start in crt1.10.6.o
     (maybe you meant: _SDL_main)
ld: symbol(s) not found
collect2: ld returned 1 exit status

I get this error when compiling 10.5 and 10.6. with i386 arch.

Is this relevant to openvrml?
I want to be able to render some vrml in a GLUT or Cocoa window
(NSOpenGLView) , so I only need, libboost_thread, libxml, libopenvrml
and libopenvrml-gl. Is this correct?

Thanks in advance.





When I try to run the next example It

On Sun, May 9, 2010 at 12:04 PM, Braden McDaniel <br...@en...> wrote:
> On Sun, 2010-05-09 at 06:17 +0900, Ignacio Enriquez wrote:
>> Hi, all
>> Long time ago I did almost the same question:
>> http://old.nabble.com/NEWBIE:-using-openvrml-in-mac-OS-10.6-td26253956.html
>> I had troubles setting my project in Xcode with openvrml from Macports.
>>
>> Now, I did as suggested but I found that Xcode does not link necessary
>> dylibs. (They have to be explicitly added to the project)
>> sample: pretty_print.cpp compiles ok, but fails when linking.
>> So I dug into /opt/local/libs and brought libopenvrml.9.dylib into
>> Xcode and 13 link errors became 6!. (So my theory is right)
>> Also found libopenvrml.la file and realized that there are many
>> dependency libraries. So, doing this manually is like a never-ending
>> work.
>
> .la are "libtool libraries", which is to say that they are actually text
> files with information for libtool (which is typically known as glibtool
> on your Mac).
>
>> So my questions are:
>> What are the dylibs needed to get pretty_print.cpp to work?
>
> Well, give us a hint, at least: what symbols are undefined?
>
>> Is there any way I can make Xcode read *.la files? (or an alternative
>> way?) so he can link libraries automatically.
>
> I'm pretty sure that there's no way Xcode will understand a .la file.
>
> I'm under the (possibly mistaken?) impression that .dylibs are aware of
> their dependencies.  I could be wrong about that; or there could be
> something wrong with the way libopenvrml.dylib was created such that
> this isn't working as it should.
>
> libopenvrml doesn't depend on much; but off the top of my head, there's
> libboost_thread and libxml.
>
>> Even though Xcode knows the library search path does not seems to be
>> searching for dylibs. How this can be?
>
> I'm not sure exactly what you mean here; but if the question is, "Why
> aren't the .dylib dependencies being pulled in automatically?" see
> above.
>
>> I am kind of lost here. I have a big program that requires VRML in the
>> last part and would like to have it running in Mac OS also.
>>
>> I am using OpenVRML 1.8.5, SnowLeopard 10.6.3 and Xcode 3.2.3
>> (Pre-release <- Is this the reason??)
>
> Based on what I know so far, probably not.
>
> --
> Braden McDaniel <br...@en...>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> openvrml-develop mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvrml-develop
>



-- 
________________________________
慶應義塾大学大学院　理工学研究科
開放環境科学専攻　斎藤英雄研究室
修士２年　Guillermo Ignacio Enriquez G.
e-mail : 　na...@hv...
________________________________
_____________________________________________

Re: [openvrml-develop] OpenVRML in MacOS - Linker Errors

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

On Sun, 2010-05-09 at 06:17 +0900, Ignacio Enriquez wrote: 
> Hi, all
> Long time ago I did almost the same question:
> http://old.nabble.com/NEWBIE:-using-openvrml-in-mac-OS-10.6-td26253956.html
> I had troubles setting my project in Xcode with openvrml from Macports.
> 
> Now, I did as suggested but I found that Xcode does not link necessary
> dylibs. (They have to be explicitly added to the project)
> sample: pretty_print.cpp compiles ok, but fails when linking.
> So I dug into /opt/local/libs and brought libopenvrml.9.dylib into
> Xcode and 13 link errors became 6!. (So my theory is right)
> Also found libopenvrml.la file and realized that there are many
> dependency libraries. So, doing this manually is like a never-ending
> work.

.la are "libtool libraries", which is to say that they are actually text
files with information for libtool (which is typically known as glibtool
on your Mac).

> So my questions are:
> What are the dylibs needed to get pretty_print.cpp to work?

Well, give us a hint, at least: what symbols are undefined?

> Is there any way I can make Xcode read *.la files? (or an alternative
> way?) so he can link libraries automatically.

I'm pretty sure that there's no way Xcode will understand a .la file.

I'm under the (possibly mistaken?) impression that .dylibs are aware of
their dependencies.  I could be wrong about that; or there could be
something wrong with the way libopenvrml.dylib was created such that
this isn't working as it should.

libopenvrml doesn't depend on much; but off the top of my head, there's
libboost_thread and libxml.

> Even though Xcode knows the library search path does not seems to be
> searching for dylibs. How this can be?

I'm not sure exactly what you mean here; but if the question is, "Why
aren't the .dylib dependencies being pulled in automatically?" see
above.

> I am kind of lost here. I have a big program that requires VRML in the
> last part and would like to have it running in Mac OS also.
> 
> I am using OpenVRML 1.8.5, SnowLeopard 10.6.3 and Xcode 3.2.3
> (Pre-release <- Is this the reason??)

Based on what I know so far, probably not.

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

[openvrml-develop] OpenVRML in MacOS - Linker Errors

[Ignacio E. <na...@gm...>]

Hi, all
Long time ago I did almost the same question:
http://old.nabble.com/NEWBIE:-using-openvrml-in-mac-OS-10.6-td26253956.html
I had troubles setting my project in Xcode with openvrml from Macports.

Now, I did as suggested but I found that Xcode does not link necessary
dylibs. (They have to be explicitly added to the project)
sample: pretty_print.cpp compiles ok, but fails when linking.
So I dug into /opt/local/libs and brought libopenvrml.9.dylib into
Xcode and 13 link errors became 6!. (So my theory is right)
Also found libopenvrml.la file and realized that there are many
dependency libraries. So, doing this manually is like a never-ending
work.

So my questions are:
What are the dylibs needed to get pretty_print.cpp to work?
Is there any way I can make Xcode read *.la files? (or an alternative
way?) so he can link libraries automatically.

Even though Xcode knows the library search path does not seems to be
searching for dylibs. How this can be?

I am kind of lost here. I have a big program that requires VRML in the
last part and would like to have it running in Mac OS also.

I am using OpenVRML 1.8.5, SnowLeopard 10.6.3 and Xcode 3.2.3
(Pre-release <- Is this the reason??)

Thanks in advance.

Ignacio.


-- 
________________________________
慶應義塾大学大学院　理工学研究科
開放環境科学専攻　斎藤英雄研究室
修士２年　Guillermo Ignacio Enriquez G.
e-mail : 　na...@hv...
________________________________
_____________________________________________

Re: [openvrml-develop] OpenVRML crashes when loading wrl file

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

On Fri, 2010-05-07 at 21:52 +0900, Lewske Wada wrote: 
> Hi people,
> I managed to get OpenVRML built and installed in Debian.
> I can show the window of openvrml-player but when I try to
> open a file it shuts down with the following message :
> 
> ** (openvrml-player:20172): CRITICAL **: Browser creation failed: Launch
> helper exited with unknown return code 127
> **
> ** ERROR:(openvrml-player/curlbrowserhost.cpp:360):void
> openvrml_player_curl_browser_host_load_url(OpenvrmlPlayerCurlBrowserHost*,
> const char*): assertion failed: (host->priv->browser)
> 
> Any suggestion?
> I searched the web and hit this solution, but I don't know how to invoke
> http://old.nabble.com/openvrml-player-crashing-td21597081.html
> "openvrml-xembed" manually.
> 
> Your help would be greatly appreciated.

openvrml-xembed gets installed in PREFIX/libexec.  If you've installed
OpenVRML, you can run it from there.

However, if you have installed OpenVRML, it should get started
automatically.  It's not clear why that's not happening.  Did you
install it to the same prefix as D-Bus?  (If you didn't, that's the
problem.)

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

[openvrml-develop] OpenVRML crashes when loading wrl file

[Lewske W. <ry...@ru...>]

Hi people,
I managed to get OpenVRML built and installed in Debian.
I can show the window of openvrml-player but when I try to
open a file it shuts down with the following message :

** (openvrml-player:20172): CRITICAL **: Browser creation failed: Launch
helper exited with unknown return code 127
**
** ERROR:(openvrml-player/curlbrowserhost.cpp:360):void
openvrml_player_curl_browser_host_load_url(OpenvrmlPlayerCurlBrowserHost*,
const char*): assertion failed: (host->priv->browser)

Any suggestion?
I searched the web and hit this solution, but I don't know how to invoke
http://old.nabble.com/openvrml-player-crashing-td21597081.html
"openvrml-xembed" manually.

Your help would be greatly appreciated.

Cheers,
Ryu : http://run.sh/

[openvrml-develop] Is there a crop like function in openVRML

[Ignacio E. <na...@gm...>]

Hi,
I would like to plot some VRML models using openVMRL but I wonder if
there is a function or method that I can use for plotting this models
partially.
Some kind of crop but for models in 3D.
For example a function that renders a big model but only the part that
are inside a certain cube. parts outside the cube will be ignored and
not rendered.

If there is no such a function in openVMRL is there such a function in
OpenGL maybe?
I hope I can get some help.

Thanks in advance.

Ignacio.

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

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

On Thu, 2010-04-01 at 15:57 -0400, Braden McDaniel wrote: 
> 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.

This bug continues to elude me. :-(

I have discovered a few things...

      * Even if I comment out all of the texture URLs in pngboxes.wrl, I
        get a segfault in sdl-viewer occasionally.  So there's
        *something* screwy going on irrespective of the image loading
        code. 
      * Fiddling with valgrind has made it clear that Text nodes are
        leaky. But, since valgrind isn't showing a lot of the symbols in
        its backtrace to the allocation point, tracking the leaks down
        is difficult.  I found one spot where we were leaking FT_Glyphs
        and fixed it; but it seems there's more.  However, it seems
        unlikely that this is the source of the memory *corruption* that
        appears to be happening. 
      * One somewhat ominous looking message I'm getting from valgrind
        is pointing to my Spirit-based node metatype identifier parser
        (which is just a minor augmentation of my URI parser).  It's not
        obvious to me that I'm doing something wrong here; conceivably
        there's some threading-related bug in Spirit.  However, Spirit
        has been substantially rewritten since I wrote this; and my code
        has not been updated to take advantage of the new version.  As I
        doubt the Spirit developers are hugely interested in possible
        obscure bugs in the old version of their project, my next step
        is to rewrite my URI and node metatype identifier parsers using
        Spirit2.

One nice side effect of me combing through the text rendering code is
that I have broken some big scary functions into smaller scary
functions.

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

Re: [openvrml-develop] A few Questions

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

On Fri, 2010-04-30 at 16:10 +0200, Christian Lang wrote: 
> > > > What do you have OPENVRML_NODE_PATH set to?
>  > > >
>  > > to [blabla]\openvrml-0.18.5\openvrml-0.18.5\src\node
>  >
>  > That's probably not correct.  It needs to be set to where the DLL
>  > modules are located (i.e., vrml97.dll, x3d-core.dll, etc.).
> 
> Yep, that was the problem. But for the sake of completeness:
> 
>  > 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.)
> 
> It seems to be:
> 
> 0x00e5d000 "urn:X-openvrml:node:Anchor"
> 
> and it points to:
> 
> 117 'u'
> 
> But with the correct setting of OPENVRML_NODE_PATH this does not occur 
> any more.
> By the way, this (the setting of OPENVRML_NODE_PATH) is a point missing 
> on the wiki page.

Yup, I thought that would be it.

And you're right... the correct setting for OPENVRML_{NODE,SCRIPT}_PATH
could be made clearer to Visual Studio users.  I'll put this on the Wiki
page, and possibly augment README as well.

> > It sounds like there's probably something wrong with the program you're
>  > using to unpack the tarball.  Make sure the program supports the tar pax
>  > format.
> 
> I used 7zip for that, but i will use the svn sources from now on.

Then also note

        http://svn.openvrml.org/svnroot/openvrml/tags

... where you'll find the tagged releases that correspond to release
tarballs.

The pax format has been around for a while and is well supported on
POSIXy systems.  It's a little surprising that a modern tool wouldn't
work with it.  (Note that I started using this format precisely to
support the path lengths in the openvrml tarball.)  You might want to
try something like WinZip; at the very least, I'm sure that GNU tar
(which you could get with Cygwin) would work.

But if you're comfortable using svn, that's just fine, too.

> Now it seems to work so far (my world loads), but with the svn sources i 
> get some errors in the output about some "incorrect handle"s.

This isn't ringing any bells for me.  Can you provide more details?

> By the way, is there already a implemented way to rotate the world 
> around another point than the centre?

No.  But a patch to implement this per the X3D
Viewpoint.centerOfRotation field would be welcome.

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

Re: [openvrml-develop] A few Questions

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

 > > > What do you have OPENVRML_NODE_PATH set to?
 > > >
 > > to [blabla]\openvrml-0.18.5\openvrml-0.18.5\src\node
 >
 > That's probably not correct.  It needs to be set to where the DLL
 > modules are located (i.e., vrml97.dll, x3d-core.dll, etc.).

Yep, that was the problem. But for the sake of completeness:

 > 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.)

It seems to be:

0x00e5d000 "urn:X-openvrml:node:Anchor"

and it points to:

117 'u'

But with the correct setting of OPENVRML_NODE_PATH this does not occur 
any more.
By the way, this (the setting of OPENVRML_NODE_PATH) is a point missing 
on the wiki page.


 > It sounds like there's probably something wrong with the program you're
 > using to unpack the tarball.  Make sure the program supports the tar pax
 > format.

I used 7zip for that, but i will use the svn sources from now on.

Now it seems to work so far (my world loads), but with the svn sources i 
get some errors in the output about some "incorrect handle"s.

By the way, is there already a implemented way to rotate the world 
around another point than the centre?

Re: [openvrml-develop] A few Questions

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

On Thu, 2010-04-29 at 12:52 +0200, Christian Lang wrote: 
> > Perhaps it was not set correctly.
> >    
> I think it was, because the 0.17.12 version worked fine.

0.17.x does not require this setting.

> Could it be 
> that blanks in the path are a problem?
> I'll try around more tomorrow.

I don't *think* spaces in the path are a problem; but this might be
worth testing.

> >> (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.

They're correct in the tarball, too:

        $ tar tvf openvrml-0.18.5.tar.gz | grep x3d-environmental-effects[.]vcproj
        -rw-r--r-- braden/users    4598 2009-07-04 17:20 openvrml-0.18.5/ide-projects/Windows/VisualC9_0/OpenVRML/x3d-environmental-effects/x3d-environmental-effects.vcproj
        $ tar tvf openvrml-0.18.5.tar.gz | grep x3d-event-utilities[.]vcproj
        -rw-r--r-- braden/users    5904 2009-07-04 17:20 openvrml-0.18.5/ide-projects/Windows/VisualC9_0/OpenVRML/x3d-event-utilities/x3d-event-utilities.vcproj
        $ tar tvf openvrml-0.18.5.tar.gz | grep x3d-key-device-sensor[.]vcproj
        -rw-r--r-- braden/users    4785 2009-07-04 17:20 openvrml-0.18.5/ide-projects/Windows/VisualC9_0/OpenVRML/x3d-key-device-sensor/x3d-key-device-sensor.vcproj
        
It sounds like there's probably something wrong with the program you're
using to unpack the tarball.  Make sure the program supports the tar pax
format.

> > 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.

Yes, the page was incorrect.  You want the "LIB Release" and "LIB Debug"
configurations.

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

Yeah; but I think this is a bug in the 0.17 project files.  The OpenVRML
project files are set up to be built with /MD(d); so its dependencies
should match that.

> > [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

That's probably not correct.  It needs to be set to where the DLL
modules are located (i.e., vrml97.dll, x3d-core.dll, etc.).  Similarly,
OPENVRML_SCRIPT_PATH needs to be set to where the scripting engine
modules live (javascript.dll and java.dll).

> > 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
> ?

branches/0.18 is what future 0.18.x releases will be made from.  trunk
will become 0.19.0.

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