Screenhack-old v. 1.0.1 README
Copyright (c) 2000 Michael Wouters <mjw@tip.csiro.au>
The RenderMan Interface Procedures and
RIB Protocol are Copyright 1988, 1989, Pixar
All rights reserved.
RenderMan is a registered trademark of Pixar.
I. What is screenhack?
II. Usage
III. Notes and limitations
I. What is screenhack?
Screenhack is a very useful tool for people wishing to add some life to their still models. It allows to create multi-frame RIB files from still scenes; you can specify actors (moving objects) as well as props (still ones) and other standard elements of the scene.
Unfortunately, you cannot manipulate meshes in any other way than:
- moving
- rotating
- scaling
It was written by Michael Wouters <mjw@tip.csiro.au> who is not working on this project any more. Last time when I heard from him he was working on a GUI version. The rest of this document was written mostly by him.
I <arturs@linuxpl.org> added Scale support and have more plans related to mesh deformation; basically screenhack should allow creating intermediate frames between (already prepared RIB's with) key frames. This, together with existing features, will make it an even more powerful tool.
II. Usage
screenhack file.scr [outputfile] [outputfile] is optional - otherwise a file file.rib is generated
A .scr file consists of blocks like
DSceneBegin
DCamera
DCamera
...
DLight
DLight
...
DProp
DProp
...
DActor
DActor
DSceneEnd
This metaphor was guided by the idea that a scene may have the same actors and props but many different camera shots ...
There are no format restrictions for a .scr file that I can remember. Some mistakes in .scr files will be caught but basically if you get a seg fault, the problem is in your .scr file.
Animation is done by specifying trajectories of actors. You can specify a trajectory by giving a formula (note: no spaces allowed in the formula ), a file of (t,x,y,z) coordinates or a list of coordinates in the .scr file (this is broken,sorry). Coordinates are interpolated with a cubic spline. The examples should make this clear.
III. Notes and limitations
Motion Blur is not working.
- DCamera -- Cameras
There are a number of basic camera shots
STATIC
PAN
ZOOM
ORBIT
DOLLY
STEADICAM - doesn't do much at present except jiggle the camera
unrealistically
The arguments taken by these shots should be evident from the examples.
Known bugs - the usual problem of a camera passing through the point it is looking at is not correctly addressed.
2. DLight -- Lights
The standard RM lights are supported and they are specified RM style except that parameters can be time dependent via formulae.
At the moment, you can only use formulae to specify time-dependence.
Haven't really tested this much so there may be bugs here.
3. DActor --- Actors
Actors are RIB fragments, assumed to be delimited by an AttributeBegin/AttributeEnd pair.
Note that actors can also have "spin"
"spin" has arguments [phi(t) x(t) y(t) z(t)] where
phi(t) is angular position
(x(t),y(t),z(t)) is the axis of rotation
Main thing undone here is automatic orientation of an actor
along its trajectory.
If you rummage through the source you will see references
to "particle" and "gas" types but these don't do much.
You can put a "tag" on an actor and then get a camera to look at that actor by specifying that it looks at that actor.
Another useful feature is "Scale". You can change the size of actors with time. You do it with size [x(t) y(t) z(t) 0] (the last argument is reserved).
The main thing missing here is a way of doing even a simple hierarchical animation - so screenhack is really only convenient for animating disconnected objects.
4. DProp -- Props
Props are just bits of RIB that don't move.
And that, alas, is all the documentation you are going to get since I am not working on this program any more.