POV-Ray : Newsgroups : povray.general : zRCube (POV Clone) : Re: zRCube (POV Clone) Server Time
8 Aug 2024 04:04:36 EDT (-0400)
  Re: zRCube (POV Clone)  
From: Francois Dispot
Date: 1 Jun 2001 16:32:31
Message: <3B17FBDD.11A8F06C@club-internet.fr>
Christoph Hormann wrote:

> > I gain network support, which means faster renders. I know that there are some
tools around
> > that help you to distribute renders over more machine, but they are not cross
platform.
> > Sure a lot of code needs to be written, but writing a ray tracer involves writing
lots of
> > code.
> >
> > As far as I know the network interfaces on Unix and win32 are quite similar, just
a few
> > calls different. I don't know about MacOS, but MacOS X should be similar again,
since it is
> > a BSD unix. And endianess problems are well understood and all operating systems
with a
> > tcp/ip stack provide functions for it (or at least should).

As Christoph said, this is more complex. If you start this way, you will
end implementing conversion routines (64/80/128 bit float, 32 bit chars,
etc...), servers ensuring that messages get through the network so that
client apps do not have to care when a computer is shut down, control
and notification protocols, data packing... And you'll finish with a
library close to PVM (or MPI, this is not about religion ;-), but with
less features and much less tests. These libraries have been around for
such a long time...

Now if PVMPov hasn't been ported to dos 2000 and its familly, well, I
dunno. According to comp.parallel.pvm ng I read sometimes, people
usually have trouble running pvm on windos, but usually they end up with
something working. AFAIK nobody could ever get it to simply _link_. As I
always said, I would be happy to help people port pvmpov (and of course
prefferably pvmegapov) to other platforms. But before starting to debug
something, you need at least to get an executable.

> I think these things were discussed quite enough, i'm sure you are welcome
> to implement an universal platform independent parallel rendering module
> for Povray, but the problems that will occur are much more than just byte
> order and network protocols. PVMPov has quite a lot of problems to deal
> with and it uses an already made and well tested system.

Well, yes and no. Yes, PVM and POVRay both have a good user base and are
well known. But pvmpov remains a terrible hack because it had to place
hooks and asynchronism in a very sequential code. Their approach towards
this is a good one. But writing it will allow to easily implement
anything new in the future is definitely crap.
-- 

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


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.