That'd be an option, but I'm using UniMegaPov,  so I think I'll stick with
Ron's suggested pnm utilities.

Derek

Post a reply to this message

"D. Stark" wrote:
> 
> That'd be an option, but I'm using UniMegaPov,  so I think I'll stick with
> Ron's suggested pnm utilities.

If MegaPov 0.5a is enough for your needs, could you please check:
http://www.wozzeck.net/images/pmp
... and report bugs!

I am currently fighting against some remaining radiosity problems, and
hust added a new error reporting mechanism to avoid having master task
waiting for slaves which already have exited on error.
I will release a new build as soon as I'm feeling better with radiosity.
-- 

      __  __ __  __  _
|  | /  \  /  / |_  /  |/
\/\/ \__/ /_ /_ |__ \_ |\

Post a reply to this message

How does this compare to the RAM use of running 2 instances of POV? 2 instances
of POV seem a little wasteful, but at least a few megs of that ram is shared.
My SMP box only has 128 right now.  : )

Derek

Francois Dispot wrote:

> "D. Stark" wrote:
> >
> > That'd be an option, but I'm using UniMegaPov,  so I think I'll stick with
> > Ron's suggested pnm utilities.
>
> If MegaPov 0.5a is enough for your needs, could you please check:
> http://www.wozzeck.net/images/pmp
> ... and report bugs!
>
> I am currently fighting against some remaining radiosity problems, and
> hust added a new error reporting mechanism to avoid having master task
> waiting for slaves which already have exited on error.
> I will release a new build as soon as I'm feeling better with radiosity.
> --

>       __  __ __  __  _
> |  | /  \  /  / |_  /  |/
> \/\/ \__/ /_ /_ |__ \_ |\

Post a reply to this message

"D. Stark" wrote:
> 
> How does this compare to the RAM use of running 2 instances of POV? 2 instances
> of POV seem a little wasteful, but at least a few megs of that ram is shared.
> My SMP box only has 128 right now.  : )

I just upgraded to 256 because my IRTC entry features a lot of
objects...

To be more precise, there is a little overhead as long as you do not use
radiosity. If you do, be aware that there are not 2, but 3 octrees,
because the master process builds its own one as part of the sharing
mechanism. So, except if you have several tens megabytes in your octree
(which is not very likely), you won't see a big difference.

The main overhead concerns rendering time, which is higher than what you
would get with an accurately split rendering across your processors. On
my latest IRTC entry, rendering speed with 2 processors was about 185%
of the speed with one processor. But OTOH you will not have to worry
about load balancing, PVM will do it for you.

-- 

      __  __ __  __  _
|  | /  \  /  / |_  /  |/
\/\/ \__/ /_ /_ |__ \_ |\

Post a reply to this message

D. Stark <dms### [at] esupportnowcom> wrote:
: Does anybody know of a command line util that will cat together two
: images? I want to create a script that will render my image with two
: povray processes and put them together without having to open up the
: gimp and kludge them together by hand.

  I used this kind of unioning image parts in my distribution script. It
requires that the image parts are in uncompressed targa format.

mv ImagePart00000.tga $IMAGE
for FILE in ImagePart?????.tga
do
    tail +19c $FILE >> $IMAGE
done


-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

So that's a 19-byte offset on a targa? hrm, learned something new today. can
I have a peek at your whole script? I haven't finished mine, and I'm not
opposed to better ideas.

Thanks,
Derek

Warp wrote:

> D. Stark <dms### [at] esupportnowcom> wrote:
> : Does anybody know of a command line util that will cat together two
> : images? I want to create a script that will render my image with two
> : povray processes and put them together without having to open up the
> : gimp and kludge them together by hand.
>
>   I used this kind of unioning image parts in my distribution script. It
> requires that the image parts are in uncompressed targa format.
>
> mv ImagePart00000.tga $IMAGE
> for FILE in ImagePart?????.tga
> do
>     tail +19c $FILE >> $IMAGE
> done
>
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Note: All the computers must have a common file system (that is, they all
see the same directory where you are starting the rendering) and you should
be able to rsh to all of them without password prompting. These usually
occur only in local networks (so this script cannot be used, at least not
unmodified, to distribute the rendering over the world).
  Put the names of the machines in the HOSTS variable at the beginning and
the correct number of them in the HOSTSCNT (I know that it may be possible
to automatically count the number of words in HOSTS but I was lazy and didn't
search for info about how to do it).


#!/bin/zsh

POVEXEC=$HOME/povray/xmegapov
ROWSPERHOST=17
HOSTSCNT=3
HOSTS=(machine1 machine2 machine3)

### If this is a child process

if [ "$1" = "__SubProc__" ]
then
    echo "### Subprocess at `uname -n` starting rendering. (`uptime | sed
's/^.*average: //'`)"

    PART=$2
    FILE=$3
    WIDTH=$4
    HEIGHT=$5
    shift 5

    let STARTROW=PART*ROWSPERHOST
    while [ $STARTROW -le $HEIGHT ]
    do
	let ENDROW=STARTROW+ROWSPERHOST-1
	echo `uname -n` rendering lines $STARTROW to $ENDROW

	$POVEXEC -i $FILE $* -w$WIDTH -h$HEIGHT +sr$STARTROW +er$ENDROW -d -p -v +ft -o
ImagePart`printf "%05i" $STARTROW` >&/dev/null

	let STARTROW+=ROWSPERHOST*HOSTSCNT
    done

    echo "### `uname -n` done."

    exit
fi

### Else this is the main process

if [ "$3" = "" ]
then
    echo "Usage: $0 <pov-file> <width> <height> [<additional pov options>]"
    exit
fi

PART=0
for HOST in $HOSTS
do
    rsh $HOST "cd `pwd`; $0 __SubProc__ $PART $*" &
    PART=$[PART+1]
done
wait

echo "Joining image parts..."
if [ `echo $1 | grep -c '\.pov$'` = 1 ]
then
    IMAGE=`echo $1 | sed 's/\.pov$/.tga/'`
else
    IMAGE="$1".tga
fi

mv ImagePart00000.tga $IMAGE
for FILE in ImagePart?????.tga
do
    tail +19c $FILE >> $IMAGE
done

rm ImagePart?????.tga

echo "Done."


-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Btw, the script is not optimal. Every machine renders the same amount
of slices. If some machine ends rendering its slices, it just does nothing
although there would be more free slices to render.
  I did it in this way because making a 100% secure mutual exclusion by
using just a file system would have been a pain.
  Despite of this "unoptimal" algorithm, the total rendering time is
considerably shorter than with just one computer.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

"D. Stark" wrote:

> So that's a 19-byte offset on a targa? hrm, learned something new today. can
> I have a peek at your whole script? I haven't finished mine, and I'm not
> opposed to better ideas.

Not always. The header is usually a minimum of 18 bytes, but it can have up to
255 bytes of arbitrary ID string in the middle. Then also if it's a paletted
image, the palette will be in there too...

Post a reply to this message

Jon A. Cruz <jon### [at] geocitiescom> wrote:
: Not always. The header is usually a minimum of 18 bytes, but it can have up to
: 255 bytes of arbitrary ID string in the middle. Then also if it's a paletted
: image, the palette will be in there too...

  The uncompressed targa images created by povray have always a 18-bytes
header.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message