#!/bin/sh

# Render a rotated red cube
#
# Before execute: chmod +x rot_cube.sh
#
# Runs projector from source (no installation required if this script is
# run from doc/tutorial)
PROJECTOR=../../src/projector

(
# Create a red cube scene as we always do (see red_cube.pro)
echo '
obj "foo"
	ambient 0.5
	diffuse 0.5
	color red
	cube

cam 1 2 3   0 0 0
light 1000 2000 3000
'

# infinite loop for generating new rotatio values and frames
while true
do
# increase rotation angles; don't worry if they go above 360,
# projector handles that correctly
	rx=$((rx + 1))
	ry=$((ry + 2))
	rz=$((rz + 3))

# transform the object and show a frame for 0.05 sec (20 fps)
	echo "obj \"foo\" mat rotx $rx * roty $ry * rotz $rz"
	echo "renderdelay 0.05"
done
) | $PROJECTOR



# Note on flow control: it does not matter that the shell loop produces the
# obj/renderdelay commands faster than 0.05 seconds. It will work ahead
# as projector is not reading while in renderdelay, it is consuming
# input slower. The pipe (shell |) between the two processes is really a
# fifo buffer in memory with a specific limited capacity, e.g. 4k or 8k.
# Once it fills up, the next echo will be blocked until projector consumes
# some of its input. Thus the usual UNIX pipe flow control works as expected:
#  - projector always has something to read so the actual FPS is really
#    determined by renderdelay
#  - when the script is blocked, it is not consuming CPU
#  - so the script is always working ahead a bit to make sure projector can
#    run smoothly