Ideas for a X3D loader

OpenGL Development JOGL Development
#1

This might not be the correct forum, but I’m unsure if there is any better.

I’m about to write a loader for X3D-files (http://www.web3d.org/) that would be independent from JOGL and any scene graph API. Since Java 6 has included JAXB 2 in Java SE, I intend to use that to build the Java objects representing a model. Basically, what I’m doing is:

  • Generate the classes using the xjc-tool in Java 6: xjc -d src -p http://www.web3d.org/specifications/x3d-3.0.xsd
  • Unmarshall an .x3d file using the JAXB 2 API (see below and javax.xml.bind)
  • Read the data from the unmarshalled objects and put it into your favourite Scene Graph API (or however you wish to use it)

The code for unmarshalling an XML document looks like this:


JAXBContext context = JAXBContext.newInstance();
Unmarshaller unmarshaller = context.createUnmarshaller();
unmarshaller.setSchema(null);
unmarshaller.setEventHandler(new javax.xml.bind.helpers.DefaultValidationEventHandler());
model = (X3D) unmarshaller.unmarshal(new FileInputStream(input));

I have some problems getting it to work properly, but overall it seems to be a pretty easy method for loading a .x3d file. I generate the .x3d using Blenders X3D export function and the file seems to validate properly.

Does this sound like a good approach for creating a standalone loader? You still have to parse the values (e.g., vertices) since they are represented as attributes in the XML-document, but that shouldn’t be a problem.

#2

Sounds nice, although I’m not very familiar with the X3D format. Anyhow, I would have gone for Collada, but I believe there is already such a thing available: http://whoola.sourceforge.net/

The library:
http://sourceforge.net/project/showfiles.php?group_id=114095&package_id=154144

I have not tried it, but I’m guessing that it is using JAXB aswell…

#3

JAXB is horribly inefficient - particularly the 2.0 codebase. It generates inordinate amounts of garbage. One of our applications had the load times increase 300% in shifting from 1.0 to 2.0 simply due to the extreme amounts of garbage generated. You would be far better off hand rolling it or just making use of the pre-built parsing infrastructure that we have in Xj3D.

#4

+1 on your JAXB statement.

The simplest approach i believe would be to use XStream to deserialize the XML into your created Java objects, only including the stuff you want, the way you want it. I did a test on XStream for Collada a while back, but it had trouble with ignoring elements (this is a feature request for a future release, not sure if it has been fixed). XStream is really really fast aswell, it uses the Xpp3 pull parser.

#5

I have to agree on the JAXB issues. Tried that approach and noticed how slow it was and the huge amount of memory it ate. Haven’t tried XStream, might have a look at that later. For now, I’m building a X3D loader using StAX instead (XMLStreamReader).

#6

Another option might be commons digester, wich is like a SAX parser with rule-sets for element<->object/factory mapping.

#7

Cool, havent tried the commons digester before. How do you specify the mappings, and does it ignore stuff that you have not declared, without warning?

#8

I think, this tutorial describes the usage better than me would do. The tutorial only describes digesters predefined rules, but you can even create new rules that are triggered when the map-expression matches.

In fact it does ignore everything you do not explicitly map, but you can use wildcards for the mapping.

Note: Digester only helps parsing the document and does not generate classes, but I think you can use JAXB for this part or schema2beans for this purpose.

#9

Oh, cool, i didnt know that. Anyway, it populates the classes, pretty much the same way as XStream. Although XStream insisted on throwing a RuntimeException everytime it found an element in the xml file that did not exist in the specified Java class, but I suppose it could be fixed, since XStream was really easy to use. Thanks for the info!