• Mark comments

In T98598#1369233, @Omar Emara (OmarSquircleArt) wrote:

Actually first, does this happen with factory settings? Maybe another add-on changed that state.

In T98598#1369208, @Omar Emara (OmarSquircleArt) wrote:

So disabling GL_POLYGON_SMOOTH fixes the original issue but makes the triangles less transparent as in your second screenshot?

@Omar Emara (OmarSquircleArt) It really changes the blending mode for nonsense.

A second test, seems that the blending mode can be fixed by using:

Ok with a first test, disabling GL_POLYGON_SMOOTH.

In T98598#1369188, @Omar Emara (OmarSquircleArt) wrote:

this seems very similar to the artifacts produced by OpenGL polygon smoothing, is this something that you have enabled somewhere? See https://community.khronos.org/t/gl-polygon-smooth-is-it-that-bad/60063.

In D14759#397367, @Hans Goudey (HooglyBoogly) wrote:

The patch looks much better to me now! It would be nice if you added a screenshot of the panel to the description too.

Great, I'll do add it + check your comments. Thanks!

Updated diff with master just in case

Added keymaps as pointed out by @Pablo Vazquez (pablovazquez)

@Hans Goudey (HooglyBoogly)
Hi! Update on the patch based on your feedback:
• Re-use the Object.color property for the wire color.
• Support other wire-based objects.

In D14755#396841, @Pablo Vazquez (pablovazquez) wrote:

Yes! I've been missing this.

Looking good UI wise, only missing the keymap:

Thanks for working on it!

In D14759#396725, @Hans Goudey (HooglyBoogly) wrote:

Personally I think the redundancy (and memory use) of the two properties isn't worth the benefits you mention.
I don't really see the drawing of these empty shapes as so different from drawing other wireframes-- their handling of alpha should probably be consistent anyway.

Having the empty color outside the empty display settings would be OK?

Yes, I think so, since I'd see it as "Which color to use to draw any of this object's wireframes", so maybe the toggle would go in the object's viewport display panel too.

Anyway, that's all just my thoughts, it's worth consulting others too.

In D14759#396707, @Hans Goudey (HooglyBoogly) wrote:

Hmm, instead of adding another property, wouldn't it make sense to support colored wireframes for all object types and use the existing object color?

@Hans Goudey (HooglyBoogly) That code is from so long that I have to check this patch and see if now that threshold is correct or even relevant.
But as a short explanation, start_gradient_threshold and end_gradient_threshold area meant to shrink and grow the gradient effect, like pushing and pulling the corners (start/end) to have a more or less smooth transition.
The point of that comment - in that moment - is that the center of the wires was a bit off so that's why those values were set less centered, that is, from around 0.5 (centered) to around 0.4 (offset to left). But as said, I have to check well it now and I will provide a diff here for that specific part is case it needs some tweak.

In D10787#335392, @Pablo Vazquez (pablovazquez) wrote:

@Juanfran Matheu (jfmatheu) are you still available to update this patch to master? It'd be great to have it in for 3.0.

Forgot the note.

• Fixed UI scaling issue.

@Hans Goudey (HooglyBoogly) Thanks for pointing up that high-dpi/scale issue! Will look into it asap and mention you once it is done!

@Hans Goudey (HooglyBoogly)
Ok so far the patch came a little bit more """complex""" but it is sticked with the convention.

In D10787#288044, @Hans Goudey (HooglyBoogly) wrote:

Thanks for the patch. I just tested it and copying and pasting feels so much better!

I think it's generally better to put the hard work of an operator in the exec function. At least that's what I've seen more often throughout the source.
It makes a bit of sense, but I'm honestly not sure why exactly. Regardless, maybe best to stick with convention?

So I'd suggest adding an "offset" operator property, setting it in the invoke function, and then retrieving it in the exec function.

In D9441#277317, @Simon Thommes (simonthommes) wrote:

I was imagining it the same way it was working before, but already indicating the sample mode with a cursor change while alt is pressed. That would work more like temporarily entering the sample tool by holding down the key.

Note: couldn't add the operator properties there in the header or tool panel, it's more like a redo operator than a modal/interactive one.

Hmm, that's unfortunate. I guess this would need the operator to be implemented completely new with the tool usage in mind?

Following the feedback from @Simon Thommes (simonthommes)
• Added support to Image Editor (paint).
• Now Alt shortcut triggers directly without clicking which is convenient and quicker.

In D8286#276635, @Simon Thommes (simonthommes) wrote:

Something that I would actually expect instead of the current behavior is that the node is not directly placed but instead grabbed by the cursor just like when adding a node.
That adds an additional click but I think it would come intuitively and might be a nice way of solving the question of placement by putting it directly into the hands of the user.

Improved patch:
• Reused some bmesh code to create the vertex so now it is way smaller patch.
• Renamed 'point' to 'vertex' as suggested by @Hans Goudey (HooglyBoogly)