Stars of Shareware: Raytrace & Morphing/SOS-RAYTRACE.ISO/programm/texte/3dsnet.txt

Text File | 1994-04-24 | 41.3 KB | 885 lines

              Confessions of a Network Renderer
                             or
               How I Learned to Love 3D Studio


It was cold, dark, and wet. Not too unusual considering it
was night time on the outskirts of San Francisco. I was
still at work, late at night, alive with the sheer pleasure
of manipulating the electronic pathways of my computer's
network system. This was not unusual. What is unusual, is
that late at night I lead a secret life. I am a night time
network renderer.

My name is Wendel Oliver Williams. WOW.  I work for a large
corporation that has a lot of  computer resources available.
Late at night, I run a few batch files I've created, and all
of a sudden dozens of machines in my office all start
working at the same time, doing my work for me. You see,
I've been working with 3D Studio and the network rendering
features.  Here is my story.


                      Networks Galore!

Before you can set up network rendering for 3D Studio, you
have to know a little bit about the type of network that you
have. Techno-gweeb that I am, I have several different types
of  networks and I run 3D Studio on all of them. Each has
its merits. Before I start spouting name brands at you
however, let's start with the basics.

There are really only two types of networks. Client/Server
and Peer-to-Peer.  3D Studio works with both of these types
of networks. A client-server network generally has each
person on the network connected to one machine called the
server. The server usually has a very large hard drive, and
files and programs which need to be shared by all the
clients (users) on the network are stored in this one
location. Clients on the network can often talk to each
other and send messages back and forth, but they can't share
files and programs that are on their personal hard drives
with each other, without first copying the files up to the
server. One client on the network can not read a file
directly off another client's hard drive. If you want to do
that, you can use a peer-to-peer network.

In a peer-to-peer network, you can set up a machine on the
network to be both a client and a server at the same time.
So if one machine on the network is set up both as a client
and a server, other machines on the network can read files
and programs directly off the hard drive of that computer.
While this might on the surface appear to give you more
freedom, it often means that there is no central location
for shared files, and I have to go hunting through the
various machines that are set up as servers to find what I
want. Also, people have a bad (in my opinion) habit of
turning off their computer before they go home or when they
are out of the office. When the computer is turned off, I
can't access  the information stored on that computer's hard
disk.

At my office I have run 3D Studio with several networks.
Novell (Client/Server), PC-NFS (Peer-to-Peer), Netware Lite
(Peer-to-Peer), Workgroups for Windows (Peer-to-Peer),
Lantastic (Peer-to-Peer) and PC/TCP (Client/Server). One
major source of confusion is that you can have more than one
network protocol running at the same time. So I can have a
Client/Server network running at the same time, and over the
same cables, as a peer-to-peer network, and have the best
(or worst) of both worlds.


 General Set up principles...or...How to set up a Modern 3D
                           Dungeon

Getting 3D Studio set up for network rendering can and
should be a fairly easy and painless procedure. If you
follow the instructions in the Advanced User Guide [pages 20-
48] closely, you shouldn't have any problems. I have
identified several pitfalls or traps that you can run into,
however.

First the basics. There are several things you need in order
to set up network rendering. The first is a copy of 3D
Studio. You only need one licensed copy of 3D Studio, no
matter how many machines you  plan to use for rendering. You
will need to install the 3D Studio software on each machine
that you are planning to use. This is not a violation of
your license agreement. Remember, 3D Studio comes with a
hardware lock. You need to have the hardware lock plugged
into the machine in order for you to use the program. If you
forget to plug this in, when you type "3DS" to start the
program, 3D Studio will tell you "Sentinel Pro not Found"
which means that the program couldn't find the hardware
lock. In Release 3, however, you can now type "3DS SLAVE".
This will start up 3D Studio and place it directly into
"slave" mode, which is a state of readiness for network
rendering. You do not need a hardware lock on the system to
start up 3D Studio in slave mode.

Installing 3D Studio on the local hard drive of each system
you are going to use can be a tedious chore. What I do is
install the software on one machine, then copy it
temporarily up to a file server, and then back down to each
machine on the network I am planning to use. This method
works, but, you need to remember that each machine will not
be set up the same, and you will still need to go around to
each machine and re-configure 3D Studio for that particular
environment. Items that you will need to configure will be
the 3DS.SET file, 3DSNET.SET file, Vibrant video
configuration, and CFIG386 configuration. We'll talk about
each of these in just a bit.

     [Note: Some people have experimented with trying to
     save disk space by installing one copy of  3D Studio on
     the Network Server, and having each of the slaves
     access this copy.  By specifying  a separate 3DS.SET
     file for each slave, and a few other configuration
     tricks I won't tell you, you can get multiple sessions
     of 3D Studio to run from one copy stored on the
     network. However, you will take a very significant
     performance hit when you try to utilize the program. If
     you are only demonstrating that network rendering
     exists, and don't actually need to render, this
     approach might be justified. In any production
     environment, this approach would not be recommended. A
     stronger statement is needed. This approach would be
     suicidal.]

The second thing you will need for network rendering is some
central location, accessible to all the slave machines,
where the control files for the rendering procedures will be
stored. This applies to both Client/Server  and  Peer-to-
Peer networks. On a Client/Server network,  those files have
to be placed in a directory on the network server. Each
machine that is going to be used for rendering has to be
logged into the network, and have read/write access to that
specific subdirectory on the file server. On a Peer-to-Peer
network, these files can be placed on any machine, as long
as all the slaves, and the master machine, are attached and
logged into that machine, and have read/write capabilities
in that subdirectory. If you do not have supervisor (read
that as God-like) privileges on your network system, you
will need to get the help of your network supervisor to help
you prepare your network for rendering.

      [Note: Network supervisors are very strange creatures
     that have very luckily found a very specific
     evolutionary niche in which to exist in this complex
     technological environment. Their lair or nest is often
     found cluttered ceiling high with various computers and
     other electronic paraphernalia which have been cracked
     open and scavenged for the parts which grow inside.
     They seem to exist solely on coffee and nicotine,
     although recently a group of supervisors have been
     noted to have given up nicotine in favor of oreo
     cookies. When approaching your network supervisor, I
     suggest you do this with extreme caution, and with
     either cigarettes or cookies in hand. Please remember
     to use extreme caution.]

One possible pitfall at this stage is not having each
machine on the network looking in the same subdirectory for
the control files. The control files are created
automatically, so if you are directing your control files to
more than one location on the net, and are not aware of
this, your slave machines will not be found by the machine
that is initiating the rendering process.


 3DSNET.SET...or...The Master's Master: the 3DSNET.SET file

One of the settings in the 3DSNET.SET file tells where to
find the network control files. This file needs to be
configured on each workstation you have copied the 3DS
program onto for network rendering. Most of the default
entries in this file may be left as they are. However there
are some settings that must be changed before network
rendering will work properly. Let's look at some of those
changes.

NET-OWNER will be a name up to 12 characters. This is the
name of the person or group to whom this workstation belongs
to, and is the first part of the data used to identify each
machine. One person could be in control of several machines,
so this name does not need to be unique.

NET-NAME is the individual name for this PC. THIS MUST BE
UNIQUE. This is also the name that will display when you are
choosing machines to render to, so a descriptive name might
be in order. "486/33 in Office 23" probably makes more sense
than "Fred's PC". This name can be up to 20 characters. [Of
course names like Caligula and Spartacus have their merit
too. I leave this to you, the network renderer, to make this
artistic decision.]

NET-MACHINE-ID also needs to be  unique number, between 0
and 9999. This number will help identify each machine to
rendering control.

NET-PATH is the directory where this computer looks to find
the shared files that all computers on the network are going
to need access to.

     Note: The NET-PATH variable is one that can cause
     confusion. Two different machines can be set up to
     access the same file server, but with different drive
     mappings. So for one machine M:\MMEDIA\3DSNET might be
     the path to find the shared files, while on another
     machine X:\3DSNET takes you to the same place on the
     file server. It doesn't matter that the paths are
     different for each machine, as long as they point to
     the same sub-directory on the file server.

     For even further confusion, drive mapping can  be
     changed at the whim of whoever is at the computer. So
     if you are using someone else's computer as a slave
     machine, you might come in one day and find that what
     used to be on Drive F: is now on Drive H:. It is for
     this reason that many people create a new login name
     specifically for network rendering. Logging in under
     this new name insures that all the drive mappings will
     be set back to whatever you specify in the login
     script, temporarily clearing out any changes that the
     main user of the computer might have made during the
     course of the day.

NET-LOCAL-PATH is the subdirectory on this particular
machine where image files will be stored in on the hard
drive, should you choose that option at rendering time.

     Note: Some confusing terminology has just been
     introduced.  When 3D Studio talks about a LOCAL save
     for an image file, it means saving it on the hard disk
     of the machine that is doing the rendering (the slave)
     NOT the machine that started the rendering process (the
     master) . So if machine A is the master machine, and is
     set up to render to machines B,C, and D, and you choose
     to save the images to LOCAL at the time of rendering,
     you will be saving images in 3 different locations, the
     hard disks of machines B,C, and D.


NET-SERVER-PATH is the subdirectory where files will be
saved if you choose SERVER at the time of rendering.
Remember, this is a path relative to the way the slave
machine is set up, so you could have each machine saving to
the same subdirectory on a file server, or to different sub
directories, however you want to set it up. Usually this
option is used to store all the images that are created from
the multiple machines into one subdirectory.

In a Peer-to-Peer network there is no central file server as
there is in a Client/Server network. If you want to save all
your images to one directory you need to assign a drive
mapping from each machine that points to one central
location on some hard disk with plenty of room. Then use
that drive mapping as the path for the NET-SERVER-PATH. All
the files will be saved in this common directory. Remember,
the drive mapping for each of the slaves may be different.
The important thing is that they all point to the same
central location on some hard disk.

3DS.SET...or...The Master's Master's Master? This is getting
                         confusing.

You will also need to configure your 3DS.SET file, VIBRANT
video configuration, and CFIG386 configuration on each slave
station, just like an initial installation of 3D Studio.
You'll probably have to carry your hardware lock around with
you to configure and test everything properly.

In the 3DS.SET file you might be adding a MAP-PATH  that
points to a subdirectory on the file server or a shared
drive for maps and IPAS routines that might be needed by all
the machines during rendering.  In order to share resources
this way, you have to be using a network protocol that has
very good file sharing capabilities. In other words, if two
machines make a call for the same texture map at the same
time, the network software can handle that request by
talking to two or more machines at the same time, with only
one file. If your network does not have EXCELLENT file
sharing capabilities, do not attempt this. Instead, copy the
maps and routines that each machine will need onto their
local hard drives. FILE SHARING ERRORS ARE ONE OF THE MOST
COMMON REASONS FOR A FAILED NETWORK RENDERING PROCESS. Also
in the 3DS.SET file you might need to change the location
that temporary files are directed to. These should be
pointed to the drive with the most free hard disk space.

You will need to configure the VIBRANT video display for the
particular machine that you are on. Slave mode of 3D Studio
still displays the main user interface on the computer
screen, so you have the same minimum requirements for video
as you would if you were using this machine as a master
station. Specifically, you need a VGA card capable of
running 3D Studio. You reconfigure each slave by  starting
3D Studio with the "3DS VIBCFG" command. This will take you
to the Vibrant configuration screen. For more information on
configuring your video display, refer to your Installation
Guide [page 4 and pages 66-67]. Make sure you know the brand
and make of the VGA card you are using  before starting this
option. If you don't know what video card is in the slave
station, a useful utility to find out this information is
MSD.EXE. This diagnostic utility will tell you information
about your computer's configuration, and is included in
either Windows 3.1 and DOS 6.x.

If you copied your version of 3D Studio from another
machine, you might also need to reconfigure your Phar Lap
swap drive. The -swapdir variable tells 3D Studio where to
write some temporary files that the memory manager will use
when it pages out to disk. You can see where the -swapdir
variable is currently pointing  by typing "CFIG386 3DS" in
the 3DS3 subdirectory. The list of configured switches will
be displayed on your screen. If you need to change the swap
drive to point to a hard disk with more free space on it,
type "CFIG386 3DS -SWAPDIR X:" where X: represents the drive
letter of the hard drive you want to use. You will now see
two -SWAPDIR variables in the list. This is O.K. 3D Studio
will use the last one that it finds. For more information
about CFIG386, refer to the installation guide [page 9 and
page 108].


   9999 rendering machines on the network, 9999 rendering
  machines. If one of those machines should happen to fail,
                           9998...

I've been asked, "Wendel, you have a network with hundreds
of machines on it. Can you really have 3D Studio running on
all those machines at the same time? The documentation says
you can link up to 9999 machines." The answer is Yes and No.
You can have up to 9999 machines set up on the network, but
you shouldn't have them all working on the same job at the
same time. The amount of network traffic going to that one
little control file will freak out the network. So, if you
have a thousand frame animation that you are going to
render, and 100 machines on the network, you can set it up
so that machines 1 through 20 render frames 1 through 200,
machines 21 through 40 render frames 201 through 400, etc.
Each one of these mini "network farms" would have its own
subdirectories and net paths set up on the seperate machines
so each set of  slaves would use a unique set of network
control files. You can link up about 20 machines on a single
job using a client server network, and 5 machines on a
single job using a peer-to-peer network, before the amount
of network traffic will start to slow down the job.

In all cases, you are going to want to minimize the amount
of network traffic. By copying texture maps, IPAS routines,
etc. down to the slave's local hard disk, you minimize the
amount of times the computer must access the network, and
consequently, minimize the chance of  a network failure.
This is especially true of peer-to-peer networks. Very few
peer-to-peer networks, sometimes referred to as "lite"
networks, were designed to handle the amount of network
traffic that 3D Studio network rendering can generate. On
some of these networks, you will begin to see a noticeable
performance decrease as the amount of network traffic
increases. To avoid this as much as possible, limit the
amount of network traffic, as noted above.


                   Using Network Rendering

So now we've got our network set up. The first thing to do
is make sure all the machines are looking in the same
subdirectory on the network for the control files. Do this
by going around to all the machines, and starting them in
slave mode for 3D Studio (type "3DS SLAVE" at the DOS
prompt).  The result is that 3D Studio starts, and
immediately flashes up a dialogue box that says "Machine in
SLAVE mode. Press escape to cancel"  (since we started from
DOS without a hardware lock, pressing escape will take us
back to DOS, not to the 3DS interface). Once all the
machines are in slave mode,  go to the master machine (the
one with the hardware lock) and start 3D Studio normally. To
see if all the machines have been recognized by the network,
follow these steps.

Select Renderer/Render View from the side menu, and pick in
one of the viewports. It's O.K. if you don't have a model
loaded at this time.

In the Render still image dialogue box, highlight the Net
Queue button at the bottom, then select render. If your
display is not set up with a set resolution and aspect
ratio, you will get a warning box that says " Render
width/height and aspect ratio settings are blank and...".
For this test, this is O.K. Normally, you would want to set
a specific height and aspect ratio for rendering.  Select
Yes to continue.

Since this is the first time you will be starting the
network render features, you will get a dialogue box that
says "MCS does not exist, create it?" This is good. Answer
Yes.

Two dialogue boxes will pop up at the same time. The one on
top is the Network Queue Entry box. In this box should be
the names of all the machines that are available for
rendering at this time. Scroll through the list and see if
all the machines you set up are there. If one or more is
missing, that means that the NET-PATH variable in the
3DSNET.SET file on those machines is pointing to a different
subdirectory than all the others. You can correct this, and
then do these steps again to make sure it is now pointing to
the right location.


    The Slave/Master  Relationship...or...How to become a 3DS
                         dominatrix

I see the glint in peoples' eyes when they talk about the
Slave/Master relationship and 3D Studio. Alas, the truth of
the matter is not as exciting as it would sound. Being a
slave in 3D Studio simply means that a particular computer
is controlled in its rendering tasks by another computer on
the network. The computer that initiates the process is
called the Master machine. All computers that are set up to
participate in this massive rendering effort are called
slave machines. The fact that the computer operator is
wearing black leather chaps and a dog collar has no bearing
on the terminology used.

Using network rendering is as easy as selecting the render
button. One of the keys to using it effectively, however, is
knowing how to select your machines. Your first choice when
performing network rendering is NET QUEUE or NET ASAP.  The
NET QUEUE option will place your rendering jobs into a
queue, or job list, in the order that they are received.
Then as machines become available for rendering, the queue
will start sending out files to the various machines to get
the rendering job done. Naturally, if there are machines
available, and you place something in the Queue, it will
begin rendering as soon as you close the dialogue box. If
there are no machines available,  the job will just sit in
the Queue until there are machines available, or until you
decide to cancel the job entry.

NET ASAP sends a rendering job to the next available machine
or series of machines on the network. This will temporarily
interrupt a job that is being read from the Net Queue, but
it will not interrupt another NET ASAP job. So, for example,
if you have placed a 100 frame animation in the NET QUEUE,
and the machines on your network are currently rendering
frames 53, 54, and 55, when you send a job to NET ASAP the
computers will finish the frames they are currently
rendering, and begin working on the NET ASAP job. When that
job is complete they will return to rendering the job that
was interrupted. As a rule of thumb, you should always
render to NET QUEUE, so that you can interrupt that process
and then resume it should you need to.


             Questions and Answers about Network
   Rendering...or...Everything you ever wanted to know, but were
                        afraid to ask

I was accosted in the elevator by a group of people wearing
pocket protectors and forced to answer a series of questions
about network rendering. I don't think that they were a
bonafide street gang, just a group who took its networking
seriously.   That's one dangerous email group.


The first time I started the network Queue, It told me "MCS
does not exist, create it?" I said yes, but what was that?

The first time you start the network rendering queue, the
control files that are needed to perform the network
functions do not yet exist. When you said yes, the necessary
control files for network rendering were created in the
directory which you have specified as your network path.
Incidentally, MCS stands for MASTER CONTROL SCRIPT file.

If you ever see this message again, then something might
have gone wrong (unless you are setting up an entirely new
network configuration, of course). If you see this message,
that means that the machine you are using does not have
access to the control files that have already been set  up.
This might mean that you forgot to log on to the network, or
that the files have been moved or erased. If this happens,
that is OK, you just have to make sure, again, that all the
slave machines and the master machine are pointing to the
same subdirectory on the Server as your network path.
Otherwise, some of your slave machines will not be
accessible to the master machine for rendering.

By the way, if you ever try to access the MCS and your
machine crashes or you get an error message, it is possible
that the file on the network has gotten corrupted.  It is
O.K. at any time to delete all the control files that are
stored on the network file server. So, just delete
everything in that subdirectory on the file server and start
3DS again. when you access the network queue, it will give
you the MCS does not exist message again, as if this was the
first time.


What is the difference between ANY or ALL?

Selecting the ALL switch at the bottom of the Network Queue
Entry dialogue box will mark all the machines that are
currently available for rendering as machines that you want
to use for the project you are rendering. You can also
deselect a machine that you don't want included in this
list. When you select render, those selected machines will
begin working on your rendering project.

Selecting <ANY> from inside the dialogue box's list window
is your way of saying "Use any machine that is now available
or might become available in the future for my rendering
project". So if you have 5 machines in the list, and you
select <ANY>, those 5 machines will begin rendering. Then,
later if you place a 6th and 7th machine into slave mode,
those machines will join into the rendering process already
in progress, so all 7 machines will be working on the one
project. (This is different from ALL. If you add machines
when you selected ALL, the new machines will not begin
rendering the job that is already in progress.)

You can also deselect machines from the <ANY> process. This
would be saying:  "Use any machine that is now available or
might become available in the future for my rendering
project, except the ones I just marked".


Why would I want to exclude a machine from my network
rendering?

The most common reason would be that you know you will need
that particular machine before the network job will probably
be finished. If you take that particular machine out of
slave mode before the job is finished, then the frame of the
animation that machine was working on will not be rendered.
This means you will have to figure out which frame it was,
and then re-render just that one frame to complete your
animation.

Another possibility is that one of the machines is much
slower than the others on the list. If it might take longer
for that one machine to render one frame than it does for
another machine to render several, you might find yourself
waiting at the end for this one slow machine to finish its
single rendering when all the other machines had finished
some time ago. (As a general rule of thumb, slave machines
on your rendering network should be just as robust as your
regular 3DS machines. This means as much RAM and hard disk
space as possible. Using your secretary's 386/20 with the 40
meg hard drive when they go home at night would probably not
be a good idea for network rendering.)


How do I get my master machine to render as a slave as well?

Once you initiate a network rendering job, the Network
control files take over. The master machine is no longer a
part of the process. So if you had selected <ANY>  as your
machines that you are rendering to, putting your master
machine into slave mode afterwards will make it available
for the rendering process in progress.


Can I set up network rendering to run as a background
process when I'm running 3DS under windows?

You might be able to get it to work with enough fiddling,
but I sure wouldn't recommend it. Even under the best of
circumstances, Windows is not considered adequate for a
production environment. Also, in most cases applications
that are running in  a DOS window are halted when they are
sent to the background. This is a setting you can change,
but depending on the application, you will be taking so many
resources away from Windows, or vice versa, that background
"multitasking" doesn't ever really work too well with
powerful applications.


What's the difference between the "LOCAL", "SERVER", and
"CUSTOM PATH" file output settings?

These are the three different ways you can tell 3DS slave
machines to save files in particular locations. The first
one, LOCAL, says to save the file to the local hard drive.
***WARNING-DANGER WILL ROBINSON!*** This means local to the
machine that is performing the rendering. That means on the
hard disk of the slave machine - NOT - the hard disk of the
machine that you are working on. If you are rendering to 5
slave machines, and you select LOCAL file output, you will
be saving files in 5 separate locations, none of which are
on the machine you are using right now (unless you select
<ANY> and then throw this machine into slave mode as well).

Choosing SERVER will send files to the subdirectory listed
under the SERVER-OUTPUT- PATH in the 3DSNET.SET file or the
Network Parameters  (Configure) dialogue box. Usually this
will be the same subdirectory on all the slave machines. For
example, all the machines would have SERVER:\3DSNET\IMAGES
on the file server listed as their output path. Remember,
however, that you could have machines sending files to
different locations with this option as well. If the
settings in one 3DSNET.SET file are different from the
settings in another, you will be sending files to two
separate locations, even though you chose SERVER.

CUSTOM-PATH file output is just that. You type the path that
you want your images to be placed in. Again, you have to
remember that it is the path as the slave machine sees it.
So if you type C:\PROJECT1\PICTURES as your custom path,
each of your slave machines must have this path available on
its hard drive, and you will be saving your files to your
individual slave machines' C:\ drive, not in one central
location.


So how do I save files in one central location? And can I
ever save them on the MASTER machine's hard disk?

If you are using a Client/Server network, the only central
location where you can store your files is on the server
itself. Choose SERVER as your output file destination. Make
sure that the SERVER-OUTPUT-PATH is pointing to the same
subdirectory on the server for each of your slave machines.
With a Client/Server network, there is no way to save all
your files centrally on the MASTER machine's hard disk.

If you are using a Peer-to-Peer network, you can save all
your files in one central location on whichever machine has
the most disk space, or on the master machine, or wherever
you like. You will accomplish this using drive mappings and
using the LOCAL option to save your files.  One of the
things Peer-to-Peer networks do is link hard drives
together. So you can set up a drive mapping that says the
hard drive on machine A is accessible to machine B as drive
letter F: (Are you confused yet? The person at machine B
will be able to read files, save files, run programs, etc.
directly off the hard disk of Machine A. Neat, huh?)

 Let's look at a specific example. Machine A has a directory
on its C: drive called C:\PROJECT1\IMAGES. You can now go
around to all the slave machines and map Drive F: equal to
the C:\PROJECT1\IMAGES directory on the master machine.
While you're there, change the NET-LOCAL-PATH parameter in
the 3DSNET.SET file to F:\ (Yes, smart alecks, you could
also use custom path to do this from the master machine, and
you wouldn't need to edit the .SET file. But this change
would not be permanent.) Now when you render and select the
LOCAL option (or CUSTOM, if you set it up that way), each
machine will save the image files to its own local F:
drive...which just happens to be C:\PROJECT1\IMAGES on the
master machine!


When I render, I get an error message box that says
"Warning: Render width, height and/or aspect ratio are blank
and network output is selected. Depending on the....". What
does that mean?

This means that in the render setup for the master machine,
you didn't select a SPECIFIC resolution and aspect ratio in
the DEVICE CONFIGURATION dialogue box. (You get that box by
selecting Configure... from the Render Screen or
Renderer\Setup\Configure from the side menus.) Not selecting
a resolution means use the defaults that are set up for the
video board in the machine doing the rendering. Now, you may
know that this means 640x480 (or whatever) and that it will
come up correctly on your machine, but other machines on the
network might be set up differently. The default on another
machine might be 320x200. When you tried to put these frames
together into an animation, they would be a different size
and aspect ratio. It just won't work. So specify a specific
resolution and aspect ratio, even if the machine you are
working on is already set up for the resolution that you
like. It will guarantee that all the machines on the network
render files in exactly the same format, resolution, and
aspect ratio.


My aspect ratio and resolution are set up properly, but the
images still look different from machine to machine. What
else can change?

Check the GAMMA correction values on each slave machine.


When I try to render a Flic file using network rendering,
only one of my slaves is activated. How can I split up the
rendering of a Flic file over several machines?

An FLC or FLI file is only one file when it is done. Thus
only one machine can be working on it at a time. If you want
to use more than one machine to render a Flic file, you can
do this by setting up the Render Configure options to render
to sequential GIF files. You will give up to a four letter
beginning for the file names, and 3DS will fill in 0000,
0001, 0002, etc. for the rest of the name on each sequential
file. In other words, the file name TEST* will produce
TEST0000.GIF, TEST0001.GIF, TEST0002.GIF, etc.  Once all the
frames are rendered individually, you can copy them all to a
single directory and compile them into a Flic file.

There are two ways to make the Flic file once you have these
images, using either Animator Pro, or 3D Studio. The easiest
way is to use Animator Pro. Use the NUMPIC utility in the
POCO pull down menu. Choose the "LOAD PICS AS FLIC" option
to make a Flic file.  If you don't have AAPRO, you can
accomplish the same thing in Video Post. Start a new 3DS
project, and move right into the Keyframer module. Select
Renderer\Video Post from the menu, and click on the active
viewport. Make sure the ADD button is highlighted, and click
once in the Queue column. You should see [KF Scene] appear.
Highlight the EDIT button, and then click on the words [KF
Scene]. The Queue Entry dialogue box will appear. Highlight
BITMAP and then click on the box just to the right of that
button. A file selection box will appear. Type in the first
four letters of the files you created followed by  an *,
then the extension (i.e. REND*.GIF) and select OK. The
bitmap name (with the *) should now appear in the box next
to the BITMAP button. Select OK and in the Video Post
dialogue box, select RENDER. You will now get the familiar
Render dialogue box. Make sure you are configured for FLIC
as your output file type and hit the RENDER button on the
bottom of the screen. When finished, you will have a flic
file from the original GIF files. You can now delete those
GIF files. (Check to make sure it worked first, though.)

Alternatively, to render a flic over several slave stations,
you can render your animation in ranges, and send each range
to a specific slave. In a 500 frame animation, for example,
send frames 1-100 to slave #1, frames 101-200 to slave #2,
etc. Each of these entries would be a separate job in the
network queue. You will then need to splice the five
resulting flic files together using either Animator Pro or
Video Post in 3D Studio.


Do I need to install the entire 3D Studio and all it's
support files?

No. You can delete any files that are not going to be used.
This would include texture maps, materials libraries, sample
meshes, project files, etc.  For the bare bones, absolute
minimum 3D Studio installation, you would need these files:

3DS.EXE
3DS.RES
3DS.SET
3DSNET.SET
VG920922.RLM
VIB3DS.VLM
VIBRANT.RES



           When bad things happen to good networks

Sure this all sounds great. Of course I visited a friend of
mine who was trying to get his network up and running, and
over the course of the night he had pulled out most of his
hair. He started out with hair that looked like Mel
Gibson's, but by the end of the night he looked more like
Mel Blanc. Following are some questions and answers I've
heard that might help you troubleshoot when problems arise.


What causes a machine to fail?

Assume that the network is up and running properly. I know
that is a big assumption on my part, but let's just pretend,
shall we? Assuming the network is up and running properly,
and all the machines are in slave mode and accessing the
same control files, there are really only two reasons that
an individual slave or node on the network will fail during
the rendering process. The first is that the slave machine
asked for a resource of some type and didn't receive it, and
the second is that the MCS sent a request to the slave but
couldn't find that computer on the net.


So...the slave would like a drink of water?

Yes, slaves make requests. They request files from the
network, they request texture maps, they request IPAS
routines, and more. All of these resources need to be
available to the slave machine in order for it to render
properly. This means for texture maps, you need to have a
directory for your texture maps in the MAP PATH of every
slave machine, not just the master machine. If you call an
IPAS routine, that routine has to be in the PROCESS
subdirectory, or wherever you point to it in the 3DS.SET
file. In other words, everything needs to be accessible to
the slave machine as if it were the only machine doing this
rendering.

The other thing to be careful about is shared files. Even if
you place all your MAP files in a subdirectory on your
server, and all your slave machines have that directory in
their map paths, they still might not be able to find the
file. This is because of the limited file sharing
capabilities of many networks.  If two slave machines ask
for the same file at the same time, unless you have some
pretty sophisticated networking software which allows
simultaneous file access, one of those machines will fail at
that point. Some network software can handle this scenario
with no problem, some network software also requires you to
load the DOS SHARE.EXE program, and some network software
will just never be up to the task. They will all SAY that
they can do it. Perhaps if we were sharing spreadsheets or
word-processing documents we wouldn't have problems, but we
are dealing with massive files that need to be handed to
these slave machines with split-second timing.

Bottom line, if you have a machine that is failing, watch it
as it tries to render. If it crashes when it is loading
materials, or trying to load an IPAS routine, then copy all
those files to the local hard disk and try again. Make sure
you copy all the needed files. If it is looking for a file
that it cannot find, you can watch and see just when the
system fails. Chances are you missed a file that needed to
be in a MAP PATH.

Another way to help diagnose why your network rendering
projects might be failing is to look at the log file that is
generated with each process in the Network Queue Control
dialogue box. Select VIEW LOG at the bottom of this dialogue
box, and then highlight the process name in the Control box.
Remember, when you delete a process from the control box,
you delete the log file as well. If you want to save the
log, you must select the SAVE option in the VIEW LOG screen
to save the log as another file, before you delete the
process from the Queue Control dialogue box.


Did someone say split-second timing...

Yes I did. It bears repeating. Network rendering requires
split-second timing in order to work. This means your
network software needs to be up to the task of distributing
files when they are requested. If it is not, then you had
better copy those files to the local machine's hard drive.

There is another point where timing is crucial. Each of the
machines on your network needs to be synchronized for date
and time. If one machine says it is 3 in the afternoon, and
another thinks it's 10 in the morning, problems can arise
(it's the same way with your co-workers). On most networks
the "window" or margin of error that you can be off from one
machine to the next is less than 10 seconds. However, on
some of the peer-to-peer networks, like Lantastic, if any
machine is more than one second out of sync,  problems may
start to crop up. Most networks have a tool that will sync
the date and time of your workstation to that of the server.
On some networks this happens automatically whenever you
login. On others there are commands that need to be run in
order to accomplish this. Many users prefer to place these
synchronization commands in a batch file or login script
that is used to start the slave machine.
This way as soon as they login to the network they are
automatically re-synced to the network clock. Whatever the
case on your particular network....SYNCHRONIZE! (Wow, I be
hypnotized, then synchronized. )



                         Conclusion

This is intended to be a living document, so any feedback
that I get will be included in future releases of this
paper. Since I am trying to remain somewhat anonymous,
please address your comments through: Brian Rudolph on
Compuserve Information Service (71722,170); or:

Autodesk Inc.
Product Support
2320 Marinship Way
Sausalito, CA 94965


Sincerely,

Wendel Oliver Williams
WOW/BR