New Seamless Texturing Technique

[Cignoni]

Hello,

I just wanted to know the hard coder opinion of this community about a new technique, called PolyCube-Map, for texture parameterization that is:

• seamless,
• mesh-independent (e.g. LOD robust)
• with a low-distortion,
• texture space efficient,
• mipmap robust,
• if you need it can be user controlled (YOU can decide what are the important portions of the mesh)

This technique was recently developed by our group (vcg.isti.cnr.it) and that we will present it at next siggraph. From the abstract:
Standard texture mapping of real-world meshes suffers from the presence of seams that need to be introduced in order to avoid excessive distortions and to make the topology of the mesh compatible to the one of the texture domain. In contrast, cube maps provide a mechanism that could be used for seamless texture mapping with low distortion, but only if the object roughly resembles a cube. We extend this concept to arbitrary meshes by using as texture domain the surface of a polycube whose shape is similar to that of the given mesh

Obviously the technique can be implemented in opengl with current hardware.

More info, pictures, a paper and a short movie at the following link:

http://vcg.isti.cnr.it/polycubemaps/

Your comments, opinions and critics are very welcome.

[Korval]

I haven't seen any real problems with seams in modern games. This is more of a solution looking for a problem.

[Pop N Fresh]

I thought the paper was excellent. I'll be awaiting the downloads.

I'm curious to see how your technique would works with texture space rendering. Something like described in ATI's skin shading paper from this year's GDC. Have you experimented using PolyCube-Map with any of these techniques?

[rgpc]

Originally posted by Korval:
I haven't seen any real problems with seams in modern games. This is more of a solution looking for a problem.

Could that be because the artists spend a great deal of time making sure they've fixed the seams? Rather than having the code do it for you?

[Cignoni]

@ rgpc
Yes! you got the main point, until now seams were mainly a artist issue. From the point of view of the coders you just need to handle the fact that the same point with the same vertex and normal could have more than a texture coordinate.

Now with the coming of render to texture algorithms seams are an issue also for us. Look at ATI slides for skin rendering (slide 21: first item "texture seams can be a problem..." ): they have to cope to the discontinuity of the parametrization in a explicit way.

With the polycube maps texturing coords will be something that is really 'per vertex' (no needs of sending the same vertex to the gpu with different tex coords), so simpler data structrures, better striping ecc.

[CatAtWork]

Agreed. Every modeller I know constantly bemoans texturing. One of my coworkers loves Z-Brush, but the mappings it generates are less than ideal.

[plasmonster]

In my opinion, the motivation for a technique like this is a no-brainer. The closer the intermediate surface resmembles the actual surface being mapped, the better. This is an excellent solution.

The paper mentions the problem with the shift operation in current hardware, and the associated fix. I wonder if near-future hardware will support bit operations, and have the fragment horsepower to handle this technique. I certainly hope so.

[davepermen]

great work. can't imagine how happy my favourite artist friend is, once he gets that link later this day. currently, he's sleeping, so i hope he has nice dreams, and not nightmares about texturing

and i, on my side, am rather happy with it, too.. this could help programmers art, too, as they are even less keen at texturing

[Korval]

This is an excellent solution.

Except for the whole performance issue. This isn't like parallax bump mapping, which has a fairly negligable impact on performance (compared to having bump mapping at all) for a massive impact on visual quality.

This technique trades per-fragment performance for artist time and some small per-vertex performance benifit in terms of stripping. I, for one, don't believe in trading performance for anything less than a non-trivial visual quality improvement. We're talking about operations that are non-trivially complex.

Artists, while they may bemoan doing it, still can do it. As such, the problem is solved.

Now, if hardware starts implementing this, such that my texture accesses can automatically do it, that's a different story. But, until then, I can find more important things to spend performance on.

[davepermen]

korval: this is RESEARCH. we know you don't give fuzz about that, but this is research, and never ment to be fast by the start. once we have the demo, people can start to optimize and compare against it, and next-gen-hw can start to show features that help to optimize it.

but we see more and more the invisible part of the power of fragment shaders: the ability to do anything to texture. different shaders to sample different sorts of shadow-depth-maps, different shaders for autogenerated texture maps in this case.

the more we can automatize this whole process, the more artists can do art. this can help solve most of the lightmappers issues of seams, it can help autogenerating doom3 style multilod bump/parallaxmapped characters out of high-res-models, etc.

lets not start a flamewar about this just because of performance. this is never an issue if you develop something new. once its working, it starts to be one. never before.

just delay your game because of some sourceleaks for another half or full year, and hw advanced much enough to be fast enough again