Examples of Opticks Usage, especially the CMake machinery

The examples have go.sh scripts which perform the normal config, make, install using a fresh build dir every time. This is a convenient when the focus is on the CMake machinery.

Testing CMake finding externals and minimal usage

UsePLog

simple executable using PLog via imported interface target from cmake/Modules/FindPLog.cmake

UseGLMRaw

(plain vanilla modern CMake with target import/export)

• find_package(GLM) succeeds due to cmake/Modules/FindGLM.cmake which exports the Opticks::GLM interface only target (GLM is just headers)
• vending targets as of CMake 3.5 takes lots of boilerplate

UseUseGLM

(plain vanilla modern CMake)

• find_package(UseGLM) succeed due to the exported target written by UseGLM
• nice and simple : plain CMake is fine when consuming targets only without vending.
• Note that only need to be concerned with direct dependency on UseGLM. The dependency of UseGLM on GLM comes along with the imported target with no effort.
• Also note that the dependency transmission is working across package boundaries, ie UseGLM and UseUseGLM are not tied together in a single CMake build, they are entirely separate projects.

UseGLMViaBCM

(modern CMake assisted by BCM)

• much less boilerplate, intent is clear
• forced(?) to place headers into an include folder in source dir
• forced(?) in install at prefix/include rather than current opticks location prefix/include/name/
• HMM: NOT KEEN ON CO-MINGLING HEADERS OF ALL PROJECTS IN A SINGLE include DIR, OR ON HAVING THE HASSLE OF SEPARATE include DIR for sources

UseUseGLMViaBCM

• similar observations to UseUseGLM

UseOpticksBoost

no longer operational exercise for the old variable-centric approach to Boost hookup

UseBoost

Attempt to vend a library target that uses Boost::filesystem:

16 find_package(Boost REQUIRED COMPONENTS filesystem)
17
18 ## kludge that tees up arguments to find_dependency in generated export useboost-config.cmake
19 ## so downstream will automatically do the above find_package
20 set_target_properties(Boost::filesystem PROPERTIES INTERFACE_FIND_PACKAGE_NAME "Boost REQUIRED COMPONENTS filesystem")

UseUseBoost

attempt to use the lib target exported from UseBoost, initially failed to auto hookup the non-direct Boost::filesystem dependent, because useboost-config.cmake had:

include(CMakeFindDependencyMacro)
# Library: Boost::filesystem
find_dependency(Boost)
include("${CMAKE_CURRENT_LIST_DIR}/useboost-targets.cmake")
include("${CMAKE_CURRENT_LIST_DIR}/properties-useboost-targets.cmake")

Suspect problem is that the non-BCM exported targets lack some needed metadata ? YEP, BCM relies on setting target properties in bcm_deploy that get read on generating the exported target serialization. Kludge fix is to misuse that property as shown above, so that the imported target automatically does the necessary:

find_dependency(Boost REQUIRED COMPONENTS filesystem)
# this works with cmake_minimum_version set to 3.5 with cmake 3.11

UseOpenMesh

check consumption of BCM exported targets done by cmake/Modules/FindOpenMesh.cmake

UseG4NoOpticks

used to develop a new FindG4.cmake that works with both Geant4 1042 and 1062, does not use Opticks at all : requires BCM and Geant4 to be installed and provided on CMAKE_PREFIX_PATH

UseUseG4NoOpticks

paired with UseG4NoOpticks, creating an executable that uses the lib from UseG4NoOpticks

CMake finding Opticks sub-packages

UseSysRap

vends a library that uses the SysRap target exported by sysrap/CMakeLists.txt

UseUseSysRap

uses the UseSysRap exported library, succeeds to auto-find the dependencies (SysRap) of its direct dependent UseSysRap

UseBoostRap

testing dependency isolation of BoostRap

UseNPY(needs-revisit)

old first attempt using raw inclusion of exported targets with the non-standard approach of cmake -DOPTICKS_CONFIG_DIR=/usr/local/opticks/config rather than using the standard find_package mechanism

• exporting was done in opticksnpy/CMakeLists.txt BUT: this approach is jumping into the thicket of the dependency tree. Better to get experience out in the leaves, before tackling the interior of the bush.

UseOpticksGLFW

minimal use of OpenGL via GLFW, pops up a window and renders a colorful rotating triangle. Key presses cause the GLFW_KEY_XX enum name to be emitted to stdout. Press ESCAPE to exit.

UseOpticksGLFWSnap

variant of UseOpticksGLFW adding the capability to save screen images to PPM files

UseOpticksGLFWSPPM

variant of UseOpticksGLFWSnap with the PPM handling from reusable sysrap/SPPM

UseShader

Formerly named UseOpticksGLFWShader

• adapted GLFW example, modified to use GLEW and GLM : it ran giving a black screen.
• adding a VAO makes the coloured triangle appear
• added error checking and compilation log output

This is a good starting point for creating self contained minimal reproducers.

UseOGLRapMinimal

Creates red-green-blue axes that can interact with using the usual controls. Tests the Rdr axis renderer in isolation using just Composition, Frame and Interactor (no Scene).

UseGeometryShader

Creates red-green-blue axes

Implemented in standalone single file fashion that sets up a geometry shader pipeline using the same shader strings as the Rdr axis renderer as used by UseOGLRapMinimal. All the mat4 have been matched with UseOGLRapMinimal.

Features a monolithic standalone getMVP, providing the ModelViewProjection matrix, which is useful for demo code.:

glm::mat4 getMVP(int width, int height, bool verbose)

Actually it was the comparison of the mat4 between UseOGLRapMinimal which uses View::getTransforms and my standalone reimplementation of the matrix manipulations in UseGeometryShader that led to finding the "uninitialized forth row bug" that has been lurking for years ready to bite just at the wrong time following a Linux kernel and driver update and OptiX update.

See the mis-named: notes/issues/OGLRap_GLFW_OpenGL_Linux_display_issue_with_new_driver.rst

UseOGLRap

same as OGLRap AxisAppCheck

UseOpticksGL

OAxisTest appears to be trying to change things with OptiX launches whilsy displaying with OpenGL

UseOpticksGLEW

Just dumping version numbers from header. CMake machinery test.

(2024 March) Reboot of OpenGL + CUDA Interop examples

UseGeometryShader

record array rec_flying_point viz using early stage of SGLFW.h encapulation (refreshed July 2025)

• NB build.sh script is unusual, it builds against OpenGL without using CMake (working on Darwin and Linux)

UseShaderSGLFW

single triangle (refreshed July 2025)

UseShaderSGLFW_Mesh

single mesh

UseShaderSGLFW_MeshMesh

multiple mesh

UseShaderSGLFW_MeshMesh_Instanced

with instancing

UseShaderSGLFW_SScene

get SMesh and instance transforms from SScene (refreshed July 2025)

UseShaderSGLFW_SScene_encapsulated

moving impl into SGLFW_Scene.h (refreshed July 2025)

Examples Directly Using NVIDIA OptiX

The below sections list examples using OptiX, named after directory names. Many of the examples are standalone in nature, not depending on an Opticks install. The steps to build (and sometimes run) are often simply:

cd ~/opticks/examples/UseOptiX
./go.sh

cd ~/opticks/examples/UseOptiX7GeometryInstanced
./go.sh

OptiX pre7 usage examples

UseOptiX

really minimal usage of OptiX C API, checking creation of context and buffer, no kernel launching

UseOptiXProgram

OptiX C API creates raygen program and launches it, just dumping launch index

UseOptiXProgramPP

OptiX C++ API variant of the above : provides a command line interface to quickly run simple OptiX code (no buffers in context).

UseOptiXBuffer

OptiX C API creates raygen program that just writes constant values to a buffer

UseOptiXBufferPP

OptiX C++ API : creates in and out buffers from NPY arrays and launches a program that simply copies from in to out. Provides a command line interface to quickly run variants of the buffer accessing GPU code.

UseOptiXGeometry

Minimally demonstrate OptiX geometry without using OXRAP, performs a "standalone" raytrace of a box with normal shader coloring.

UseOptiXGeometryTriangles

Minimally demonstrate the use of optix::GeometryTriangles introduced in OptiX 6.0.0. Raytraces an octahedron writing a PPM file. Based on NPY and SYSRAP for buffer and PPM handling. No OXRAP.

Standalone-ish OptiX 5 or 6 Examples

UseOptiXTexture

C API 3D texture creation, with pullback test into out_buffer

UseOptiXTextureLayered

Switch from 3D to layered 2D texture, exfill attempt to fill with MapEx failed

UseOptiXTextureLayeredPP

Convert to use OptiX 6 C++ API

UseOptiXTextureLayeredOK

Start encapsulation into Make2DLayeredTexture

UseOptiXTextureLayeredOKImg

Use ImageNPY::LoadPPM to load images into textures First try at 2d layered tex failed, so reverted to 2d textures.

UseOptiXTextureLayeredOKImgGeo

Ray-traced theta-phi texture mapping onto a sphere, when using an Earth texture this provides Earth view PPM images centered around any latitude-longitude position. This example was used to develop the watertight OptiX OCtx wrapper (C opaque pointer style) which does not leak any optix types into its interface.

Intersects are highly instrumented with the position of each interesect recorded into a pos buffer.

UseOptiXGeometryInstanced

start from UseOptiXGeometryInstancedStandalone, plan:

1. DONE: Opticks packages to reduce the amount of code
2. DONE: adopt OCtx watertight wrapper, adding whats needed for instancing
3. DONE: add optional switch from box to sphere
4. DONE: generate PPM of thousands of textured Earths

jumble of thousands of spheres gradient shaded with red/green/blue border/midline/quadline

UseOptiXGeometryInstancedOCtx

start from UseOptiXGeometryInstanced, using just OCtx

/tmp/octx.sh : normal shaded assembly of boxes and spheres /tmp/octx.sh global : global shaded assembly of boxes and spheres /tmp/octx.sh textured,tex1 : textured assembly of boxes and spheres, using tex1 green midline

/tmp/octx.sh single : normal shaded single box and sphere /tmp/octx.sh single,textured,tex1 : single box and sphere

/tmp/octx.sh textest,tex0 : vertical gradient with red border /tmp/octx.sh textest,tex1 : vertical gradient with green midlines /tmp/octx.sh textest,tex2 : vertical gradient with blue quadlines

ISSUE

on Linux/OptiX 6.5 the spheres are appearing as big boxes but there is no problem with the sphere implementation when used not in an assembly. Perhaps problem with the transforms/scaling/bbox ?

ISSUE HAS DISAPPEARED

Returning to this issue after implementing IntersectSDF to automatically test for such problems find that the problem is no longer happening.

UseOptiXGeometryOCtx

start from UseOptiXGeometry to investigate why getting problem with instanced spheres in OptiX 6.5 Creates PPM of a single normal-shaded sphere or box picked via argument sphere.cu or box.cu

UseOptiXGeometryInstancedStandalone

creates a jumble of thousands of randomly oriented boxes, colorfully normal-shaded

Experimental pre7 and 7 machinery

UseOpticksOptiX

checking FindOpticksOptiX.cmake can be made to work with 5,6 and 7

Standalone-ish OptiX 7 Examples

UseOptiX7

Basic check of CMake machinery, finding OptiX 7

UseOptiX7GeometryStandalone

Start from the SDK optixSphere example This example uses custom(aka analytic or non-triangulated) geometry. Follows the monolithic main layout of optixSphere, just adapting to use glm for viewpoint math. (Feb 2024: updated for OptiX 7.5+)

UseOptiX7GeometryModular

Start from UseOptiX7GeometryStandalone Apply wrecking ball to the monolith, splitting into:

Engine

context, control

Binding

common types between CPU and GPU

PIP

pipeline of programs creation and updating

GAS

geometry acceleration structure building

Revisited this, tidying up the headers aiming to eliminate optix types from high levels in order to hide the version. (Feb 2024: updated for OptiX 7.5+)

UseOptiX7GeometryInstanced

Attempting to switch UseOptiX7GeometryModular to use an instanced custom geometry for lots of spheres. (Feb 2024: updated for OptiX 7.5+)

UseOptiX7GeometryInstancedGAS

Started from UseOptiX7GeometryInstanced.

1. pulled out the higher level geometry setup into Geo
2. uses a single IAS with multiple GAS
3. create big sphere containing a cube grid of two radii, where the intersect program gets its sphere radius from Sbt record

(Feb 2024: updated for OptiX 7.5+)

UseOptiX7GeometryInstancedGASComp

Started from UseOptiX7GeometryInstancedGAS. (Feb 2024: updated for OptiX 7.5+)

UseOptiX7GeometryInstancedGASCompDyn

SBT mechanics worked out, using vectors of BI structs to keep count Find that have to fudge the bbox larger to get expected results ? (Feb 2024: updated for OptiX 7.5+)