strange effect with UV-maps and multires

[Gaia_Clary]

hi;

i found some weird thing during learning UV-mapping: i created a plane object.
then i did the following sequence:

1.) go to edit mode
2.) subdivide 3 times. now i have a plane with 88 faces
3.) mesh -> UV-unwrap -> unwrap. Now i get an ideal uv map (88 squares, see pic 1)
4.) Now warp the mesh into a cylinder. i place 3D cursor below the plane, then
warp 360 degrees (W-360), so that the plane looks like a cylinder now.
5.) i locate the seem, where the left and the right side of the plane are wrapped together.
the seem is highlighted in pic.2 .
i remove double vertices now. and i end up with a perfect cylinder and a perfect UV-map.
everything is intact until here.

now trouble starts.

6.) I add one level of multires (either catmul-clark, or simple subdiv, it doesn’t matter for the effect). When i now look at the UV map, i see 16*16 squares as expected. But when i select the same vertex row in the cylinder, as before, i expect to select the vertices along the sides of the UV-map. But there is a sudden shift at the top 2 rows of the UV-map (see pic 3).

i tried everything to avoid this effect, but as soon as i add a level of multires, the effect apears (ok, in very rare cases the effect does NOT occur, but i was not able to tell, when that happens, and whn it does not happen). The effect only appears when i add multires, AFTER i have applied the Warp-tool.

If i apply multires to the simple plaine, the UV-map looks like expected,
but now i can’t remove the double vertices from point 5 (multires does not allow to remove vertices)

Anyone got an idea, what could cause this effect and how i could avoid it ? Yes, i know, there are simpler ways to get a perfectly unwrapped cylinder, but id like to understand my error.

thank you in advance.

Attachments

[Gaia_Clary]

ups… Maybe i asked in the wrong forum ? Can anyone give me a suggestion for a better place to ask my question ? thank you in advance

[musk]

Have you tried applying the multires? I think the problem is that uv unwrapping doesn’t support the multires datatype in the way you are using it. Try unwrapping again once you added the multires as another alternative.

And no you have not posted in the wrong place it is just that nobody has had this problem befor and knows a solution.

[jpbouza]

Yeah, don´t mix multires with unwrapping…Actually, try not to mix multires with ANYTHING!! (at least until the new MultiRes functionalities that are being developed are added to the main Blender branch)

First do your unwrapping, your texturing and all you edits, and in the last step of your workflow add multires. Or apply it first, as Musk Says.

[Gaia_Clary]

thank you very much for your answers.
so i am stuck in a deadlock situation, because i want to unwrap, before i am manipulating the plane (that makes unwrapping so easy for my application).

Then i want to bend the plane into a cylinder, then remove douplicates, where
the plane left/right sides touch each other after the bending.
When i apply multires before removing the douplicates, i get an error (cant modify the mesh in multires mode)
when i apply multires after removing the doubles, i get the unwrapp-problem as described.

well, then i have to keep mulitres out of the way for some time…
thank you anyways for giving me at least the insight, that there is an ongoing development with multires. maybe (hopefully) my observations even can give some hints to the developers.

[musk]

May ask why you are using such a weird workflow to unwrap a cylinder?

[Gaia_Clary]

unintentional duplicate removed…

[Gaia_Clary]

sure, the point is much more complex, than unwrapping a cylinder in such a weird way

the main point is, that i want to create objects for second life. In second life basically 4 mesh types are supported: sphere, cylinder, plane and torus. But these objects are not imported/transported as simple .obj or any other common used 3D format.

We must create so called “texture maps” instead, which are basically images of size 3232 pixels, where each pixel transports 3 8-bit values (red,green,blue coded) Each pixel represents a vector, that defines the offset of one vertex relative to the object center. Thus each object for second life can use exaclty 3232=1024 faces and about 1024 vertices (depending whether we use a plane,a cylinder, a sphere, or a torus the exact amount of used vertices differs due to removed douplicate vertices at the stitching sides)

We can create such images easily by some transformations of an UV-map. But we need “perfectly unwrapped objects”. i.e. the uv-map must use 8*8 squared quads and it must not contain any holes. So the perfect unwrap takes place when unwrapping a simple blender plane. After the plane is unwrapped, i can bend it to my final object shape (for instance a simple cylinder, torus, sphere, or more complex objects, e.g. a whine glass, a more organic shape, or whatever else). The good thing is, that the UV-map does not change, once the unwrapping (of the simple plane) has taken place. So after finishing my sculpting, i just bake the final uv-image and i am ready for import to second life.

The exact workflow is described in my recent tutorial “sculpted prims for blender purists” which can be found at blog.machinimatrix.org and it is the easiest “pure” workflow (without any scripts), which i know. (well i found an even
easier workflow for the color encoding, but this is another story)

But to make the process realy complete, i want to add multires too, because this is an important concept and it can be used to enhance visualising quality in second life. So i tried to subdivide my initial plane 3 times then add 2 levels of multires and now i clash severely as i explained previously. just keping multires aside gives perfect results…

so… maybe you understand a bit better, why i try to use this weird unwraping. it is the target domain, which enforces this. But maybe … there are other ways to get my goal, which i am not aware off. So if any other (easy!) path leads to similar results… i would be happy to learn them.

[Gaia_Clary]

hi;

I just wanted to tell you, that the strange effect with UV-unwrapping, has been “partially” curred within the newest 2.47 RC (build 16019M) . After thinking a bit about what we can see there, we decided now to report this as a bug. This bug has already been reported to the blender bug-tracker by one of us, see

http://projects.blender.org/tracker/index.php?func=detail&aid=17506&group_id=9&atid=125

Although i personally am still not 100% sure, whether we realy are working in the correct way here. So here is a snippet from the bug report mentioned above, that might help understanding, what goes wrong (either in our process, or within blender ) …

This is the path along we go and eventually fail:

0.) open the bugreport.blend file (see attachment)
1.) go to edit mode
2.) subdivide 3 times
3.) rotate the object 90 deg along the x-axis (r x 90)
4.) place 3D cursor at <0,0,-0.5>
5.) mesh -> unwrap -> unwrap
6.) Warp 360 deg. (W 360) (thus creating a cylinder)
7.) remove doubles (w 6)
8.) in the UV image editor create a new image (size= 64*64)
9.) add multires
10.) add 2 levels of multires
11.) select all vertices
12.) render -> bake render meshes -> full render

Now we see typically 2 squared areas within the final image, which are rotated by 180 degrees with regards to the rest of the image. These 2 rotated squares destroy the otherwise smooth color transition in the rest of the image. (see also the attached file “distorted.png” ), you see, what i mean immediately at the top left and top right corners of the image. If you rotate the two squares by 180 degrees, the resulting image looks again smooth and as expected (see expected.png)

We even found a workaround to avoid this effect:
If we add an additional render -> bake render meshes -> full render
right BEFORE we add multires, then proceed with multires as described above, the final render->bake produces a correct result…

BTW: if we postpone the image creation step to immediately before we do the final bake, then blender reports that it can’t find an image to bake to… And this is realy something i do NOT understand at all ;-(

Attachments

bugreport.blend (147 KB)