Overview
of Building Dive WorldsOverview
of Building Dive Worlds
There are several ways in which Dive worlds can be built and run. These pages will demonstrate most of these methods and hopefully serve as a reference for anyone who wants to go and build their own Dive worlds.
In each section I've tried to indicate at what the corresponding tasks in dVS might map onto.
Easiest way to include an object in the environment. Very portable since any tcl enabled application can load and run these objects.
Corresponds roughly to the dVISE level of programming (though you have the full power of tcl at your command, and access through tcl to most of the dive C functions).
Create the .vr and .tcl scripts. Load them into a world and let em rip.
EXAMPLES
The annotated patience game example is more complete and you should refer to the file format refence, the Dive/Tcl Behaviour Interface and the Dive/Tcl Reference Manual.
The world is the basic unit of a shared environment. Distribution is done per world and they serve to collect relevant objects together.
Roughly corresponds to a dVS world (or mazfile).
Worlds are defined in much the same was as objects. There is a world data structure that gives all the relevant information.
An annotated world file, with a discussion of various issues.
A dive application can access a running dive database and use all the functionality of the dive libraries to manipulate it. Example applications include vishnu and clock .
These applications roughly correspond to dVS Actors, vishnu being similar to the visual actor and the clock to an application actor.
The directory build contains example code and makefile. You need to link your application with the dive libraries and after set up and callback initialisation (if any) you call the Dive C functions directly.
The complete instructions for building and running a simple application are given in the annotated clock example.
Applications talk to Dive through a high level interface that speak DIVE/TCL commands. Difference to above. A dynamic way of extending a Dive actor.
No analogy in dVS.
This one is simple.
Clock example.
Vishnu is just a complicated DIVE application. Loads up a TCL description of the interface and creates a couple of new functions. Might want to add new buttons to the interface, or set preferences.
Roughly corresponds to modifying the behaviour of the visual actor and body actors.
Preference setting. Vishnu's TCL description is loaded from vishnu-init.tcl. This can be customized and used with the -initscript flag.
The London Demonstrator and Acting Rehearsal demos are both good examples of applications that use the diva process with alternative (and dynamically reconfigurable) desktop user interfaces
If you want to add a visual application with *very* rapid response to behaviour that needs to be represented in C code. Plugins allow you to add C functions to Diva in a very flexible way. You can register tcl functions within the actor interpreter for example, or extend the user interface on the fly.
The Dive3.3 distribution contains several examples of plugins.
EXAMPLES
Eventually this section will contain a link to an annotation of the face plugin.
If you want to add a visual application with *very* rapid response to behaviour that needs to be represented in C code. If you have a C process that connects to the Dive database which responds to user input, then the lag of the database might be too high for critical applications. If you have Dive3.3 then you would write a plugin instead.
The FULL Dive distribution contains the libraries and headers that are sufficient to recompile Diva. You can compile a special Diva that uses the Dive C library to register interest in events and control the world like you would with a normal C process. It has the advantage that it renders a view and thus visual events are processed and displayed immediately.
EXAMPLES
Mike's 3D sculpting system - using a separate process the swept surface woud take too long to appear.