The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
In my past I did a lot of geometric programming. Something we had to be be very careful of was degenerate intersections and numerical tolerance. That is the first thing I thought of when you mentioned an odd number of intersections. If you are at or very close to the endpoint of a line segment, it might miss, or hit, when it really shouldn't.
Sometimes you have to catch them and handle them specially (*cough* hack *cough*). Like artificially extend the vector slightly to see if it intersects within the segment, or keep intersections that are questionable conditional until you can tell the count is right. For instance, imagine two line segments whose common endpoint is on or very close to the segment you are intersecting with. Really, there should be only one intersection there. But if you count each segment endpoint as colliding, then you get two intersections where you should have only one. Or vice versa, you might discard both because you think they are off the line, and have zero where you should have one.
Sorry, this is off the top of my head remembering stuff we had to deal with a long time ago.
Hey I am pretty sure it is such error.. it only happen (so far as I know) with 2 almost parallel shape and one with 1 very small edge...
Anyhow can't do anything more about this week, preparing a table top RPG adventure..
But gods this is so frustrating...
For the record to get around such issue I merge many point that I found close to each other, nudging them slightly.. But that is not enough... Now I also use smarter crossing edge detection at intersection, still not enough..
That's how I have solved some knotty issues with a Python bouncy ball simulation I have been writing(just because I wondered what all the hype about Python has been).
I created a logger class and wrote all the data out to a tab delimited file.
I then found fairly quickly where the issues were - as rather than see isolated data, which is what debugger information tends to present, I was able to see data over time and solve the problem from there.
“That which can be asserted without evidence, can be dismissed without evidence.”
write a python parser, then we'll talk about "getting used to it" when you have to make the grammar (including the tokenizer) context sensitive in order to handle significant vs insignificant whitespace.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
Seems to me you have an ID problem here. I will try to explain. When your eraser tool, which is nothing but a circle object intersects with the existing object it creates new vertices. Those new vertices need to be connected to existing ones. During this process an AREA needs to be defined within the connections will happen. Since you have no area defined, newly formed vertices connect to the existing ones. Since no more than 2 vertices can be connected on a 2 dimensional object, an existing connection is broken splitting the object in 2. Here's how this happens: there's a vertex at the top left of your image where the breaking happens, and let's label it V1, and it's connected to a vertex below it, so let's label that one V2, and there's a Bezier curve that connects them. When you introduce the eraser tool (which is a new circle object that also consists of vertices) and intersect it with the object, you are creating new vertices, so for easier understanding let's say 2 new ones, V3 and V4. As a result, instead of new vertices V3 and V4 being connected and creating a Bezier curve between them, connection at V1 breaks, a new connection is created between V1 and V4, also between V2 and V3 thus splitting the object in two, and also creating a Bezier curve as it was their last state.
The best way to approach this problem is to create 2 new states for each vertex:
- is a vertex being deleted cause intersection happens where the vertex is, and 2 new vertices are created and connected thus eliminating the first one,
- if the intersection doesn't happen where the new vertex is, newly created vertices should be connected to the nearest left, between themselves, and nearest right, following the edge of the object. Proposed solution
This is just a rough idea on what's going on and what the solution may be. I hope I helped.
Sometimes I have to merge vertex when they are separated by very small interval, otherwise I got algorithmic issue... (like never ending loop calculating approximate intersection)
But when I merge the intersection above, they become a touch.. i.e. the merge point is NOT an intersection anymore.. but I dunno it, all I know (at the moment) is a point with 4 line convergent on it, must be an intersection, right?
I have to take that into consideration! Woa,.. good find.. will implement that later!
(got othe rthings to do! )
At this stage I am not interested in reading other people's code! ^_^
And I need the (working) algorithm in my .NET app.. I would be interested in a .NET C# library manipulating geometry.. But I can't find any..
(the only one I know is some GIS I forgot the name, and they only deal in polygon, not shape and their API is convoluted...)
A slight misunderstanding.I wasn't talking about the code but the understanding of behavior of editable spline objects and their properties, i/e axis orientation of vertices within the spline (where during intersection X and Y axis can be swapped), managing direction of IDs (i/e clockwise vs counterclockwise on a circle), and welding function (which, as the name says) welds two vertices into one using the area concept (maximum allowed distance between two vertices so no unwanted vertices get welded), for the purpose of avoiding problems like the one you encountered, which are quite common in the world of 3D graphic. For the past 23 years of my experience with CAD and 3D software I have seen my share of weird things, and I have an understanding that I thought might be useful.
Basically, I am trying to point you think in the right direction, nothing more.
To be fair I had trouble understanding your explanation...
I think I found the fix (while day dreaming during latest work meeting just now)(this is for a pet home project).
Each intersection vertex need a bool Crossing flag.
When I merge 2 vertices (because of close proximity), crossing should be updated with an Xor of both values.
A, I see, this is exactly how it works and what I tried to explain. Boolean Crossing is the function that counts vertices (initialize), labels them, determines the intersection (input), determines which object "cuts" which (direction) and executes crossing by creating the new object. Here's a graphic representation of what I tried to explain, even now it's not so important, and here's the "disappearing" vertex example. XOR (I believe) deals with the very issue.
I'm glad the solution was so simple, I'm not a programmer (at least I don't dare call myself one) so I wasn't aware of the existing classes and functions, that'd save us a lot of talk. Oh well, at least you got a visual representation of how it works and a better understanding.
So, voodoo exorcised!
Keep it goin' and have fun m8
It happened to me once and i had a too long time to discover the problem.
i was using ADO.Net, and connecting a textbox.text to a field in the table, and that field is int16, and i was trying to save into it an int64, and while the number value is small, but still, the textbox did not have its text changed, it always stayed a null.
after the yoricka came , i changed/or casted the int64 to int16, and it worked.
so, check if there is a conversion happening here or there.
May god give u good health and knowledge.
I think I get it ... (since it's gonna be hard to fix I left the fix (test) to later)
When I merge 2 intersection close to each other (for numerical reason), sometimes the resulting point is not an intersection (despite having for segment attached to it) but just a touch...
9 times out of 10 this type of issue is related to only a few of things. 1) Something isn't being properly initialized (especially common in loops; where do you initialize/reset conditions) 2) you are calling routines and not careful about parameter passing (value vs reference) 3) You've an error that for some reason is "swallowed". My first week on my current job I added an Unhandled Exception Handler to a troublesome Windows Service. It was very enlightening. 4) the Context has changed between your calculation loop and the validation (have seen issues with the same name used in different namespaces and the code was actually executing 2 different code sets)
This are a bear to track down. Often the best way to find the bug is swallow your pride and get a junior person to sit with you and explain your code to him. The 2nd set of eyes, rethinking the code as you explain it and sometimes "dumb" questions will highlight your problem. I ate crow recently after swearing my code was solid and it "had" to be a data issue, a code review with a person my junior caused me to spot the bad code I had passed over 100 times while trying to fix the bug.