When working up your models you are welcome to develop them how you please, but when it comes to delivering these models to other people, they need a few things cleaned up. And when it comes to rendering a piece of geometry in a Renderman renderer, there are some really important things to consider. Especially when it comes to how the geometry is arranged, and UVs are laid out.
Renderman renderers are not as forgiving as many others. For instance if the normals are funky, this will cause all sorts of nastiness when the shaders are applied. Don’t assume that because the geo looks fine in the Blender renderer, it will work in Aqsis or another Renderman renderer.
Terminology
(I thought I should make sure we all know what I’m talking about)
- Asset – the full collection of geo to be passed between artists. The Peacock.
- Mesh – an element of geo in the asset. Left Eyeball.
- Geo – geometry in general.
- Shell – a seamless collection of Uvs.
- Shader – a program written in Renderman Shading Language to define the surface properties of the geo.
Polygons:
All polygons are to be quads. Triangles if you are really stuck.
Break your asset up into meshes that will have different surface propeties. Renderman does not support multiple shaders per single piece a geo. So you cannot have the head of the character with one shader for the fur, and then select the beak and apply a different shader. This is a really important issue. It will mean that you need to think carefully about seams, and how to connect these pieces together.
Meshes should be ‘closed’ surfaces. For example don’t just model one side of a piece of paper, model both. It takes a fraction more work, but it means that these meshes will be more versatile when it comes to shading. On a similar note, it’s worth modelling things like eye sockets for characters too. This way if the eyeball doesn’t sit perfectly – or is stretched – then the render may still look correct in the gaps. If there was no geo there, it may be too late or too hard to send the model back to get fixes made.
All normals are to face the intended direction. If on the same surface some are facing out, and some are facing in, then edges or seams will appear on these borders. You may also get things like shadows and occlusion calculating incorrectly as when they are calculating, they test for things like normal direction.
UVs:
Be patient, and take your time. There is no fast answer to setting up good Uvs.
Uniform spacing. Test your Uvs regularly with a checker map. All the checks should be evenly distributed across a mesh. It’s important for the texture painter to know that if they paint a detail in one area of the model, the same detail painted elsewhere in that model will come through the same size.
No atlas mapping. Break your UVs into logical shells. This way anyone can easily paint and amend textures. It’s not uncommon for textures to need little paint fixes late in the game, and to be able to open up and spot the problem areas quickly, is something you’ll soon appreciate. Atlas mapping is – possibly in my own opinion – only useful if you have a full 3d paint application supporting your work, like Mudbox or zBrush. Take the time to lay UVs out correctly.
Keep all geo in a single UV set. I’m not sure about how Blender deals with different sets, but I think they also need to supported in the shaders for them to work. So for now, keep them in the default set.
Get regular feedback from your favourite texture artist, on how they would like the UVs laid out. Think about the artist painting the UVs, if you have 10 fingers it might be easier to lay them all out in the same direction, near each other. This will make it much easier for the artists to paint up the details. Also, keep the different UV shells orientated vertically and horizontally. If they are skewed it becomes very hard to paint and change details.
All UVs to be kept within a 0-1 range (unless a method for dealing with UV Tiles has been developed).
Be patient, and take your time.
So in conclusion …
Just make sure you tidy up after yourself. It’s actually fairly easy to write some simple QA tools that can test many of these things, otherwise just get into the habit of checking everything before you hand off the asset to the next person in the line. If someone has planned to do some work on an asset – and these things have not been checked – they may well end up wasting a lot of time trying to fix errors, and be well within their rights to simply send it back to the modeler for continued work. Also it’s possible that an error may not show up until a lot of work has taken place. This is why it’s very important to QA your own work.
Leave a Reply