I’ve been extremely busy with work lately, but by popular request here’s a build of Pixero/ctrl.studio’s mix20layers for 64 bit Mac/Maya environments.
It’s pretty much the same as traditional installations, except the lib file is a .dylib now instead of an .so like it’s been historically.
The build is now on my downloads page. When I get more time, I’ll update the rest of the Pixero shaders for the new environment as well.
Add comment May 29th, 2010
Recently I’ve been working on some R&D for stereo 3D environments and pipeline issues.
One big issue is that cheats that you become accustomed to in production such as projections and bump maps break in an awful lot of circumstances when viewed in stereo, so very fine displacements will come in quite handy.
Since ZBrush 3.5 (and earlier if you knew how to break Multi-Displace’s cryptic code), it’s quite easy to generate single channel gray (1×32 bit) displacements instead of traditional (3×32 bit) maps… essentially giving you the same amount of detail in 1/3 the disk space and network throughput overhead… and RAM overhead if the entire texture needs to remain in memory.
PRMan in Maya handles single channel gray float TIFFs just fine, but Mental Ray (as of Maya 2010) doesn’t. The old swiss army knife imf_copy won’t recognize the files either to convert them to another friendly format, such as .map if you’re having RAM issues.
More after the break…
Long story short, I realized that I’m creating an enormous RAM and network bottleneck when working with multiple 8k displacements in a single scene, and the problem gets multiplied with the more render nodes that you’re using.
Example: 1×32 8k displacement = ~263mb while a 3×32 8k displacement = ~787mb. If you think about the implications there, it doesn’t take many of those maps to bring your RAM and network down to a crawl.
Why don’t we just combine huge displacement maps 3 at a time: one map per RGB channel of a 3×32 .tiff? That gives us most of the benefits of using the much smaller grayscale maps: smaller disk & ram footprint, significantly faster network spools, and the exact same quality. It just takes a few minutes to set this up.
Open 3 different displacement maps (all at the same resolution). One by one, copy it and paste into a single channel of a new 32-bit per channel RGB Photoshop file. You do this my clicking on your channels palette then clicking on each channel individually.
Once you’re done, save out the file as a 32-bit TIFF, uncompressed.
Now we come into Maya and build our network.
The idea is you take your single texture file node, shove it into a Luminance node per channel, and it’s in the format that the displacement shader and shading groups require.
Click the image above to enlarge the an example network.
Basically given a file node, three luminance nodes and three displacement nodes in hypershade, hook them up like this:
(Texture)File1.outColorR -> Luminance1.valueR
(Texture)File1.outColorR -> Luminance1.valueG
(Texture)File1.outColorR -> Luminance1.valueB
Luminance1.outValue -> displacementShader1.displacement
Then set File1 color gain and color offset to 1 gain V,-0.5 in offset V (ZBrush 3.5) or 2.2 in gain V, -1.1 in offset V (Earlier ZBrush) by clicking on the color swatch next to the offsets, switching to HSV and entering a number. Yep, you’re setting the gain and offset on the color, not the alpha like usual.
Rinse and repeat with File1 G and B channels:
(Texture)File1.outColorG -> Luminance2.valueR
(Texture)File1.outColorG -> Luminance2.valueG
(Texture)File1.outColorG -> Luminance2.valueB
Luminance2.outValue -> displacementShader2.displacement
(Texture)File1.outColorB -> Luminance3.valueR
(Texture)File1.outColorB -> Luminance3.valueG
(Texture)File1.outColorB -> Luminance3.valueB
Luminance3.outValue -> displacementShader3.displacement
The other cool bit about this is that you can convert it into .map format and it still works, however .map format generally adds about 1/3 of the filesize as overhead when converting to a pyramid lookup. Depending on your file sizes vs. RAM vs. network throughput it may or may not be worth converting to .map.
Here’s an example scene using the tutorial setup, just with much smaller maps. Maya 2010 .ma format.
http://www.treyharrell.com/downloads/thDisplacementSplit.zip
I’m sure I’m not the first to use this particular technique, but it came in super handy tonight — it saved 4-5 minutes network spool per render slave — about 18 minutes total per frame — plus about 2gb RAM overhead on an R&D project.
2 comments January 5th, 2010
Working on reel updates currently, but wanted to share this piece ahead of time.
http://www.treyharrell.com/downloads/PriusBreakdown-H264.mov
I tracked & stabilized the background plate, then lit & shaded a stock Prius model and replaced the car in the original shot. I used some photogrammetry techniques to project accurate ground reflections back onto the car, and hand-painted an HDRI skydome based on the background plate.
Minor amounts of roto & paint fix to complete the illusion in comp. Maya, Renderman Studio, Syntheyes and Shake used. 3 days to complete the shot including render time.
Add comment September 21st, 2009
I had a request today to put together a Mac universal compile of domeAFL. Since I had to make a few tweaks to get it building properly under OS X 10.6 Intel, I’m sharing my build and sourcecode. Someone else out there might find this useful.
It’s a mentalray lens shader that does 180° distortion for projection on planetarium / IMAX domes. Might come in useful if you want to unwrap your own scene for IBL effects as well.
Also worth mentioning that this isn’t just a universal compile, it’s a fat universal compile: PPC, Intel 32, Intel 64 in a single .so. I figure Autodesk might release a 64 bit Maya on the Mac side one of these years, so why not?
The compiled shader and source code are attached below:
th_DomeAFL for Maya 2008 SP1 (shader only): OS X PPC/Intel32
5 comments September 8th, 2009
I’m about a month into using Renderman Studio v2, and I’d like to share a few random hints about how to get things working how you’d expect them to. This list is generally for people who are used to the mental ray/Maya way of doing things.
This first collection is about one of PRMan’s strongest points: displacements. It’s absurdly fast due to how the REYES architecture handles micropolygons, and it barely has any RAM footprint at all.
1. Object scale is incredibly important when working with displacements in RFM. Your displacement map is calculated in world space, so if you scale up your mesh in Maya, it’ll do weird things to a 32-bit displacement, and you’ll end up having to tune your alpha gain & offset to match the scaling ratio.
Freezing your transforms doesn’t work, because it’s reading the map in world space.
The proper way to fix this issue is to scale your mesh in Maya, freeze the transforms, export it out as an .obj, then import it at the lowest subdivision level into your sculpt, recalculate all your maps, then export the mesh again from ZBrush (UVs might smooth or shift, always re-export your .obj after calculating displacements).
After that, reimport it into Maya (make sure you check “Merge UVs” under the export options!). This way ZBrush is calculating your displacements at actual scale, and you can use the magic numbers: alpha gain of 2.2, offset of -1.1 on your map. Remember to turn off quadratic filtering on your image as it softens your displacements.
Note: Alpha gain / offset of 2.2 / -1.1 are for versions of ZBrush prior to 3.5. From 3.5 on, use 1 / -0.5.
2. Your shading rate affects how much of the displacement map is actually used, and you have to set this multiple places depending on your scene setup (subsurface render passes, renderradiosity render passes as well as the “quality” tab under render globals). In general, you can think of a “1″ setting for shading rate as production quality, but it’s possible to go higher (more on this below).
Worth clarifying that you don’t necessarily need to set this to the *same* value if you’re, say, doing an environment light with color bleeding. There’s a strong possiblity that a 64-sampled renderradiosity map will look totally fine and have enough detail with a sample rate of 20(!!!) and save you a ton of map calculation time.
3. Is your displacement, hair or other micro-detailed feature not sharp enough? Try cranking your sample rate all the way down to .1. — zero isn’t an option, it’ll set it to 1 automatically.
4. Getting weird blobby surface artifacts when rendering displacements (or subsurface effects)? It’s likely due to PRman’s credo of avoiding raytracing at all costs.
What you’re seeing is the result of your pointclouds or raytraced shadows being calculated against your un-displaced model, then just the points that invoke raytracing are comped over your render, and unless you force Renderman to calculate displacements against everything, you’ll end up with an ugly, blobby, posterized mess.
Click on your object, then go to the attribute editor and manage attributes. You need to add a “trace displacements” attribute to your object. (Attributes->Renderman->Manage Attributes).
Be aware, however, that if you’re using lots of rays (for raytraced shadows, for instance) that each of those rays is getting calculated a bunch of times and it can all add up in your render times.
5. While not strictly a displacement tip, it applies due to the way “trace displacements” is handled: when doing pointcloud passes for environment lights (RenderRadiosity etc), make damned sure that raytracing is disabled for your pointcloud passes or your render will quite likely never complete in your lifetime.
6. Getting a ghost of your mesh’s wireframe when using displacements and raytraced shadows? The fix is the same as tip #3 — turn your shading rate way way way down. Generally .1 is the magic setting to fix this. If you’re using other passes (subsurface, radiosity etc) make sure to set your sample rate there as well if you’re seeing artifacts on those passes as they preview render. This is a brute-force fix that looks good without tweaking any other settings.
There’s another method to fix this issue that isn’t quite so brute force: adjust your trace bias up by small amounts until the self-shadowing (that’s what those ghosts are) go away. Render times will likely be much quicker with this method, but shadows won’t likely be quite as detailed or accurate.
7. Magic numbers for 32-bit ZBrush displacements in Slim:
Assuming you’re using a combine node:
Do displacement: checked
Use shading normals: checked
Base: -0.50
Kb: 2.2
Note: Base / Kb of -0.50 / 2.2 are for versions of ZBrush prior to 3.5. From 3.5 on, use -0.50 / 1
Add a bump, make it an image file with 0 filter, set to a value of 1.
Pretty much the same thing as Maya… the math’s the same, even if the numbers are different, so it might trip some folks up.
–
More hints to come in the not-too-distant future.
7 comments September 1st, 2009
As cool as mental ray is, when interacting with it through Maya one often feels like they’re on the wrong end of an abusive relationship.
To speak plainly, integration and workflow sucks, and once the honeymoon wears off with the bells and whistles (”Car paint! Cool! SSS! Cool! Arch Materials! Cool!”) you come to realize that the foundations of the Maya integration are buggy as hell, and quite likely never to be polished or fixed. Sometimes you just want to slap shaders on a model and hit render — particularly when you’re the entire pipeline.
MR is certainly useable in production when you’ve got dedicated lighting and render wrangling TDs… but when I’m trying to knock something out quickly at home, I find myself spending entirely too much time tuning out the grain and getting render times under control.
Again, fine if it’s my job to be the guy who gets to bake FG, and tweak sample rates to get average render times manageable, wire up rayswitches and the production shaders (poster child for sharp edges here) to get accurate shadow extraction etc… but if I’m working on a project 100% myself — man it’s a time sink that should be mostly unnecessary these days (particularly after working with PRMan, 3DLight and VRay in production environments).
Case in point… render passes? Still a completely ridiculous workflow that doesn’t work as advertised and barely works at all…. now three yearly upgrades down the road. I’ve written MEL scripts that brute force render layers and shaders to get useable passes, or I end up circumventing Maya’s pass system entirely with a 3rd party framebuffer like MegaTK or Ctrl.buffers. I can’t believe anyone has been able to use the stock render pass system in production without major modifications.
Use background? Still not working with final gather / occlusion (since the beginning of time), so awesome… I get to do channel math to extract my shadows from multiple passes, or wire up the production shaders with rayswitches and the like — which aren’t supported in Maya, and calling the setup unintuitive would be generous.
Subsurface scattering is getting slower with every update. With progress messages set to “fatal only” I routinely get 50+ gig log entries complaining about hidden lights.
And linear workflow / gamma. Dear. God. VRay lets me check a single box to gamma correct everything. PRMan just does the right thing. Max got a box like that for Mental in 2010, but no such love for Maya users.
At any rate, this isn’t a Dear John letter to nVidia/mental just yet, but I have been seeing Renderman for Maya behind its back for a while. The polish, speed, documentation and openness of the whole thing make me want to:
1. Cry
2. Spring for Renderman Studio
Consider the following test image:
Using Maya’s default fur workflow, this rendered in a fraction of Mental Ray’s time (jaw-dropping would describe it), it looked better, the fur doesn’t flicker when using FG/GI and the render passes just worked. Out of the box. No weirdness other than having to specify a deep shadow map and learn how to tune sampling rates and recursion. It’s not a final model, but I got the thing modeled, scultped, lit, furry and groomed in a day. It’s not hero model detailed, but it’s passable for a mid to long shot already.
This is the first real playing with the “lite” version of Renderman for Maya I’ve done, and I’m simply delighted to say the least. I’d always assumed it was just a pared-down version of RAT… which it is to a degree, but the simplicity is actually a strength when you’re trying to get stuff looking good with nice render times fast… generally the point when you’re trying to get a project out before it gets shelved at home.
I only really get the chance to work with PRMan within established pipelines on gigs. But with these kind of results this easily, I’m sorely tempted to make the plunge for my home office.
Time is money, yes. But time is also crucial for an artist. When you’re working on your own stuff without a deadline or paycheck, it’s entirely too easy to lose interest and shelve a project if you get mired in the tech details. And that’s something I’d love to avoid at home as much as I can.
23 comments August 14th, 2009
I think most people that have used ZBrush have gotten something really cool (or at least promising) sculpted out, and had either lower levels of subdivision get corrupt, or have your geometry get mangled… either through a crappy basemesh that you used to get up and running quickly, or invisible bad topology on a mesh that you tweaked point by point.
In this case, I was just noodling a concept from a stock basemesh that had terrible topology and I ended up losing my lowest sub-d levels at a pretty early stage. The model and texturing aren’t the greatest, but they’re not meant to be. They’re meant to be fast exercises to help arrive at a final product faster.
The following video is a half-hour step-by-step walkthrough of how you can find yourself in that situation, and how to recover your detail on a clean mesh.
Strictly speaking, the workflow is a retopology technique, but I’d never seen it applied to imported meshes with new UVs, and I’d definitely never seen recovery of polypaint/texturing info from a mucked up model.
http://www.treyharrell.com/tutes-2009/medretopo-pt1/
Approximately 30 minutes, embedded Flash video @ 800×600
Add comment February 11th, 2009
My 3D Still gallery has been updated with a few more recent images. Included in the updates are another coffee fix that was a test for a new lighting rig that I’ve been working on, and the riveting conclusion to the Godzilla modeling series.
Add comment January 27th, 2009
I love being able to triple boot Linux, MacOS X and WinXP x64 on my main Mac for 3D & web development work, however Windows handles time zone offsets differently from every other OS out there — so when you reboot into Windows, you’re looking at a 4-5 hour difference (EDT currently).
Apple’s Boot Camp drivers handle resynching the time automatically, but they don’t work with WinXP 64 (only Vista x64), so I’ve hacked together a quick .bat script that’s intended to be placed in your Startup Items folder (under the start menu).
It includes two longish pauses: the first because sometimes the startup items get invoked before the network card initializes (silly Windows). The second is so that you can read the result if the script fails before the shell window auto closes.
At any rate, just paste the following into Notepad and save as timesynch.bat in your Start Menu startup items (C:\Documents and Settings\All Users\Programs\Startup\)
@ECHO OFF
ECHO Preparing to resynch time to Internet time server ...
TIMEOUT 10
w32tm /resync
ECHO Execution complete ...
TIMEOUT 5
Add comment September 26th, 2008
Now available: compiled Mix20Layers for OS X Universal (modified by Jan Sandström, based on Mix8Layers by ctrl.studio).
Like the last batch of shaders, this is also available on Pixero’s site at http://www.pixero.com, under his Shaders -> Mental Ray area. The universal .so is contained within the standalone shader package toward the bottom of the page.
Big thanks to Jan for allowing me to compile these!
Add comment June 5th, 2008
CGTalk Maya Feed Slashdot