search

sesopenko / VoronoiLib

C# implementation of Fortunes Algorithm. Includes MonoGame example
MIT License
0 stars 2 forks source link

Close cells that hit the edge of the enclosing diagram area. #7

Closed rurounijones closed 1 year ago

rurounijones commented 2 years ago

Close a site's cell by creating closing VEdge when the cell would otherwise be left open due to hitting the edge of the enclosing area of the voronoi diagram.

  1. If the cell has two VEdge that hit the same boundary (e.g. Top) then a new VEdge is created connecting the two along the boundary.
  2. If a cell has two VEdge that hit connected boundaries (e.g. Top and Left) then two new VEdge are created linking the existing two VEdge to the shared corner.
  3. If a cell has two VEdge that hit opposite boundaries (e.g. Top and Bottom) then three VEdge are created linking the existing two using the closest two corners

The VEdge running along the boundary will be null for either its Left or Right property as there is nothing outside the boundary.

RudyTheDev commented 2 years ago

2. If a cell has two VEdge that hit connected boundaries (e.g. Top and Left) then two new VEdge are created linking the existing two VEdge to the shared corner.

A site can have 4 boundary edges too. Hitting connecting boundaries can mean either, for example:

bound 4

rurounijones commented 2 years ago

This fork also appears to be dead, which is a shame, so I have stopped working on things related to this and have forgotten most of the context so am not actively looking at this.

RudyTheDev commented 2 years ago

This fork also appears to be dead, which is a shame, so I have stopped working on things related to this and have forgotten most of the context so am not actively looking at this.

I have been working from https://github.com/rurounijones/VoronoiLib/tree/cells. That seemed to be the "newest" version.

Are you using or updating another fork or your own or none at all? I am not sure where I would submit pull requests or if there even is any maintained fork. I would prefer not to make yet another fork-but-not-really repository.

rurounijones commented 2 years ago

I have been working from https://github.com/rurounijones/VoronoiLib/tree/cells. That seemed to be the "newest" version. Are you using or updating another fork or your own or none at all? I am not sure where I would submit pull requests or if there even is any maintained fork. I would prefer not to make yet another fork-but-not-really repository.

Unfortunately that is my fork that only existed as a source for merging into this fork; which was the most active one at the time and had an associated nuget package. My fork does not have a nuget package and I lack the knowledge to maintain it.

My recommendation would be that you use this @sesopenko fork or create your own.

sesopenko commented 2 years ago

My recommendation would be that you use this @sesopenko fork or create your own.

This one has working unit tests using a more common testing library, so it's easier to fork from than the original creator's lib. If anybody wants to be added as an admin of this repo, I'm totally up for sharing the load of managing PRs.

RudyTheDev commented 2 years ago

This one has working unit tests using a more common testing library, so it's easier to fork from than the original creator's lib.

I did indeed use this fork as the base mostly because of NUnit and because the original fork seems dead.

If anybody wants to be added as an admin of this repo, I'm totally up for sharing the load of managing PRs.

I could probably do that, at the very least do some quick bug fixes for this.

I guess a bigger question would be as to what are your plans for this fork? I have now made a lo-o-o-ot of changes on my end. I assumed this fork wouldn't be active anymore (since it has that unmerged cells PR, which was kind of critical to working with the result). So I went completely ham on the codebase without really considering merging anymore (or the original code style or layout). Ideally, I would just bring all my changes when ready, but this means the whole project gets restructured. I am using this library in an ongoing project, so I will maintain it and fix any issues regardless, but I cannot keep up with 2 forks. I will upload my change to my fork at some point and we could decide if you would rather merge or not?