Discussion Forums

The Latest...
Smedge has moved on. Now you can get the ease of use of Smedge 2 with the power of Smedge 3 in the new Smedge. Check out the Smedge Downloads page to download the updated Smedge for Windows, Mac, or Linux and get started right away.

See Robin's homepage.

The Way of Smedge

• The Smedge Interface
• Clients and Servers
• Jobs
• Packets

The Smedge window in action. The main window is divided into three areas. In the top area, you can choose to look at either a list of all the packets currently rendering or a list of all the clients that are connected together. The middle section shows a list of jobs that have active packets rendering. The bottom section shows the queue of jobs. You can sort the lists by any of the columns in the lists.

Every aspect of Smedge has been designed to be easy to use. Most elements are self explanatory, and almost every dialog box has context sensitive help. Click on the little question mark icon in the corner, then click on the item you want information about.

Smedge is really designed to be left running all the time. Design decisions made early in the development of Smedge caused the program to be written as a single easy to use application rather than a Windows NT based "Service." These considerations were both ease of setup and use by the end user and limitations in the multi-user design of the Windows operating system. While Smedge will continue to work if you open and close it all the time, it will be more effecient and maintain and display better information if you leave it running.

Smedge is a "Peer to Peer" networking application. This means that there is no central Smedge Server that must be running at all times. (Note that you can specify a dedicated server in Smedge #31 and later.) However, the notions of "Client" and "Server" are used in a specific manner inside of Smedge.

A Client is any computer that is running Smedge. The Client portion of the program does the real work of Smedge: the rendering of packets.

A Server is one specific instance of Smedge that acts as a dispatcher for all of the Smedges on your network. This is how Smedge can make sure that two computers don't try to work on the same packet at the same time.

Any Smedge client can act as the server. You can see the IP address of the server by looking in the about box of any Smedge that is connected. You can tell if Smedge is connected by looking in the bottom corner of the window for the "Connected" text. Should the server machine shut down (if the user closes Smedge on that machine, shuts that machine down, or that machine crashes), one of the other Smedge clients on the network will take over as server. Because every client maintains a list of all the job information, there should be no loss of data when this happens. It is normal for Smedge to take a few seconds to connect to the new server and resume normal operation.

With Smedge #31 and later, you can dedicate a specific machine to act as server. This process is a little more complex to setup, but can provide more stability. For more information see Specifying a dedicated server.

For more information see The Smedge Client.

The central piece of information that Smedge deals with is a Job. The job contains the information that tells the client what to do. It contains:

• What product to use
• A job name (for informational purposes only)
• The scene file to render
• A project for that scene (in some cases)
• The range of frames to render
• The size of the packets to use
• Any extra parameters to pass to the renderer
• A priority
• and A Pool

The specifics of jobs can be dependent on the product. For more information see The Smedge Job.

The last two items listed are used by smedge to know how to distribute a job to the clients. The priority of a job determines what order jobs are rendered in. Higher priority jobs are rendered before lower priority jobs. If a job has a priority of zero, packets for that job are not sent out to be rendered. This is like a pause option.

Groups of clients can be assembled into Pools. The job is assigned to a pool, and will have priority on machines in that pool over jobs not assigned to the pool. You can decide if a client is allowed to render jobs in pools that the client does not belong to (see The Smedge Client for more information).

Note that pools override priorities. A machine will render an "in-pool" job before an "out-of-pool" job regardless fo the priorities of the two jobs.

If the pool and priority of jobs are the same, they will be rendered on a first come, first served basis.

A Packet is a portion of a scene that will actually be rendered by a client. Packets are determined by the Packet Size parameter of the job, and are in units of frames.

For example, if you have 50 frames to render and set the packet size to 5, the scene will be broken into work units of 5 frame each. The first packet will contain frames 1-5, The second packet will contain frames 6-10, and so on. Each client asks for a packet to render. The server will start with the first packet. As the client finishes a packet, the status of that packet is updated, and the next packet will be dispatched. Packets are dispatched in this manner until every packet has been sent.

The packet method of distribution has advantages and disadvantages. Because the granularity of packets is smaller than if you just divided up the total frames by the total number of clients, you can more effeciently use your resources if you have scenes that can very in time from frame to frame. However, there is overhead incurred in starting the rendering application for each packet, so it is not always wise to simply use single frame packets.

A compromise is set your packet size for your particular needs. If you have a job that renders really fast, use a larger number. If you have a really slow render, use smaller packet sizes, even single frame packets. You will have to experiment to determine the optimum packet size for a different jobs based on your rendering clients and network.

For more information see The Smedge Packet.