The Machine Configuration is a subsection of the Ventuz Configuration and defines common settings that are not changed very often:
| Generate Touch for Mouse | Enable to generate artificial touch events for mouse movements. This allows a mouse to trigger interaction nodes such as the Touch Button. |
The Windows Touch API was introduced by Microsoft with Windows Vista/Windows 7 to present a uniform way of devices interacting with the Windows operating system. It is usually only used for simple setups: one touch LCD display that is connected to a single machine. To support multi touch interaction with Windows applications that have no explicit multi touch support, a Windows Touch display generates both touch as well as artificial mouse information.
| Enabled | Enables the Windows Multitouch messages and blocks the artificial mouse messages generated by the same display. To use a touch display with mouse I/O nodes, deactivate this checkbox. |
The TUIO network protocol is often used by camera-based tracking systems or other dedicated Multi Touch input devices. It is the de-facto standard for transmitting touch information between devices/machines. Touch LCD displays, however, often only implement the Windows Touch protocol.
| Enabled | Enables the TUIO input. |
| UDP Port | UDP/IP port for TUIO messages. The default port used for the TUIO protocol is 3333. |
| Multicast IP | Multicast IP address used for TUIO messages. If left empty UDP Unicast is used and the TUIO sender must send the data to the local IP address of this Ventuz machine. |
The Ventuz Input Subsystem is capable of distributing input information from one machine to a cluster of machines. For example, a mouse attached to the host computer can be relayed to a number of rendering client machines. For more information, see Input Handling inside Ventuz. Please note that a valid Cluster License must exist to enable the Cluster Networking for interactivity.
| Single Machine Setup | The machine will only react to input information from devices attached to itself. The information will neither be broadcast to the network nor will the machine react to any information that may be broadcast by a Master machine in the same network. |
| Master | The machine will broadcast the information received from hardware devices attached to it into the network. It will not react to the information directly but listen to the sent network packages in the same way as a Client machine. |
| Client | The Ventuz scene will not receive any input from hardware devices attached to the local machine. However, it will receive and react to input broadcast by the Master machine. |
| Processing Delay | When using multiple machines, each may have a slightly different latency when it comes to receiving information from the input Master. A machine caches received information until the machine's clock matches the timestamp in the input information package plus the processing delay. So if it takes up to 3 frames to send information from the host to one machine but only 1 frame to get it to another, a sufficiently high processing delay forces all machines to process the information at the same time. |
| Scale with Window Size | Both the Inertia and Tick Attraction threshold are based on the nodes mapping area, not pixel resolution. Therefore increasing the window size will increase the size of the mapping area coordinate system in screen space and a specific movement will result in a smaller velocity than before. By activating this option, Ventuz will compensate for such changes automatically. |
| Scaling Factor | Use this value to scale the Inertia and Tick Attraction Threshold of all Translation/Rotation/Transformation Nodes. This is most useful when the target presentation system has a much larger display (in physical size, not resolution) than the system the scene was authored on but the node behaviors should feel the same. |
Deprecated
Remoting 2 is a Microsoft .net Remoting based protocol that was introduced in Ventuz 2008 (V2). This protocol still exists in Ventuz 4 but does not support the entire set of functionality (such as Template Engine, Live Options, etc). It is Recommended to use Remoting 4 for new client applications. Ventuz Director uses Remoting 4.
| Enabled | Enables the .net Remoting remote interface. |
| TCP Port | TCP/IP Port to be used. |
Remoting 4 was introduced with the release of Ventuz 4 and is the recommended way to remote Ventuz Runtime. Remoting 4 is always enabled and uses TCP port 19400. This settings are not adjustable. See Remoting
| Enabled | Enables the Miranda/Vertigo remote interface. |
| TCP Port | TCP/IP Port to be used. |
Deprecated
The Command Line Interface (CLI) is a very simple TCP text based interface to control very simple actions in Ventuz Runtime. This protocol still exists in Ventuz 4 but does not support the entire set of functionality (such as Template Engine, Live Options, etc). It is recommended to use Remoting 4 for new client applications. Ventuz Director uses Remoting 4 as well.
| Enabled | Enables the CLI remote interface. |
| Command Separator | Line-ending to be used for CLI commands. |
| Line Separator | If text values are transferred, this line-ending is used to substitute line-feeds. A safer way to transfer line feeds is to HTML-encode them, e.g. |
| Command Indexing | If Command Indexing is enabled (other than None) every command has to be led by an command index value. Any response to this command will be send with same index number. The mode Advanced allows to send an index of -1 to tell the CLI that no response is required at all. |
| Encoding | Selects the character encoding to be used. |
OSC Remoting is a very simple Open Sound Control based protocol to control DataItems of the SceneData. It only controls the current scene loaded in Port 0 of the layout scene in pipe 0. It is unable to manage scenes or Templates. For more sophisticated remoting capabilities use Remoting 4
| Enabled | Enables the OSC remote interface. |
| Receive UDP Port | Defines the UDP/IP port to use for receiving OSC messages. |
| Receive Multicast IP | If specified, the [wikiRemotingDeprecated OSC] remote interface. |
| Receive UDP Port | Defines the UDP/IP port to use for receiving OSC messages. |
| Receive Multicast IP | If specified, the OSC Remoting listens to a UDP Multicast group. If left blank, UDP Unicast is used. |
| Send Enabled | If enabled, externalized events are sent as an OSC message. |
| Send UDP Port | Defines the UDP/IP port to be used for sending events. |
| Send Multicast IP | Defines the UDP/IP address to be used for sending events. |
The Culture Settings contain configurations related to Fonts, Font Rendering and Text Formatting.
| 2D Text | Enables high quality 2D text rendering. See Text2D |
| Culture | Selects the culture to be used for text formatting |
| Charset | Selects the Unicode ranges to be used when using Font and Typefaces. |
The Web Browser Node has some internal settings to adjust its compatibility with certain web sites and networking behavior.
| Disable Plugin | Plugins (like Adobe Flash) are disabled. |
| Disable Java Script | Execution of Java Script code is disabled. |
| Language | The Language of the browser. Some web sites may recognize this language and display content in that culture. If left blank, the system language (culture) is used. |
| Proxy Server | If no direct internet access is available proxy servers for all protocols can be configured here. |
| User Agent | Some web sites (like Facebook.com) expect special keys in the user-agent string. The user agent string can be manually adjusted here. See http://www.user-agents.org |
The Process Settings allow Ventuz to run on a higher process priority or be processor affine. Microsoft does not recommend to change such process settings and let Windows manage the CPU core sharing with other processes. If you are aware of these concerns you can adjust some process related settings here.
| Process Priority | The Windows process priority. |
| Processor Affinity | Check the preferred CPUs (cores) to run Ventuz on. |
Enables the camera tracking from TrackMen 3D Tracking Solutions. This protocol receives multiple tracked cameras via UDP unicast or UDP broadcast.
| Port | The UDP port to receive tracking data |
| Studio ID | The Studio ID to filter the correct data from the correct cameras of a studio. |
| Multicast Address | If the tracking system broadcasts the UDP packets to the network enter the IP address here. If not leave this field empty. |
| Latency | If the tracking data arrives too early adjust an artificial delay here. |
| Timecode Display Format | Specifies the string formatting for timecode properties in Ventuz Designer/Runtime |
Configures the progress visualization type when Ventuz Runtime is launching a scene.
| Progress Type | Visualization can be set to either none, a grid of squares or a progress line at the bottom. |
| Color Encoded by Machine ID | Choose whether the squares and the line are colored according to the machine id or not. |
Configures Settings to monitor a running Ventuz Designer or Runtime
| Send Statistics via OSC (Legacy) | Performance Statistics will be broadcast via OSC in the legacy Ventuz 2006 format. |