MaxScript Editable Poly - Collapse vertices
I've done a similar script by request quite a while ago, the barebones version would be:
Hopefully it's short enough for you to comprehend while still applicable (with a few changes here and there - you might want to use 3d grid for lookup for complex meshes, for example). Instead of collapsing the verts, it positions them at the same place - one loop to find all close verts, another to merge them in groups. It uses a threshold (btw. note that equality comparison on two Point3 values, effectively vectors consisting of single precision floats, will often return false even when the two points are by design on the same position - look up float comparison for further info).
Using mesh instead of poly methods is just my personal preference, if you'd like to use polyop methods, only averageSelVertCenter would need to be replaced by a simple function - sum of all positions divided by their count.
try destroyDialog ::vertexFuse catch()
rollout vertexFuse "Vertex Fuse" width:150 height:65
(
spinner spnDist "Distance: " range: fieldWidth:50 type:#worldunits
button btnFuse "Fuse Vertices" width:135 height:25 offset:
local setMeshVert = meshOp.setVert
fn getNearbyVertices index list dist verts queue =
for v in queue
where distance verts.pos verts.pos <= dist do
(
append list v
queue= false
getNearbyVertices v list dist verts queue
)
on btnFuse pressed do with undo off, redraw off
(
if selection.count != 1 do
return messageBox "Select one object."
local obj = selection
local objTM = obj.transform
if NOT isKindOf obj Editable_mesh do convertToMesh obj
setCommandPanelTaskMode mode:#create
local verts = obj.verts as bitArray
local vertCount = verts.count
local vertList = join #() obj.verts
local vertDist = spnDist.value
local vertQueue = #{}
local matchedVerts = #{}
local fuseList = #()
for i = 1 to vertCount do
(
local v = vertList
for j = i + 1 to vertCount
where NOT matchedVertsAND
distance v.pos vertList.pos <= vertDist do
(
append vertQueue i
append vertQueue j
append matchedVerts j
)
)
local vertToSelect = copy vertQueue
for v in vertQueue do
(
local vertGroup = #{}
getNearbyVertices v vertGroup vertDist vertList vertQueue
append fuseList vertGroup
)
for each in fuseList do
(
obj.selectedVerts = each
setMeshVert obj each ((averageSelVertCenter obj) * objTM)
)
obj.selectedVerts = vertToSelect
setCommandPanelTaskMode mode:#modify
subObjectLevel = 1
)
)
createDialog vertexFuse
Hopefully it's short enough for you to comprehend while still applicable (with a few changes here and there - you might want to use 3d grid for lookup for complex meshes, for example). Instead of collapsing the verts, it positions them at the same place - one loop to find all close verts, another to merge them in groups. It uses a threshold (btw. note that equality comparison on two Point3 values, effectively vectors consisting of single precision floats, will often return false even when the two points are by design on the same position - look up float comparison for further info).
Using mesh instead of poly methods is just my personal preference, if you'd like to use polyop methods, only averageSelVertCenter would need to be replaced by a simple function - sum of all positions divided by their count.
You are free to use whatever suits your purpose best, meshop methods are in some cases faster but sometimes the conversion from poly to mesh beats the purpose.
I'm not sure what you mean by the border here. In a subobject sense, finding out if a vertex lies on a border means that the vertex is one of the border verts - you'd get the border verts before entering the loop - borderVerts = polyOp.getVertsUsingEdge obj (polyOp.getOpenEdges obj) - and then in the loop test for it - borderVerts.
As for averageSelVertCenter, just look it up in the reference. Same applies for where condition - look up for loop syntax in the reference.
I'm not sure what you mean by the border here. In a subobject sense, finding out if a vertex lies on a border means that the vertex is one of the border verts - you'd get the border verts before entering the loop - borderVerts = polyOp.getVertsUsingEdge obj (polyOp.getOpenEdges obj) - and then in the loop test for it - borderVerts.
As for averageSelVertCenter, just look it up in the reference. Same applies for where condition - look up for loop syntax in the reference.
No, it won't work like this, look at the code I posted before - the second loop is not just iterating over all the candidates, it's recursively searching for the neighbor candidates to collapse. To see what would happen in you case compare it with for example max teapot, 4 segments, 120-unit radius - run my code on it converted to editable mesh, run this code on it converted to editable poly:
That's basically your code cleaned up a bit with some erroneous parts removed.
Have a look at bitarrays and how they work, and study polyOp structure for a while to see what you can use. Don't write new code until you are familiar with them, otherwise you end up reinventing the whell which makes your code both slower and harder to read (and introduces some bugs here and there as well). Take for example this part:
Using bitarray for disabledVerts, it can be rewritten as
Note that in another line,
And a minor nitpick would be changing
Also don't use EditablePoly methods, many of them require modify mode and redraw the UI, which slows things down. Another problem with them is that you often have to select verts and "push the buttons" instead of passing some arbitrary vertex bitarray directly to a function.
(
local distanceToCollapse = 10.0
local objs = for obj in selection where isKindOf obj Editable_Poly collect obj
local getVertPos = polyOp.getVert
for obj in objs do
(
local disabledVerts = #{}
local vertexCount = polyOp.getNumVerts obj
format "Object: %, Vertex count: %\n" obj.name vertexCount
print ("Detection started ...")
for a = 1 to vertexCount-1 do
for b = a + 1 to vertexCount
where distance (getVertPos obj a) (getVertPos obj b) < distanceToCollapse do
(
append disabledVerts a
append disabledVerts b
)
format "Detection finished. Detected % collapsible vertices of %.\n" disabledVerts.numberSet vertexCount
polyOp.collapseVerts obj disabledVerts
format "Vertex count after collapse: %\n" (polyOp.getNumVerts obj)
)
)
That's basically your code cleaned up a bit with some erroneous parts removed.
Have a look at bitarrays and how they work, and study polyOp structure for a while to see what you can use. Don't write new code until you are familiar with them, otherwise you end up reinventing the whell which makes your code both slower and harder to read (and introduces some bugs here and there as well). Take for example this part:
for c = 1 to disabledVertex.count do
(
if disabledVertexas Integer == b as Integer then
(
availableVertex = false
print (...)
)
)
Using bitarray for disabledVerts, it can be rewritten as
if disabledVerts do print (...)or rather using this line together with the original condition ((...) AND (...)). Apart from the debug print, it's not needed here as bitarrays don't have duplicate entries anyway so I left it out in the end.
Note that in another line,
disabledVertex = disabledVertex + #(b)is actually
append disabledVerts b
And a minor nitpick would be changing
collapsableVertex = collapsableVertex + 1to
collapsableVertex += 1although you don't actually need it at all.
Also don't use EditablePoly methods, many of them require modify mode and redraw the UI, which slows things down. Another problem with them is that you often have to select verts and "push the buttons" instead of passing some arbitrary vertex bitarray directly to a function.