7.5 Controlling Memory Usage

The dynamic allocation and releasing of memory in HOOPS/3dGS is controlled by an internal memory manager. When new objects are inserted into the database and files are loaded, the memory allocation for these items are performed by the memory manager. As files are closed and objects are deleted, the memory manager takes care of the freeing of the memory associated with them.

If your HOOPS-based application is experiencing memory problems, you can perform memory debugging by enabling the system option raw memory via the Define_System_Options function. When this setting is turned on, HOOPS no longer uses its internal memory manager for dynamic memory allocation but calls directly to the operating system for the allocation and freeing of memory. The direct calls to malloc and free allows a developer to easily track memory leaks using Valgrind, Visual Studio or any other memory debugging tool. Note that turning raw memory on can significantly effect HOOPS/3dGS performance. We do not recommend enabling this option for shipping versions of HOOPS-base application. Thus, by default, raw memory is turned off.

When memory is scarce and performance is a priority, the ability to control memory usage is vital to the responsiveness and effectiveness of an application. For applications that want to use their own memory manager, HOOPS provides functionality for more direct control of the internal memory usage via the malloc and free options in Define_System_Options. To use malloc and free, you must make Define_System_Options your first call to HOOPS and set these options at that time. The malloc option accepts a function pointer which will be used by HOOPS to request memory for new objects. The free option accepts a function pointer that HOOPS will use to release memory. Malloc and free must be set in conjunction with one another. Note that these options are persistent through a call to Reset_System.

In general, if you want to track HOOPS' memory usage in your application, you can use the function Show_Memory_Usage. This function returns via reference the amount of memory that HOOPS has allocated as well as how much memory is currently being used. If you find that there is a significant gap between these two numbers, you can call Relinquish_Memory to force HOOPS to release unused memory back to the system.

If malloc and free options are set as well as raw memory, the malloc and free options will supercede the raw memory. Note that even when these memory options are used, HOOPS still uses the internal memory manager to control the allocation of small internal data structures.

7.5.1 Geometry Memory Optimizations

HOOPS/3dGS automatically performs a considerable amount of memory optimization internally for the storage and rendering of geometry. However, there a few special options and notes related to optimizing memory usage for faces.

7.5.1.1 Shell Facelists

HOOPS/3dGS retains the facelist passed into Insert_Shell by default. The number of bytes allocated for each shell facelist can be quite high. For example, a shell with 1 million triangular faces (therefore references 3 points), HOOPS/3dGS will use an extra 16MB of memory to perform the SSE-based software culling.

However, if the shell will not be edited, local shell attributes will not be edited after the first update, and the original facelist does not need to be accessed via Show_Shell, then the facelist need not be retained. Setting the conserve memory option to 'face list'in a call to Define_System_Options instructs HOOPS/3dGS to discard the facelist after the shell has been drawn for the first time.

  HC_Define_System_Options("conserve memory = face list");  

If the facelist has been discarded, then Show_Shell will return a facelist based on the interally-calculated tristrips, which means that each face will consist of a single triangle.

7.5.1.2 Software Culling Optimizations

HOOPS/3dGS tries to perform backplane culling using a technique called 'screen-plane facings' when display lists are turned off. This technique can improve rendering performance by up to 35%, but at the cost of additional memory usage for shell primitives. The number of bytes allocated for each shell's 'facings' can be up to twenty times the number of faces. For example, HOOPS/3dGS will use an additional 20 MB of memory to perform the SSE-based software culling for a shell with one million faces. This technique is only used if Intel x86 SSE extensions are available. If the extensions are not available, then culling will be performed as usual; specifically, it will be performed by the underlying 3D hardware if a 3D driver is being used, or via a regular software path if a 2D driver or software z-buffer is being used.

This functionality can be disabled by calling Define_System_Options and setting the conserve memory option to 'facings':

HC_Define_System_Options("conserve memory = facings"); 
Next

Previous

Index