In May we published a piece on Ptex and UDIMs (UV mapping). This caused some interesting discussions, to say the least! Here is Part 2 of that article putting the case for Ptex, and perhaps addressing some of the issues raised in the original fxguide story. For this perspective on the issue of texturing we spoke to several members of Walt Disney Animation Studios. The good news is that, while UDIMs have proven to have been helpful for UV texture artists, Ptex is also set to improve and that Disney is looking to offer even more tools into the public domain to help that happen.
One correction: In the previous story we incorrectly stated that "Ptex can be limited to 8k x 8k UV’s say 32k x 32k in Arnold." There is no intrinsic limit on the Ptex per-face resolution, as pointed out by Disney Animation's Principal Software Engineer Brent Burley: "It's more a matter of the tool-chain. And while a tool may limit per face resolution to 4k/8k/whatever, the total number of texels in the Ptex file can be orders of magnitude greater. Having many gigatexels in a Ptex file is routine for us."
As discussed in the first article, Ptex is an alternative approach to texturing. It is a per-face texture mapping system that does not require UV assignment. Walt Disney Animation Studios was motivated to develop Ptex after a series of problems, especially performance issues "UVs had always been a hassle, they were a bottleneck in our pipeline," explains Burley.
Ptex manages more of the process for the artist, and in so doing solving many of the issues that artists have had to find solutions for in the straight UV world. For example, the issue of seams and how to produce an efficient set of seams in Ptex is virtually a non-issue, where in UV space whole programs have developed to allow artists to better seam and tile their textures. And it is more than just how tiles are seamed, it flowed on to how to get seams without artifacts. For example, with displacement or how filtering is done with the seamed tiles and especially the performance on doing such operations, in particular memory loads.
"There were many problems but the straw that broke the camel's back so to speak is the IO load", says Burley. "We were tiling our models and putting multiple UV tiles on each surface and the file counts were just going through the roof. We had a 100 times or more texture files than surfaces, and this was an IO load that was killing our servers with Render IO." So bad was the problem becoming that artists were looking to use procedural textures rather than image based textures. "We are very texture based," adds Burley, "we wanted to solve the textures problem, so we came up with Ptex and it addresses the performance issues."
Ptex was designed so that each texture layer (each complete texture set on a surface) has now independent resolution control, which means each layer does not have to be the same size. This means that "your color map can have a different resolution than your displacement map - even different ratios between faces," says Burley. Internally large textures are tiled so that they can go to 8K or 16K per face textures or beyond. When there can be an arbitrary number of textures, say 10,000 or more, the file can be dozens of gigabytes, and Disney has found Ptex to scale very well for production use.
But what is really interesting is that many maps are done for just fixing one part of an object or blending one particular point on a character. "We have a special optimization for constant faces," outlines Burley. "They are just stored in a special block for all the faces in a single constant texture at the start of the file. This has a real benefit for the memory footprint, disk footprint and even the filter knows about them and filters very efficiently."
The significance of this comes from the fact that the team estimates that 95% of the faces are constant. They are often times just masks, which are very sparse, with all white or black and then with just some detail on say one part where they are blending some special feature boundary. These store and load very quickly.
Ptex generally is optimized for rendering and to minimize random seeks. The MIP maps, for example, are stored for optimum rendering access. In production these optimizations have really made a huge difference. The Disney Animation team has an average of 8 Ptex files per surface (color, reflectance, displacement, etc.), with up to several dozen files per surface on hero elements. This translates to hundreds of thousands of Ptex files per shot. As Ptex files can range from a few KB to multiple GB, it can be larger than memory. "We average half a byte per texel in our usage, 95 per cent of faces are constant due to large numbers of mask textures," comments Burley.
Performance was one key issue raised in the UDIM article that was offered as a reason why Ptex had not been more widely adopted. Here again are those earlier NON-Disney stats (REPRINTED from the first article for clarity):
|threads||pixel rendering time||speedup|
Wait a second...
This stats above are indeed a warning against what might happen, but are perhaps actually irrelevant, points out Burley. While it is possible to have Ptex perform this way, it is not the current recommended practice for implementing Ptex. To explain, Burley examined not one theoretical job but more than 400,000 jobs - from one actual full week of production on the Disney film Frozen:
"Thread counts varied, but most jobs were 1, 2, 4, or 8 threads. In total, just 5.2% of time was in Ptex. By thread count, Ptex took 3.7%, 4.0%, 6.3%, 5.9% for 1/2/4/8 thread jobs respectively. A handful of jobs ran with 16 threads with 1.7% time in Ptex. This was all in PRMan, using a single shared Ptex cache for surface textures. There were also very few outliers; 65% of the jobs were less than 4% Ptex, 90% of the jobs less than 15% Ptex, and only 1% of the jobs ever took more than 30% of the time in Ptex."
All of the Disney stats include I/O and filtering time. "We've never had a problem with Ptex texture access in RenderMan," says Burley.
So why the vast difference from the test mentioned in the fxguide UDIM article to the reality of Disney Animation in production?
According to Burley, “PRMan uses shading grids which access textures coherently with minimal contention between threads so a shared Ptex cache works fine; we’ve used a shared cache for all of our films up to Frozen. With ray-traced GI however, texture access can become incoherent and the shared cache may not perform well. In this case, a separate Ptex cache per thread can be used." PRMan, for example, did not initially have a separate cache per thread but for many years now it has had this important improvement. When Ptex is used with a separate cache per thread," explains Burley, "there is no multi-threading slowdown at all due to Ptex, just increased memory usage."
As part of this investigation a test was run with the teapot example from the Ptex website using PRman 18.0 (with the output resolution changed to 4096x4096 - the machine specs were 16 core, 128 GB RAM, no-hyperthreading, RHEL):
|threads||pixel rendering time||speedup|
In this test case, with 16 threads it was 6.7 times faster with PTex, compared to 1.5 times in our previous story. This completely changes the issue of multi-threading. Even at 6.7 times the scaling is not 1:1. To investigate further it is worth asking how linear is the scaling when we have a test run without any texture at all...
|threads||pixel rendering time||speedup|
There is a 6.7x speedup on 16 threads (on a 16-core machine) with Ptex, and 6.5x speedup without any texture. This is not the exact same scene as originally rendered (and quoted in fxguide's first story) and it is not meant to be anything other than an illustrative example, but it clearly shows Ptex does not have issue when implemented with a separate cache per thread.
Burley further adds that this is not an isolated trick that the RenderMan team alone have discovered. He points out that V-Ray scales and it does not use a separate cache per thread. "Vladimir Koylazov of Chaos Group contributed an improved version of the Ptex cache used in V-Ray that scales better when sharing the cache among threads," says Burley. That version of optimized shared cache has been shared back on github by Koylazov for all to access. It is a separate branch of Ptex used at the moment probably only by V-Ray.
Note: Only a 16 thread machine was used in the new tests above - 32 and 64 threads were not tested.
The next important point revolves around the flexibility of changes that happen in a Ptex pipeline.
"If you don’t have enough tessellation in your geometry one can’t get enough resolution in Ptex..."
- This was also a point from the first story that is certainly not true in the case of Disney Animation.
"Ptex is what allows us to paint and render models well before asset work (i.e. Look Development) begins," says Burley. "And when assets do reach Look Development we rarely have locked assets; model changes are a fact of life. Good texture transfer tools make this a non-issue."
Unlike some of the other points, this point pivots on some technology that Disney Animation has, that few others do. General users do not have the Disney Animation transfer tools.
There are several challenges that a Ptex pipeline can throw up, but Disney Animation believes they have addressed these with their in-house authoring tool. Namely, autosize (computing the resolution of each per-face texture optimally using a target texels-per-unit in object space), transferring between models (location-based, texel-to-texel, or face-to-face), copy and paste/mirror and flat painting, something that traditional UV texturing clearly provides inherently.
"The good news: Disney Animation is taking a new set of transfer tools & other utilities and making them open source"
The flat painting is something artists just like to be able to do, even knowing the textures must be changed as they resurface the non-flat model. The Disney authoring tool provides multiple different and dynamic flattened views of the artist's work. Localized areas of a three-dimensional surface can be quickly and conveniently selected and flattened for 2D painting by the artist in an interactive tool, with minimal distortion.
It does seem like the authoring tool is a huge reason why Disney has been so successful and had such a positive experience with their Ptex pipeline.
The good news: Disney Animation is taking a set of transfer tools and other utilities and making an open source version release. This generous move may yet prove to be the tipping point for Ptex for other facilities.
Why not stay with UVs?
- UVs are a hassle or bottleneck, often times requiring specialist stitching/seaming solutions
- UV filter seams, especially with displacements can be a problem
- UV distortion
- IO difficulty with tiled UVs: separate file per tile = 100x number of textures
Given the nature of seams and UV tiles, Ptex can provide a much stronger filtering environment. Ptex can provide seamless filtering which alone can be a major help to texture artists. Burley also points to the lack of setup time and effort with Ptex, avoiding UV's wasted space (empty texture areas), and arbitrary number of textures per file as just a few of the issues. Ptex also tends to be implemented in a way that is much more memory efficient not only for storage but also loading - with:
- Constant faces optimization (disk, memory, filter)
- Fine control over resolution, can differ per texture layer
- File format optimized for rendering, reducing file counts, minimizing seeks. e.g. all the textures for a given mipmap level are stored together
- No inherent per-face resolution limit; large face textures are tiled as needed.
On that last point the Disney team currently go up to 8k x 8k in their authoring tool, and are currently testing 16k.
Disney Animation's last four features have used Ptex completely: Bolt (2008), Tangled (2010), Wreck-It Ralph (2012), Frozen (2013), and their next film (due out later this year) continues to do so 100%, namely, Big Hero 6. These films store up to hundreds of GB of texture data per shot.
Image right above: The Disney Animation authoring tool showing the ease of retargeting
1. Original Model containing a total of 3064 quad faces
2. Original model topology, without textures
3. New model after a change to add a pair of raised rings. Face/vertex ordering has also been affected.
4. Due to model changes, the old Ptex does not map correctly. Some faces are missing texture entirely - other faces have the wrong image data. Transfer is a two-step process, both attempt to preserve texture quality. The face-to-face copying retains original texel data with no resampling, so perfect quality.
5. Many faces can be directly transferred pixel for pixel - this is very fast and preserves the quality perfectly.
6. The remaining faces are completed using a 3D location based transfer texel by texel. The new model has 3192 quad faces in total.
Cover art texture is not Disney it is photo credit: D Sharon Pruitt.
Special thanks to
Dan Candela, Head of Software (Disney Animation)
Brent Burley (PTex author & developer)
Dan Teece (Paint3D - Disney 3d paint package - author & developer)
Chuck Tappan (Look Supervisor)
Ryan Duncan (Look artist).
We've been a free service since 1999 and now rely on the generous contributions of readers like you. If you'd like to help support our work, please join the hundreds of others and become an fxinsider member.