Justin
I use no textures, just simple geometry.
The time (almost all of it) goes in the initial load call. The other time
usage is not an issue for me.
So for geometry that's taking me 60 seconds to get on screen, that would be
55 seconds in the initial load call but perhaps 15 seconds total if I use
VMRL97.jar instead
If you are saying that there is no chance of XJ3D ever approaching that
speed (and this seems to be what you are saying) then is becomes more
essential that the source of VRML97.jar be found so that those of us that
need a viable VRML geometry loader can support it for ourselves and plan our
own route forward.
It hope that is does not heed to be the case.
Alex Bowden
-----Original Message-----
From: Discussion list for Java 3D API [mailto:[EMAIL PROTECTED]]
On Behalf Of Justin Couch
Sent: 05 April 2002 12:03
To: [EMAIL PROTECTED]
Subject: Re: [JAVA3D] Loading VRML from a URL with VRML97.jar crash. (and
plea for the source)
Alex Bowden wrote:
> 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.
Which parts of the load time? Is it time to get something on screen, or
the completed load time including textures etc?
In general, I doubt we would ever be able to get to the speed of the
original Sun code. There are many reasons for this, but the core
difference is a loader that was designed for a single task (Sun's code -
VRML/Java3D Loader) and one that was designed to be general (Xj3D).
The original code was purely designed to load VRML97 and no more. It
took many shortcuts to do that. Nodes aren't supported, theres no
generality in the code and construction of the classes are hard-coded.
For example, the parser, when it encounters a Shape node, automatically
knows that the next one to expect will be one of the geometry types or
it will be an Appearance. That way, the code can call "new Appearance()"
directly.
In the current code, we don't have that luxury. The X3D spec is much more
flexible than VRML97. It is completely componentised, which means we
don't know what nodes to expect and what nodes should not be limited
until we start parsing the file. This imposes three design restrictions
on us:
- every time a node is loaded we don't know what it is until we get
the name. There is no pre-built optimisation paths available.
- Every node must be checked against the allowed list for this file. As
every file has a set of components and levels within that component, a
node that is allowed in one file may not be allowed in another. That
requires a check of not only the node/component relationships, but also
the level supported.
- Dynamic loading of every node. We can't use the "new" operator to
construct any node in the system. We have to use
Class.forName()/.newInstance() for every node in the file. This
requirement to use reflection is always going to be slower than direct
use of new. Because X3D basically defines abstract types of nodes, a
component can define a new, different Appearance node that extends the
basic AppearanceNodeType in the VRML scene graph. We have no idea
beforehand what to expect and so everything must be dynamically loaded.
There are several other architectural decisions that we made that will
also effect load performance somewhat. Protos, for example, are kept as
a separate in-memory copy rather than using them as direct node
expansions (macros). This is done so that our file translation
requirements are easy to meet - a proto definition is always lying
around in memory so that if someone wants to dump the state of the scene
as a VRML file "now" they can, complete with all the proto definitions.
To create an instance of the proto in a runtime system effectively means
a double parse of the proto - once for the proto representation and
another to walk it's scene graph and build a renderer-specific instance.
I have in mind one or two more optimisations that could be performed,
but I really doubt you'll see the current code get much quicker from the
loading perspective. X3D has far greater requirements than VRML97 and so
we have to build the highly generalised system you see today. We have no
intentions of building a VRML97-only parser/renderer because that would
mean maintaining two separate codebases, which we don't want to do. We
use JavaCC as the parser, which by all accounts is one of the fastest
available. We could implement a custom parser for the VRML97/X3D file
formats, but the complexity of the grammar is huge and would take many
months just for the parser implementation for very little benefit in
overall load time. Without profiling the code, I can guarantee you that
the bottleneck is the dynamic node loading, and there is very little we
can do to optimise that bit given all our other requirements.
--
Justin Couch http://www.vlc.com.au/~justin/
Java Architect & Bit Twiddler http://www.yumetech.com/
Author, Java 3D FAQ Maintainer http://www.j3d.org/
-------------------------------------------------------------------
"Humanism is dead. Animals think, feel; so do machines now.
Neither man nor woman is the measure of all things. Every organism
processes data according to its domain, its environment; you, with
all your brains, would be useless in a mouse's universe..."
- Greg Bear, Slant
-------------------------------------------------------------------
===========================================================================
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".
