Warp wrote:
> Charles C <nomail@nomail> wrote:
>> Or, here's another approach:  Let all machines go at once & let SDL create "flag
>> files" and either render blank (read "easily sorted out") images or real frames
>> depending on whether a given frame number's "flag file" exists already or not.
> 
> http://en.wikipedia.org/wiki/Race_condition#Computing
> 

:-D It's a 'practical' solution to distributing frames using a simple 
SDL-only approach, not a 'theoretically ideal' solution...

Rendering 5400* frames of "Psychedelic Scrambler"  over about 23 odd 
days on a handful of processes resulted in maybe 2 or 3, mayyyybe 4 
duplicate frames rendered and no apparent file handling errors on the 
part of the NAS that contained my shared directory.  While I had systems 
restart or crash in the middle, iirc as far as I could tell the times 
didn't correspond to the same frame being rendered on multiple machines. 
OTOH, who knows.

*plus about a day's worth I accidentally deleted.

Charles

Post a reply to this message

StephenPope wrote:
> I'm still looking for any comments at all about alternatives to POV-Ray.

I guess this is a bit of a biased crowd. I think you forgot to ask 
"What's the best raytracer out there?" :-)

Anyway sorry I can't be more help.  I don't have any real experience 
with the alternatives and I bet I'm not alone in that.  Hmmmmm.  Based 
on your wanting a powerful SDL, I'm guessing being limited to polygon 
meshes isn't going to work for you?  That knocks out a few.

Post a reply to this message

> I'm afraid you will probably have to compare them yourself; such work is
> time-consuming and very scene-dependent, and so quite rare.

There is a comparison of various renderer on a simple scene here:
http://www.winosi.onlinehome.de/Gallery_t14_01.htm

But they are not all raytracers, and it would take some time to 
investigate on the scene description language of each. And some may be 
outdated... POV for example is not at the latest version.

-- 
Vincent

Post a reply to this message

Vincent Le Chevalier nous apporta ses lumieres en ce 2007/11/05 04:05:
> Tom York a écrit :
>> I'm afraid you will probably have to compare them yourself; such work is
>> time-consuming and very scene-dependent, and so quite rare.
> 
> There is a comparison of various renderer on a simple scene here:
> http://www.winosi.onlinehome.de/Gallery_t14_01.htm
> 
> But they are not all raytracers, and it would take some time to 
> investigate on the scene description language of each. And some may be 
> outdated... POV for example is not at the latest version.
> 
The main problemwith that comparison is that every samples where done on 
different machines with wildly varying specifications: pentium III and IV, 
athlon, single, dual processors, maount of RAM, CPU speed,...

WinOSI: P4 1.7GHz
Whire Frame, OpenGL, BMRT, Perceptuum, Radiance: CPU and GPU not precised.
POV-Ray 3.5: 1.4GHZ AMD.
Virtualight: P II 233 MHz.
Autodesk VIZ 4:P III 800MHz.
KRay: Athlon XP 1700+.
Lightwave: Athlon 1400 MHz.
VRay: DUAL Athlon MP 1800+.
JaTrac: Athlon 1GHz.
Realsoft 3D: Athlon 1400 MHz.
Yafray: P 4 3GHz.
Art of Illusion 2.0: Athlon 3000+.
Redqueen: P 4 2GHz.
Cinema4D: Athlon XP 1800+.
Strata 3D Pro: dual P III 800MHz.

This make any speed comparison absolutely futil. To be able to do a speed 
comparison, you need to render with every programms on the same machine, or 
machines with the same caracteristics.
RAW CPU speed is of no help: some benchmarks show my 1400 MHz Athlon with single 
chanel DDR 266 as faster than a 1.8 GHz P 4 (same RAM), and a 3GHz P 4, with 
dual chanels DDR2 400 to be only 12% faster than my very aging computer...

-- 
Alain
-------------------------------------------------
   I knew a girl so ugly that she was known as a two-bagger. That's When you put 
a bag over your head in case the bag over her head comes Off.
	Rodney Dangerfield

Post a reply to this message

Alain <ele### [at] netscapenet> wrote:
> The main problemwith that comparison is that every samples where done on
> different machines with wildly varying specifications: pentium III and IV,
> athlon, single, dual processors, maount of RAM, CPU speed,...
>
> WinOSI: P4 1.7GHz
> Whire Frame, OpenGL, BMRT, Perceptuum, Radiance: CPU and GPU not precised.
> POV-Ray 3.5: 1.4GHZ AMD.
> Virtualight: P II 233 MHz.
> Autodesk VIZ 4:P III 800MHz.
> KRay: Athlon XP 1700+.
> Lightwave: Athlon 1400 MHz.
> VRay: DUAL Athlon MP 1800+.
> JaTrac: Athlon 1GHz.
> Realsoft 3D: Athlon 1400 MHz.
> Yafray: P 4 3GHz.
> Art of Illusion 2.0: Athlon 3000+.
> Redqueen: P 4 2GHz.
> Cinema4D: Athlon XP 1800+.
> Strata 3D Pro: dual P III 800MHz.
>
> This make any speed comparison absolutely futil. To be able to do a speed
> comparison, you need to render with every programms on the same machine, or
> machines with the same caracteristics.
True, but a number of those apparently cost in the hundreds of $ or eurs, so
not something everybody can pull off. It looks like the Winosi site relies on
external input.

There's a list of renderers (not just raytracers from the look of it) at
http://www.pointzero.nl/renderers/, but it doesn't make any comparison. It
looks like a number of raytracers that used to be free have "evolved" into
commercial packages. :-(

> --
> Alain
> -------------------------------------------------
>    I knew a girl so ugly that she was known as a two-bagger. That's When you put
> a bag over your head in case the bag over her head comes Off.
>  Rodney Dangerfield

Post a reply to this message

Alain a écrit :
> The main problemwith that comparison is that every samples where done on 
> different machines with wildly varying specifications: pentium III and 
> IV, athlon, single, dual processors, maount of RAM, CPU speed,...
> 

I think the purpose of the comparison was more to see the differences 
between the images produced, in this case. The render time gives an 
order of magnitude of the speed...

-- 
Vincent

Post a reply to this message

Vincent Le Chevalier nous apporta ses lumieres en ce 2007/11/06 04:46:
> Alain a écrit :
>> The main problemwith that comparison is that every samples where done 
>> on different machines with wildly varying specifications: pentium III 
>> and IV, athlon, single, dual processors, maount of RAM, CPU speed,...
>>
> 
> I think the purpose of the comparison was more to see the differences 
> between the images produced, in this case. The render time gives an 
> order of magnitude of the speed...
> 
I totaly agree with you. The comparison of the output is the thing this site is 
good for, along with a list of renderers that one can eveluate.
Some of the renders look extremely exagerated regarding radiosity colour bleeding.

-- 
Alain
-------------------------------------------------
Experience hath shewn, that even under the best forms of government those
entrusted with power have, in time, and by slow operations, perverted it
into tyranny.
Thomas Jefferson

Post a reply to this message

> > trace frames 0,10,20,30... on PC 1, frames 1,11,21... on PC 2 etc.
> Wouldn't it be simpler to simply trace eg. frames 0-9 in PC 1, 10-19 in PC 2, etc?

Well neither are ideal but the original scheme is better ... a key goal of
distributed rendering is load balancing, that is, you don't want to be waiting
at the end for one machine to finish because it was doing all the slow frames.
SInce many/most animations have some parts that are slower to render than
others, rendering every n'th frame on a machine is preferable.

The best way (optimal load balancing) is to have a server that is spawning jobs
to the clients as each client finishes a frame. In the worst case then you are
only waiting at the end for the length of time it takes one frame to render.
This is the way I do it, it isn't hard to script and there are some free tools
available to do this automatically. If you are luck enough to have a Mac then
just use xgrid that is supplied free with all macs.

-------------------------------------
P a u l   B o u r k e
http://local.wasp.uwa.edu.au/~pbourke/

Post a reply to this message

"Paul Bourke" <pau### [at] uwaeduau> wrote:
> > > trace frames 0,10,20,30... on PC 1, frames 1,11,21... on PC 2 etc.
> > Wouldn't it be simpler to simply trace eg. frames 0-9 in PC 1, 10-19 in PC 2, etc?
>
> Well neither are ideal but the original scheme is better ... a key goal of
> distributed rendering is load balancing, that is, you don't want to be waiting
> at the end for one machine to finish because it was doing all the slow frames.
> SInce many/most animations have some parts that are slower to render than
> others, rendering every n'th frame on a machine is preferable.
>
> The best way (optimal load balancing) is to have a server that is spawning jobs
> to the clients as each client finishes a frame. In the worst case then you are
> only waiting at the end for the length of time it takes one frame to render.
> This is the way I do it, it isn't hard to script and there are some free tools
> available to do this automatically. If you are luck enough to have a Mac then
> just use xgrid that is supplied free with all macs.
>
> -------------------------------------
> P a u l   B o u r k e
> http://local.wasp.uwa.edu.au/~pbourke/


I absolutely detest this forum for timing out (while typing my post) and
required me to login again and eventually loosing my original post!!!

free tools like?

I wrote my script on jdk1.6.0_02 using the subframes and a windoze netshare
folder to maintain concurrency (as the creation of the 'checkfile' is atomic).

Post a reply to this message

zeroin23 wrote:
> I absolutely detest this forum for timing out (while typing my post) and
> required me to login again and eventually loosing my original post!!!

The back-button is your friend, or you could just use a newsreader. The
login timeout is several hours, btw...

	Thorsten

Post a reply to this message