I must orient all the sub-curves to the original curve direction.
Any suggestion?
Thanks,
Roy
orient curves direction.gh (12.8 KB)
I must orient all the sub-curves to the original curve direction.
Any suggestion?
Thanks,
Roy
orient curves direction.gh (12.8 KB)
Hi,
Have you tried the “flip curve” component ?
You can use the original curve as a guide.
Hi Baptiste,
with the original curve it doesn’t works (I don’t know why…it was my first choice) but I’ve found the solution:
Why would you Graft your point list at the very beginning ?
At first, I would have tried this way :
But you’re right, it doesn’t seem to work and I don’t understand why… Probably related to the way the “Flip” component has been designed.
You could also try this as a workaround :
thanks, baptiste.
there was already a solution in the previous post, anyway
let’s add a third one
this does not shatter anything, in order to maintain complete integrity, and just retrieves subcurves of your original curve
because domains are untouched and sorted, the direction of each subcurve is unchanged in relation of the original one
generally speaking, whatever works is fine, but I wouldn’t shatter unless strictly necessary (which is not, at least in this particular case)
extract subcurve without shattering.gh (13.5 KB)
Brilliant! Thanks a lot!
As usual, I spoke too soon…
My issue now is that the sub-curve is a “new” curve, not a piece of the original like I have if I use shatter. So when I finish, I must make a solid difference that it doesn’t work this way.
if you refer to the sub-curves having Domains that are referenced to the original curve (A) -yes they are- you can reset the sub-curve domains to default “0 to 1” value by Reparametrizing them (B) or by providing an explicit domain (C)
extract subcurve without shattering.gh (20.7 KB)
if your observation is not about the Domains, then I’m sorry but I haven’t understood the issue correctly
Hi inno,
here is the example about what I’m telling.
Using “SUB CURVES” the solid difference fails, using the scattering it works.
subcurve vs shatter.gh (24.6 KB)
Ops… right now, I’ve found that the problem is not caused by using the SHATTER/SUBCURVES command but by using the OFFSET command.
It’s the OFFSET of the curve that APPROXIMATE the new curve that doesn’t follow the original offset curve.
So, the second definition will work if you use the subcurve. However, you can’t use the first easy definition because of the OFFSET command.
P.s. god is in detail
I think that particular thing is more of a solid boolean issue: if you increase the thickness of the solid part to be removed, like in this case I applied a stupid x*2 in such a way the solids to be intersected share the least amount of same surfaces, the top definition looks like working fine as well
subcurve vs shatter_inno.gh (21.1 KB)
I am on 8 SR6 (8.6.24074.1001, 2024-03-14)
Yes, of course.
As mentioned, the OFFSET curve “approximates” the new curve, so it doesn’t work without growing the cutting solid. With the second method, you don’t need any workaround to create the right boolean difference.
The only way to make the first method possible is to grow the tolerance in Rhino (but all these workarounds will cause significant problems in your future work).