Expo System
ShadowVision
- Basic Shadow Tracking Video: video
- Bounding Boxes: Information we will pass to the Flash Viz Engine in order to visualize objects corresponding to the shadow shape.
Constraints for reliable camera vision:
- no exposure to daylight (-> "tunnel")
- interior materials which inhibit reflection of the projection light (-> black interior)
Measurements we will track around a person
- standing 120 cm away from the projected image
- tiptoes in 100 cm distance from the projected image
- 90 cm width
- 240 cm height
Camera will be mounted on 240 cm height.
- UPDATE: Current State (25.01.2010) of MediaWall
- projected image: 250cm
- distance from floor to lower edge of projection: 19cm
- size of illuminated floor from player to projected image: 100cm
Mockup
Der Mockup ist im Project Space der Media Computing Group gebaut worden.
Hardware
Logistik für Transport nach Shanghai organisiert CAAD.
Voraussichtlich europäische Steckdosen im DuC Gebäude.
Projectors
chosen projector: PDT4000
The projected image will be 1.8m*1.35m, 2x for each module placed vertically (width 1.8m, height 2.7m)
The amount of modules depends on interior design constraints.
Our requirements for the projectors:
- Distance between the backside of projector and projected < 180cm
- Resolution: XGA
- VGA Connector
- Network power on/off
- Brightness > 3000 ANSI lumens
- Contrast > 2000:1
- Light bulbs need to last for a constant usage of 14h/day, 60 days
Video cameras for ShadowTracking
- NET Foculus FO323SB
- BW camera
- 1/3" CCD chip
- progressive scan
- C-Mount
- Format 0
- 640x480
- 60fps
- Format 1
- 1024x768
- 30fps
- Format 2 not supported
- Format 7
- 1024x768
- 36fps
- NET Foculus FO134SB
- BW camera
- 1/2" CCD chip
- progressive scan
- C-Mount
- Format 0
- 640x480 (resolution too low)
- 60fps
- Format 1&2 not supported
- Format 7
- 640x480
- 86fps
- NET Foculus FO234SB
- BW camera
- 1/2" CCD chip
- progressive scan
- C-Mount
- Format 0
- 640x480 (crop out!)
- 60fps
- Format 1&2 not supported
- Format 7
- 780x580
- 63fps
- NET Foculus FO134SC & Foculus FO234SC
- 1/2" CCD chip
- progressive scan
- C-Mount
- color cameras
- outputs Raw Bayer Pattern which is converted by software
- colors are depicted badly without correct conversion algorithm
Lens for video camera
- NET L-SV-0514MP lens (focal length=5mm)
Light control
- DMX Mulitdim MKII.
Setup
- Use “Mode” button to switch into DMX mode. display:”A001”
- Use the Arrow Buttons to set address.make sure that it is adress 1(A001)
- Use “menu” button to set channel CH:04 set to 4 (using arrow buttons)
- Press “menu” again S1oF use the arrow Keys to set switch mode all to off: S1of,S2of (use “menu” to change between switch
Summary:
When you press menu several times, you should see these
- A001
- CH:04
- S1oF
- S2oF
- S3oF
- S4oF
Cables and other hardware
- Network cables (for both projector and computer)
- VGA or DVI cables (depending on positioning of computers)
- Firewire 400, to be checked
- audio cables, not decided yet
- switches
Audio Hardware
- probably stereo speakers for each module
Computer
- 1 MacMini als Server, (Maus und Tastatur)
- 4 MacPro (Standardkonfig + 1 Grafikkarte GT 120, 512MB), Module für Beamer Rückprojektion
- NVIDIA GeForce GT 120 with 512MB of GDDR3 memory, PCI Express 2.0, one Mini DisplayPort, and one dual-link DVI port
- 5 x MiniDisplay-> DVI Adapter 10 x MiniDisplay-> DVI Adapter
Touch screen
- Hardware Constraints
- Compatible with Mac
- Non-capacitive screen to reduce interference from nearby metal.
- Wall-mounted
- Installation Constraints
- Hide screen from the public
- Lets the game master see the screen while can see how players are doing
- Info: Why do we need a touchscreen VS iPod Touch
- Candidates: 12" Touch screens:
- Elo 1215L and 1247L, each 500 Euro
- GVision P12DS - JA, 460 Euro
- Sinocan T06-12OF, no price info yet
Software
UML Diagram
State machine
- State machine for game interaction: file name: "Game state machine" in oliver folder
- State machine for server: file name: "Server state machine" in oliver folder
Game ID
the game ID scheme is a string:
yymmdd.hh:mm.#
e.g.
- 100113.08:00.1 ---> first game of the day at 8 AM
- 100113.18:00.135 ---> 135th game of the day at 6 PM
This game ID is:
- unique
- not random
- include the date and time information
Game ID will be associated with icon and color based on a pre-defined scheme.
We will use only the counter part of the game to match with the icon and color.
For example, when there are 4 combinations of icons and colors: A, B, C, and D
- 100113.08:00.1 --> A (the first game of the day )
- 100113.08:00.2 --> B
- 100113.08:00.3 --> C
- 100113.08:00.4 --> D
- 100113.08:00.5 --> A
- 100113.08:00.6 --> B
- 100113.08:00.7 --> C
- 100113.08:00.8 --> D
Game server and game module communication protocol
(additions in 21.01.10 are in orange, deprecates are striked through see: {file name="100121 Scoring.pdf"} for scoring scheme of electricity and water phase)
The message will be exchanged using NSDictionary objects. All constants are defined in: XPSClientConstants.h (svn). The communication is done through ThoMoNetworkingFramework over the protocol named in kXPSProtocolName constant.
Every message have a type (kXPSMessageTypeKey). The possible value of this entry is one of:
- Server -> client
- kXPSMessageTypeGotoState
- kXPSMessageTypeElectricityScore
- kXPSMessageTypeWaterScore
- kXPSMessageTypeShutdown
- kXPSMessageTypeResetProcess
- kXPSMessageTypeDuplicateClientId
- Client -> server
- kXPSMessageTypeQueryState
- kXPSMessageTypeBuildingFeature
- kXPSMessageTypeElectricityFeature
- kXPSMessageTypeTreeFeature
- kXPSMessageTypeWaterFeature
Server -> client
Every message from server -> client (except ResetProcess and Shutdown) will have the following entries:
- State that client should go to/be in (kXPSMessageClientStateKey)
- the value is NSNumber instance that have intValue as defined in XPSClientState type.
- Game ID (kXPSMessageGameIdKey)
- the value is NSNumber that have unsignedIntValue
Goto state message:
(message type: kXPSMessageTypeGotoState) the state is compulsory, so there's nothing more here.
Score messages
Electricity
Water
Maintenance messages
- Shutdown: (message type: kXPSMessageTypeShutdown)
- Reset Process: (message type: kXPSMessageTypeResetProcess)
- Client have duplicate client ID: (message type: kXPSMessageTypeDuplicateClientId)
Client -> server
All messages from client must have kXPSMessageClientIdKey key and value must be NSNumber: 1 for the leftmost module, the nest one has ID 2, and so on. Client must send kXPSMessageGameIdKey that got from the server at the current game.
Message types are:
- Query state: (message type: kXPSMessageTypeQueryState)
- Building feature:
- Electricity feature:
- Tree feature:
- Water feature:
Game server and web server communication protocol
For each game, an XML file will be sent to the web server. The structure of the XML file looks like the following figure.
Example file: {file name="ExampleMessageToServer2.plist" desc="ExampleMessge XML to server"}
The file is a serialized pList in XML format. The file contain a dictionary with two keys:
- kSHSMessageGameIdKey: Game ID (string) as described here
- kSHSGameScoreArrayKey: an array. Each element can be either:
- string "kSHSMissing" which means that the module doesn't sent the score to server, so there's nothing to send to web server for this module.
- OR a dictionary containing the following keys
- kSHSBuildingIdKey: a string ID (or URL from Jens) of matched building.
Giveaway Client
The giveaway client pretends to be another SHSClient (ID: 9). It response to the kXPSMessageTypeGamePaused and kXPSMessageTypeGameResumed message.
It sends a message to Flash application using the same network configuration as in SHSClient. The {file name="gamePauseMessage.plist" desc="message example"}looks like the following figure.
- kXPSMessageGameIdKey: String of game ID
- kXPSRemainingTimeKey: remaining game time in seconds
- kXPSGameIsPaused: is TRUE when the game is paused
- kXPSIsConnectedToServer: is TRUE when the giveaway client is connect to server. This flag indicates whether the timer is updated according to the server or just an estimate time.
Game Client -> Flash
Flash visualizer communicates with SHSClient using protocol named "shsFlashComm" (Flash doesn't have to care about protocol name.).
A Flash visualizer shows the result for one module (2 players), so there will be two Flash per machine. The Flash for the left and the right player listen to port 8624 and 8625 respectively.
Flash will get the following messages in XML format.
- go to state message is sent every time the state changes. Here is the list of possible state names
- building feature is sent in building states
- electricity feature and scoreis sent in electricity states
- (to-be-defined) tree feature
- water feature and score is sent in water states
The anatomy of message looks like following figures.
Go to state message
Building feature
Score and feature message (electricity and water)
5/6-point message to Flash5-point message (trunk)
6-point message (only in Chat’s computer and a separate folder in mockup)
