Page 1 of 1

### Decimater

Posted: Tue Jan 20, 2004 8:30 am
It would be really great to not have it remove uv mapping -_-

Posted: Tue Jan 20, 2004 9:32 am
Could never be perfect but If I had the time I dont think it would be that hard (in python that is).
It would just need to do approximations using new new vert position and find the UV co-ords from the old face to re-assign new UV-coords.

It would stuff up with complex mesh's that were decimated a lot and could never be expected to accuratly re-assign non-contigues UV maps.

- Cam

Posted: Wed Jan 21, 2004 2:12 am
if I knew how the decimeter work I woulda wrote a script to reassign uv mapping -_-

Posted: Wed Jan 21, 2004 5:22 am
Sutabi wrote:if I knew how the decimeter work I woulda wrote a script to reassign uv mapping -_-
you really don't need to know how the decimator works to do that
(but it would be a pain, worrying about faces in normal direction from each vertex....)

(the following I assume you know how these commands work in wings3d)
from my playing with the decimator, it appears it colapses edges that have little or no significance to the mesh (low angles on these edges) until it reaches or passes the number you specified, however the result of the colapse can produce faces that point the wrong way (try decimating a 2d filled donut shape). However, with this method, (if implemented in python) it is almost trivial to keep vertex colors, uv coordinates, and material information, and not much more difficult to care about them when decimating.

(need to look at the source for this)

Posted: Wed Jan 21, 2004 5:41 am
YOu could do this without knowing how the decimator worked.
It would just copy the UV's from one selected object onto another making approximations is the to co-ordinates.

If the mesh was low poly to start with then It would probably show but for mesh's with smooth, high poly surfaces I think it would port fine.

This is how it would work (its messt, and would be better off in the decimator code its self, but OI think it would work well enough)

Ok
newMesh = .....
oldMesh = .....
Loop through newMesh faces:
loop through newMesh face verts. (only 3/4 of course)
loop through oldMesh faces
Store the oldmesh's face distance newmesh's vert position
AND the face normal compared to the newMesh's face normal.
IF the combine normal and postional distance is smaller then
...the previousle recorded one then
CloseFace = oldmesh.closefaceIndex

# Now we have the closest face work out the UV's
# This would ned to use some vector maths but youd need to find where the vert's XY is in reference from the vector of the face normal.
# Then youd calculate the interpolated UV Coords using the new position. Then Assign it to the faces vert.

Thats it, would also work for Vertex colours.

Could some experienced blender coder tell me weather this is a totaly stupid way of doing this?
Im quiet sure it would work but I could be going about it a long way.

-Cam

Posted: Wed Jan 21, 2004 9:32 am
I would see this working in conjunction with a needed feature in the UV-editor:

1) 'welding' of verts in the UV window. This would allow us to have 'mesh' groups which correspond to the UV map. With seam edges just like the UVmap (eg. chest/arms)

2) When decimating, the decimater would NOT affect the mesh map seam edges but would only work on the internal 'welded' points.

As ,eg. a body, may be UV mapped in parts, the hard part would be because during decimation some of the new faces would need to now be in differnt parts of the same map (eg where shoulder meets arm) - which is impossible with only one uvmap per face. If the decimation does not occur at 'seams' then is should not be a problem imo. This also has the added advantage that with careful preperation of where your seams occur, you could keep your model somewhat animatable even after considerable decimation.

Its all in the seams, i say! or so it seems...

Posted: Wed Jan 21, 2004 1:56 pm
ilac wrote:1) 'welding' of verts in the UV window. This would allow us to have 'mesh' groups which correspond to the UV map. With seam edges just like the UVmap (eg. chest/arms)
If I understand what you mean by weld, you can already do that in the UV editor.

Just select the points you want to weld to the same place and scale them together to zero. Select them with border select in subsequent moves and the points are more or less welded.

If you don't want to move one or more vertices, if you just zoom in very close in the UV/Image editor, you actually run into a resolution limitation which sort of works like a snap-to-grid.

Both are one point at a time though, so its more time consuming than other versions of a weld I can dream up, .

Posted: Wed Jan 21, 2004 5:16 pm
zaz wrote:
ilac wrote:1) 'welding' of verts in the UV window. This would allow us to have 'mesh' groups which correspond to the UV map. With seam edges just like the UVmap (eg. chest/arms)
If I understand what you mean by weld, you can already do that in the UV editor.

Just select the points you want to weld to the same place and scale them together to zero. Select them with border select in subsequent moves and the points are more or less welded.

If you don't want to move one or more vertices, if you just zoom in very close in the UV/Image editor, you actually run into a resolution limitation which sort of works like a snap-to-grid.

Both are one point at a time though, so its more time consuming than other versions of a weld I can dream up, .
Thanks - but you're missing the point: By scaling you are putting them in the same place. They are not 'one'. They just look like it. It's not a property of the vertex - This property is relevant to the UV+decimation argument - which is what this thread is about.

The mesh in the 3d window shares vertices amongst adjacent faces. The 'mesh' in the uv window has individual vertices for each face - no matter how much you can scale them together - they might be overlapping but they are not 'one'. Welding means that UV faces get to share vertices - and that is the important property for decimation:
Vertices that are shared amongst ALL faces they are part of can be considered for removal. Vertices that are not shared by all the faces they form must not be removed by the decimation (or at least the chain they form can be reduced/decimated). These would be the vertices that form the seams (outline)

Posted: Sun May 29, 2005 9:51 am
hm.... just bumping a feature request. I never got aroiund to devloping the script and my hands is full with my renderman app

Posted: Mon May 30, 2005 1:02 am
Well, I tried to write a script to restore uv mapping/vertex colors to meshes after decimation, but I decided it would be better to write my own decimator

I wrote a bunch, but kind of gave up...

well anyway, the decimator isn't intended as a tool to reduce the polygon count of existing [good] meshes for lower LOD levels in games, but rather to reduce the polygon count of scanned data.

this makes its lack of preservation of uv mapping, material assignment, vertex colors completly tolerable [scanned data doesn't have this stuff, so you can't really loose it]

however, the decimator seems primarily used in the first situation I mentioned, to reduce the polygon count of a nearly complete mesh with uv, material, and vertex colors

so, it needs to preserve these things, and reduce the polygon count keeping them in mind. Also, a decimator that does this will be able to work with scanned meshes, though it will probably be slower and have different bugs.

now, NVidia's tool melody has a mesh decimation feature, and from what I've read I'd imagine it does what we would like. The code for the decimation stuffs appears to be under GPL or LGPL and is available from [may have to click a couple links]:
http://graphics.cs.uiuc.edu/~garland/software.html

also check out that person's papers, some cool stuff there