Joining two objects with different UVs destroys UVs of one object in some specific, reproducable, cases #37577

New Issue

Jonatan Bijl · 2013-11-22T10:36:35+01:00

Jonatan Bijl commented

2013-11-22 10:36:35 +01:00

System Information
WinXP, nvidia 9800GT

Blender Version
Broken: Blender 2.69 (r60995)
Worked: Blender 2.69RC1 (r60597)

Short description of error
Joining two objects with different UVs resets the UVs of one or more objects to (0,0) in some specific cases (see below)
Note that this bug is an attempt to more specifically describe the (uncorrectly rejected) bug http://developer.blender.org/T37182

Exact steps for others to reproduce the error

I consistently get this bug when I do the following steps:

create a cube (or any other mesh primitive)
go to edit mode and unwrap the cube (for this bug the kind of unwrapping does not really matter)
go back to object mode and duplicate the cube (using shift-d)
go to edit mode, and unwrap the second cube in a different way (so it has different uvs)
go back to object mode, Shift-select the first cube, and press Ctrl+J
in edit mode, the uvs of one of the two cubes appear as expected, the uvs of the other have gone to the lower-left corner of the uv layer. There is still only one UV layer, called "UVMap" (as it was in each of the two cubes before joining)

Other cases:

same as above, but then with three copies. when joining, only the active object loses its UVs. The uvs of the other two objects are preserved
a python script of mine which creates piles of objects by copying them and joining them. (have not been able to create a simplified version to add to this bug)

Cases when this behaviour does not occur:

When I ctrl-Z until just before the join, and then join again, it works as expected (both cubes keep their UV layout). So there is something weird and buggy and inconsistent going on.
When I separately create two cubes, unwrap each, and join them

**System Information** WinXP, nvidia 9800GT **Blender Version** Broken: Blender 2.69 (r60995) Worked: Blender 2.69RC1 (r60597) **Short description of error** Joining two objects with different UVs resets the UVs of one or more objects to (0,0) in some specific cases (see below) Note that this bug is an attempt to more specifically describe the (uncorrectly rejected) bug http://developer.blender.org/T37182 **Exact steps for others to reproduce the error** I consistently get this bug when I do the following steps: - create a cube (or any other mesh primitive) - go to edit mode and unwrap the cube (for this bug the kind of unwrapping does not really matter) - go back to object mode and duplicate the cube (using shift-d) - go to edit mode, and unwrap the second cube in a different way (so it has different uvs) - go back to object mode, Shift-select the first cube, and press Ctrl+J - in edit mode, the uvs of one of the two cubes appear as expected, the uvs of the other have gone to the lower-left corner of the uv layer. There is still only one UV layer, called "UVMap" (as it was in each of the two cubes before joining) Other cases: - same as above, but then with three copies. when joining, only the active object loses its UVs. The uvs of the other two objects are preserved - a python script of mine which creates piles of objects by copying them and joining them. (have not been able to create a simplified version to add to this bug) Cases when this behaviour **does not** occur: - When I ctrl-Z until just before the join, and then join again, it works as expected (both cubes keep their UV layout). So there is something weird and buggy and inconsistent going on. - When I separately create two cubes, unwrap each, and join them

Jonatan Bijl commented

2013-11-22 10:36:35 +01:00

Changed status to: 'Open'

Jonatan Bijl commented

2013-11-22 10:36:35 +01:00

Added subscriber: @jonim8or

blender-admin commented

2013-11-22 10:36:35 +01:00

#37182 was marked as duplicate of this issue

blender-admin commented

2013-11-22 10:36:35 +01:00

#37737 was marked as duplicate of this issue

Bastien Montagne was assigned by Campbell Barton

2013-11-22 10:42:57 +01:00

Bastien Montagne commented

2013-11-22 11:01:46 +01:00

Well, with such a good description, it’s indeed easy to confirm that bug! :)

Bastien Montagne commented

2013-12-10 17:04:19 +01:00

Added subscribers: @vladoakmacic, @mont29

Bastien Montagne commented

2013-12-10 17:04:19 +01:00

◀ Merged tasks: #37737.

Bastien Montagne commented

2013-12-14 11:45:34 +01:00

Grmlll… Now I can’t reproduce this bug in latest master, as if it had been fixed already somehow… Could you please check again with a recent build from http://builder.blender.org/download/ ?

Vlado Akmacic commented

2013-12-15 16:17:53 +01:00

With recent build (blender-2.69-4a14102-win64) the bug is still there for me.

Bastien Montagne commented

2013-12-15 16:41:01 +01:00

@vladoakmacic I tested your file, you have two different names for your UV maps (UVMap and UVTex), so you obviously get two different maps in your joined object! There is absolutely no bug here (as a side note, please avoid ziping mere blend files, it makes us lose some time, just use the Compress option when saving the blend file).

Vlado Akmacic commented

2013-12-15 18:40:42 +01:00

@mont29 OK, now I see that I have two different names for your UV maps (that is because I added one object with Append), but why isn't it problem with Blender 2.68 and backwards? Does that mean that it is bug if it joins them even though there are two different names for UV maps? ;)
bug.blend

@mont29 OK, now I see that I have two different names for your UV maps (that is because I added one object with Append), but why isn't it problem with Blender 2.68 and backwards? Does that mean that it is bug if it joins them even though there are two different names for UV maps? ;) [bug.blend](https://archive.blender.org/developer/F41352/bug.blend)

Bastien Montagne commented

2013-12-15 20:07:53 +01:00

@vladoakmacic Maybe you should read release notes? http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.69/Modeling#Mesh_Merging CD layers are now merged by name instead of index/position.

Vlado Akmacic commented

2013-12-15 21:39:40 +01:00

OK, now I understand. We can call this case closed :)

Jonatan Bijl commented

2013-12-17 11:21:43 +01:00

Seems to work for me with build blender-2.69-d963412-win32

Bastien Montagne commented

2013-12-17 11:40:51 +01:00

Changed status from 'Open' to: 'Archived'

Bastien Montagne closed this issue

2013-12-17 11:40:51 +01:00

Bastien Montagne commented

2013-12-17 11:40:51 +01:00

Nice, closing then! :)

Bastien Montagne commented

2014-01-29 19:43:53 +01:00

Added subscribers: @tea_monster, @dfelinto, @MaleneThyssen

Bastien Montagne commented

2014-01-29 19:43:53 +01:00

◀ Merged tasks: #37182.

Bastien Montagne commented

2014-01-29 19:47:20 +01:00

@jonim8or I tried again to reproduce this (as described above, same as your post in #37182), and I still can't reproduce this!

Don’t know what happens… :/

@jonim8or I tried again to reproduce this (as described above, same as your post in #37182), and I still can't reproduce this! Don’t know what happens… :/

Malene Thyssen commented

2014-01-29 21:19:26 +01:00

Ah! thanks Mont!

And - i fixed my issue by renaming all uvmaps again this time making them all the same name, instead of carefully giving them different names hah!

All was good then.

Still is a bit weird that one uvmap just gets crumbled into a dot if the uvmaps has different names i think?
Anyway i am happy - my issue is fixed for now :D

Ah! thanks Mont! And - i fixed my issue by renaming all uvmaps again this time making them all the same name, instead of carefully giving them different names hah! All was good then. Still is a bit weird that one uvmap just gets crumbled into a dot if the uvmaps has different names i think? Anyway i am happy - my issue is fixed for now :D

Bastien Montagne commented

2014-01-29 22:34:09 +01:00

@MaleneThyssen: Nah, if you merge cubeB with UVmapB in cubeA with UVmapA, since vertices from B do not have any UV coordinates for UVmapA, they just get default ones (0, 0)… so they all get crumbled! :)

Jonatan Bijl commented

2014-01-31 13:30:12 +01:00

@mont29 : I did some tests to reproduce it. I can still reproduce, but apparently it matters which unwrap method you use.

For me the bug happens when using project from view for the first cube, and project from view(bounds) for the second. But when using lightmap pack and project from view the bug does not occur. This is in 2.69, official release.

I've checked the names of the UV layers, but these are the same. (unwrapping the first cube creates a uv layer. unwrapping the second cube modifies the uv layer)

so here is the new steps to reproduce

create a cube (or any other mesh primitive)
go to edit mode and unwrap the cube using Project from View
go back to object mode and duplicate the cube (using shift-d)
go to edit mode, and unwrap the second cube using Project from View (Bounds)
go back to object mode, Shift-select the first cube, and press Ctrl+J
in edit mode, the uvs of one of the two cubes appear as expected, the uvs of the other have gone to the lower-left corner of the uv layer. There is still only one UV layer, called "UVMap" (as it was in each of the two cubes before joining)

@mont29 : I did some tests to reproduce it. I can still reproduce, but apparently it matters which unwrap method you use. For me the bug happens when using *project from view* for the first cube, and *project from view(bounds)* for the second. But when using *lightmap pack* and *project from view* the bug does not occur. This is in 2.69, official release. I've checked the names of the UV layers, but these are the same. (unwrapping the first cube creates a uv layer. unwrapping the second cube modifies the uv layer) so here is the new **steps to reproduce** - create a cube (or any other mesh primitive) - go to edit mode and unwrap the cube using *Project from View* - go back to object mode and duplicate the cube (using shift-d) - go to edit mode, and unwrap the second cube using *Project from View (Bounds)* - go back to object mode, Shift-select the first cube, and press Ctrl+J - in edit mode, the uvs of one of the two cubes appear as expected, the uvs of the other have gone to the lower-left corner of the uv layer. There is still only one UV layer, called "UVMap" (as it was in each of the two cubes before joining)

Bastien Montagne commented

2014-01-31 16:23:31 +01:00

Changed status from 'Archived' to: 'Open'

Bastien Montagne reopened this issue

2014-01-31 16:23:31 +01:00

Bastien Montagne commented

2014-01-31 16:23:31 +01:00

Ok… Finally manage to reproduce the issue.

The kind of unwrapping does not seem to have any importance, what's important is this: bug only happens (as far as I can see) when you create the UVmap of the first cube in Edit mode, leave back to Object mode, and do not switch again first cube in Edit mode. Else, joining works as expected.

So I suspect a sync issue in CDLayers between Object and Edit modes, somehow… Will dig this next week.

PS: Following steps above allow to recreate the bug, if you really create first cube from scratch (using the default-scene one does not work). And to make joining work as expected, you just have to tab one more time in/out Edit mode for the first cube, before doing the joining (after or before duplicating to the second cube, that does not matters).

Ok… Finally manage to reproduce the issue. The kind of unwrapping does not seem to have any importance, what's important is this: bug only happens (as far as I can see) when you **create** the UVmap of the first cube in Edit mode, leave back to Object mode, **and do not switch again first cube in Edit mode**. Else, joining works as expected. So I suspect a sync issue in CDLayers between Object and Edit modes, somehow… Will dig this next week. PS: Following steps above allow to recreate the bug, if you really create first cube from scratch (using the default-scene one does not work). And to make joining work as expected, you just have to tab one more time in/out Edit mode for the first cube, before doing the joining (after or before duplicating to the second cube, that does not matters).

blender-admin commented

2014-02-04 12:10:59 +01:00

This issue was referenced by blender/blender-addons-contrib@605910f060

This issue was referenced by blender/blender-addons-contrib@605910f060c774c7d2396c1659b560a26ad2cdcf

blender-admin commented

2014-02-04 12:10:59 +01:00

This issue was referenced by 605910f060

This issue was referenced by 605910f060c774c7d2396c1659b560a26ad2cdcf

Bastien Montagne commented

2014-02-04 12:17:21 +01:00

Changed status from 'Open' to: 'Resolved'

Bastien Montagne closed this issue