|
From: Paolo C. <pao...@is...> - 2008-05-19 21:05:43
|
I would like to avoid the use of shaders, it seems to me a too not general solution. Far from the mesh processing spirit of MeshLab. There are two solutions 1) repeating. surely works, but increase the size of the final texture. 2) clipping the triangles. a bit harder. as a negative side it changes the topology of the mesh, increasing its complexity in terms of number of triangles and vertices. Luckyly enough the vcg library offers methods for this kind of clipping that make it in a almost automatic way. Look at the refine classes. Imho both of the two solution are viable. The best things could be to offer both options to the user and let him choose :) I would not consider resampling here. it is somethng that you can always perform (and probably in a better way) outside meshlab with any image tool, without touching at all the mesh. Do not concentrate too much on the size of the compressed textures. I do not think that it is the most important issue here. Cheers and thanks for your help p. skunkwerk wrote: > thanks Paolo, > page 10 of the paper here: > ftp://download.nvidia.com/developer/NVTextureSuite/Atlas_Tools/Texture_Atlas_Whitepaper.pdf > discusses this issue, and says you can either use pixel shaders (which > might be possible in meshlab, but not generic viewers) or just repeat > the texture however many times necessary in the atlas itself (wrap or > mirror modes) - i did a quick test in photoshop with a single and > tiled texture to see if it would be able to detect the tiling and not > increase the file size - however the original file was 240k, and the > tiled file ended up being 342k when using PNG. the other option might > be to simply resize the tiled textures to fit into the size occupied > by the original texture - but you would decrease the resolution by > doing so. but the 3d viewer at the default zoom would already display > a lower-resolution version of the texture if it must be repeated > within a fixed area, right? so the issue would only be visible at > higher zoom levels - when you might expect the resolution of a tiled > texture to increase, but doesn't. perhaps we could have a > user-selectable value that determines how we tradeoff texture atlas > size and tiled texture resolution? > > graci, > imran > > On Sun, May 18, 2008 at 10:58 PM, Paolo Cignoni > <pao...@is... <mailto:pao...@is...>> wrote: > > skunkwerk wrote: > > thanks Paolo, > > sorry - i should have caught that. I'm testing out the code > right > > now, and I need confirmation of UV coordinate formats: > > > > 1) if the coordinates are >1 that means the textures are to be > > repeated/tiled, correct? but meshlab can handle this, I don't > need to > > change anything. > > 2) what do negative uv coordinates mean? I assumed the origin > (0,0) > > was at the top-left corner of the textures. I don't see how you > could > > have negative uv coordinates (as i'm seeing in some models) > unless the > > origin is in the center. > > > > cheers, > > imran > > > yes texture coords out of the [0..1] range mean that the mesh is using > tiling and assuming that the texture is tiled. Tiling works also > in the > negative space. > > Note that when a mesh is using tiling the atalsing procedure it is not > very simple. > a simple clamping the the coords does not work verywell and can > produce > weird results. > > For example a triangle spanning from 0.9 to 1.1. cannot be > replaced with > a triangle spanning from 0.9 to 0.1, instead of simply crossing the > border thenewe traiangle crosses the whole texture. In this case the > only correct solution, i fear, is to split the triangle in two > along the > 1.0 tex coord value, so that we have two trianbgles, a first one > spanning from 0.9 to 1.0 and a second one spanning from 0.0 to 0.1. > > - as a first option do a modulo and simply issue a warning. > - as a second option we should clip the mesh. It can be done by using > the refineE and using a edge predicate that splits the edge only > if its > textture coords are not inside the 0.1 range. Multiple passes could be > required (separately for each texture coord axis) > > cheers > p. > > > > -- > Paolo Cignoni -- Senior Researcher > Visual Computing Laboratory - ISTI - CNR > http://vcg.isti.cnr.it/~cignoni <http://vcg.isti.cnr.it/%7Ecignoni> > > ISTI - CNR > Via Moruzzi 1, > 56124 Pisa > ITALY > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Meshlab-devel mailing list > Mes...@li... > <mailto:Mes...@li...> > https://lists.sourceforge.net/lists/listinfo/meshlab-devel > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > ------------------------------------------------------------------------ > > _______________________________________________ > Meshlab-devel mailing list > Mes...@li... > https://lists.sourceforge.net/lists/listinfo/meshlab-devel > -- Paolo Cignoni -- Senior Researcher Visual Computing Laboratory - ISTI - CNR http://vcg.isti.cnr.it/~cignoni ISTI - CNR Via Moruzzi 1, 56124 Pisa ITALY |
