This beauty will most likely be available with the next release of Ventuz 3.

The quality of the 3M is quiet nice. On very bright backgrounds we noticed  cross patterns. Maybe this grid will disappear within the next LCD releases. But so far a pretty cool solution for a up to 20 finger system….

“Interfacing Technology”

What’s that? At the end is a simple feature, but it’s very very powerful to increase the modularity of Ventuz drastically. Collaborative work becomes much more effective than ever before. Interfaces are some kind of Exposings whose remain existent if you delete the actual content of a container. This enables you to divide the actual logical work from the design part because you could define a ‘communication’ interface with a container upfront and ‘implement’ the actual content later. Of course you can exchange such content easily or drag&drop the content from one container to another – without losing the bindings!

Another big feature: Scene Ports act now ‘like’ containers and of course, they can have interfaces! Because of that Cross-Scene-Bindings are now possible!

You will love it – because we already do! 

Feel free to download Ventuz 2008 R5.24 RC1 now and don’t hesitate to use it. The official release is planned shortly (may be next week). The 2 weeks of testing with hundreds of scenarios were successful that we think it’s time to reveal this technology to you!

We prepared a Whitepaper for R5.24 (PDF) to help existing Ventuz users to get faster into the new features.

Download Ventuz 2008 R5.24 RC1 x86 or Ventuz 2008 R5.24 RC1 x64

Expect also many other nice features (like node navigation) and bug fixes in R5.24

Have fun!

Your Ventuz Development Team

—

Ventuz Release NotesVentuz 2008 R5.24

Stay tuned!

Our internal working title of this version was “The SM-Version” where SM doesn’t mean what you might think… it simply means: Scene Management

Why did we change the ‘old’ scene management?

In the previous versions of Ventuz the scene management had several problems and insufficient features. Also, the ability to split several parts of a show into smaller pieces, what scenes were initially meant for, did not fulfill the requirements. The previous approach of the “Scene Reference” didn’t help that much. The main issues were:

• Asynchronous load of scenes was not possible. The renderer stopped while loading sub-scenes.
• Multiple instances of the same scene in memory couldn’t be handled properly (remoting)
• Nested scenes were not exported correctly.
• Reference scenes couldn’t be edited on-the-fly. You only were able to open another instance in the Ventuz Designer, edit it and “Save & Reload” the scene into its referencing node.
• Blocking a scene reference didn’t really save performance, because the entire logic inside still kept working (like animation, movers, etc)

What’s new?

• The Scene and Slide Reference nodes have been replaced by the Scene Port and Slide Port node.
  A Port node can hold a scene and is able to render the scene as it was “inside” the hosting scene. Hierarchy nodes like Axis, Color, etc can affect the sub-scene.

  

• The main features of ports are:
  • If a Port is blocked by its Blocked property or by another parent node (alpha, switcher, etc) the scene gets inactivated and the internal scene logic is turned off. The performance saved on CPU is fantastic!
  • A Port can reference a scene by its name (URL), but also can reference a scene from memory. The remoting is able to load a scene and assign it later to Ports. This technique will allow us to switch or cycle scenes between ports in later versions of Ventuz.
  • A Port can be “locked”; that means the remoting or the new Stage Editor (see below) is not able to change the scene-to-port assignment. You can either lock a port by checking its “Lock” property or simply bind the File property to a data source (e.g. URL node or Excel)
  • Ports can load scenes asynchronously (in background). A “Progress” value from 0% to 100% informs the hosting scene about the load progress. The Port also provides a “Loaded” and a “Failed” event  to trigger certain stuff inside the hosting scene (like a fade in/out animation)

• Every Scene can have an unlimited number of Scene Ports to “host” sub-scenes. We call the level of nested scenes the Scene Level. The scene level you usually work with is “Level  1”, the next lower level is “Level 2” and so forth.
• Every Scene Port has a name (the normal node name) and an ordinal number starting at zero. This number is used to address ports within a scene via remoting. It is also important for “Layout Scenes” (see below)
• If you open a scene currently assigned to a port, you can edit it on-the-fly! This makes modular work really easy!
• Within the Ventuz Designer you can edit the exposed properties of a scene. A real “inter-scene-communication” does not exist yet. This will be the next step of development (see below)

The new Stage Editor

When working with nested scenes and remoting, you easily could lose the overview of which scene is rendered where. That’s why we developed the new Stage Editor (Ctrl-F12):

This Editor allows you to see all scenes in memory along with their available ports. Scenes can be loaded by the Ventuz Designer, by a Scene Port or by Remoting. The editor is again a tree view like you already know from the scene hierarchy editor. Drag&Drop makes it easy to assign scene to ports and track assignment changes via remoting. The scenes currently opened in the Designer as well the current scene are visually marked in the Stage Editor.

Inside the Stage Editor you also can switch and select the Layout of your current project (see below). It also allows you to temporarily change the MachineID for your local machine for testing cluster setups. Both features (layout and ID switches) are also accessible via keyboard shortcuts.

The editor is quite simple and has no “hidden” key shortcuts for special operations. Only Drag&Drop and the toolbar on top! Click and Double-Click on Scenes and Ports start some logical actions… try it out!

Advanced Layout Scenes

The new Scene Management allowed us to implement a very powerful new feature called Project-Layouts or Master-Scenes. A Layout is a scene loaded with your project before your first “user-scene” on Level 1. Layouts are placed in “Level 0” and can be used to create complex scene setups like multiscreen, stereoscopic, cube-projections, layering, etc. The big advantage of using layouts is that you don’t need to mess around with this setups anymore! Let Ventuz create Layouts for you (future versions) or let your Ventuz-Guru create the stereo-setup. You simply place a single sphere in your Level 1 scene – that’s it.

In the past, the “guru’s” created the “scene head” and provided a blank scene to the actual content designers. The new Layout concept separates the idea of layout, content and sub-content!

Layouts are simple scenes holding at least one unlocked scene port, preferable port ordinal 0 (the default port) is not locked. A layout scene is a normal scene:  you can use all nodes, externalize properties and insert layout related content.

The possibilities of layout are massive:

• A split layout with two ports (left and right) by using two relative viewport nodes splitting the screen in two parts.
• A layered scene layout: imagine three ports, background, content and overlay!
• An effect-layout making a standard glow and mirror rendering!
• …

Configure the layouts in the project settings dialog by accessing the new “Layout” config page:

Create a layout setup by selecting “new”. Enter a layout name and select the actual layout scene file. The fields “description” and “icon” can be used to help a user of your layout to work with it.

A very important feature of a layout is to override the actual rendering and screen settings of your project. In the D3D Overrides tab, you will find a small checkbox on every configuration group. If you check that box you can setup new values for each particular layout:

Imaging you setup a multi-head projection with two Ventuz machines with two outputs each. In such a case you could create a “preview” layout showing you the entire 4-screen-stripe, a “production” layout showing the actual content of one Ventuz machine depending on the machine ID (left or right).

Export Scenes and Projects

Inside the Ventuz Designer all layouts of a project are loaded in memory to allow the user to switch between them whenever (s)he wants. The Ventuz Presenter/Runtime only loads one layout and doesn’t provide the ability to switch layouts during production!

If you export scene / projects to archives, please notice the following

• Export a scene to VZA (Ventuz Design Archive)
  VZA exports stores the current open scene of the Designer into an archive including all nested scenes and their resources. Resources can be deselected in the resource dialog during export.
• Export a scene to VRA (Ventuz Runtime Archive)
  VRA exports does the same as an VZA export, but all exported scenes are written in runtime format (.vrs – Ventuz Runtime Scene). All required resources are included as well.
• Export to VPR (Ventuz Presentation)
  A Presentation export does not export the currently opened scene anymore! It actually exports the current layout setup, which means the current active layout with its complete current port assignment! So don’t forget to select the correct “production” layout before exporting a VPR!
  If you need to add more scenes to your VPR, you can use the Resource Linker node to embed more scenes in your presentation. The main-scene, could decide which scene to load during runtime!
• Export to VZD (Ventuz Director)
  A Director is a special form of the Ventuz Project file allowing the Presenter/Runtime to startup. If you export a Director the current active layout is “marked” to be the “production” layout of that Director. You also will be asked to export the current layout as a Runtime Archive VRA with the difference to the normal VRA export that no nested scenes are included in that export.
  A change to the Ventuz Presenter/Runtime allows to “auto-import” Ventuz Runtime Archives even if they are “beside” the director file instead of being stored in the AutoImport folder, because this folder might not exist on the first startup.
  The new auto-import also imports all found VRA files before (!) actually initializing the renderer and layouts.

What’s also new in R5.20

• There is a new “Rectangle Rounded” geometry node. Check it out! It’s powerful for borders and frames, but also for rectangular soft shadow. Have a closer look to its texture mapping options.

  

• The Render Target Node has been extended to select “Project” for its Multisampling Quality. In that case the Project settings are used, probably overwritten by the layout setting.
  The RT can also perform a “Render-Once” mode. This mode can be used to render textures of content which doesn’t change (pre-compose) or generate thumbnails of your sub-scenes!

Roadmap for Ventuz 2008

1. Interface Containers
   This feature will allow you to define a bind for properties, methods and events at a container without (!) having any content inside that container. The actual container-content defines the actual functionality by exposing properties, methods and events. As long name and type of those “interface members” matched the containers definition (hull) this members get bound.
   This technique will allow you to change container content (by drag&drop) without the need to re-bind the outer communication!
   The same technique is used to “talk” to nested scenes as well. Your master scene could call the “Start” method on a port. As long the nested scene exposes a “Start” method, the trigger will do what you expect. Ventuz becomes really modular!
2. Symbols
   The mechanism of “externalizing” properties will be enhanced that way, that other properties in your stage (bulk of nested scenes) can access these externals. You can create real “variables” or “parameters” or exchange information across all scenes without the need to bind them!
3. Remoting SDK
   The new Scene Management required a revision of the entire remoting as well; otherwise the new features weren’t accessible at all. The new Remoting server is already running and exposed to .net-Remoting, but not officially “released” to be used.
   The old remote interfaces (CLI, Vertigo, OSC, .net remoting 1.0) have been adapted to the new remoting layer and should work as they did before, without accessing the new layout feature!
   The upcoming SDK will provide the ability to implement your own remoting interfaces. The CLI, OSC and Vertigo remoting will get a new version each to make to new features (ports) usable for them.
   Another important reason why we changed the remoting is that the importance of cluster remoting came in focus faster than we thought. Therefore the new remoting allows asynchronous execution of each command. All commands can be scheduled and queued by assigning a timestamp (cluster-clock). The Cluster-HUB will be part of the remoting SDK for synchronizing the external control of multiple Ventuz Machines in a Ventuz-Cluster.

Don’t worry to test the R5.20!

Due to the massive changes in the Ventuz core, content saved with R5.20 can’t not be loaded in any lower version anymore: Scenes, Projects and all Archives

R5.20 has been tested for weeks and some customers are already producing with it. Our latest exhibition shows (Best Of Events, Dortmund and Integrated Systems Europe, Amsterdam) were build with that version without any problems.

Anyway, big changes popup new issues. Areas where issues could appear:

• Export of VPR Presentations and other archives
• Remoting, especially VertigoXMedia and OSC, async callbacks
• Launch of very, very complex nested scenes with nested async loads

Our current development focus is on releasing the R5.20!

The reason why we have a “Release Candidate” is to give our customers the chance of influence on issue as soon as possible!

If we do not get feedback from your side we consider this version as “accepted” and will release and support it as usual. So, please don’t hesitate to download and install R5.20 RC1

We appreciate your comments and bug-reports!

Your Ventuz Development Team!

DOWNLOAD R5.20 RC1 HERE!

R5.19 is coming with that new feature and many bug fixes – don’t hesitate to update!

Cheers

Just doing some development towards a 64 bit version of Ventuz. It´s already working as you can see above but there are still some issues to fix. A 64 bit version will give you the possibility to use more than 1.4 Gb memory for the Ventuz process. But don´t expect to build scenes with a million nodes that run smootly. The Garbage Collector of .Net might upset your plans.
If your scene gets really big Ventuz will hold a lot of objects which have to be inspected by the GC. This might cause render stalls. But you can use more and bigger resources. If your graphics cards has 4 GB you can use a lot of images and textures in your scene, highly tessellated models etc… YEAH – no problem!
Unfortunately some APIs that Ventuz depends on have no 64 bit version. For example Quicktime. This means no QT in the 64 bit version of Ventuz as long as the guys from Cupertino are not able to build a 64 bit version of Apple Quicktime.

1. Content Families
   The new ability to “group” nodes in the content editor as “Families” helps to keep nodes together.
   Automatic layout won’t shuffle your nodes anymore…
   Also a seamless zoom is available by turning the mouse wheel.
   

   Content Families

2. Clip Control with duration
   The animation editor can now display controlled clips (QT, Audio, Sound and Sound3D) with their duration. Also the actual start offset can be adjusted!
   

   Clip Control in Animation

3. Entirely revised Screen Shaping Editor
   Features like Keystone, Corner Pinning, Scaling, Rotation, Gamma Ramps on soft edges and several test patterns are now available!
   

Expect the official release beginning of June 2009