Page MenuHome

[UV] [Multi-Edit] Display>Stretch>Area doesn't work
Closed, ResolvedPublic


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: rBb46245470f79
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

  1. 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.


Event Timeline

George Vogiatzis (Gvgeo) claimed this task.

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.

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.

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.

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 (Gvgeo) removed George Vogiatzis (Gvgeo) as the assignee of this task.
Sebastian Parborg (zeddb) lowered the priority of this task from Needs Triage by Developer to Confirmed, Medium.

@Brecht Van Lommel (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.

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

@Brecht Van Lommel (brecht) @Jeroen Bakker (jbakker)

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.

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).

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