Hi all,
I am trying to reverse the direction of PolyCurves. I can’t simply use the Reverse node, as this one fails once the curves need a tolerance to get a successful join.
In the past, I used reversing all curves, or the lists they were in, or both (can’t remember, to be honest). But now I ran into a situation where I have two PolyCurves, and I cannot consistently reverse them. One will reverse when reversing the curves itself, but not when reversing the order in the list. The other one will reverse when reversing the order in the list, but not when reversing the curves.
Also using both reverse’s (list and curve) in any order doesn’t lead to a consistent result for these two curves.
Anyone any idea how to solve this, without writing ugly code (hey, did approach 1 work? No? Try approach 2!)?
PolyCurve-Reverse.dyn (47.3 KB)
curve_set_1.sat (5.4 KB)
curve_set_2.sat (40.3 KB)
Thanks,
GG
The easier question might be “Why are you reversing the polycurve?”
If you have a specific condition that has to be met, then you can check for compliance at each step along the way to determine when reversal needs to occur. The other option is to just rebuild the polycurve by points rather than reversing it.
how about reversing the points and knots of the nurbscurve?
Funny enough, I need the PolyCurve to build a grid of points, but the order of the points matter. Yes, I could create the points first, and then reverse the order, if needed, but I am getting tired to write uglier and uglier code because of Dynamo bugs and limitations. ;-(
Might work, but we would be again (see my post above) in “ugly code” territory.
What is “ugly code” in your opinion? Writing code that accomplishes your task is never ugly. It can be inefficient or use bad practices, but the reasoning for the code isn’t what makes it “ugly”. It can sometimes feel like additional steps are ugly and unnecessary because we’ve targeted the wrong issue. That’s always a good point to reevaluate our logic and try to understand what the root cause of the complication is.
My question about “why” you need to reverse is because the logic you’re building can probably be restructured to do what you want without so many steps and this perceived notion of “ugly” or “unnecessary”. If you’re building out a grid system then why are you dealing with curves and joined polycurves? If some curves need to be reversed and others don’t, then what is causing the difference? Should that not be the first priority? I think we need more context as to exactly what you’re wanting to do and the issue you’re running into.
If you have 100 code blocks to do the same thing because you don’t know how to use a list, that has to be deemed ugly surely?
All those methods are going to fail unless the curve was drawn in order.
You’ve got segments that make up the full curve… But they weren’t drawn sequentially.
Your curve is kinda like this (numbers are indexes in the list)
So no amount of reverse is going to help.
You need a way to put them in order.
Try this:
Then your curves should be in the right order for manipulation.
This is what I was trying to hint at. “Ugly code” isn’t the problem when you have ugly data. It can feel like you’re having to write unnecessary fixes when your logic is inherently broken (even if that’s due to ugly data that isn’t your fault).
First of all, I am thankful for your responses here! Nevertheless, I would appreciate if you would assume that (unless proven otherwise) I kind of know what I am doing, before telling me “you don’t know how to handle lists” or “your logic is broken”. 
My definition of ugly code:
Having to put in multiple nodes to fix things that Dynamo should right in the first place.
In this example:
The Reverse node does not work on all PolyCurves (already in the backlog for the Dynamo team). The workaround provided by THEM (so not my fault) when I reported this: reverse the order in the list (as you can read here):
So now the workaround wasn’t working for THIS example, which is why I asked for help.
The “ugly data” is produced by the Dynamo intersection node, when intersecting two sets of surfaces.
I need the points to be created on the polycurves to flow into the same direction, as I am building Polylines from them later. I am now going by the reversal of the order of some sets of points on the PolyCurves which I wanted to reverse.
Again, nevertheless thanks for the productive suggestions of the posts above.
The “hundreds of code blocks” have been created to make it easy to understand what is going on in that simple script on the first view. I was trying to be helpful for people who didn’t write this script.
Wait what?
Where did anyone say you couldn’t handle lists?
My message was an example of what I’d call ugly code… In response to Nick. Nothing in that message was in relation to your code.
Ah, sorry, misunderstood that message! Thought you were relying to my sample script…
The intent with these questions is never to assume one thing or the other. It’s actually the opposite. When trying to help others on the forum, we often have little to no context for why they’re trying to do something, what they’ve done so far, whether they’ve made any mistakes, or what their data looks like. In order to make accurate statements on your workflow, we have to be given explicit context. The comments made above where not meant to be directly applicable to you but rather explain in context the reasoning behind these kinds of statements.
There’s certainly an argument to be made on how these two nodes should interact with each other (and I agree with you in this case), but that doesn’t mean that their current interaction is inherently wrong. The polycurve does get reversed by how it was created, but that doesn’t always align with the conceptual understanding of how a reversed polycurve should look. The workaround would be to build out the logic that fixes this. That’s exactly what the Dynamo team is going to have to do to “correct” the node. If it’s good enough for the official fix, then why is it “ugly” for someone else to do it manually?
Again, I completely understand your frustration, but the issue isn’t just simply that polycurves don’t reverse. The real issue is that the geometry creating the polycurves wasn’t handled in a way that ensures all polycurves were created the same. It’s up to you to decide whether you’d rather fix the root cause of the “bad” geometry or write a workaround for the reversing of the polycurve. Just because something should be simple doesn’t mean that it is.
Fair enough, thanks, Nick!
This is close to an even more simple solution which I got reminded of by this post from you: creating a PolyCurve from curves automatically puts them in the right order. Simply retreiving the curves from a once created PolyCurve, reversing the order in the list of these curves then works, even without your “intermediate” node of CloseWithLine.
Thanks everyone, love the helpful community here!
Just to show that “fixing” the initial geometry isn’t that bad:
It’s just a matter of checking start and end locations to organize both the curve points as well as their location in the list. This could be simplified a lot more as well. I just wanted to show that it’s only two conditions with basically the same logic.
Thanks, Nick!
Wanted to weigh in here real quick…
Sadly 90% of geometry automation entails this, though usually it’s ‘check for a condition, and if it happens take action A; otherwise take action B’.
So in some cases yes the Dynamo team can and should address that - I will state with absolute certainty that Curve.Reverse should work with PolyCurves.
But in other cases we (the graph authors) should structure our graphs (scripts, code) in such a way that we prevent edge cases from occurring which will mean things generally execute faster. How that is done… well it is very context dependent, which isn’t an ideal answer as it doesn’t help here (I think you’re squared away with the PolyCurve.Curves > List.Reverse and some of the other methods noted in the thread).
This isn’t to say any one person’s code isn’t good (every graph is a win in some way), or that Dynamo is as easy as it could be (no blockers is the ideal which I would like to see), but that dealing with these issues is a part of the process inherent to scaling the code across projects, ecosystems and toolsets.