It sort of makes sense, I'll have to re-read that carefully. I kind of started to go down that road, but then decided it was simpler to just duplicate the mesh and delete the faces. I think the reason why the method you suggest is a bit complicated for my use, is it is likely I will be poly separate in a non linear order so the face ID list would be something like f[12], f[2], f[6], f[8], so then the chipOff will return 2,6,8,12. which is predictable, but then I have to sort them back into the correct order which is a pain I think.
On Tuesday, March 5, 2013 3:40:17 AM UTC-6, Jesse Capper wrote: > So I did some more tests and think I may have found a way to use polyChipOff > and polySeparate and reliably get the chippedOff polys in the order they were > selected. > > If you call polySeparate with the -rs flag, it will only separate the shells > of the faces that are currently selected. So you could have a 5x5 plane where > every face has been chipped off, but if you select only one of those faces > and call cmds.polySeparate(rs=True), you will get two meshes: one of the > single face you selected, another of the remaining faces. > > Now, from what I can tell, the order of the resulting meshes seems to be > consistent. It depends on two things: the lowest faceID of each shell, and > the number of shells that are not being separated. In general the resulting > meshes are in the same order as the lowest faceID of each shell that was > separated. So if you have a mesh with 10 polys and you chipOff and separate > f[7], f[8], and f[9], the mesh that came from f[0:6] will be the first > returned mesh, f[7] will be the second, and so on. The only catch seems to be > if the portion of the mesh that is not being separated (in the previous > example that is f[0:6]) contains more than one shell, it gets returned last, > regardless of it's lowest faceID. So if you had a 10-poly mesh again and > chippedOff f[1], f[7], f[8], and f[9], but only separated 7:9, the order of > the returned meshes would be f[7], f[8], f[9], f[0:6], because of that fact > that f[0:6] contains two shells (f[1] being it's own shell since we chipped > that off). > > It's late and I'm hitting the sack but it's held up in all the tests I've > done so far. If that doesn't make sense (it probably doesn't) I can post some > images tomorrow. I'll run some more tests too. > > It's a weird one. > > On Monday, March 4, 2013 10:28:06 PM UTC-8, Jesse Capper wrote: > > What exactly are you trying to accomplish here? Splitting a ribbon of polys > > from an ordered edge selection and retaining the resulting meshes in the > > order the edges were selected? What problems were you running into with > > polyChipOff? > > > > On Saturday, March 2, 2013 3:36:54 PM UTC-8, Bradon Webb wrote: > > > here is my working solution: > > > > > > not pretty but i guess it gets the job done. since i am combining this > > > with another script my application is to select the edges in order around > > > the ring. and it will convert each edge selection into a ordered face > > > list. then I duplicate the object for as many faces as in the list, and > > > on each mesh deletes all the faces save the one from the ordered face > > > list. > > > > > > http://pastebin.com/U5QZXm2n > > > > > > polyChipOff was just too crazy to work with because the mesh keeps > > > changing names and also face numbers change around too. -- You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsubscr...@googlegroups.com. To post to this group, send email to python_inside_maya@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
