-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Final edge in VoronoiSite.ClockwiseCell is randomly backwards #6
Comments
Correction: it's all edges, I misunderstood the .ClockwiseCell - it doesn't supply the edges in clockwise winding, it supplies them in the order as if they were clockwise, but their directions are still random. Need a second pass to fix their directions to give an actual winding. |
Ah, I see. I was wondering what sort of edge case I was missing because I check But yes, You can see that "clockwise" actually depends on the edge's position relative to the cell. And I can't really change start/end points once they are assigned. You are probably wanting to use May be there is a nicer way I could be returning this, although I am not really sure. I guess I haven't implemented getting edges from a point yet, so following along points doesn't let you "look back" at the edges. |
Yep, if you're working with 3D meshes I don't see a way around this - every
triangle must by definition have the same winding order, all
processing/algs will break otherwise - so it's normal to make sure the
triangles are all 'correct' at the start of processing.
Points 'works' but discards meta information, meaning we lose a lot of the
value of Voronoi in the first place (and would have to manually reconstruct
it, e.g. by calculating neighbours).
My current workaround is a 10 lines piece of code that iterates through the
edge list after I've extracted them from the lib, flipping edges that are
incorrect, until they are all in the same CW direction. Works fine.
…On Sun, 5 May 2024 at 20:36, Rudy ***@***.***> wrote:
Ah, I see. I was wondering what sort of edge case I was missing because I
check ClockwiseCell in unit tests extensively.
But yes, ClockwiseCell returns the edges in an order where one follows
the other logically, but does not guarantee any order for each edge's
start/end points. I guess the simplest explanation is to think what
direction is the middle line supposed to go to be considered clockwise for
both cases:
clockwise.png (view on web)
<https://github.com/RudyTheDev/SharpVoronoiLib/assets/3857299/99cc1971-34b5-4cf5-b033-e6a84014b4f7>
You can see that "clockwise" actually depends on the edge's position
relative to the cell. And I can't really change start/end points once they
are assigned.
You are probably wanting to use ClockwisePoints if you are trying to wind
around the cell.
May be there is a nicer way I could be returning this, although I am not
really sure. I guess I haven't implemented getting edges from a point yet,
so following along points doesn't let you "look back" at the edges.
—
Reply to this email directly, view it on GitHub
<#6 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACHL6OLWCEBZOOKXKVPVF3ZA2C2HAVCNFSM6AAAAABHH6CNGWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJUHEZDGOBVHA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Approx 50/50 chance of this happening, that when requesting .ClockwiseCell, the Edge instances I get are all correct except the final one, where Start and End are reversed.
Guess: the code for ClockwiseCell has an out-by-1 error and is failing to reverse the final edge, so its a matter of luck whether the edge was already clockwise before the conversion took place.
The text was updated successfully, but these errors were encountered: