The WorkSpace EditorThe WorkSpace Editor Introduction
How To..
Workspace Settings
Search Paths
Resource
Locations
Directory Maps
Setup
File Menu
The WorkSpace editor provides the RAT applications with a simple set of interchangeable project and resource locations. It also provides an interface, when using MTOR, between the Maya and the RAT project location. The primary feature behind the WorkSpace editor is to provide an interface to search paths and resource locations that can be quickly changed and edited depending upon project needs.
A file 'RATWorkspace.ws' is created in the current Root directory that is used to specify additional search paths and resources beyond the defaults provided during startup. This file allows all applications to share the same workspace settings across similar Root locations.
An important aspect of the search paths in the workspace are the ability to resolve both absolute and relative path names. All relative path names are resolved relative to the current Workspace Root. Relative path names are particularly useful in their ability to allow projects to be portable between different machines. If all a projects resources are relative to its root directory, then that entire structure can be easily moved between machines without having to worry about differences in network topologies. Most RAT applications will attempt to use relative path names whenever possible unless the prefer Full Paths preference is set.
The WorkSpace Editor works in two basic modes. The first mode
provides each RAT application with a description of the root (or project)
location and optional search path information. The second mode is
used in conjunction with MTOR. In this case MTOR controls the root
directory location as specified by Maya. Thus the WorkSpace editor
provides no control of project location in this case, just search paths
and resource locations.
Override Project Settings - two options are available for overriding certain project options:
Relative Vs. Absolute Path Names - The primary advantage
of relative path names is their increased portability across different
NFS mount points and machines. Whenever possible, it is generally
preferable to use relative path names. In cases where data is always
stored in one location then an absolute path name can be used (if only
to assure that these resources are always used regardless of project location).
Generally, Server Paths will be absolute, while Project Paths will be relative
 |
|
All settings for the RAT workspace file can be set within this dialog
window.
Changes to the workspace settings can be committed by pressing the
Apply button, or by selecting save in the file menu
Search Paths
Search paths are used by RAT applications to find needed resources. Two different sets of search paths are provided.
Search paths can be rearranged within the current path list by dragging and dropping the paths. Directory locations can also be dragged between different project setting dialog windows.
Search paths can be specified based on resource type. The "default" search path will be used by resources which have an empty type-specific search path. If the search path for a resource type is not empty it will be used instead of the default search path. Note that the default does not serve as a fallback when a resource is not found in its non-emtpy type-specific search path. The list of resource types is based on the WSSearchPath.* and WSServerSearchPath.* prefs located in the default RAT.ini as follows:
# Searchpaths can be specified by resource type to avoid unnecessarily
# broad searches. The following search paths will be editable in the
# workspace editor. If the search path for a resource type is empty the
# default local or server search path will be used instead.
# If the search path for a resource type is not empty it entirely
# replaces the default local or server search path.
SetPref WSSearchPaths.archive {}
SetPref WSSearchPaths.palette {}
SetPref WSSearchPaths.procedural {}
SetPref WSSearchPaths.shader {}
SetPref WSSearchPaths.texture {}
SetPref WSServerSearchPaths.serverarchive {}
SetPref WSServerSearchPaths.servershader {}
SetPref WSServerSearchPaths.servertexture {}
# Uncomment any of these to make them editable in the workspace editor
#SetPref WSSearchPaths.display {}
#SetPref WSSearchPaths.vfxmaster {}
#SetPref WSSearchPaths.vfxinstance {}
#SetPref WSServerSearchPaths.servervfxmaster {}
#SetPref WSServerSearchPaths.servervfxinstance {}
#SetPref WSServerSearchPaths.serverdisplay {}
The strings above like texture, shader, etc can be anything you want, and the workspace object will keep track of them, but the only ones
which are output to RIB as "Option searchpath" calls are the ones listed in the prman user's manual under the PRMan Options section. Those are:
shader, texture, vfxmaster, vfxinstance, display, archive, procedural, servershader, servertexture, servervfxmaster, servervfxinstance,
serverdisplay, serverarchive.
Scripting Workspace Search Paths
Methods like GetSearchPaths, SetSearchPaths, AddSearchPath have always accepted a "which" arg, which had to be either "local" or "server", and
those still work, or you can supply an arbitrary other type, like "texture".
GlobalizePath now takes an optional reztype arg which defaults to "local", so this shouldn't affect any existing scripts.
workspace GlobalizePath {path {reztype local}}
ResolvePath has changed. There's a new optional reztype, and it's been inserted in front of the other optional args. This may be annoying for existing scripts, but I figured it might be more annoying to be required to supply extensions and format everywhere...
workspace ResolvePath {path {reztype local} {extensions {}} {format ""}}
There's a new method called GetSearchPathTypes which accepts either local or server as its arg and returns a list of all the local or server types:
workspace GetSearchPathTypes {{which local}}
The Resource Locations tab provides a mechanism for specifying the locations and names of the directories used by the RAT applications. These paths can be either relative or absolute path descriptions. In the process of using RAT applications any one of the resource locations will be created as needed.
Directory mapping allows a substitution to be applied to some left-hand portion of absolute paths encountered by RAT applications. This functionality can be useful for distributed rendering or transfering a project from one system to another.
A directory mapping is a triplet consisting of a from-path, to-path, and zone. A mapping is only relevant on systems which are in the same zone as specified in the map. When an absolute path is encountered, the first mapping (with the appropriate zone) whose from-path matches some portion of the beginning of the absolute path will be applied. No more mappings in the list are applied beyond the first match. Also note that matching is both case and slash insensitive. The paths must be entered in UNIX style notation like p:/path/goes/here or //machinename/mountpoint/directory. Use forward slashes (good: "/"), not backslashes (bad: "\" ).
A default zoning scheme based on network file system type is set up in the factory RAT.ini file. Systems running on win32 platforms are considered to be in the UNC zone, while unices are in the NFS zone. In other words, a pref called WSDirmapZone is set to be either UNC or NFS during RAT initialization. When adding a new dirmap in the workspace editor, you'll notice a selection menu in the zone field; You can't type in just any arbitrary zone. This zone list can be edited via the WSDirmapZoneList preference in RAT.ini. The list consists of NFS and UNC by default.
System administrators who are interested in implementing a different zoning scheme at their site need to be aware that the RAT.ini is not the only place where zoning information is specified. As you may have guessed, directory mapping is also understood by PRMan, which looks for zone information in rendermn.ini; Look for lines like "/dirmap/zone/intelnt UNC" in the default rendermn.ini. Dirmaps are passed from the RAT workspace (project settings) into the mtor-generated RIB file. That's how prman gets a hold of them, but PRMan still needs its own mechanism for determining what zone it's running in (hence the zone information in both RAT.ini and rendermn.ini).
Finally, dirmap support has also been added to the Alfred dispatcher. This functionality comes into play when directory mapping is used in conjunction with distributed rendering. In order for the dispatcher to identify the zone of each server, zone information needs to be added to server slot definitions in the master alfred.schedule. The appropriate zone and machine architecture should be included in each machine's service key: "NT zone=UNC" or "Linux zone=NFS" or "SGI zone=NFS". This info can be added to Alfred's Master Server List (via Alfred-> Scheduling-> Master Schedule)
Here we see that Gurgle's zone is defined as NFS running Linux.
See the Alfred release note on Dispatcher Dirmap Support for more information on setting service keys for dir mapping.
Under the "Workspace File Search Paths" sub-tab of "Settings" you can specify a list of paths which should be searched for RAT workspace files when a Maya project is loaded. By default, the list consists of just $WSRoot, which means that workspace files are looked for in the root directory of the project. You may want to have a master workspace file which lives outside of the project root and is referenced by multiple projects.
The "Workspace File List" is a list of workspace file names which should be loaded if found in the workspace file search paths. The default name that is searched for is "RATworkspace.ws". You could, alternatively always look for a default filename first, followed by one reserved for user-specific settings; Both files, if found, would be loaded, but the second could override settings in the first. For example, the workspace file list might consist of "RATworkspace.ws" followed by "myRATworkspace.ws".
The "Workspace File Search Paths" are stored in a pref called WSFileSearchPaths, and the "Workspace File List" is stored in the WSFileList pref. Both prefs are set up with values mentioned above in the default RAT.ini.
|
Pixar Animation Studios
|