When JT Open Toolkit exports a model, the toolkit creates one or more DirectModel files, referred to as "JT files" due to their ".jt" file extension. JT files represent an extremely robust and flexible data format, capable of storing:
JT Open Toolkit's API presents a product structure (PS) abstraction to client applications. This frees such application from requiring low-level knowledge of the renderable nature of the resultant JT data.
There are three fundamental object types available from which to create product structure:
The relationship of product structure hierarchy to exported JT file structure is arbitrary. Any node in the hierarchy may be specified as the start of a new JT file. Thus, product structure may be represented in a variety of JT file configurations.
For convenience, JT Open Toolkit defines three common product structure-to-file structure mappings. These include:
The following example illustrates each of the three standard mappings. Given the following JT Open Toolkit product structure hierarchy, where A1, A2, and A3 are JtkAssembly nodes; P1, P2, and P3 are JtkPart nodes; and P1' is an JtkInstance of P1:
A1 +-A2 | +-P1 | +-P2 +-A3 +-P1' +-P3the standard mappings would result in the following JT files:
| Mapping | Files Generated |
|---|---|
| Per part | A1.jt A1/P1.jt A1/P2.jt A1/P3.jt |
| Fully shattered | A1.jt A2.jt A3.jt P1.jt P2.jt P3.jt |
| Monolithic | A1.jt |
To help shrink the storage and transmition bandwidth requirements of 3D models, JT files may take advantage of compression. Use of compression is transparent to the user of the JT data, and a given model may be composed of JT files using different compression settings (including none).
To date, the JT file format has evolved through two forms of compression, exposed in JT Open Toolkit as standard and advanced compression. These differ in that the former employs a simple, lossless compression algorithm, while the latter employs a more sophisticated, domain-specific compression scheme supporting lossy geometry compression. Client applications are encouraged to take advantage of advanced compression over standard compression, as attainable compression ratios are much greater. Support for standard compression is maintained only in the interest of backward compatibility with legacy JT file viewing applications.
The compression form used by a JT file is related to the JT file format version in which it was written. This version is readily viewable by opening a JT file in a text editor and looking at its ASCII header information. The following table summarizes the how this version information relates to compression:
| Version | Compression | Support | Comments |
|---|---|---|---|
| 6.4 | None | All viewer and JT Open Toolkit releases | Largest JT file size. File I/O is very fast to local disk, but slower to remote data sources due to increased data traffic. |
| 7.0 | All JT file content losslessly compressed using standard dictionary compression techniques. | All viewer and JT Open Toolkit releases | Typical compression ratios average about 2:1 over v6.4 JT files. File writing is slower than v6.4 due to compression overhead. Reading is fast. |
| 8.0 | Renderable geometry content losslessly or lossily compressed, all other JT file content losslessy compressed. | VisMockup v4.0 and higher, JT Open Toolkit v5.0 and higher |
Smallest potential JT file size. Typical compression ratios average about 2.5:1 over v7.0 files using moderately lossy geometry compression. Local disk I/O is slower than v7.0, but remote I/O is potentially much faster due to the greatly reduced data volumes. |