miff

package: GraphicsMagick

title: miff(4)

text:
# miff(4)

## NAME
MIFF - Magick Image File Format

## SYNOPSIS
\#include <image.h>

## DESCRIPTION
The Magick Image File Format (MIFF) is a platform-independent format for storing bitmap images. MIFF is a part of the ImageMagick toolkit of image manipulation utilities for the X Window System. ImageMagick is capable of converting many different image file formats to and from MIFF (e.g. JPEG, XPM, TIFF, etc.).

A MIFF image file consist of two sections. The first section is a header composed of keys describing the image in text form. The next section is the binary image data. The header is separated from the image data by a : character immediately followed by a newline.

The MIFF header is composed entirely of LATIN-1 characters. The fields in the header are key and value combination in the key=value format, with each key and value separated by an equal sign (=). Each key=value combination is delimited by at least one control or whitespace character. Comments may appear in the header section and are always delimited by braces. The MIFF header always ends with a colon (:) character, followed by a ctrl-Z character. It is also common to proceed the colon with a formfeed and a newline character. The formfeed prevents the listing of binary data when using more(1) under Unix where the ctrl-Z has the same effect with the type command on the Win32 command line.

The following is a list of key=value combinations that may be found in a MIFF file:

background-color=color

border-color=color matte-color=color these optional keys reflects the image background, border, and matte colors respectively. A color can be a name (e.g. white) or a hex value (e.g. #ccc).

class=DirectClass

class=PseudoClass the type of binary image data stored in the MIFF file. If this key is not present, DirectClass image data is assumed.

colors=value

the number of colors in a DirectClass image. For a PseudoClass image, this key specifies the size of the colormap. If this key is not present in the header, and the image is PseudoClass, a linear 256 color grayscale colormap is used with the image data. The maximum number of colormap entries is 65535. colorspace=CMYK the colorspace of the pixel data. The default is RGB.

columns=value

the width of the image in pixels. This is a required key and has no default.

compression=BZip

compression=Fax compression=JPEG compression=LZW compression=RLE compression=Zip the type of algorithm used to compress the image data. If this key is not present, the image data is assumed to be uncompressed.

delay <1/100ths of a second>

the interframe delay in an image sequence. The maximum delay is 65535.

depth=8

depth=16 the depth of a single color value representing values from 0 to 255 (depth 8) or 65535 (depth 16). If this key is absent, a depth of 8 is assumed.

dispose value

GIF disposal method. Here are the valid methods:

```
     0  No disposal specified.

     1  Do not dispose between frames.

     2  Overwrite frame with background color from header.

     3  Overwrite with previous frame.
```

gamma=value

the gamma of the image. If it is not specified, a gamma of 1.0 (linear brightness response) is assumed,

id=ImageMagick

identifies the file as a MIFF-format image file. This key is required and has no default. Although this key can appear anywhere in the header, it should start as the first key of the header in column 1. This will allow programs like file(1) to easily identify the file as MIFF.

iterations value

the number of times an image sequence loops before stopping.

label={value}

defines a short title or caption for the image. If any whitespace appears in the label, it must be enclosed within braces.

matte=True

matte=False specifies whether a DirectClass image has matte data. Matte data is generally useful for image compositing. This key has no meaning for pseudo-color images.

montage=<width>x<height>{+-}<x offset>{+-}<y offset>

size and location of the individual tiles of a composite image. See X(1) for details about the geometry specification. Use this key when the image is a composite of a number of different tiles. A tile consists of an image and optionally a border and a label. <width> is the size in pixels of each individual tile in the horizontal direction and <height> is the size in the vertical direction. Each tile must have an equal number of pixels in width and equal in height. However, the width can differ from the height. <x offset> is the offset in number of pixels from the vertical edge of the composite image where the first tile of a row begins and <y offset> is the offset from the horizontal edge where the first tile of a column begins.

If this key is specified, a directory of tile names must follow the image header. The format of the directory is explained below.

page=value

preferred size and location of an image canvas.

profile-icc=value

the number of bytes in the International Color Consortium color profile. The profile is defined by the ICC profile specification located at ftp://sgigate.sgi.com/pub/icc/icc34.ps.

colorspace=RGB

red-primary=x,y

green-primary=x,y blue-primary=x,y white-point=x,y this optional key reflects the chromaticity primaries and white point.

rendering-intent=saturation

rendering-intent=perceptual rendering-intent=absolute rendering-intent=relative Rendering intent is the CSS-1 property that has been defined by the International Color Consortium (http://www.color.org).

resolution=<x-resolution>x<y-resolution>

vertical and horizontal resolution of the image. See units for the specific resolution units (e.g. pixels per inch).

rows=value

the height of the image in pixels. This is a required key and has no default.

scene=value

the sequence number for this MIFF image file. This optional key is used when a MIFF image file is one in a sequence of files used in an animation.

signature=value

this optional key contains a string that uniquely identifies the image pixel contents. NIST's SHA-256 message digest algorithm is recommended.

units=pixels-per-inch

units=pixels-per-centimeter image resolution units. Other key value pairs are permitted. If a value contains whitespace it must be enclosed with braces as illustrated here:

id=ImageMagick

class=PseudoClass colors=256

compression=RunlengthEncoded packets=27601

columns=1280 rows=1024

signature=d79e1c308aa5bbcdeea8ed63df412da9

copyright={Copyright (c) 2001 ImageMagick Studio}

<FF>

:

Note that key=value combinations may be separated by newlines or spaces and may occur in any order within the header. Comments (within braces) may appear anywhere before the colon.

If you specify the montage key in the header, follow the header with a directory of image tiles. This directory consists of a name for each tile of the composite image separated by a newline character. The list is terminated with a NULL character.

If you specify the color-profile key in the header, follow the header (or montage directory if the montage key is in the header) with the binary color profile.

Next comes the binary image data itself. How the image data is formatted depends upon the class of the image as specified (or not specified) by the value of the class key in the header.

DirectClass images (class=DirectClass) are continuous-tone, images stored as RGB (red, green, blue), RGBA (red, green, blue, alpha), or CMYK (cyan, yellow, magenta, black) intensity values as defined by the colorspace key. Each intensity value is one byte in length for images of depth 8 (0..255), whereas, images of depth 16 (0..65535) require two bytes in most significant byte first order.

PseudoClass images (class=PseudoClass) are colormapped RGB images. The colormap is stored as a series of red, green, and blue pixel values, each value being a byte in size. If the image depth is 16, each colormap entry consumes two bytes with the most significant byte being first. The number of colormap entries is defined by the colors key. The colormap data occurs immediately following the header (or image directory if the montage key is in the header). PseudoClass image data is an array of index values into the color map. If there are 256 or fewer colors in the image, each byte of image data contains an index value. If the image contains more than 256 colors or the image depth is 16, the index value is stored as two contiguous bytes with the most significant byte being first. If matte is true, each colormap index is followed by a 1 or 2-byte alpha value.

The image data in a MIFF file may be uncompressed, runlength encoded, Zip compressed, or BZip compressed. The compression key in the header defines how the image data is compressed. Uncompressed pixels are just stored one scanline at a time in row order. Runlength encoded compression counts runs of identical adjacent pixels and stores the pixels followed by a length byte (the number of identical pixels minus 1). Zip and BZip compression compresses each row of an image and precedes the compressed row with the length of compressed pixel bytes as a word in most significant byte first order.

MIFF files may contain more than one image. Simply concatenate each individual image (composed of a header and image data) into one file.

## SEE ALSO
display(1), animate(1), import(1), montage(1), mogrify(1), convert(1), more(1), compress(1)

## COPYRIGHT
Copyright (C) 2000 ImageMagick Studio, a non-profit organization dedicated to making software imaging solutions freely available.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files ("ImageMagick"), to deal in ImageMagick without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of ImageMagick, and to permit persons to whom the ImageMagick is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of ImageMagick.

The software is provided "as is", without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and noninfringement. In no event shall ImageMagick Studio be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with ImageMagick or the use or other dealings in ImageMagick.

Except as contained in this notice, the name of the ImageMagick Studio shall not be used in advertising or otherwise to promote the sale, use or other dealings in ImageMagick without prior written authorization from the ImageMagick Studio.

## AUTHORS
John Cristy, ImageMagick Studio


RTCBufferType

package: embree-devel

title: RTCBufferType(4embree4)

text:
# RTCBufferType(4embree4)

### NAME

```
RTCFormat - specifies format of data in buffers

```

### SYNOPSIS

```
#include <embree4/rtcore_ray.h>
enum RTCBufferType
{

  RTC_BUFFER_TYPE_INDEX            = 0,

  RTC_BUFFER_TYPE_VERTEX           = 1,

  RTC_BUFFER_TYPE_VERTEX_ATTRIBUTE = 2,

  RTC_BUFFER_TYPE_NORMAL           = 3,

  RTC_BUFFER_TYPE_TANGENT          = 4,

  RTC_BUFFER_TYPE_NORMAL_DERIVATIVE = 5,

  RTC_BUFFER_TYPE_GRID                 = 8,

  RTC_BUFFER_TYPE_FACE                 = 16,

  RTC_BUFFER_TYPE_LEVEL                = 17,

  RTC_BUFFER_TYPE_EDGE_CREASE_INDEX    = 18,

  RTC_BUFFER_TYPE_EDGE_CREASE_WEIGHT   = 19,

  RTC_BUFFER_TYPE_VERTEX_CREASE_INDEX  = 20,

  RTC_BUFFER_TYPE_VERTEX_CREASE_WEIGHT = 21,

  RTC_BUFFER_TYPE_HOLE                 = 22,

  RTC_BUFFER_TYPE_TRANSFORM            = 23,

  RTC_BUFFER_TYPE_FLAGS = 32
};

```

### DESCRIPTION
The RTBufferType structure defines slots to assign data buffers to using the [rtcSetGeometryBuffer], [rtcSetSharedGeometryBuffer], and [rtcSetNewGeometryBuffer] API calls.

For most geometry types the RTC_BUFFER_TYPE_INDEX slot is used to assign an index buffer, while the RTC_BUFFER_TYPE_VERTEX is used to assign the corresponding vertex buffer.

The RTC_BUFFER_TYPE_VERTEX_ATTRIBUTE slot can get used to assign arbitrary additional vertex data which can get interpolated using the [rtcInterpolate] API call.

The RTC_BUFFER_TYPE_NORMAL, RTC_BUFFER_TYPE_TANGENT, and RTC_BUFFER_TYPE_NORMAL_DERIVATIVE are special buffers required to assign per vertex normals, tangents, and normal derivatives for some curve types.

The RTC_BUFFER_TYPE_GRID buffer is used to assign the grid primitive buffer for grid geometries (see [RTC_GEOMETRY_TYPE_GRID]).

The RTC_BUFFER_TYPE_FACE, RTC_BUFFER_TYPE_LEVEL, RTC_BUFFER_TYPE_EDGE_CREASE_INDEX, RTC_BUFFER_TYPE_EDGE_CREASE_WEIGHT, RTC_BUFFER_TYPE_VERTEX_CREASE_INDEX, RTC_BUFFER_TYPE_VERTEX_CREASE_WEIGHT, and RTC_BUFFER_TYPE_HOLE are special buffers required to create subdivision meshes (see [RTC_GEOMETRY_TYPE_SUBDIVISION]).

The RTC_BUFFER_TYPE_TRANSFORM buffer is used to provide instance transformation information for instance array geometries (see [RTC_GEOMETRY_TYPE_INSTANCE_ARRAY]).

The RTC_BUFFER_TYPE_FLAGS can get used to add additional flag per primitive of a geometry, and is currently only used for linear curves.

### SEE ALSO
[rtcSetGeometryBuffer], [rtcSetSharedGeometryBuffer], [rtcSetNewGeometryBuffer]


RTCCurveFlags

title: RTCCurveFlags(4embree4)

text:
# RTCCurveFlags(4embree4)

### NAME

```
RTCCurveFlags - per segment flags for curve geometry

```

### SYNOPSIS

```
#include <embree4/rtcore.h>
enum RTCCurveFlags
{

  RTC_CURVE_FLAG_NEIGHBOR_LEFT  = (1 << 0),

  RTC_CURVE_FLAG_NEIGHBOR_RIGHT = (1 << 1)
};

```

### DESCRIPTION
The RTCCurveFlags type is used for linear curves to determine if the left and/or right neighbor segment exist. Therefore one attaches a buffer of type RTC_BUFFER_TYPE_FLAGS to the curve geometry which stores an individual byte per curve segment.

If the RTC_CURVE_FLAG_NEIGHBOR_LEFT flag in that byte is enabled for a curve segment, then the left segment exists (which starts one vertex before the start vertex of the current curve) and the current segment is rendered to properly attach to that segment.

If the RTC_CURVE_FLAG_NEIGHBOR_RIGHT flag in that byte is enabled for a curve segment, then the right segment exists (which ends one vertex after the end vertex of the current curve) and the current segment is rendered to properly attach to that segment.

When not properly specifying left and right flags for linear curves, the rendering at the ending of these curves may not look correct, in particular when round linear curves are viewed from the inside.

### SEE ALSO
[RTC_GEOMETRY_TYPE_CURVE]


RTCFeatureFlags

title: RTCFeatureFlags(4embree4)

text:
# RTCFeatureFlags(4embree4)

### NAME

```
RTCFeatureFlags - specifies features to enable

  for ray queries

```

### SYNOPSIS

```
#include <embree4/rtcore_ray.h>
enum RTCFeatureFlags
{

  RTC_FEATURE_FLAG_NONE = 0,

  RTC_FEATURE_FLAG_MOTION_BLUR = 1 << 0,

  RTC_FEATURE_FLAG_TRIANGLE = 1 << 1,

  RTC_FEATURE_FLAG_QUAD = 1 << 2,

  RTC_FEATURE_FLAG_GRID = 1 << 3,

  RTC_FEATURE_FLAG_SUBDIVISION = 1 << 4,

  RTC_FEATURE_FLAG_POINT = ... ,

  RTC_FEATURE_FLAG_CURVES = ... ,

  RTC_FEATURE_FLAG_CONE_LINEAR_CURVE = 1 << 5,

  RTC_FEATURE_FLAG_ROUND_LINEAR_CURVE  = 1 << 6,

  RTC_FEATURE_FLAG_FLAT_LINEAR_CURVE = 1 << 7,

  RTC_FEATURE_FLAG_ROUND_BEZIER_CURVE = 1 << 8,

  RTC_FEATURE_FLAG_FLAT_BEZIER_CURVE = 1 << 9,

  RTC_FEATURE_FLAG_NORMAL_ORIENTED_BEZIER_CURVE = 1 << 10,

  RTC_FEATURE_FLAG_ROUND_BSPLINE_CURVE = 1 << 11,

  RTC_FEATURE_FLAG_FLAT_BSPLINE_CURVE = 1 << 12,

  RTC_FEATURE_FLAG_NORMAL_ORIENTED_BSPLINE_CURVE = 1 << 13,

  RTC_FEATURE_FLAG_ROUND_HERMITE_CURVE = 1 << 14,

  RTC_FEATURE_FLAG_FLAT_HERMITE_CURVE = 1 << 15,

  RTC_FEATURE_FLAG_NORMAL_ORIENTED_HERMITE_CURVE = 1 << 16,

  RTC_FEATURE_FLAG_ROUND_CATMULL_ROM_CURVE = 1 << 17,

  RTC_FEATURE_FLAG_FLAT_CATMULL_ROM_CURVE = 1 << 18,

  RTC_FEATURE_FLAG_NORMAL_ORIENTED_CATMULL_ROM_CURVE = 1 << 19,

  RTC_FEATURE_FLAG_SPHERE_POINT = 1 << 20,

  RTC_FEATURE_FLAG_DISC_POINT = 1 << 21,

  RTC_FEATURE_FLAG_ORIENTED_DISC_POINT = 1 << 22,

  RTC_FEATURE_FLAG_ROUND_CURVES = ... ,

  RTC_FEATURE_FLAG_FLAT_CURVES = ... ,

  RTC_FEATURE_FLAG_NORMAL_ORIENTED_CURVES = ... ,

  RTC_FEATURE_FLAG_LINEAR_CURVES = ... ,

  RTC_FEATURE_FLAG_BEZIER_CURVES = ... ,

  RTC_FEATURE_FLAG_BSPLINE_CURVES = ... ,

  RTC_FEATURE_FLAG_HERMITE_CURVES = ... ,

  RTC_FEATURE_FLAG_INSTANCE = 1 << 23,

  RTC_FEATURE_FLAG_FILTER_FUNCTION_IN_ARGUMENTS = 1 << 24,

  RTC_FEATURE_FLAG_FILTER_FUNCTION_IN_GEOMETRY = 1 << 25,

  RTC_FEATURE_FLAG_FILTER_FUNCTION = ... ,

  RTC_FEATURE_FLAG_USER_GEOMETRY_CALLBACK_IN_ARGUMENTS = 1 << 26,

  RTC_FEATURE_FLAG_USER_GEOMETRY_CALLBACK_IN_GEOMETRY = 1 << 27,

  RTC_FEATURE_FLAG_USER_GEOMETRY = ... ,

  RTC_FEATURE_FLAG_32_BIT_RAY_MASK = 1 << 28,

  RTC_FEATURE_FLAG_ALL = 0xffffffff
};

```

### DESCRIPTION
The RTCFeatureFlags enum specify a bit mask to enable specific ray tracing features for ray query operations. The feature flags are passed to the rtcIntersect1/4/8/16 and rtcOccluded1/4/8/16 functions through the RTCIntersectArguments and RTCOccludedArguments structures. Only a ray tracing feature whose bit is enabled in the feature mask can get used. If a feature bit is not set, the behaviour is undefined, thus the feature may work or not. To enable multiple features the respective features have to get combined using a bitwise OR operation.

The purpose of feature flags is to reduce code size on the GPU by enabling just the features required to render the scene. On the CPU there is no need to use feature flags, and the default of all features enabled (RTC_FEATURE_FLAG_ALL) can just be kept.

The following features can get enabled using feature flags:

•

RTC_FEATURE_FLAG_MOTION_BLUR: Enables motion blur for all geometry types.

•

RTC_FEATURE_FLAG_TRIANGLE: Enables triangle geometries (RTC_GEOMETRY_TYPE_TRIANGLE).

•

RTC_FEATURE_FLAG_QUAD: Enables quad geometries (RTC_GEOMETRY_TYPE_QUAD).

•

RTC_FEATURE_FLAG_GRID: Enables grid geometries (RTC_GEOMETRY_TYPE_GRID).

•

RTC_FEATURE_FLAG_SUBDIVISION: Enables subdivision geometries (RTC_GEOMETRY_TYPE_SUBDIVISION).

•

RTC_FEATURE_FLAG_POINT: Enables all point geometry types (RTC_GEOMETRY_TYPE_XXX_POINT)

•

RTC_FEATURE_FLAG_CURVES: Enables all curve geometry types (RTC_GEOMETRY_TYPE_XXX_YYY_CURVE)

•

RTC_FEATURE_FLAG_ROUND_CURVES: Enables all round curves (RTC_GEOMETRY_TYPE_ROUND_XXX_CURVE).

•

RTC_FEATURE_FLAG_FLAT_CURVES: Enables all flat curves (RTC_GEOMETRY_TYPE_FLAT_XXX_CURVE).

•

RTC_FEATURE_FLAG_NORMAL_ORIENTED_CURVES: Enables all normal oriented curves (RTC_GEOMETRY_TYPE_NORMAL_ORIENTED_XXX_CURVE).

•

RTC_FEATURE_FLAG_LINEAR_CURVES: Enables all linear curves (RTC_GEOMETRY_TYPE_XXX_LINEAR_CURVE).

•

RTC_FEATURE_FLAG_BEZIER_CURVES: Enables all Bézier curves (RTC_GEOMETRY_TYPE_XXX_BEZIER_CURVE).

•

RTC_FEATURE_FLAG_BSPLINE_CURVES: Enables all B-spline curves (RTC_GEOMETRY_TYPE_XXX_BSPLINE_CURVE).

•

RTC_FEATURE_FLAG_HERMITE_CURVES: Enables all Hermite curves (RTC_GEOMETRY_TYPE_XXX_HERMITE_CURVE).

•

RTC_FEATURE_FLAG_CONE_LINEAR_CURVE: Enables cone geometry type (RTC_GEOMETRY_TYPE_CONE_LINEAR_CURVE).

•

RTC_FEATURE_FLAG_ROUND_LINEAR_CURVE: Enables round linear curves (RTC_GEOMETRY_TYPE_ROUND_LINEAR_CURVE).

•

RTC_FEATURE_FLAG_FLAT_LINEAR_CURVE: Enables flat linear curves (RTC_GEOMETRY_TYPE_FLAT_LINEAR_CURVE).

•

RTC_FEATURE_FLAG_ROUND_BEZIER_CURVE: Enables round Bézier curves (RTC_GEOMETRY_TYPE_ROUND_BEZIER_CURVE).

•

RTC_FEATURE_FLAG_FLAT_BEZIER_CURVE: Enables flat Bézier curves (RTC_GEOMETRY_TYPE_FLAT_BEZIER_CURVE).

•

RTC_FEATURE_FLAG_NORMAL_ORIENTED_BEZIER_CURVE: Enables normal oriented Bézier curves (RTC_GEOMETRY_TYPE_NORMAL_ORIENTED_BEZIER_CURVE).

•

RTC_FEATURE_FLAG_ROUND_BSPLINE_CURVE: Enables round B-spline curves (RTC_GEOMETRY_TYPE_ROUND_BSPLINE_CURVE).

•

RTC_FEATURE_FLAG_FLAT_BSPLINE_CURVE: Enables flat B-spline curves (RTC_GEOMETRY_TYPE_FLAT_BSPLINE_CURVE).

•

RTC_FEATURE_FLAG_NORMAL_ORIENTED_BSPLINE_CURVE: Enables normal oriented B-spline curves (RTC_GEOMETRY_TYPE_NORMAL_ORIENTED_BSPLINE_CURVE).

•

RTC_FEATURE_FLAG_ROUND_HERMITE_CURVE: Enables round Hermite curves (RTC_GEOMETRY_TYPE_ROUND_HERMITE_CURVE).

•

RTC_FEATURE_FLAG_FLAT_HERMITE_CURVE: Enables flat Hermite curves (RTC_GEOMETRY_TYPE_FLAT_HERMITE_CURVE).

•

RTC_FEATURE_FLAG_NORMAL_ORIENTED_HERMITE_CURVE: Enables normal oriented Hermite curves (RTC_GEOMETRY_TYPE_NORMAL_ORIENTED_HERMITE_CURVE).

•

RTC_FEATURE_FLAG_ROUND_CATMULL_ROM_CURVE: Enables round Catmull Rom curves (RTC_GEOMETRY_TYPE_ROUND_CATMULL_ROM_CURVE).

•

RTC_FEATURE_FLAG_FLAT_CATMULL_ROM_CURVE: Enables flat Catmull Rom curves (RTC_GEOMETRY_TYPE_FLAT_CATMULL_ROM_CURVE).

•

RTC_FEATURE_FLAG_NORMAL_ORIENTED_CATMULL_ROM_CURVE: Enables normal oriented Catmull Rom curves (RTC_GEOMETRY_TYPE_NORMAL_ORIENTED_CATMULL_ROM_CURVE).

•

RTC_FEATURE_FLAG_SPHERE_POINT: Enables sphere geometry type (RTC_GEOMETRY_TYPE_SPHERE_POINT).

•

RTC_FEATURE_FLAG_DISC_POINT: Enables disc geometry type (RTC_GEOMETRY_TYPE_DISC_POINT).

•

RTC_FEATURE_FLAG_ORIENTED_DISC_POINT: Enables oriented disc geometry types (RTC_GEOMETRY_TYPE_ORIENTED_DISC_POINT).

•

RTC_FEATURE_FLAG_INSTANCE: Enables instance geometries (RTC_GEOMETRY_TYPE_INSTANCE).

•

RTC_FEATURE_FLAG_FILTER_FUNCTION_IN_ARGUMENTS: Enables filter functions passed through intersect arguments.

•

RTC_FEATURE_FLAG_FILTER_FUNCTION_IN_GEOMETRY: Enable filter functions passed through geometry.

•

RTC_FEATURE_FLAG_FILTER_FUNCTION: Enables filter functions (argument and geometry version).

•

RTC_FEATURE_FLAG_USER_GEOMETRY_CALLBACK_IN_ARGUMENTS: Enables RTC_GEOMETRY_TYPE_USER with function pointer passed through intersect arguments.

•

RTC_FEATURE_FLAG_USER_GEOMETRY_CALLBACK_IN_GEOMETRY: Enables RTC_GEOMETRY_TYPE_USER with function pointer passed through geometry object.

•

RTC_FEATURE_FLAG_USER_GEOMETRY: Enables RTC_GEOMETRY_TYPE_USER geometries (both argument and geometry callback versions).

•

RTC_FEATURE_FLAG_32_BIT_RAY_MASK: Enables full 32 bit ray masks. If not used, only the lower 7 bits in the ray mask are handled correctly.

•

RTC_FEATURE_FLAG_ALL: Enables all features (default).

### SEE ALSO
[rtcIntersect1], [rtcIntersect4/8/16], [rtcOccluded1], [rtcOccluded4/8/16],


RTCFormat

title: RTCFormat(4embree4)

text:
# RTCFormat(4embree4)

### NAME

```
RTCFormat - specifies format of data in buffers

```

### SYNOPSIS

```
#include <embree4/rtcore_ray.h>
enum RTCFormat
{

  RTC_FORMAT_UINT,

  RTC_FORMAT_UINT2,

  RTC_FORMAT_UINT3,

  RTC_FORMAT_UINT4,

  RTC_FORMAT_FLOAT,

  RTC_FORMAT_FLOAT2,

  RTC_FORMAT_FLOAT3,

  RTC_FORMAT_FLOAT4,

  RTC_FORMAT_FLOAT5,

  RTC_FORMAT_FLOAT6,

  RTC_FORMAT_FLOAT7,

  RTC_FORMAT_FLOAT8,

  RTC_FORMAT_FLOAT9,

  RTC_FORMAT_FLOAT10,

  RTC_FORMAT_FLOAT11,

  RTC_FORMAT_FLOAT12,

  RTC_FORMAT_FLOAT13,

  RTC_FORMAT_FLOAT14,

  RTC_FORMAT_FLOAT15,

  RTC_FORMAT_FLOAT16,

  RTC_FORMAT_FLOAT3X4_ROW_MAJOR,

  RTC_FORMAT_FLOAT4X4_ROW_MAJOR,

  RTC_FORMAT_FLOAT3X4_COLUMN_MAJOR,

  RTC_FORMAT_FLOAT4X4_COLUMN_MAJOR,

  RTC_FORMAT_GRID,

  RTC_FORMAT_QUATERNION_DECOMPOSITION
};

```

### DESCRIPTION
The RTFormat structure defines the data format stored in data buffers provided to Embree using the [rtcSetGeometryBuffer], [rtcSetSharedGeometryBuffer], and [rtcSetNewGeometryBuffer] API calls.

The RTC_FORMAT_UINT/2/3/4 format are used to specify that data buffers store unsigned integers, or unsigned integer vectors of size 2,3 or 4. This format has typically to get used when specifying index buffers, e.g. RTC_FORMAT_UINT3 for triangle meshes.

The RTC_FORMAT_FLOAT/2/3/4... format are used to specify that data buffers store single precision floating point values, or vectors there of (size 2,3,4, etc.). This format is typcally used to specify to format of vertex buffers, e.g. the RTC_FORMAT_FLOAT3 type for vertex buffers of triangle meshes.

The RTC_FORMAT_FLOAT3X4_ROW_MAJOR and RTC_FORMAT_FLOAT3X4_COLUMN_MAJOR formats, specify a 3x4 floating point matrix layed out either row major or column major. The RTC_FORMAT_FLOAT4X4_ROW_MAJOR and RTC_FORMAT_FLOAT4X4_COLUMN_MAJOR formats, specify a 4x4 floating point matrix layed out either row major or column major. The RTC_FORMAT_QUATERNION_DECOMPOSITION format specifies a structure that represents a quaternion decomposition (see [RTCQuaternionDecomposition]) of an affine transformation. These formats are used in the [rtcSetGeometryTransform] function or in geometry buffers with type RTC_BUFFER_TYPE_TRANSFORM in order to set a transformation matrix for instance and instance array geometries.

The RTC_FORMAT_GRID is a special data format used to specify grid primitives of layout RTCGrid when creating grid geometries (see [RTC_GEOMETRY_TYPE_GRID]).

### SEE ALSO
[rtcSetGeometryBuffer], [rtcSetSharedGeometryBuffer], [rtcSetNewGeometryBuffer], [rtcSetGeometryTransform] [RTCQuaternionDecomposition]


RTCHit

title: RTCHit(4embree4)

text:
# RTCHit(4embree4)

### NAME

```
RTCHit - single hit structure

```

### SYNOPSIS

```
#include <embree4/rtcore.h>
struct RTCHit
{

  float Ng_x;                                        // x coordinate of geometry normal

  float Ng_y;                                        // y coordinate of geometry normal

  float Ng_z;                                        // z coordinate of geometry normal

  float u;                                           // barycentric u coordinate of hit

  float v;                                           // barycentric v coordinate of hit

  unsigned int primID;                               // geometry ID

  unsigned int geomID;                               // primitive ID

  unsigned int instID[RTC_MAX_INSTANCE_LEVEL_COUNT]; // instance ID
};

```

### DESCRIPTION
The RTCHit type defines the type of a ray/primitive intersection result. The hit contains the unnormalized geometric normal in object space at the hit location (Ng_x, Ng_y, Ng_z members), the barycentric u/v coordinates of the hit (u and v members), as well as the primitive ID (primID member), geometry ID (geomID member), and instance ID stack (instID member) of the hit. The parametric intersection distance is not stored inside the hit, but stored inside the tfar member of the ray.

The embree4/rtcore_ray.h header additionally defines the same hit structure in structure of array (SOA) layout for hit packets of size 4 (RTCHit4 type), size 8 (RTCHit8 type), and size 16 (RTCHit16 type). The header additionally defines an RTCHitNt template for hit packets of an arbitrary compile-time size.

### SEE ALSO
[RTCRay], [Multi-Level Instancing]


RTCHitN

title: RTCHitN(4embree4)

text:
# RTCHitN(4embree4)

### NAME

```
RTCHitN - hit packet of runtime size

```

### SYNOPSIS

```
#include <embree4/rtcore.h>
struct HitN;
float& RTCHitN_Ng_x(RTCHitN* hit, unsigned int N, unsigned int i);
float& RTCHitN_Ng_y(RTCHitN* hit, unsigned int N, unsigned int i);
float& RTCHitN_Ng_z(RTCHitN* hit, unsigned int N, unsigned int i);
float& RTCHitN_u(RTCHitN* hit, unsigned int N, unsigned int i);
float& RTCHitN_v(RTCHitN* hit, unsigned int N, unsigned int i);
unsigned& RTCHitN_primID(RTCHitN* hit, unsigned int N, unsigned int i);
unsigned& RTCHitN_geomID(RTCHitN* hit, unsigned int N, unsigned int i);
unsigned& RTCHitN_instID(RTCHitN* hit, unsigned int N, unsigned int i, unsigned int level);

```

### DESCRIPTION
When the hit packet size is not known at compile time (e.g. when Embree returns a hit packet in the RTCFilterFuncN callback function), Embree uses the RTCHitN type for hit packets. These hit packets can only have sizes of 1, 4, 8, or 16. No other packet size will be used.

You can either implement different special code paths for each of these possible packet sizes and cast the hit to the appropriate hit packet type, or implement one general code path that uses the RTCHitN_XXX helper functions to access hit packet components.

These helper functions get a pointer to the hit packet (hit argument), the packet size (N argument), and returns a reference to a component (e.g. x component of Ng) of the the i-th hit of the packet (i argument).

### SEE ALSO
[RTCRayN]


RTCQuaternionDecomposition

title: RTCQuaternionDecomposition(4embree4)

text:
# RTCQuaternionDecomposition(4embree4)

### NAME

```
RTCQuaternionDecomposition - structure that represents a quaternion

  decomposition of an affine transformation

```

### SYNOPSIS

```
struct RTCQuaternionDecomposition
{

  float scale_x, scale_y, scale_z;

  float skew_xy, skew_xz, skew_yz;

  float shift_x, shift_y, shift_z;

  float quaternion_r, quaternion_i, quaternion_j, quaternion_k;

  float translation_x, translation_y, translation_z;
};

```

### DESCRIPTION
The struct RTCQuaternionDecomposition represents an affine transformation decomposed into three parts. An upper triangular scaling/skew/shift matrix

$$ S = \left( \begin{array}{cccc} scale_x & skew_{xy} & skew_{xz} & shift_x \\ 0 & scale_y & skew_{yz} & shift_y \\ 0 & 0 & scale_z & shift_z \\ 0 & 0 & 0 & 1 \\ \end{array} \right), $$

a translation matrix

$$ T = \left( \begin{array}{cccc} 1 & 0 & 0 & translation_x \\ 0 & 1 & 0 & translation_y \\ 0 & 0 & 1 & translation_z \\ 0 & 0 & 0 & 1 \\ \end{array} \right), $$

and a rotation matrix R, represented as a quaternion

quaternion~r~ + quaternion~i~ i + quaternion~j~ i + quaternion~k~ k

where i, j k are the imaginary quaternion units. The passed quaternion will be normalized internally.

The affine transformation matrix corresponding to a RTCQuaternionDecomposition is TRS and a point p = (p~x~, p~y~, p~z~, 1)^T^ will be transformed as

p′ = T R S p.

The functions rtcInitQuaternionDecomposition, rtcQuaternionDecompositionSetQuaternion, rtcQuaternionDecompositionSetScale, rtcQuaternionDecompositionSetSkew, rtcQuaternionDecompositionSetShift, and rtcQuaternionDecompositionSetTranslation allow to set the fields of the structure more conveniently.

### EXIT STATUS
No error code is set by this function.

### SEE ALSO
[rtcSetGeometryTransformQuaternion], [rtcInitQuaternionDecomposition]


RTCRay

title: RTCRay(4embree4)

text:
# RTCRay(4embree4)

### NAME

```
RTCRay - single ray structure

```

### SYNOPSIS

```
#include <embree4/rtcore_ray.h>
struct RTC_ALIGN(16) RTCRay
{

  float org_x;        // x coordinate of ray origin

  float org_y;        // y coordinate of ray origin

  float org_z;        // z coordinate of ray origin

  float tnear;        // start of ray segment

  float dir_x;        // x coordinate of ray direction

  float dir_y;        // y coordinate of ray direction

  float dir_z;        // z coordinate of ray direction

  float time;         // time of this ray for motion blur

  float tfar;         // end of ray segment (set to hit distance)

  unsigned int mask;  // ray mask

  unsigned int id;    // ray ID

  unsigned int flags; // ray flags
};

```

### DESCRIPTION
The RTCRay structure defines the ray layout for a single ray. The ray contains the origin (org_x, org_y, org_z members), direction vector (dir_x, dir_y, dir_z members), and ray segment (tnear and tfar members). The ray direction does not have to be normalized, and only the parameter range specified by the tnear/tfar interval is considered valid.

The ray segment must be in the range [0, ∞], thus ranges that start behind the ray origin are not allowed, but ranges can reach to infinity.

The ray further contains a motion blur time in the range [0, 1] (time member), a ray mask (mask member), a ray ID (id member), and ray flags (flags member). The ray mask can be used to mask out some geometries for some rays (see rtcSetGeometryMask for more details). The ray ID can be used to identify a ray inside a callback function, even if the order of rays inside a ray packet has changed.

The embree4/rtcore_ray.h header additionally defines the same ray structure in structure of array (SOA) layout for API functions accepting ray packets of size 4 (RTCRay4 type), size 8 (RTCRay8 type), and size 16 (RTCRay16 type). The header additionally defines an RTCRayNt template for ray packets of an arbitrary compile-time size.

### SEE ALSO
[RTCHit]


RTCRayHit

title: RTCRayHit(4embree4)

text:
# RTCRayHit(4embree4)

### NAME

```
RTCRayHit - combined single ray/hit structure

```

### SYNOPSIS

```
#include <embree4/rtcore_ray.h>
struct RTCORE_ALIGN(16) RTCRayHit
{

  struct RTCRay ray;

  struct RTCHit hit;
};

```

### DESCRIPTION
The RTCRayHit structure is used as input for the rtcIntersect-type functions and stores the ray to intersect and some hit fields that hold the intersection result afterwards.

The embree4/rtcore_ray.h header additionally defines the same ray/hit structure in structure of array (SOA) layout for API functions accepting ray packets of size 4 (RTCRayHit4 type), size 8 (RTCRayHit8 type), and size 16 (RTCRayHit16 type). The header additionally defines an RTCRayHitNt template to generate ray/hit packets of an arbitrary compile-time size.

### SEE ALSO
[RTCRay], [RTCHit]


RTCRayHitN

title: RTCRayHitN(4embree4)

text:
# RTCRayHitN(4embree4)

### NAME

```
RTCRayHitN - combined ray/hit packet of runtime size

```

### SYNOPSIS

```
#include <embree4/rtcore_ray.h>
struct RTCRayHitN;
struct RTCRayN* RTCRayHitN_RayN(struct RTCRayHitN* rayhit, unsigned int N);
struct RTCHitN* RTCRayHitN_HitN(struct RTCRayHitN* rayhit, unsigned int N);

```

### DESCRIPTION
When the packet size of a ray/hit structure is not known at compile time (e.g. when Embree returns a ray/hit packet in the RTCIntersectFunctionN callback function), Embree uses the RTCRayHitN type for ray packets. These ray/hit packets can only have sizes of 1, 4, 8, or 16. No other packet size will be used.

You can either implement different special code paths for each of these possible packet sizes and cast the ray/hit to the appropriate ray/hit packet type, or extract the RTCRayN and RTCHitN components using the rtcGetRayN and rtcGetHitN helper functions and use the RTCRayN_XXX and RTCHitN_XXX functions to access the ray and hit parts of the structure.

### SEE ALSO
[RTCHitN]


RTCRayN

title: RTCRayN(4embree4)

text:
# RTCRayN(4embree4)

### NAME

```
RTCRayN - ray packet of runtime size

```

### SYNOPSIS

```
#include <embree4/rtcore_ray.h>
struct RTCRayN;
float& RTCRayN_org_x(RTCRayN* ray, unsigned int N, unsigned int i);
float& RTCRayN_org_y(RTCRayN* ray, unsigned int N, unsigned int i);
float& RTCRayN_org_z(RTCRayN* ray, unsigned int N, unsigned int i);
float& RTCRayN_tnear(RTCRayN* ray, unsigned int N, unsigned int i);
float& RTCRayN_dir_x(RTCRayN* ray, unsigned int N, unsigned int i);
float& RTCRayN_dir_y(RTCRayN* ray, unsigned int N, unsigned int i);
float& RTCRayN_dir_z(RTCRayN* ray, unsigned int N, unsigned int i);
float& RTCRayN_time (RTCRayN* ray, unsigned int N, unsigned int i);
float&        RTCRayN_tfar (RTCRayN* ray, unsigned int N, unsigned int i);
unsigned int& RTCRayN_mask (RTCRayN* ray, unsigned int N, unsigned int i);
unsigned int& RTCRayN_id   (RTCRayN* ray, unsigned int N, unsigned int i);
unsigned int& RTCRayN_flags(RTCRayN* ray, unsigned int N, unsigned int i);

```

### DESCRIPTION
When the ray packet size is not known at compile time (e.g. when Embree returns a ray packet in the RTCFilterFuncN callback function), Embree uses the RTCRayN type for ray packets. These ray packets can only have sizes of 1, 4, 8, or 16. No other packet size will be used.

You can either implement different special code paths for each of these possible packet sizes and cast the ray to the appropriate ray packet type, or implement one general code path that uses the RTCRayN_XXX helper functions to access the ray packet components.

These helper functions get a pointer to the ray packet (ray argument), the packet size (N argument), and returns a reference to a component (e.g. x-component of origin) of the the i-th ray of the packet (i argument).

### SEE ALSO
[RTCHitN]


title: RTC_GEOMETRY_TYPE_CURVE(4embree4)

text:
# RTC_GEOMETRY_TYPE_CURVE(4embree4)

### NAME

```
RTC_GEOMETRY_TYPE_FLAT_LINEAR_CURVE -

  flat curve geometry with linear basis
RTC_GEOMETRY_TYPE_FLAT_BEZIER_CURVE -

  flat curve geometry with cubic Bézier basis
RTC_GEOMETRY_TYPE_FLAT_BSPLINE_CURVE -

  flat curve geometry with cubic B-spline basis
RTC_GEOMETRY_TYPE_FLAT_HERMITE_CURVE -

  flat curve geometry with cubic Hermite basis
RTC_GEOMETRY_TYPE_FLAT_CATMULL_ROM_CURVE -

  flat curve geometry with Catmull-Rom basis
RTC_GEOMETRY_TYPE_NORMAL_ORIENTED_BEZIER_CURVE -

  flat normal oriented curve geometry with cubic Bézier basis
RTC_GEOMETRY_TYPE_NORMAL_ORIENTED_BSPLINE_CURVE -

  flat normal oriented curve geometry with cubic B-spline basis
RTC_GEOMETRY_TYPE_NORMAL_ORIENTED_HERMITE_CURVE -

  flat normal oriented curve geometry with cubic Hermite basis
RTC_GEOMETRY_TYPE_NORMAL_ORIENTED_CATMULL_ROM_CURVE -

  flat normal oriented curve geometry with Catmull-Rom basis
RTC_GEOMETRY_TYPE_CONE_LINEAR_CURVE -

  capped cone curve geometry with linear basis - discontinuous at edge boundaries
RTC_GEOMETRY_TYPE_ROUND_LINEAR_CURVE -

  capped cone curve geometry with linear basis and spherical ending
RTC_GEOMETRY_TYPE_ROUND_BEZIER_CURVE -

  swept surface curve geometry with cubic Bézier basis
RTC_GEOMETRY_TYPE_ROUND_BSPLINE_CURVE -

  swept surface curve geometry with cubic B-spline basis
RTC_GEOMETRY_TYPE_ROUND_HERMITE_CURVE -

  swept surface curve geometry with cubic Hermite basis
RTC_GEOMETRY_TYPE_ROUND_CATMULL_ROM_CURVE -

  swept surface curve geometry with Catmull-Rom basis

```

### SYNOPSIS

```
#include <embree4/rtcore.h>
rtcNewGeometry(device, RTC_GEOMETRY_TYPE_FLAT_LINEAR_CURVE);
rtcNewGeometry(device, RTC_GEOMETRY_TYPE_FLAT_BEZIER_CURVE);
rtcNewGeometry(device, RTC_GEOMETRY_TYPE_FLAT_BSPLINE_CURVE);
rtcNewGeometry(device, RTC_GEOMETRY_TYPE_FLAT_HERMITE_CURVE);
rtcNewGeometry(device, RTC_GEOMETRY_TYPE_FLAT_CATMULL_ROM_CURVE);
rtcNewGeometry(device, RTC_GEOMETRY_TYPE_NORMAL_ORIENTED_BEZIER_CURVE);
rtcNewGeometry(device, RTC_GEOMETRY_TYPE_NORMAL_ORIENTED_BSPLINE_CURVE);
rtcNewGeometry(device, RTC_GEOMETRY_TYPE_NORMAL_ORIENTED_HERMITE_CURVE);
rtcNewGeometry(device, RTC_GEOMETRY_TYPE_NORMAL_ORIENTED_CATMULL_ROM_CURVE);
rtcNewGeometry(device, RTC_GEOMETRY_TYPE_CONE_LINEAR_CURVE);
rtcNewGeometry(device, RTC_GEOMETRY_TYPE_ROUND_LINEAR_CURVE);
rtcNewGeometry(device, RTC_GEOMETRY_TYPE_ROUND_BEZIER_CURVE);
rtcNewGeometry(device, RTC_GEOMETRY_TYPE_ROUND_BSPLINE_CURVE);
rtcNewGeometry(device, RTC_GEOMETRY_TYPE_ROUND_HERMITE_CURVE);
rtcNewGeometry(device, RTC_GEOMETRY_TYPE_ROUND_CATMULL_ROM_CURVE);

```

### DESCRIPTION
Curves with per vertex radii are supported with linear, cubic Bézier, cubic B-spline, and cubic Hermite bases. Such curve geometries are created by passing RTC_GEOMETRY_TYPE_FLAT_LINEAR_CURVE, RTC_GEOMETRY_TYPE_FLAT_BEZIER_CURVE, RTC_GEOMETRY_TYPE_FLAT_BSPLINE_CURVE, RTC_GEOMETRY_TYPE_FLAT_HERMITE_CURVE, RTC_GEOMETRY_TYPE_FLAT_CATMULL_ROM_CURVE, RTC_GEOMETRY_TYPE_NORMAL_ORIENTED_FLAT_BEZIER_CURVE, RTC_GEOMETRY_TYPE_NORMAL_ORIENTED_FLAT_BSPLINE_CURVE, RTC_GEOMETRY_TYPE_NORMAL_ORIENTED_FLAT_HERMITE_CURVE, RTC_GEOMETRY_TYPE_NORMAL_ORIENTED_FLAT_CATMULL_ROM_CURVE, RTC_GEOMETRY_TYPE_CONE_LINEAR_CURVE, RTC_GEOMETRY_TYPE_ROUND_LINEAR_CURVE, RTC_GEOMETRY_TYPE_ROUND_BEZIER_CURVE, RTC_GEOMETRY_TYPE_ROUND_BSPLINE_CURVE, RTC_GEOMETRY_TYPE_ROUND_HERMITE_CURVE, or RTC_GEOMETRY_TYPE_ROUND_CATMULL_ROM_CURVE to the rtcNewGeometry function. The curve indices can be specified through an index buffer (RTC_BUFFER_TYPE_INDEX) and the curve vertices through a vertex buffer (RTC_BUFFER_TYPE_VERTEX). For the Hermite basis a tangent buffer (RTC_BUFFER_TYPE_TANGENT), normal oriented curves a normal buffer (RTC_BUFFER_TYPE_NORMAL), and for normal oriented Hermite curves a normal derivative buffer (RTC_BUFFER_TYPE_NORMAL_DERIVATIVE) has to get specified additionally. See rtcSetGeometryBuffer and rtcSetSharedGeometryBuffer for more details on how to set buffers.

The index buffer contains an array of 32-bit indices (RTC_FORMAT_UINT format), each pointing to the first control vertex in the vertex buffer, but also to the first tangent in the tangent buffer, and first normal in the normal buffer if these buffers are present.

The vertex buffer stores each control vertex in the form of a single precision position and radius stored in (x, y, z, r) order in memory (RTC_FORMAT_FLOAT4 format). The number of vertices is inferred from the size of this buffer. The radii may be smaller than zero but the interpolated radii should always be greater or equal to zero. Similarly, the tangent buffer stores the derivative of each control vertex (x, y, z, r order and RTC_FORMAT_FLOAT4 format) and the normal buffer stores a single precision normal per control vertex (x, y, z order and RTC_FORMAT_FLOAT3 format).

### Linear Basis
For the linear basis the indices point to the first of 2 consecutive control points in the vertex buffer. The first control point is the start and the second control point the end of the line segment. When constructing hair strands in this basis, the end-point can be shared with the start of the next line segment.

For the linear basis the user optionally can provide a flags buffer of type RTC_BUFFER_TYPE_FLAGS which contains bytes that encode if the left neighbor segment (RTC_CURVE_FLAG_NEIGHBOR_LEFT flag) and/or right neighbor segment (RTC_CURVE_FLAG_NEIGHBOR_RIGHT flags) exist (see [RTCCurveFlags]). If this buffer is not set, than the left/right neighbor bits are automatically calculated base on the index buffer (left segment exists if segment(id-1)+1 == segment(id) and right segment exists if segment(id+1)-1 == segment(id)).

A left neighbor segment is assumed to end at the start vertex of the current segment, and to start at the previous vertex in the vertex buffer. Similarly, the right neighbor segment is assumed to start at the end vertex of the current segment, and to end at the next vertex in the vertex buffer.

Only when the left and right bits are properly specified the current segment can properly attach to the left and/or right neighbor, otherwise the touching area may not get rendered properly.

### Bézier Basis
For the cubic Bézier basis the indices point to the first of 4 consecutive control points in the vertex buffer. These control points use the cubic Bézier basis, where the first control point represents the start point of the curve, and the 4th control point the end point of the curve. The Bézier basis is interpolating, thus the curve does go exactly through the first and fourth control vertex.

### B-spline Basis
For the cubic B-spline basis the indices point to the first of 4 consecutive control points in the vertex buffer. These control points make up a cardinal cubic B-spline (implicit equidistant knot vector). This basis is not interpolating, thus the curve does in general not go through any of the control points directly. A big advantage of this basis is that 3 control points can be shared for two continuous neighboring curve segments, e.g. the curves (p0,p1,p2,p3) and (p1,p2,p3,p4) are C1 continuous. This feature makes this basis a good choice to construct continuous multi-segment curves, as memory consumption can be kept minimal.

### Hermite Basis
For the cubic Hermite basis the indices point to the first of 2 consecutive points in the vertex buffer, and the first of 2 consecutive tangents in the tangent buffer. These two points and two tangents make up a cubic Hermite curve. This basis is interpolating, thus does exactly go through the first and second control point, and the first order derivative at the begin and end matches exactly the value specified in the tangent buffer. When connecting two segments continuously, the end point and tangent of the previous segment can be shared. Different versions of Catmull-Rom splines can be easily constructed using the Hermite basis, by calculating a proper tangent buffer from the control points.

### Catmull-Rom Basis
For the Catmull-Rom basis the indices point to the first of 4 consecutive control points in the vertex buffer. This basis goes through p1 and p2, with tangents (p2-p0)/2 and (p3-p1)/2.

### Flat Curves
The RTC_GEOMETRY_TYPE_FLAT_* flat mode is a fast mode designed to render distant hair. In this mode the curve is rendered as a connected sequence of ray facing quads. Individual quads are considered to have subpixel size, and zooming onto the curve might show geometric artifacts. The number of quads to subdivide into can be specified through the rtcSetGeometryTessellationRate function. By default the tessellation rate is 4.

### Normal Oriented Curves
The RTC_GEOMETRY_TYPE_NORMAL_ORIENTED_* mode is a mode designed to render blades of grass. In this mode a vertex spline has to get specified as for the previous modes, but additionally a normal spline is required. If the Hermite basis is used, the RTC_BUFFER_TYPE_NORMAL and RTC_BUFFER_TYPE_NORMAL_DERIVATIVE buffers have both to be set.

The curve is rendered as a flat band whose center approximately follows the provided vertex spline, whose half width approximately follows the provided radius spline, and whose normal orientation approximately follows the provided normal spline.

To intersect the normal oriented curve, we perform a newton-raphson style intersection of a ray with a tensor product surface of a linear basis (perpendicular to the curve) and cubic Bézier basis (along the curve). We use a guide curve and its derivatives to construct the control points of that surface. The guide curve is defined by a sweep surface defined by sweeping a line centered at the vertex spline location along the curve. At each parameter value the half width of the line matches the radius spline, and the direction matches the cross product of the normal from the normal spline and tangent of the vertex spline. Note that this construction does not work when the provided normals are parallel to the curve direction. For this reason the provided normals should best be kept as perpendicular to the curve direction as possible. We further assume second order derivatives of the center curve to be zero for this construction, as otherwise very large curvatures occurring in corner cases, can thicken the constructed curve significantly.

### Round Curves
In the RTC_GEOMETRY_TYPE_ROUND_* round mode, a real geometric surface is rendered for the curve, which is more expensive but allows closeup views.

For the linear basis the round mode renders a cone that tangentially touches a start-sphere and end-sphere. The start sphere is rendered when no previous segments is indicated by the neighbor bits. The end sphere is always rendered but parts that lie inside the next segment are clipped away (if that next segment exists). This way a curve is closed on both ends and the interior will render properly as long as only neighboring segments penetrate into a segment. For this to work properly it is important that the flags buffer is properly populated with neighbor information.

For the cubic polynomial bases, the round mode renders a sweep surface by sweeping a varying radius circle tangential along the curve. As a limitation, the radius of the curve has to be smaller than the curvature radius of the curve at each location on the curve.

The intersection with the curve segment stores the parametric hit location along the curve segment as u-coordinate (range 0 to +1).

For flat curves, the v-coordinate is set to the normalized distance in the range -1 to +1. For normal oriented curves the v-coordinate is in the range 0 to 1. For the linear basis and in round mode the v-coordinate is set to zero.

In flat mode, the geometry normal Ng is set to the tangent of the curve at the hit location. In round mode and for normal oriented curves, the geometry normal Ng is set to the non-normalized geometric normal of the surface.

For multi-segment motion blur, the number of time steps must be first specified using the rtcSetGeometryTimeStepCount call. Then a vertex buffer for each time step can be set using different buffer slots, and all these buffers must have the same stride and size. For the Hermite basis also a tangent buffer has to be set for each time step and for normal oriented curves a normal buffer has to get specified for each time step.

Also see tutorials [Hair] and [Curves] for examples of how to create and use curve geometries.

### EXIT STATUS
On failure NULL is returned and an error code is set that can be queried using rtcGetDeviceError.

### SEE ALSO
[rtcNewGeometry], [RTCCurveFlags]


title: RTC_GEOMETRY_TYPE_GRID(4embree4)

text:
# RTC_GEOMETRY_TYPE_GRID(4embree4)

### NAME

```
RTC_GEOMETRY_TYPE_GRID - grid geometry type

```

### SYNOPSIS

```
#include <embree4/rtcore.h>
RTCGeometry geometry =

  rtcNewGeometry(device, RTC_GEOMETRY_TYPE_GRID);

```

### DESCRIPTION
Grid meshes are created by passing RTC_GEOMETRY_TYPE_GRID to the rtcNewGeometry function call, and contain an array of grid primitives. This array of grids can be specified by setting up a grid buffer (with RTC_BUFFER_TYPE_GRID type and RTC_FORMAT_GRID format) and the grid mesh vertices by setting a vertex buffer (RTC_BUFFER_TYPE_VERTEX type). See rtcSetGeometryBuffer and rtcSetSharedGeometryBuffer for more details on how to set buffers. The number of grid primitives in the grid mesh is inferred from the size of the grid buffer.

The vertex buffer contains an array of single precision x, y, z floating point coordinates (RTC_FORMAT_FLOAT3 format), and the number of vertices is inferred from the size of that buffer.

Each grid in the grid buffer is of the type RTCGrid:

```
struct RTCGrid
{

  unsigned int startVertexID;

  unsigned int stride;

  unsigned short width,height;
};

```

The RTCGrid structure describes a 2D grid of vertices (with respect to the vertex buffer of the grid mesh). The width and height members specify the number of vertices in u and v direction, e.g. setting both width and height to 3 sets up a 3×3 vertex grid. The maximum allowed width and height is 32767. The startVertexID specifies the ID of the top-left vertex in the vertex grid, while the stride parameter specifies a stride (in number of vertices) used to step to the next row.

A vertex grid of dimensions width and height is treated as a (width-1) x (height-1) grid of quads (triangle-pairs), with the same shared edge handling as for regular quad meshes. However, the u/v coordinates have the uniform range [0..1] for an entire vertex grid. The u direction follows the width of the grid while the v direction the height.

For multi-segment motion blur, the number of time steps must be first specified using the rtcSetGeometryTimeStepCount call. Then a vertex buffer for each time step can be set using different buffer slots, and all these buffers must have the same stride and size.

### EXIT STATUS
On failure NULL is returned and an error code is set that can be queried using rtcGetDeviceError.

### SEE ALSO
[rtcNewGeometry]


title: RTC_GEOMETRY_TYPE_INSTANCE(4embree4)

text:
# RTC_GEOMETRY_TYPE_INSTANCE(4embree4)

### NAME

```
RTC_GEOMETRY_TYPE_INSTANCE - instance geometry type

```

### SYNOPSIS

```
#include <embree4/rtcore.h>
RTCGeometry geometry =

   rtcNewGeometry(device, RTC_GEOMETRY_TYPE_INSTANCE);

```

### DESCRIPTION
Embree supports instancing of scenes using affine transformations (3×3 matrix plus translation). As the instanced scene is stored only a single time, even if instanced to multiple locations, this feature can be used to create very complex scenes with small memory footprint.

Embree supports both single-level instancing and multi-level instancing. The maximum instance nesting depth is RTC_MAX_INSTANCE_LEVEL_COUNT; it can be configured at compile-time using the constant EMBREE_MAX_INSTANCE_LEVEL_COUNT. Users should adapt this constant to their needs: instances nested any deeper are silently ignored in release mode, and cause assertions in debug mode.

Instances are created by passing RTC_GEOMETRY_TYPE_INSTANCE to the rtcNewGeometry function call. The instanced scene can be set using the rtcSetGeometryInstancedScene call, and the affine transformation can be set using the rtcSetGeometryTransform function.

Please note that rtcCommitScene on the instanced scene should be called first, followed by rtcCommitGeometry on the instance, followed by rtcCommitScene for the top-level scene containing the instance.

If a ray hits the instance, the geomID and primID members of the hit are set to the geometry ID and primitive ID of the hit primitive in the instanced scene, and the instID member of the hit is set to the geometry ID of the instance in the top-level scene.

The instancing scheme can also be implemented using user geometries. To achieve this, the user geometry code should set the instID member of the ray query context to the geometry ID of the instance, then trace the transformed ray, and finally set the instID field of the ray query context again to -1. The instID field is copied automatically by each primitive intersector into the instID field of the hit structure when the primitive is hit. See the [User Geometry] tutorial for an example.

For multi-segment motion blur, the number of time steps must be first specified using the rtcSetGeometryTimeStepCount function. Then a transformation for each time step can be specified using the rtcSetGeometryTransform function.

See tutorials [Instanced Geometry] and [Multi Level Instancing] for examples of how to use instances.

### EXIT STATUS
On failure NULL is returned and an error code is set that can be queried using rtcGetDeviceError.

### SEE ALSO
[rtcNewGeometry], [rtcSetGeometryInstancedScene], [rtcSetGeometryTransform]


text:
# RTC_GEOMETRY_TYPE_INSTANCE_ARRAY(4embree4)

### NAME

```
RTC_GEOMETRY_TYPE_INSTANCE_ARRAY - instance array geometry type

```

### SYNOPSIS

```
#include <embree4/rtcore.h>
RTCGeometry geometry =

   rtcNewGeometry(device, RTC_GEOMETRY_TYPE_INSTANCE_ARRAY);

```

### DESCRIPTION
Embree supports instance arrays, which is a more memory efficient way to represent large amounts of instances of the same or a small set of (sub)scenes. The main difference to regular Embree instances is that Embree instance arrays have a buffer of transformations (either affine transformations or quaternion decompositions [RTCQuaternionDecomposition]) that can be allocated by Embree or a shared buffer, similar to vertex buffers for triangle meshes. Optionally, instead of instancing only one scene, an instance array can instance multiple scenes by passing an array of scenes and a corresponding index buffer that specifies which instance of the instance array instances which of the scenes in the scenes array.

Instance arrays are created by passing RTC_GEOMETRY_TYPE_INSTANCE_ARRAY to the rtcNewGeometry function call. The instanced scene can be either be set using the rtcSetGeometryInstancedScene call, or if multiple scenes should be instanced by passing an array of scenes using rtcSetGeometryInstancedScenes. The latter also requires to specify an index buffer using rtcSetNewGeometryBuffer or rtcSetSharedGeometryBuffer with RTC_BUFFER_TYPE_INDEX as the buffer type.

Because the transformation information can become large for a large amount of instances, the instance array allows to share the transformation buffer between the user application and Embree. It can be either stored in a buffer created by Embree with rtcSetNewGeometryBuffer or an already existing buffer can be shared using rtcSetSharedGeometryBuffer. In either case, the buffer type has to be RTC_BUFFER_TYPE_TRANSFORM and the allowed formats are RTC_FORMAT_FLOAT4X4_COLUMN_MAJOR, RTC_FORMAT_FLOAT3X4_COLUMN_MAJOR, RTC_FORMAT_FLOAT3X4_ROW_MAJOR, and RTC_FORMAT_QUATERNION_DECOMPOSITION. Embree will not modify the data in the transformation buffer.

Embree instance arrays support both single-level instancing and multi-level instancing. The maximum instance nesting depth is RTC_MAX_INSTANCE_LEVEL_COUNT; it can be configured at compile-time using the constant EMBREE_MAX_INSTANCE_LEVEL_COUNT. Users should adapt this constant to their needs: instances nested any deeper are silently ignored in release mode, and cause assertions in debug mode.

Please note that rtcCommitScene on the instanced scene(s) should be called first, followed by rtcCommitGeometry on the instance array, followed by rtcCommitScene for the top-level scene containing the instance array.

If a ray hits the instance, the geomID and primID members of the hit are set to the geometry ID and primitive ID of the hit primitive in the instanced scene. The instID member of the hit is set to the geometry ID of the instance array in the top-level scene and the instPrimID member is set to the index of the hit instance of the instance array.

For multi-segment motion blur, the number of time steps must be first specified using the rtcSetGeometryTimeStepCount function. Then a transformation for each time step can be specified using the rtcSetNewGeometryBuffer or rtcSetSharedGeometryBuffer function and passing the time step as the slot parameter of these calls.

See the [Instance Array Geometry] tutorial for an example of how to use instance arrays.

### EXIT STATUS
On failure NULL is returned and an error code is set that can be queried using rtcGetDeviceError.

### SEE ALSO
[rtcNewGeometry], [rtcSetGeometryInstancedScene], [rtcSetGeometryInstancedScenes], [rtcSetNewGeometryBuffer], [rtcSetSharedGeometryBuffer], [rtcGetGeometryTransformEx]


title: RTC_GEOMETRY_TYPE_POINT(4embree4)

text:
# RTC_GEOMETRY_TYPE_POINT(4embree4)

### NAME

```
RTC_GEOMETRY_TYPE_SPHERE_POINT -

  point geometry spheres
RTC_GEOMETRY_TYPE_DISC_POINT -

  point geometry with ray-oriented discs
RTC_GEOMETRY_TYPE_ORIENTED_DISC_POINT -

  point geometry with normal-oriented discs

```

### SYNOPSIS

```
#include <embree4/rtcore.h>
rtcNewGeometry(device, RTC_GEOMETRY_TYPE_SPHERE_POINT);
rtcNewGeometry(device, RTC_GEOMETRY_TYPE_DISC_POINT);
rtcNewGeometry(device, RTC_GEOMETRY_TYPE_ORIENTED_DISC_POINT);

```

### DESCRIPTION
Points with per vertex radii are supported with sphere, ray-oriented discs, and normal-oriented discs geometric representations. Such point geometries are created by passing RTC_GEOMETRY_TYPE_SPHERE_POINT, RTC_GEOMETRY_TYPE_DISC_POINT, or RTC_GEOMETRY_TYPE_ORIENTED_DISC_POINT to the rtcNewGeometry function. The point vertices can be specified t through a vertex buffer (RTC_BUFFER_TYPE_VERTEX). For the normal oriented discs a normal buffer (RTC_BUFFER_TYPE_NORMAL) has to get specified additionally. See rtcSetGeometryBuffer and rtcSetSharedGeometryBuffer for more details on how to set buffers.

The vertex buffer stores each control vertex in the form of a single precision position and radius stored in (x, y, z, r) order in memory (RTC_FORMAT_FLOAT4 format). The number of vertices is inferred from the size of this buffer. Similarly, the normal buffer stores a single precision normal per control vertex (x, y, z order and RTC_FORMAT_FLOAT3 format).

In the RTC_GEOMETRY_TYPE_SPHERE_POINT mode, a real geometric surface is rendered for the curve, which is more expensive but allows closeup views.

The RTC_GEOMETRY_TYPE_DISC_POINT flat mode is a fast mode designed to render distant points. In this mode the point is rendered as a ray facing disc.

The RTC_GEOMETRY_TYPE_ORIENTED_DISC_POINT mode is a mode designed as a midpoint geometrically between ray facing discs and spheres. In this mode the point is rendered as a normal oriented disc.

For all point types, only the hit distance and geometry normal is returned as hit information, u and v are set to zero.

For multi-segment motion blur, the number of time steps must be first specified using the rtcSetGeometryTimeStepCount call. Then a vertex buffer for each time step can be set using different buffer slots, and all these buffers must have the same stride and size.

Also see tutorial [Points] for an example of how to create and use point geometries.

### EXIT STATUS
On failure NULL is returned and an error code is set that can be queried using rtcGetDeviceError.

### SEE ALSO
[rtcNewGeometry]


title: RTC_GEOMETRY_TYPE_QUAD(4embree4)

text:
# RTC_GEOMETRY_TYPE_QUAD(4embree4)

### NAME

```
RTC_GEOMETRY_TYPE_QUAD - quad geometry type

```

### SYNOPSIS

```
#include <embree4/rtcore.h>
RTCGeometry geometry =

  rtcNewGeometry(device, RTC_GEOMETRY_TYPE_QUAD);

```

### DESCRIPTION
Quad meshes are created by passing RTC_GEOMETRY_TYPE_QUAD to the rtcNewGeometry function call. The quad indices can be specified by setting an index buffer (RTC_BUFFER_TYPE_INDEX type) and the quad vertices by setting a vertex buffer (RTC_BUFFER_TYPE_VERTEX type). See rtcSetGeometryBuffer and rtcSetSharedGeometryBuffer for more details on how to set buffers. The index buffer contains an array of four 32-bit indices per quad (RTC_FORMAT_UINT4 format), and the number of primitives is inferred from the size of that buffer. The vertex buffer contains an array of single precision x, y, z floating point coordinates (RTC_FORMAT_FLOAT3 format), and the number of vertices is inferred from the size of that buffer. The vertex buffer can be at most 16 GB large.

A quad is internally handled as a pair of two triangles v0,v1,v3 and v2,v3,v1, with the u'/v' coordinates of the second triangle corrected by u = 1-u' and v = 1-v' to produce a quad parametrization where u and v are in the range 0 to 1. Thus the parametrization of a quad uses the first vertex p0 as base point, and the vector p1 - p0 as u-direction, and p3 - p0 as v-direction. Thus vertex attributes t0,t1,t2,t3 can be bilinearly interpolated over the quadrilateral the following way:

```
t_uv = (1-v)((1-u)*t0 + u*t1) + v*((1-u)*t3 + u*t2)

```

Mixed triangle/quad meshes are supported by encoding a triangle as a quad, which can be achieved by replicating the last triangle vertex (v0,v1,v2 -> v0,v1,v2,v2). This way the second triangle is a line (which can never get hit), and the parametrization of the first triangle is compatible with the standard triangle parametrization.

A quad whose vertices are laid out counter-clockwise has its geometry normal pointing upwards outside the front face, like illustrated in the following picture.

```

```

For multi-segment motion blur, the number of time steps must be first specified using the rtcSetGeometryTimeStepCount call. Then a vertex buffer for each time step can be set using different buffer slots, and all these buffers must have the same stride and size.

### EXIT STATUS
On failure NULL is returned and an error code is set that can be queried using rtcGetDeviceError.

### SEE ALSO
[rtcNewGeometry]


title: RTC_GEOMETRY_TYPE_SUBDIVISION(4embree4)

text:
# RTC_GEOMETRY_TYPE_SUBDIVISION(4embree4)

### NAME

```
RTC_GEOMETRY_TYPE_SUBDIVISION - subdivision geometry type

```

### SYNOPSIS

```
#include <embree4/rtcore.h>
RTCGeometry geometry =

  rtcNewGeometry(device, RTC_GEOMETRY_TYPE_SUBDIVISION);

```

### DESCRIPTION
Catmull-Clark subdivision meshes are supported, including support for edge creases, vertex creases, holes, non-manifold geometry, and face-varying interpolation. The number of vertices per face can be in the range of 3 to 15 vertices (triangles, quadrilateral, pentagons, etc).

Subdivision meshes are created by passing RTC_GEOMETRY_TYPE_SUBDIVISION to the rtcNewGeometry function. Various buffers need to be set by the application to set up the subdivision mesh. See rtcSetGeometryBuffer and rtcSetSharedGeometryBuffer for more details on how to set buffers. The face buffer (RTC_BUFFER_TYPE_FACE type and RTC_FORMAT_UINT format) contains the number of edges/indices of each face (3 to 15), and the number of faces is inferred from the size of this buffer. The index buffer (RTC_BUFFER_TYPE_INDEX type) contains multiple (3 to 15) 32-bit vertex indices (RTC_FORMAT_UINT format) for each face, and the number of edges is inferred from the size of this buffer. The vertex buffer (RTC_BUFFER_TYPE_VERTEX type) stores an array of single precision x, y, z floating point coordinates (RTC_FORMAT_FLOAT3 format), and the number of vertices is inferred from the size of this buffer.

Optionally, the application may set additional index buffers using different buffer slots if multiple topologies are required for face-varying interpolation. The standard vertex buffers (RTC_BUFFER_TYPE_VERTEX) are always bound to the geometry topology (topology 0) thus use RTC_BUFFER_TYPE_INDEX with buffer slot 0. User vertex data interpolation may use different topologies as described later.

Optionally, the application can set up the hole buffer (RTC_BUFFER_TYPE_HOLE) which contains an array of 32-bit indices (RTC_FORMAT_UINT format) of faces that should be considered non-existing in all topologies. The number of holes is inferred from the size of this buffer.

Optionally, the application can fill the level buffer (RTC_BUFFER_TYPE_LEVEL) with a tessellation rate for each of the edges of each face. This buffer must have the same size as the index buffer. The tessellation level is a positive floating point value (RTC_FORMAT_FLOAT format) that specifies how many quads along the edge should be generated during tessellation. If no level buffer is specified, a level of 1 is used. The maximally supported edge level is 4096, and larger levels are clamped to that value. Note that edges may be shared between (typically 2) faces. To guarantee a watertight tessellation, the level of these shared edges should be identical. A uniform tessellation rate for an entire subdivision mesh can be set by using the rtcSetGeometryTessellationRate function. The existence of a level buffer has precedence over the uniform tessellation rate.

Optionally, the application can fill the sparse edge crease buffers to make edges appear sharper. The edge crease index buffer (RTC_BUFFER_TYPE_EDGE_CREASE_INDEX) contains an array of pairs of 32-bit vertex indices (RTC_FORMAT_UINT2 format) that specify unoriented edges in the geometry topology. The edge crease weight buffer (RTC_BUFFER_TYPE_EDGE_CREASE_WEIGHT) stores for each of these crease edges a positive floating point weight (RTC_FORMAT_FLOAT format). The number of edge creases is inferred from the size of these buffers, which has to be identical. The larger a weight, the sharper the edge. Specifying a weight of infinity is supported and marks an edge as infinitely sharp. Storing an edge multiple times with the same crease weight is allowed, but has lower performance. Storing an edge multiple times with different crease weights results in undefined behavior. For a stored edge (i,j), the reverse direction edges (j,i) do not have to be stored, as both are considered the same unoriented edge. Edge crease features are shared between all topologies.

Optionally, the application can fill the sparse vertex crease buffers to make vertices appear sharper. The vertex crease index buffer (RTC_BUFFER_TYPE_VERTEX_CREASE_INDEX), contains an array of 32-bit vertex indices (RTC_FORMAT_UINT format) to specify a set of vertices from the geometry topology. The vertex crease weight buffer (RTC_BUFFER_TYPE_VERTEX_CREASE_WEIGHT) specifies for each of these vertices a positive floating point weight (RTC_FORMAT_FLOAT format). The number of vertex creases is inferred from the size of these buffers, and has to be identical. The larger a weight, the sharper the vertex. Specifying a weight of infinity is supported and makes the vertex infinitely sharp. Storing a vertex multiple times with the same crease weight is allowed, but has lower performance. Storing a vertex multiple times with different crease weights results in undefined behavior. Vertex crease features are shared between all topologies.

Subdivision modes can be used to force linear interpolation for parts of the subdivision mesh; see rtcSetGeometrySubdivisionMode for more details.

For multi-segment motion blur, the number of time steps must be first specified using the rtcSetGeometryTimeStepCount call. Then a vertex buffer for each time step can be set using different buffer slots, and all these buffers have to have the same stride and size.

Also see tutorial [Subdivision Geometry] for an example of how to create subdivision surfaces.

### Parametrization
The parametrization for subdivision faces is different for quadrilaterals and non-quadrilateral faces.

The parametrization of a quadrilateral face uses the first vertex p0 as base point, and the vector p1 - p0 as u-direction and p3 - p0 as v-direction.

The parametrization for all other face types (with number of vertices not equal 4), have a special parametrization where the subpatch ID n (of the n-th quadrilateral that would be obtained by a single subdivision step) and the local hit location inside this quadrilateral are encoded in the UV coordinates. The following code extracts the sub-patch ID i and local UVs of this subpatch:

```
unsigned int l = floorf(0.5f*U);
unsigned int h = floorf(0.5f*V);
unsigned int i = 4*h+l;
float u = 2.0f*fracf(0.5f*U)-0.5f;
float v = 2.0f*fracf(0.5f*V)-0.5f;

```

This encoding allows local subpatch UVs to be in the range [-0.5,1.5[ thus negative subpatch UVs can be passed to rtcInterpolate to sample subpatches slightly out of bounds. This can be useful to calculate derivatives using finite differences if required. The encoding further has the property that one can just move the value u (or v) on a subpatch by adding du (or dv) to the special UV encoding as long as it does not fall out of the [-0.5,1.5[ range.

To smoothly interpolate vertex attributes over the subdivision surface we recommend using the rtcInterpolate function, which will apply the standard subdivision rules for interpolation and automatically takes care of the special UV encoding for non-quadrilaterals.

### Face-Varying Data
Face-varying interpolation is supported through multiple topologies per subdivision mesh and binding such topologies to vertex attribute buffers to interpolate. This way, texture coordinates may use a different topology with additional boundaries to construct separate UV regions inside one subdivision mesh.

Each such topology i has a separate index buffer (specified using RTC_BUFFER_TYPE_INDEX with buffer slot i) and separate subdivision mode that can be set using rtcSetGeometrySubdivisionMode. A vertex attribute buffer RTC_BUFFER_TYPE_VERTEX_ATTRIBUTE bound to a buffer slot j can be assigned to use a topology for interpolation using the rtcSetGeometryVertexAttributeTopology call.

The face buffer (RTC_BUFFER_TYPE_FACE type) is shared between all topologies, which means that the n-th primitive always has the same number of vertices (e.g. being a triangle or a quad) for each topology. However, the indices of the topologies themselves may be different.

### EXIT STATUS
On failure NULL is returned and an error code is set that can be queried using rtcGetDeviceError.

### SEE ALSO
[rtcNewGeometry]


title: RTC_GEOMETRY_TYPE_TRIANGLE(4embree4)

text:
# RTC_GEOMETRY_TYPE_TRIANGLE(4embree4)

### NAME

```
RTC_GEOMETRY_TYPE_TRIANGLE - triangle geometry type

```

### SYNOPSIS

```
#include <embree4/rtcore.h>
RTCGeometry geometry =

  rtcNewGeometry(device, RTC_GEOMETRY_TYPE_TRIANGLE);

```

### DESCRIPTION
Triangle meshes are created by passing RTC_GEOMETRY_TYPE_TRIANGLE to the rtcNewGeometry function call. The triangle indices can be specified by setting an index buffer (RTC_BUFFER_TYPE_INDEX type) and the triangle vertices by setting a vertex buffer (RTC_BUFFER_TYPE_VERTEX type). See rtcSetGeometryBuffer and rtcSetSharedGeometryBuffer for more details on how to set buffers. The index buffer must contain an array of three 32-bit indices per triangle (RTC_FORMAT_UINT3 format) and the number of primitives is inferred from the size of that buffer. The vertex buffer must contain an array of single precision x, y, z floating point coordinates (RTC_FORMAT_FLOAT3 format), and the number of vertices are inferred from the size of that buffer. The vertex buffer can be at most 16 GB large.

The parametrization of a triangle uses the first vertex p0 as base point, the vector p1 - p0 as u-direction and the vector p2 - p0 as v-direction. Thus vertex attributes t0,t1,t2 can be linearly interpolated over the triangle the following way:

```
t_uv = (1-u-v)*t0 + u*t1 + v*t2

     = t0 + u*(t1-t0) + v*(t2-t0)

```

A triangle whose vertices are laid out counter-clockwise has its geometry normal pointing upwards outside the front face, like illustrated in the following picture:

```

```

For multi-segment motion blur, the number of time steps must be first specified using the rtcSetGeometryTimeStepCount call. Then a vertex buffer for each time step can be set using different buffer slots, and all these buffers have to have the same stride and size.

Also see tutorial [Triangle Geometry] for an example of how to create triangle meshes.

### EXIT STATUS
On failure NULL is returned and an error code is set that be get queried using rtcGetDeviceError.

### SEE ALSO
[rtcNewGeometry]


title: RTC_GEOMETRY_TYPE_USER(4embree4)

text:
# RTC_GEOMETRY_TYPE_USER(4embree4)

### NAME

```
RTC_GEOMETRY_TYPE_USER - user geometry type

```

### SYNOPSIS

```
#include <embree4/rtcore.h>
RTCGeometry geometry =

  rtcNewGeometry(device, RTC_GEOMETRY_TYPE_USER);

```

### DESCRIPTION
User-defined geometries contain a number of user-defined primitives, just like triangle meshes contain multiple triangles. The shape of the user-defined primitives is specified through registered callback functions, which enable extending Embree with arbitrary types of primitives.

User-defined geometries are created by passing RTC_GEOMETRY_TYPE_USER to the rtcNewGeometry function call. One has to set the number of primitives (see rtcSetGeometryUserPrimitiveCount), a user data pointer (see rtcSetGeometryUserData), a bounding function closure (see rtcSetGeometryBoundsFunction), as well as user-defined intersect (see rtcSetGeometryIntersectFunction) and occluded (see rtcSetGeometryOccludedFunction) callback functions. The bounding function is used to query the bounds of all time steps of a user primitive, while the intersect and occluded callback functions are called to intersect the primitive with a ray. The user data pointer is passed to each callback invocation and can be used to point to the application’s representation of the user geometry.

The creation of a user geometry typically looks the following:

```
RTCGeometry geometry = rtcNewGeometry(device, RTC_GEOMETRY_TYPE_USER);
rtcSetGeometryUserPrimitiveCount(geometry, numPrimitives);
rtcSetGeometryUserData(geometry, userGeometryRepresentation);
rtcSetGeometryBoundsFunction(geometry, boundsFunction);
rtcSetGeometryIntersectFunction(geometry, intersectFunction);
rtcSetGeometryOccludedFunction(geometry, occludedFunction);

```

Please have a look at the rtcSetGeometryBoundsFunction, rtcSetGeometryIntersectFunction, and rtcSetGeometryOccludedFunction functions on the implementation of the callback functions.

Primitives of a user geometry are ignored during rendering when their bounds are empty, thus bounds have lower>upper in at least one dimension.

See tutorial [User Geometry] for an example of how to use the user-defined geometries.

### EXIT STATUS
On failure NULL is returned and an error code is set that can be queried using rtcGetDeviceError.

### SEE ALSO
[rtcNewGeometry], [rtcSetGeometryUserPrimitiveCount], [rtcSetGeometryUserData], [rtcSetGeometryBoundsFunction], [rtcSetGeometryIntersectFunction], [rtcSetGeometryOccludedFunction]


rtcAttachGeometry

title: rtcAttachGeometry(4embree4)

text:
# rtcAttachGeometry(4embree4)

### NAME

```
rtcAttachGeometry - attaches a geometry to the scene

```

### SYNOPSIS

```
#include <embree4/rtcore.h>
unsigned int rtcAttachGeometry(

  RTCScene scene,

  RTCGeometry geometry
);

```

### DESCRIPTION
The rtcAttachGeometry function attaches a geometry (geometry argument) to a scene (scene argument) and assigns a geometry ID to that geometry. All geometries attached to a scene are defined to be included inside the scene. A geometry can get attached to multiple scenes. The geometry ID is unique for the scene, and is used to identify the geometry when hit by a ray during ray queries.

This function is thread-safe, thus multiple threads can attach geometries to a scene in parallel.

The geometry IDs are assigned sequentially, starting from 0, as long as no geometry got detached. If geometries got detached, the implementation will reuse IDs in an implementation dependent way. Consequently sequential assignment is no longer guaranteed, but a compact range of IDs.

These rules allow the application to manage a dynamic array to efficiently map from geometry IDs to its own geometry representation. Alternatively, the application can also use per-geometry user data to map to its geometry representation. See rtcSetGeometryUserData and rtcGetGeometryUserData for more information.

### EXIT STATUS
On failure an error code is set that can be queried using rtcGetDeviceError.

### SEE ALSO
[rtcSetGeometryUserData], [rtcGetGeometryUserData]


rtcAttachGeometryByID

title: rtcAttachGeometryByID(4embree4)

text:
# rtcAttachGeometryByID(4embree4)

### NAME

```
rtcAttachGeometryByID - attaches a geometry to the scene

  using a specified geometry ID

```

### SYNOPSIS

```
#include <embree4/rtcore.h>
void rtcAttachGeometryByID(

  RTCScene scene,

  RTCGeometry geometry,

  unsigned int geomID
);

```

### DESCRIPTION
The rtcAttachGeometryByID function attaches a geometry (geometry argument) to a scene (scene argument) and assigns a user provided geometry ID (geomID argument) to that geometry. All geometries attached to a scene are defined to be included inside the scene. A geometry can get attached to multiple scenes. The passed user-defined geometry ID is used to identify the geometry when hit by a ray during ray queries. Using this function, it is possible to share the same IDs to refer to geometries inside the application and Embree.

This function is thread-safe, thus multiple threads can attach geometries to a scene in parallel.

The user-provided geometry ID must be unused in the scene, otherwise the creation of the geometry will fail. Further, the user-provided geometry IDs should be compact, as Embree internally creates a vector which size is equal to the largest geometry ID used. Creating very large geometry IDs for small scenes would thus cause a memory consumption and performance overhead.

### EXIT STATUS
On failure an error code is set that can be queried using rtcGetDeviceError.

### SEE ALSO
[rtcAttachGeometry]


rtcBuildBVH

title: rtcBuildBVH(4embree4)

text:
# rtcBuildBVH(4embree4)

### NAME

```
rtcBuildBVH - builds a BVH

```

### SYNOPSIS

```
#include <embree4/rtcore.h>
struct RTC_ALIGN(32) RTCBuildPrimitive
{

  float lower_x, lower_y, lower_z;

  unsigned int geomID;

  float upper_x, upper_y, upper_z;

  unsigned int primID;
};
typedef void* (*RTCCreateNodeFunction) (

  RTCThreadLocalAllocator allocator,

  unsigned int childCount,

  void* userPtr
);
typedef void (*RTCSetNodeChildrenFunction) (

  void* nodePtr,

  void** children,

  unsigned int childCount,

  void* userPtr
);
typedef void (*RTCSetNodeBoundsFunction) (

  void* nodePtr,

  const struct RTCBounds** bounds,

  unsigned int childCount,

  void* userPtr
);
typedef void* (*RTCCreateLeafFunction) (

  RTCThreadLocalAllocator allocator,

  const struct RTCBuildPrimitive* primitives,

  size_t primitiveCount,

  void* userPtr
);
typedef void (*RTCSplitPrimitiveFunction) (

  const struct RTCBuildPrimitive* primitive,

  unsigned int dimension,

  float position,

  struct RTCBounds* leftBounds,

  struct RTCBounds* rightBounds,

  void* userPtr
);
typedef bool (*RTCProgressMonitorFunction)(

  void* userPtr, double n
);
enum RTCBuildFlags
{

  RTC_BUILD_FLAG_NONE,

  RTC_BUILD_FLAG_DYNAMIC
};
struct RTCBuildArguments
{

  size_t byteSize;

  enum RTCBuildQuality buildQuality;

  enum RTCBuildFlags buildFlags;

  unsigned int maxBranchingFactor;

  unsigned int maxDepth;

  unsigned int sahBlockSize;

  unsigned int minLeafSize;

  unsigned int maxLeafSize;

  float traversalCost;

  float intersectionCost;

  RTCBVH bvh;

  struct RTCBuildPrimitive* primitives;

  size_t primitiveCount;

  size_t primitiveArrayCapacity;

  RTCCreateNodeFunction createNode;

  RTCSetNodeChildrenFunction setNodeChildren;

  RTCSetNodeBoundsFunction setNodeBounds;

  RTCCreateLeafFunction createLeaf;

  RTCSplitPrimitiveFunction splitPrimitive;

  RTCProgressMonitorFunction buildProgress;

  void* userPtr;
};
struct RTCBuildArguments rtcDefaultBuildArguments();
void* rtcBuildBVH(

  const struct RTCBuildArguments* args
);

```

### DESCRIPTION
The rtcBuildBVH function can be used to build a BVH in a user-defined format over arbitrary primitives. All arguments to the function are provided through the RTCBuildArguments structure. The first member of that structure must be set to the size of the structure in bytes (bytesSize member) which allows future extensions of the structure. It is recommended to initialize the build arguments structure using the rtcDefaultBuildArguments function.

The rtcBuildBVH function gets passed the BVH to build (bvh member), the array of primitives (primitives member), the capacity of that array (primitiveArrayCapacity member), the number of primitives stored inside the array (primitiveCount member), callback function pointers, and a user-defined pointer (userPtr member) that is passed to all callback functions when invoked. The primitives array can be freed by the application after the BVH is built. All callback functions are typically called from multiple threads, thus their implementation must be thread-safe.

Four callback functions must be registered, which are invoked during build to create BVH nodes (createNode member), to set the pointers to all children (setNodeChildren member), to set the bounding boxes of all children (setNodeBounds member), and to create a leaf node (createLeaf member).

The function pointer to the primitive split function (splitPrimitive member) may be NULL, however, then no spatial splitting in high quality mode is possible. The function pointer used to report the build progress (buildProgress member) is optional and may also be NULL.

Further, some build settings are passed to configure the BVH build. Using the build quality settings (buildQuality member), one can select between a faster, low quality build which is good for dynamic scenes, and a standard quality build for static scenes. One can also specify the desired maximum branching factor of the BVH (maxBranchingFactor member), the maximum depth the BVH should have (maxDepth member), the block size for the SAH heuristic (sahBlockSize member), the minimum and maximum leaf size (minLeafSize and maxLeafSize member), and the estimated costs of one traversal step and one primitive intersection (traversalCost and intersectionCost members). When enabling the RTC_BUILD_FLAG_DYNAMIC build flags (buildFlags member), re-build performance for dynamic scenes is improved at the cost of higher memory requirements.

To spatially split primitives in high quality mode, the builder needs extra space at the end of the build primitive array to store split primitives. The total capacity of the build primitive array is passed using the primitiveArrayCapacity member, and should be about twice the number of primitives when using spatial splits.

The RTCCreateNodeFunc and RTCCreateLeafFunc callbacks are passed a thread local allocator object that should be used for fast allocation of nodes using the rtcThreadLocalAlloc function. We strongly recommend using this allocation mechanism, as alternative approaches like standard malloc can be over 10× slower. The allocator object passed to the create callbacks may be used only inside the current thread. Memory allocated using rtcThreadLocalAlloc is automatically freed when the RTCBVH object is deleted. If you use your own memory allocation scheme you have to free the memory yourself when the RTCBVH object is no longer used.

The RTCCreateNodeFunc callback additionally gets the number of children for this node in the range from 2 to maxBranchingFactor (childCount argument).

The RTCSetNodeChildFunc callback function gets a pointer to the node as input (nodePtr argument), an array of pointers to the children (childPtrs argument), and the size of this array (childCount argument).

The RTCSetNodeBoundsFunc callback function gets a pointer to the node as input (nodePtr argument), an array of pointers to the bounding boxes of the children (bounds argument), and the size of this array (childCount argument).

The RTCCreateLeafFunc callback additionally gets an array of primitives as input (primitives argument), and the size of this array (primitiveCount argument). The callback should read the geomID and primID members from the passed primitives to construct the leaf.

The RTCSplitPrimitiveFunc callback is invoked in high quality mode to split a primitive (primitive argument) at the specified position (position argument) and dimension (dimension argument). The callback should return bounds of the clipped left and right parts of the primitive (leftBounds and rightBounds arguments).

The RTCProgressMonitorFunction callback function is called with the estimated completion rate n in the range [0, 1]. Returning true from the callback lets the build continue; returning false cancels the build.

### EXIT STATUS
On failure an error code is set that can be queried using rtcGetDeviceError.

### SEE ALSO
[rtcNewBVH]


rtcCollide

title: rtcCollide(4embree4)

text:
# rtcCollide(4embree4)

### NAME

```
rtcCollide - intersects one BVH with another

```

### SYNOPSIS

```
#include <embree4/rtcore.h>
struct RTCCollision {

  unsigned int geomID0, primID0;

  unsigned int geomID1, primID1;
};
typedef void (*RTCCollideFunc) (

  void* userPtr,

  RTCCollision* collisions,

  size_t num_collisions);
void rtcCollide (

    RTCScene hscene0,

    RTCScene hscene1,

    RTCCollideFunc callback,

    void* userPtr
);

```

### DESCRIPTION
The rtcCollide function intersects the BVH of hscene0 with the BVH of scene hscene1 and calls a user defined callback function (e.g callback argument) for each pair of intersecting primitives between the two scenes. A user defined data pointer (userPtr argument) can also be passed in.

For every pair of primitives that may intersect each other, the callback function (callback argument) is called. The user will be provided with the primID’s and geomID’s of multiple potentially intersecting primitive pairs. Currently, only scene entirely composed of user geometries are supported, thus the user is expected to implement a primitive/primitive intersection to filter out false positives in the callback function. The userPtr argument can be used to input geometry data of the scene or output results of the intersection query.

### SUPPORTED PRIMITIVES
Currently, the only supported type is the user geometry type (see [RTC_GEOMETRY_TYPE_USER]).

### EXIT STATUS
On failure an error code is set that can be queried using rtcGetDeviceError.


rtcCommitGeometry

title: rtcCommitGeometry(4embree4)

text:
# rtcCommitGeometry(4embree4)

### NAME

```
rtcCommitGeometry - commits geometry changes

```

### SYNOPSIS

```
#include <embree4/rtcore.h>
void rtcCommitGeometry(RTCGeometry geometry);

```

### DESCRIPTION
The rtcCommitGeometry function is used to commit all geometry changes performed to a geometry (geometry parameter). After a geometry gets modified, this function must be called to properly update the internal state of the geometry to perform interpolations using rtcInterpolate or to commit a scene containing the geometry using rtcCommitScene.

### EXIT STATUS
On failure an error code is set that can be queried using rtcGetDeviceError.

### SEE ALSO
[rtcInterpolate], [rtcCommitScene]


rtcCommitScene

title: rtcCommitScene(4embree4)

text:
# rtcCommitScene(4embree4)

### NAME

```
rtcCommitScene - commits scene changes

```

### SYNOPSIS

```
#include <embree4/rtcore.h>
void rtcCommitScene(RTCScene scene);

```

### DESCRIPTION
The rtcCommitScene function commits all changes for the specified scene (scene argument). This internally triggers building of a spatial acceleration structure for the scene using all available worker threads. Ray queries can be performed only after committing all scene changes.

If the application uses TBB 2019 Update 9 or later for parallelization of rendering, lazy scene construction during rendering is supported by rtcCommitScene. Therefore rtcCommitScene can get called from multiple TBB worker threads concurrently for the same scene. The rtcCommitScene function will then internally isolate the scene construction using a tbb::isolated_task_group. The alternative approach of using rtcJoinCommitScene which uses an tbb:task_arena internally, is not recommended due to it’s high runtime overhead.

If scene geometries get modified or attached or detached, the rtcCommitScene call must be invoked before performing any further ray queries for the scene; otherwise the effect of the ray query is undefined. The modification of a geometry, committing the scene, and tracing of rays must always happen sequentially, and never at the same time. Any API call that sets a property of the scene or geometries contained in the scene count as scene modification, e.g. including setting of intersection filter functions.

The kind of acceleration structure built can be influenced using scene flags (see rtcSetSceneFlags), and the quality can be specified using the rtcSetSceneBuildQuality function.

Embree silently ignores primitives during spatial acceleration structure construction that would cause numerical issues, e.g. primitives containing NaNs, INFs, or values greater than 1.844E18f (as no reasonable calculations can be performed with such values without causing overflows).

### EXIT STATUS
On failure an error code is set that can be queried using rtcGetDeviceError.

### SEE ALSO
[rtcJoinCommitScene]


rtcDetachGeometry

title: rtcDetachGeometry(4embree4)

text:
# rtcDetachGeometry(4embree4)

### NAME

```
rtcDetachGeometry - detaches a geometry from the scene

```

### SYNOPSIS

```
#include <embree4/rtcore.h>
void rtcDetachGeometry(RTCScene scene, unsigned int geomID);

```

### DESCRIPTION
This function detaches a geometry identified by its geometry ID (geomID argument) from a scene (scene argument). When detached, the geometry is no longer contained in the scene.

This function is thread-safe, thus multiple threads can detach geometries from a scene at the same time.

### EXIT STATUS
On failure an error code is set that can be queried using rtcGetDeviceError.

### SEE ALSO
[rtcAttachGeometry], [rtcAttachGeometryByID]


rtcDisableGeometry

title: rtcDisableGeometry(4embree4)

text:
# rtcDisableGeometry(4embree4)

### NAME

```
rtcDisableGeometry - disables the geometry

```

### SYNOPSIS

```
#include <embree4/rtcore.h>
void rtcDisableGeometry(RTCGeometry geometry);

```

### DESCRIPTION
The rtcDisableGeometry function disables the specified geometry (geometry argument). A disabled geometry is not rendered. Each geometry is enabled by default at construction time.

After disabling a geometry, the scene containing that geometry must be committed using rtcCommitScene for the change to have effect.

### EXIT STATUS
On failure an error code is set that can be queried using rtcGetDeviceError.

### SEE ALSO
[rtcNewGeometry], [rtcEnableGeometry], [rtcCommitScene]


rtcEnableGeometry

title: rtcEnableGeometry(4embree4)

text:
# rtcEnableGeometry(4embree4)

### NAME

```
rtcEnableGeometry - enables the geometry

```

### SYNOPSIS

```
#include <embree4/rtcore.h>
void rtcEnableGeometry(RTCGeometry geometry);

```

### DESCRIPTION
The rtcEnableGeometry function enables the specified geometry (geometry argument). Only enabled geometries are rendered. Each geometry is enabled by default at construction time.

After enabling a geometry, the scene containing that geometry must be committed using rtcCommitScene for the change to have effect.

### EXIT STATUS
On failure an error code is set that can be queried using rtcGetDeviceError.

### SEE ALSO
[rtcNewGeometry], [rtcDisableGeometry], [rtcCommitScene]


rtcFilterIntersection

title: rtcFilterIntersection(4embree4)

text:
# rtcFilterIntersection(4embree4)

### NAME

```
rtcFilterIntersection - invokes the intersection filter function

```

### SYNOPSIS

```
#include <embree4/rtcore.h>
void rtcFilterIntersection(

  const struct RTCIntersectFunctionNArguments* args,

  const struct RTCFilterFunctionNArguments* filterArgs
);

```

### DESCRIPTION
The rtcFilterIntersection function can be called inside an RTCIntersectFunctionN callback function to invoke the intersection filter registered to the geometry and stored inside the context. For this an RTCFilterFunctionNArguments structure must be created (see rtcSetGeometryIntersectFilterFunction) which basically consists of a valid mask, a hit packet to filter, the corresponding ray packet, and the packet size. After the invocation of rtcFilterIntersection, only rays that are still valid (valid mask set to -1) should update a hit.

### EXIT STATUS
For performance reasons this function does not do any error checks, thus will not set any error flags on failure.

### SEE ALSO
[rtcFilterOcclusion], [rtcSetGeometryIntersectFunction]


rtcFilterOcclusion

title: rtcFilterOcclusion(4embree4)

text:
# rtcFilterOcclusion(4embree4)

### NAME

```
rtcFilterOcclusion - invokes the occlusion filter function

```

### SYNOPSIS

```
#include <embree4/rtcore.h>
void rtcFilterOcclusion(

  const struct RTCOccludedFunctionNArguments* args,

  const struct RTCFilterFunctionNArguments* filterArgs
);

```

### DESCRIPTION
The rtcFilterOcclusion function can be called inside an RTCOccludedFunctionN callback function to invoke the occlusion filter registered to the geometry and stored inside the context. For this an RTCFilterFunctionNArguments structure must be created (see rtcSetGeometryIntersectFilterFunction) which basically consists of a valid mask, a hit packet to filter, the corresponding ray packet, and the packet size. After the invocation of rtcFilterOcclusion only rays that are still valid (valid mask set to -1) should signal an occlusion.

### EXIT STATUS
For performance reasons this function does not do any error checks, thus will not set any error flags on failure.

### SEE ALSO
[rtcFilterIntersection], [rtcSetGeometryOccludedFunction]


title: rtcForwardIntersect1(4embree4)

text:
# rtcForwardIntersect1(4embree4)

### NAME

```
rtcForwardIntersect1/Ex - forwards a single ray to new scene

  from user geometry callback

```

### SYNOPSIS

```
#include <embree4/rtcore.h>
void rtcForwardIntersect1(

  const struct RTCIntersectFunctionNArguments* args,

  RTCScene scene,

  struct RTCRay* ray,

  unsigned int instID
);
void rtcForwardIntersect1Ex(

  const struct RTCIntersectFunctionNArguments* args,

  RTCScene scene,

  struct RTCRay* ray,

  unsigned int instID,

  unsigned int instPrimID,
);

```

### DESCRIPTION
The rtcForwardIntersect1 and rtcForwardIntersect1Ex functions forward the traversal of a transformed ray (ray argument) into a scene (scene argument) from a user geometry callback. The function can only get invoked from a user geometry callback for a ray traversal initiated with the rtcIntersect1 function. The callback arguments structure of the callback invokation has to get passed to the ray forwarding (args argument). The user geometry callback should instantly terminate after invoking the rtcForwardIntersect1/Ex function.

Only the ray origin and ray direction members of the ray argument are used for forwarding, all additional ray properties are inherited from the initial ray traversal invokation of rtcIntersect1.

The implementation of the rtcForwardIntersect1 function recursively continues the ray traversal into the specified scene and pushes the provided instance ID (instID argument) to the instance ID stack. Hit information is updated into the ray hit structure passed to the original rtcIntersect1 invokation.

This function can get used to implement user defined instancing using user geometries, e.g. by transforming the ray in a special way, and/or selecting between different scenes to instantiate.

For user defined instance arrays, the rtcForwardIntersect1Ex variant has an additional instPrimID argument which is pushed to the instance primitive ID stack. Instance primitive IDs identify which instance of an instance array was hit.

When using Embree on the CPU it is possible to recursively invoke rtcIntersect1 directly from a user geometry callback. However, when SYCL is used, recursively tracing rays is not directly supported, and the rtcForwardIntersect1/Ex functions must be used.

The ray structure must be aligned to 16 bytes.

### EXIT STATUS
For performance reasons this function does not do any error checks, thus will not set any error flags on failure.

### SEE ALSO
[rtcIntersect1], [RTCRay]