Firstly, I apologize if this is a FAQ, but I did search the archives a bit before I composed this.
No, not a FAQ. Nobody has been really interested in it.
Second: is there any way to access the j3d or x3d data structures via the DOM APIs?
No.
If not, is there any work being done or talk about work being done in that area? If not - jeepers, why not?
Very simple - the requirements of DOM and those of the X3D scene graph model are almost mutually incompatible. X3D can be represented well enough as an XML file, but once you want to turn that into a runtime structure to poke and prod with, all hell breaks loose. I actually did a lot of work at the specification level to make this work, but each time there was one close to insurmountable roadblock that would turn up.
As a small taste of the various problems, here's the sort of issues you run into:
- Nodes with more than one SFNode/MFNode field. Because of the document structure that was decided to be used (IMNSHO it is _very_ badly designed) you need to tell the parent element which field the child element belongs to using the containerField. This becomes a required attribute, but the value of the attribute is not a fixed value - it could change. If not provided (remember that the DOM is _not_ backed by a DTD or schema at runtime, so anything is possible, including not providing the required information) then you get weirdness at the player level. There's an object, but it does nothing. It gets worse when you start DEF/USEing that node.
- PROTOs. A DOM interface allows you to screw around with the internals of the PROTO definition at runtime. This is a really bad thing to do. Protos act like a macro substitution system. At runtime, according to the X3D abstract model, the innards of a proto definition are not to be accessible from the outsides. With the DOM that is not the case - you have complete access to everything. One of the reasons this causes major headaches is the way PROTOs need to be implemented. Regardless of the actual detail, to create a new instance of a proto, you end up needing to copy the proto internals and turn it into a live node. In some cases, that means building internal state machines or other funky structures (I know of at least one implementation that has built a byte-code like structure to "replay" a proto definition), which makes it impossible to modify the structure on the fly. An additional semantic issue is that you would now have two nodes that look the same from the outside (same node name) but function differently, which is A Bad Thing.
- Performance of the DOM is woeful if you want to run events. The DOM event model is designed for slow-speed text systems. Basically, take everything that you would do to optimise a high-speed 3D renderer and do exactly the opposite of it. For example, all the events are required to bubble up from the element to the root of the scene graph, and other events (eg mouse) are supposed to cascade down from the root of the graph. This is a nice system if all you want to do is deal with whether someone has run a mouse over a link or picture. It sucks really badly when you have 500 objects all generating at least two events every frame on a system running at 100 frames a second. The DOM event model was never designed for real-time requirements and to force that onto the system would extremely severely hamstring performance. Early on in our work with Xj3D when we started implementing the X3D spec, we did this. When we turned on the DOM events, our performance (measured by framerate) basically dropped by an order of magnitude on anything more than a trivial spinning box example. _thats_ how bad it is.
-- 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".
