Dynamics Engine - use and misuse

Yon has completed a version of the Dynamics engine, based upon his proposal in the TechSpec document. It seems to be quite robust. A working version with a small state space designed for the Great Yarmouth Txoom implementation is available at http://f0.am/cgi-bin/cvsweb.cgi/tx-code/dynamics/eerm/ Unfortunately it seems that the external cannot be downloaded directly to a Mac system to be used, one must set up the whole CVS shamozzle to enjoy it. See Using CVS for notes.

This collection of notes should help in understanding how to use and misuse it, to get the sort of responses and behaviour that we want. I hope we can develop some silly examples to demonstrate what to do, and some interesting things too.

This document is full of presumptions and questions, some of which will be solved by code reading, some by Yon, some by experiment. I hope I have noted them all sufficiently. Please help by repairing them!

The eermMax object is a binary Max external. It has five arguments.

  • int (maximum ?) number of nodes
  • int maximum number of simplices
  • int number of tokens
  • int The size of the input data vectors.
  • float Initial Dt value

Inputs are:

  • configuration files (see below) which are input as messages
  • data streams as named vectors (see below) (i.e. also messages)
  • bang as a time step
  • other messages: PostTokens, PostSimplices, etc

Outputs are:

  • Positions of tokens in pX/NodeName [value] form
  • Some things seem to go straight to the Max window
  • is that it?

Make sure that the arguments to the eermMax object are consistent with the numbers in the config file, or initialisation messages.

  • nodes
  • simplices (a collection of nodes, the space between them)
  • transitions between simplices
  • features for attraction at nodes - mean and variance
  • potential is read but not used
  • dynamics model (Spring works, InverseSquare (gravity) doesn't)
  • tokens (player position)
  • token start positions (simplex and position thereon)

All simplices must have the same dimension. In order to simulate a simplex of lower dimension, nodes can be made to be nonattractive by defining its variance to be very low (e.g. 0.00001). On the other hand, a high variance will allow a node to attract a token strongly when the sensor data matches the feature at that node.

The following messages are used to tell eerm what to do, how to do it, and when. Most of them only make sense to be done once, setting up the state space as a collection of connected simplices. One set up, probably the only thing to do dynamically is to keep sending bangs to make time go forward. Perhaps it is possible to directly reposition a token when some external events force this. The first messages are useful ongoingly. (that is not a real word).

Take a step forward. Do shit. Spit it all out.

Tell the Max window what the structure is.

Tell the Max window where everything is. Or is this via the outputs?

Create a node. Each node must have a unique index, an integer, starting at zero. The name is used later. Is case significant? Example:

NodeSetLabel 1 feed

Create a simplex. The length of the list of node names defines the dimension of the simplex. At the moment it is necessary to name the nodes in ascending index order. Failure to do so leads to a max crash. Example:

SimplexNew FSE feed spawn extrude

Define the transfer probability of moving from simplex1 to simplex2. The prob should be a float between 0 and 1. Presumption that eerm matches the common faces of the simplices together, and reacts when the token hops over the side. Example:

SimplexSetTp FRE FSE 1.0

Here we are using a probabilty of 1.0 to ensure that the surface is proper. If we had three 3-simplices coming together along one edge, then we would need to define probabilities of transfer between them all. Question: are there probabilities allowed of transfer back to the same simplex? This is the default behaviour (when no transfer probability is defined along an edge). Check to see whether this remains as the default with varying probabilities as we change the other transitions probs.

  • NodeSetMean [nodeName] [list of mean values]
  • NodeSetVar [nodeName] [list of variance values]
  • NodeSetPotential [nodeName] [float]

Defines the feature for a node. A feature is meant to be a collection of input data values, defined by a mean and a variance. The length of the list of mean and variance values is defined in the eermMax arguments. This mean value is used to determine the force of attraction of a node to a token on an involving simplex dependent upon the closeness of the data values to the mean. The variance determines how strong the attraction will be: extremely low values means little effect, high values mean it will be a strong effect. Experiments suggest that values differing by a factor of 10^6 leave the smaller variance node alone.

Example:

NodeSetMean intrude 0.5 0.5 0.5 0.5 0.5 0.5 0.5 0.5

NodeSetVar intrude 0.001 0.001 0.001 0.001 0.001 0.001 0.001 0.001

NodeSetPotential intrude 1.0

Defines a new token with the given name.

  • TokenSetSimplex [tokenName] [simplexName]
  • TokenSetCoord [tokenName] [vector of position]

Defines the starting position of a token on the state space. First a simplex must be defined. The position vector is a list of positive floats summing to 1.0 - the number of entries should correspond to the number of nodes in the simplex, that is, the dimension of the space within which the simplex lies. Example:

TokenSetSimplex p2 FSE

TokenSetCoord p2 0.8 0.05 0.15

Set the dynamics model. The models Spring and Gravity (i.e. inverse square) are defined. Gravity is buggy (dec 2002), do not use it.

Set the time Step. Used in making a config and also in real time.

Set the slew. Check up on this. Used in real time.

The data inputs to the eermMax object consist of the token name (as defined in the configuration) followed by a list of floating point numbers defining the input vector.

Presumption: values should be between 0 and 1, as a float.

It is advisable to use the pak object or somesuch to force the passing on of all changes in the data vector to the eermMax object.

Q: do we need to keep sending the values, or is the last received value use by eermMax every time it gets a bang?

It is not possible to reload an eerm definition, so close patch and reload. There cannot be two eerm objects simultaneously (global variables).

– TimBo - 19 Dec 2002


Libarynth > Main Web > ProjectTxoom > ProjectTxoomSystem > ProjectTxoomNotes > DynamicsEngine r8 - 25 Aug 2003 - 14:54 -


  • dynamics_engine.txt
  • Last modified: 2007-06-09 11:31
  • by 127.0.0.1