Page MenuHome

Inset Polygon addon problems
Closed, ResolvedPublic

Description

Windows 7 Professional 54-bit w SP1
GeForce GTX 760 - driver 361.43

Blender 2.76 (sub 8), branch: master, commit date: 2016-01-22 02:31, hash: 017c45b,
type: Release build date: Fri 01/22/2016, 05:01 AM

note: problems can be reproduced on any version of Blender back as far as 2.75a

Short description of error

Inset Polygon function is not working correctly in the following ways:

A) When generating inset polygons, the edges from the original faces are not deleted. The operator is forced to select each one by hand for deletion. This problem occurs in all but the simplest of meshes. The problem occurs with either of the attached blend files ( poly_inset_problem1.blend, poly_inset_problem2.blend ).

B) When generating inset polygons on selected faces from a more complex mesh ( blend, poly_inset_problem2.blend ) the add-on generates nested groupings of inset polygons rather than one, discrete group of inset polygons when the distance of the inset polygons is increased. This behaviour can not be controled by the operator.

C) As a last observation, when the inset polygon function has finished the operator is left with an empty selection. It would seem more correct for the newly-created group of inset polygons to be selected by default.

Event Timeline

Ignatz (ignatz) added a project: Add-ons.
Ignatz (ignatz) set Type to Bug.
Ignatz (ignatz) added a subscriber: Ignatz (ignatz).
Ignatz (ignatz) created this task.
Ignatz (ignatz) raised the priority of this task from to Needs Triage by Developer.

@Ignatz (ignatz) you can use also the build-in Inset function with the hotkey I as an alternative.

Only the remaining edges can be considered as a bug, the rest is Design not a Bug. @Howard Trickey (howardt), can you review it?
However

seems to produce an error with the inset amount of 77.279999 (the inset face produced with this value will remain if you increase it further) or without Region enabled with the value 0.2

A) Yes, it is a bug that the original edges are not deleted. That seems like new behavior -- I'll look at it.

B) This is by design, because what is happening when the distance gets bigger is that certain edges from the outer vertices meet and merge, so that n-gons (n > 4) would be all over the place. I decided to make the nested polygons rather than have many ngons, but I can see that the user might like a choice.

C) acknowledged.

I have for the last few months been working on making the best feature of this inset (the auto-merging of advancing edges, and also an auto-splitting that happens when a reflex vertex's advancing edge hits an opposite edge) and put it into the built-in C inset (the totally separate inset that the hotkey i invokes). This has been hard work and is far from finished, but because I am doing this, I uninterested in enhancing the 'inset polygon' functionality because that operation will be removed when I'm done. Nevertheless, I'll look at bug A. Thanks for reporting.

Howard,

Yes, I understand about the nested groups being an intential part of the functionality of the utility. It is just that the steps of the nesting seem so arbitrary. Some control of the number of steps and/or distance between same for the user might be really nice.

I went and tested the current native inset polygon function ('I' hot key). It did not leave any loose edges, but it did not perform as well as your current add-on in terms of finding the correct inset path form. (see attached image).

Bastien Montagne (mont29) triaged this task as Confirmed, Medium priority.Jan 29 2016, 4:33 PM

I fixed problem (A) with commit 9fe70215a0a9ec58e338571c029a80a44b075d73.
I also changed the post-operator selection, but not to what you really want, sorry. It now selects all polys newly created, whereas I think you want only the inner ones. I could fix that, but it would take more work and, as I said, I am porting this functionality to C, where I am doing the selection properly.

As to your reply about (B): the nesting is not arbitrary: it happens precisely at the points where intersections happen. Since those happen at unpredictable inset distances, I can't make it respect some specified number of steps and/or distance between nested groups and still have contours at the distances where intersections happen.