Code Intro
From Moviesandbox
If you're looking for the old CodeIntro, that page has moved to UT2k4_CodeCentral.
Contents |
(important) classes
- Renderer - takes care of shadows, FrameBufferObjects, Overlays, textures, etc. Does not do a very good job in sorting, no real scenegraph yet. Holds a vector of all actors and buttons. Calls setup and update functions. Initialises all known objects for later lookup and type inspection
- Input - takes care of all Input and callback functions, also holds mouse functionality, save-directories, scene save/load.
- content - a convenient way of creating and initialising everything that's supposed to be created on startup.
- actor - base class of all objects (including buttons) saves/loads itself (called from Input, or other places. Draws itself (called from renderer).
Random blurbs that need structure
Particle Systems
- transparency right now is binary (transparent pixels get pushed to z=100000 in Pixelshader)
- ParticleScale is being transferred as particleLocation.w to save shader bandwidth
Actor to Actor References
Integer numbers that reference the location of an actor or button in the Renderer::actorList or Renderer::buttonList.
So far this is used for key-frames and attachments. This way they can be easily serialized to XML when saved. But we need to be careful when we change the actorList!
- when deleting, always call checkReferences on Actors!
- always be mindful of the function checkReferences when buttons/actors reference something!
--Fiezi 23:15, 5 June 2008 (MEST)
OSC message control
Did you know Moviesandbox can be remote controlled?
All you need to do is set up a UDP connection, get a Port and then post a valid OSC message.
The idea is to follow this sequence:
- request a new UDP connection on the main UDP channel/port
- receive all relevant object names, setup instructions, etc. /should these be updated regularly through the main UDP channel?)
- keep listening on the MSB broadcast port (this is where all clients are listening)
- setup a connection on the new port
- send a /select message to select an actor you would like to work with
- send a /set message together with the name of the property you would like to set
- send a /get message together with the name of the property you would like to get
- send a /function message to call a function on the object (still have to figure this one out...)
OSC message implementation
The two classes to watch here are UDPInput and Pilot.
The UDPInput is the main class that creates a specified Pilot class depending on the type of Input we are expecting (TUIO or general OSC).
The Pilot class is created as a seperate thread.
Pilot parses the OSC Message and looks for data types. Current supported datatypes:
- vector3f
- float
The structure of the OSC message is "/pilot/datatype/datatype/... arg, arg, ...
