sjt.is

Pipeline. Period.

Textures, it’s always the textures

‘What to do with the textures?’ is something that constantly pops up at work, that is where should we store them?

When I started back at Caoz after my stint at SPI I was scrambling to set up a somewhat working pipeline for our TV production that was starting up. We wanted to use Tactic since we had been lacking any sort of project tracking up until that point. (For some reason we were using Alienbrain which we have thankfully pretty much removed from our workflow) The problem is that modeling/shading had started and I was more worried about getting a functioning animatic > animation > lighting workflow going. The unfortunate side-effect of this was that the textures for the assets were now in 2+ locations, some of the textures were textures that were shared between assets and someone was clever enought to put them somewhere like

R:/project/assets/textures

But some textures had been made after we started moving to working on a server (instead of alienbrains local->remote syncing shenanigans) so they ended up in a proper location like

//server/share/project/asset/Pictures/textures/

Another thing we wanted to achieve was to have the textures files locally on each machine rendering. All of this texture crap led me to using something I dubbed the texture pit. This is just a vast dump of all the textures located on a common path on the server, e.g.

//server/share/project/common_asset/texture_pit

And at lookdev publish time all the textures are copied over there (if they don’t already exist) as well as a .tx file is created for our dear Arnold renderer. Then we replace the link inside Softimage to point to the environment variable $CZ_TEXTURE_PIT which for all gui instances of Softimage point to the server side texture pit. Now we turn to rendering. At the start of every render job the pit is synced to the local hard drive of the render client and then it is just a matter of redefining $CZ_TEXTURE_PIT within XSIBATCH to point to the synced texture pit on the local machine. Tada, all textures in one place and locally on the render machines.

This setup requires us also to define a texture root for SItoA as well as re-export all our environment standins and set the export to use relative texture paths.

Pros

  • It’s comfortable to know that all the textures are in that one folder on the server.
  • If the same texture file is used in multiple assets (same filename) then the one single texture in the pit already got it covered.
  • The textures are on the render clients local hard drives meaning faster renders and less network load.
  • We have hardly seen missing textures errors since we started using the pit, and if we encounter them, they are easily resolved with dumping the missing texture into the pit.

Cons

  • An evergrowing vast collection of textures being synced around the network many of maybe are never used because the texture was used for a prop which was used in episode no. 2 but never again, still that texture is being synced and stored on all our clients.
  • Wasted space on the server, keeeping the textures within the asset folder and the pit == twice the storage.
  • Finding a texture to use on a new asset requires the texture file names to be very descriptive so you can find them easily.
  • Does not enforce a structured workflow for texture artists, they can pretty much save their textures where they want while they work and then just at publish time sync their textures to the pit. So getting back to their work files can be tricky.
  • No version tracking whatsoever (this is just our setup, version tracking within the pit is quite possible)

I think I have written enough about our texture handling (or lack thereof) at Caoz.