Hide menu
Loading...
Searching...
No Matches
JT Converter

Overview

JT_Reader can read files compliant with the JT formats from 8.0 to 10.5 and ISO14306:2012. JT_Writer can write files compliant with the JT formats 9.5 and ISO14306:2012.

The JT format applies compression and encoding when storing data, therefore files can contain many more entities and can take considerably longer time to convert in comparison with files of similar sizes stored in other formats (e.g. IGES, STEP, etc).

The JT converter uses the Parasolid converter to import XT B-Rep elements from JT files and to export B-Rep representations to JT format.

CAD Exchanger can read and write both monolithic files and assemblies with external references.

Scope

Import Export

(*) JT_Reader recognizes JT B-Rep and XT B-Rep; JT_Writer uses XT B-Rep to store BRep representations.

Mapping

Import Mapping

Below tables shows how JT entities are mapped into CAD Exchanger entities after import.

Note
Mapping for XT B-Rep entities can be found in Mapping.

Product Structure

JT Entity CAD Exchanger Entity
Meta Data Node Element ModelData_Assembly
Instance Node Element ModelData_Instance
Part Node Element ModelData_Part

Polygonal

JT Entity CAD Exchanger Entity
Tri-Strip Set Shape LOD Element ModelData_IndexedTriangleSet
Polyline Set Shape LOD Element ModelData_PolyLineSet
Point Set LOD Element ModelData_PolyPointSet

Parameters

Importer Parameters

The JT import parameters are controlled by JT_ReaderParameters. The following table contains a list of parameters for JT import:

Parameter Default value Description
LayerConversionMode() None

Specifies the mode of layers import.

  • If None then does not perform any special processing, no layers are created.
  • If LayerFilter then creates layers using the "LAYERFILTER" and "LAYER" properties in the property tables of scene graph elements.
  • If RefSet then creates layers using the "REFSET" properties in the property tables of scene graph elements.

Refer to Layers Support for further details.

ReadPMI() false See Base_ReaderParameters::ReadPMI().

Exporter Parameters

The JT export parameters are controlled by JT_WriterParameters. The following table contains a list of parameters for JT export:

Parameter Default value Description
FileSplitMode() Monolithic

Defines the mode of splitting the resulting JT file.

Supports per part, shattered and monlithic modes:

  • in PerPart mode the central file contains a product structure and refers to individual part files stored in the subdirectory named as the central file;
  • in Shattered mode, each part and assembly node is stored in the separate file;
  • in Monolithic mode (default), a single file containing entire model is stored.
WriteBRepRepresentation() true

See Base_WriterParameters::WriteBRepRepresentation().

Without B-Rep representations a jt file may not be effectively usable/loadable by some CAD systems or application which expect them.

WritePolyRepresentation() true

See Base_WriterParameters::WritePolyRepresentation().

If more than one polygonal representations is present in model, then all of them are written.

If there is no polygonal representation then computes it on the fly from available B-Rep representation.

Without polygonal representations a jt file may not be viewable by some 3rd-party viewers (e.g. Siemens jt2go) which are only able to visualize tessellated representations.

LayerConversionMode() None

Specifies the mode of layers export.

  • If None then ignores layers attached to scene graph elements.
  • If LayerFilter then generates LAYERFILTER properties for the root assembly to convert layers.
  • If RefSet then generates REFSET properties for the root assembly to convert layers.

Refer to Layers Support for further details.

OverrideInstanceNames() false

Specifies whether original instance names should be overridden by parts/assemblies the instances refer to.

If false (by default) then original names of parts/assemblies/instances are mapped to JT. However some CAD systems (e.g. Solid Edge ST6) may not be able to import files with instance names distinct from parts/assemblies they refer to, even if other applications (e.g. jt2go, NX) read such files fine.

When OverrideInstanceNames is true then a part (assembly) will use a source name if specified, or name of the first instance, or otherwise 'unspecified'. Instance(s) will always use a part's (assembly's) name (or 'unspecified'), i.e. will always be equal to the referred part (assembly's).

WritePMI() false See Base_WriterParameters::WritePMI().

Details

Delayed External File Parsing

When parsing JT files with external references (i.e. per-part or shattered assemblies), external files are parsed in a lazy manner. That is, parsing a particular JT file is deferred until a resulting scene graph element (an assembly or a part) representing that JT file is accessed for the first time, e.g. via accepting a visitor.

This allows to incrementally load elements of the model, significantly enhances application response and reduces peak memory footprint when working with large assemblies. To take most advantage of this feature, it can be used in conjunction with the option DelayedConversion() which will delay conversion in a user's application. In that case, initial parsing a JT file will be instant, and actual parsing and conversion will only be performed for those scene graph elements which will be of user's interest and only when it is needed for the first time.

Reference Set Support

To be added...

Layers Support

Although JT format does not explicitly define layer entities, some JT-aware applications such as Siemens Teamcenter are able to recognize layer structures described with the help of string properties following some conventions. CAD Exchanger is able to respect these conventions in order to convert to/from layer objects.

The modes of layer import and export are controlled by JT_ReaderParameters::LayerConversionMode() and JT_WriterParameters::LayerConversionMode() respectively.

Depending on the values behavior can be as follows:

  • None (default). A reader will not perform any processing, properties from JT files will simply be mapped 'as is'. A writer will ignore layers available in the model.
  • LayerFilter. A reader will recognize "LAYERFILTER" and "LAYER" properties stored in the property tables of parts and assemblies and convert them into corresponding structure of layers. Names stored in the "LAYERFILTER" properties will define corresponding layers names. A writer will automatically generate "LAYERFILTER" and "LAYER" properties to map available layers to JT.
  • RefSet. A reader will recognize "REFSET" properties stored in the property tables of assemblies and convert them into corresponding structure of layers. Names stored in the "REFSET" properties will define corresponding layers names. A writer will automatically generate "REFSET" and "SUBNODE" properties to map available layers to JT.

Notes (for LayerFilter mode):

  1. Layers with equal names, for instance LAYERFILTER000="SOLIDS=1,2,3" and LAYERFILTER001="SOLIDS=3,4,5" in import and ModelData_Layer L1("Solids") and L2("Solids") in export will be merged;
  2. In import, "LAYER" and "LAYERFILTER" property items are not copied to target property tables.
  3. In export, layers without names will be given a name "UNNAMEDFILTER###" where ### is a unique three-digit number.
  4. In export, in a resulting JT file, a property table of each graph element attached to a layer, will contain an item "LAYER=1,ni", where "1" is a hard-coded layer "ALL", and ni is automatically generated layer rank number (starting with 2).
  5. In export, no verification is performed whether the source property tables already contained "LAYER" or "LAYERFILTER" items. In the case of collision, behavior is undefined.
  6. In export, a property table with "LAYERFILTER" items is added to root scene graph element. Although a part can also be root, "LAYERFILTER" mechanism has only been found to apply to assemblies, therefore behavior for parts is undefined.
  7. Layers should only contain parts. Although a model with layers containing assemblies and/or instances will be correctly exported to JT, downstream applications may not correctly recognize "LAYERFILTER" items containing assemblies or instances.