@unknownuser said:

Pascal's averaged 8.4 versus 45.9 for Caul's

Heh, really ?? 8 seconds vs 45 for 5000 Points ?

edit:( My timings: Pascal ~ 10 sec, CAUL's module 1.11 sec )
Then CAUL's method add constructionpoints inside the timings, also.

I forgot to mention I tested under Su8. So maybe "distance squared" performs better under Ruby2 ? Might be worthwhile to do some profiling after all then.

(I don't know the accuracy of the test..)

	mod = Sketchup.active_model
	sel = mod.selection
	ents = mod.entities

	sel.clear
	
	cps = []
	saved = []

	maxdist = 1000
	mindist = 500
	
	minSQ = mindist*mindist
	
	tp = ents.add_cpoint( ORIGIN ) #testpoint Try offsets from 0,0,0 ?
	tp = tp.position
	
	for i in 0..5000
		cp = ents.add_cpoint( Geom;;Point3d.new(rand*maxdist,rand*maxdist,rand*maxdist) )
		cps << cp
	end

	t = Time.now
	
	cps.each{|cp|
		
		pt = cp.position
		
		x = tp.x-pt.x
		y = tp.y-pt.y
		z = tp.z-pt.z
		
		#next unless pt.distance(tp) <= mindist
		next unless ( x*x + y*y + z*z ) <= minSQ
		
		saved << cp
	}
	
	puts Time.now-t
	
	sel.add( saved )
	nil
	
	

@unknownuser said:

You could try to use a space hash.

That looks nice! Did you get that from the Geometric Tools library ?
Ive seen something similar like this before and can't remember where it was.
Looks useful for other tests as well.

Edit: the distance Square method gives 0.016 sec for 5000 Points btw...
About twice as fast as pt.distance(pt)
Scratch that. I forgot to mute the subtractions. About same as API distance method. So I would suggest trying CAULS method.
There is probably Little to gain from using distance squared in Ruby vs API methods.

@unknownuser said:

The idea was NOT to compare all points, but as some are discarded, to be sure they are not compared in the loop with all others, to reduce the total number of comparisons.
If I copy "valid" points in another array, I will have to compare all points, even those already found as "too close".

Ah I see. As long as you have a plan for it

I was thinking if one could reverse engieneer the distance to only do added subtraction tests.
Probably NOT since 1 large dimension value can negate the others (?). But it wont hurt trying to see if you could find an algorithm for that.

The distance method use Square root. So it's bound to be slow.

You could do testing with "distance squared" method, although it won't give you the accurate distance.
But maybe for sorting out some Points for a more detailed test.

You could compute the 1 comparing distance from distance = (dist*dist) and compare with that perhaps.

Distance Square uses 3 multiplications and 3 subtract. So I don't know if the Ruby version will be faster than the API "distance" method, though.
In a C-extension it is for sure.

Point a and b

x = a.x-b.x; y = a.y-b.y; z = a.z-b.z # Don't remember if one has to use .abs (?)
dist_sq = xx + yy + z*z

Distance = Math.sqrt( dist_sq )

Regarding you code I'm not sure what you want to do with marking the Points with a boolean.
It might be faster to append results to a new Array rather then store a lot of small arrays . And maybe even use a Hash.

I can imagine some clever person have convoluted API way for comparing distances between points. This code will work in a C-extension though..

@jiminy

@unknownuser said:

I wonder what Trimble will do with webdialogs if MS gets rid of IE. Go with Spartan, or finally embed a browser? Or completely ditch webdialogs?

Good question.

Ditching webdialogs would put me in a somewhat bad mood, since invested so much time (and code) in dealing with them.

It would break many plugins, that's for sure.

Good luck!

Havent tried swig.

Are you using the provided examples at the Github Project ? They should be relatively new.
https://github.com/SketchUp/ruby-c-extension-examples

If you follow this "not so old" discussion there some info about C++ extensions.
Not swig releated, but you might change idea and go straight C++.
(Can't see why it woulden't be more straightforward using C++ for connecting to a C++ library.)
http://sketchucation.com/forums/viewtopic.php?f=180%26amp;t=58825

As you can see I'm not expert at the subject. But picking up the example I could just hack away. It worked pretty much straight of the bat. Well almost

Thomthom might provide you some more solid advice about the subject..

@unknownuser said:

In earlier versions of the plugin I did manually use your 2dBoolean afterwards because the plugin only did the hatching. In the newer versions, I added code to do the intersections immediately after the copy-ing process so 2dBoolean isn't needed anymore. The workflow got more streamlined by doing so.

Ah, I see.

Your code seems to be working fine though.

I don't get same timings on my computer. 25k is already taking over a minute to intersect. So in my computer in order to achieve a "smooth" workflow as a stamptool I would estimate components shouldn't rise above 10K.
50K -100K really sounds a lot. But I'm getting the impression my computer is getting old..

Like I said in another topic, it would be interesting to see what kind of response time different workstations get from intersections like this. And using edge-patterns in LO.

Although that line patterns would never really become dense(?) and cause a problem, but does indeed look very useful.

Looking good..

Are you still using 2dboolean for the intersection part ?

Looks a bit faster now, although I couldent estimate edgecount by a video.

Now you are just being a bit square

@unknownuser said:

I know Jolran's been working on a vector based plugin, Hatchfaces, for some time, but it looks like he's stalled. Perhaps the inclusion of pattern-fills in LO has stolen his fire for the project. If so, too bad. It was promising.

Hi.

Just wanted to say Hatchfaces is not forgotten, but I'm working on a different project which eventually might include some hatching possibilities.

Inclusion of pattern-fills in LO and now Skalp, has indeed taken away motivation from updating Hatchfaces itself. At least until there is a lot of demand for it..
Meanwhile you could checkout 2d boolean..

During my research I have come to the conclusion that the texture approach is probably the simplest way to go. Because of flaws of intersections and calculation time.

However, I'm tinkering out different approachs avoiding intersections. But "User-patterns" will be difficult to support, which is a bit dissapointing.

Another thing, but related.

It would be interesting to hear about experiences of building a whole model with many edge hatches. Cause I did that once with 2dboolean.
And while it was fine in Sketchup. Working in LO was a disaster. Could barely change pages.
LO doesent like many edges...

Really cool! Crazy amounts of polygons.

Right! (about the model)

@unknownuser said:

it would be neat to see sketchup adopt some sort of psuedo-nurbs eventually ala bonzai3D (or now form•Z jr)

Pseudo-Nurbs ?! I forgot about Forms. Should have a peek and see what the pseudo is about.

It's problematic with the tesselation as Quad type in Sketchup since we can only use planar faces. Also adding geometry is fastest with Polygonmesh class which also requires triangles.
So I don't know..

In my case I'm only subdividing the tesselation/triangulation.

But I agree, NURBS built into the Sketchup core would be nice.

Jeff I hear what you're saying and understand what you are getting at. The complexity you wish would probably scare away many newbies, yes.
It's difficult to find a balance of power and simplicity.
I think XSI foundation did it nicely, but alas...

But we can drop the subject if you prefer..

EDIT: That Z_BRUSH model One of those belts of the model would kill Sketchup.

@unknownuser said:

they are already there, SU just fails to use them with it's own tools...
but exports them to AutoCad, go figure...

What do you mean. Does Sketchup have some underlying code I never heard about ?

@unknownuser said:

can't the vector be form child.bounding_box.centre to target.bounding_box.centre ?

I place the boxes on points from a grid. Those points can be reused for building the vectors to target. So it would probably be the same thing as you mean ?
I suppose a "Align with vector" Node would be in order to transform locally in the vector direction.

Anyway I try to keep a maximum of 50 nodes when developping, so I have to deal with this later. I just wanted to show that it could probably be done with point to target algorithm.

However rereading the post more closely I don't think it's what the author wants. So back to Jeff and the magnetics

Heh, well put.

I'll accept your answer.

Although to give cred to the Guys at Trimble I do think they have made great changes recently that will permit further enhancements of Sketchup.

Regarding arcs and circles. They will come
Knotvector-based, nonuniformed rational ones...

Jeff hammond. Why do you often direct to Rhino as a solution to problems when modeling in Sketchup?

Don't you want Sketchup to evolve ?

Rotate by distance looks a bit funky. Maybe if used normalized values...

The vectors are all setup, so I guess one could easily go for an angular approach instead...

@unknownuser said:

use js as a visual menu, with some sliders...

You mean like a node-editor ?

You mean generating the data from Javascript ? I'd imagine that would be rather slow..

My theory is to let HTML/Js do the Gui part and do the heavy calculations on Ruby and or C++ side..
That's just my opinion, but I'll stick to it.

I use d3.js as JS library and it's used quite often for scientific illustration.
It has Voronoi, projections etc. But to slow to use with Sketchup.

These kind of parametric geometries tend to get dense pretty quickly, so fast code is quite essential. But that library has some interesting code that's for sure.

Interesting!

I'm working on a parametric modeler that could hopefully(one day ) do this sort of things.

I can say from my own test-experiences you would REALLY want some kind of real-time preview setting these things up. Having a 1-shot plugin doing this is akward.

It does look more like distance based rotation/alignment on the first picture. Rather than some sort of magnetic 2 flow-direction.
edit: Looking again it does look like all the cubes are pointing at the point regardless of distance

The magnetic version is interesting though!

But that would be a totally different and more complex algorithm based on curve fitting. More in the way Jeff demonstrates.

Feel free to PM me ideas and suggestions. Looks like you have a few.