One of the ways in which Mango facilitates the understanding of how people work and collaborate with each other, is by introducing the concept of “resources” and “resource types”.

resources are the different files that are made by the pipeline(or artist in the pipeline) and handed off between different pipeline steps. One of the key designs ideas of mango is to categorize and label the different kind of resources that are created in production to better understand the following questions…

What is the main purpose of the resource?

What step of the pipeline is best suited to create this resource?

How is this resource used by artist and producers (The Pipeline)?

How do we ingest this resource into different steps of the pipeline efficiently?

How do we keep every instance of this resource used through out the pipeline up to date?

this is illustrated in the following graph. (right click on the image and choose “view image” to see a larger version)

In this graph, we illustrate the relationship between different “resource types” in the lighting to composting pipeline. in this snippet of the pipeline the following 4 types of resources are used

WorkFiles

3d Elements

preComp

Paint

comp

in this scenario, work-files mostly deal with application specific files (.max, .ma, .mb, .nk). it is important to understand that in the mango pipeline “work files” in their entirety are not designed to be handed of to the next pipeline step (dough they certainly can be). instead the goal is to have a modular system, where the artist can build “work file” with everything that they need to get the job done, but only hand off the smaller chunk of work that his responsible for via the publish process. the next person in the pipe then collects all the available resources, built by the people before him/her, and and assembles a complete file that is then used to generate new or updated resources.

In this example the lighter makes a “work file” where he/she will load or create all the resources that he need to create the “3dElements” (image sequences) that will be assembled by the comp artist.

the roto paint artist will make a “work file” where he/she will paint out markers from a plate and render this clean “paint” elements so they can be used by the compositor

the compositor will make a work file in which he will composite all the 3dElements, Paint, and PreComp images sequences and render a final comp.

in this workflow, no artist really cares or needs an other artist’s “work file”. They only need to get the resources created by “work files”.

in the case of the other 3 resource types used (3dElements, preComp, paint, comp) they all share one thing in common, they are all images sequences. But just having a resource type called “image sequence” doesn’t tells enough about how this resource is to be used in our pipeline. By breaking it down into the the following different types, it becomes more clear as what the purpose of each image sequence is meant to do, and how it is supposed to be used by the next step in the pipeline.

Why not have different resource types for each application?the reason why all this different software formats are grouped together as one resource type is because they have a very particular purpose, and that is to create other resources. no other resources in our pipeline has the ability to create new resources other than work files. so we give them they own special category.

it it possible what so ever, that this file types will be used by future resource types, in wich this files will be used to hand over data needed for some step of the pipeline, but in this case the files would never be opened and worked on.

it’s also important to note, that by making the work-file resource type generic. we can more rapidly add new software package to the pipeline… seance of all the tools dealing with work-files won’t have to be updated to account for a new resource type.

with that said Mango does track what application made the work file. and as to stream line the process of finding workfiles that belong to a particular software.

Unique Storage location per resource typeone of the benefits of splitting resources into this “purpose descriptive” types, Is that it allows us to split the storage across multiple drives or servers, An example of this can be storing all image sequences of type 3dElements on drive x:, while storing all images sequence of type comp in Y:. A studio has the option of using as many different storage server as there are resource types.

Expandability

One of the main benefits of building a pipeline with the concept of resource and resource types, centered around the idea of “Work files” that out put axillary “resources”, is that growing the pipeline to cover new techniques and technology becomes much easier, by simply introducing new resource types, and rules that govern how this new resource is going to be handed off.

this means additions can be made to the pipeline with our affecting any all-ready existing methods and practices. or having to re-engineered major parts of code to account for new on though of practices.

Well folks, it’s finally here… just a few days ago Autodesk released it’s 3dsmax 2014 extension to those who are members of the subscription program.

This extension release is something that I’ve been very excited about ,and have been looking forward to ever since the new features were first announced.

Well thankfully the wait is over. I’ve spent some time today checking out the new implementation trying to figure out what this update will mean to future mango development for 3ds max (which I would rather do in python and PySide so that apps can float between Max, Maya, Nuke).

Anyway here are some of my first impressions along with some snippets from today’s familiarization session, I hope they might be insightful.

This is not Blur Python

While evaluating the new python implementation in max 2014, it becomes very hard not to compare it to Blur python. They are both CPython implementations. But that’s about where the similarities end. If you have experience working with Blur Python this first installment of 3dsmax python by autodesk is going to be somewhat of hard pill to swallow.
Unlike Py3dsMax(blur python), maxPlus (autodesk python) does not really expose the same set of libraries and methods that people familiar with maxscript already know and love. Instead it exposed a very small (it’s actually pretty large) subset of the max SDK, and relies heavily on the idea, that programers will do most of the max interactions by writing python string containing max script code.
This string are then to be evaluated by “maxPlus.Core.EvalMAXScript” python method. In my opinion this will alienate allot of people.

Those who are familiar with maxscript but are new to python will have to learn a whole new way of working with the limited set of exposed functions, and a brand new methodology behind creating and manipulating objects and data in max. Everything you know about max-script is now obsolete.

Those who looked at python as a bridge to write tools for max with out having to learn maxscript will still have to learn maxscript to access the majority of functions and methods available via maxscript.

I’m hoping that the awkwardness of MaxPlus is just due to it’s infancy, and that in the next year or so it will be expanded to equal or even best blur python. At first glance it seems Autodesk really did the bare minimum. We can only hope that this was a time limitation, and that they will continue to devote time to growing the max python ecosystem.

No Python.import

One of Blur Python’s coolest features was the ability to import python modules right into maxscript via the “python.import” method.
This was really great for production, since any max scripter could use python libraries straight in maxscript with out knowing anything about python. For anyone that has used this feature to quickly harness the power of python external libraries inside of their native maxscript code, this will more than likely be very sad news. I really hope Autodesk can bring this feature back since it opens up the power of python to a much larger sets of users.

Where is PySide/PyQt?

Well not surprisingly Autodesk has decided not include PySide or PyQt with it’s new implementation of Python. The fact that PySide doesn’t come integrated with this first release of python is incredibly disappointing. Especially since I have been running Blur Python (Without Qt) in 2014 for months now, the Autodesk implementation of Python is a major downgrade when compared to Blur Python. This alone will keep me from upgrading current mango clients to this new extension (mango currently uses blur Python).

I really hope that they will spend sometime integrating PySide by the time 3ds max 2015 comes out. Switching from Py3dsMax (Blur Python) to MaxPlus (Autodesk Python) is going to be painful, but a properly supported PySide module would really make the switch worth it.

DIY PySide?

While Autodesk failed to give us an easy to use PySide implemention similar to the ones natively supported in Nuke and Maya, they were nice enough to include some documentation that the more technically inclined can use to compile PySide (that’s right! you going to compile stuff!!) against the proper builds of qt and python that are now bundled with max (Python 2.7.3, Qt 4.8.2). From the documentation hints, I was able to actually make my own image of PySide that allows me to start using Qt inside of 3dsmax 2014. This process while a bit technical and esoteric, is actually not to difficult and requires zero programing experience, I recommend that anyone interested actually try it. If you are too lazy to do it your self, you can try using my compiled installer (use it at your own risk) , which can be found here .
After installing my newly compiled PySide build, I set to do some basic testing using the following snippets. My initial test was just a QMessageBox…

This messagebox was just a way to test that the PySide was actually being loaded and working in max, and that python could collect some data from max and pass it to Qt.

While I was writing this snippet there were a few things that I noticed that seem strange.

Modal windows have no effect on the max session. It’s not really clear to me how to parent Qt windows to the max application it self. So modal windows which would usually freeze max until the user close the dialog are not actually freezing max.

Executing a QApplication is not needed, doing so actually really screws up the max environment, the behavior makes seem as if qt and python are not running on the main max thread. But I’m more than likely just missing a step.

Other than those strange oddities PySide seems to actually be working. Even with out executing the QApplication I can launch dialogs add widgets via the .show() and exec_() methods. exec_() seems to have absolutely no effect on the max session itself (same as qmessagebox) which is very strange.

Even though Autodesk’s first version of Python for max leaves a lot to be desired, I’m vary happy that Autodesk has actually taken on the task of bringing this very important feature to max. Not having to depend on a 3rd party to provided python support will make it much easier for studios to migrate to feature version of 3ds max with out fear of breaking their pipeline. With today’s need for python and Qt in the never ending realm of unified pipelines an awkward implementation of python, and a ghetto home brew of PySide are much better than NO PYTHON and NO PYSIDE.

I’m looking forward to experimenting with Mango and 3ds Max using this setup, and seeing what new knowledge tips and tricks the community will bring forth in the upcoming months…

I’m happy to share with you guys a screen grab of the dependency viewer for “mango version viewer”.. view the versions associated with any element being reviewed any time any place with out out having to open the work-files them self’s
dependencies are hierarchical so that you can easily view them in a natural way…

Some one had asked for samples of animation setups i have done through out my career..
i lost allot of my work a few years back when my external drive died.. but recently i found this videos, which are a bit dated, but still hold a special place in my hart 🙂
anyway, if you are bored and looking for something to bore you even more check them out 🙂
httpv://youtu.be/FO3JVHBdwI8
httpv://youtu.be/6fQINze9c0I
httpv://youtu.be/307PdswKUJs

Some time has passed since my last Mango related post. Thankfully, I have made significant progress. I’m glad to announce that Mango Phase 1 will be completed in the next few weeks. There are three important developments which I will address in this post: resource-tracking, the Software Launcher, and user applications and tools (stand-alone and software-integrated).

Mango’s Resource-Tracking

Mango Phase 1 has been about setting up the structure on which the entire pipeline is based. I implemented base APIs that will support all of the core stand-alone applications and software-integrated tools. The two most significant APIs in this stage of development are:

versionTracker (API for versioning of resources with database backend)

namingAPI (API for generating the folder structure that host the files that make up the files associated with versions made by versionTracker)

These two main components come together to create a resource-tracking system. In Phase 1, the development of the resource-tracking system has been focused on the needs of smaller studios in rapid production environments. This focus allows smaller studios to start using resource-tracking without being overly intrusive or creating a bottleneck for the artist by over-departmentalizing the process. To achieve this implementation, Mango Phase 1 concentrated on establishing the standards and practices necessary for creating and tracking the main resource types that are the most important in the “generalist” environment. In particular, I have focused on artist “work files”, “render elements”, and “shot plates.” In Phase 2, I will move toward more detailed resource-tracking and implement new resource types for “models”, “rigs”, “animation caches”, “cameras,” and “shaders.”

Mango’s Software Launcher

The Software Launcher is the common entrance to the pipeline. It is a stand-alone application that allows supervisors to control the software configuration by creating unique profiles for their projects. These profiles control which software, plug-ins, third party tools, and extensions are used by artists on their projects. Profiles allow artist to jump between projects, while guaranteeing that every artist under the same project has the same set of tools. Moreover, this profile mechanism allows supervisors to adopt new software or plugin versions without unintended negative effects on concurrent projects. The Software Launcher and its profile mechanisms means that studios no longer have to rely on IT to push plug-in installations over large networks via more traditional time-consuming means that can be unreliable (e.g., MSI, Psexec, manual installations).

The connection between Mango and the artist’s software relies on the modular plug-in distribution system of the Software Launcher. Mango and its tools get attached to the target application via the “LosPipeLine” Software Launcher module which should be part of every Software Launcher profile. The Software Launcher also offers and optional command line mode. This mode is used to apply the profile-based software configuration approach to network rendering solutions, such as Thinkbox’s Deadline.

User Applications ( stand alone and software-integrated)

Additionally, the deployment of Phase 1 focused on the “hand off” of resources across the different disciplines of the shot creation process (e.g., how a lighter hands off lighting elements to a compositor). Mango is composed of several applications and tools, both stand-alone and software-integrated. These tools are easy-to-use interfaces for artists, supervisors, and managers to facilitate the adoption of the Mango workflow. Here’s a list of the initial set of applications and tools that are bundled with Mango Phase 1:

Project Manager (stand-alone)

Simple interface for quickly creating the base directory for a new project

Allows for adding sequences and shots at anytime to any project

Workspace Manager (Integrated with 3ds max, maya, and nuke)

Simple interface for creating and navigating artists’ work areas, work files, and snap shots

What is PTS?

A PTS (Production Tracking System) is a database that manages VFX/Animation projects and studio resources. This system helps producers, supervisors, and artists keep track of the multiple tasks that are required to successfully complete a show. It facilitates communication between departments and provides real-time reports on the current progress and cost of work. The PTS represents the integration of a “back-end” database (e.g., postgreSQL or MySQL) and “front-end” applications. The everyday user interacts with “front-end” applications which are designed to meet his unique needs. These applications can be stand-alone or integrated into third party commercial or proprietary software (e.g., task management application or resource publishing tools inside of Maya, Nuke, etc.).

Why is there a need for a PTS?

A well-designed PTS is integral to an effective studio. It allows artists, supervisors, and producers to find relevant information quickly. For example, an artist can see a list of incomplete tasks that are assigned to him. Then, a supervisor can use PTS to comment on the tasks which artists marked “ready for review” and keep a historical log of these comments. While a producer can use PTS to see which shots are over-budget and the human resources department can have a record of billable hours that are connected to specific tasks. Everyone involved in the production process is able to input and query this information through applications that are stand-alone and/or integrated with third-party commercial or proprietary software.

A few examples of common stand-alone applications in PTS are:

A Time-Card Application

creates an electronic record of billable hours in the database which replaces paper time-cards.

allows artists to connect these hours to a particular task which can be used to create more detailed reports.

A Task Management Application

allows supervisors to break large scale work into smaller easily-delegated tasks.

holds other important information to facilitate time-management (e.g., priorities and due-dates).

connects tasks to progress-tracking statuses (e.g., “in progress” or “awaiting supervisor review) which can be filtered by supervisors and artists.

A Dailies Application

lists all the image sequences sent by artists to be reviewed in dailies.

uses the versioning system in PTS to help supervisors quickly find older versions of the same sequence for comparison during review.

connects comments about the work being reviewed in dailies to the task that generated it to ensure the artist has a record of the notes.

A few examples of common applications which are integrated into third-party software in PTS are:

Publishing and Versioning Tools

help artists version their work while keeping a historical record of changes.

allow for easier hand-off of versioned work to the next step in the pipeline.

when necessary, allow artists to easily roll-back to previous versions of their work.

adds a layer of programmable quality control to ensure smooth ingestion into the pipeline.

allows lighters and effects artists to quickly know the resources that make-up a 3d scene.

allows artists to compare version information about the resources currently in the scene.

Alerts artists when scene resources need to be updated.

Scene Building Tools

Eliminates the need for multiple artists to work on the same file by allowing artists to build unique files with shared resources.

A PTS adds accountability and power to a studio because it automates some of the more tedious aspects of the VFX/Animation pipeline. A pipeline that revolves around a well-designed PTS allows artists to focus the majority of their time on art, rather than addressing technical complications that arise from keeping scene files updated. In addition, it gives supervisors and producers the real-time information that allows them to track the progress of work and make better choices which maximize the project’s profit.

Why is a PTS not as Common in Smaller Studios?

If a PTS is so wonderful, why is everyone not using one? There are four simple answers to this question:

Smaller studios don’t usually have the resources to employ full-time programers. So, developing and integrating a PTS into their pipeline is not cost-effective.

The culture of many smaller studios means that there are no uniform standards and practices about how scene files are created and shared. Therefore, their database (the “back-end” of a PTS) mirrors this complexity and quickly outlives its usefulness.

Popular expensive commercial solutions (e.g., Shotgun/Tank, FileMaker Pro, SharePoint) are a framework for a database but, they don’t offer uniform standards and practices. This leads to the previously described problem for studios who do not have strong standards and practices. Moreover, many of these commercial solutions don’t offer third-party integrated applications leaving studios to write their own.

These expensive commercial options still require the additional cost of Technical Directors to update, maintain, populate, and further develop these systems; sometimes greatly increasing the cost of integrating such a system.

While smaller studios have a very large incentive to invest in a pipeline that revolves around a well-designed PTS, they often don’t. The expense in time and money for an inadequate product is too much of a risk.

What is Mango?

Mango is an economical plug-and-play solution that is designed around how people actually work in VFX/Animation studios. It recognizes that many studios do not have set standards and practices which are a predictable and repeatable way of creating quality work (Modular Asset Pipeline Flow). Mango not only provides a uniform way of accomplishing this work, but it is a ready-to-use PTS that is modeled around a uniform set of standards and practices. In addition, Mango includes tools that will run on multiple applications (e.g., Maya, 3ds Max, Nuke, Houdini) to help enforce the uniform standards and practices without limiting artists creative ability.

Mango eliminates the need to have multiple programmers to mold the system to work in your studio. It greatly simplifies the nature of the database that you will use to track this work. Mango minimizes the footprint that these kind of systems can have in a studio pipeline. It fundamentally changes the way the studio works. In other words, Mango helps to create and monitor a more efficient studio work system by providing a full end-to-end pipeline.

When will Mango be Complete?

Mango is an on-going personal project on which I am working full-time from home. It is the result of 10 years of experience working in a range of studios in the VFX/Animation industry. The base for the PTS and several applications will be complete by the end of July. The development cycle is going to be rapid this is why I am researching tying together multiple open-source libraries and technologies (e.g., Python, postgreSQL, SQLAlchemy). Not only will this make my development cycle more efficient, but it also makes it more accessible to other programmers.

Anyway stay tuned, I will add more posts related to my findings about database programing for the VFX industry.

One of the main interests in my career has been developing a way in which I could optimize the process of creating and revising animated content in 3d through uniform standards and practices. My interest in this topic is rooted in my experience as a Character Technical Director (TD). A Character TD collaborates with many different departments. For example, he is the one that makes sure that models are technically sound for rigging. He also has to collaborate with animators to ensure that the animation set-ups are simple yet powerful enough for the animator to be able to achieve the desired performance. A Character TD interacts with lighting and effects to make sure that the animated performance transfers from animation department to the lighting department without breaking. He is usually in charge of adding more animated detailed to assets via simulations like hair and cloth. These are just a few of the responsibilities of a Character TD,basically, he has his hands in everything. Owing to their work responsibilities, most Character TDs frequently assume some of the responsibilities of pipeline development.

While I’ve been fortunate enough to work at studios that have had well-designed asset-based pipelines, I have worked at others that have failed to develop the standards and practices necessary to implement such a pipeline. I have drawn on these professional experiences in both kinds of studios to develop a specialization in writing 3D pipelines and developing this, often missing, set of standards and practices. The link below is an image of an up-to-date concept map of how assets should flow and can be developed through a pipeline. There are many benefits to implementing this kind of pipeline. A few of the most notable include:

Modeling, rigging, shading, lighting, effects, and animation can evolve parallel to each other rather than being linearly dependent. This monumentally increases the speed with which people can accomplish work by eliminating a known bottleneck.

It facilitates the tracking of different versions of a resource that form an asset and even allow roll-back. This ensures that artists always have the correct versions of resources on which their work depends.

It eliminates the need of transitioning from previs to postvis work. This avoids a common redundant step in many small studio pipelines.

This standardized asset flow allows for a very simple database model which is able to track and manage the work greatly simplifying the development of a PTS system (mango pts).

so very often TD’s look for ways to distribute their tools via menu’s. yet it has been my experience that using the code that’s documented can be really flaky seance any error half way through your code.. can make max go into to a weird state along with making your menu file corrupt all together (which means max my not start again for you until you fix this file). so while doing some work with manu’s i decided to put together a simple object oriented API that anyone could use to build this menu’s virtually with a limited number of commands..
the concept behind it is the new menu becomes a virtual object created by TD that he can append other items too.. once he is done appending this items he can commit his new menu to the ui, via the myMenu.commitMenu command.. pretty simple (i hope :D)

anyway the hope for this api is that TD’s can deploy menu’s faster, and with less code.. along with adding a separation of the building of the code, and the actual drawing of the menu’s.. in hope’s that bugs regarding the building of the data, will not corrupt any of the menu files of or put max in “strange limbo mode”

This is an other repost from an old blog.. i figure i transfer it over 🙂

Ok, so i started updating some scripts that I’ve used tabs for, this is what i have found so far.

the dot net controller syntax for tabs is..

dotNetControl axList "System.Windows.Forms.Tabcontrol"

this makes a tab controller with the variable name of axList
the previous activeX controller would make the tab group and give you one default tab,Â this is not the same for dotNet tabs. in dotNet Tabs you have to create each tab your self.

adding new tabs is very easy, here’s the syntax to add tabs….

Tab = axList.tabPages.add "myAwsomeTab"

tab information can be access through “tabPages”, for example to query how many tabs there are in the tab controller you can do this…

numberOfTabs = axList.tabPages.count

to query individual tabs you have to use add “.Item” and then the index of the node you want to acess, (keep in mind that dot net controller arrays start at 0 and not at 1 like activeX and maxscript arrays)

firstTab = axList.tapPages.item[0]

this will store the first tab in the tab controller to in the variable first Tab.

if you need to query the or change the selected node there are now two methods to do this

selectedIndex = axlist.selectedIndex
selectedTab = axlist.selectedTab

the last thing i found out is some simple way of changing the appearance of your tabs.

tabStyle = dotNetClassÂ "System.Windows.Forms.TabAppearance"

this give you a dot net class from which you can apply 1 of the the following 3 styles

this is what I’ve run into today, i don’t like how the tab’s are highlighted by default when selected i don’t think it is obvious enough. i will play around and see if a can find some good methods of changing that, i might play around with changing the color of selected nodes or something until then, good luck and good night.

This are some old notes, i had posted on another site regarding activeX to dotNet scripting… might be old news but i figured someone might find it usefull 🙂

So today i began to look into dot net controllers inside of max so that i can brake the studios current dependency on max 8 (activeX controller in max 9 don’t work unless 8 is installed),

and while it seem that the general work flow of the activeX controllers carries over to dotNet, there are allot of thing that are not documented and have become way more complex.

the main thing i noticed is dealing with object fonts, sizes, and styles such as bold italic etc, has become a bit more of a chore. here are some of the things i’ve found out, that i couldn’t find any where on the net.

when dealing with tree view nodes under activeX this is how you would change the text

node.font = "Tahoma"
node.fontsize = 7
node.bold = true

this has become a bit more complex in dotNet. a font is now an object value which is created out of sevral other objects and classes…

“fontfamily” this is the actual windows font to use

“fontStyle” this is the style of the text which can be bold , italic, crossed, etc