PTex and Performance

[FSGFX]

Hi, there are a lot of rumors about PTex and its mipmapping and multithreading shortcomings.

How much is this affecting the render time and memmory usage. ?
Has someone done a side by side test with standard textures..?

[vlado]

I haven't done any side-by-side comparisons, but I can give it a try. The PTex library has multithreading issues in its original form, but we did extensive modifications to improve that...

Best regards,
Vlado

[FSGFX]

Thanks Vlado would be great to see a side by side comparison.

[vlado]

So far on a single i7 (8 logical cores), performance is almost identical between regular textures, tiled .tx and Ptex (provided that the tiled cache and Ptex cache are large enough). Tomorrow I will do some tests on a dual Xeon.

Best regards,
Vlado

[Morbid Angel]

After using ptex in few productions we determined that there is little benefit from ptex and here is why:

- it requires point order for displacement, so mesh changes are a problem
- same goes for textures, any geo change = rebake if your software supports it, we had problems using mudbox
- cool thing about ptex is you have no tiles so as we have geo that has 10-20-30 tiles ptex is better in that regard but its small benefit
- vector displacement is successful with ptex, but hard to get to work and not so plug and play

utimately for us production requires fast paced changes, ptex due to reasons above is not a fist choice for us.

[FSGFX]

Thanks for testing Vlado.
Would be interesting to know how well its working with mipmapping and ram usage.
Is it true that ptex also if the objects are far away has to hold a small texture for each face of the object in memmory..?
This could be a huge overhaed in complex scenes.

@Morbid
yes we encounter the same issues, but if you know about the shortcomings its a great tool.
we use it mainly for displacement the diffuse and most other maps are still uv based.
thanks for the input.

[vlado]

So I hit a small snag in my testing in that Ptex files out of Mudbox do not have mip-mapping; will see if I can convert them. In the meantime, with mip-maps built on the fly (which slows down the Ptex a bit), the results are as follows:

PNG files: 2m 52s (includes loading of the files and building of mip-maps)
TX files: 2m 42s (includes loading of the tiles, but the files already had mip-maps)
PTX file: 3m 8s (includes loading of the file and building mip-maps on the fly)

The rendered image is attached; disregard my painting skills It is a tough test as the reflective sphere and the GI cause almost all texture data to be loaded at various mip-map levels. The scene is intentionally very simple to put more stress on the texturing.

The machine is a dual Xeon (32 logical cores). As you see, the results are not too bad. If I manage to get Ptex files with mip-maps, it should be a bit better too, both in terms of rendering and in terms of RAM usage.

Best regards,
Vlado

[vlado]

Actually the files did have mip-maps, but we were always doing anisotropic filtering for PTex files, which was slowing things down. With isotropic filtering (like we do for the other textures), things are a bit faster so I will redo the test again.

Best regards,
Vlado

[FSGFX]

interesting what Marcos Fajardo thinks about ptex...
http://www.fxguide.com/featured/udim-uv-mapping/