Ptex format for 3DCoat?

Ptex is a texture mapping system developed by Walt Disney Animation Studios for production-quality rendering:

* No UV assignment is required! Ptex applies a separate texture to each face of a subdivision or polygon mesh. * The Ptex file format can efficiently store hundreds of thousands of texture images in a single file. * The Ptex API provides cached file I/O and high-quality filtering - everything that is needed to easily add Ptex support to a production-quality renderer or texture authoring application.

ZBrush has basically had the same thing for years. The problem is that you can end up with seams between all those little tiles. So hundreds of tiles means hundreds of seams. The seams are especially noticeable if you use any form of texture compression, or if your model has a specular shader applied. I don't know why it is, but specular+bump shaders have a way of exposing seams. You can even see this in 3D Coat just by painting specular over a known UV seam. And it can be even more visible when you export to another 3D engine with different shaders.

So despite ZBrush's auto UV mapping the pros still manually UV map their models in order to hide and minimize the number of seams.

It's funny in some ways because 3D Coat already does auto mapping (cubic) with minimal texture stretching. So why don't you guys use it?. Could it be because the seams still show?

But who knows, perhaps the ptex guys have found a magical formula for dealing with seams. But I seriously doubt it.

I don't think this is the same as what zb uses, but I don't know enough on the topic to discuss it. I can say that this works wonderfully as just about every surface of the movie Bolt uses it and I doubt they would've done that if they didn't love it.

Ptex is very close to microvertex painting. So I think I will do it. Yes, seams problem is not too easy, but it could be solved too.
Possibly Ptex support will be done as additional plugin and possibly not for free because this technology is too unique and far not everyone needs it.

I don't think this is the same as what zb uses, but I don't know enough on the topic to discuss it. I can say that this works wonderfully as just about every surface of the movie Bolt uses it and I doubt they would've done that if they didn't love it.

It's basically the same as ZBrush's AUVTiles mapping.

If your target is a renderer (like mental ray etc) then you will be able to get away with it. But if you plan on using a game engine then you may be disappointed if you plan on using texture compression or specular maps.

But keep in mind that 3D Coat's current auto mapping will also suffice for high quality renderers in the same way PTex does.

Ptex is very close to microvertex painting. So I think I will do it. Yes, seams problem is not too easy, but it could be solved too.Possibly Ptex support will be done as additional plugin and possibly not for free because this technology is too unique and far not everyone needs it.

I'm pretty sure Ptex is _not_ in Zbrush though it might have something similar.

Yep, very similar. But not the same code.

It specifically deals with the seams problem to prevent any visible seams.

To be fair, the seam problem isn't a PTex (or AUVTiles) problem. It's a problem relating to texture compression and game engine specular maps. And I suspect the specular map seam issue is a limitation of 3D hardware and so therefore out of the hands of 3D modeling application programmers like Andrew. But if you don't plan on using specular maps (in relation to game engines) or texture compression then it's not a problem.

But for the ptex guys to say "There's no seams" may be misleading some game engine artists to think they've found the answer to all their UV problems.

If it has one similar in ZB no doubt they will put this in that app now, there seems to be a lot of hype for this on CG sites at the moment. When it is added in 3DC (sound like it will now) then it might get the program some interest because people will post and someone will say thats in 3DC getting it interest. The problem is all the other app developers probably have seen this and will be adding it in also soon.

Adding great ideas while they are new is always a good idea and it also makes the app well known for having it first

I fail to see the logic reasoning why people would not want this type of tech in 3DC. It shaves hours of work and improves the quality for all who do texturing, and then you wanna sell that as a separate module ?!

I fail to see the logic reasoning why people would not want this type of tech in 3DC. It shaves hours of work and improves the quality for all who do texturing, and then you wanna sell that as a separate module ?!

Because at this point most renderers can't render it, so you would have to paint with it, then bake it to a UV map anyway, so you might as well just paint the UV map in the first place.

For those thinking it is similar to AUV tiles in Zbrush, it is not at all. Zbrush still creates UVs, just automatically and per polygon but uses a single texture map. This is no different then unitizing and an automatic layout of UVs within Maya.

The differance here, is that each polygon gets a 0-1 texture space. So imagine each polygon gets its own texture map, and the user decides the resolution of this texture map. I imagine there is some clever way of loading and unloading each texture map so you can work at highResolutions but not have the entire texture set of the object in Memory. Film Characters will often get hundreads of 4k texture maps!

The issue of course is that the only supported render engine is Renderman. Wether the other render engines integrate it is pure speculation.

For those thinking it is similar to AUV tiles in Zbrush, it is not at all. Zbrush still creates UVs, just automatically and per polygon but uses a single texture map. This is no different then unitizing and an automatic layout of UVs within Maya.

The differance here, is that each polygon gets a 0-1 texture space. So imagine each polygon gets its own texture map, and the user decides the resolution of this texture map. I imagine there is some clever way of loading and unloading each texture map so you can work at highResolutions but not have the entire texture set of the object in Memory. Film Characters will often get hundreads of 4k texture maps!

The issue of course is that the only supported render engine is Renderman. Wether the other render engines integrate it is pure speculation.

Unless using vertex coloring then the resulting model (in a real time 3D engine) will still need UVs. And it still ultimately adds up to the same thing as AUVTiles in that eech polygon is assigned a unique piece of texture. and that neighboring polygons don't share a neighboring piece of texture, therefore resulting in the potential for seams (in game engines).

A guy from Maxon requested that I post this on the CGTalk thread about Ptex:

Ptex is nothing like AUV, AUV fits small polygons on a texture, it is still a UV on a texture space. Really what ptex is more like, is storing a separate texture image per polygon, and then containing all those separate textures in one file. It is not each separate polygon on one big texture like AUV. You can change a single polygons resolution at anytime.