Realtime image display means that rendered image data is made available while it is being rendered, on a tile-by-tile basis. The tiles are sent to various destinations in parallel as listed below. Any number of concurrent streams is supported, and the delivery of tiles is handled by a separate thread in mental ray that will maintain a fast response rate regardless of system load, not exhibiting long delays between tiles because running independently of rendering operations.
Image tiles can be sent to
The image file is created initially with a size of exactly 128 bytes. The first bytes are are filled with a sequence of characters such as
ray3.6,1024,768,robot,51382,1.000000,140528,51383
The fields are comma separated. The order and meaning of the fields is pre-defined as follows:
| version | width | height | host | tile port | gamma | process | talk port |
|---|---|---|---|---|---|---|---|
ray3.6 | 1024 | 768
| robot | 51382 | 1.0
| 140528 | 51383
|
3.6 for current mental ray indicating IPv6 support, or
3.3 for older versions using IPv4. Otherwise, both versions
perform identical display protocol communication and byte streams.
robot, to be able to connect to remote renderings.
-1 as socket identifier for
the tile port, which informs that the firewall mode
was enabled by the package that mental ray is integrated in. This mode
attempts to work with restrictive firewall software which considers an
attempt to create any kind of socket, even local sockets, as a
remote access and, therefore, blocks it. This is common practice on Windows
platforms. mental ray in firewall mode does not use sockets for
communication any more, thus disables tile delivery in this case.
mental ray also offers the
mi_disp_stream_socket_begin function, which installs a user-defined
socket and starts sending data to that socket. This socket is independent of
the socket created automatically by mental ray for image file output, and
will not get written to any files.
Note The difference between a file descriptor (method 1) and a socket is that the former begin the transfer with a type-5 message and the latter with a type-6 message (see below).
Data is sent in packets. Each packet consists of a header, followed by optional image data. The header consists of five integers in network byte order (big-endian, high byte first): one packet type code followed by four parameters. The following packets are defined:
| 0 | 1 | 2 | 3 | 4 | data size | function |
|---|---|---|---|---|---|---|
| 6 | frame | 0 | 0 | 0 | 0 | start of a new frame |
| 5 | width | height | gamma | 0 | 0 | image size (file descriptor only) |
| 2 | xl | xh | yl | yh |
n · (yh − yl + 1) · (xh − xl + 1) |
new image tile, n = 4 for RGBA |
| 4 | 0 | 0 | 0 | 0 | 0 | end of image |
| 3 | 0 | 0 | 0 | 0 | 0 | refuse connection |
5) are sent only to file descriptors
and not to sockets because socket readers have obtained that information
from the 128-byte file already. All integer values are sent in network byte
order, including the gamma value which is actually a floating-point value
(to be read as integer and converted to a float afterwards, see example).
Packets with types not listed in the table above should be
quietly ignored, they will consist of only the header.
Only image data packets (type 2) have data after the header.
Data is sent in expected order, like RGBARGBA... for color tiles with eight
bits per pixel component, beginning with the lower left corner of each tile.
The coordinates of the lower left tile pixel (xl, yl) and of
the upper right tile pixel (xh, yh) are in absolute image
coordinates. If output shaders run, the image may be sent multiple times,
once as rectangular tiles during rendering and then once per output shader
in blocks of scanlines, or even as a complete image. The order of tile and
scanline packets is undefined.