I want to use this post to highlight the workflow I am using when working with blender and Mari.
To get an overall view of the features and capabilities of Mari, I advise to go to the Mari website and read through the material presented there.
I will concentrate here more on the differences between blender and Mari and how to set things up to straighten these out.
Disclaimer: The workflow shown here is based on blender 2.49b. The procedures and techniques portrayed in this post also apply to the current blender 2.57b. Blender 2.49b is used here, because I started Ara’s Tale at a time when blender 2.57 was in its early alpha state and I did not want to jeopardize my sanity by additionally to creating singlehandedly a short movie, fighting with alpha software as well. In hindsight this was a very wise decision …
Overview and analysis
The most obvious question is of course, how to get the model from bender into Mari and the painted textures back. Mari’s format of choice for object import is the Wavefont OBJ format, which blender is quite capable of exporting. The object gets exported complete with the desired UV set.
The usage of UV sets is where the differences start. Blender can hold a bunch ( I guess up to 16 in blender 2.49b) of different uv sets for the same mesh. When setting up materials (aka shaders) you refer to these uv sets by name when mapping a texture. This feature has a load of applications and is quite handy. A typical usage is to create a projection painting workflow inside blender were you paint through an image onto the mesh.
Well, with that all said, you cannot use this inside Mari, as there is only one uv set associated with a mesh, which I guess is a limitation of the obj format, but thats only a guess.
What Mari is using, and using quite heavily, are patches. This is something, which pure blender users are not really familiar with, as there is no direct correspondent feature available in blender. It can be mimicked though.
Patches are, as the name suggests, parts of a mesh with separately corresponding uv subsets. Each patch occupies a tile (size 1) in the uv space, but can be located ‘anywhere’. That means the real starting coordinate could be (10,4). With this you can easily organize complex objects and handle them as one piece.
The material system in blender can only map textures using uv coordinates from the 0-1 range. So what you typically do, is to unwrap your mesh and start to optimize the uv unwrapping to fit into a single uv tile with size 1. If you need extra details in a certain part you either increase the uv real estate of the associated faces or just increase the texture size for the shading. This quickly becomes very cumbersome if you happen to have several areas where you need high detail.
As long as you stay with this 1 tile approach there is not much preparation work to do before exporting your mesh to be used inside Mari. You have one patch, and that is quite easily handled by Mari. Thus the typical workflow used inside blender allows for a smooth pipeline.
But this behaviour always bothered me. During the texturing of the cliffs of the entry set, I tried several approaches all of them not very easy to use. I ended up with dividing the set into several objects each with their own material, uv sets etc. The challenge here was to paint the textures in a way that you do not see the object boundaries. This was tedious and an extremely time consuming job to do.
With Ara I chose another approach. Here I have distinctive parts which needs separate texturing but I wanted to have the object in one piece. This led the way to use multiple uv sets (for the head, each hand and the feet) and assign different materials to the parts of the mesh, where the used textures are mapped using the respective uv layer. This almost sounds like the patch approach described earlier. In this case I had not the problem of painting head and hands at the same time so the painting workflow was easier to manage.
With Ara set up in this way, there is no direct and simple road to a proper workflow blender->Mari, as there are no multiple uv sets inside Mari.
The tests with Mari and the texturing of the main set showed me an approach which is quite usable and requires (almost) no additional work but a little bit of different thinking 🙂
Mari needs patches, mapped into one uv set with each patch fitting into one tile of the uv set. I already have this division made with Ara, but now instead of creating a uv set for each ‘patch’ I create one patch uv set (which I call painting) and place the unwrapped sub sets to single tiles inside the uv space. One has to be a bit careful here, because blenders uv tools for unwrapping always create a mapping inside the 0-1 tile. But with proper selection and subsequent moving of the patches inside the uv space you are all set up.
Now this uv set is obviously not usable for any texture mapping inside blender. What I do next is to copy the painting uv set to a new one ( I call it render) and move all the patches back to the 0-1 tile. This creates overlapping uvs of course, but this wont be a problem. The faces forming one patch have their own material assigned and with this their own textures. With this you never experience the problems usually arising when using overlapping uv sets. So what I actually did here was to create a transformation between the different methodology spaces of blender and Mari. They are basically the same, but need just some in between translation.
Now you can easily export the mesh to an OBJ with the painting uv set applied, paint inside Mari and use the created textures inside blender but this time mapped to the render uv set.
Hands on example
After so much dry rambling, I show you now how this actually translates into the real world (aka with pictures :))
As I said earlier Ara was originally done the multiple uv set way, but I still had some problems with seams, which are partly due to me not working properly with blenders painting tools and partly with some shortcomings of blenders baking.
So this offers a perfect opportunity to showcase the transistion of the existing Ara to a new one which can be painted inside Mari.
Lets start with the setup of the original uv sets:
This is the Ara’s model as it is used during rendering. The parts which never show, because they are hidden beneath the dress are masked out and only the visible parts are shown.
With this I have the following uv sets:
Here we see an uv set for the head each hand and the feet. Also note the modifier stack with the used masking modifier.
The faces for each of the parts all have a different material applied. So there are a total of 4 materials associated with the mesh
Next is the process of setting up a painting uv set to be used by Mari. This can easily be done be reusing the head uv set and copying the uv sub sets from the other uv layers to this one ( ctrl-c in the viewport in edit mode)
With this all done I then move the patches to the desired tile and finally arrive at:
As organization principle I use the V axis. 0- head, 1 – hands and 2 the feet. This is arbitrarily chosen. You have to keep in mind though always to use positive coordinates, otherwise Mari will refuse to load the exported object. There is also a limitation ( baking limitation) on the maximum size u axis ( 10 ).
I then copy this uv set and move all the patches back to tile 0-1 which gives quite a mess 🙂
The next step is to export the object. We have to make sure that the correct uv set is selected for display/rendering, because the exporter will use the active uv set when exporting the mesh.
When exporting the mesh the exporter asks for some options and I use the following setup in this case:
Important here is the ‘Selection Only’, ‘Apply Modifiers’ and ‘UVs’ selection. ‘Apply Modifiers’ applies besides others the subsurf modifier which results in a denser mesh and is easier to paint with.
With this done the geometry is ready for import into Mari. But before I switch there lets have a look at the existing material/texture setup used for the Ara model.
I will take the head material as example. The material is node based and is derived (and heavily modified) from the 3 layer SSS setup found e.g. here.
This is an overview of the setup
Now whats important related to the workflow with Mari, is what textures are involved in this setup. There are a couple of texture maps which create this whole material:
- brows ( I chose to paint them instead using hair)
- bump map
- normal map ( derived from the sculpting workflow)
- specularity map
Some of these maps are reused in the sub materials (details, bump and normal maps).
Below are images taken from an actual render and a glsl viewport to demonstrate what is seen inside blender. This is to judge how closely the shader setup inside Mari is to blenders.
Well now its time to fire up Mari and create an Ara project.
Creating a new project inside Mari and importing the exported mesh is straightforward and I choose to just create a grey diffuse channel as starting point. As you can see below the model is cleanly imported and the uv patches are properly done as well.
Next step is to import the existing textures and create the corresponding channels. As discussed above this includes 8 channels. I create these 8 channels and name them appropriately. Then for each channel I import the existing textures.
After this is done I have the complete texture set, 8 channels with 4 patches at a resolution of 4K, complete inside Mari. Painting could now start right away by selecting the channel to paint on and just paint. But before doing this I want to setup a new shader with the goal to mimic as best as possible the SSS skin shader I have inside blender.
The problem that arises here is that the node setup used in blender cannot be completely duplicated inside Mari ( at least to my current limited knowledge, that is 🙂 ). I cut it down a bit and recreate a shader stack that catches all the important stuff.
Here is a screen shot with the shader set up. The blend values had to be tweaked a bit to the lower side but all in all the result is quite good:
As a side note. When I activated GLSL view in blender, it took about 15 sec to actually display the result in the viewport and even then the textures were very blurred. With Mari the result is instantaneous and without any visible degrading in texture quality, and thats even more true when actually start painting.
The painting for Ara is already done ( all but the feet but that will come later), so there is not much left to do but some minor corrections. One issue has plagued me though throughout the finalizing of several shots. In some angles and camera distances you quite clearly notice seams in the final render. I tracked this down and found that the baked normal maps, coming out from the sculpting workflow had too less bleeding applied and as it turned out I couldn’t increase the bleeding to a point where it worked. This was always on my todo list and now is the perfect time and tool at hand to tackle this small nasty detail.
See here for a shot where he problem is clearly seen at the neck.
Mari offers a bleed command for its patches which is exactly what I need. And it is perfectly legal to use the bleed command on a normal map as well.
Before the bleeding
and the bleeding applied
As you can see the bleeding covers more or less the whole space. And with this corrected normal map exported and loaded into blender we get a corrected render:
The combination blender – Mari works quite well so far, there is just one annoyance, which I have yet to explore a bit further. It seems that if I use blender and Mari at the same time, running on 2 different virtual desktops, I get frequent lockups when doing some paning/zooming/rotating inside Mari. And these lockups are very hard ones: the system in itself is working, but all things display related are frozen. I have to attach from another computer to see, if there are any messages from the nvidia driver. For the time being I close blender whenever I work with Mari and have no further lockups so far.
Thats it for this current post. For the next part I will try to demonstrate the actual painting techniques done on the main set.
6 thoughts on “Blender/Mari diary #1”
Great documentation Martin, very interesting.
Really good tutorial with lots of info.
There’s something I missunderstood. You say you copy the UV set before joining all patches back to tile 0-1 in Blender. What do you do with that copy? The .obj you export to Mari have the messed UV set or the correct one that you copy to somewhere?
Thanks by the way!
I see your problem here. Actually it is a bit of information I forgot to add 🙂
Each UV set in blender has a ‘render’ and an editing button to it. Before exporting the OBJ you should make sure that the UV set with multiple patches (the first one in my example) has these buttons activated. With this the exporter knows what UV set to use when exporting the OBJ.
I hope this helps.
Please feel free to ask again if anything is still unclear.
I got it!
Good luck for your project too.
I’ll subscribe your site!
Hello, thanks for the idea. The only missing piece is – when you did a non messed UVs laying each part of your object in it’s separate tile. Then you move all your UVs into one tile (and create as you refer to – messed UVs). Question here is – how can you perfectly place UVs from non messed tile in 0,0 messed tile so those are not even one pixel offsetted relatively to the tile they are in? Of course if all my tile’s UV islands would be touching all the top, bottom, left, right margins – i would simply set “constraint to image bounds” and simple move would put it in place, however I always use bleed approx 9px around each UV island therefore my UVs are never touching tile’s boundaries.
How you go about it? Thank you.
The tiles in blender are always layed out in multiples of the assigned image, or ( 256 if no image is assigned ).
To move the UV patches, just use multiples of the image size.
e.g.: if you have an image with 1024×1024 assigned and you want to move an uv layout from tile 0/3, just move the uv layout by -4096 in x direction.
As a side note: This workflow was developed for blender 2.49 and its internal render engine. As is turns out now, with blender 2.6x and cycles render engine, this tricking with multiple UV sets is no longer necessary. Cycles seems to project back all UV tiles into the 0/0 tile.