The HOOPS/3dGS headers and libraries are located in the following directories:
Platform | Header location | Library location | Library names |
---|---|---|---|
Windows | /Dev_Tools/hoops_3dgs/source | /Dev_Tools/hoops_3dgs/lib/<platform> | hoops.lib |
Linux | <UNIX COMMON PACKAGE>/Dev_Tools/hoops_3dgs/source/ | /Dev_Tools/hoops_3dgs/lib/<platform> | libhoops<version>.so |
OS X | <UNIX COMMON PACKAGE>/Dev_Tools/hoops_3dgs/source/ | /Dev_Tools/hoops_3dgs/lib/<platform> | libhoops<version>.dylib |
Windows runtime DLLs are located at /bin/<platform>/hoops<version>_<platform>.dll. Linux and OS X runtimes are the same as the exported libraries mentioned in the table above. Regardless of platform, you must include the HOOPS/3DGS runtime libraries in the execution environments PATH, or in the application's current directory.
Additionally under Windows, if you wish to use the DX9 or DX11 drivers, you must ensure that the dx9_<hoops_version>.dll and dx11_<hoops_version>.dll files are included in your application's directory or the runtime PATH. These DLLs are also located in the /bin/<platform> directory of your HOOPS installation.
Developers can build a scaled-down version of HOOPS/3DGS. It will not be provided as a pre-built library; rather developers will be able to compile obfuscated HOOPS/3DGS source code using compiler flags to stub out pieces of functionality that are not needed (for example, -DDISABLE_SHOW in the CFLAGS line).
This section will provide details on the areas of core functionality that can be individually stubbed out, along with the estimated corresponding HOOPS/3DGS library size reduction.
The core functionality breakout list covers items that can be broken out as separate components. If all the items are broken out, the size of the HOOPS/3DGS library reduces to ~1MB. This size is largely a function of the core architecture of HOOPS Visualize which utilizes sophisticated data-structures and scaffold database/rendering/attribute logic to enable support of all these powerful components. Further reduction of the library size causes a run-in with the 80/20 rule (except in this case it is more like the 95/5 rule). That is, significant additional effort in stripping out functionality would result in minimal incremental size reduction.
This involves removal of all logic to perform software rasterization of the scene, with or without a z-buffering stage, including lookup tables, dc_z functions, etc... The Visualize software z-buffer and software-frame buffer logic is no longer available to produce non-OpenGL based interactive rendering of complex 3d, shaded scenes.
These include algorithms such as hidden-line-removal and painter's. This prevents HLR renderings, or mixed-mode (vector and raster) rendering of scenes to hardcopy devices such as a native GDI Printer or Clipboard DC, Postscript file/device, etc. If you wanted to ensure transparent objects were rendered correctly you would need to include at least one sorting algorithm (probably z-sort at a cost of ~ 8K).
If Item 1 is also stubbed out, then HOOPS/3DGS would not be able to rendering a complex scene to a hardcopy device. (Either it needs to be sorted and drawn back-to-front, or it needs to be rendered to an offscreen buffer using a szb/sfb. A remaining option would be for the developer to manually grab the screen image (or have OpenGL render to an offscreen image) and the blit that image to the hardcopy device.
Reading/writing HMF files would be unsupported.
TrueType, Double Byte, and Unicode fonts would no longer be supported.
This is the texturing software implementation and support code. If disabled, then objects could not be textured.
Certain display modes (8-bit, 16-bit; mapped and grayscale)
Any higher-level HOOPS attributes that apply to the visual appearance of entities (HOOPS-specific line-patterns, face patterns, marker symbols, etc.) that are not supported by OpenGL would no longer be supported.
The developer would not be able to query attributes in the HOOPS/3DGS scene-graph. (Typically this would be done within an application that provides editing capabilities.)
The developer would not be able to UnSet attributes in the HOOPS/3DGS scene-graph.
The developer would not be able to query/edit geometry primitives stored in the HOOPS/3DGS scene-graph. (Typically this would be done within an application that provides editing capabilities.)
The developer could not define custom fonts or use HOOPS internal stroked fonts.
HOOPS-style input handling would not be available. Typically this is only used in standalone 'HOOPS-only' demos.
Levels-of-detail for HOOPS/3DGS shell primitives could no longer be generated.
Developer could not search for open segments, color names, contents, aliases, textures, etc.
Developer could not set/show colors using HOOPS/3DGS' built in color names, or create their own color names.
Developer could not manipulate the HOOPS/3DGS scene-graph nodes (segments), such as copy, style, move, rename, flush, etc.
Developer would not have access to vector and matrix math utility routines, shell optimization routines, etc.
Developer could not perform selection using aperture, window, or volume selection methods / polygon or polyline selection.
The HOOPS I.M. API is no longer available. Developer can no longer make traversal time draw decisions, or utilize the immediate-mode type HIC_ routines to directly draw to the screen.
Developer could not use Code Generation system option.
Developers could not manipulate local face, vertex, and edge attributes from open shells and meshes.
HOOPS event handling routines. Developer could not use routines such as HC_Await_Event.
Developer would forfeit certain performance optimizations during operations such as normal vector calculations.
Developer would forfeit certain performance optimizations during some procedures, uch as the use of Show_Existence.
Developer would forfeit the use of Phong shading and software texturing.
Developer would forfeit the use of color index interpolation or color maps.
Developer would forfeit the use of partial erase.
Developer would forfeit the use of partial erase or sub-windows within included segments.
disables only HOOPS' internal implementation of capping polygon generation, leaving "cut edges" callbacks intact.
disables HOOPS' internal implementation of fake shadows
Next
| Index
|