I’m in the process of porting some very old code of mine to the new modeling core and I just got partial support for the JT Open file format working! If you’ve never heard of it, JT Open is a modern CAD transfer format. Although it has been designed by Siemens / UGS, it is intended to serves as a CAD exchange/storage format rather than coining it towards one particular application. Think Alembic for CAD: It can contain polygonal, NURBS and parametric surface information (cylinder, offset surfaces, etc), PMI (product management information) and a couple of other things your garden-variety 3D-poly-based format won’t be able to handle. On the other hand, it cannot store animations.
What makes JT interesting is that Siemens decided to publish a specification and even get it ISO certified. But it’s not for the light-hearted:
The spec itself has almost 500 pages and JT can embed Parasolid files (called XT-Brep) which also has another 100+ pages. And if that were not enough, it can even have an additional surface type which – at the time I last looked into it – was called libra (or ultra-light surfaces) for which the specification was not part of the original ISO certification. And there is also PLMXML, which is a related format for storing assembly structures (basically storing the scene hierarchy in a separate file from the geometry to easier handle very large data sets). And as with all current formats, it evolves. I believe the ISO certification was done for JT 8.1 and they are now at 9.5. So any implementer is in a constant state of playing catch up… man, that were a lot of “and”…
But I like JT for a couple of reasons:
- Specification: The spec is actually quite well written. When I wrote the original implementation, there were only few areas that were a bit vague. For the most part, it was just putting the spec to code and it worked.
- Compression: They actually did a lot of research on what compression algorithms to use on what data fields so the resulting file is rather slow. I remember receiving a 90MB JT file once that was so big, the software I was working on at the time was unable to handle it in a 32bit application because it ran out of memory trying to read/convert all those polygons.
- Delayed-loading: The format stores the scene hierarchy and the meshes / BReps in different segments and every segment has a GUID. So one can for example load polygon data only when opening the file and later read the corresponding BReps on demand if the user wants to re-tessellate something.
- Chunk versioning/offsets: Even if you discover a future file, due to the structure of the segments, its easy to skip unrecognized parts.
It’s actually quite instructive to read the spec just for learning what a modern file format can look like. I only wished there were more publicly available data sets for testing…
Right now I’m only using the polygonal data and some parts of the material system. Import of standard-NURBS-type BReps is also done, but I have no data structures to use them in my scene graph yet. But that’s exactly why I dug up the old code again, to finally get about writing my own NURBS tessellator!
Update – 07/13/2014
Okay, I take it back, at least partily… I hate JT. I checked out their 9.5 and 10.0 specs and they changed the size of some data fields or omitted them completely! In one version, the Brep segment version number is an I32 followed by a U32 of reserved data, in another version it’s a I16, and in yet another version it’s a U8 and the reserved field has been dropped. The version number inside segments is only for a specific version (e.g. V8.1 Brep segment version 4, V8.1 Brep segment version 5). That means one either has to pass the file format version number manually to the reading code or one has to duplicate all the class structures for every file format version! I’m currently sticking with just supporting 8.1 but man, that is getting ugly…
Leave a Reply