Mergecoplaner - slow

Rhino
1

I’m merging a lot of coplaner faces (like 1000+ objects) but it is fairly slow. I don’t feel like it is utilizing parallel processing, and it’s also spending a lot of delay on printing for every single object.

Perhaps it needs a review?

2

also pressing escape doesnt stop it, despite the messages. (perhaps it skips 1 of my 1000 objects)

3

Here is a python script that does this with parallel computing:

#! python 2
# BJW Merge Coplanar Multithreaded

import Rhino
import rhinoscriptsyntax as rs
import scriptcontext as sc
import System.Threading.Tasks as tasks

tolerance = sc.doc.ModelAbsoluteTolerance
angle_tolerance = sc.doc.ModelAngleToleranceRadians

def merge_coplanar():
	objects = rs.GetObjects("Select meshes, polysurfaces or SubDs", filter=16+32+262144, preselect=True)
	if not objects:
		print("Cancel")
		return

	new_geometries = [None for obj in objects]

	def worker(i):
		obj = objects[i]
		geo = sc.doc.Objects.Find(obj).Geometry
		if geo.ObjectType == Rhino.DocObjects.ObjectType.Mesh:
			geo.MergeAllCoplanarFaces(tolerance, angle_tolerance)
		elif geo.ObjectType == Rhino.DocObjects.ObjectType.Brep:
			geo.MergeCoplanarFaces(tolerance, angle_tolerance)
		elif geo.ObjectType == Rhino.DocObjects.ObjectType.SubD:
			geo.MergeAllCoplanarFaces(tolarance, angle_tolerance)
		else:
			return
		new_geometries[i] = geo

	Rhino.RhinoApp.SetCommandPrompt("Threads processing, please wait...")
	tasks.Parallel.ForEach(xrange(len(objects)), worker)

	Rhino.RhinoApp.SetCommandPrompt("Applying new geometries...")
	rs.EnableRedraw(False)
	for obj, new_geo in zip(objects, new_geometries):
		if new_geo is None:
			continue
		obj_ref = Rhino.DocObjects.ObjRef(obj)
		sc.doc.Objects.Replace(obj_ref, new_geo)
	rs.EnableRedraw(True)

if __name__ == "__main__":
	merge_coplanar()
4

Lovely, never thought of that and I’m a coder myself. Although maybe it would be useful by default for other non-forum-addict users :rofl::hear_no_evil_monkey:

5

I think the ESC key works to stop a single large merge operation, but it doesn’t work to break a large batch of individual operations. Maybe the above script could be modified to have the worker query the current state of the ESC key.