Visualizing STEP Files

Visualizing STEP Files
Displaying STEP via Java3D API

Software Concepts
Load STEP File into system – create
intermediate Objects
3 main types of intermediate Objects
Intermediate Objects are converted to
derivatives of Shape3D Class
Result is placed in SceneGraph Object

The Java STEP Visualizer uses the common Model-Viewer-Controller paradigm
The “Controller” (i.e., STEPController Class) calls all the needed methods for the user interface
Such that the M-V-C are abstracted from one-another. Calls the PreProcessor to create the
Intermediate Objects (STEPEntities), then the “Factory” Class (i.e., STEPFactory) to actually
use the created STEPEntities into the final “Products” that will be visualized by the “Viewer”
To better facilitate the robustness of the Java STEP Visualizer, a PreProcessor
Interface was implemented. There are three main methods used by any Class that
Implements this Interface for the proper execution of “pre-processing” an input
STEP File to the Intermediate Object structures:
1. readSTEPFile – parses the initial file
2. createEntities – creates the intermediate Objects
3. createProducts – creates the actual “renderable” PRODUCT(S)
The Intermediate Objects that the Java STEP Visualizer builds are almost a one
-to-one reflection of the description found in the STEP File format:
1. STEPGeometry (curves and surfaces)
2. STEPGeometryRepresentation (Solid Models such as Manifold_Solid_Brep)
3. STEPGeometryRepContext (Transforms – e.g., Item_Defined_Transforms)

The “readSTEPFile” method uses a STEPParser Class Object that is completely
Abstracted from its use – makes software refactoring easier. The STEP File is held in
An Associated Array (i.e., HashMap) and the ASCII STEP File is quickly released from
External file handlers because the I/O is a “drag” on the system.
The “createEntities” method creates the actual Intermediate Objects mentioned in the
Previous slide.
The Intermediate Objects are passed to various “helper” methods that create the Product(s) and
Attach a Geometry Object (i.e., the BasicGeometry Class) which is made-up of a series of
GeometryArrays (part of the Java3D Geometry Class structure) – each of which is a single
FACE in a given Product.
Finally, the PreProcessor Object stores these Products in an associated Array of Products
(fully-qualified; i.e., relationships among the various Products are implemented as well as the
Geometries mentioned previously). NOTE: Not all Products have Geometries defined and
Only “point” to others as their child – however, at some point in the “tree” of the STEP File there
Is a Geometry.
The final step before the defined STEP Model can be displayed is finished by the Factory
Class Object such that the various “products” (derivatives of the Java3D Shape3D Class) are
Placed properly in the “tree” structure (defined by the previously completed associated Array)
Under the main BranchGroup Object (a Java3D construct that is a Node that the Java3D
“engine” iterates over automatically in Retained Mode)

After calling the STEPFactory Object to create the finalized Products for display, the
STEPController Object passes the BranchGroup Object (i.e., the main Node under which
The STEPModel will be displayed) to the STEPViewer Object (i.e., the “Viewer”). The resulting
STEPModel is rendered on the screen, ready for user interaction.
The STEPViewer handles all the needed rotations and “views” for the Java STEP Visualizer
The STEPViewer performs the following operations:
1. Place each STEPModel (a sub-tree of Nodes) in its proper place in Virtual World
2. Adjust the newly placed Model (from Local to Virtual World Coordinates)
3. Applies a Bounding Sphere and a TransformGroup Object (for rotations, zooms, etc)
Quick note, to create the STEPModel recursion was used for a couple of reasons:
1. Given that the STEP File already has a tree-like relation it was natural
2. Some of the Transforms on various Product Geometries are cumulative and the
Java3D API automatically handles this when it iterates over the Node Structure of
the variously defined sub-trees (i.e., each STEPModel).

Java3D API
• Tree-like structure
(SceneGraph)
• Graphics pipeline is
abstracted from Developer
• Fully Object-Oriented,
Platform neutral
• Each Shape3D Object
(Product) has an associated
Appearance Object (controls
colour, transparency, and
various rendering attributes)

Java3D API
Two Major Nodes make up Java3D API: Leaf (Rendered) and Group (for sub-trees)
Three main modes of rendering:
1. Retained Mode – pure Object-Oriented
2. Intermediate Mode – removes the use of SceneGraph, more like pure OpenGL
3. Mixed Mode – a “mix” of both Retained and Intermediate modes
We used “retained mode” for the following reasons:
1. The SceneGraph is used so a fully Object Oriented paradigm is used (unlike JOGL
or other OpenGL bindings that are procedural-based). This makes a better mix with
the standard Java programming usage.
2. Picking support for Geometry selection
3. Multiprocessor aware, multithreaded implementation
4. Basic user interaction through Behavior model (e.g., TransformGroups)

Java3D API
What about rendering speed?
Common question, with good reason. Historically Java has been lacking in the speed
Department. However, Java3D is built upon the lower-level DirectX and OpenGL
Libraries and as such the actual rendering speed of Java3D has more to do with the GPU
Than the language itself. And with the new Just-in-time compilers as well as the fact that
Java3D “optimizes” the structure of the Node(s) in a given sub-graph (i.e., a STEPModel) –
Speed has more and more to do with algorithmic development.
As noted, the SceneGraph optimizes a sub-graph before pushing it to the GPU such as combining
TransformGroups and Shape3D Objects that use similar geometries. Of course this can be slowed
By the use of “capability bits” for things like on-the-fly changing of Appearances as well as the
iteration over the SceneGraph structure by the Java3D “engine” but the freeing of the developer
from the traditional graphics pipeline is valuable in and of itself. The developer is free to
concentrate on design and not generally worry about how it is implemented.
Also, Java3D is truly platform neutral – a great benefit not to be overlooked given that the
Languages themselves will become less important than the robustness and neutrality offered by
The Java/Java3D API.

Software Flow for Java STEP
 Once the STEP Model is rendered, any changes are
made to the STEPEntities contained in the Java
STEP Program (i.e., the Intermediate Objects).
 The hide/show options uses these Intermediate
Objects such that if a partial save occurs – only the
currently rendered Product(s) are saved to an
external binary JCNAT file. Whereas a full save will
save all the Products regardless if they are currently
rendered or not (the “missing” Products) are merely
grayed-out in the GUI Tree in the left panel.

Physical Object
The Original Physical
Object being modeled
By the STEP File.
NOTE, that the model itself
Is “solid” (i.e., has a Volume)

Rendered Surface Object
The original STEP file is
Meshed into a series of
Triangles (GPU is optimized
For rendering triangles).
NOTE: The rendered Object
Is not solid (missing Volume)

Java STEP Visualizer Hide
 The next few slides show the use of the
Java STEP Visualizer hide option
 The user can either select the Product
from the left GUI Tree Panel or use the
Mouse with the “A” (Product/Assembly)
Option button selected.
 Currently the highlight has been set to
GREEN but can be anything

Java STEP Visualizer Hide
 After selection of various Products, the user selects
from the top task bar the “Hide” Options
 There are two selections beneath the “Hide” Option:
 Hide Selections
 Hide UnSelections (boolean operation – all unselected are
hidden)
 The following slide hides the “selected” Products
 The slide after the next, hides the “unSelected”
Products (i.e., the boolean operation)

Create New Product
 The user can also create a NEW
Product from existing FACE(S)
 Select the task-bar button “F” (FACE) to
activate the selection of Geometries of
each Product
 With the mouse, select a FACE, it is
highlighted as GREEN (shown on next
slide)

Create NEW Product
 After highlighting the FACE(S) the user
wishes to make a new product from,
from the task bar select Edit.
 Select “create new Product’
 Enter the name and a short description
of the New Product (as shown in
following slide)

Create New Product
 After entering in the needed info, the “OK” button of
the pop-up “New Product” Window is clicked
 The newly-created Product is appended under the
USER-DEFINED section of the GUI Tree Panel (to
the left) and the new Product is now highlighted.
 This NEW Product is actually a NEW Rendered
Product that can be saved as a binary same as any
other Product from the STEP Model (not saved back
to the original STEP File as previously mentioned).

Create NEW Product
 The Original Product(s) from which the
new Product was created can be seen
without occlusion (as shown in the next
slide)
 The New Product can also be shown
separately (as shown in the slide after
next).

Renaming a Product
 The user can re-name (alias) a pre-existing
Product via the Mouse or selection through
the GUI Tree Left Panel.
 Mouse: Select the “A” (Assembly/Product)
button and select the desired Product
 GUI Tree: Select the Product to be re-named
 The following slide shows the selection of a
Product for re-naming

Renaming a Product
 After selecting the Product to be
renamed, from the task-bar select “edit”
 Select “rename product”
 Enter the name and short description of
the re-named Product (as shown in next
slide).

Renaming a Product
 After clicking “OK” on Pop-up window, the
renamed Product (i.e., the Product alias) is
placed under the USER-DEFINED Directory.
 Whenever the user clicks the Product, both
original and renamed product will select
themselves – the same goes for deselecting
 This selection works for both the Left GUI
Tree Panel and the Product itself (via the
Mouse).

Visualizing STEP Files

More Related Content

What's hot

Similar to Visualizing STEP Files

Visualizing STEP Files