Group.make_unique VS group.name = name

jolran

Yeah! At least no more annoying message!

thomthom

I am adding them as "add_instance" from "groups.entities.parent", that may be why I getting splats.

You could output debug messages to a file and see when the messages stopped - then you know whereabouts the crash occurs.

There is a bug where a group's parent isn't correct. See snippet here on how to detect and ensure you get the correct definition:
http://www.thomthom.net/thoughts/2012/02/definitions-and-instances-in-sketchup/#finding-the-componentdefinition

Info on how to reproduce it: http://sketchucation.com/forums/viewtopic.php?f=180&t=19765&p=163776#p163776

jolran

Thanks, thoose will be very useful.

However I do not get any splats any more, if renaming the groups that is
Before I used make_uniq and all was fine too. No splats.

I'm pretty sure I know whereabouts the crash occours anyway, it's when using transform_by_vectors inside groups. This is all done while looping a surface, so I'm investigating if I could speed loop up somehow, cause its calling a couple of methods.
Reccursion or not I don't know yet..

thomthom

@jolran said:

This is all done while looping a surface, so I'm investigating if I could speed loop up somehow, cause its calling a couple of methods.
Reccursion or not I don't know yet..

You do you many transformation within a loop?

Bulk operations is always faster than many separate ones. If you need to cache some data and perform one big transformation it will be faster.

jolran

@unknownuser said:

You do you many transformation within a loop?

Yes, to each groups vertices while looping the surface they are added onto. It sounds terrible.

I tried storing vertices and vectors for each group in a Hash. Structure: hash{ group => [vertices], [vectors] } for a transformation outside the surfaceloop.

Then loop only groups and transform by vectors. But that was surprisingly slower than going 1 big loop.
I did try that in a rather quick test, so I will revisit again and see if I can split loops up a little or maybe hardcode some values.
Difficult when there are quite a lot of arguments being tossed around.

I do not know what performance to expect. Maybe I'm trying to bend Ruby into what it's not.
C-extension seam to far away for me..

Transforming vertices on groups entities. Its over 400 000. So maybe 9 min is normal?
You can see there are tiny gaps between groups here and there. It is because I'm only doing tapering on the sides. If I do tapering on top-bottom as well processing time will double!

Anyway, I try to stay ontopic, although I'm stressed about this

Group.name maybe gave a slight speedboost and the ruby console don't get filled up with error messages.

thomthom

Is this a commercial plugin? Or can you show the code? Might be able to make some suggestions.

Ingeneral - if your Ruby loop mostly calls SU API methods then a C extension won't be that much faster. It'll have pretty much the same overhead calling ruby methods. Where you can make a performance boost is if you have lots of calculations.

thomthom

1931 groups - and how many faces/vertices in each group?

jolran

233 entities X 1931 groups in this test.

@unknownuser said:

Ingeneral - if your Ruby loop mostly calls SU API methods then a C extension won't be that much faster. It'll have pretty much the same overhead calling ruby methods. Where you can make a performance boost is if you have lots of calculations

Ah, Ok.
I do not know where I am on that scale exactly.

It's not a commercial plugin. Not yet anyway . Although it's starting to cost, timewise in coding this

The script is too messy to be posted here, but can show a line sweep method that is costing time. Or rather it's the transformation of the vertices at the end that is expensive.
This method is called after the group is inserted on to the face, when looping the faces. There can be many groups!

Prior to adding the instance to the face I have calculated angle of rotations, vectors and lines needed for this linesweep.

Principal for a line sweep is to calculate 1 side at a time. L, R, Top, bottom etc.
Edit: I guess on could merge calculation for both pair so sides. L,R and then Top, Bottom. Perhaps.. Don't know if that would improve performance though..
Limitline is the face other edge one could say.

I had to figure out a calculation so the scaling gets exponential(when nearing the centerline = less), without doing to heavy Math.
Unfortunately the arrays gets recreated everytime.
It might be difficult to grasp what is going on with so little code provided. But I'm not comfortable in posting the whole script yet.

def self.linesweep(face, verts, gp, center_line, sweep_vec, limit_line, centerline_max)
		#ALOGARITHM; Scalevector.length = n-(n * intersectionpoint/MAXDistance )
		vecs = []; vertises = [] #
		
		for v in verts
			vp = v.position.transform!(gp.transformation) #match group transformation once.
			vp = vp.project_to_plane(face.plane)# 3D geometry
			sweep_Line = [vp, sweep_vec] 
			vp2 = vp.project_to_line(center_line)
			vec2 = vp.vector_to(vp2) 
			next if vec2.length <= 0 #error if not.
			if vec2.samedirection?(sweep_vec.reverse) 
				i = Geom.intersect_line_line(sweep_Line, limit_line) #outside limit line.
				ig = i.distance_to_line(center_line).to_l
				scalefactor = ig/(centerline_max) #
				scale_len = vec2.length-(vec2.length*scalefactor)
				vec2.length = scale_len.to_l
				vecs << vec2.transform!(gp.transformation.inverse) #
				vertises << v #
			end
		end
		gp.entities.transform_by_vectors( vertises, vecs ) #
	
	end

thomthom

You can PM me the whole lot if you want me to look at it privately.

jolran

That would be better for me. I'll try to clean out the rubbish from the script first.

BTW, thanks a lot. You are very helpful

back soon..