Denis, are you pulling my leg?
YOU USE unwrap interface functions and DON’T CHECK if the current modpanel object is Unwrap_UVW modifier.
I had that test in earlier versions (though in the form of testing the class of modPanel.getCurrentObject()) and the error was already there.
I removed that test later for the reasons stated in my second post.
But I’ll have one of the guy with the error try it again with the correction you suggest.
The thing is, if not having that test is a mistake, why is the compile error showing for only 2 guys out of 15 or 18?
I’ll post the result of the test as soon as I have it (doesn’t depend only on me).
this error has to be shown for every user. including yourself. the puzzle is why it doesn’t show
I’ll have the test done later tonight so won’t post the result before tomorrow.
In the meantime to answer your question, let me put it this way. How can you possibly execute the macro from the mapping menu of the edit dialog without an object with an unwrap?
Or better, can you even open that dialog without first having an object selected, with an unwrap modifier in its stack and being at the unwrap level?
Please intall the script and try it yourself.
I don’t want to install any not working scripts…
it’s all that you need to install the FIXED macro:
(
local macro = "$userMacros\\UVW Unwrap-straightenUVstrip.mcr"
if doesfileexist macro do
(
fileIn macro
if (theMenu = menuMan.findMenu "UVW Unwrap - UVW Mapping") != undefined do
(
local num = theMenu.numItems()
local noItem = true
local theTitle = "Straighten UV Strip..."
for i = 1 to num while noItem do noItem = ((theMenu.getItem i).getTitle() != theTitle)
if noItem do
(
if not (theMenu.getItem num).getIsSeparator() do
(
local theSep = menuMan.createSeparatorItem()
theMenu.addItem theSep -1
)
local theItem = menuMan.createActionItem "straightenUVstrip" "UVW Unwrap"
theItem.setTitle theTitle
theItem.setUseCustomTitle true
theMenu.addItem theItem -1
menuMan.updateMenuBar()
)
)
)
)
it’s safe to put this code into scripts startup (it’s how I do it).
Thanks for that, Denis.
I’ve sent a new .mzp with your corrections both in install.ms and in the macro to one of the guys with the error.
I first tried it myself of course and that went well, which is a good omen (but then I didn’t have the error in the first place).
I’m waiting for his answer (fingers crossed).
BINGO!
The compile error is gone!
And also the other problem with the double drop (?!).
Thanks a ton Denis. Especially for insisting and keeping up with me despite a good deal of thickness on my part.
Much much appreciated
i am glad to be helping you. but i suggest you to go on trimesh level. the number of faces might be different but the number of map verts is the same. you always can convert map verts to map faces. also i suggest to support unwrap applied to multiple nodes.
The macro works only on the trimesh, through meshOp methods: theObj = selection[1].mesh
The whole topology check is based on that.
It also makes an extensive use of verts-to-faces and faces-to-verts conversions:
local f2v = meshOp.getMapVertsUsingMapFace
local v2f = meshOp.getMapFacesUsingMapVert
Is this what you mean?
Support for multiple nodes would be great. It’s vaguely on the to-do list.
Right now, I’m looking into extending the algorithm to work on strips that are more than 1 face wide.
This proves a lot more complicated than expected: some configurations are undetermined, considering only their topology.
A simple example is a 2×2 quads configuration, with all diagonal edges pointing toward the center vertex. The topology is identical to that of an octagon with a center vertex: no way to define width and length directions.
If you have an idea, I’m buying!