Rick [Kitty5] wrote:
> Christoph Hormann wrote:
> 
>>Running POV-Ray on a multiprocessor system would be the same as running
>>on several independent machines - you would start several render
>>processes for using all available processors.
> 
> And hope your not using radioasity....
> 

No, you just have to understand how radiosity works to be able to 
distribute the render efficiently.

A good example for this being a usable technique for radiosity renders 
as well is:

http://astronomy.swin.edu.au/~pbourke/povray/night/

-- 
Christoph Hormann
http://www.tu-bs.de/~y0013390/

Post a reply to this message

> Have you come up with a way of handling scenes that use persistent variables
> (e.g. particle systems, physics, etc)?
It is clear that for such systems a frame can only be rendered if his 
predecessor has already been done (or say the part modifying persistent 
variables, i.e. parsing). This is of course totally in contrast with the 
original idea of seperating the workload on multiple POV-instances. I 
ran into a similar problem with an animation I'm working on which will 
be rendered on the IMP farm (http://www.imp.org). The only way to handle 
the situation was to change the scene not to use file-i/o (i.e. 
persistent variables) at all.
Another approach which could work in many cases is to seperate 
simulation from rendering: First, calculate the persistent variables and 
save them in a frame-dependent include file (this must be done in a 
single machine, of course). Then distribute this data among your render 
clients (or make sure they can access it somehow) and render a second 
pass using the data generated before. This would be a good idea if the 
calculation of the persistent variables does not take too much time 
compared to the rendering itself. (You can compare this method with a 
two-pass rendering for splitted radiosity renders).

> Have you tried a similar approach on still images?
Would be pretty the same IMHO, simply do not hand out frames via 
INI-files but parts of the image using +SR, +ER, +SC and +EC command 
line switches.

If you are using Windows, you should take a look at SMPOV:
http://www.it-berater.org/smpov.htm
A freeware tool for distributed POV-rendering for Windows.

Another option would be POV-Anywhere by Christoph Hormann 
(http://www-public.tu-bs.de:8080/~y0013390/povany/index.html) which 
works on many platforms (including Windows using cygwin).

For animations there is also the Internet Movie Project (www.imp.org). 
The server/client software is ported to Perl currently, so it works on 
Windows and Linux, too (Current server is Windows only).

HTH,
Florian

Post a reply to this message

laurent.artaud[AT]free.fr <"laurent.artaud[AT]free.fr"> wrote:
> Well, re-read my posts: I _NEVER_ SAID THAT THE _FPU_ WAS 32 BITS!

  Direct quote from your post:

"Even if the Athlon-XP's FPU is able to use 64 bits double precision
floats, it's internal structure is only 32 bits"

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

> laurent.artaud[AT]free.fr <"laurent.artaud[AT]free.fr"> wrote:
> 
>>Well, re-read my posts: I _NEVER_ SAID THAT THE _FPU_ WAS 32 BITS!
> 
> 
>   Direct quote from your post:
> 
> "Even if the Athlon-XP's FPU is able to use 64 bits double precision
> floats, it's internal structure is only 32 bits"
> 

It has already been said, I did not use the correct phrasing, and I 
corrected it in the next post.
I was meaning the global Athlon-XP was 32 bits EXCEPT for the FPU, which 
could use 64 bits (an even more)

-- 
Laurent ARTAUD (lau### [at] freefr)

Post a reply to this message

> If you are using Windows, you should take a look at SMPOV:
> http://www.it-berater.org/smpov.htm
> A freeware tool for distributed POV-rendering for Windows.
>
> Another option would be POV-Anywhere by Christoph Hormann
> (http://www-public.tu-bs.de:8080/~y0013390/povany/index.html) which
> works on many platforms (including Windows using cygwin).

That looks pretty useful :)

Thanks!
-- 
Tek
www.evilsuperbrain.com

"Florian Brucker" <tor### [at] torfboldcom> wrote in message
news:4066cc96$1@news.povray.org...
> > Have you come up with a way of handling scenes that use persistent variables
> > (e.g. particle systems, physics, etc)?
> It is clear that for such systems a frame can only be rendered if his
> predecessor has already been done (or say the part modifying persistent
> variables, i.e. parsing). This is of course totally in contrast with the
> original idea of seperating the workload on multiple POV-instances. I
> ran into a similar problem with an animation I'm working on which will
> be rendered on the IMP farm (http://www.imp.org). The only way to handle
> the situation was to change the scene not to use file-i/o (i.e.
> persistent variables) at all.
> Another approach which could work in many cases is to seperate
> simulation from rendering: First, calculate the persistent variables and
> save them in a frame-dependent include file (this must be done in a
> single machine, of course). Then distribute this data among your render
> clients (or make sure they can access it somehow) and render a second
> pass using the data generated before. This would be a good idea if the
> calculation of the persistent variables does not take too much time
> compared to the rendering itself. (You can compare this method with a
> two-pass rendering for splitted radiosity renders).
>
> > Have you tried a similar approach on still images?
> Would be pretty the same IMHO, simply do not hand out frames via
> INI-files but parts of the image using +SR, +ER, +SC and +EC command
> line switches.
>
> If you are using Windows, you should take a look at SMPOV:
> http://www.it-berater.org/smpov.htm
> A freeware tool for distributed POV-rendering for Windows.
>
> Another option would be POV-Anywhere by Christoph Hormann
> (http://www-public.tu-bs.de:8080/~y0013390/povany/index.html) which
> works on many platforms (including Windows using cygwin).
>
> For animations there is also the Internet Movie Project (www.imp.org).
> The server/client software is ported to Perl currently, so it works on
> Windows and Linux, too (Current server is Windows only).
>
> HTH,
> Florian
>

Post a reply to this message

"Rick [Kitty5]" <ric### [at] kitty5com> wrote in message
news:406582b6@news.povray.org...
> Christoph Hormann wrote:
> > For multiprocessor machines and clusters you have a large number of
> > possible solutions but a fast multiprocessor system will usually be
> > quite expensive in comparison to a set of several inexpensive single
> > processor computers.
>
> For dual CPU boxen, aside from the cost of the extra CPU and a little more
> on the motherboard its not as bad as you would think. Significantly cheaper
> than 2 computers!

Actually I've been looking into some prices, and the extra cost of the
motherboard is pretty substantial. The cheapest dual processor motherboard I
could find was over $200, whereas I found a single processor one that was
roughly equivalent for under $50. Plus the CPUs are more expensive. In fact it
works out that a dual processor system would cost me around $700 to build, and
be only slightly more than twice as fast as a system I could build for under
$200 (based on the results on the pov benchmarks site). I tried a variety of
different multi-processor setups (Athlon MP, and two different Opteron setups)
but in every case the extra processing power was outweighed by the extra cost.
So I think I'm better off with lots of very cheap systems.

-- 
Tek
www.evilsuperbrain.com

Post a reply to this message

laurent.artaud[AT]free.fr <"laurent.artaud[AT]free.fr"> wrote:
> > "Even if the Athlon-XP's FPU is able to use 64 bits double precision
> > floats, it's internal structure is only 32 bits"

> It has already been said, I did not use the correct phrasing, and I 
> corrected it in the next post.
> I was meaning the global Athlon-XP was 32 bits EXCEPT for the FPU, which 
> could use 64 bits (an even more)

  I thought "it" referred to "FPU"... :)

  By the way, it's "its", not "it's".
  The latter means "it is", and "it is internal structure is only 32 bits"
doesn't make sense. :)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

> 
>   By the way, it's "its", not "it's".
>   The latter means "it is", and "it is internal structure is only 32 bits"
> doesn't make sense. :)
> 

Oh!
Thanks for pointing that. I usually don't make that kind of error.
I'll have to be more careful when I type...

Regards,

-- 
Laurent ARTAUD (lau### [at] freefr)

Post a reply to this message

Tek wrote:

>> If you are using Windows, you should take a look at SMPOV:
>> http://www.it-berater.org/smpov.htm
>> A freeware tool for distributed POV-rendering for Windows.
>>
>> Another option would be POV-Anywhere by Christoph Hormann
>> (http://www-public.tu-bs.de:8080/~y0013390/povany/index.html) which
>> works on many platforms (including Windows using cygwin).
> 
> That looks pretty useful :)
> 
I'm actually rendering my animations using RendView, a self-developed 
tool. Not useful for still images but it can distribute frames across a
network. Lots of features. 

http://www.cip.physik.uni-muenchen.de/~wwieser/ani/rendview/

BTW, as we were talking about the hardware: I was running RendView 
and POVRay-3.5+own patches on a...
  28-node PIV-2.4 GHz (HT) cluster 
last week for the animation "Flying along Vallis Marineris on Mars"
Can recomment that :)

Wolfgang

Post a reply to this message

Christoph Hormann wrote:

> Tek wrote:
>> 
> But much more important is that there is no way to implement
> multithreading in a portable manner - not even for the three 'official'
> platforms.  So if you want to attempt implementing such a system (which
> would be pretty hard on the current POV-Ray source anyway) you would
> have to implement several platform specific variants.
> 
Yes but it should be possible to find a portable interface for all the OSes. 
It's like there are 3 different graphical interfaces (Mac, Windows, X11). 
That should be possible for threads, too. At least Apache-2 can do it IIRC. 

I think, one could consider designing POVRay-4 in a way to allow for that. 

Wolfgang

Post a reply to this message