Whatever happened to Ptex?

I understand that this cannot be used with the render engines, but would ptex textures work if I were say, to export it to the source engine using the smd/dmx exporter?

OpenSubdiv instead:

  • allows full threading, including use of GPU
  • creates and draws subsurfed “on the fly”, so you don’t need to generate/store data
  • has excellent crease support
  • has adaptive (screen space) subdivision
  • supports Ptex natively (non UV texture mapping)

Is there a developer, working on ptex support?

BTW, ptex is a great way to apply textures.
It isn’t always your best choice.

I think this is just a matter of learning to walk before we can run. OpenSubDiv has to happen first, and naturally Ptex will follow.

As was pointed out by the folks over at Solid Angle recently, the scalability of PTex is honestly pretty terrible. It was never really designed to be used alongside a path tracer. This means that threading will have to be improved on our side, or we’ll have to wait for the native PTex support in OIIO that is in the works to mature. At the moment integration would speed up artist workflow while painting, but the hit you would take on render times compared to simple UV mapping wouldn’t be worth it in any way, IMO.

PTex would be awesome for texture painting. You paint with a ptex texture, not having to worry about topology or Uvs, then bake to a normal uv texture once you’ve finalized the model.

Regarding PTex, what kind of performance one would expect in using Ptex on a sculpt in Blender (or any high poly model) in comparison to Vertex paint on it (very very slow on high poly in Blender) ?
Would it still be very slow on such model ?

OK, let’s say, we can paint in Ptex and ask for “baking” transferring in vpaint set. It may take some minutes but who cares.
Today, practically, we can’t paint on a 300k mesh in vpaint mode. Horrible performance.
It’s not zbrush, neither it’s 3dcoat. It’s blender.
But, neither we can vpaint a multires mesh.
This stopped in favor of Ptex. (Nicholas Bishop’s unfinished projects, if I recollect correctly).

Zbrush… just reminds me, it neither supports Ptex.

You could do this workflow now by placing a seam on every edge and unwrapping. This completely negates the benefits of PTex, mainly the ability to have per-face texel resolution. This will really be a non-starter (and indeed, it’s why Mr. Bishop’s work was halted) until we have a way to bake them AND quickly and reliably render them within Blender, and this is going to be an issue until some incompatibilities between the PTex file format and highly scalable methods like path tracing are sorted out.

Again, this is not a problem of the file format, this is a problem of the Pixar reference implementation library. You don’t have to use it, certainly not for rendering. Since Pixar uses path-tracing themselves now, they must have implemented it properly into Renderman.

By the way, does Arnold even use Mip-Maps? It’s certainly not necessary in a path-tracer where you have so many AA samples for free, but a Mip-Map cache system for Cycles could drastically reduce texture memory consumption and tie in well with Ptex.

Ptex really isn’t rocket science, I refuse to believe that Solid Angle can’t come up with a better implementation than what they have now, if it really scales so badly.

They give the option to use the MakeTX utility to create packed .tx files including mipmaps. Speedup is decent, and it’s fairly simple to write a batch script that will run it on entire folders of images. MakeTX comes with OIIO, there are plans to include it in Cycles in the future according to Brecht.

After speaking with a guy from Solid Angle the issue isn’t that they can’t come up with a better solution. It’s that right now they’re still trying to feel out the best way to handle it. They’ve branched OIIO on their own and made it almost fully scalable up to 64 threads at this point, so that’s an option for PTex as well, but they aren’t sure if that’s the right answer with PTex support in OIIO on the horizon. But the fact remains that Solid Angle added PTex in its recommended configuration, saw the terrible performance, and ripped it back out. On top of that, the PTex guys did their own implementation in Arnold and the results were even worse, embarrassingly so. There’s work to be done, and just tossing it into Cycles as is doesn’t seem to be a wise option.

Matthew, imo you compare a bit too much Cycles and Arnold. If Ptex “is bad” on Arnold doesn’t mean automatically it will with Cycles too, also because, i guess, we don’t even have all the threading magic and optimizations Arnold has.

Though, i will link the original article where i suppose you took these numbers. link At least Zalamander and others might get better what is this about and cast some more light on this “crappy ptex” thing. Because honestly Matthew, without any offence, you’re the proudest Arnold fanboy :slight_smile: You should also take into account RenderMan is their main competitor among the big boys, so highlighting they’re better at something is also “marketing” stuff, without meaning it’s not real of course.

“You would be surprised”, explained Fajardo, “even Disney’s almighty Ptex library, which caused so many ripples in the industry, is not threaded well and destroys the performance of your renders. Which is probably OK for Disney as they use PRman therefore running it on very few threads. But run it on all the threads of a powerful machine, as we did, on a simple scene with a single Ptex-textured polygon, and the results are abysmal.” Here are the results Solid Angle provided to support this claim

This doesn’t sound like they spent a lot of effort on it. I had a look at the Ptex code and it indeed uses locks everywhere, but that’s because it is meant for editing. I wouldn’t be surprised if they just wired the “getPixel” method into their texture lookup system and observed how it doesn’t scale. You can tell that using Ptex for in-flight lookups will not scale, by looking at the code for five minutes, no benchmarks required.

Otherwise, I don’t see what the threading/locking issue is for read-only data. PTex has been implemented multiple times to run on commodity OpenGL, it couldn’t be too hard getting it to run efficiently on the almighty CPU, could it?

IMO comparisons between Cycles and Arnold are very apt. The algorithms between the two are incredibly similar, and both will need to solve the same problems in more or less the same ways to be as efficient as possible. In fact, when using the non-progressive integrator you can almost do a 1-to-1 comparison between the two. I don’t think Cycles should aim for parity with Arnold, lest Brecht et al wear themselves ragged trying to keep up with a full company of graphics gurus, but one of the beautiful things about having a commercial company so willing to share papers and info based on the roadblocks they’ve encountered is that anyone working on a similar project can say “well, they ran into problems here, and if I trust that this info is valid I can skip the roadblock step and move directly into the fixing the problem step”. There’s a reason Brecht and others are excited to see the upcoming papers from Solid Angle on SSS, BVH implementation, etc. These are guys that know ray/path tracing down to its core, and making sure their work is competitively fast is their bread and butter. PTex is also reportedly one of their most requested feature additions, so when they says “It’s not ready for prime time in a path tracer” I’m inclined to believe them. They gain nothing by relying on OIIO, and would lose nothing by implementing PTex, so it’s clearly not just a case of laziness or stubbornness.

Zal, that’s clearly a different test than the ones I was told about. Different scenes were mentioned, each with poor performance, not just a single test with a single textured face. It would be rather silly to put the time into implementing PTex into your render engine only to run a single test, then throw up your hands in frustration and rip the code back out. Again, the studios using Arnold are clamoring for PTex support I’m sure, so it’s definitely in their best interest to get it working ASAP. But as with any company selling a product, it’s better to do it the right way out of the gate. It will likely be easier for Cycles to overcome this hurdle, wherever it might exist in the code, as Cycles isn’t aiming for 32-core scalability across the board, but we’ll have to wait and see what Brecht says or comes up with before anything can be said definitively.

PTex is also reportedly one of their most requested feature additions, so when they says “It’s not ready for prime time in a path tracer” I’m inclined to believe them

If that’s what they tell you, fair enough. The Ptex library is quite obviously not useful to use directly in a raytracer, for texture lookups. What they probably don’t want to tell you outright is that they aren’t willing to invest into a proper solution just now. I’m not saying they’re lazy, getting stable software out is one hell of a task, no matter how many “guru” programmers you have. But the users probably don’t want to hear something like that for an often-requested feature. It’s then easy to blame the PTex library instead and waive responsibility.

As you say, Cycles has the benefit of not having to please a lot of customers. You can have a working “not-quite-so-good” implementation that takes only 10% of the work of a fully-tested product.

Now, you got me, zalamander.
We’re searing collateral ideas.
If this is possible LOL

m9105826, haven’t said comparisons or similar problem solving have to be avoided, absolutely, but you also said some days ago ptex would be much welcome. Now SA says ptex has crappy threading capabilities compared to their texture engine, that is, quoting from the article

probably, the most efficient (in terms of threading) texture engine in the industry

Then my question is, would we lost these speed gain they have, implementing ptex? Rendering apart, Blender is a whole package, texture painting would benefit quite a lot with it, afaik there aren’t great FOSS 3d painting programs around, Blender might be the first (serious) one, so should BF avoid ptex because Arnold does not use it? That’s my point.