Topics by tag:
Recently published articles by Dave G:
Now that Mari 2.6 and Maya 2015 are out, I think it’s time to release Mari Me 2 that is a complete rewrite of the MEL version that is now much more powerful than that old script was. Aside from being able to send stuff from Maya to Mari, the new version has a ton of little goodies that aid working between Maya and Mari without the need to look at a single dialog box. Mari Me 2 can both send and receive objects to Mari, updating metadata-tagged materials for identification across sessions. It works great as a quick way to jump back and forth for stuff like Mari 2.6’s texture transfer feature that bakes textures between different mesh topologies or UV sets:
The transfer feature is better than it looks from those results – I was just kind of lazy about my alignment of the two different meshes in Maya. Mari Me also has a smart way to update your existing materials that is renderer agnostic. It doesn’t care what type of material is used on the mesh and will simply update it based on the channel name within Mari. If your material’s emissive channel in Maya is “blinn1.incandescence”, just name the channel “incandescence” in Mari and when you send it back to Maya, it will link up to that channel in the material:
That’s why I created a AddNewChannel-VRayMtl.txt setting preset for standard V-Ray Materials that you can paste into the channel presets section your Mari.ini file – those are pre-named to link up with the slots of a V-Ray Material and it would be very easy to make one for Arnold, RenderMan, etc that you could share on the Github page. If you send a texture to Maya from Mari without having sent anything from Maya to initiate those material metadata tags, it will just import the textures and you’ll see the file nodes in the Hypershade. Mari Me’s metadata tags don’t create any sort of plug-in dependency so nothing will break and you won’t receive any warnings if you send a scene to someone without it installed.
Automatic UDIM sending and loading
Mari Me 2 has robust support for UDIM-tiled textures:
If you are running Maya 2015 or above, that supports the UDIM file name variable, Mari Me will use that instead of importing and manually tiling all the UDIM textures. It will also recognize these 2015 UDIM names when you send tiled textures to Mari. It should also work fine with multiple meshes and a mix of tiled and non-tiled UV meshes. I tried to make it smart enough not to break with these production workflow variables but it’s possible stuff slipped through so let me know if you see anything and I’ll see if I can find some time to fix it in the near future.
Mari 2.6v1 got support for Alembic animated meshes and the Python import syntax is the same as importing OBJs so I added support for exporting animated meshes from Maya to Mari via Alembic:
As you can see in the interface, there are a bunch of other little tools and tricks in Mari Me 2:
There are no file format options so everything is sent back and forth as TIFF, since that format can accommodate all bit depths and all working files are in a projectpath/MariMe/ folder so there is no risk of clobbering your existing assets.
Released under a BSD3 license
I started the Python version of Mari Me as a “Pro” version that was going to be monetized but decided not to after getting a new job that I’ll get into later. Because I’m going to be super busy with this new gig, I’m going to have to release Mari Me as unsupported but I released it as open source under the BSD3 license for studios or individuals that want to change the code and use it for their own and they can decide whether or not they want to fork it or not on the Github page for Mari Me:
The old MEL version is no longer on Creative Crash. Read the Read Me file because that explains the setup.
4 notes | Permalink
There are a lot of texture sites out there and I have a ton of stock images that I already use for texturing but I recently discovered texturelib.com and it is hands down the best site for textures I’ve seen. The quality and resolution of the images are great but what really stands out about their images is that they are exceptionally shot, without uneven lighting, wide-angle distortion or bad perspectives. They must be using long focal lengths and cameras mounted on remote-controlled helicopters for most of these because you just can’t shoot stuff like this without some special setup:
Anyway, I just had to spread the word because I just bought the year’s subscription for a paltry $29. Seriously, run don’t walk to get on that stuff.
3 notes | Permalink
I’m doing a scene with a bunch of simple cloud shadows cast over a valley and I’m using a plane with a repeating cloud texture mapped to the Opacity attribute of a V-Ray Mat. This will render a lot faster than doing a volumetric cloud and I also get the flexibility of using a gamma correct for the file texture node to effectively dodge and burn the cloud edges:
Since a gamma curve only adjusts your mid tones, this is a good way to save a trip to Photoshop and it’s lossless so it doesn’t mess up your original cloud texture. The results are pretty convincing too:
So, after tiring of Mari’s new project panel and its non-OS version of its open dialog, I decided to make a script (Download here) that sends the selected mesh from Maya to Mari for painting. It has some nice options that I think will be welcome:
The features are shown in the video here:
If you don’t choose to send an existing texture, it will create a 50% grey “color” channel that is set to the resolution of the slider, which snaps to Mari’s supported resolutions.
I added the ability to send a tessellated and displaced mesh even though I know that Mari does displacement previews but these don’t use your actual values from your existing Maya model so this script creates a mesh that is closer to what will render. It’s not the best solution since the geometry can be really jaggy but it’s better than nothing. Just make sure you only run this displacement script on cage-type geometry because it smooths the mesh and then tessellates so it will extremely slow if it’s a already high-ish res mesh.
As you can see from the video, I originally made this script to send Python to the clipboard since I didn’t see any documentation for the command port that is used by Nuke to talk to Mari but there was an example script that showed that it receives straight Python. So my script does all the gross code escaping and wraps the Python commands in a single line and passes it to Mari.
To get the script to speak to Mari, you need to make sure that Mari’s command port is open to the default port of 6100. This is in the Scripts portion of the Mari preferences.
The only limitations to the script right now are that it needs to have a relatively simple material applied to the selected mesh – it will simply fail if you have a V-Ray Blend Mat applied to it, for example – a fix for this will come soonish. You also have to have a mesh selected when you run it. Also, textures are currently sent only as RGB, with no scalar option. This will come later and I’d like to add an auto-detect for the applied texture res for the slider. Tiled mats are not supported – obviously that is a dealbreaker for many but hopefully I can get that working some time in the future. I haven’t tested it in Windows or Linux but it should work fine. The exported meshes are stored in a project_path/GoZ/ folder because I didn’t want to create a different folder for OBJs that I use with my ZBrush meshes.
One of the tricks I learned as a photo retoucher back in my university days was that, if you wanted to tile a texture or extend a background, the fastest way is to duplicate the layer and then flip it. When you align the edges, there will be a match at the edges, which is usually easier to clean up than a messy clone job. Well, Maya’s texture nodes let you mirror your U or V texture so that this is done for you without having to head to Photoshop. For something like a plywood reference texture, it works really well:
Obviously, that seam is going to be a little obvious but I am using it as a painting reference, so I don’t need to clean it up. Other textures may be less obvious when mirrored.
0 notes | Permalink
If you tweak cage meshes in Maya that are to be subdivided and displaced, you end up worried about a couple things: what will happen to your seams when you do that tweak and what is the displacement going to do when applied to your tweak? As I mentioned in an earlier post, you can do a polygonal displacement preview but sometimes it is sufficient to just preview the displacement on your cage mesh in Maya. So I wrote a script that will be part of the next version of V-Ray Tuner that makes a temporary surface shader and applies the displacement map for the currently selected mesh as the diffuse colour. If you run it again, it switches back to the original shader and deletes the temp surface shader – no crap left around.
One nice feature of this script is that it uses the same file node as your material so even if you change the link to a new file you might have touched up, it will update the original shader’s displacement file node even though you are previewing the surface shader. I hope you find it useful.
Grab the script here. It works with all renderers.
5 notes | Permalink
So I am working on something that needs some tricky UV and vertex tweaks and, if you’re a V-Ray user, you probably know that viewport 2 is fast but V-Ray’s default baked previews in Maya are really low res – I don’t even think that 64x64 pixels qualifies as “low res,” it’s so bad. Luckily, after getting in touch with Chaos Group about it, they let me know that there is a workaround to get high res previews. Jack up the resolution in viewport 2’s “Bake Resolution for Unsupported Texture Types” setting, save and reload the scene and you’ll have a high res preview:
Thanks again to Chaos Group for the exceptional support. After years of struggling with all the problems and dearth of support for mental ray, it’s so refreshing to have such good support in V-Ray. They never cease to impress me.
One of the big things you need to get used to with Mari, if you’re coming from something like Mudbox, is that a lot of tools need to work with the paint buffer. Where you can smudge any applied texture in Mudbox, you can only do a slerp (Mari’s smudge) to the active paint buffer in Mari. There is a workaround to get baked textures into the paint buffer though: use the clone tool and clone right on top of itself, so that you have zero offset between your source and your clone. This basically lifts the cloned area right into the paint buffer so you can use something like the slerp. Check it out:
Updated: now supports vertical UDIM tiling and textures from Mudbox.
I’ve been avoiding using multiple UV tiles for a long time since the workflow can be pretty annoying and there is a lot of room for human error but, with the coming of Mari on the Mac, I have been using them finally and developed a script to handle the creation of multi-UDIM tiled textures in Maya:
Grab the script here. The hooking up of the textures is based on this post on CGSociety, where it’s shown how you can completely avoid the layered texture workflow by just daisy-chaining the out colour of one texture into the default colour slot of the next. My script then reads the filename of the texture and guesses its frame offset (U/horizontal only for now) by the number before the file extension – if it’s colordust.1003.tif, then it’s assumed it’s offset by two U tiles. It also disables UV wrapping on the 2D texture nodes. When the connections are done, the top-level texture (that needs to be connected to your shader) is selected. This workflow works with any renderer. I’ve also updated it to support vertical UDIMs:
Important: the script relies on these two standard naming conventions: filename.1031.tif (name, dot, number, dot, extension) for Mari and Material1_Flattened_Diffuse_u2_v1 (name and then tiles appended to end) for Mudbox. These are the defaults so you shouldn’t have any problems but the script won’t work if you change the dots in the Mari name or the underscores in the Mudbox one.
Just a note that renderers like V-Ray and Arnold support UDIM and Mudbox-style tiles – see V-Ray docs here but those only appear at render time. You don’t get a preview in Maya since it doesn’t recognize the filename.UDIM.tif format. Thanks to Roman Lapaev for pointing this out though.
4 notes | Permalink
Stacks of paper and money are one of those things that would be complete slowverkill to create as individual planes with SSS. Unless you need them to flap at the edges, a stack of bills can be easily faked with a series of lines along the edges that are then used as a mask for a stretched edge fake in Photoshop, and later as a separate bump map:
The render (notice the light catching the bump on the stack at the bottom):
The one complication to this workflow is that Photoshop will usually detect that you’re trying to edit a bank note image and not let you edit it:
That’s why I had to do the initial layering in the excellent and cheap photo editor Pixelmator and the banknote image wasn’t detected in the layered image used above. If you want to do a dollar stack, you might need to use The GIMP if you’re looking for a free Photoshop alternative.