DOCSEARCHbyAlgolia
Submit Docs

Intel OSPRay Documentation

repository·devel·Indexed 22 days ago

https://github.com/renderkit/ospray

An open-source, scalable, and portable ray tracing engine for high-performance, high-fidelity visualization. OSPRay supports Intel CPUs, Intel Xe GPUs, and ARM64 architectures, utilizing Intel Embree, Open VKL, and Open Image Denoise. The documentation covers build instructions via CMake Superbuild, cross-compilation, API initialization using ospInit, and extending the engine with new geometry types via the Module Concept.

Tokens
66.4K
Snippets
161
Records
240
Agent score
77%

What's inside OSPRay

  1. What is Intel OSPRay?

    devel

    Intel® OSPRay is an open-source, scalable, and portable ray tracing engine designed for high-performance, high-fidelity visualization. It supports both surface- and volume-based rendering for interactive applications and can run on various hardware scales, from laptops to HPC compute nodes.

    Key Characteristics:

    • Rendering Types: Supports surface-based and volume-based visualizations.
    • License: Apache 2.0.
    • Core Dependencies: Built on top of Intel Embree, Intel Open VKL, and Intel Open Image Denoise.
    • Implementation:
      • CPU: Uses Intel ISPC (Implicit SPMD Program Compiler) to exploit instruction sets like SSE4, AVX, AVX2, AVX-512, and NEON.
      • GPU (Beta): Based on the SYCL cross-platform programming language via Intel oneAPI DPC++.

  3. Overview of Intel OSPRay

    devel

    Intel® OSPRay is an open-source, scalable, and portable ray tracing engine designed for high-performance, high-fidelity visualization. It supports Intel Architecture CPUs, Intel Xe GPUs, and Aarch64/ARM64 CPUs.

    Key characteristics:

    • Target Hardware: Laptops, workstations, and HPC compute nodes.
    • Rendering Types: Supports both surface-based and volume-based visualizations.
    • Core Dependencies: Built on top of Intel Embree, Intel Open VKL, and Intel Open Image Denoise.
    • CPU Performance: Uses Intel ISPC to exploit instruction sets like SSE4, AVX, AVX2, AVX-512, and NEON.
    • GPU Support (Beta): Based on SYCL (via Intel oneAPI DPC++), supporting Intel Arc™ GPUs and Intel Data Center GPU Flex/Max Series.

  4. Access related Intel graphics technologies

    devel

    OSPRay often works in conjunction with other technologies. You can find information for these related projects at their respective sites:

    • Embree: Ray tracing kernels.
    • Open VKL: Volume kernel library.
    • Open Image Denoise: Image denoising technology.

  5. Explore OSPRay-powered visualization tools

    devel

    Several specialized applications use OSPRay for specific domains:

    • OSPRay Studio: A lightweight visualization application used to showcase the latest OSPRay features.
    • "osprey" Rhino Viewport Plugin: A plugin for Rhino3D that accelerates rendering compared to the built-in renderer.
    • Tapestry: A microservice for cloud-based scientific visualization that uses OSPRay to provide interactive visualization of large datasets via the web.
    • Megamol: A molecular dynamics framework capable of rendering billions of particles interactively using OSPRay.
    • VMD: A molecular dynamics visualization package that includes OSPRay as one of its integrated renderers.
    • pCon.planner: An architectural design application that uses OSPRay for photorealistic path-traced renderings.
    • VESTEC: A toolkit for extreme computing that utilizes OSPRay to realize 3D visualization environments for interactive exploration.

  6. Naming conventions for the OSPRay public API

    devel

    When designing or extending the public API, follow these naming rules to ensure consistency:

    • Enums over Strings: Prefer using enum types instead of passing string parameters.
    • Case Style: Use camelCase for both parameters and object names (e.g., metallicPaint).
    • Singular Parameters: Use singular names for parameters, even if they represent an array (e.g., index, material).
    • Prefixing Related Data: For data that belongs together (such as members of a struct-of-arrays), use a common prefix (e.g., vertex.color and vertex.normals).
    • Boolean Naming: For switches (bools), name the variable after what it switches, without prefixes like enable, use, or is (e.g., shadows instead of shadowsEnabled).

  7. C++ Memory Management and Pointer Guidelines

    devel

    Follow these practices for robust memory management in OSPRay:

    • Collections: Prefer STL containers like std::vector or rkcommon::containers::AlignedVector over C-style arrays.
    • Smart Pointers: Use smart pointers instead of raw new and delete. Use std::unique_ptr for heap objects unless multiple observers are required.
    • Allocation: Construct smart pointers using rkcommon::make_unique<> or std::make_shared<> rather than using new.
    • Pointer Scope: Keep raw pointer usage local to a single function or a single .cpp file.
    • References vs Pointers: Use references instead of pointers when nullptr is not a valid value.
    • Cleanup: Use rkcommon::utility::OnScopeExit to ensure non-trivial objects are robustly cleaned up when a function exits.

  8. Configure photometric lights with intensity distributions

    devel

    Photometric lights (measured sources like IES) can use an intensityDistribution array to modulate intensity per direction. This is supported by sphere, spot, and quad lights.

    Mapping Logic:

    • 1D Array: Values are mapped to the C-$\gamma$ coordinate system where $\gamma$ is in $[0, \pi]$. The first value is at $0$ and the last is at $\pi$.
    • 2D Array: Used for asymmetric illumination. Values are mapped to C-halfplanes in $[0, 2\pi]$. The orientation of the $C_0$-plane is defined by the c0 parameter.

    Parameters:

    • float[] intensityDistribution: Luminous intensity distribution. At least two values are required for 1D mapping.
    • vec3f c0: Orientation of the $C_0$-(half)plane (required for asymmetric 2D distributions).

    Note: When using intensityDistribution, intensityQuantity must be set to OSP_INTENSITY_QUANTITY_SCALE.

    // Conceptual setup for a photometric light
OSPLight light = ospNewLight("spot");
// Set intensityQuantity to OSP_INTENSITY_QUANTITY_SCALE
// Provide intensityDistribution array...

  9. OSPRay ISPCDevice Specific Design Choices

    devel

    When working with ISPCDevice specific implementations:

    • Bindings: Prefer using Embree C API bindings over ISPC where possible.
    • Error Handling: Prefer throwing exceptions when an object is found to be invalid during the commit() phase.
    • Batch Updates: Prefer setting ISPC-side values in a single set() call rather than using multiple individual setter functions.
    • Complexity: Minimize the number of alias names provided for both object types and parameters.

  10. Use Groups to organize scene objects

    devel

    Groups represent collections of OSPGeometricModels, OSPVolumetricModels, and OSPLights that share a common local-space coordinate system.

    Clipping Geometry

    By adding models to the clippingGeometry array, you enable a clipping feature. Any supported geometry can be used for clipping as long as it partitions space into clipping and non-clipping regions.

    • All geometries and volumes assigned to geometry or volume will be clipped.
    • Clipping geometries from all groups and instances are combined (a union) and applied to all other objects in the world.
    • To change which part of space is clipped, use the invertNormals flag on the OSPGeometricModel.

    Group Parameters

    TypeNameDefaultDescription
    OSPGeometricModel[]geometryNULLArray of geometric models
    OSPVolumetricModel[]volumeNULLArray of volumetric models
    OSPGeometricModel[]clippingGeometryNULLArray of geometric models used for clipping
    OSPLight[]lightNULLArray of lights
    booldynamicScenefalseUse faster BVH build (slower traversal) or optimized for traversal (slower build)
    boolcompactModefalseUse a more compact BVH in memory at the cost of traversal performance
    boolrobustModefalseEnable more robust ray intersection code paths (slightly slower)
    OSPGroup group = ospNewGroup();

  11. How to extend OSPRay with a new geometry type

    devel

    OSPRay uses a 'Module Concept' that allows developers to dynamically load new functionality, such as new geometry types, renderers, camera types, or volume types.

    To implement a new geometry type via a pluggable module, you must follow these requirements:

    1. Library Naming: For OSPRay to discover a module named myModuleName, the build system must produce a library named libospray_module_myModuleName.so (or the platform equivalent).
    2. Geometry Registration: To define a new geometry type named MyGeometry, you must use the OSPRAY_REGISTER_GEOMETRY(ImplementationName, MyGeometry) macro within one of your C++ files.
    3. Data Access: You can use the commit() method of the geometry to query data that the user has added to it.
    4. Implementation: The example module demonstrates using embree and ispc to implement the intersect() and postIntersect() functions for a bilinear patch geometry.

  12. Understand Curve Bases and Types

    devel

    Curve Bases

    • OSP_LINEAR: Indices point to 2 consecutive control points. The curve goes through all control points.
    • OSP_BEZIER: Indices point to 4 consecutive control points. The curve interpolates between the 1st and 4th points.
    • OSP_BSPLINE: Indices point to 4 consecutive control points. Non-interpolating; allows sharing 3 control points between segments for C1 continuity.
    • OSP_HERMITE: Requires both vertex and tangent buffers. Indices point to 2 consecutive points and 2 consecutive tangents. Interpolating.
    • OSP_CATMULL_ROM: Indices point to 4 consecutive control points. The curve goes through the middle two points ($p1, p2$).

    Curve Types

    • OSP_FLAT: Fast rendering as a sequence of ray-facing quads.
    • OSP_ROUND: Renders a real geometric sweep surface (useful for closeups).
    • OSP_RIBBON: Renders a flat band; requires a normal buffer. Not supported for OSP_LINEAR.
    • OSP_DISJOINT: Only for OSP_LINEAR. Segments are individual cones or cylinders and not connected at joints.