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