Conversation

For every research paper that begins with "first, generate a unique texture parameterization", I point to the horrible agony of game developers trying to create reasonable texture parameterizations: twitter.com/ssylvan/status miciwan.com/SIGGRAPH2013/L gamasutra.com/view/feature/1 etc. :)

Quote Tweet

Sebastian Sylvan

@ssylvan

Nov 17, 2015

New blog post! Fixing texture seams with linear least squares: sebastiansylvan.com/post/LeastSqua

Replying to

True but in practice tbh we still do it all the time...

Replying to

...and depend on artists to hide all of seams, leaks, and discontinuities :/ I've seen a lot of bushes and rocks placed over terrain seams, decorative moulding covering lightmap leaks at corners, belts & armor covering normal map discontinuities.

Replying to

and

Good parameterizations, water-tight models, LODs, probe positions, etc. are all POSSIBLE, and artists achieve them every day. However, it is a mistake when research papers consider time-consuming manual tuning and least-bad automated solutions to be a robust turnkey process.

Replying to

and

I think this _could_ be turnkey, but takes a lot of effort. Someone could probably make a good living doing nothing but developing a UV atlas middleware library (optimal splits, chart packing, seams, etc... and then after all that, make it super robust and fast).

Replying to

and

Disney's PTex fully solves this for the artist. It introduces performance issues on the GPU (filtering is particularly expensive), but I wonder if the other costs could be amortized...

Replying to

and

Without HW support, ptex isn't a great fit for real time. sebastiansylvan.com/post/casting-a I mean.. that's six years ago. Still no major Ptex use in games...

sebastiansylvan.com

Casting a Critical Eye on GPU PTex

Replying to

For offline work though, it's great. All of the downsides kinda go away there.

Replying to

Err, Ptex in offline rendering is not rosy actually...

Replying to

Ut oh. Can you describe some of the limitations? On the real-time side, we've all heard it is great and are headed in that direction!

Replying to

Simplifying to some extent, Ptex is per-face mipmaps pyramid. 1) the table of offsets to the tiles data can be huge for densely modeled objects and it must be kept in memory if any minimum random access is required (path tracing).

4:51 PM · Feb 21, 2018

Replying to

2) the table of offsets is Zip-compressed in a single block. You must read it all at once, no chance of reading only a small “low res” block of data for LOD.

Replying to

3) for densely modeled object, or at a distance, there is no filtering if faces are smaller than a pixel (or ray footprint). This because the top most aggregation level is the per-face 1x1 mipmap. Thus AA requires supersampling from outside the texture subsystem.

Show replies

Replying to

Is pre-tessellation a factor? I.e is this made worse because you are dicing PTex to micro polygons?

Replying to

Depends on how “pre” the pre-tessellation is. If you mean that tessellation is done before frame rendering, then no, that is not an issue: Per micropolygon indices to the original unsubdivided faces and the face UV is all that you need to access ptex for the unsubdivided model.

Show replies