[UV] [Multi-Edit] Display>Stretch>Area doesn't work #63755

New Issue

Jakub Daruk · 2019-04-20T10:17:24+02:00

Jakub Daruk commented

2019-04-20 10:17:24 +02:00

System Information
Operating system: Windows-10-10.0.17763 64 Bits
Graphics card: GeForce GTX 970/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 425.31

Blender Version
Broken: version: 2.80 (sub 57), branch: blender2.7, commit date: 2019-04-17 19:26, hash: b46245470f
Worked: (optional)

Short description of error
There is a bug with Area stretch type in UV window. It doesn't show correct values (colors). Also it doesn't respect size of one object UV Islands according to another objects sizes.

[When you merge all object into one it all works! It doesn't work with multi edit.]

Exact steps for others to reproduce the error
1.Create cube
2.Duplicate this cube, put it aside
3.Open first cube UV window
4.Move UV a bit that it doesn't overlap with other cube UV
5.Now select 2 cubes and open UV window, Go to Display>Stretch(tik)>Area
6. Cubes UVs should be blue, now try resize one of them

They remain blue and they should changing colors based on size of the object and overall unwrap.
This bug is since forever in 2.80 and probably there's more realated to it.

Cheers!

**System Information** Operating system: Windows-10-10.0.17763 64 Bits Graphics card: GeForce GTX 970/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 425.31 **Blender Version** Broken: version: 2.80 (sub 57), branch: blender2.7, commit date: 2019-04-17 19:26, hash: `b46245470f` Worked: (optional) **Short description of error** There is a bug with Area stretch type in UV window. It doesn't show correct values (colors). Also it doesn't respect size of one object UV Islands according to another objects sizes. [When you merge all object into one it all works! It doesn't work with multi edit.] **Exact steps for others to reproduce the error** 1.Create cube 2.Duplicate this cube, put it aside 3.Open first cube UV window 4.Move UV a bit that it doesn't overlap with other cube UV 5.Now select 2 cubes and open UV window, Go to Display>Stretch(tik)>Area 6. Cubes UVs should be blue, now try resize one of them They remain blue and they should changing colors based on size of the object and overall unwrap. This bug is since forever in 2.80 and probably there's more realated to it. Cheers! ![Area type BUG.jpg](https://archive.blender.org/developer/F6961329/Area_type_BUG.jpg)

Jakub Daruk commented

2019-04-20 10:17:24 +02:00

Added subscriber: @KibaX

blender-admin commented

2019-04-20 10:17:24 +02:00

#66523 was marked as duplicate of this issue

George Vogiatzis commented

2019-04-20 10:44:26 +02:00

Added subscriber: @Gvgeo-1

George Vogiatzis commented

2019-04-20 10:44:26 +02:00

Changed status from 'Open' to: 'Archived'

George Vogiatzis closed this issue

2019-04-20 10:44:26 +02:00

George Vogiatzis self-assigned this 2019-04-20 10:44:26 +02:00

George Vogiatzis commented

2019-04-20 10:44:26 +02:00

This is how it should be work. You just resize a separate cube. There is no stretch.
If you join the cubes will see that it working fine.

This is how it should be work. You just resize a separate cube. There is no stretch. If you join the cubes will see that it working fine. ![000079.png](https://archive.blender.org/developer/F6961337/000079.png)

George Vogiatzis commented

2019-04-20 10:50:56 +02:00

I just saw the description update.
In 2.79 there was no multi-edit. These objects are 1 joined object and are indeed stretched, as would be in 2.80 if you join them too.
In multi-edit mode are separate objects and as such, there is no stretch.

I just saw the description update. In 2.79 there was no multi-edit. These objects are 1 joined object and are indeed stretched, as would be in 2.80 if you join them too. In multi-edit mode are separate objects and as such, there is no stretch.

Jakub Daruk commented

2019-04-20 11:51:26 +02:00

So I need to join all dozens objects on my scene to adjust texel density and then separate them again because I need it to bake high into low poly ? ... It doesn't sound any good for guy who work with games- like myself. It looks like the way before I even discover Multi-edit addon for 2.79. Also preparing assets atlases in 2.80 is kinda senseless work right now.

George Vogiatzis commented

2019-04-20 12:56:13 +02:00

You are right, this doesn't make sense.
I'm changing the bug status back.
This was a functionality with Multi-edit addon shipped in 2.79.

You are right, this doesn't make sense. I'm changing the bug status back. This was a functionality with Multi-edit addon shipped in 2.79.

George Vogiatzis commented

2019-04-20 12:58:32 +02:00

Changed status from 'Archived' to: 'Open'

George Vogiatzis reopened this issue

2019-04-20 12:58:32 +02:00

George Vogiatzis removed their assignment 2019-04-20 12:58:32 +02:00

Sebastian Parborg commented

2019-04-25 12:12:37 +02:00

Added subscribers: @brecht, @ZedDB

Brecht Van Lommel was assigned by Sebastian Parborg

2019-04-25 12:12:37 +02:00

Sebastian Parborg commented

2019-04-25 12:12:37 +02:00

@brecht I guess that the UV code has to be updated to take all objects in to account when using multi edit. Now at least, the display seems to be isolated to the geometry of each individual object.

Brecht Van Lommel removed their assignment 2019-04-25 12:17:26 +02:00

Jeroen Bakker was assigned by Brecht Van Lommel

2019-04-25 12:17:26 +02:00

Brecht Van Lommel commented

2019-04-25 12:17:26 +02:00

Right. I'm going to pass this one to someone else, a bit random since this falls between a few areas of the code.

George Vogiatzis commented

2019-04-25 13:03:28 +02:00

@brecht @Jeroen-Bakker

Already looked at this. It feels a bit out of reach for me.

The only way I could thought of is,
to move faces_areas calculations
from uvedit_fill_buffer_data()
to ED_uvedit_draw_main().
But will have to pass a some variables(struct?) through draw functions.

                                    BMFace *efa,
                                    BMesh *bm,
                                    float (*faces_areas)[2],
                                    float totarea,
                                    float totuvarea,
                                    float Fulltotarea,
                                    float Fulltotuvarea

I expect that you can handle it way better than this.
But if, by any chance sounds good enough, I could give it a try.

@brecht @Jeroen-Bakker Already looked at this. It feels a bit out of reach for me. The only way I could thought of is, to move faces_areas calculations from `uvedit_fill_buffer_data`() to `ED_uvedit_draw_main`(). But will have to pass a some variables(struct?) through draw functions. ``` BMFace *efa, BMesh *bm, float (*faces_areas)[2], float totarea, float totuvarea, float Fulltotarea, float Fulltotuvarea ``` I expect that you can handle it way better than this. But if, by any chance sounds good enough, I could give it a try.

Philipp Oeser commented

2019-07-08 11:00:47 +02:00

Added subscriber: @JVM

Jeroen Bakker commented

2019-07-10 15:55:02 +02:00

I would keep the mesh data (face area and uvarea) as much as possible in the VBO's as these will be reused. My approach would be to move the dynamic part of the data into the shader (totarea, totareauv).
this will be the total sum of all areas and the total sum of all uv area's from the objects that are being edited. The per mesh totals can be stored in the MeshBatchCache.

As I currently see it the calculation needs to take place in world space so we need to take the world_matrix into account. Currently the whole calculation is done in object local space.
I would propose to move the stretch calculation to the vertex shader. (move edit_uv_get_stretch_area to gpu_shader_2D_edituvs_stretch_vert.glsl).

I would keep the mesh data (face area and uvarea) as much as possible in the VBO's as these will be reused. My approach would be to move the dynamic part of the data into the shader (totarea, totareauv). this will be the total sum of all areas and the total sum of all uv area's from the objects that are being edited. The per mesh totals can be stored in the MeshBatchCache. As I currently see it the calculation needs to take place in world space so we need to take the world_matrix into account. Currently the whole calculation is done in object local space. I would propose to move the stretch calculation to the vertex shader. (move `edit_uv_get_stretch_area` to `gpu_shader_2D_edituvs_stretch_vert.glsl`).

Jeroen Bakker commented

2019-09-03 11:12:24 +02:00

Discussed last week and we will do the calculation in local/mesh space.

blender-admin commented

2019-09-03 13:42:11 +02:00

This issue was referenced by 64f8f7db7c

This issue was referenced by 64f8f7db7cce0c8923afcabb523f7400f744387e

Jeroen Bakker commented

2019-09-04 08:13:06 +02:00

Changed status from 'Open' to: 'Resolved'

Jeroen Bakker closed this issue

2019-09-04 08:13:06 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

[UV] [Multi-Edit] Display>Stretch>Area doesn't work #63755