New mesh algorithm to improve performance?
- Thread starter bdmosky
- Start date
I guess it would have to assume that all the texture coordinates were applied linearly. AHH! Reading further I see it is to post-process triangles output from a scanner, in which case you probably only have position information and want to reduce a ludicrous number of triangles to something managable.
It's a shame it's limited to flat surfaces. It'd perhaps be more useful if it could output curved data such as Bezier or B-Spline patches, or, say, Catmull-Clark subdivision surfaces.
In terms of usefulness to rendering, I'm more interested by the polygon->normal map technique where a very detailed model is replaced by a much simpler model and a custom normal map.
It's a shame it's limited to flat surfaces. It'd perhaps be more useful if it could output curved data such as Bezier or B-Spline patches, or, say, Catmull-Clark subdivision surfaces.
In terms of usefulness to rendering, I'm more interested by the polygon->normal map technique where a very detailed model is replaced by a much simpler model and a custom normal map.
Simon, have you looked at Hoppes work on geometry textures?
They have some really pretty interesting properties, since you effectively remesh the model completly regularly, you can trivially subdivide the result.
The results are far from perfect, but it's a really interesting approach.
They have some really pretty interesting properties, since you effectively remesh the model completly regularly, you can trivially subdivide the result.
The results are far from perfect, but it's a really interesting approach.
IMHO geometry textures have too many problems at this time.
GT work well with vertices without extra attributes, like color, texture coordinates, normals, and so on..
Trying to find a good parametrization with low distorsion on all the attributes it's not an easy problem to solve (if it's solvable at all..)
A completely regular mesh is an interesting object to work with..it's very easy to render/subdivide and I believe we'll see soon some approach that mixes GT with some other multiresolution representation scheme on the extra vertex attributes (displaced subdivision surfaces would be a good candidate imho)
ciao,
Marco
GT work well with vertices without extra attributes, like color, texture coordinates, normals, and so on..
Trying to find a good parametrization with low distorsion on all the attributes it's not an easy problem to solve (if it's solvable at all..)
A completely regular mesh is an interesting object to work with..it's very easy to render/subdivide and I believe we'll see soon some approach that mixes GT with some other multiresolution representation scheme on the extra vertex attributes (displaced subdivision surfaces would be a good candidate imho)
ciao,
Marco
nAo said:
Well I think we can all agree that if you define good as not having order of magnitude fluctations of the number of samples per area then it is not going to be solveable, no more than you can find a good resolution for a regular grid shadow map.
Both need the same solution IMO. Adaptive resolution texture maps ... no matter how much it sucks from an implementation point of view.
The nice thing is that in some cases it doesn't suck at all.MfA said:
One can use a very low resolution geometry texture to encode a low resolution mesh from its high resolution counterpart.
The process of further subdivide the coarse mesh can be much more simple with a now completely regular mesh and one can use a lot of different algorithms here, from a standard midpoint insertion/quad split to subdivision surfaces.
A smooth subdivision scheme can be slow at run time but it has the potential to be coupled with a smoother displacement map too that can be compressed (wavelets?) much more effectively, so trade offs have to be made.
In displaced subdivision surfaces each triangle (a quad in a GT framework) has 'attached' a fixed resolution displacement map, but it doesn't have to be that way. It may be desiderable to store different resolution displacement maps (or other attributes, like vertex colors, normals, glossiness, and so on..) on each base quad in the GT. In a highly programmable (and highly parallel..eheh
) architecture you don't need to make random memory accesses in order to render a GT mesh, every memory access become streamlined and adaptive texture maps (or better.. scalar fields associated to base quads) are much more simple to implement, imho.Obviously I ignored a lot of small and not so small problems here..like seams and t-junctions creation between different resolution scalar fields on close to each other base quads, topological restrictions on the high resolution mesh, etc..
ciao,
Marco
Similar threads
