Giles

Thanks for the suggestion that I may be able to recreate the source of
VRML97.jar by routing through the version 1.0 of each file in CVS.  If
nothing better comes up I'll try it - but surely someone must still have a
copy of an item of source that frankly quite a few people still use.

With regard to your query

"If its rendering speed then I'm not suprised, we have concentrated on
optimizing that end and
wont till after M5.  If its loading speed them I'm suprised."

I think its time to be surprised.  Load speed is quite an issue.  Some of
these files take a minute or so to load on Xj3D and say 15 seconds on
VRML97.  Its typically about 4 :1 hence I only currently use XJ3D when
VRML97 has failed.

Please do not take this as a lack of support for your efforts.  I believe
that the XJ3D project is essential and have every confidence that there will
eventually be a single VRML geometry loader that I can use and rely on

        Alex Bowden
        [EMAIL PROTECTED]

-----Original Message-----
From:   Discussion list for Java 3D API [mailto:[EMAIL PROTECTED]]
On Behalf Of Giles
Sent:   04 April 2002 18:41
To:     [EMAIL PROTECTED]
Subject:        Re: [JAVA3D] Loading VRML from a URL with VRML97.jar crash. (and
where is              the              source)

Alex Bowden wrote:

>I need to ask the following question but I would like to AVOID starting yet
>another flame war between the pro and anti VRML97.jar factions - so let me
>explain first:
>
>In my application I use both XJ3D and VRML97.jar loaders.
>
>I do this because the XJ3D loader will load some things that VRML97 will
not
>load, however the VRML97.jar loader is about 4 times faster and will load
>95% of the simple (CAD output) data that I am involved with.
>
Are you refering to rendering or loading speed?  If its rendering speed
then I'm not suprised, we have concentrated on optimizing that end and
wont till after M5.  If its loading speed them I'm suprised.  One area
that I recently fixed(post M4 CVS) is texture loading.  Its now about 5
times faster.

The rendering speed of the current system could be greatly improved by
shutting off alot of capability bits.  But that means turning off most
of the VRML runtime.  The original loader did not support the spec fully
and hence can make a bunch of optimizations that full VRML runtime
cannot.  We know that a lot of people want just a VRML geometry loader
and we will provide this capability, but our focus has been on
completing the VRML specification.  Our architecture decisions are based
on meeting the VRML runtime capabilties, not optimizing for the static
VRML case.

Our plans are to include the ability to specify the capability bits our
the loaded content in M5.  This will solve half the problem.  The other
half of the problem is that we wrap most things in BranchGroups so we
can remove the content at runtime.  I'm not sure we can fix this for
M5....  its a much deeper structural issue.

>
>Probably when the XJ3D loader fully meets the VRML97 spec (M5?) then we can
>look forward to some performance improvements.
>
>Anyway until then I need to use both loaders to get the performance that I
>need, with the breadth of data supported.
>
>Now the question....
>
>java.lang.NegativeArraySizeException
>                at
>com.sun.j3d.loaders.vrml97.impl.ContentNegotiator.startLoading(ContentNegot
i
>ator.java:88)
>        at
>com.sun.j3d.loaders.vrml97.impl.ContentNegotiator.run(ContentNegotiator.jav
a
>:63)
>Exception loading URL: java.lang.NullPointerException
>java.lang.NullPointerException
>at java.io.ByteArrayInputStream.<init>(Unknown Source)
>at com.sun.j3d.loaders.vrml97.impl.Loader.openURL(Loader.java:276)
>                at
com.sun.j3d.loaders.vrml97.impl.Loader.load(Loader.java:293)
>                at
com.sun.j3d.loaders.vrml97.VrmlLoader.doLoad(VrmlLoader.java:112)
>                at
com.sun.j3d.loaders.vrml97.VrmlLoader.load(VrmlLoader.java:106)
>
>
>Can anybody tell me anything about this error
>
No great hints here, when I used the loader I always loaded local files.

>Can anybody tell me where I can get the source of the VRML97.jar loader so
>that I can debug it myself.
>
Your best bet is to checkout the initial versions in CVS.  Not the first
tagged version which is VERSION-2-0-M1, but the 1.0 version of each
file.  This is not an exact copy of the original source code, but it
might give you a place to start from.  Don't expect the current makefile
system to work with it, look for a build.sh to compile the old stuff.
 The only copy of the original code I have is hacked to pieces as I took
the original code and modified it for a project.  It was that experience
that led us to the rewrite we have done today.

>Please, someone must know where the source to VRML97.jar can be obtained.
>I understand that Sun handed it over to the XJ3D so maybe there is even
some
>obligation - at least moral - to continue to make it available unsupported
>until XJ3D can fully replace it.
>
Sun did not hand this code over.  They released the code as open source
and we picked it up and ran with it.  It has not been maintained by
anyone for years.

>

--
Alan Hudson
President: Yumetech, Inc.                      http://www.yumetech.com/
Web3D Open Source Chair        http://www.web3d.org/TaskGroups/source/

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to