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

branch: sisyphus


rtcCommitBuffer

package: embree-devel

title: rtcCommitBuffer(4embree4)

text:
# rtcCommitBuffer(4embree4)

### NAME

```
rtcCommitBuffer - commits buffer content from host to device

```

### SYNOPSIS

```
#include <embree4/rtcore.h>
void rtcCommitBuffer(RTCBuffer buffer);

```

### DESCRIPTION
If the buffer was created using rtcNewBufferHostDevice the rtcCommitBuffer function commits changes of the host buffer data to the device. This call is not necessary if the buffer was created with a non SYCL Embree device.

The call to rtcCommitBuffer will internally use a temporary SYCL queue and wait for the memory copy to finish. The function rtcCommitBufferWithQueue can be used to asyncronously copy the data to the device.

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

### SEE ALSO
[rtcCommitBufferWithQueue] [rtcNewBufferHostDevice]


rtcCommitBufferWithQueue

title: rtcCommitBufferWithQueue(4embree4)

text:
# rtcCommitBufferWithQueue(4embree4)

### NAME

```
rtcCommitBufferWithQueue - commits buffer content from host to device using a given SYCL queue

```

### SYNOPSIS

```
#include <embree4/rtcore.h>
void rtcCommitBufferWithQueue(RTCBuffer buffer,

    sycl::queue queue, sycl::event* event);

```

### DESCRIPTION
If the buffer was created using rtcNewBufferHostDevice the rtcCommitBufferWithQueue function commits changes of the host buffer data to the device. If the buffer was created with a non SYCL Embree device or the SYCL device has host unified memory, this call has no effect.

The call to rtcCommitBufferWithQueue will use the given SYCL queue to copy the memory asynchronously. If the SYCL event argument event is a valid pointer, Embree will use this pointer to return a copy of the SYCL event associated to the memory copy. The parameter event is optional and will be ignored if it is a null pointer.

The user is responsible for synchronization using the SYCL queue or the optional SYCL event.

This function is only avaiable on Embree versions with enabled SYCL support.

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

### SEE ALSO
[rtcCommitBuffer] [rtcNewBufferHostDevice]


rtcCommitSceneWithQueue

title: rtcCommitSceneWithQueue(4embree4)

text:
# rtcCommitSceneWithQueue(4embree4)

### NAME

```
rtcCommitSceneWithQueue - commits scene changes using a given

  SYCL queue for host-to-device memory transfers

```

### SYNOPSIS

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

  sycl::queue queue,

  sycl::event* event);

```

### DESCRIPTION
The rtcCommitSceneWithQueue 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.

The rtcCommitSceneWithQueue function differs from rtcCommitScene only in that the former uses a SYCL queue passed by the application for asynchronous host-to-device memory transfers and the latter uses an internal and temporary SYCL queue and is blocking, i.e. the function returns after all memory transfers are completed.

The application is responsible for synchronization when using rtcCommitSceneWithQueue by either calling wait() on the queue or use the optional event argument to receive a copy of the sycl::event associated with the last memcpy command that was submitted to the queue. The argument event can also be a null pointer in which case the argument will be ignored internally.

A SYCL kernel calling rtcTraversableIntersect or rtcTraversableOccluded using a RTCTraversable associated with the RTCScene scene has a dependency on the host-to-device memory transfers and therefore has to be synchronized properly.

This function is only available when SYCL support is enabled. In case the RTCDevice associated with the scene is not a SYCL device, rtcCommitSceneWithQueue will behave the same as rtcCommitScene.

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

### SEE ALSO
[rtcCommitScene]


rtcGetBufferDataDevice

title: rtcGetBufferDataDevice(4embree4)

text:
# rtcGetBufferDataDevice(4embree4)

### NAME

```
rtcGetBufferDataDevice - gets a device pointer to the buffer data

```

### SYNOPSIS

```
#include <embree4/rtcore.h>
void* rtcGetBufferDataDevice(RTCBuffer buffer);

```

### DESCRIPTION
The rtcGetBufferDataDevice function returns a pointer to the buffer data of the specified buffer object (buffer argument) which can be used for accessing the data on the device. If Embree has no SYCL support or the SYCL device has host unified memory, the pointer is equal to the pointer returned by rtcGetBufferData.

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

### SEE ALSO
[rtcGetBufferData], [rtcNewBuffer]


rtcGetGeometryBufferDataDevice

text:
# rtcGetGeometryBufferDataDevice(4embree4)

### NAME

```
rtcGetGeometryBufferDataDevice - gets pointer to

  the first buffer view element on the device.

```

### SYNOPSIS

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

  RTCGeometry geometry,

  enum RTCBufferType type,

  unsigned int slot
);

```

### DESCRIPTION
The rtcGetGeometryBufferDataDevice function returns a pointer to the first element of the buffer view attached to the specified buffer type and slot (type and slot argument) of the geometry (geometry argument) on the device.

If the device associated with geometry is no SYCL device, or if Embree is executed on a system with host unified memory (e.g., on an iGPU), the returned pointer is the same as the one returned by rtcGetGeometryBufferData.

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

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


rtcGetGeometryTransformFromTraversable

text:
# rtcGetGeometryTransformFromTraversable(4embree4)

### NAME

```
rtcGetGeometryTransformFromTraversable - returns the interpolated instance

  transformation for the specified time

```

### SYNOPSIS

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

  RTCTraversable traversable,

  unsigned int geomID,

  float time,

  enum RTCFormat format,

  void* xfm
);

```

### DESCRIPTION
The rtcGetGeometryTransformFromTraversable function is equivalent to rtcGetGeometryTransformFromScene but takes traversable object (traversable argument) instead of a scene object. Using this method is optional on CPU but it is required for SYCL.

For more details, refer to the documentation of rtcGetGeometryTransformFromScene.

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

### SEE ALSO
[rtcGetGeometryTransformFromScene], [rtcGetSceneTraversable]


rtcGetGeometryUserDataFromTraversable

text:
# rtcGetGeometryUserDataFromTraversable(4embree4)

### NAME

```
rtcGetGeometryUserDataFromTraversable - returns the user data pointer

  of the geometry through the scene object

```

### SYNOPSIS

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

    RTCTraversable traversable,

    unsigned int geomID);

```

### DESCRIPTION
The rtcGetGeometryUserDataFromTraversable function is equivalent to rtcGetGeometryUserDataFromScene but takes traversable object (traversable argument) instead of a scene object. Using this method is optional on CPU but it is required for SYCL.

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

### SEE ALSO
[rtcGetGeometryUserDataFromScene], [rtcGetSceneTraversable]


rtcGetSceneTraversable

title: rtcGetSceneTraversable(4embree4)

text:
# rtcGetSceneTraversable(4embree4)

### NAME

```
rtcGetSceneTraversable - gets a read-only hand to a RTCScene object

  that is also valid on a SYCL device and can be used for ray queries.

```

### SYNOPSIS

```
#include <embree4/rtcore.h>
RTCTraversable rtcGetSceneTraversable(RTCScene scene);

```

### DESCRIPTION
The rtcGetSceneTraversable function returns a read-only handle to a RTCScene object (scene argument). Traversable objects are used for ray queries on a SYCL device.

Traversable objects can also be used in host/CPU code and Embree provides other API calls such as the rtcTraversablePointQuery to help write portable code compatible with CPU and SYCL device execution.

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

### SEE ALSO
[rtcTraversableIntersect1]


rtcNewBufferHostDevice

title: rtcNewBufferHostDevice(4embree4)

text:
# rtcNewBufferHostDevice(4embree4)

### NAME

```
rtcNewBufferHostDevice - creates a new data buffer with

  explicitly managed host and device memory allocations

```

### SYNOPSIS

```
#include <embree4/rtcore.h>
RTCBuffer rtcNewBufferHostDevice(

  RTCDevice device,

  size_t byteSize
);

```

### DESCRIPTION
The rtcNewBufferHostDevice function creates a new data buffer object of specified size in bytes (byteSize argument) that is bound to the specified device (device argument). The buffer object is reference counted with an initial reference count of 1. The returned buffer object can be released using the rtcReleaseBuffer API call. If Embree has SYCL support enabled and the SYCL device has no host unifed memory (e.g, a discrete GPU), the buffer allocates memory on the host and device explicitly. After the buffer is modified on the host rtcCommitBuffer can be used to synchronize host and device memory by copying the buffer content from the host to device. If the Embree version has no SYCL support or the SYCL device has host unified memory, the buffer will behave the same as a buffer created using rtcNewBuffer. The specified number of bytes are allocated at buffer construction time and deallocated when the buffer is destroyed.

```

```

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

### SEE ALSO
[rtcCommitBuffer], [rtcNewBuffer], [rtcRetainBuffer], [rtcReleaseBuffer]


rtcNewSharedBufferHostDevice

title: rtcNewSharedBufferHostDevice(4embree4)

text:
# rtcNewSharedBufferHostDevice(4embree4)

### NAME

```
rtcNewSharedBufferHostDevice - creates a new shared data buffer

  with a managed copy of the buffer in device memory

```

### SYNOPSIS

```
#include <embree4/rtcore.h>
RTCBuffer rtcNewSharedBufferHostDevice(

  RTCDevice device,

  void* ptr,

  size_t byteSize
);

```

### DESCRIPTION
The rtcNewSharedBufferHostDevice function creates a new shared data buffer object bound to the specified device (device argument). The buffer object is reference counted with an initial reference count of 1. The buffer can be released using the rtcReleaseBuffer function.

At construction time, the pointer to the user-managed buffer data (ptr argument) including its size in bytes (byteSize argument) is provided to create the buffer. At buffer construction time no buffer data is allocated on the host, but the buffer data provided by the application is used. A equal sized memory allocation is created on the device. The buffer data must remain valid for as long as the buffer may be used, and the user is responsible to free the buffer data when no longer required.

```

```

The data pointer (ptr argument) must be aligned to 4 bytes; otherwise the rtcNewSharedBufferHostDevice function will fail.

The function rtcCommitBuffer can be used to synchronize the buffer content with the device.

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

### SEE ALSO
[rtcNewSharedBuffer], [rtcCommitBuffer], [rtcRetainBuffer], [rtcReleaseBuffer]


rtcSetNewGeometryBufferHostDevice

text:
# rtcSetNewGeometryBufferHostDevice(4embree4)

### NAME

```
rtcSetNewGeometryBufferHostDevice - creates and assigns a new host/device

  data buffer pair to the geometry

```

### SYNOPSIS

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

  RTCGeometry geometry,

  enum RTCBufferType type,

  unsigned int slot,

  enum RTCFormat format,

  size_t byteStride,

  size_t itemCount,

  void** ptr,

  void** dptr
);

```

### DESCRIPTION
The rtcSetNewGeometryBufferHostDevice function creates a new host/device data buffer pair of specified format (format argument), byte stride (byteStride argument), and number of items (itemCount argument), and assigns it to a geometry buffer slot (type and slot argument) of the specified geometry (geometry argument). The buffer data is managed internally and automatically freed when the geometry is destroyed.

The byte stride (byteStride argument) must be aligned to 4 bytes; otherwise the rtcSetNewGeometryBufferHostDevice function will fail.

The allocated buffer will be automatically over-allocated slightly when used as a vertex buffer, where a requirement is that each buffer element should be readable using 16-byte SSE load instructions.

If ptr is not null, it will be used to return the address of the host data buffer. If dptr is not null, it will be used to return the address of the device data buffer. Either ptr or dptr or both can be null. In this case rtcGetGeometryBufferData and rtcGetGeometryBufferDataDevice can be used to get the addresses of the host and device data buffers.

The application is responsible of keeping the host and device memory in sync. The host memory has to be updated before calls of rtcCommitScene involving the associated geometry.

If Embree has no SYCL support or the associated Embree device is no SYCL device the dptr argument will return the same address as ptr if on null. In this case the function rtcSetNewGeometryBufferHostDevice will behave like rtcSetSharedGeometryBuffer.

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

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


rtcSetSharedGeometryBufferHostDevice

text:
# rtcSetSharedGeometryBufferHostDevice(4embree4)

### NAME

```
rtcSetSharedGeometryBufferHostDevice - assigns views of shared data buffers

  to a geometry using explicit host and device memory

```

### SYNOPSIS

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

  RTCGeometry geometry,

  enum RTCBufferType type,

  unsigned int slot,

  enum RTCFormat format,

  const void* ptr,

  const void* dptr,

  size_t byteOffset,

  size_t byteStride,

  size_t itemCount
);

```

### DESCRIPTION
The rtcSetSharedGeometryBufferHostDevice function binds views of a shared user-managed data buffers to a geometry buffer type and slot (type and slot argument) of the specified geometry (geometry argument). The user-managed data buffers are passed using the ptr argument for the host side allocated memory and the dptr parameter for the memory allocated on the device.

One can specify the start of the first buffer element in bytes (byteOffset argument), the byte stride between individual buffer elements (byteStride argument), the format of the buffer elements (format argument), and the number of elements to bind (itemCount).

The start address (byteOffset argument) and stride (byteStride argument) must be both aligned to 4 bytes; otherwise the rtcSetSharedGeometryBufferHostDevice function will fail.

```

```

The buffer data must remain valid for as long as the buffer may be used, and the user is responsible for freeing the buffer data when no longer required.

The application is responsible of keeping the host and device memory in sync. The host memory has to be updated before calls of rtcCommitScene involving the associated geometry.

If Embree has no SYCL support or the associated Embree device is no SYCL device the dptr argument must be a null pointer. In this case the function rtcSetSharedGeometryBufferHostDevice will behave like rtcSetSharedGeometryBuffer.

Sharing buffers can significantly reduce the memory required by the application, thus we recommend using this feature. When enabling the RTC_SCENE_FLAG_COMPACT scene flag, the spatial index structures index into the vertex buffer, resulting in even higher memory savings.

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

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


text:
# rtcTraversableForwardIntersect1(4embree4)

### NAME

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

  from user geometry callback

```

### SYNOPSIS

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

  const struct RTCIntersectFunctionNArguments* args,

  RTCTraversable traversable,

  struct RTCRay* ray,

  unsigned int instID
);
void rtcTraversableForwardIntersect1Ex(

  const struct RTCIntersectFunctionNArguments* args,

  RTCTraversable traversable,

  struct RTCRay* ray,

  unsigned int instID,

  unsigned int instPrimID,
);

```

### DESCRIPTION
The rtcTraversalbeForwardIntersect1 and rtcTraversableForwardIntersect1Ex functions are equivalent to rtcForwardIntersect1 and rtcForwardIntersect1Ex respectively but take a traversable object (traversable argument) instead of a scene object.

For more details, refer to the documentation of rtcForwardIntersect1/Ex.

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

### SEE ALSO
[rtcForwardIntersect1], [rtcGetSceneTraversable]


text:
# rtcTraversableForwardIntersect4(4embree4)

### NAME

```
rtcTraversableForwardIntersect4/8/16/Ex - forwards a ray packet to new scene

  from user geometry callback

```

### SYNOPSIS

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

  void int* valid,

  const struct RTCIntersectFunctionNArguments* args,

  RTCTraversable traversable,

  struct RTCRay4* ray,

  unsigned int instID
);
void rtcTraversableForwardIntersect8(

  void int* valid,

  const struct RTCIntersectFunctionNArguments* args,

  RTCTraversable traversable,

  struct RTCRay8* ray,

  unsigned int instID
);
void rtcTraversableForwardIntersect16(

  void int* valid,

  const struct RTCIntersectFunctionNArguments* args,

  RTCTraversable traversable,

  struct RTCRay16* ray,

  unsigned int instID,

  unsigned int instPrimID
);
void rtcTraversableForwardIntersect4Ex(

  void int* valid,

  const struct RTCIntersectFunctionNArguments* args,

  RTCTraversable traversable,

  struct RTCRay4* ray,

  unsigned int instID,

  unsigned int instPrimID
);
void rtcTraversableForwardIntersect8Ex(

  void int* valid,

  const struct RTCIntersectFunctionNArguments* args,

  RTCTraversable traversable,

  struct RTCRay8* ray,

  unsigned int instID,

  unsigned int instPrimID
);
void rtcTraversableForwardIntersect16Ex(

  void int* valid,

  const struct RTCIntersectFunctionNArguments* args,

  RTCTraversable traversable,

  struct RTCRay16* ray,

  unsigned int instID,

  unsigned int instPrimID
);

```

### DESCRIPTION
The rtcTraversableForwardIntersect4/8/16/Ex functions are equivalent to rtcForwardIntersect4/8/16/Ex but take a traversable object (traversable argument) instead of a scene object.

For more details, refer to the documentation of rtcForwardIntersect4/8/16/Ex.

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

### SEE ALSO
[rtcForwardIntersect4/8/16/Ex], [rtcGetSceneTraversable]


text:
# rtcTraversableForwardOccluded1(4embree4)

### NAME

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

  from user geometry callback

```

### SYNOPSIS

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

  const struct RTCOccludedFunctionNArguments* args,

  RTCTraversable traversable,

  struct RTCRay* ray,

  unsigned int instID
);
void rtcTraversableForwardOccluded1Ex(

  const struct RTCOccludedFunctionNArguments* args,

  RTCTraversable traversable,

  struct RTCRay* ray,

  unsigned int instID,

  unsigned int instPrimID,
);

```

### DESCRIPTION
The rtcTraversalbeForwardOccluded1 and rtcTraversableForwardOccluded1Ex functions are equivalent to rtcForwardOccluded1 and rtcForwardOccluded1Ex respectively but take a traversable object (traversable argument) instead of a scene object.

For more details, refer to the documentation of rtcForwardOccluded1/Ex.

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

### SEE ALSO
[rtcForwardOccluded1], [rtcGetSceneTraversable]


text:
# rtcTraversableForwardOccluded4(4embree4)

### NAME

```
rtcTraversableForwardOccluded4/8/16/Ex - forwards a ray packet to new scene

  from user geometry callback

```

### SYNOPSIS

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

  void int* valid,

  const struct RTCOccludedFunctionNArguments* args,

  RTCTraversable traversable,

  struct RTCRay4* ray,

  unsigned int instID
);
void rtcTraversableForwardOccluded8(

  void int* valid,

  const struct RTCOccludedFunctionNArguments* args,

  RTCTraversable traversable,

  struct RTCRay8* ray,

  unsigned int instID
);
void rtcTraversableForwardOccluded16(

  void int* valid,

  const struct RTCOccludedFunctionNArguments* args,

  RTCTraversable traversable,

  struct RTCRay16* ray,

  unsigned int instID
);
void rtcTraversableForwardOccluded4Ex(

  void int* valid,

  const struct RTCOccludedFunctionNArguments* args,

  RTCTraversable traversable,

  struct RTCRay4* ray,

  unsigned int instID,

  unsigned int instPrimID
);
void rtcTraversableForwardOccluded8Ex(

  void int* valid,

  const struct RTCOccludedFunctionNArguments* args,

  RTCTraversable traversable,

  struct RTCRay8* ray,

  unsigned int instID,

  unsigned int instPrimID
);
void rtcTraversableForwardOccluded16Ex(

  void int* valid,

  const struct RTCOccludedFunctionNArguments* args,

  RTCTraversable traversable,

  struct RTCRay16* ray,

  unsigned int instID,

  unsigned int instPrimID
);

```

### DESCRIPTION
The rtcTraversableForwardOccluded4/8/16/Ex functions are equivalent to rtcForwardOccluded4/8/16/Ex but take a traversable object (traversable argument) instead of a scene object.

For more details, refer to the documentation of rtcForwardOccluded4/8/16/Ex.

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

### SEE ALSO
[rtcForwardOccluded4/8/16/Ex], [rtcGetSceneTraversable]


title: rtcTraversableIntersect1(4embree4)

text:
# rtcTraversableIntersect1(4embree4)

### NAME

```
rtcTraversableIntersect1 - finds the closest hit for a single ray

```

### SYNOPSIS

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

  RTCTraversable traversable,

  struct RTCRayHit* rayhit

  struct RTCIntersectArguments* args = NULL
);

```

### DESCRIPTION
The rtcTraversableIntersect function is equivalent to rtcIntersect1 but takes traversable object (traversable argument) instead of a scene object. Using this method is optional on CPU but it is required for SYCL.

For more details, refer to the documentation of rtcIntersect1.

### 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], [rtcGetSceneTraversable]


title: rtcTraversableIntersect4(4embree4)

text:
# rtcTraversableIntersect4(4embree4)

### NAME

```
rtcTravesableIntersect4/8/16 - finds the closest hits for a ray packet

```

### SYNOPSIS

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

  const int* valid,

  RTCTraversable traversable,

  struct RTCRayHit4* rayhit,

  struct RTCIntersectArguments* args = NULL
);
void rtcTraversableIntersect8(

  const int* valid,

  RTCTraversable traversable,

  struct RTCRayHit8* rayhit,

  struct RTCIntersectArguments* args = NULL
);
void rtcTraversableIntersect16(

  const int* valid,

  RTCTraversable traversable,

  struct RTCRayHit16* rayhit,

  struct RTCIntersectArguments* args = NULL
);

```

### DESCRIPTION
The rtcTraversableIntersect4/8/16 functions are equivalent to rtcIntersect4/8/16 but take a traversable object (traversable argument) instead of a scene object.

For more details, refer to the documentation of rtcIntersect4/8/16.

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

### SEE ALSO
[rtcIntersect4/8/16], [rtcGetSceneTraversable]


title: rtcTraversableOccluded1(4embree4)

text:
# rtcTraversableOccluded1(4embree4)

### NAME

```
rtcTraversableOccluded1 - finds any hit for a single ray

```

### SYNOPSIS

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

  RTCTraversable traversable,

  struct RTCRay* ray,

  struct RTCOccludedArguments* args = NULL
);

```

### DESCRIPTION
The rtcTraversableOccluded1 function is equivalent to rtcOccluded1 but takes traversable object (traversable argument) instead of a scene object. Using this method is optional on CPU but it is required for SYCL.

For more details, refer to the documentation of rtcOccluded1.

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

### SEE ALSO
[rtcOccluded1], [rtcGetSceneTraversable]


title: rtcTraversableOccluded4(4embree4)

text:
# rtcTraversableOccluded4(4embree4)

### NAME

```
rtcTraversableOccluded4/8/16 - finds any hits for a ray packet

```

### SYNOPSIS

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

  const int* valid,

  RTCTraversable traversable,

  struct RTCRay4* ray,

  struct RTCOccludedArguments* args = NULL
);
void rtcTraversableOccluded8(

  const int* valid,

  RTCTraversable traversable,

  struct RTCRay8* ray,

  struct RTCOccludedArguments* args = NULL
);
void rtcTraversableOccluded16(

  const int* valid,

  RTCTraversable traversable,

  struct RTCRay16* ray,

  struct RTCOccludedArguments* args = NULL
);

```

### DESCRIPTION
The rtcTraversableOccluded4/8/16 functions are equivalent to rtcOccluded4/8/16 but take a traversable object (traversable argument) instead of a scene object.

For more details, refer to the documentation of rtcOccluded4/8/16.

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

### SEE ALSO
[rtcOccluded4/8/16], [rtcGetSceneTraversable]


rtcTraversablePointQuery

title: rtcTraversablePointQuery(4embree4)

text:
# rtcTraversablePointQuery(4embree4)

### NAME

```
rtcTraversablePointQuery - traverses the BVH with a point query object

```

### SYNOPSIS

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

  RTCTraversable traversable,

  struct RTCPointQuery* query,

  struct RTCPointQueryContext* context,

  struct RTCPointQueryFunction* queryFunc,

  void* userPtr
);

```

### DESCRIPTION
The rtcTraversablePointQuery function is equivalent to rtcPointQuery but takes a traversable object (traversable argument) instead of a scene object.

For more details, refer to the documentation of rtcPointQuery.

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

### SEE ALSO
[rtcPointQuery], [rtcGetSceneTraversable]


title: rtcTraversablePointQuery4(4embree4)

text:
# rtcTraversablePointQuery4(4embree4)

### NAME

```
rtcTraversablePointQuery4/8/16 - traverses the BVH with a point query object for a ray packet

```

### DESCRIPTION
The rtcTraversablePointQuery4/8/16 functions are equivalent to rtcPointQuery4/8/16 but take a traversable object (traversable argument) instead of a scene object.

For more details, refer to the documentation of rtcPointQuery4/8/16.

### SEE ALSO
[rtcPointQuery4/8/16], [rtcGetSceneTraversable]