[Closed] Mini-Challenge #3

This works fine for small collections, but explodes with 100 teapots… I was hoping that proboolean’s merge would be fast since no geometry calculations are done… And you can pass it an array of nodes to merge so no need for iterating over a selection in maxscript…

objs=$selection as array

main=objs[1]
deleteitem objs 1
 
ProBoolean.CreateBooleanObjects  main objs  3 2 1

i’ve posted unified test with [b]ivanisavich /b and [b]3dsmax /b methods. the test generates defined amount of boxes in different range and order. small boxes has to be attach to big box. my method is caster. it’s hidden temporarily.

see the code and use custom slot for your algorithm following the template. let me know if need any assistance.

the code is http://forums.cgsociety.org/attachment.php?attachmentid=162171

next time when you want to show your method please just post the customAttach function:

 	fn customAttach source nodes pb:pb1 = 
 	(
 		count = nodes.count
 		 <loop> while not keyboard.escpressed do
 		(
 			pb.value = nodes.count*100./count
	   /*
		   your attach method with counting number of attached vertices
	   */
 		)
 		source
 	)
 

i’ve double-checked. ProBoolean Merge is not the same as Attach.

with your test case my method is a bit slower than regular cluster attach because the test objects are already editable_polys. I was testing with teapot primitives earlier, in which case converting each object to a poly (cluster attach method) is much slower.
I will look for a method which is more optimized for this test case.

there is a myth that attaching or some other extensive operations are faster with UNDO OFF. check the test. it’s not TRUE. but it’s a subject of another discussion.

cluster:
Create. Time: 0.266 Memory: 133912L First: p0 Last: p99
Create. Time: 0.262 Memory: 132792L First: p0 Last: p99
#cluster: with undo:on Time:0.438 Memory:5880L Updates:329002

My method:
Create. Time: 0.263 Memory: 133304L First: p0 Last: p99
Create. Time: 0.261 Memory: 133280L First: p0 Last: p99
#custom: with undo:on Time:0.235 Memory:2312L Updates:0

Here’s the code, I could optimize it a bit further

edit: A thing that might disqualify me is that the timings appear before the actual mesh does

  	------------------ template ----------------
  	fn customAttach source nodes pb:pb1 = 
  	(
  		objs=nodes
  		main=source
   
  		ProBoolean.SetOperandA main
  		ProBoolean.SetPlanarEdgeRemoval main 2
  
  		ProBoolean.SetUpdateMode main 3
  		for i=1 to objs.count do
  		(
  		ProBoolean.SetOperandB main  objs[i]  4 2 
  		)
  		ProBoolean.SetUpdateMode main 0
  		
  		main
  
   )
  

you have to convert to POLY. it changes everything

sorry but what does the pb:pb1 means in the function definition?

Ok, I finally have something that beats cluster attach performance, if only by ~5%:

fn customAttach source nodes pb:pb1 = 
	(
		fn qsfn v1 v2 = v1.numVerts - v2.numVerts		
		insertitem source nodes 1
		qSort nodes qsFn
		local k = 1
		local count = nodes.count
		local att = polyop.attach		
		while nodes.count > 1 and not keyboard.escpressed do
		(
			local nk = nodes[k]
			pb.value = 100 - nodes.count*100./count
			att nk nodes[k+1]
			verts += nk.numverts
			deleteItem nodes (k+1)
			if nodes[k+2]!=undefined and nk.numVerts >= nodes[k+2].numVerts do k += 1
			if k >= nodes.count do k = 1			
		)
		nodes[1]
	)

#cluster:	with undo:on	Time:2.297	Memory:72168L	Updates:5567158
#custom:	with undo:on	Time:2.209	Memory:72192L	Updates:5297612

lo,
how many nodes are used for this test? what method of distribution?
but your solution is exactly same as I started from qsort is very slow…