Topology changes and Non-manifold meshes
Jonathan Gibbs
I have a few questions about geometric restrictions for meshes to
which PTex will be applied.
The first is simple: are there any mesh topologies which PTex doesn't
support? In particular, it is ok with non-manifold meshes?
The second is a little longer:
Our FX dept will often increase the resolution of a mesh to add small
deformations to it as a part of shot work. It seems to me that I could
uniformly subdivide a mesh and the corresponding ptex would still be
valid if I did something like:
- bake the intrinsic UVs (face-vertex rate) and the face-ids (face
rate) into the mesh
- subdivide
- use the now explicit UVs and face-ids (which are no longer
unique across the mesh) to look up in the ptex file
I imagine that this would work fine at render-time with the correct
shader, but probably break some tools which assume the face-ids are
unique and that the UVs are always intrinsic. (Is it normal to assume
this?)
Further, our FX dept often totally changes the topology of the mesh
for things like fracturing/breaking objects. Of course, we need to
maintain the edges of each uv "region" in a traditionally UV'd model
in order for the texture to apply correctly, but we can do anything we
want away from the edges. I imagine with the above pipeline, this is
also true so long as all the original edges of the base mesh were left
in tact. That is, I can tessellate each base mesh face in any way I
like, so long as I don't remove the edges of each face (though I can
subdivide them). This is a little restrictive, but perhaps not too
bad.
Is what I describe normal for those using PTex? Are there other
approaches I am missing?
How are people dealing with fracturing/breaking objects after they've
been textured with PTex, especially if the resulting topology is
changing from frame to frame?
Very much thanks!
--jono
brentb
> The first is simple: are there any mesh topologies which PTex doesn't
> support? In particular, it is ok with non-manifold meshes?
edge and that there are only two faces sharing any given edge.
> Our FX dept will often increase the resolution of a mesh to add small
> deformations to it as a part of shot work. It seems to me that I could
> uniformly subdivide a mesh and the corresponding ptex would still be
> valid if I did something like:
> - bake the intrinsic UVs (face-vertex rate) and the face-ids (face
> rate) into the mesh
> - subdivide
> - use the now explicit UVs and face-ids (which are no longer
> unique across the mesh) to look up in the ptex file
we've begun subdividing in a regular order and specifying the subd
level as an attribute such that the shader can infer the "base" faceid
and uv from the subdivided ones using simple mod math.
> Further, our FX dept often totally changes the topology of the mesh
> for things like fracturing/breaking objects. Of course, we need to
> maintain the edges of each uv "region" in a traditionally UV'd model
> in order for the texture to apply correctly, but we can do anything we
> want away from the edges. I imagine with the above pipeline, this is
> also true so long as all the original edges of the base mesh were left
> in tact. That is, I can tessellate each base mesh face in any way I
> like, so long as I don't remove the edges of each face (though I can
> subdivide them). This is a little restrictive, but perhaps not too
> bad.
the fractured mesh. We've even using the Ptex triangle format for
this and rendered as a poly mesh at very high tessellation.
Jonathan Gibbs
On Mon, May 2, 2011 at 7:40 AM, brentb <brent....@disney.com> wrote:
> Ptex assumes that the winding order is the same for faces sharing an
> edge and that there are only two faces sharing any given edge.
I imagine if need be we could simply not tell ptex about a third face
sharing a single edge and all we'd loose would be nice filtering
across that edge for that third face.
> This is what we've traditionally done in our pipeline. More recently,
> we've begun subdividing in a regular order and specifying the subd
> level as an attribute such that the shader can infer the "base" faceid
> and uv from the subdivided ones using simple mod math.
Sound like a good solution.
> That should work, but we generally just do a point cloud transfer to
> the fractured mesh.
I imagine any quality loss from the re-sampling just doesn't matter
for VFX/animation work?
--jono
brentb
> I imagine if need be we could simply not tell ptex about a third face
> sharing a single edge and all we'd loose would be nice filtering
> across that edge for that third face.
least consistent, e.g. if face A is listed as a neighbor of B then B
should also be listed as the neighbor of A. If you have three faces
sharing an edge, the easiest thing might be to make the edge a border
for all of the faces.
> > That should work, but we generally just do a point cloud transfer to
> > the fractured mesh.
>
> I imagine any quality loss from the re-sampling just doesn't matter
> for VFX/animation work?
textures though so we usually have some room for resampling. Also,
only faces that are affected by the shatter need to be resampled. If
a face's position is the same in the old and new mesh (within some
threshold) then we just copy the texture verbatim.