Plugin search help -- combining lines
-
You are right about setting the variable to 'class' using @@ rather than 'global' with $ - it's much safer - I was churning that out rather too quickly...
The 'trick' to force broken edges into one only works on plain edges.
With an edge that's part of a curve it can't... for you next step why not see if you can find all edges that are co-linear [it already does that and if one is part of a curve then remember all of the curves edges in an array and then explode the curve, immediately remake the curve leaving out the one edge you want to heal. Then it will heal back into its co-linear mate... It just needs a test in the iterated loops...
When 'we' get it 'perfect' then 'we' could issue a joint 3-way update...
-
You mean 4-way
-
@unknownuser said:
You mean 4-way
Like "Additional semi-humorous material supplied by Rich O'Brien."
-
If you mean that 'Disconbobulator' isn't a good name for a plugin then so be it. It may not be a impressive as 'Quadrilateralizer' but its close!
-
@unknownuser said:
If you mean that 'Disconbobulator' isn't a good name for a plugin then so be it. It may not be a impressive as 'Quadrilateralizer' but its close!
I wanted something to explain what it did in the name. RickW's 'Windowizer' makes Windows, my 'Latticeizer' makes Lattices and 'DeBabelizer' translates text [Babelfish/TowerOfBabel etc]... When you make triangles out of a face you 'Triangulate' it BUT when you make a face into quadrilaterals you don't say you 'Quadrilateralate' it [that was an early alternative name!]; an '-izer' ending suggest 'doing' so 'Quadrilateralizer' it became... 'Quadrilateralizer' gets 635 hits on Google, 235 of them when it's combined with 'TIG' - strangely most are Chinese
-
Well, at least (here, on the forums) we do not have to pronounce that quadri... plugin.
Back in Mountain View in 2008, I even had issues with the Protractor tool (certainly Rich will chime in with some ideas about drinking less the night before and such I am sure)
-
@tig said:
You are right about setting the variable to 'class' using @@ rather than 'global' with $ - it's much safer - I was churning that out rather too quickly...
The 'trick' to force broken edges into one only works on plain edges.
With an edge that's part of a curve it can't... for you next step why not see if you can find all edges that are co-linear [it already does that and if one is part of a curve then remember all of the curves edges in an array and then explode the curve, immediately remake the curve leaving out the one edge you want to heal. Then it will heal back into its co-linear mate... It just needs a test in the iterated loops...
When 'we' get it 'perfect' then 'we' could issue a joint 3-way update...Ummm, maybe later.
Doesn't need to be perfect...Anywayz ... here is another problem: a set of connected lines were 2 of them are said to be repaired, but never are. I attached the model. I think the tolerance is too low perhaps?
-
The edges in the 'line' are not co-linear, the first two edges' vectors differ noticeably and the rest diverge even more... Vector3d(0.0104132, 0.999946, 0) and Vector3d(0.0101495, 0.999948, 0)... so they won't be joined by Sketchup into one edge no matter how hard you try - but you could of course 'weld' them into a 'curve'......
-
@tig said:
The edges in the 'line' are not co-linear, the first two edges' vectors differ noticeably and the rest diverge even more... Vector3d(0.0104132, 0.999946, 0) and Vector3d(0.0101495, 0.999948, 0)... so they won't be joined by Sketchup into one edge no matter how hard you try - but you could of course 'weld' them into a 'curve'......
Yeah, I see...but.... the plugin says they are... or thinks they are...
-
@agamemnus said:
@tig said:
The edges in the 'line' are not co-linear, the first two edges' vectors differ noticeably and the rest diverge even more... Vector3d(0.0104132, 0.999946, 0) and Vector3d(0.0101495, 0.999948, 0)... so they won't be joined by Sketchup into one edge no matter how hard you try - but you could of course 'weld' them into a 'curve'......
Yeah, I see...but.... the plugin says they are... or thinks they are...
I expect that's because the 'parallel?' test for vectors returns true but Sketchup itself still won't join the lines as they are not co-linear...
We could replace the test with something else as the two vectors are clearly not equal - perhaps comparing them as arrays - so v1.to_a==v2.to_a returns false [correctly] even when v1.parallel?(v2) returns true !! -
@tig said:
I expect that's because the 'parallel?' test for vectors returns true but Sketchup itself still won't join the lines as they are not co-linear...
We could replace the test with something else as the two vectors are clearly not equal - perhaps comparing them as arrays - so v1.to_a==v2.to_a returns false [correctly] even when v1.parallel?(v2) returns true !!I see... so it's really a Sketchup bug. "parallel" is built-in, (right?), but it doesn't have the same precision as the main program, which is a decently-sized oversight.
In terms of comparing them as arrays: that's probably slower, but it might have the same comparison as the main program. (I don't know)
I'm not entirely sure how Sketchup does precision anyhow... floats (32 or sometimes64 bit numbers with decimal points)? Really big integers masquerading as floats? Some weird combination? There's a big difference... two string representations of a float will often look different but actually have the same float value. I suspect something like that is happening here.
-
Bump!
I'm going to forget that TIG's code/solution existed in 2 months and re-post my question...
Advertisement