MOGFAQ

From WikiDocs

1 What is MOG?
- 1.1 Seriously, what is MOG?
2 What is a pipeline versus what is version control?
3 How Does the MOG Pipeline compare to Perforce?
4 How does MOG’s versioning compare to Perforce’s versioning?
- 4.1 The major differences:
5 What are the benefits of using MOG Library over Perforce for source art assets?
- 5.1 MOG’s Library Tab Advantages
6 What kind of system Integrity should be expected?
7 How scalable is MOG:
8 Packaging
9 Privileges
10 Changing Properties
11 Troubleshooting
- 11.1 Documentation Requests

What is MOG?

MOG is half man, half dog. It is its own best friend.

Seriously, what is MOG?

We chose the name MOG because our artists wanted us to call it Transmogrifier, a name that the programmers moaned was WAY too long to put throughout our code. So, MOG is a short way to say Transmogrifier. It was an added bonus that the name accurately describes what we do to data. While we don't use a cardboard box, what we do is no less magical for those using it.

MOG allows you to streamline the content creation workflow and you will see an obvious boost in the efficiency of your team. Artists become free to just be artists, programmers become free to program (rather than constantly tracking down issues associated with bad data that resulted from human error), and the entire team enjoys a higher level of collaboration.

MOG is a unique blend of traditional asset management and automation with a light twist of version control. Just because MOG contains some elements of version control, it is important not to lose sight of the fact that MOG is a content pipeline not just another Perforce. No other solution can offer teams such a wide range of solutions for so many of the age-old problems often found in game development.

What is a pipeline versus what is version control?

Version Control: The management of multiple revisions of the same unit of information. It is most commonly used in engineering and software development to manage ongoing development of digital documents containing critical information that may be worked on by a team of people. Originally created for tracking text-based changes in code. Only recently, has there been a lot of effort made by version control companies to better support the inclusion of binary data.

Most common Version Control Features:

Check-in/Check-out
File Locking
Branching/Tagging
Conflict Management (Merging)
Syncing
Remote Depots

Pipeline: A set of data processing elements connected in series, so that the output of one element is the input of the next one. The elements of a pipeline are often executed in parallel or in time-sliced fashion.

    Example:  An artist working in Photoshop must first collapse the Photoshop file to a single TGA
    image then execute a series of special post-processes on the file and finally use a proprietary 
    tool to convert the image to the desired, often proprietary format, required by the target platform.

Most common Pipeline Features:

Asset management and tracking tools
Automation
Asset Feedback loop
Asset Metadata
Workflow Control
Leverage existing ad-hoc tools

How Does the MOG Pipeline compare to Perforce?

It is important to distinguish why Asset Management is not just version control. Just tracking revisions of a file does nothing for complexities associated with the proper care, management, processing and flow control of an asset. A pipeline defines the process that each asset is subjected to when it is being prepared for the game and allows that process to be automated.

Because the development of a game is an ever-evolving process, it is inherent that there will eventually be a bad asset that finds its way through the pipeline. For this purpose MOG needed the ability to recover the previous version of an asset. Thus, there was a light Version Control Schema introduced to MOG and the confusion between MOG and Perforce was born.

How does MOG’s versioning compare to Perforce’s versioning?

To start off, MOG’s version control was built around the concept that the game is always moving forward. Each progression improves upon the last as the team slowly moves toward their end goal. Based on our experience, artists mostly need recent revisions with the occasional need to roll back to a previous milestone. We believe it is simply unnecessary for the daily workflow of an artist to be tracked for all time and eternity as it would be if checked into most other Version Control Systems.

The major differences:

Unreferenced Revisions:
This property in MOG allows the team to specify how many unused referenced versions should be kept
excluding revisions referenced by a past milestone or branch of the game. In addition, this
setting can be modified all throughout the project so that different types of assets can each be
tracked differently. For example, The project can choose to reduce this number for large assets
like Bink movies while at the same time increase the number for smaller assets allowing the
projects to maintain a consistent and manageable repository size throughout the development cycle.
Asset Containers are not Individual Files:
Pipeline assets are complex objects that consist of one or more imported digital file(s). These
asset containers include the originally imported files along with all the processed versions of
those files. Interacting with small collections of files as a single asset greatly improves the
manageability of the game data.

Repository:
In order to be as scalable as possible, it was important to obtain the fattest pipe possible for
the data transfers. Therefore, the MOG repository is stored on the File Server which has been
greatly optimized for large team environments. Not to mention the ability to leverage the speed
and scalability of an already existing File Server. The actual data structure of each asset
consists of a series of small directories which contain the associated files.
Time Stamp Based:
Because of the unique nature of MOG’s version control, unreferenced asset revisions are
automatically thinned as they fall out of date. Because of this thinning, asset revision
identifiers are time-based so that thinned revisions won’t leave holes in their number sequence
chains.

MOG’s overlap with Perforce allows the day-to-day art changes to be revisioned outside of the normal Perforce repository. If the project so desires, they can still periodically check in the packages/data to Perforce anytime they wish and not really affect how MOG's performs its primary pipeline functions.

What are the benefits of using MOG Library over Perforce for source art assets?

We should start by first explaining the history of the MOG Library. Originally, the MOG pipeline only encompassed the handling of exported data. Source art such as Maya, Max and Photoshop files were traditionally stored in external version control solutions. Because of client requests, and the fact that the core MOG technology already existed, the MOG Library Tab was added as an alternative source art file solution that supported the traditional check-in/check-out paradigm.

MOG’s Library Tab Advantages

    Auto thinning:
    Library assets automatically inherit the auto thinning features because they use MOG’s internal
    version control.
    Embedded Pipeline Properties:
    Library assets can contain embedded properties that can are retained between revisions.
    Source asset to final game asset relationships:
    Relationships between the original source art files and their exported/processed game files can
    be tracked.
    Integrated importing over to MOG user inbox:
    Easy one click importing of source art files into the user’s MOG inbox.
    Integrated branching:
    Branching the project also branches source art files contained in the MOG Library.
    Source assets are included with exported project snapshots:
    MOG project snapshots include source art files along with all the other pipeline files, 
    properties and settings.
    Simpler Interface:
    Artist wanted a simpler less programmer-centric interface for checking in/out source art files.

Although the move to include the MOG Library Tab was found to be helpful for many clients, it further blurred the boundaries between MOG and Perforce. It is important to note that the use of this tab is purely optional and can be substituted for any other external version control solution.

What kind of system Integrity should be expected?

MOG uses the File Server to store the actual data including asset properties. The SQL Server contains the asset’s metadata for fast lookup and reporting. Both the repository and database tables should be scheduled with regular backups to maintain proper system integrity.

In addition to traditional backups, MOG also allows the creation of a project snapshot that includes everything within the project making it easy to transport an entire project to an alternative MOG Server or location.

How scalable is MOG:

Every project has its own unique requirements. Some projects have millions of little assets while others might be limited to only a few thousand really large assets. Regardless, the MOG Pipeline needed to be scalable in both settings. For this reason, we divided the servers into the 3 separate components allowing a team to decide how to best specialize the hardware for their project.

    1)     MOG Server – TCP Traffic manager
    2)     File Server – Main asset repository
    3)     SQL Server – Asset metadata repository

The recommended hardware requirements are a good File Server capable of supporting the team, a beefy CPU for the SQL Server and a basic box for the MOG Server. Improving the performance of a File Server or SQL Server is a known and well defined process that can be custom-tailored to the specific needs of each team. In short, the scalability of the MOG pipeline is directly proportionate to the quality of the File Server and SQL Server.

    For instance:
    If you want faster update times for large files, focus more on your File Server.
    If large teams want punchy/fast interaction within the MOG Client, focus on the SQL Server.