Hoops Visualize Technical Documentation

HOOPS Visualize

This section is aimed at developers of 2D and 3D engineering and technical applications. It describes the general architecture, features, and benefits of HOOPS Visualize. The sections cover areas where HOOPS Visualize offers some real benefits to developers of professional software applications looking to offer advanced features for 2D and 3D display and user-interaction. It focuses on how using such features could enhance the usability of new or existing engineering software applications.

Note that only the most significant features of HOOPS Visualize are covered here, some features and functions are covered only briefly, and some are omitted altogether.

What is HOOPS Visualize?

What is HOOPS Visualize?

HOOPS Visualize is a set of software libraries designed to aid developers of industrial graphics applications by reducing development time, effort, and cost.

However, HOOPS Visualize is not simply a rendering engine – it is a high-level graphics framework that can be integrated with common GUI libraries such as .NET, WPF, and Qt. The system has a built-in interface to common third-party toolkits such as the Siemens Parasolid modeling kernel and the Autodesk RealDWG libraries. While it is often associated with 3D applications, HOOPS Visualize also offers native support for strategically important 2D rendering.

The structure of HOOPS Visualize is described in detail below. At this point two libraries in particular should be noted:

  • HOOPS Visualize/3DGS: The 3D Graphics System [3DGS] is the core geometry database, scene graph, and driver management system.
  • HOOPS Visualize/MVO: The Model-View-Operator [MVO] library is a high level application layer that is designed to implement commonly used operators such as camera orbit or select-by-drag. It maps platform-independent GUI events to multiple calls within 3DGS. The source code for MVO is available in readable form.

Getting Started with HOOPS Visualize

Getting Started with HOOPS Visualize

HOOPS Visualize is a large system with many thousands of API functions. Initially, it can appear intimidating, particularly to those without experience in computer graphics programming.  However, once the component subsystems and their relationships are understood, HOOPS Visualize provides many routes to rapid prototyping and development.

A key point to remember is that HOOPS Visualize users are not alone – Tech Soft 3D is set up to provide substantial support and consulting services to those familiarizing themselves with HOOPS Visualize. If you need an explanation, our support staff is here to provide it.

How to Start Your HOOPS Visualize Evaluation

Of course, it is not for us to tell our potential customers how to evaluate our software. Our customers are experts in their domains and know what they want. Keeping that in mind, this section attempts to offer some guidance based on our experience working with many HOOPS Visualize evaluators.

In general, projects based on HOOPS Visualize fall into three categories:

  • Replacing the existing graphics subsystems in one or more established applications within a company
  • Starting a new project or product from scratch, either as part of an existing application portfolio or as part of a startup company.
  • Extending an existing application to add new graphical capabilities or improve performance.

Developers evaluating HOOPS Visualize have a broad range of experience in graphics programming from those that are relatively new to graphics programming to those that have worked on several graphics subsystems in either games or industrial graphics.

Having recognized these distinctions we’d give the same broad advice in all cases:

  • Define Goals and Constraints: We assign a Consuting Engineer to all potential costomers to help with the evaluation process. It is very important to define your evaluation goals up front and to discuss these goals with your Consulting Engineer. We can help advise as to how achievable and realistic they are in your time frame, and suggest the fastest routes to achieve them. In many cases, we can work with you to help answer the up-front question “before I spend time working on HOOPS Visualize, I need to know whether the software can meet my demanding needs at all.”
  • Gain a broad understanding: Once you’ve decided to investigate HOOPS Visualize in more detail, take a little time to understand the broad structure of the software and how the libraries fit together. You don’t need to read all the HOOPS Visualize documentation – this overview provides a good start and your Consulting Engineer can recommend the key sections to cover based on your evaluation goals.
  • Do the tutorials: Do some of the tutorials in the Getting Started section – they are fairly easy to work through, and demonstrate how quickly you can get prototypes going with HOOPS Visualize – we’d recommend ‘spheres’ as a good start. This also involves building and familiarizing yourself with some of the samples.
  • Start building a prototype: Start building your own standalone prototype. You’ll find you can move on quickly from the tutorials to create a new project and start adding functionality. Although it may seem to be a little extra effort up-front, you’ll find that you have a clean code-base to work with and can therefore concentrate on testing HOOPS Visualize, not on tackling the complexities of your existing code base.
  • Extend the prototype: Add functionality to the prototype based on your evaluation goals. This will usually involve some form of data import, selection, manipulation, and visualization of results.

Quite often, the above process can be completed within a week, and by this time you will already be feeling comfortable and familiar with HOOPS Visualize and should have something useful to demonstrate to your stakeholders.

At this point you are in a good position to revisit your evaluation goals and look at how HOOPS Visualize meets some of the more difficult challenges you face.

Also remember that HOOPS Visualize is distributed with a broad range of samples and all except the core of HOOPS Visualize is shipped with readable source code. So, if you want to see how Tech Soft 3D’s programmers have implemented something there is usually some code to refer to.

The HOOPS Visualize Scenegraph and Drivers

The HOOPS Visualize Scenegraph and Drivers

HOOPS Visualize 3D Graphics System, or 3DGS comprised of a scene graph and a set of drivers that is able to render the scene to various devices. The next section discusses HOOPS Visualize/3DGS at a scene graph and driver level.


The scene graph

A scene graph is a directed graph that describes a 2D or 3D scene, usually in a hierarchical manner. In HOOPS Visualize, the nodes of the scene graph are known as segments. The geometries associated with each segment are sometimes called entities and the information describing how each segment should be displayed are known as attributes.

  • Segments can have any number of subsegments and may contain entities.
  • Entities are always contained in a segment, but the entities themselves never have children
  • Attributes are generally applied to segments but can be applied to entities in certain special cases.

Segment attributes inherit from parent to child unless the child specifically overrides the attribute.

Each segment can have a modeling transform that defines a segment’s location, rotation, and scale with respect to its parent segment. This enables support for rigid-body animation and forward kinematic chains.

Normally a child will only have a single parent. However both segments and geometry can be included in the scene graph multiple times without copies being made:

  • When a segment has more than one parent the segment is said to be included by the other segments.
  • When an entity has more than one parent it becomes known as reference geometry.

The current support for geometric entities in HOOPS Visualize can be divided into groups as follows:

  • 2D entities that can be used in 2D or 3D scenes, for example, polylines, circles, ellipses, grids, text
  • 3D polygonal entities e.g. shells and meshes
  • Higher-level primitives that are converted to triangles or lines for drawing, such as, splines, NURBS, polycylinders
  • Special case entities that serve a particular purpose other than simply defining geometry, such as, lights, cut-planes, references.

The Shell Entity

For 3D systems the primary geometric entity that will be used is the HOOPS Visualize shell. The internal structure is common within computer graphics and is often termed ‘indexed face set’ or ‘polygon-point mesh’.

A shell defines the boundary surface of an object in 3D space using a set of planar polygons. Polygons can be multi-sided and can include holes. For performnce reasons, the shell is defined as an array of vertices and a face list that defines each polygon.

HOOPS Visualize supports advanced functionality relating to shells including the ability to select, highlight and modify individual sub-entities the faces, edges, and vertices that make up 3D geometry. Additionally, normals colors, and texture coordinates can be set at the sub-entity level to enable a wide variety of complex shading and rendering.

Lines and Text

Most HOOPS Visualize customers develop applications that draw substantial numbers of lines and text.

Our software supports a large number of line styles, end caps, glyphs, disjoint lines, and infinite lines. Application developers can also define their own custom line and glyph styles.

Substantial development effort has been made to support fast, high-quality text display within HOOPS Visualize, and to match this display in WYSIWYG print drivers. Some of the key features in the HOOPS Visualize text pipeline are:

  • Predefined stroke fonts
  • Support for system, Truetype, Opentype, Type1, and user-defined fonts
  • A Tech Soft 3D font is provided for PMI/GD&T display
  • Full internationalization support including Unicode/MBCS and UTF-8, UFT-16 and UTF-32 encoding.
  • Functions to convert text to geometry, multiline text, billboarding, text justification and layout options.
  • Ability to automatically switch fonts at different screen sizes to enhance readability.
  • Ability to set different attributes per character in a text string
  • Text greeking to improve performance by limiting drawing of text when it is small on-screen.

The Tech Soft 3D Font displaying PMI/GD&T information

The Drivers


One of the key architectural aims behind HOOPS Visualize is to provide a platform and device-independent description of 2D and 3D scenes, which can then be rendered to any of the devices supported by HOOPS so that whenever possible, the result looks the same on all devices.

The code responsible for reading the 3DGS database and rendering it to a particular device is called the ‘driver’. A full list of HOOPS Visualize drivers can be found in the Device Guide.

In addition to other targets, our drivers support the output of the graphics data to screen, to image and video formats such as JPEG and TIFF, and to printers and plotters via Postscript and HPGL2.

Initially, most HOOPS applications are concerned with screen-based interaction, and the primary drivers for this are based on OpenGL and DirectX. A full software pipeline is also provided for use in situations where hardware acceleration is not available or is problematic.

In recent years, significant investment has been made to re-engineer the HOOPS Visualize OpenGL and DirectX drivers to be entirely shader-based. This important innovation is described in more detail in the Shader Pipelines page.

Print and Plot Support

Hardware-based rendering APIs such as OpenGL and DirectX do not offer a high level of support for printing and plotting. It is always possible to capture the image that has been drawn and use that for printing, but for large-sizes this will involve stitching together several images in order to get the resolution required. For many scenes and hardware combinations this technique is likely to be slow and use excessive memory. In some circumstances quality may be sacrificed as the output device’s native drawing algorithms are not used.

HOOPS Visualize printing and plotting drivers, include Adobe PDF, Postscript, Microsoft Windows GDI, X11, Apple Quartz, Qt and HPGL/2. Each driver is optimized for the device in order to make use of the native primitives provided by its output API. Support for hybrid vector/raster hardcopy generation is provided.

Rasterized parts of the scene, such as textured objects, are accurately rendered using the device’s raster interface, while vector parts of the scene such as lines, edges, and text are drawn using the device’s native vector interface. The vector primitives are drawn using hidden-line removal, allowing them to be effectively interleaved with the 3D rasterized objects, rather than just being overdrawn. HOOPS provides efficient, high-quality hardcopy regardless of the scene contents or hardcopy interface.

The DPI resolution of the rasterized geometry can be controlled by the developer, allowing them to determine the tradeoff between accuracy and speed/memory-usage during the hardcopy generation.

Scene graph and Drivers – Flexibility

The HOOPS Visualize scene graph and driver system has been built from the ground up to allow a high degree of flexibility for application developers. For example:

  • HOOPS Visualize can run on-screen or off-screen drivers simultaneously.
  • Any segment in the scene graph can be exported without exporting the entire scene graph.
  • Data can be loaded from disk into any segment of the scene graph without altering other sections of the hierarchy.
  • Multiple views of the same part of the scene graph can be visualized simultaneously and independent of attribues.
  • Style segments allow groups of attributes to be applied in one operation.
  • Conditional includes allow the scene graph to be automatically changed at draw time based on user-defined conditions.

Selection and Highlighting

Selection and Highlighting

The HOOPS Visualize libraries provide multipleways to perform selection as well as several advanced highlighting techniques.


Control over what is targeted for selection is flexible:

  • Nodes in the scenegraph can be marked as available for selection or not (Set_Selectability)
  • Selection can operate at the object level as well as for entire segment hierarchies. Selection of individual faces, edges, and vertices can also be enabled.
  • The number of selection results returned can be programmatically capped to ensure performance remains constant in densely packed scenes.
  • The selection proximity can be used to select the nearest item on screen within a screen-based tolerance
  • Selection can be performed using a drag box, arbitrary screen regions defined by polylines or polygons, by a volume of 3D space, or by an arbitrary triangle mesh. The latter method can also used for clash detection and is known as “shell selection”.
  • Optimizations for selection performance include using octrees to provide very fast shell selection and ‘visual selection’, which only interrogates items that were visible in the last screen update.

Edge selection (left), vertex selection (center) and face selection (right).

When performing selection, often it is required to convert coordinates between coordinate systems. HOOPS Visualize provides utility functions to transform between coordinate spaces including world, local and screen coordinates.

The MVO library provides higher level classes to support selection and highlighting.


HOOPS Visualize provides a number of standard and advanced highlighting models:

  • Standard Override: temporarily change the color of the segment and use ‘attribute lock’ to force the child segments to also change color. This is useful when you wish to highlight an entire assembly.
  • Conditional Highlighting: temporarily moving the objects to be highlighted to a ‘highlight’ segment which has the chosen highlight attributes.
  • Quickmoves Highlighting: use the ‘quickmoves’ 3D-sprite feature (discussed in Advanced Features) to redraw the highlighted objects on top of the current view but with correct depth-sorting.
  • Inverse Transparency Highlighting: draw the selected objects with their original or new attributes and draw the rest of the scene as transparent. An option is available to draw the transparent portion in grayscale.
  • Dynamic Highlighting: automatically highlight any objects that lie underneath the cursor. An option is available to extend this to include regions of a shell – a region being a pre-defined set of triangles within a triangle mesh.

Inverse transparency highlighting of pipes and valves in plant datasets.

Selected Advanced Features

Selected Advanced Features


Fast, accurate multi-layer transparency has always been a challenging feature for interactive computer graphics as to ensure correct blending it is necessary to draw the scene in a back-to-front order. As model size increases the time taken for any sorting algorithm needed to achieve this can increase dramatically.

HOOPS Visualize offers a number of transparency algorithms offering both high-quality and high-performance:

  • Screen-door:this provides very fast drawing by substituting true transparency blending with a screen-door effect where only a fraction of pixels in a transparent object are drawn, allowing objects behind to show through. No sorting is performed. This can be an effective technique when navigating around a model
  • Painters algorithm:  a sort-based method that gives a completely accurate rendering of scenes at the expense of performance – useful for high-quality printing and plotting
  • Z-Sort :sorts either all the triangles in the scene based on the triangle’s center (“nice”) or all the objects in the scene (“fast”). The former gives high quality results for small scenes, the latter is useful for fast inverse-transparency highlighting in large scenes.
  • Depth Peeling:this technique is not based on sorting and exploits the z-buffer approach to depth testing, where each ‘pixel’ in the buffer contains the depth of the nearest object drawn. It is the algorithm of choice for use with modern graphics cards as performance varies with screen resolution and the number of layers of transparency chosen to be drawn, rather than with model size. The HOOPS Visualize algorithms are optimized to minimize the amount of redrawing in multi-layer depth peeling and to take advantage of hardware occlusion support if available.

Depth peeling transparency: one layer (left), two layers (middle) and three layers (right).

Immediate Mode

As described above during normal operation HOOPS Visualize is a retained mode system i.e. a scene including both geometry and structure are created in the HOOPS Visualize database and this data is interrogated when the user asks the application to draw the scene.

In certain situations it is useful to be able to make decisions on what is to be drawn once the draw process has started. A common example is to hide annotations when the point which the annotation references is obscured by an item of geometry.

HOOPS Visualize Immediate mode provides call-back stubs in the draw pipeline and an API that allows device -independent drawing of graphical primitives i.e. the same call to draw a polygon works for DirectX and OpenGL.

Bounded Section Planes

Both OpenGL and DirectX supply support for hardware-based section (“cut”) planes so that the model can be sectioned so the interior can be viewed.

Three sided bounded sections through a mechanical model (left) and a tetrahedral mesh (right).


Additionally HOOPS Visualize supports:

  • Manipulation of cutting planes in space using manipulation handles
  • Local visibility settings for cut planes so that parts of the scenegraph can be left unaffected by the cut-plane
  • Calculation of polyline cut boundaries and end-cap geometry.
  • Cutting sections that allow two and three-sided bounding sections through models to show ¾ and other complex section views
  • Bounded slices through the scene

A bounded three-sided section through a large Plant dataset showing internal pipes

Quick Moves and 3D-Sprites

The term ‘quick moves’ refers to repeatedly drawing entities on the screen without redrawing the rest of the scene. Examples include a rubber-band box for selection or to specify a zoom area, or dragging a piece of geometry through the scene.

By default if the ‘quick moves’ heuristic is enabled in HOOPS Visualize then HOOPS Visualize will choose the best method available depending on hardware support. Typically this will be to use hardware-based overlay planes but if these are not available then XOR-based quickmoves may be used.

HOOPS Visualize also has an advanced quickmoves option termed 3D-spriting. With normal quickmoves all new geometry is drawn on top of the scene and no depth-test occurs. With 3D sprites the object is drawn in full 3D with a correct depth test. 3D Sprites are a valuable optimization in large scenes where objects can be correctly highlighted, moved and redrawn without the need to redraw the entire scene.

Polygonal Clip Regions

It is very common for users of HOOPS Visualize-based applications to work in 3D. However in many cases the final product is a 2D report or a set of 2D drawings. HOOPS Visualize provides a range of capabilities to help automatically generate 2D drawings from 3D models. These include configurable hidden line, section boundary and end-cap generation and polygonal clip regions.

A polygonal clip region is defined by an arbitrarily-shaped convex polygon – for example a circle. When inserted in the HOOPS Visualize scenegraph all geometry below that node/segment is clipped so that only the portions within the polygonal region are drawn. This capability is extremely useful for adding detail sections to a drawing.

Point Clouds – Dynamic Level of Detail and “Splat” Rendering

As laser scanning becomes more prevalent across a range of industries, from Coordinate Measurement Machines to Plant Management through Civil Engineering and Graphical Information Systems, large point-based datasets are becoming standard. HOOPS Visualize provides a range of interactive navigation and analysis tools specifically aimed at working with point clouds and laser-scan data.

A laser scan of a log cabin seen from the outside.

In HOOPS Visualize, Point Clouds are represented using the shell primitive with a null face-list array. The vertex marker primitive offers hardware accelerated shader-based;splat-rendering; where each point is drawn as a disc or a square. By increasing the on-screen size of each point, surfaces become opaque even in areas with relatively low point density. This has the substantial advantage that useful visualization can be achieved with a smaller number of points.

The ‘vertex decimation’ rendering option provides a dynamic level-of-detail capability so that only a percentage of vertex markers in each point cloud are drawn per frame. This technique works particularly well with randomized point clouds and constant frame rate algorithms.

A laser scan of the interior of a log cabin. Full resolution (top left), Full resolution with splat rendering (top right), 50% dynamic LOD (bottom left), 50% dynamic LOD with splats (bottom right)

As well as fast display of large point clouds HOOPS Visualize offers a variety of measurement utilities including fast nearest distance calculations between individual points as well as points and CAD geometry. Multi-threaded routines are available to compare an entire point cloud with the triangle-based data, shading each point appropriately relative to a table of tolerance distances. These capabilities can be used to rapidly calculate collisions between geometry and laser-scan data, for example when designing new pipe layouts in a scan of an existing process plant.

Laser scan point cloud (left) and original CAD geometry (right).

Combined distance tolerance comparison display.

Further information about HOOPS Visualize’ Point Cloud support can be found in the ‘Out Of Core Rendering’  section in ‘Performance’.

Advanced Geometry Utilities

In order to support a number of our customer’s goals such as clash detection and design part versus measured part differencing, HOOPS Visualize/3DGS offers a number of useful geometry-based utilities alongside the standard vector and matrix mathematics support that is standard in most 3D toolkits:

  • Compute_Points_Distance_From_Shell:  Rapidly compute the nearest distance between two shells or a shell and a point cloud. Can make use of a spatial hierarchy to significantly reduce calculation time.
  • Compute_Convex_Hull: A useful way to close non-closed bodies for collision detection or level of detail
  • Compute_Face_Neighborhood: given a face, rapidly determine the neighboring faces in a shell. This is useful as the face list has not explicit topological connectivity
  • Compute_Circumsphere: calculate the bounding sphere for a segment and its children
  • Compute_Circumcuboid: calculate the axis-aligned bounding box for a segment and its children
  • Compute_Intersect_Polyline: calculate the polyline of intersection between two shells
  • Compute_Optimized_Shell: optimizes a shell for faster rendering – optionally includes
  • remove redundant vertices and degenerate faces
  • convert all faces to the same vertex winding
  • calculate levels of detail
  • remove orphan vertices
  • skin the shell i.e. compute the external surface and discard the interior points


  • Compute_Point_Inside_Shell: given a set of points determine whether each point resides inside, outside or on the shell boundary.
  • Compute_Shell_Enclosure: determine if two shells intersect or if one is entirely contained within the other.
  • Compute_Swept_Shell: create a swept-volume for a shell moved in a linear motion
  • Compute_Swept_Shell_By_Path: create a swept-volume for a shell moved along a non-linear path.
  • Compute_Triangulation: triangulate a shell that contains many sided-polygons and holes.


An I-Beam swept along a NURBS curve



Performance is a strategically important area for HOOPS Visualize development, particularly for large datasets. Tech Soft 3D sees datasets that are both large (tens of millions of triangles, hundreds of millions of points) and very large (hundreds of millions of triangles, billions of points) becoming more common in a number of industries.

While sectors involving large capital projects such as construction, shipbuilding, energy and offshore have always been challenging for interactive graphics, assemblies and datasets within traditional MCAD and downstream applications are also growing. And for the first time the possibility to interactively render the huge meshes used in FEA and CFD is becoming real.

Enterprise-wide computer hardware has been 64-bit capable for some time. In the US more than a third of Windows Vista seats sold were 64-bit. With Windows 7 64-bit is becoming standard. With the 32-bit addressable memory limit removed the limits on application performance and usage will start move from being memory-bound to graphics-bound. For many applications, success in this new environment will be partly determined by how well their graphics subsystem is capable of handling large datasets.

The next section details the some of capabilities within HOOPS Visualize for improving performance for both standard and large datasets.

Optimized Draw Pipeline

The graphics pipeline within HOOPS Visualize has been highly optimized to remove bottlenecks. Wherever possible array-based data structures are used in preference to pointers to improve cache coherence. A dedicated parallel memory manager is used to deliver fast memory allocations and memory is automatically cleaned during idle time.  As previously discussed shaders are used heavily to workaround bottlenecks and slowdowns that are typical within graphics drivers written primarily with the games industry in mind

Automated performance testing is conducted weekly to ensure any slowdowns introduced with new development are picked up early in the development process and optimized out as soon as possible.

Why is HOOPS Visualize often faster, even on small datasets?

Modern consumer graphics cards are very powerful. In sheer processing power they are an order magnitude more powerful than the fastest consumer CPUs.

However this power is achieved through a high degree of parallelization, something that suits the graphics pipeline. If an operation cannot be parallelized then running it on a graphics card will be very slow.

Additionally to take full advantage of that power, all significant bottlenecks must be removed. Even seemingly minor bottlenecks can destroy performance.

In Industrial applications the following situations are typical:

  • Data must be cached on the graphics card to avoid overloading the CPU to GPU bus with “heavy” geometry data
  • Context switching on the graphics card must be minimized – that means geometries must be merged to avoid display list/vertex buffer setup times and where possible geometry must also be organized by common attributes.
  • Care must be taken to avoid a high number of nodes (segments) in the scenegraph on the CPU side. Simply traversing the pointers in a scenegraph structure with tens of thousands or hundreds of thousands of nodes can take more time than is available at 15 to 30 frames per second without making any calls to the graphics hardware i.e. drawing nothing.
  • Drawing of entities that are known to draw slowly must be handled carefully during interactive navigation – this includes text, complex line styles and transparency.

For the reasons above it is common that structures setup with the business needs of the application in mind will be pathologically bad for rendering performance due to excessive numbers of objects and entities.

This includes structures typical for 2D or 3D CAD editing, visualization of cell-based analysis results or reviewing complex architectural or plant models. To improve rendering performance for such datasets there is no option but to manage two structures, one representing the business needs of the application and a second representing the performance needs of the graphics card.

HOOPS Visualize’ approach to managing these issues is discussed in more detail below.

Display Lists and “Segment Level” Display Lists

In general terms a ‘display list’ simply refers to a list of instructions or commands to display a scene or a portion of a scene.

With the advent of consumer-level graphics hardware it became clear that in many cases sending large amounts of geometry data from the CPU to the GPU could become a bottleneck in the graphics pipeline. To workaround this issue techniques were developed that allowed developers to cache geometry data on the graphics card, alleviating the bottleneck caused by the CPU to GPU bus.

One of the earlier implementations was the OpenGL display list, which involved specifying a list of OpenGL commands that could be executed in a single call. OpenGL drivers provided by card vendors were responsible for interpreting the list and caching it in a form suitable for execution on the card.

More recently both DirectX and OpenGL have extended this concept to allow a more general and appropriate form of on-card memory management through Vertex Buffers and Vertex Buffer Objects (VBOs). These structures map more closely to a polygon mesh – similar to a HOOPS Visualize shell.

Caching data on the graphics card is critical for good performance on modern cards. As the cached data increases (cards with 1GB of on-board memory are now common) managing that data in a granular fashion is also critical to avoid slowdowns as on-card data is destroyed and regenerated.

The HOOPS Visualize ‘display list’ option automatically creates and manages vertex buffers/VBOs on the graphics card mirroring the geometry data on the CPU. HOOPS Visualize ensures graphics card memory is not ‘blown’ by adding more data than is available in physical memory – which causes the graphics driver to page main memory resulting in a  catastrophic slowdown in most cases.

By default HOOPS Visualize places each geometry item in a vertex buffer. The advanced option ‘segment level’ display lists places all entities beneath a segment in the same vertex buffer. In well-structured scenes this helps minimize context switching on the graphics card.

Scene Reorganization and “Static Model”

As already discussed context-switching can significantly affect graphics card performance. In the simple case of a 2D drawing, if every line has a different color to the previous line, and every line is in it’s own display list or vertex buffer, then each time a line is drawn the graphics must reset its color and display list state. Hence a graphics card capable of processing hundreds of millions of triangles per second might be unable to draw a relatively small 2D drawing in real-time.

As scenes size increases in terms of the amount and size of geometric entities, the chance that a particular graphics card will be powerful enough to interactively draw all the data decreases. A conceptually simple workaround to this situation is to not attempt to draw all the data, but to only draw the data that is most relevant.

This approach is commonly called ‘culling’. There are many types of culling commonly used in graphics pipelines including backplane, view frustum and occlusion – all of which HOOPS Visualize supports. Effective scene organization can lead to more effective culling as well as reducing context switching on the graphics card.

HOOPS Visualize offers application developers the flexibility to organize all or parts of their scenes in ways which are performance-friendly. HOOPS Visualize also provides two functions to assist with and automate this task

  • Optimize_Segment_Tree: This core 3DGS function allows all or part of the scene to be reorganized based on a number of application controlled options. In particular the scene can be reorganized by color, which is very effective for 2D scenes, or spatially, which tends to be very effective for 3D scenes with large numbers of objects. The ‘instance shells’ option will search the scene for duplicate geometry, replacing duplicates with a reference to a single copy of that geometry. This is particularly effective in saving memory in large architectural, construction and plant models.
  • Static Model: This heuristic tells HOOPS Visualize to reorganize the scenegraph without modifying the original structure that has already been created by the application. HOOPS Visualize creates a second internal tree with a reduced segment number that is used for drawing and picking, and internally maintains a mapping with the original tree created by the application. Because geometry is not duplicated, only referenced, there is a minimal memory impact in creating the second tree.

By default static model will focus on minimizing segment number and attribute switching. When used in conjunction with segment level display lists a scene with hundreds of thousands of objects can be represented by a relatively small number of vertex buffers on the graphics card.

The ‘static model = lmv’ option creates a spatial hierarchy that is used by the fixed framerate algorithm to do time-bounded prioritized rendering, described below.

It is important to note that any kind of scene reorganization does have limitations. The implied inheritance of the original scenegraph is broken, so operations such as animation can be more difficult. If an object is edited so an attribute changes such as color or position it may need to be placed in a different branch of the reorganized scene. Hence editing of such scenes can involve the optimized structure being recreated, which can take several seconds for large scenes. Additionally vertex buffers on the graphics card that represent the changed objects need to be modified or recreated.

There are a number of ways to manage this. ‘Quickmoves’ highlighting is provided so that objects can be highlighted without the need to reorganize by simply redrawing them on top of the existing scene.

Another effective method takes advantage of the fact that static model can be applied to any scenegraph node and can be applied multiple times in the same scenegraph. Thus when an entity is modified only the portion of the scenegraph to which that particular static scene heuristic is applied needs reorganizing.

In future HOOPS Visualize releases incremental updates to static model will be added to minimize regeneration time. However many HOOPS Visualize customers are already experiencing dramatic performance improvements in editing environments through judiciously using static model within their scenes.

Frame-rate based interaction: ‘Target’ and ‘Fixed’ Framerate

Reorganizing the scene and data on the graphics card can deliver significant speedups – an order of magnitude in many cases. However there are still many situations where not all the data in the scene can be rendered at interactive framerates. In these cases it is necessary to cull some data so that the user does not see all data drawn every frame.

HOOPS Visualize has a number of methods to do this but two of the more advanced are the ‘target’ and ‘fixed’ framerate algorithms.


Target framerate is an MVO-based function. The application specifies a target framerate – perhaps 15 frames per second, and some culling parameters. While interaction is occurring HOOPS Visualize/MVO takes control of scene drawing and draws only those objects with a screen size in that frame larger than a certain threshold. The time taken to draw the frame is recorded. If the frame took longer than the target framerate the size culling threshold is increased, if it took less time the size culling threshold is decreased.

This technique provides a simple way to deliver interactive framerates on a variety of models. However as it does not guarantee the framerate it is not regarded as being as useful as the ‘fixed framerate’ method. Nonetheless it is mentioned here as it is a very effective method for navigating certain types of scene.


Fixed-framerate is built into HOOPS Visualize/3DGS and is very simple to activate.

With fixed-framerate the application specifies a desired framerate. HOOPS Visualize draws the scene in a priority order depending on the current camera parameters. The priority of an object can be determined by its screen size and its proximity to the viewer.

HOOPS Visualize monitors the time that has been taken to draw the frame and when there is no more time HOOPS Visualize interrupts the draw and starts the next draw. When navigation pauses or stops HOOPS Visualize draws (fills-in) the rest of scene in order from the point at which the last render stopped.

The fixed-framerate algorithm guarantees smooth navigation and, as the decision making is primarily CPU-based it scales well from low-end to high-end graphics hardware. It is particularly effective when combined with the static model; option and segment level display lists.

Out-of-Core Rendering

Out-Of-Core Rendering

Interactively manipulating very large datasets is challenging for system memory as well as graphics performance, even on 64-bit systems. Laser-scanning operations in particular can generate gigabytes of data that need to be visualized interactively in order to be processed and analyzed.

HOOPS Visualize includes a technology preview of HOOPS Visualize out-of-core rendering for point clouds, that allows very large point cloud to be manipulated within physical memory even on 32-bit systems.

HOOPS Visualize out-of-core takes advantage of several new techniques to be available in HOOPS Visualize including hierarchical level-of-detail and parallel database writes using proxy scenegraphs.


A video demonstrating HOOP out-of-core is available on request.


A 500 million point cloud laser scan combined with CAD design data drawn in 1GB of memory.

The Advanced Shader Pipeline

The Advanced Shader Pipeline

The development of very powerful highly-parallelized GPUs available at commodity prices on enterprise-level hardware, including laptops, has transformed the computer graphics industry – both for games and industrial usage.

The introduction of programmable shaders onto graphics card drivers has opened the way for dramatic changes in how graphics cards can be used and how their power can be exploited. While this is bringing many benefits, the complexity of developing low-level graphics software in this new environment is increasing bringing new challenges to applications developers in all relevant industries.

In Computer Graphics the term ‘shader’ was originally introduced as a concept to photorealistic-rendering, long before powerful graphics hardware made it possible to consider writing shaders that would execute in real-time. One of the earliest references to the term is from Pixar’s Renderman system introduced in 1989 where shaders were often used to draw more accurate materials than could be easily achieved by simply mapping 2D textures into the scene.

Programmable shaders were widely used in photorealistic rendering engines throughout the 1990’s until they more widely adopted on computer graphics hardware with the introduction of pixel-shaders into DirectX 8 at the end of 2000. Since then, driven primarily by the demands of the gaming industry, shaders have flourished, offering ever more complex capabilities and achieving ever more sophisticated effects.

Defining the term ‘shader’ is somewhat difficult since shaders can vary greatly depending on the environment in which they operate.

Consider the ‘graphics pipeline’ to be the sequence of operations in which a 3D scene description is converted to a 2D image with transformations, lighting and material definitions having been correctly evaluated and applied so the each pixel in the 2D image is the correct color.

A shader is then a set of instructions that are inserted into that pipeline to define how one part of those operations should occur.

Prior to the introduction of shaders, calls to graphics systems depended on fixed-functions so that what is available in the existing function calls limits what is achievable. For example, if three lighting models are available it is very hard to extend to new lighting models. With shaders adding advanced lighting effects becomes easy as code can be inserted into the graphics pipeline to modify the lighting accordingly.

Shaders are therefore a powerful concept, but with that power comes responsibility. If code inserted into the graphics pipeline has bugs, or does not behave well with the rest of the pipeline or with other shaders then the results can be disastrous – an incorrect image, unusable performance, or a crash.

Why does HOOPS Visualize use shaders?

The software developers at Tech Soft 3D have been following the development of shaders on graphics hardware throughout the last decade, waiting for standards to stabilize sufficiently to add a shader interface to HOOPS Visualize.

The introduction of DirectX 10 removed the fixed function pipeline from DirectX completely. The implication then was that for HOOPS Visualize to continue DirectX support, something viewed strategically critical, then all the functions HOOPS Visualize already supported via fixed-function pipelines had to be supported in a shader-based pipeline. This was a significant challenge and work began on a shader-based pipeline for DirectX 9 in 2006.

While shaders are generally associated with visual quality and advanced effects in computer games and movies, it quickly became clear to the HOOPS Visualize’ developers that in industrial applications shaders could be used to improve performance.

For example, most computer games don’t draw many, if any, lines. Most CAD applications draw lots of lines. Consequently the fixed-function implementations for line-drawing in many DirectX 9 hardware drivers were generally very slow – often unacceptably slow for industrial applications. By using shaders to implement line-drawing along with HOOPS Visualize’ complex line-styles, end-caps and glyphs, the whole pipeline in DirectX has been speeded up dramatically for scenes containing these entities.

HOOPS Visualize now has a fully developed shader pipeline for DirectX9 and OpenGL

These shader pipelines offer the following advantages:

  • There is substantial code-sharing between the DirectX and OpenGL drivers
  • Stability across graphics cards that implement full shader interfaces is improved as the same HOOPS Visualize code is executed on all these cards. The amount of card-driver dependent code in use is reduced.
  • Performance drops (“slow-paths”) on these graphics cards are reduced as more functionality is now executed in shaders provided by HOOPS Visualize.

Jaw model with multi-layer transparency and ambient occlusion.

Visual Quality

Visual Quality

Although the HOOPS Visualize toolkit is primarily focused on delivering high levels of performance and interactivity, visual quality is also important. This section briefly details some of the more important features HOOPS Visualize offers in this area.

The HOOPS Visualize API has extensive support for color including multiple color models, color maps, color aliases and different definitions for the front and back of a material.

Gouraud and Phong Shading Models

HOOPS Visualize supports the standard gouraud and more advanced phong shading models. With Gouraud shading the light at each vertex is computed and then interpolated across the face. With Phong shading the light is calculated for every pixel on the face, resulting in a more accurate display of curved surfaces and enhanced specular highlights.

Phong shading is computationally intensive and has generally been difficult to do interactively. HOOPS Visualize is able to exploit the power of modern GPUs to deliver fast and accurate phong shading.

HOOPS Visualize Gouraud shading (left) and Phong shading (right).

Color Interpolation for Display of Analysis Results

A broad range of applications require a visual representation of values that have been obtained through extra calculations such as finite element and computational fluid dynamics, or that represent externally measured or modeled data e.g. oil reservoir and mine engineering. Examples range from the stress on the undercarriage of a plane during landing through estimates of mineral amounts from geological models.

At its simplest, color interpolation involves setting a color representing the external value on each vertex of each face. Colors are then interpolated across the face to give an approximate representation of how the values change across each face, and hence across the entire model.

In many cases each color represents and exact range of values and vertices on the original polygon mesh (“HOOPS Visualize shell”) may not directly correspond with changes in value. HOOPS Visualize offers and advanced function called color index interpolation which uses textures and texture maps to accurately display the changes between color bands, irrespective of where vertices on lie on the underlying mesh. An option is provided to blend the hard-edged bands if preferred.

Section of an engine block showing mesh edges (top left), color interpolation (top right), color index interpolation (bottom left) and blended index interpolation (bottom right).

Isolines and Contour Lines

Consider that each vertex in polygon mesh (shell) represents a real-world value. It is therefore possible to calculate lines that lie on the surface of the mesh of constant value. These are called isolines, or contour lines, and HOOPS Visualize provides a wide variety of functions to calculate and display them.

Isolines calculated from values on an engine block mesh.


Advanced Hidden Line

A number of highly configurable hidden-line algorithms are supported varying from fast shader-based approaches to full analytical hidden-line suitable for large-scale plotting.

The ‘fast hidden line approach’ uses the z-buffer on the graphics-hardware to perform hidden line for interactive viewing.

Shader-based fake hidden line creates an effective approximation of a hidden line view. Combined with the fast silhouette option and thick silhouette objects a technical drawing style can be achieved. Ambient occlusion can be added to give extra depth.

Fake hidden line with silhouette edges and ambient occlusion.

Hybrid Rendering of Hidden Line, Transparency and Shadows.



One of the most commonly used methods to create both realism and fantasy in interactive computer graphics is to map a 2D image (bitmap) onto surfaces in the 2D or 3D scene. This is known as texture mapping.

A stadium model enhanced using texture mapping.

HOOPS Visualize has extensive support for textures and texture mapping including using images for the window background, for decals (applying text and logos to surfaces), applying multiple textures to different faces in a shell, environment mapping and zebra striping to visualize surface continuity. HOOPS Visualize also supports grayscale and compressed images which can in turn be used to reduce texture size. (Supported formats include JPEG, TARGA, DXT1, DXT3 and DXT5.)

Environment mapping (left), overlapping textures (middle), different textures on faces in a shell (right).

Zebra-striped shading to analyze surface curvature.

Advanced Shaders

Advanced Shaders

The following advanced functions require implementation using GPU shaders to be effective. It is technically possible to implement some through fixed-function pipelines but the quality is generally inferior.

Bump Maps

Bump mapping is a technique used to convey surface texture and roughness. A specific lighting calculation is carried out for each pixel based on a ‘bump map’ texture that describes the height of the surface at each point. In some implementations, including HOOPS Visualize, the height map is converted to a normal map which represents the direction of the surface normal at each pixel as opposed to the actual height value.

A stone wall texture with a bump applied.


Fast Silhouette Edges

As a standard HOOPS Visualize provides control over whether interior and exterior (perimeter) silhouette edges are drawn. Using the standard fixed function pipeline there is always the possibility that the face display will interfere with the interior edge display causing stitching artifacts.

Fast silhouette edges are a shader-based technique based on examining differences in values in the z-buffer, rather than inferring the edges from the topological definition. As the name suggested, this technique offers dramatically better performance.

The ‘heavy exterior’ sub-option can be enabled to draw the external edges more thickly. Combined with Gooch shading this gives a technical drawing appearance.

A structural steel model with normal lighting (left) and enhanced silhouette edges (right).

Real-Time Shadows

Traditionally accurate shadow calculations have been very computationally expensive and largely the preserve of ray-tracing systems, where much of the expense of calculating the shadows has already been performed as part of the ray-trace.

HOOPS Visualize provides GPU-based shadow mapping which uses a two-pass rendering technique to simulate accurate shadows in real-time based on the z-buffer and textures. Advanced options include automatically regenerating the shadow map resolution as the camera zooms in and out, and adding a jitter effect to blur the hard edges of the shadows.

Real time shadows on a turbine model.


Ambient Occlusion

Ambient occlusion is a technique that uses global lighting calculations to identify occluded areas and reduce the ambient light in these areas. It gives a soft shadowing effect to the model and enhances contrast to give the model more ‘pop’.

An architectural interior with flat lighting (top), ambient occlusion (middle) and real-time shadows (bottom)

Ambient occlusion is also very effective when used together with fake hidden line:

A mechanical model rendered with fake hidden line and ambient occlusion.



Bloom mimics the distorting bleed effect seen when viewing a bright light source through a real-world lens. Bloom has the effect of enhancing specular highlights and is particularly effective when used in conjunction with environment mapping to represent reflective surfaces.

Radial bloom (left) and Star bloom (right).

Depth of Field

When objects are viewed through a lens, those that lie outside the focal range of the lens appear blurred while objects that are in the focal range appear in focus. The quality of this blurring is referred to by photographers as “bokeh” and narrow ‘depth of field’ is exploited by cinematographers and photographers to enhance an image by focusing attention on the subject.

Depth of field applied to a cityscape.

Gooch Shading

The Gooch shading model is a non-photorealistic technique aimed at technical illustration. The shading calculations incorporate some physics-based calculations. The results are blended with an artistic color scheme that assigns warm colors to bright surfaces and cool colors to darker surfaces. The results can then be blended with more traditional diffuse lighting.

Gooch rendering is generally used with enhanced silhouette edges to create the feel of a technical drawing.

A Formula 1 car with normal shading (left) and cartoon-style Gooch shading (right)

Hemispheric Ambient Lighting

This real-time technique is used to simulate the contribution to color from reflected light on the ground and lighting conditions in the sky. A lighting vector is defined and color contributions for that vector and its reverse are defined.

Scene with textures and ambient occlusion (left), interactive shadows and hemispheric lighting (right).


Reflection Planes

Reflection planes mirror the scene and give a perceived mirror quality to the boundary between the reflection and the scene. This can be particularly effective for the display of mechanical designs. HOOPS Visualize provides a number of options including blurring, transparency and distance attenuation.

A car model using ambient occlusion, real-time shadows, silhouette edges, bloom a reflection plane.

Material Library

Material Library

The Material Library offers a way to rapidly load, maintain, manipulate and customize sophisticated materials in the HOOPS Visualize environment. The Material Library consists of two main components:

HMaterialLibrary class:  The class works in conjunction with the Material Resources resources package that can be downloaded from the Developer Zone.

Material Resources:  The Material Resources package is a collection of sophisticated materials and environments developed by a team of artists, shader experts and engineering industry veterans.   The materials represent the most commonly found materials in the engineering and visualization space. Each material consists of photorealistic textures that have been paired with highly tuned custom shader code that accentuates the uniqueness of each material.

The figure shows the Material Library workflow as detailed by the steps below.

Model with advanced materials, shadows, bloom, and ambient occlusion.

Custom Material Shaders

For the DX9 and OpenGL2 drivers, HOOPS offers the ability to enhance the rendering pipeline by allowing developers to inject custom code into the pixel shader. This is achieved by defining a custom shader using a Define_Shader function.

Creating custom shader code is an intricate process. In many cases, custom shaders are written for a specific texture.The Material Resources package includes a wide range of custom shader code that you can use as samples.

In the custom shader source, you can have one or more glsl/hlsl functions that override HOOPS default pixel shader behavior. There are four points where you can intercept execution:

  • color_shader: defines the base color of the material, e.g.: procedural wood, perlin turbulence, or perhaps just a simple texture lookup.
  • surface_shader: e.g. bump mapping, parallax mapping, displacement, providing vector field data for anisotropic materials.
  • lighting_shader: modifies or replaces the standard lighting calculations.
  • effects_shader: modifies or replaces mirror value, environment color, and glow level.

Figure 5.7.1.a shows the intercept points for the pixel shader execution.

At each intercept point, the normal HOOPS shader code runs first. Then your shader code will receive our outputs as your inputs. Your shader can selectively override some outputs or write all the outputs. In the latter case, the shader compiler will discard the HOOPS shader code when it optimizes it.

Advanced Features of HOOPS Visualize/MVO

HOOPS Visualize/MVO Operators

As well as providing the extensible application-layer framework for event/action operators, HOOPS Visualize MVO provides a substantial set of predefined operators that can greatly reduce development time on new projects and applications.

The Event Manager class manages receives and dispatches events, including those from the mouse and keyboard, to multiple recipients. Pre-defined event managers are provided for the 3D input devices such as the Space Mouse and joysticks.


  • Camera Orbit, Camera Pan and Camera Zoom
  • Camera Orbit Turntable: Orbit the camera constrained about the defined axis (default-Z)
  • Camera Orbit Relative: Orbit around an object or point in the scene
  • Camera Zoom Box: Zoom the camera to the area selected area by a rubber-banded rectangle
  • Camera Manipulate: Combines Orbit Pan and Zoom using Ctrl and Shift keys. Also use third button for Camera Orbit Relative and Scroll Wheel for Zoom.
  • Camera Walk: Generalized operator for scene walkthroughs
  • Forwards, backwards, left/right dolly, up, down, look up, look down
  • DOOM Style Keyboard control or flight-style mouse control
  • Gravity and Collision detection
  • Walk speed controllable relative to bounds of scene

The HOOPS Visualize/MVO Undo Manager tracks camera and matrix changes and can be further enhanced to include user-defined undo actions.


All operators use HSelectionSet to manage a group of current selections so multiple selections can be performed and managed using Ctrl-Select.

  • Aperture Select: a hit test based on a circular aperture defined using the selection proximity.
  • Area Select:  select using a rectangular drag-box
  • Polygon Select: select using a user-defined polygon
  • Polyline Select: select using a user-defined polyline

Area select (left), polyline select (middle) and polygon select (right).


Operators are provided for the temporary or permanent interactive creation of circles, cones, cuboids, cylinders, NURBS curves and surfaces, polylines, rectangles, spheres and cut/section planes.

Annotation and Markup

Operators are provided for redlining (circle, rectangle, screen space polyline and world space polyline), post-it notes, annotations and dimensions.

The Markup Manager controls placement of the annotations and markers in the scenegraph and a layer-based organization is provided. Annotations added to the scene are automatically stored with HSF files.

HOOPS Visualize-Based Annotations in Solidworks eDrawings



The core database, HOOPS Visualize/3DGS, has no built-in concept of animation. Normal scenegraph inheritance rules allow developers to easily add simple animations and create forward-kinematic chains.

Additionally animations that comprise geometry or color interpolation changes can be created, either by directly editing the geometry per frame using 3DGS edit functions, or by swapping successive references to the modified geometry as the animation proceeds.

Animation of landing gear showing changes in stress on a strut.

The animation classes in HOOPS Visualize/MVO provide a complete keyframe animation engine built on top of HOOPS Visualize/3DGS.

Example code is provided for recording camera flythroughs, smoothed scene transitions, exporting to HSF, XML and AVI. Sensors can be defined so that animations can be activated automatically in response to user events and animated objects can detect if they collide with other elements in the scene, triggering a callback.

Animation of interpolated values in an engine block.

Graphs, Charts and Plots

Although HOOPS Visualize is not designed as a charting tool, the highly optimized draw pipeline and fast selection routines available in HOOPS Visualize can offer an advantage when creating plots and graphs with large numbers of datasets.

Application developers are free to build their own graph and plot subsystems on top of HOOPS Visualize/3DGS. HOOPS Visualize/MVO contains a set of classes that can be used independently of the other parts of MVO to speed this process. Pie charts, histograms, line graphs and mixed 2D plots are all supported.

An interactive plot of four hundred thousand points using HOOPS Visualize.

Manipulator Handles

HOOPS Visualize/MVO provides a set of classes that create and manage both simple and complex on-screen geometry manipulation. These classes can be used as-is or the code can be used as an example framework for setting up manipulators specific to an application. Custom manipulators can be created where user-defined geometry is used for each manipulator handle in place of the standard geometry provided by HOOPS Visualize/MVO

The manipulators provide constrained translation, rotation and scaling along both axes and in planes axes as well as free form movement.


Interactive Scene Widgets

In many cases it is desirable to have context-based controls shown in the scene close to the current point of interest. This reduces the amount of screen real-estate needed to use an application effectively and also reduces the distance of mouse moves needed to complete an operation.

The HOOPS Visualize/MVO walkthrough operator provides an example of this type of control, in this case designed for interactive navigation through datasets, as opposed to orbiting around them. The operator can be used as-is, or as the basis for extension to application specific in-scene controls.

Clash Detection

HOOPS Visualize offers a range of utilities to support advanced clash and collision detection. These include

  • Detecting collisions with the camera during interactive walkthroughs – so the viewer cannot walk through walls for example
  • Sweep-based dynamic collision detection for simulation of moving objects e.g. robotic workcells, CMM probes, multi-axis machine tools and fixtures, material flow through factories
  • Static clash detection for identifying design errors in large capital projects with multiple suppliers e.g. construction, plant and shipbuilding projects
  • Point-based clash detection for adding new geometry to laser-scans of existing environments

HOOPS Visualize collision detection is based on polygonal and point geometry and is heavily optimized for performance. A spatial hierarchy is created so that individual triangles and points are spatially localized so that expensive triangle-triangle or triangle-point intersection calculations are minimized.

Both hard (intersecting) and soft (touching) clashes can be identified, and nearest distance calculations are available to determine whether non-intersecting geometry lies within a specified tolerance – for example electric cabling that has been placed too near a hot pipe.

Clash detection in HOOPS Visualize is provided in several layers. The core geometry functions are available in the HOOPS Visualize/3DGS library and can be used to rapidly develop a custom clash or collision framework to a custom specification. Additionally HOOPS Visualize/MVO provides an extra framework for static clash detection that includes an example MFC-based user interface in the HOOPS Visualize Part Viewer demonstration application.

The sample interface includes options for controlling calculation and results, selecting which parts of the model tree to compare with which other parts, a variety of highlight modes and the ability to identify each clashing object in the model tree.

PMI Classes

HOOPS Visualize/MVO provides a set of PMI classes which simplify managing PMI or GD&T data in a HOOPS Visualize scene graph. Classes are provided for inserting, modifying and querying datums, dimensions, feature control frames, view entities, notes and roughness features. There is also a facility for dealing with generic PMI, meant to allow managing GD&T which doesn’t conform to the any of the other types provided. Additionally the PMI classes provide a means of creating views associated with PMI entities created via the classes. Here is a sample scene graph structure that is automatically generated from the PMI classes:

Here is a sample view entity, associated with a specific DatumEntity and FeatureControlFrameEntity:

Data Import and Export: HSF, Bridges and HIO Modules

Data Import and Export: HSF, Bridges and HIO Modules

As already mentioned The HOOPS Visualize 3D Application Framework comprises more than core geometry and graphics routines. One particularly important area is the links and bridges to external file formats and modeling engines.

HOOPS Visualize Stream Format (HSF)

The HOOPS Visualize Stream Format is an open, extendible, highly-compressed and streamable file format designed for lightweight communication of graphical and geometrical information. Reading and writing HSF is supported by the HOOPS Visualize Stream libraries.

  • Extendible: HSF and the supporting read/write libraries, is token-based. Tokens to support all HOOPS Visualize primitives and entities are pre-defined. Application developers can add their own tokens to extend the format. When read into HOOPS Visualize using standard code tokens that have not been recognized are simply ignored.
  • Highly-Compressed: HSF supports both lossless LZ compression and advanced edge-breaking algorithms. Lossy compression allows vertices and normals to be written in a compressed format that is significantly smaller than standard floating point.
  • Streamable: HSF supports:
  • object revisiting – objects can be tagged to be revisited later in the import or export.
  • piecemeal reading and writing – user-specified chunks of data can be read or written.
  • data dictionary – the scenegraph can be written first followed by the geometry allowing the structure of the file to be quickly read in and then the required nodes to be read first.
  • automatic object prioritization – shell primitives can be prioritized based on their size and vertex density.

The HOOPS Visualize Stream Format has been adopted by a number of major Mechanical CAD vendors as the basis for their proprietary lightweight file formats.

HOOPS Visualize Parasolid and ACIS Bridges

Bridges between HOOPS Visualize and the two most commonly used solid modeling kernels can be provided for use with HOOPS Visualize. The term ‘bridge’ is used to indicate a bi-directional link i.e. a mapping table is maintained so that a Parasolid or ACIS entity can be easily identified from a HOOPS Visualize entity, and vice versa. This makes the process of selection for modeling easier.

The Parasolid Modeling kernel can be licensed directly from Tech Soft 3D.

In addition two extended file formats based on HSF are provided by way of example – PSF (Parasolid Stream Format) and ASF (ACIS Stream Format). Each format contains both solid-based geometry for modeling and the polygon-based geometry for graphical display.

The HOOPS Visualize/Parasolid Bridge is provided in readable source code on the standard HOOPS Visualize installation. The HOOPS Visualize/ACIS Bridge is available to licensees of ACIS.

The Parasolid and ACIS Partviewers are provided in source code form as reference applications that comprise significant functionality.

The Parasolid Part Viewer Reference Application.

HOOPS Visualize/HIO Modules

HIO stands for HOOPS Visualize Input/Output. The HIO modules are based around a plug-in architecture to HOOPS Visualize/MVO. At runtime, if the appropriate DLLs are available then HOOPS Visualize/MVO will automatically extend the input and output options from HOOPS Visualize to include that file format.

Many HIO modules are based around third-party libraries. Some must be separately licensed and for some there is an extra charge.

Here is an example of supported HIO modules:

  • Autodesk DWG, based on Autodesk RealDWG libraries
  • Adobe PRC, based on Adobe Acrobat Pro Extended
  • Bentley DGN, based on the Open Design Alliance DGN libraries
  • Autodesk DWF, based on the Autodesk DWF Toolkit
  • Google Sketchup, based on the Google Sketchup SDK.

In most cases a mapping is maintained between entities in the external database e.g. DWG, and the HOOPS Visualize entities that have been created from them.

Splat rendering of a laser scan of a city street.

Graphics Card Support

Graphics Card Support

One of the more time-consuming problems facing any developer of hardware-accelerated graphics applications is the problem of bugs and instabilities in the drivers for the GPU itself. These drivers are very complex and in most operating systems they are supplied by the card vendor – typically NVIDIA, AMD or Intel. Problems can be common and, when reported, can be difficult to identify and workaround. One of the key benefits for HOOPS Visualize customers is that when these potentially time consuming problems occur they have someone to turn to. Tech Soft 3D’s approach to handling graphics card driver instabilities includes:

  • HOOPS Visualize is continually tested against different graphics cards on multiple platforms, including laptops. The Tech Soft 3D graphics card lab now contains more than 130 graphics cards.
  • When a problem occurs on a particular card our support team will cross-check for known issues reported by other customers. In many cases the problem can be fixed by upgrading the card driver, in other cases by downgrading the card driver to an older version.
  • If changing the graphics card driver does not resolve the problem then the HOOPS Visualize Graphics Card Validator should be run. This HOOPS Visualize-based test program is shipped with each HOOPS Visualize release and performs a series of tests to identify which calls in HOOPS Visualize are causing the problem. A log file is produced and that can be sent to Tech Soft 3D support.
  • If a problem is identified Tech Soft 3D will if possible acquire the graphics card and work to resolve the problem. Internally HOOPS Visualize maintains a table of graphics cards and known problems when a HOOPS Visualize driver is initialized HOOPS Visualize can enable appropriate workarounds for that specific GPU.
  • When the problem is resolved the fix or workaround will be added to HOOPS Visualize. In many cases the HOOPS Visualize API function Define_Driver_Config can be used to extend the table for that graphics card. This allows application developers to apply patch fixes without needing a new of version of HOOPS Visualize or shipping new DLLs.
  • In some cases the workaround will not be sufficient and new versions of the HOOPS Visualize dlls will be made available in a point release.
  • While in all cases the preference is to resolve the actual issue with the card, Tech Soft 3D understands that end-users have their own jobs to do and simply want to continue working, not spend time changing graphics drivers etc. HOOPS Visualize-based applications have several options to facilitate this:
    If running with OpenGL as the primary driver, switch to DirectX, or vice versa. The drivers provided by the graphics card companies are quite different, and a problem in one usually doesn’t manifest in the other.
    If there is still a problem run HOOPS Visualize in safe-mode. This forces HOOPS Visualize to use a software pipeline which bypasses the graphics card driver altogether. Stability is chosen over performance.

What is a Scenegraph?

What is a Scene Graph?

It is surprisingly difficult to providing a definition of a scene graph that is succinct, useful and non-trivial (a graph that describes a scene). Here is one attempt:

A scene graph is a way of ordering graphical scene data into a hierarchy where parent nodes affect child nodes.”

This definition probably excludes some structures that could be called scene graphs, and includes others that most probably wouldn’t consider as scene graphs.

Working with most common conception it is important to note

  • the parent to child relationship is fundamental
  • the order is important i.e. child nodes inherit attributes from parent nodes

Scene graphs form a useful abstraction for both scene data and scene behavior. Prior to the use of scene graphs both data and behavior were defined procedurally. Code defining the scene was interspersed with code that operated on the scene. Hence scene or behavior changes involved modifying code. A scene graph encapsulates the scene in a manner that allows it to be modified independent of both code and scene geometry.

A scene graph can also be considered a higher-level abstraction to lower-level graphics APIs such as OpenGL and DirectX although this is merely one specific example of the principles of abstraction and encapsulation.

Example: A Simple Solar System

Consider a simple solar system, with two planets orbiting a star and two moons orbiting each planet.

The left-hand diagram above shows how this solar system might be represented in a hierarchy. The position of the each moon at any point in time is calculated by combining the rotation transforms of its parents.

The right-hand pseudo-code demonstrates how to draw this system explicitly in code. This is fine, but what happens if the system changes slightly – for example imagine planet 1 develops a slight precession (wobble) while orbiting the star.

The diagram on the left below shows that in terms of the graph the precession can be accommodated quite easily. However the explicit code must change considerably – and it would be easy to mismatch the saving and restoring of matrices to get the wrong result. This is only a simple example.

Code that walks the scene graph deals with each node, entity and attribute in a generic sense i.e. the same code can be used at any point in the scenegraph. A scene graph walk routine will start at the top, examine each node and execute the relevant routines depending on what that node represents. The expanded result will be a sequence of calls similar to the diagram on the right, but the code that creates those calls will be very different using simple loops and recursion.

Loading posts...