Colorbleed: Mac 'n' Cheese Supermarket & Mr Probz - I'm right here

VFX
1

So i’ve been watching the forums here and I really like seeing all the work that has been done by everyone.
This time I wanted to share our latest two projects done here at Colorbleed, a company which might need a short introduction.

Colorbleed is a small new studio in the Netherlands focusing on animations for Short films, Music Videos, Commercials, etc.

Mac ‘n’ Cheese Supermarket
About two years ago we released our graduation project Mac ‘n’ Cheese which kickstarted our company.
Ever since back then we were trying to get funding to create a new episode in the Mac ‘n’ Cheese franchise, and we finally did.
Check it out here:
http://vimeo.com/77359213

//youtu.be/WdJ0LzQv8Ek

We used this project to really focus on our workflow and pipeline to get everything we do in the studio more streamlined.
This meant designing our own folder structure, incorporating Alembic into our workflow combined with our own shader relations (using JSON) format.

Alongside doing this we had to fill a supermarket with many products in a convenient way, so we wrote some display filling algorithms (raycasting for putting objects within the bounding box of the object.)
This was an ongoing development, so still many displays were ordered and filled by hand.
Though we could have never done this without even simple offsetting and ordering tools we built.

Between the first Mac ‘n’ Cheese and the second we switched from Mental Ray to V-Ray.
In Mental Ray with the bigger scenes we had a lot of incosistent errors during batch renders (random black frames/spots), also V-ray seemed to take up the bigger scenes much easier.
Also the vrayScenes allowed us to easily render totally separate from Maya, which probably reduced a lot of the errors.

Mr Probz - I’m right here
Together with dutch artist Mr. Probz we came up with a scenario for his new song I’m right here.
From the beginning he was looking for a new style that fitted the song, so this is what we came up with:
http://www.youtube.com/watch?v=gnlEJA4BRyI

//youtu.be/gnlEJA4BRyI

For this project we had 8 weeks of production time and about 3.5 weeks in we finally had an idea of what kind of style we wanted to do for this.
That’s when we started prototyping the first 3D visual designs, and especially how we could do this in 3D (and even in Maya…)
Somehow Maya natively was giving a hard time trying to do what we wanted for the prototypes so we quickly chose to write our own C++ plug-in.
In the end we wrote a system that allows us to project paint streaks (actual geometry) onto the existing geometry which is renderable with V-ray.
Then we started adding a toolset that allowed us to quickly visualize the streaks and gave the ability to tweak the size and amount on the different objects.
This was actually the first project we rendered on 4k; we chose to render it this size (after our first prototypes) because it allowed some more detail to come through in the end.
Luckily the technique really allowed for sizes like that: 5 frames rendered 5-15 minutes on a single workstation at 4k, that is 1-3 minutes per frame.

Hope you like it!

-Roy

2

Hey Roy, Thanks for sharing some info about these projects. My studio is always refining our folder structure and I would love to hear about how you ended up structuring yours. Can you talk a little about that? Also, I have only heard of Alembic but I have not yet used it. Can you elaborate on how you incorporated Alembic into your workflow and talk about some of the benefits it provided?

3

Yeah, I’ll briefly elaborate.

Folder Structure
As we graduated we had always worked with Maya’s (ugly) folder structure. We did categorize everything ourselves but we did mainly stick to scenes, sourceImages, etc.
So back then we would have:

  • scenes/animation
  • scenes/model
  • sourceImages/character/bob/

It was clean enough for the small teams/projects we worked with during school, yet when we started Colorbleed the first thing we wanted to change is the folder structure.
Because even though it did the job so far, we knew it would become a big bottleneck early in the process. So we took the liberty to start the discussion about workflow right from the start.

One thing we wanted to do is seperate the work files from the published files, in our cases we named these folders:
/dev/
/asset/

In other studios these would resemble:
/work/
/publish/

The DEV folder is structured in what we call workspaces (if you are more of a Shotgun guy you would call it a Step), this could be: Animation, Model, Lighting, LookDev, etc.
The ASSET folder is structured around the assets: Model, Renders, Resources, Shots, Audio.

If you would work on a model you would be doing your thing inside:
/dev/model/character/bob/maya/

Then we publish it to:
/asset/model/character/bob/

This looks pretty similar, (because model workspace is similar to the asset description: model) but the lookDev looks like:

/dev/lookDev/character/bob/maya/

Then we publish it to:
/asset/model/character/bob/shaders/
/asset/model/character/bob/textures/

And we also have some extra seperated structures outside of DEV and ASSET, like ‘art’ and ‘docs’.

Alembic
Alembic is basically a geometry cache format that contains all the mesh information, it’s (becoming) an industry standard that works well in a variety of applications (like Maya, 3DsMax, Softimage, Houdini, C4D).
Besides being a good exchange format it’s also a very clean, quite small and fast format for working with animated models.
In our productions we use it after the animation process to create a clean geometry cache that we perform the lighting on.

If you’re used to Maya Cache files, then instead of importing/referencing geometry and assigning a cache to that keep in mind that the Alembic file contains the geometry.
You aren’t required to assign it to an existing mesh.
A downside to this (as Alembic currently stands and I think it will likely stay like that) is that the format doesn’t contain the shaders.
In our productions it’s actually an upside, because this means that the preview shaders from the animation scenes are removed automatically, they’ll never be transferred.
To keep our rendering/lighting workflow fast after animation we wrote tools that after the import of the alembic could easily assign the shaders that were built in the lookDev workspace for a particular object.
We also support multiple shader variations per object in our asset pipeline, these variations can be assigned either in the animation scene and will transfer over to the lighting scene.
Or we could (for a quick fix) change the shaderVariation in the lighting scene and update the loaded shaders accordingly (through tools and scripts).

Does that help? :wink:

-Roy

4

Thanks for sharing and great work guys :slight_smile:

5

Hey Roy, finally on Tech-Artists, nice to see you here. We need more Dutch TDs here.

6

Thanks for the warm welcome guys! :wink: