'Project from View' UV mapping produces distorted maps #33055

New Issue

Andrew Price · 2012-11-03T06:37:34+01:00

Andrew Price commented

2012-11-03 06:37:34 +01:00

%%%This bug occurs when using the 'Project from View' UV unwrapping technique. If the texture in the UV Image Editor is not 1:1 aspect ratio, it distorts the map to match the aspect ratio of the image, which is wrong.

This picture demonstrates what I mean: http://i.imgur.com/1xmKG.png

This is a big problem for artists (especially when hard surface texturing) because the texture should match the original texture as closely as possible. Having the wrong aspect ratio is a huge hindrance to that.

To replicate the problem:

Download this texture: http://i.imgur.com/VLab5.jpg
Open blender and replace the default cube with a plane.
Split the viewport and assign the other window to the UV/Image Editor.
Add the texture to the UV/Image Editor.
Go into top view so you are looking down on the plane.
Select the plane, go into edit mode and press U > Project from View.

You should see this happen: http://i.imgur.com/1xmKG.png

I first noticed this bug about 6 months ago. At first I thought it may be a feature, but now I think it's a bug that was accidentally introduced.

Thanks devs! Love your work!%%%

%%%This bug occurs when using the 'Project from View' UV unwrapping technique. If the texture in the UV Image Editor is not 1:1 aspect ratio, it distorts the map to match the aspect ratio of the image, which is wrong. This picture demonstrates what I mean: http://i.imgur.com/1xmKG.png This is a big problem for artists (especially when hard surface texturing) because the texture should match the original texture as closely as possible. Having the wrong aspect ratio is a huge hindrance to that. To replicate the problem: 1. Download this texture: http://i.imgur.com/VLab5.jpg 2. Open blender and replace the default cube with a plane. 3. Split the viewport and assign the other window to the UV/Image Editor. 4. Add the texture to the UV/Image Editor. 5. Go into top view so you are looking down on the plane. 6. Select the plane, go into edit mode and press U > Project from View. You should see this happen: http://i.imgur.com/1xmKG.png I first noticed this bug about 6 months ago. At first I thought it may be a feature, but now I think it's a bug that was accidentally introduced. Thanks devs! Love your work!%%%

Andrew Price commented

2012-11-03 06:37:34 +01:00

Changed status to: 'Open'

blender-admin commented

2012-11-03 06:37:34 +01:00

#46211 was marked as duplicate of this issue

blender-admin commented

2012-11-03 06:37:34 +01:00

#46014 was marked as duplicate of this issue

Anthony Edlin commented

2012-11-03 09:31:56 +01:00

%%%Ok this is kind of strange. At first by following your instructions I could reproduce the problem you describe. Aspect ratio of uvs stretched from what was on 3d view.

Then I switched the 3d view to orthographic view and did the same thing (unwrap -> project from view) and noticed that the aspect ratio was correct, so I thought the problem must have been with perspective view. But now that I switched back to perspective view it also has the correct aspect ratio, and I can't seem to get it to reproduce the initial problem anymore, even after restarting/recompiling blender. I know toolsettings is saved in the scene when unwrap_exec is called so I thought there might be something wrong in that area, but from looking at the code I can't see what. Now that I can't repeat the problem I can't really debug it properly.

When you go through these steps, if you could pull down the top menu where the operators are shown and look for correct_aspect when you do the unwrap and see if it says True or False?%%%

%%%Ok this is kind of strange. At first by following your instructions I could reproduce the problem you describe. Aspect ratio of uvs stretched from what was on 3d view. Then I switched the 3d view to orthographic view and did the same thing (unwrap -> project from view) and noticed that the aspect ratio was correct, so I thought the problem must have been with perspective view. But now that I switched back to perspective view it also has the correct aspect ratio, and I can't seem to get it to reproduce the initial problem anymore, even after restarting/recompiling blender. I know toolsettings is saved in the scene when unwrap_exec is called so I thought there might be something wrong in that area, but from looking at the code I can't see what. Now that I can't repeat the problem I can't really debug it properly. When you go through these steps, if you could pull down the top menu where the operators are shown and look for correct_aspect when you do the unwrap and see if it says True or False?%%%

Cezary Kopias commented

2012-11-03 09:47:02 +01:00

%%%Quick check and the bug (correct aspect not working) occurs only when Cycles is selected as Renderer. Win7_x64 r51814
Hope it helped cheers%%%

%%%Quick check and the bug (correct aspect not working) occurs only when Cycles is selected as Renderer. Win7_x64 r51814 Hope it helped cheers%%%

Anthony Edlin commented

2012-11-03 10:02:57 +01:00

%%%I can confirm this now also, you are correct it's when cycles is the renderer, good find.%%%

Cezary Kopias commented

2012-11-03 10:03:06 +01:00

%%%Further investigation... it will work in Cycles...
... but only if you open the texture (only Edit Mode) in the VU/Image editor when Internal is selected as renderer and then switch to Cycles.%%%

%%%Further investigation... it will work in Cycles... ... but only if you open the texture (only Edit Mode) in the VU/Image editor when Internal is selected as renderer and then switch to Cycles.%%%

Andrew Price commented

2012-11-03 11:31:14 +01:00

%%%Oh really? I've encountered this problem frequently for the last 6 months, and each time the scene has been opened in Cycles renderer every time. Never internal.
I'm using Windows 7 64+

Cheers%%%

%%%Oh really? I've encountered this problem frequently for the last 6 months, and each time the scene has been opened in Cycles renderer every time. Never internal. I'm using Windows 7 64+ Cheers%%%

Ton Roosendaal commented

2012-11-03 17:39:41 +01:00

%%%Well - isn't that strange! Let's see if I can find out why cycles setting changes how viewport unwrap goes...%%%

Ton Roosendaal commented

2012-11-03 18:12:07 +01:00

%%%I totally fail to redo :( also not in 2.64a release.

Can anyone make a .blend with the error? Just use a generated image (UV grid)%%%

%%%I totally fail to redo :( also not in 2.64a release. Can anyone make a .blend with the error? Just use a generated image (UV grid)%%%

Anthony Edlin commented

2012-11-03 18:44:36 +01:00

%%%I've attached a .blend file.

I can reliably reproduce this if I switch to internal renderer, unlink the texture, then unwrap with project from view, then go back to cycles render, create a new texture not of the same aspect ratio, then unwrap with project from view again and the uv's will be off. You can also add a texture when in internal render of any size and unwrap, then goto cycles render and add a different texture of a different aspect ratio and unwrap again to get uv's that are off. It seems like unwrapping is using the texture that was assigned when you had the internal renderer selected instead of the one that you choose when cycles is selected to correct the uv aspect.%%%

%%%I've attached a .blend file. I can reliably reproduce this if I switch to internal renderer, unlink the texture, then unwrap with project from view, then go back to cycles render, create a new texture not of the same aspect ratio, then unwrap with project from view again and the uv's will be off. You can also add a texture when in internal render of any size and unwrap, then goto cycles render and add a different texture of a different aspect ratio and unwrap again to get uv's that are off. It seems like unwrapping is using the texture that was assigned when you had the internal renderer selected instead of the one that you choose when cycles is selected to correct the uv aspect.%%%

Cezary Kopias commented

2012-11-04 03:47:27 +01:00

%%%Steps to reproduce:

BLENDER INTERNAL
1)Load Factory Settings split view and make it UV image editor
2)In UV image editor : clock new texture: 512x1024 hit OK
3)go into editmode for the default cube and unwrap using project form view
4)hit F6 in 3d view still in editmode and check if 'Correct Aspect' is selected
5) optionally toggle this feature to see the difference
5)it works correctly

CYCLES
Do everything the same except after loading factory defaults change to Cycles and proceed..
and see that 'Correct Aspect' don`t work.%%%

%%%Steps to reproduce: BLENDER INTERNAL 1)Load Factory Settings split view and make it UV image editor 2)In UV image editor : clock new texture: 512x1024 hit OK 3)go into editmode for the default cube and unwrap using project form view 4)hit F6 in 3d view still in editmode and check if 'Correct Aspect' is selected 5) optionally toggle this feature to see the difference 5)it works correctly CYCLES Do everything the same except after loading factory defaults change to Cycles and proceed.. and see that 'Correct Aspect' don`t work.%%%

Andrew Price commented

2012-11-04 06:31:54 +01:00

%%%Thanks Czarek! I'm glad someone else was able to reproduce it. I was beginning to think I was the only one! :)%%%

Anthony Edlin commented

2012-11-04 08:15:06 +01:00

%%%So looking through the code I see the problem is the inability of the correct_uv_aspect function to get a texture for a cycles render or to fallback to an image from the space_image if it can't find a cycles texture. If you look in the image_refresh function of space_image.c you can see that the code has two different paths for getting a texture based on the BKE_scene_use_new_shading_nodes function. Also, cycles only gets textures through the material nodes.

I can see two problems to fix here:

Make sure that correct_uv_aspect uses BKE_scene_use_new_shading_nodes to have different code paths for getting the texture to work with.
Even if you fix 1, you will still not be able to unwrap with proper aspect until you've added a material to your object and added a texture to your material node.

1 is pretty easy and straightforward, I wrote a small patch that does this and it works.

2 though is a bigger issue and comes with more questions, at least for me. Should it even be allowed to unwrap a cycles object if there is no material node texture? When you do should it always display a blank image so you know it's not using your texture in the UV/Image editor? Or should it fallback to the texture you've selected in your UV/Image editor if it can't find a texture node? Those are just some questions, and I'm not an expert in this area so others should probably work on it.

That being said, just for fun I did write a patch that falls back to the UV/Image editor texture if it can't find a texture node. It does seem to half work, I can unwrap with correct aspect on a texture with cycles render and no material nodes added. But right now it broke unwrapping on a blank texture and it touches a bunch of code that I don't know all that well.

If anyone wants me to post the patches to look at just say so, otherwise I may poke at them as time permits.%%%

%%%So looking through the code I see the problem is the inability of the correct_uv_aspect function to get a texture for a cycles render or to fallback to an image from the space_image if it can't find a cycles texture. If you look in the image_refresh function of space_image.c you can see that the code has two different paths for getting a texture based on the BKE_scene_use_new_shading_nodes function. Also, cycles only gets textures through the material nodes. I can see two problems to fix here: 1) Make sure that correct_uv_aspect uses BKE_scene_use_new_shading_nodes to have different code paths for getting the texture to work with. 2) Even if you fix 1, you will still not be able to unwrap with proper aspect until you've added a material to your object and added a texture to your material node. 1 is pretty easy and straightforward, I wrote a small patch that does this and it works. 2 though is a bigger issue and comes with more questions, at least for me. Should it even be allowed to unwrap a cycles object if there is no material node texture? When you do should it always display a blank image so you know it's not using your texture in the UV/Image editor? Or should it fallback to the texture you've selected in your UV/Image editor if it can't find a texture node? Those are just some questions, and I'm not an expert in this area so others should probably work on it. That being said, just for fun I did write a patch that falls back to the UV/Image editor texture if it can't find a texture node. It does seem to half work, I can unwrap with correct aspect on a texture with cycles render and no material nodes added. But right now it broke unwrapping on a blank texture and it touches a bunch of code that I don't know all that well. If anyone wants me to post the patches to look at just say so, otherwise I may poke at them as time permits.%%%

Ton Roosendaal commented

2012-11-04 13:21:50 +01:00

%%%Hi Anthony & Czarek,

Thanks for all the help! I think it's time to involve Brecht in this though. He's been tinkering with this code.
Posting a patch is of course always welcome :)%%%

%%%Hi Anthony & Czarek, Thanks for all the help! I think it's time to involve Brecht in this though. He's been tinkering with this code. Posting a patch is of course always welcome :)%%%

Andrew Price commented

2012-11-05 02:31:35 +01:00

%%%@Anthony
Regarding Point 2: I definitely think you should be allowed to unwrap an object, without a texture first applied.

The reason for this is that sometimes while modelling you want to unwrap everything first, before applying a texture. I frequently use 1:1, tileable textures, so I don't necessarily need to see the UV map over the image to know how it will look.

I also really dislike the idea of it 'auto choosing' whatever is in the UV Image editor, as this frequently overrides the texture that was previously set... but I'll save that for another bug report :P%%%

%%%@Anthony Regarding Point 2: I definitely think you should be allowed to unwrap an object, without a texture first applied. The reason for this is that sometimes while modelling you want to unwrap everything first, before applying a texture. I frequently use 1:1, tileable textures, so I don't necessarily need to see the UV map over the image to know how it will look. I also really dislike the idea of it 'auto choosing' whatever is in the UV Image editor, as this frequently overrides the texture that was previously set... but I'll save that for another bug report :P%%%

Anthony Edlin commented

2012-11-05 04:50:52 +01:00

%%%Well Brecht commit a fix for the first part. As long as your object has a material with a texture it will use that texture to correct the aspect. I tested it with my test file and it works great. If you don't have a texture node somewhere in your material and have a non 1:1 texture selected in the image viewer the uv's will still look stretched, because it will use the blank 1:1 image by default to calculate the uvs.%%%

Brecht Van Lommel commented

2012-11-05 15:02:10 +01:00

%%%I did indeed fix the behavior when there is an image texture assigned in the cycles material. It's still somewhat confusing if you have not done this yet, and assigning the image in the image editor does not automatically create an image texture node.

Not sure yet about the best solution, it could automatically create an image texture node, or we could hide the image chooser when uv editing without an image texture node.%%%

%%%I did indeed fix the behavior when there is an image texture assigned in the cycles material. It's still somewhat confusing if you have not done this yet, and assigning the image in the image editor does not automatically create an image texture node. Not sure yet about the best solution, it could automatically create an image texture node, or we could hide the image chooser when uv editing without an image texture node.%%%

Andrew Price commented

2012-11-06 03:29:06 +01:00

%%%Oh, so the action where it automatically overrides an assigned image with what's in the UV Image editor has been fixed? That's really cool if so. I remember nearly pulling my hair out making a scene a few months back. Blender kept overriding all my textures with whatever was in the UV editor :P Glad it's fixed.

As for a solution, does it really need to do something automatically when an image is in the editor? Perhaps a command would be better. Like an option in the menus of the editor to "Port Texture to Material". That would please both parties in my opinion. Those that want it can port on command without it annoying others who want to experiment with images without changing their materials.
Just an idea.%%%

%%%Oh, so the action where it automatically overrides an assigned image with what's in the UV Image editor has been fixed? That's really cool if so. I remember nearly pulling my hair out making a scene a few months back. Blender kept overriding all my textures with whatever was in the UV editor :P Glad it's fixed. As for a solution, does it really need to do something automatically when an image is in the editor? Perhaps a command would be better. Like an option in the menus of the editor to "Port Texture to Material". That would please both parties in my opinion. Those that want it can port on command without it annoying others who want to experiment with images without changing their materials. Just an idea.%%%

Anthony Edlin commented

2012-11-06 16:27:09 +01:00

%%%@Andrew-57
I think everything you just described is a whole other issue not directly related to this unwrapping aspect problem.

It's now fixed so at least unwrapping with cycles will give you good results if you have a texture in the material, or if you don't have a texture it will unwrap with default of 1:1. I think my point 2 above is really a more general problem exposed here.

Your idea of "Port Texture to Material" could work. Also another idea would be to have a checkbox that was something like "follow active object". This could then make the image editor always use the texture from the active object, which would get the texture from the material or would force the image blank if there wasn't a texture node. Then if the active object was changed the UV/Image editor would change, or if texture was changed from UV/Image editor it could change the texture on the object. Both of these could possibly work in simple cases, but then you have to consider multiple textures on a single object that need to use different UV's and now you're down a rabbit hole because which texture do you follow/link with. Also what about the different image editor modes like paint and mask, and other image editor options like pin. We also have 2 different systems for textures, cycles and internal. All of a sudden your simple solution becomes a 100 headed snake. This could also be viewed as a more general problem of "how much should editors follow other editor types, or what convention should be used to do this", since other spaces have this problem also, like selecting the uv map from the properties editor.

In reality I think this bug could probably be closed and mark a todo item in the wiki for dealing with image editor behaviour. In fact, since it's a wiki, I added a todo item to the image editor about this at: http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Editors

Thanks.%%%

%%%@Andrew-57 I think everything you just described is a whole other issue not directly related to this unwrapping aspect problem. It's now fixed so at least unwrapping with cycles will give you good results if you have a texture in the material, or if you don't have a texture it will unwrap with default of 1:1. I think my point 2 above is really a more general problem exposed here. Your idea of "Port Texture to Material" could work. Also another idea would be to have a checkbox that was something like "follow active object". This could then make the image editor always use the texture from the active object, which would get the texture from the material or would force the image blank if there wasn't a texture node. Then if the active object was changed the UV/Image editor would change, or if texture was changed from UV/Image editor it could change the texture on the object. Both of these could possibly work in simple cases, but then you have to consider multiple textures on a single object that need to use different UV's and now you're down a rabbit hole because which texture do you follow/link with. Also what about the different image editor modes like paint and mask, and other image editor options like pin. We also have 2 different systems for textures, cycles and internal. All of a sudden your simple solution becomes a 100 headed snake. This could also be viewed as a more general problem of "how much should editors follow other editor types, or what convention should be used to do this", since other spaces have this problem also, like selecting the uv map from the properties editor. In reality I think this bug could probably be closed and mark a todo item in the wiki for dealing with image editor behaviour. In fact, since it's a wiki, I added a todo item to the image editor about this at: http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Editors Thanks.%%%

Brecht Van Lommel commented

2012-11-08 17:02:24 +01:00

%%%Fair enough, this is not so easy to solve and not really a bug anymore, will mark this as todo.%%%