|
![](/i/fill.gif) |
On 7-12-2012 20:52, MichaelJF wrote:
> Hm, this must be a misunderstanding. I used an animation to compute the
> occlusion maps one after the other for every mesh involved. Having 1107 meshes
> in a union I had to bake the occlusion map for ever mesh against their union.
> Every single mesh has to have its own uv-mapping. The animation was only a
> technique to bake all the maps needed. To explain this a little bit more: I have
> one mesh for the body of Theseus, one for his head, one for his filled holes
> (with Meshlab), one for his penis and 1103 for his locks. The "animation" was
> simply to switch through all this meshes and bake occlusion maps for every
> single mesh. In the end I put them all together in applying the results to the
> proper objects. For use with the mesh-cam you must have an uv-mapping for every
> single mesh involved. You cannot combine them. That was the task here. With the
> mesh-cam uv-mapping has to be different from simple texturing. With simple
> texturing you can have overlapping areas, like PoseRay does it. FlyerX modifies
> the uv-mapping slightly from tube to tube most likely to have a certain
> variation with the texture but this did not address the issues of the mesh cam.
> Here you need a one-to-one allocotion from the uv-map to the point at the object
> surface. That was the reason to tear the PoseRay-results into parts and render
> them one after the other in an "animated" sequence.
I have not much experience with the mesh cam yet, which explains my
comment :-) Thanks for the explanation.
Thomas
Post a reply to this message
|
![](/i/fill.gif) |