Distributed Raytracing, tools to use (RMI, WebService, somethingelse)?

[Daniel Pitts]

I'm thinking about creating a Distributed Ray-tracer. I've created a
Ray-Tracer that is multi-threaded, and was thinking about ways to make
it multi-computer ;-)

My current set up:
I have a class Universe, which represents the scene, including lighting,
shapes, etc...
I have a class BlockTracer that traces a block of pixels, and sets part
of a BufferedImage to the value of those pixels.

My current thoughts are that I should use RMI.
I would make my Universe serializable. I would create a BlockQueue
class which will a block that needs to be traced to any node that is
ready. When a node grabs a block, it traces that block in the Universe,
and then sends a completed image fragment back to the Client.

Does this sound like a workable strategy? Should I use something other
than RMI? If some of my nodes are behind a firewall, can I use UPnP
with RMI?

Thanks,
Daniel.

 

[Arne Vajhøj]

I'm thinking about creating a Distributed Ray-tracer. I've created a
Ray-Tracer that is multi-threaded, and was thinking about ways to make
it multi-computer ;-)

My current set up:
I have a class Universe, which represents the scene, including lighting,
shapes, etc...
I have a class BlockTracer that traces a block of pixels, and sets part
of a BufferedImage to the value of those pixels.

My current thoughts are that I should use RMI.
I would make my Universe serializable. I would create a BlockQueue
class which will a block that needs to be traced to any node that is
ready. When a node grabs a block, it traces that block in the Universe,
and then sends a completed image fragment back to the Client.

Does this sound like a workable strategy? Should I use something other
than RMI? If some of my nodes are behind a firewall, can I use UPnP
with RMI?

RMI is convenient to use when working with complex data types.

If the work done for each call is significant, then the overhead
would be small.

And if you always let the clients initiate the connection and
your server are not behind a firewall or behind a firewall that
you control, then you should not get any problems.

Arne

 

[Zig]

I'm thinking about creating a Distributed Ray-tracer. I've created a
Ray-Tracer that is multi-threaded, and was thinking about ways to make
it multi-computer ;-)

My current set up:
I have a class Universe, which represents the scene, including lighting,
shapes, etc...
I have a class BlockTracer that traces a block of pixels, and sets part
of a BufferedImage to the value of those pixels.

My current thoughts are that I should use RMI.
I would make my Universe serializable. I would create a BlockQueue
class which will a block that needs to be traced to any node that is
ready. When a node grabs a block, it traces that block in the Universe,
and then sends a completed image fragment back to the Client.

Does this sound like a workable strategy? Should I use something other
than RMI? If some of my nodes are behind a firewall, can I use UPnP
with RMI?

RMI is good at some things.

* Sending a graph of (serializable) objects to another client for
processing - quite easy.
* Getting a progress bar to show you how far along your universe is as it
is uploading - remarkably frustrating.

Tracking down errors in a client side app is a bit tricky too. You might
keep in mind that each "block" has 3 states:

* new
* pending
* complete

If a client takes a new block, it moves into the pending queue. If
something is still in the pending state, you may need to periodically poll
those clients to make sure they are really still working, and haven't
crashed.

Also note with a remote queue, you may also need to implement an ACK when
a block is received. Consider:

public interface BlockQueue extends java.rmi.Remote {
public Block poll() throws RemoteException;
}

In this case, your local BlockQueue might complete the poll(), but
transmission of the Block can still throw an exception. Thus, the server
has removed a block, but the client never receives it.

On the plus side, with RMI you can use a RMIClassLoader. If developers can
contribute new classes to your Universe, then (in theory), rendering
clients could dynamically discover & load the new classes from the server.

RMI is really tricky with firewalls, though. Every exported object has
it's endpoint set by the host, instead of inheriting the route the client
used to reach the object. If the host of a remote object is behind a NAT,
you must tack on a
-Djava.rmi.server.hostname=(NAT address)
onto the JVM's startup command line.

As for UPnP, some Java APIs exist, but I don't know what their maturity is.

HTH,

-Zig