[comp.graphics] Any interest in a parallel raytracer?

kory@avatar.avatar.com (Kory Hamzeh) (11/27/90)

I wrote a parallel raytracer (named 'prt') a while back with the following 
features:

	- Runs on multiple heterogeneous machines networked together
	  using TCP/IP.
	- Crude load balancing.
	- Primitives:
		- Polygons
		- Spheres
		- Hallow Sphere
		- Cones
		- Cylinders
		- A object that can be expressed in a quadratic form
		- Rings
	- Shading:
		- Gourard
		- Phong
		- Whitted
	- Rendering:
		- Simple: one ray per pixel
		- Stochastic sampling (jitter)
	- Instances of objects.
	- Input format:
		- An extention of nff. I have written a filter which
		  will convert NFF files to prt format.
	- Output format:
		- MTV format (24 bit).

Note that prt is a parallel raytracer which spawns off children over
multiple machines to distribute the work. I have only used it on five
Sun Sparcstations and have gotten excellent performance. I'm not aware
of any other public domain parallel raytracers other than VM_pRay 
(which, I believe, runs only on a specific platform).

Since there are so many public domain raytracers currently available,
I wanted to see if there was any interest in prt before I send it
to comp.sources.unix.

So, if you are interested in getting your hands on prt, please let me
know. If I get enough positive responses, I will post it in c.s.u.

Thanks,
--kory


-- 
-------------------------------------------------------------------------------
Kory Hamzeh             UUCP: avatar!kory or ..!uunet!avatar!kory
                    INTERNET: kory@avatar.com 

kory@avatar.avatar.com (Kory Hamzeh) (11/28/90)

In article <105@avatar.avatar.com>, kory@avatar.avatar.com (Kory Hamzeh) writes:
> 
> 
> I wrote a parallel raytracer (named 'prt') a while back with the following 
> features:
> 	[ lots of stuff deleted ]
> 
> Since there are so many public domain raytracers currently available,
> I wanted to see if there was any interest in prt before I send it
> to comp.sources.unix.
> 
> So, if you are interested in getting your hands on prt, please let me
> know. If I get enough positive responses, I will post it in c.s.u.
> 
> -------------------------------------------------------------------------------
> Kory Hamzeh             UUCP: avatar!kory or ..!uunet!avatar!kory
>                     INTERNET: kory@avatar.com 

I received over 100 request for prt within 24 hours of posting the above
article. I can't mail to everyone for obvious reasons and if I post it
to comp.sources.unix, it might take up to 1 month before Rich Salze can
release it (Rich has a very busy schedule).

I can do any of the following:

	- Make it available via anonymous uucp
	- Post it to comp.graphics
	- I don't have ftp access, but if some who does can make it available
	  for anonymous ftp, I can mail them a copy. (If you are interested
	  in archiving prt for anonymous ftp access, please let me know).

Posting to comp.graphics would be the fastest way, but I have a funny
feeling it will piss off some of the net gurus.

Either way, I need to beef up the documentation before I release it. I hope
to send it out by the end of the week.

And lastly, I will be upgrading the OS on my mail gateway over the weekend and
I expect to have some minor e-mail glitches. If you send me mail and it 
bounces, please try again.

Anyway, let me know.

Thanks,
--kory


-- 
-------------------------------------------------------------------------------
Kory Hamzeh             UUCP: avatar!kory or ..!uunet!avatar!kory
                    INTERNET: kory@avatar.com 

marcel@tnoibbc.UUCP (Marcel Boender) (11/28/90)

Article 11961 Kory Hamzeh writes :

> ...
> So, if you are interested in getting your hands on prt, please let me
> know. If I get enough positive responses, I will post it in c.s.u.

	Yes, please post it !
-- 
Marcel Boender : TNO-BOUW                   INTERNET : marcel@tnoibbc
               : PO-box 49                  DOMAIN   : marcel@ibbc.tno.nl
               : 2600 AA Delft              UUCP     : ..!hp4nl!tnoibbc!marcel
               : the Netherlands            PHONE    : +31 15 842031

garyc@hobbes.wv.tek.com (Gary Combs) (11/29/90)

In article <2188@tnoibbc.UUCP>, marcel@tnoibbc.UUCP (Marcel Boender) writes:
|> From: marcel@tnoibbc.UUCP (Marcel Boender)
|> Subject: Re: Any interest in a parallel raytracer?
|> Keywords: Parallel Raytracers
|> Date: 28 Nov 90 13:31:14 GMT
|> 
|> Article 11961 Kory Hamzeh writes :
|> 
|> > ...
|> > So, if you are interested in getting your hands on prt, please let me
|> > know. If I get enough positive responses, I will post it in c.s.u.
|> 
|> 	Yes, please post it !
|> -- 
|> Marcel Boender : TNO-BOUW                   INTERNET : marcel@tnoibbc
|>                : PO-box 49                  DOMAIN   : marcel@ibbc.tno.nl
|>                : 2600 AA Delft              UUCP     : ..!hp4nl!tnoibbc!marcel
|>                : the Netherlands            PHONE    : +31 15 842031

-- 


Dito for me.



-------------------------------------------------------------------------------
Gary Combs
Tektronix, Inc
NWD Technical Marketing Support
(503)685-2072
garyc@shamu.wv.tek.com
-------------------------------------------------------------------------------

jonas-y@isy.liu.se (Jonas Yngvesson) (11/30/90)

kory@avatar.avatar.com (Kory Hamzeh) writes:

>I wrote a parallel raytracer (named 'prt') a while back with the following 
>features:

I have made a network distributed version of David K. Buck's
ray-tracer DKB. 

>	- Runs on multiple heterogeneous machines networked together
>	  using TCP/IP.

Same here, I used inetd to fire up a trace server on request from the
client. The client tokenizes the input file and sends these tokens to
each server. The client then distributes the job, one scanline per server
until the image is finished.

>	- Crude load balancing.
>	- Primitives:
>		- Polygons
>		- Spheres
>		- Hallow Sphere
>		- Cones
>		- Cylinders
>		- A object that can be expressed in a quadratic form
>		- Rings
>	- Shading:
>		- Gourard
>		- Phong
>		- Whitted
>	- Rendering:
>		- Simple: one ray per pixel
>		- Stochastic sampling (jitter)
>	- Instances of objects.
>	- Input format:
>		- An extention of nff. I have written a filter which
>		  will convert NFF files to prt format.

DDKB (distributed dkb) has the same primitives, shading and input
format as DKB (for obvious reasons). This includes very nice support
for solid texturing.

Antialiasing differs slightly. DKB uses an adaptive jittered
supersampling, but in DDKB, each server only has access to one scanline
at a time. This means adaption is done in x-direction only.

>	- Output format:
>		- MTV format (24 bit).

Here I have used a mix between the MTV-format an the QRT-format used
in DKB. An MTV-header is followed by the scanlines in QRT-format.
Each line tagged with its line number (this is because the lines are
stored in the order they are finished by the servers and must be
sorted before display).

>Note that prt is a parallel raytracer which spawns off children over
>multiple machines to distribute the work. I have only used it on five
>Sun Sparcstations and have gotten excellent performance. I'm not aware
>of any other public domain parallel raytracers other than VM_pRay 
>(which, I believe, runs only on a specific platform).

Yeah! We have tried DDKB running on 55 sparcstations (then we ran out
of file descriptors, perhaps we should use UDP instead of TCP).
Pretty good performance indeed.
Unfortunately DKB is not a terribly fast tracer in itself and I have no
time to hack around in it.

I'm not very willing so send this thing out though. Partly because it
is still only a hack, and partly because I have not contacted David
Buck and asked what he thinks about the whole thing.

--Jonas

------------------------------------------------------------------------------
 J o n a s   Y n g v e s s o n
Dept. of Electrical Engineering	                         jonas-y@isy.liu.se
University of Linkoping, Sweden                   ...!uunet!isy.liu.se!jonas-y
-- 
------------------------------------------------------------------------------
 J o n a s   Y n g v e s s o n
Dept. of Electrical Engineering	                         jonas-y@isy.liu.se
University of Linkoping, Sweden                   ...!uunet!isy.liu.se!jonas-y

valdis@wizards.vt.edu (Valdis Kletnieks) (11/30/90)

In article <105@avatar.avatar.com>, kory@avatar.avatar.com (Kory Hamzeh) writes:
|> Since there are so many public domain raytracers currently available,
|> I wanted to see if there was any interest in prt before I send it
|> to comp.sources.unix.
|> 
|> So, if you are interested in getting your hands on prt, please let me
|> know. If I get enough positive responses, I will post it in c.s.u.
Kory:

(1) I'm interested, as I'm sure a lot of other people are as well.
However, please note that 

(2) comp.sources.unix is a "black hole" - the moderator seems to have
fallen asleep at the wheel, and nothing posted to it ever surfaces.

You may wish to consider posting it to this newsgroup instead?

				Valdis Kletnieks

kjartan@puce.inria.fr (Kjartan Emilson) (11/30/90)

Does anybody have an algorithm for a massively parallel raytracer,
which could for example run on a Connection Machine, i.e a machine
with a 'single instruction - many data' architecture ?

		-Kjartan

kyriazis@iear.arts.rpi.edu (George Kyriazis) (12/01/90)

In article <9308@mirsa.inria.fr> kjartan@puce.inria.fr (Kjartan Emilson) writes:
>
>Does anybody have an algorithm for a massively parallel raytracer,
>which could for example run on a Connection Machine, i.e a machine
>with a 'single instruction - many data' architecture ?
>

The ray-tracing algorithm is usually paralellelized ray-at-a-time, which
makes it suitable for MIMD machines.  If you want to run it on an SIMD
you have a problem, since you have to advance all rays at the same time,
then filter out which rays do not need a second reflection, and trace the
second level, etc.

I believe that Scott Whitman (at uiuc?) has written a ray-tracer for
a SIMD machine.  I don't remember any details.  Pick up the SIGGraph
proceedings for either '88 or '89 (don't remember which one) on ray-tracing
or parallel computer architectures for computer graphics and you are
going to see his name there.

Hope that helps.


----------------------------------------------------------------------
  George Kyriazis                 kyriazis@rdrc.rpi.edu
 				  kyriazis@iear.arts.rpi.edu

punch@pleiades.cps.msu.edu (Bill Punch) (12/04/90)

I know of one researcher who did work on implementation of ray-tracing
on a massively parallel machine like the Connection Machine. I got it as
a tech report from the connection machine peopleT(TMC), it is also a
tech report at the MIT Media lab.

	Hubert Delany, "Ray Tracing on a Connection Machine", Tech report from 
	Thinking Machines Corp., Tech Report Number VZ88-3, April 1988.

Very Intersting Stuff!

						>>>bill punch<<<
						punch@pleiades.cps.msu.edu

mike@BRL.MIL (Michael John Muuss <mike>) (12/04/90)

In article <105@avatar.avatar.com>, kory@avatar.avatar.com (Kory Hamzeh)
writes:
|> I wrote a parallel raytracer (named 'prt') a while back ...
|> 	- Runs on multiple heterogeneous machines networked together
|> 	  using TCP/IP.
|> 	- Crude load balancing.

Well, the BRL-CAD Package ray-tracer operates both on shared memory
multi-processors, as well as in a network-distributed mode.  While not
PD, it is free.  I have written about it in a number of articles,
including:

%K MUUS90a
%A M. J. Muuss
%T Workstations, Networking, Distributed Graphics, and Parallel Processing
%E D. F. Rogers, R. A. Earnshaw
%B Computer Graphics Techniques:  Theory and Practice
%I Springer-Verlag
%D 1990

While not "super sophisticated", the load balancing algorithm is
non-trivial.  It assigns pixel blocks of variable size.  Three
assignments are outstanding to each worker at any time, to
pipeline against network delay.  New assignment size is tuned,
based upon measured past performance (weighted average with variable
weighting, depending on circumstances).

I'd certainly be interested in seeing a copy of your work.

	Best,
	 -Mike Muuss

	  Advanced Computer Systems
	  Ballistic Research Laboratory
	  APG, MD  21005-5066

kory@avatar.avatar.com (Kory Hamzeh) (12/06/90)

In article <14648@smoke.brl.mil>, mike@BRL.MIL (Michael John Muuss <mike>) writes:
> 
>       [ lots of good stuff about BRL-CAD deleted ]
>
> While not "super sophisticated", the load balancing algorithm is
> non-trivial.  It assigns pixel blocks of variable size.  Three
> assignments are outstanding to each worker at any time, to
> pipeline against network delay.  New assignment size is tuned,
> based upon measured past performance (weighted average with variable
> weighting, depending on circumstances).
> 
> I'd certainly be interested in seeing a copy of your work.
> 



Prt's load balancing is not as sophisticated as BRL-CAD's. Prt simply
multiplexes the scanlines across the different machines. The slowest
machine on the network will be the bottle neck.

When I get a chance, I would like to use the same techniques used in BRL-CAD. 
I think that it is the best load balancing for a raytracer.


--kory


-- 
-------------------------------------------------------------------------------
Kory Hamzeh             UUCP: avatar!kory or ..!uunet!avatar!kory
                    INTERNET: kory@avatar.com