openvrml-develop — OpenVRML developers mailing list

[openvrml-develop] Re: Vrml97Parser Performance

[Damian M. <da...@er...>]

In our quest for speed, we inline'd _GetNextChar() and it turns out that
on a 1000Mhz Pentium, isNewLineChar() is chewing up 10% of the time on
nextToken().

I was thinking of inlining all the routines in the anonymous namespace.

Some questions:

a)	Could we come up some 'ctype' like scheme whereby we assume
	that char is signed and we do a table lookup?

b)	Alternatively, is a test such as

	(isdigit(c) || ('A' <= c && c <= 'F') || ('a' <= c && c <= 'f'))

	always valid for a hex digit.

While I fully appreciate that one should get it right before you make it
fast, we find that if something takes ages to load, be it a VRML file or
a web page, then users will complain.

Thanks - Damian (McGuckin)

Pacific Engineering Systems International, 22/8 Campbell St, Artarmon NSW 2064
Ph:+61-2-99063377 .. Fx:+61-2-99063468   | unsolicited email not wanted here !
Views and opinions here are mine and not those of any past or present employer

[openvrml-develop] Transparency

[Damian M. <da...@er...>]

This has been open for over a year.  I'd like to close it.

There are two issues with transparency, one associated with materials and
one with images that have transparent parts.  Apparently neither work.

I have looked at the bug page and it doesn't give me much of a hint except
to say that with z-buffers it is a problem.

In 'ViewerOpenGL::insertTexture', it mentioned

	// Enable blending if needed
  	if (d_blend && (nc == 2 || nc == 4))
    		glEnable(GL_BLEND);

Don't we need an extra

	glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

or does the one in ViewerOpenGL::initialize cover us forever.  There is a
glDisable(GL_BLEND) in ViewerOpenGL::redraw() and I thought that this
clobbered the glBlendFunc().  I am a long way away from being an OpenGL
guru.

Heaven only knows what to do with Material transparency.

Can anybody direct me to where there are some simple files to try this
out?  And/or any theory that might be useful especially in the context of
OpenVRML and its usage in the context of OpenGL.

Thanks - Damian (McGuckin)

Pacific Engineering Systems International, 22/8 Campbell St, Artarmon NSW 2064
Ph:+61-2-99063377 .. Fx:+61-2-99063468   | unsolicited email not wanted here !
Views and opinions here are mine and not those of any past or present employer

[openvrml-develop] Re: Speed Issues

[Damian M. <da...@er...>]

A while ago, I mentioned ...

> The killer, at least for the type of data we have, appears to be the
> call to
>
> 	gluScaleImage(....)
>
> Eliminating this call during operations reduces load time from 24 seconds
> down to 15 seconds.  Mind you, the only way to properly eliminate this
> call is to preprocess your images before to ensure your images are nice
> sizes when they hit memory.  That almost seems like a mandatory item when
> using OpenVRML.  Preprocess your images or suffer a performance hit.

Or, better still rewrite 'gluScaleImage'.

Going to Mesa and #define'ing it to use point-sampling instead of using
the standard OpenGL box filter does the trick also.  The box filter
exercises the CPU something fierce.  This really needs to be rewritten
using templates but that can wait.

This routine only manipulates the image. It does nothing graphically.

> However, a quick perusal of the code shows us that in the line where this
> routine is (effectively) called that we have a comment there which warns
> us ....
>
> 	      // Always scale images down in size and reuse the same pixel
> 	      // memory. This can cause some ugliness...
>
> Can anybody enlighten me as to the ugliness that this will cause?

Let's look at the fundamentals of the box filter used in the original
routine. Assume you have a VRML scene which say visualizes features which
are sharp. If you are applying the texture at approximately the same
resolution as the texture image was stored at, then, yes, you will get
some ugliness because sharp features might get smoothed.  The point
sampling method avoids smoothing/blurring of sharp features as and the
performance saving is big, big, big.  Mind you, you can probably find
images where smoothness is an issue and this can also cause grief.

We had jobs where the processing of the initial VRML load was taking 10
seconds, and the graphics 1 second, and then 191 textures took 20 seconds
to process on a 1000Mhz PIII.  On a Celeron 550, load processing went down
to 20 odd seconds from something approaching 2 minutes.

Thanks - Damian (McGuckin)

Pacific Engineering Systems International, 22/8 Campbell St, Artarmon NSW 2064
Ph:+61-2-99063377 .. Fx:+61-2-99063468   | unsolicited email not wanted here !
Views and opinions here are mine and not those of any past or present employer

[openvrml-develop] Re: Speed Issues

[Damian M. <da...@er...>]

> Also, the initial display of the VRML file, from load, has both texturing
> and alpha-blending turned on.
>
> How would I make the start-up ignore these without affecting the Viewer's
> ability to turn them back on?

That appears to be largely a waste of time.

The killer, at least for the type of data we have, appears to be the
call to

	gluScaleImage(....)

Eliminating this call during operations reduces load time from 24 seconds
down to 15 seconds.  Mind you, the only way to properly eliminate this
call is to preprocess your images before to ensure your images are nice
sizes when they hit memory.  That almost seems like a mandatory item when
using OpenVRML.  Preprocess your images or suffer a performance hit.

However, a quick perusal of the code shows us that in the line where this
routine is (effectively) called that we have a comment there which warns
us ....

	      // Always scale images down in size and reuse the same pixel
	      // memory. This can cause some ugliness...

Can anybody enlighten me as to the ugliness that this will cause?

Thanks - Damian (McGuckin)

Pacific Engineering Systems International, 22/8 Campbell St, Artarmon NSW 2064
Ph:+61-2-99063377 .. Fx:+61-2-99063468   | unsolicited email not wanted here !
Views and opinions here are mine and not those of any past or present employer

Re: [openvrml-develop] help with build - macOS 9 ?

[Tom F. <tf...@us...>]

Hi John,

Don't suppose you have a site up showing off SimVRMLLookat? I'd love to 
see some screenshots and get some more information on what you're using 
it for. It'd be nice to have another project to add to the list at 
http://openvrml.sourceforge.net/links.php :-)

Later,
Tom

----- Original Message -----
From: John Richardson <ric...@sp...>
To: <ope...@li...>
Sent: Monday, December 17, 2001 1:52 PM
Subject: Re: [openvrml-develop] help with build - macOS 9 ?

> Hello,
>
> I have a speech enabled user interface for OpenVRML 0.10.1. It is called
> SimVRMLLookat. It leverages off of the MacLooakat application. The User
> interface was developed using the SuperCard IDE and it also has a "G"
> language version developed using the Labview IDE for real time data
> acquisition.

<snip>

[openvrml-develop] Speed Issues

[Damian M. <da...@er...>]

I've done some simple speed gains in the MathUtils.cpp code.  They were
basically implementations loop unrolling and elimination of Mcopy and
other temporary space that was redundant.

However, I can't put it into a form to go into the current tree because
I can't do a clean build from the current tree.

While I can pull down the current tree for openvrml-0.11.latest, I can't
build a release with all the other stuff.  I seem to be missing something.
What's the trick?

Also, the initial display of the VRML file, from load, has both texturing
and alpha-blending turned on.

How would I make the start-up ignore these without affecting the Viewer's
ability to turn them back on?

Thanks - Damian (McGuckin)

Pacific Engineering Systems International, 22/8 Campbell St, Artarmon NSW 2064
Ph:+61-2-99063377 .. Fx:+61-2-99063468   | unsolicited email not wanted here !
Views and opinions here are mine and not those of any past or present employer

[openvrml-develop] Re: Doc2 - adding big buffer

[Damian M. <da...@er...>]

On Sun, 23 Dec 2001, Damian McGuckin wrote:

> I need to increase the speed of loading big, multi-megabyte VRML files.

The change was a lot simpler than what I had tried in the first place.

I changed the size of the buffer declared in doc2 to 65535 and achieved
nearly a factor of two performance gain on big files.  The load time went
from 44 seconds down to 24 on a 1000Mhz Pentium over a 100Mbit/sec
network.

Not as much as I had hoped but better than nothing.

I tried to profile this under LINUX but to no avail.  I compiled it with
a '-p' flag and it core dumped.  Took out the '-p' and it worked.  Looks
like it is more the profiling rather than anything else.

Anybody got ideas on where to target performance problems?

I need to get the scene complexity down a bit in these big files.  I saw
something called Chisel and Vorlon.  Do they do anything?

Has anybody considered having precompiled VRML files which are loaded
directly?

Happy Christmas - Damian (McGuckin)

Pacific Engineering Systems International, 22/8 Campbell St, Artarmon NSW 2064
Ph:+61-2-99063377 .. Fx:+61-2-99063468   | unsolicited email not wanted here !
Views and opinions here are mine and not those of any past or present employer

[openvrml-develop] Doc2 - adding big buffer

[Damian M. <da...@er...>]

I need to increase the speed of loading big, multi-megabyte VRML files.
They are of the order of 5MB. These then include another 30MB of related
VRML files, URLs related to textures, and the like.  To this end, I
proposed to change the size of the file buffers used by the classes Doc
and Doc2.

Correct me if whatever follows is garbage.

I think that a Doc is fairly easy.  I have added a extra entry to the
class which is an internal buffer and when a file is opened with

	::fopen

I simply allocate a lot of space and, like any STDIO file, use setvbuf.
I'll make it easy to change this size at a later stage.

Doc2 is a little more difficult.  It uses 'streambuf' and 'istream' but
then replaces their open functions and effectively.  In 'filebuf::open',
it simply calls the global gzopen out of 'ZLIB', i.e.

	gzFile gzopen(const char *path, const char *mode);

Then with the STDIO file,

	this->file

we new up some more buffer space, assign this space to the FILE with
another setvbuf and away we go.

This looks too simple. I might be getting in the road of other logic.

And have I missed something?  Does it go elsewhere in the code if the file
is not gzipped?

In the past, I have generally done my own big buffering and stayed away
from IOSTREAMs whenever performance was an issue so my experience in this
area is a little sparse.

Thanks - Damian (McGuckin)

Pacific Engineering Systems International, 22/8 Campbell St, Artarmon NSW 2064
Ph:+61-2-99063377 .. Fx:+61-2-99063468   | unsolicited email not wanted here !
Views and opinions here are mine and not those of any past or present employer

[openvrml-develop] Performance improvements

[Damian M. <da...@er...>]

We are trying to improve the performance of OpenVRML.

The simplest step is increasing the buffer size in reads.

I have put a big buffer into Doc but putting a larger buffer (cleanly)
into the IOSTREAM used by Doc2 has me stumped. I've never tried to do this
before.  Anybody got any ideas.

Also, we are looking at trying to defer the processing of some the texture
files ( and the like ) until they are needed or even trying to use some
asynchronous I/O portably between Windows and Unix ( and eventually Mac ).

What about simplifying the actual geometry you are displaying until you
are (visually) closer to the object?

Thanks - Damian (McGuckin)

Pacific Engineering Systems International, 22/8 Campbell St, Artarmon NSW 2064
Ph:+61-2-99063377 .. Fx:+61-2-99063468   | unsolicited email not wanted here !
Views and opinions here are mine and not those of any past or present employer

Re: [openvrml-develop] help with build - macOS 9 ?

[Michael L. <Mic...@hr...>]

On Monday, December 17, 2001, at 06:52 , John Richardson wrote:

> The ultimate future of OpenVRML on the Mac is OS X.
>
The OpenVRML libraries and Lookat should compile just fine under Mac OS X 
-- the few minor changes that were needed in order to compile were made a 
while back, although a little hacking of the build system may still be 
necessary (instructions have been posted here in the past by a couple of 
different people) in order to build the make files and get the binary 
files to link. I think Braden has updated the autoconf setup to take Mac 
OS X into account, so the next release may build without the need to hack,
  but I haven't had time to do much recently and have not therefore been 
able to contribute with the testing and feedback required.

Sourceforge has a Mac OS X box in its compile farm which would enable 
folks without direct access to a Mac to try compiling on one, but 
unfortunately it has not been useful since Apple's developer tools are 
missing a couple of vital GNU tools that Sourceforge won't install 
individually. Apple released an update a couple of days ago, which may 
have rectified this problem (it's a 200Mb download and Apple' site has 
been very busy so I haven't got hold of a copy yet).

I haven't had any time at all to contribute to hobby coding the last few 
months (and even more significantly, don't have a PPC Mac at home at the 
moment). Hopefully in 2002...

Mike.

Re: [openvrml-develop] help with build - macOS 9 ?

[John R. <ric...@sp...>]

Hello,

I have a speech enabled user interface for OpenVRML 0.10.1. It is called
SimVRMLLookat. It leverages off of the MacLooakat application. The User
interface was developed using the SuperCard IDE and it also has a "G"
language version developed using the Labview IDE for real time data
acquisition.

I'll be dragging the GUI to Macworld and I'll be hanging out at the Robolab
BOF. Robolab is a Labview based IDE for Lego Minstormes. I will be
attempting to get OpenVRML compiled before the show with CW 7 and if the
problems persist I'll try to hobnob (U.S. slang for consult)  with the
metrowerks people. I will also attempt to place the modified MacLookat GUI
in the Source forge repository before Macworld SF. Note that SuperCard is a
rapid prototyping tool for user interfaces. So you can easily make VRML
GUI's that match your desires and specifications within the current SimVRML
API. The SimVRML system has an API for Navigation only at this time.
SuperCard is in the 100 USD range.

Now, back to the original problem.

The basic problem is that Metrowerks made MAJOR changes to the IDE after
version 4.0 of the IDE which equals version 5 of Codewarrior. Version 6 or
7 are using IDE 4.1 or higher. Now, the claim from Metrowerks is:
	"The Metrowerks compiler now STRICTLY supports the C / C++ ISO
standard"

That translates into the vernacular as "We don't allow any slop (= junk,
trash, and generally clever code)"

So, either

1) Metrowerks remade their IDE so that it messes with our heads.
Unintentionally of course. Note that they inlined a lot of utilities so the
libraries are different.

OR

2) OpenVRML code was designed and patched to make things work, including
clever little patches which now have come back to haunt us when compilers
play by the rules. This does not mean the overall OpenVRML design is bad.

Now, the only reason that I am having this discussion is that SuperCard (or
Metacard or Director or HyperCard or Applescript) and Labview are not Mac
OS X native. National Instruments and Incwell have announced OS X ports. An
Applescript IDE will be native on OS X shortly. So for the next year to 18
months there will be a reason to use CW 5 and possibly CW 6/7 to produce OS
9 GUI's for OpenVRML. The ultimate future of OpenVRML on the Mac is OS X.
Mike Louka is the guru for that effort.

Other comments

Note: I am using Plaintalk based speech recognition to substitute for
joysticks and other devices.

Trackers --- Somewhere on my list is a task to compile the Intersense C
code for their tracker. I have previously compiled it for SGI IRIX. The
code comes compiled for Windows and the source has Windows and UNIX
compiler directives. I can also attach a tracker to a Java 2 application
and so this is a good sign for Mike's OS X effort. However, the tracker
system is expensive (1500 USD). All tracker systems are expensive.

Now, Macworld magazine had an article on essential reality's glove. It is
rumoured to cost 130 USD and to be available about the time of Macworld SF
or shortly after. So, that would be my first choice to work on until
tracker / eyeglass combinations come down below the 200-300 USD range that
people are used to paying for Playstations and xbox's.

Joysticks are somewhere on my list.

John F. Richardson

>hello,
>
>i'm new to the openVRML project and am having a little trouble building
>openvrml-0.11.2 under MacOS 9.2, CodeWarrior 7.   i'll also admit to not
>being a professional programmer by any means, so there's an element of
>blind guessing here too.  anyway, here's the issues i've run into:
>
>* buildall seemed to be missing ...
>
>* couldn't import XML project files - seemed to expect another space at the
>end of the first tag.
>
>* when building OpenVRMLgl, got an error in ViewerOpenGL.h
>
>class OPENVRML_GL_SCOPE ViewerOpenGL : public Viewer {
>
>removed 'OPENVRML_GL_SCOPE' and then built w/o complaining.
>
>* then tried to build OpenVRMLcore.  Many errors appeared, relating to
>missing files.  some of them weren't in src/openvrml/OpenVRML,
>particularly many of the VrmlNode classes.  I found many of them in a
>prior release (0.10) so most of those errors were satisfied...
>
>* ScriptJS.cpp seems truncated.  file begins
>
>);
>
>      for (int i=0; i<(int)len; ++i)
>	{
>	  jsval elt;
>
>
>halfway through the function before
>static JSBool eventOut_setProperty(JSContext *cx, JSObject *obj, jsval id,
>jsval *val)
>
>tried re-downloading and expanding the files and came up with the same
>result each time.  is this likely to be something wrong with my
>compression software (MacGZip and Stuffit?)
>
>Also, is each version download a complete build, or are update versions
>dependent on other ones?
>
>thanks in advance for any help - i'd be very excited to get this running.
>much kudos to all involved in this project.   i've been working with VRML
>for
>the past few years for online art projects, and it's wonderful to see
>thhat it
>and X3D are continuing to evolve ... this project in particular is very
>exciting
>
>to me because I've been repeatedly stumped by missing features or bugs
>in orphaned commercial viewers, so the prospect of at least knowing why
>things aren't working <g> or hopefully adding additional features is
>terrific.
>
>i don't know if anyone's working on these yet, but I'd like to see things
>like
>tracker support, stereo, video input and tracking, and communication
>capability (sockets or serial port) to attach homebrewed interface devices,
>sound servers, etc.  for VR installations as well as web-based worlds.
>
>thanks,
>
>
>--ben chang
>bc...@ar...
>Art & Technology, School of the Art Institute of Chicago
>
>_______________________________________________
>openvrml-develop mailing list
>ope...@li...
>https://lists.sourceforge.net/lists/listinfo/openvrml-develop

Re: [openvrml-develop] help with build - macOS 9 ?

[Michael L. <Mic...@hr...>]

I don't think anyone has sucessfully compiled OpenVRML on anything newer 
than CodeWarrior 5.3 since OpenVRML 0.10.x. In other words, it needs 
some work to get it to build using CodeWarrior under the classic Mac OS.

BuildAll is in the source archive on CVS but has not been updated for a 
while. BuildAll appears to be missing in the distribution... All the 
CodeWarrior build files are for CW5.3.

John F. Richardson on this list has been looking at getting the code to 
compile under CodeWarrior 6, but I don't think he managed to resolve all 
the compiler-related problems he had.

At the moment, it is easier to get OpenVRML to compile on Mac OS X using 
the developer CD that comes with the OS, or to compile an older version 
of OpenVRML.

Michael.


bc...@ar... wrote:

> 
> 
> hello,
> 
> i'm new to the openVRML project and am having a little trouble building 
> openvrml-0.11.2 under MacOS 9.2, CodeWarrior 7.   i'll also admit to not 
> being a professional programmer by any means, so there's an element of 
> blind guessing here too.  anyway, here's the issues i've run into:
> 
> * buildall seemed to be missing ...
> 
> * couldn't import XML project files - seemed to expect another space at the 
> end of the first tag.  
> 
[snip]

[openvrml-develop] help with build - macOS 9 ?

[<bc...@ar...>]

hello,

i'm new to the openVRML project and am having a little trouble building 
openvrml-0.11.2 under MacOS 9.2, CodeWarrior 7.   i'll also admit to not 
being a professional programmer by any means, so there's an element of 
blind guessing here too.  anyway, here's the issues i've run into:

* buildall seemed to be missing ...

* couldn't import XML project files - seemed to expect another space at the 
end of the first tag.  

* when building OpenVRMLgl, got an error in ViewerOpenGL.h

class OPENVRML_GL_SCOPE ViewerOpenGL : public Viewer {

removed 'OPENVRML_GL_SCOPE' and then built w/o complaining.  

* then tried to build OpenVRMLcore.  Many errors appeared, relating to 
missing files.  some of them weren't in src/openvrml/OpenVRML, 
particularly many of the VrmlNode classes.  I found many of them in a 
prior release (0.10) so most of those errors were satisfied...

* ScriptJS.cpp seems truncated.  file begins

);

      for (int i=0; i<(int)len; ++i)
	{
	  jsval elt;


halfway through the function before 
static JSBool eventOut_setProperty(JSContext *cx, JSObject *obj, jsval id, 
jsval *val)

tried re-downloading and expanding the files and came up with the same 
result each time.  is this likely to be something wrong with my 
compression software (MacGZip and Stuffit?)  

Also, is each version download a complete build, or are update versions 
dependent on other ones?

thanks in advance for any help - i'd be very excited to get this running.  
much kudos to all involved in this project.   i've been working with VRML for  
the past few years for online art projects, and it's wonderful to see thhat it 
and X3D are continuing to evolve ... this project in particular is very exciting

to me because I've been repeatedly stumped by missing features or bugs 
in orphaned commercial viewers, so the prospect of at least knowing why 
things aren't working <g> or hopefully adding additional features is terrific.  

i don't know if anyone's working on these yet, but I'd like to see things like 
tracker support, stereo, video input and tracking, and communication 
capability (sockets or serial port) to attach homebrewed interface devices, 
sound servers, etc.  for VR installations as well as web-based worlds.  

thanks,


--ben chang
bc...@ar...
Art & Technology, School of the Art Institute of Chicago

[openvrml-develop] Re: Tracking down wrong value of d_relativeUrl

[Damian M. <da...@er...>]

Tom mentioned the problem was ...

>     if (currentRel.length() == 0 || relativeUrl.length() == 0
>             || currentRel != relativeUrl) {
>         this->d_relative.set(relativeUrl);
>     }

The patch actually was something like 'trash the comparison', i.e. discard

>             || currentRel != relativeUrl) {

so you ended up with something like

>     if (currentRel.length() == 0 || relativeUrl.length() == 0)
>         this->d_relative.set(relativeUrl);

or against 0.11.2

	if (!currentRel || !relativeUrl )
		d_relative.set(relativeUrl);

> I've done some regression testing using the NIST conformance tests of
> the different grouping nodes and no new problems have appeared. I'd
> appreciate it though if others could take a look at the patch to
> verify the sanity of the change.

Well, it WORKs against my data sets as well.

Tom was worried whether it broke anything else.

The new logic appears to be basically

	If current Relative URL is already set, don't change
	it unless you are being asked to wipe it clear

What my question is what was the originally intended logic?  Besides the
logic to handle 'inline url URLNAME', where else is it used?

As VrmlNodeGroup is itself a base class, what objects actually end up
using the method VrmlNodeGroup::addToScene.  I found it extremely hard to
figure out which object/method was doing what with both GDB and even my
own diagnostics using 'theSystem->debug'.  The design of the inheritance
almost makes everything appear global but with the disadvantage that you
can't see which variable is which.  It is the benefits of data-hiding in
reverse. We seem to be loosing some of the great benefits of OO program.
My $0.01 worth.

Thanks - Damian (McGuckin)

Pacific Engineering Systems International, 22/8 Campbell St, Artarmon NSW 2064
Ph:+61-2-99063377 .. Fx:+61-2-99063468   | unsolicited email not wanted here !
Views and opinions here are mine and not those of any past or present employer

Re: [openvrml-develop] Re: Tracking down wrong value of d_relativeUrl

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

On Mon, 2001-12-03 at 18:14, Damian McGuckin wrote:
> 
> Well, it was d_relative but Thomas found the right place.
> 
> > Patch #488262 has been submitted for this problem. This patch fixes bug
> > #225694 as well.
> 
> > > Commenting out the following lines will allow the image to be correctly.
> > >
> > >    if (currentRel.length() == 0 || relativeUrl.length() == 0
> > >            || currentRel != relativeUrl) {
> > >        this->d_relative.set(relativeUrl);
> 
> With regard to getting the patch, probably a dumb question, but having
> never done it before, ...
> 
> I can't login to cvs because I am not registered and don't really
> understand the registration process and whether it needs to ve vetted.

You don't need a SourceForge account to get anonymous access to CVS:

    <http://sourceforge.net/cvs/?group_id=7151>

> And because I don't know the module name, I can't get the patch.

The module name is "openvrml". To get the patch, just download it from
the patch manager:

    <http://sourceforge.net/tracker/index.php?func=detail&aid=488262&group_id=7151&atid=307151>

Patches can be applied with the "patch" program (or by hand, of course).

Braden

[openvrml-develop] Re: Tracking down wrong value of d_relativeUrl

[Damian M. <da...@er...>]

Well, it was d_relative but Thomas found the right place.

> Patch #488262 has been submitted for this problem. This patch fixes bug
> #225694 as well.

> > Commenting out the following lines will allow the image to be correctly.
> >
> >    if (currentRel.length() == 0 || relativeUrl.length() == 0
> >            || currentRel != relativeUrl) {
> >        this->d_relative.set(relativeUrl);

With regard to getting the patch, probably a dumb question, but having
never done it before, ...

I can't login to cvs because I am not registered and don't really
understand the registration process and whether it needs to ve vetted.

And because I don't know the module name, I can't get the patch.

Thanks - Damian (McGuckin)

Pacific Engineering Systems International, 22/8 Campbell St, Artarmon NSW 2064
Ph:+61-2-99063377 .. Fx:+61-2-99063468   | unsolicited email not wanted here !
Views and opinions here are mine and not those of any past or present employer

Re: [openvrml-develop] Tracking down wrong value of d_relativeUrl

[Thomas F. <tf...@us...>]

Patch #488262 has been submitted for this problem. This patch fixes bug 
#225694 as well.

I've done some regression testing using the NIST conformance tests of 
the different grouping nodes and no new problems have appeared. I'd 
appreciate it though if others could take a look at the patch to verify 
the sanity of the change.

Later,
Tom

Thomas Flynn wrote:

> Damian McGuckin wrote:
>
>> With 'GTKLOOKAT', I am reading a ( boring but small sample ) file
>>
>>     a.wrl
>>
>> which 'inlines' a URL file
>>
>>     model/c.wrl
>>
>> which in turn reads a URL (image) files
>>
>>     image/asp.jpg
>>
>> The file a.wrl resides in the current directory, as does the
>> directory 'model'.  Directory 'image' resides within 'model'.
>>
>> In the first pass through the VRML nodes, done with readWwl ( which is
>> associated with a Doc ), the part of each included file, i.e. the
>> d_relativeUrl, is correct.  It uses
>>
>>     VrmlNodeInline::addToScene
>>         which (calls) VrmlNodeInline::load
>>             which (calls) VrmlScene::readWrl
>>
>>
>> However, on a second pass through, the 2nd level nested file, sky.jpg,
>> thinks its parent is a.wrl, not model/c.wrl. As a result, the nested 
>> image
>> cannot be found. I do not know where these nodes are being 
>> processed.  It
>> is definitely not readWrl.  If I ensure that the directory image is 
>> in the
>> same directory as 'a.wrl', this solves the problem but that isn't the
>> point.  I don't have control like this all the time.  VRML is 
>> supposed to
>> take care of nesting.
>>
>> I can't even figure out which routine is used to make the second pass
>> but it isn't the same as the first pass.  There seem like there are
>> many routines that do fundamentally the same thing and I am lost.
>>
> The second pass is being made in NodeInline::addToScene() on the call 
> to NodeGroup::addToScene() ... the relative URL passed into both 
> methods is null (which makes sense as the inline is at the root)  The 
> problem is that NodeGroup::addToScene resets the current relative URL 
> (the correct one determined in the first pass!) with the null URL that 
> has just been passed in.
>
> Commenting out the following lines will allow the image to be correctly.
>
>    if (currentRel.length() == 0 || relativeUrl.length() == 0
>            || currentRel != relativeUrl) {
>        this->d_relative.set(relativeUrl);
>    }
>
> This probably isn't a good fix as it likely breaks something somewhere 
> else, I'll look into this a little more and see what I come up with.
>
> Later,
> Tom
>

Re: [openvrml-develop] Tracking down wrong value of d_relativeUrl

[Thomas F. <tf...@us...>]

Damian McGuckin wrote:

>With 'GTKLOOKAT', I am reading a ( boring but small sample ) file
>
>	a.wrl
>
>which 'inlines' a URL file
>
>	model/c.wrl
>
>which in turn reads a URL (image) files
>
>	image/asp.jpg
>
>The file a.wrl resides in the current directory, as does the
>directory 'model'.  Directory 'image' resides within 'model'.
>
>In the first pass through the VRML nodes, done with readWwl ( which is
>associated with a Doc ), the part of each included file, i.e. the
>d_relativeUrl, is correct.  It uses
>
>	VrmlNodeInline::addToScene
>		which (calls) VrmlNodeInline::load
>			which (calls) VrmlScene::readWrl
>
>
>However, on a second pass through, the 2nd level nested file, sky.jpg,
>thinks its parent is a.wrl, not model/c.wrl. As a result, the nested image
>cannot be found. I do not know where these nodes are being processed.  It
>is definitely not readWrl.  If I ensure that the directory image is in the
>same directory as 'a.wrl', this solves the problem but that isn't the
>point.  I don't have control like this all the time.  VRML is supposed to
>take care of nesting.
>
>I can't even figure out which routine is used to make the second pass
>but it isn't the same as the first pass.  There seem like there are
>many routines that do fundamentally the same thing and I am lost.
>
The second pass is being made in NodeInline::addToScene() on the call to 
NodeGroup::addToScene() ... the relative URL passed into both methods is 
null (which makes sense as the inline is at the root)  The problem is 
that NodeGroup::addToScene resets the current relative URL (the correct 
one determined in the first pass!) with the null URL that has just been 
passed in.

Commenting out the following lines will allow the image to be correctly.

    if (currentRel.length() == 0 || relativeUrl.length() == 0
            || currentRel != relativeUrl) {
        this->d_relative.set(relativeUrl);
    }

This probably isn't a good fix as it likely breaks something somewhere 
else, I'll look into this a little more and see what I come up with.

Later,
Tom

[openvrml-develop] Tracking down wrong value of d_relativeUrl

[Damian M. <da...@er...>]

With 'GTKLOOKAT', I am reading a ( boring but small sample ) file

	a.wrl

which 'inlines' a URL file

	model/c.wrl

which in turn reads a URL (image) files

	image/asp.jpg

The file a.wrl resides in the current directory, as does the
directory 'model'.  Directory 'image' resides within 'model'.

In the first pass through the VRML nodes, done with readWwl ( which is
associated with a Doc ), the part of each included file, i.e. the
d_relativeUrl, is correct.  It uses

	VrmlNodeInline::addToScene
		which (calls) VrmlNodeInline::load
			which (calls) VrmlScene::readWrl


However, on a second pass through, the 2nd level nested file, sky.jpg,
thinks its parent is a.wrl, not model/c.wrl. As a result, the nested image
cannot be found. I do not know where these nodes are being processed.  It
is definitely not readWrl.  If I ensure that the directory image is in the
same directory as 'a.wrl', this solves the problem but that isn't the
point.  I don't have control like this all the time.  VRML is supposed to
take care of nesting.

I can't even figure out which routine is used to make the second pass
but it isn't the same as the first pass.  There seem like there are
many routines that do fundamentally the same thing and I am lost.

The offending (underlying) variable is d_relativeUrl.  This is a field
of

	VrmlNodeTexture
	....AudioClip
	....Background


To track this down, I need some help on understanding the structure
of these heavily nested classes.

1)
	How, from a VrmlNodeTexture node, get the d_url that belongs to
	its associated VrmlNodeImageTexture ( I have one image associated
	with each texture ).  Note that d_url belongs in

		VrmlNodeImageTexture
		........MovieTexture
		........AudioClip
		........Anchor
		........Inline

2)
	Where would the actual URL ( filename in my case ) of

		url "filename.jpg"

	be actually copied into ( what appears to be the VrmlMFString )
	d_url in VrmlNodeImageTexture which is later extracted as
	an array of URLs with the method

		d_url.get()
	or
		(char *) d_url.getElement(0)

	This might help me to isolate where the corruption is occuring.

3)
	Any other suggestions are welcomed.

Don't tell me to use 'GDB' because to use that effectively assumes you
know something about the structure and where to jump to.  I'm hoping that
somebody out there already knows the structure.  My UNIX data files are
included.

I am not a VRML expert.  I just want to view files created by anther
programs.  Before this exercise, I thought I knew something about
object-oriented programming and C++ and reusability. I am starting to
doubt that now.

As an aside, and while I marvel at this body of work, has anybody ever
pulled apart 'vrm97node.cpp' to work with each class.  10,000 lines is a
nightmare.

Thanks - Damian (McGuckin)

Pacific Engineering Systems International, 22/8 Campbell St, Artarmon NSW 2064
Ph:+61-2-99063377 .. Fx:+61-2-99063468   | unsolicited email not wanted here !
Views and opinions here are mine and not those of any past or present employer

[openvrml-develop] Re: 64MB limit ( Damian McGuckin )

[Damian M. <da...@er...>]

> I have a large VRML file that I am trying to display with GTKLOOKAT.  It
> core dumps before it seriously displays anything.  It reads the files OK.
> However, I suspects some system setting as it dumps a core file of size
>
> 	67186688 Nov 25 15:40 core

Solution - Upgrade version of Linux.

Problem goes away.

Probably somebody else's dud library.

Thanks - Damian (McGuckin)

Pacific Engineering Systems International, 22/8 Campbell St, Artarmon NSW 2064
Ph:+61-2-99063377 .. Fx:+61-2-99063468   | unsolicited email not wanted here !
Views and opinions here are mine and not those of any past or present employer

Re: [openvrml-develop] Installation Problem

[Thomas F. <tf...@us...>]

Precompiled libs for win32 can be found at
http://openvrml.org/dist/win32_required_libs.zip

I'm not a Windows guy so I'm not positive these will work with Win2000
(work fine on Win98) but they'd be worth a shot.

Later,
Tom


¹Ú ÀÎ±Ô wrote:

>I am completely a beginner in using OpenVRML.
>
>Please somebody tell me how to obtain LIB files or compilable workspace of zlib, libpng, libjpeg, and js32.
>
>Some of the URL in the readme file are closed.
>
>My platform is Win2000 with MS Visual Studio.
>
>Thanks in advance.
>¢—§¾¹¥uëޖŠfj)b?	b²Ú)z{?W^½éh¦X¬¶?(º·~Šàzw­†?i???l²‹«qçè?§zßåŠËl?X¬¶)ߣ?)z{?W^½éhp===
>

[openvrml-develop] Re: 64MB limit

[Damian M. <da...@er...>]

On Sun, 25 Nov 2001 ope...@li... wrote:

> Date: Sun, 25 Nov 2001 16:51:31 +1100 (EST)
> From: Damian McGuckin <da...@er...>
> To: <ope...@li...>
> Subject: [openvrml-develop] 64MB limit
>
> I have a large VRML file that I am trying to display with GTKLOOKAT.  It
> core dumps before it seriously displays anything.  It reads the files OK.
> However, I suspects some system setting as it dumps a core file of size
>
> 	67186688 Nov 25 15:40 core
>
> This factors to 65536 * ( 65536 + 76 ) which is too close to 64MB and too
> neat for my liking.  I am quite happy to send the ( 13MB uuencoded ) file
> to somebody else if you want to try it.

Being a bit more intelligent and trying some other big files, I am sure
that problem is not a 64MB limit.

I can get problems with other ( sort of ) smaller executable sizes ( 27MB
or so ) which also dump core as a result of a malloc() problem from within
the OpenGL library.

> The program dumps core where a 'where' in gdb with OpenVRML 0.11.2 and
> GTKlookat 0.9.1 compiles with '-g',  shows up
>
> 	#0  0x405b6f7a in malloc () from /lib/libc.so.6
> 	#1  0x405b6d3e in malloc () from /lib/libc.so.6
> 	#2  0x404c4a78 in gluTessVertex () from /usr/X11R6/lib/libGLU.so.1

As to what the problem really is, that remains to be solved.

Thanks - Damian (McGuckin)

Pacific Engineering Systems International, 22/8 Campbell St, Artarmon NSW 2064
Ph:+61-2-99063377 .. Fx:+61-2-99063468   | unsolicited email not wanted here !
Views and opinions here are mine and not those of any past or present employer

[openvrml-develop] Installation Problem

[<sa...@sa...>]

SSBhbSBjb21wbGV0ZWx5IGEgYmVnaW5uZXIgaW4gdXNpbmcgT3BlblZSTUwuDQoNClBsZWFzZSBz
b21lYm9keSB0ZWxsIG1lIGhvdyB0byBvYnRhaW4gTElCIGZpbGVzIG9yIGNvbXBpbGFibGUgd29y
a3NwYWNlIG9mIHpsaWIsIGxpYnBuZywgbGlianBlZywgYW5kIGpzMzIuDQoNClNvbWUgb2YgdGhl
IFVSTCBpbiB0aGUgcmVhZG1lIGZpbGUgYXJlIGNsb3NlZC4NCg0KTXkgcGxhdGZvcm0gaXMgV2lu
MjAwMCB3aXRoIE1TIFZpc3VhbCBTdHVkaW8uDQoNClRoYW5rcyBpbiBhZHZhbmNlLg0K

[openvrml-develop] Recent checkins

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

Just an update regarding some recent checkins I've made...

I've threatened to do it for some time; now it's done: OpenVRML's stuff
now lives in the OpenVRML namespace. Accordingly, that annoying "Vrml"
prefix has been whacked off a number of our class names.

I've also been rearranging some code into different files; generally,
consolidating multiple classes in a single header/implementation file
pair. A lot of OpenVRML's code has been written under the philosophy,
"one header and one implementation file per class"; this is not a
particularly good strategy for nontrivial C++ library projects. You wind
up with a lot of files; including, most annoyingly, a lot of header
files. Users of the library potentially must use *lots* of #include
directives to get what they need.

So, now, an attempt is being made to sanely organize classes into fewer
files. I've adopted a convention of using all lower-case letters for
file names: since there may be multiple class definitions in a file, it
nolonger makes sense to attempt to match the file name to the class
name.

Braden

Re: [openvrml-develop] 64MB limit

[Thomas F. <tf...@us...>]

Can you post the world somewhere where we can access it by ftp or http? 
I'm willing to take a look at this and see if I can come up with anything.

Tom

Damian McGuckin wrote:

>I have a large VRML file that I am trying to display with GTKLOOKAT.  It
>core dumps before it seriously displays anything.  It reads the files OK.
>However, I suspects some system setting as it dumps a core file of size
>
>	67186688 Nov 25 15:40 core
>
>This factors to 65536 * ( 65536 + 76 ) which is too close to 64MB and too
>neat for my liking.  I am quite happy to send the ( 13MB uuencoded ) file
>to somebody else if you want to try it.
>
>On a Windows Box with Blaxxun, the model needs about 90MB.  I have also
>tried this VRML file on at least one other PC VRML browser. This is a
>multi-file model with lots of external images and was created using
>Alias|Wavefront Maya 2.5.
>
>On a Mandrake 7.2 LINUX machine with
>
>$ limit
>cputime         unlimited
>filesize        unlimited
>datasize        unlimited
>stacksize       8MB
>coredumpsize    97MB
>memoryuse       unlimited
>maxproc         2048
>descriptors     1024
>memorylocked    unlimited
>addressspace    unlimited
>
>The program dumps core where a 'where' in gdb with OpenVRML 0.11.2 and
>GTKlookat 0.9.1 compiles with '-g',  shows up
>
>	#0  0x405b6f7a in malloc () from /lib/libc.so.6
>	#1  0x405b6d3e in malloc () from /lib/libc.so.6
>	#2  0x404c4a78 in gluTessVertex () from /usr/X11R6/lib/libGLU.so.1
>
>Any ideas.
>
>Is it just some system setting?
>
>Thanks - Damian (McGuckin)
>
>Pacific Engineering Systems International, 22/8 Campbell St, Artarmon NSW 2064
>Ph:+61-2-99063377 .. Fx:+61-2-99063468   | unsolicited email not wanted here !
>Views and opinions here are mine and not those of any past or present employer
>
>
>_______________________________________________
>openvrml-develop mailing list
>ope...@li...
>https://lists.sourceforge.net/lists/listinfo/openvrml-develop
>