kurbo
geogram
kurbo | geogram | |
---|---|---|
5 | 9 | |
649 | 1,610 | |
3.2% | - | |
7.8 | 9.5 | |
15 days ago | 3 days ago | |
Rust | C++ | |
Apache License 2.0 | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
kurbo
-
Voronoi Diagram and Delaunay Triangulation in O(nlog(n)) (2020)
The numerical robustness thing gave me a chuckle (rotate 1 radian and pray to the geometry gods), especially as I've been spending a good fraction of my time dealing with that in fancy path rendering and stroking.
One of the things I really want to work on in the next few months is a path intersection implementation that's robust by construction, backed up both by a convincing (if not formal) argument and tests crafted to shake out robustness issues. I have a bunch of ideas, largely motivated by the need to generalize well to curves - Shewchuk's work, cited elsethread, is impressive but I'm not smart enough to figure out how to make it work for arbitrary Béziers.
There's an issue[277] to track the work, and that has pointers to some of the ideas. If anyone is interested in working with me on this, please get in touch. If successful, I think it'll result in a nice code base and also likely a publishable paper.
[277]: https://github.com/linebender/kurbo/issues/277
-
Announcing Bezier-rs: computational geometry algorithms for Bézier paths (seeking code review and boolean ops help)
I have some ideas on how to do boolean ops, some of which is written up in a blog post issue, and for which I have some code locally. In particular, the parabola estimate seems much more efficient than the usual fat line approach. I also have a sketch of quadratic/quadratic intersection in kurbo#230.
-
Bit Twiddling Hacks (2005)
I love these kinds of things and use them in GPU programming, among other things. Things have changed in a variety of ways: population count and count-trailing-zeros are generally available as fast instructions now. Multiply is also now just as fast as other operations, so is not to be avoided.
A couple examples. [1] computes the sum of the number of bytes used of four consecutive segments of a bezier path - each segment can be lineto, quadto, or curveto, can be the end of a path or not, and be i16 or f32. 4 tag bytes are packed into a 32 bit word, it computes all these, then sums them together.
[2] linearizes a recursive subdivision into an iterative loop. The stack depth is represented as the number of zeros in a word, so pushing the stack is a left shift, and popping is a right shift. It turns out you want to pop multiple levels at once, and the number of levels is computed by countTrailingZeros. ([2] is experimental Rust code, but I will adapt this into a compute shader)
[1]: https://github.com/linebender/piet-gpu/blob/main/piet-wgsl/s...
[2]: https://github.com/linebender/kurbo/blob/euler/src/euler.rs#...
-
A Review of the Odin Programming Language
That's a reasonable choice and I do agree it has nice properties, for example (a << b) << c is equal to a << (b + c) (unless that latter addition overflows), but it also does put you pretty firmly in the category of "not squeezing out every last cycle like you can in C." Usually that's one of the the things people expect in a tradeoff involving safety.
Regarding "never," I am an adventurous programmer[1], so am fully willing to accept that I am the exception that proves the rule.
On the more general point of UB for arithmetic overflow, I think we're on the same side: this is a pretty broken story in the way C has ended up, and one of the clear motivations for a cleaned up better-than-C language. I'm more interested in your thoughts on data races, where I suspect we have a substantive difference in perspective.
[1]: https://github.com/linebender/kurbo/blob/de52170e084cf658a2a...
- Kurbo: A Rust library for manipulating curves
geogram
-
Voronoi Diagram and Delaunay Triangulation in O(nlog(n)) (2020)
Interesting question! By virtue of being a tree, the MST produces at most 3 edges coming out of any vertex, so this should be the same in 3D. The MST then adds (sometimes) a 4th edge, so, although you could build both graphs in 3D space, you would still end up with 4 edges coming out of any vertex, I think.
In 3D space the Delaunay triangulation would produce a bunch of irregular tetrahedra, so the edges coming out from every vertex would vary between a minimum of 3, and a maximum of 12, if I get it right (ref: [1] :-).
The 3D Voronoi cells are another story... I found some implementation that you can play with to see how it looks [2] [3], each cell is of a shape called "convex polytope". It feels like these cells are packed like each of the sub-cubes of a rubik, but I'm not 100% sure :-) ... if that's true, you could jump from each vertex to the next in at most 17 directions? (hand-waves :-p)
--
1: https://en.wikipedia.org/wiki/Tetrahedron#/media/File:M_tic....
2: https://github.com/BrunoLevy/geogram/wiki/Delaunay3D
3: https://math.lbl.gov/voro++/examples/
-
Photogrammetric point cloud to mesh
Geogram, it has some pointsets to surface functionality : https://github.com/BrunoLevy/geogram
-
Geogram: Programming Library with Geometric Algorithms
Thank you very much for this feedback, it is super useful. Do not hesitate to post this type of comment to geogram's github (https://github.com/BrunoLevy/geogram/issues)
Please note that the Logger mechanism can be redirected to a GUI, it is used for instance in the GUI applications made with Geogram (https://github.com/BrunoLevy/geogram/wiki/Applications) and in Graphite (https://github.com/BrunoLevy/GraphiteThree)
About using std::string as path under Windows, I understand that it may cause some problems with users who use general characters in their directories, but it does not prevent the application from running and from loading/writing files. In the future, when std::filesystem is well standardized, I plan to get read of my FileSystem implementation.
- Geogram: a programming library with geometric algorithms
What are some alternatives?
unity-delaunay - A Delaunay/Voronoi library for Unity, and a simple destruction effect
unity-quickhull - An implementation in Unity of the Quickhull algorithm for generating 3D convex hulls
GraphiteThree - Experimental 3D modeler
femton - Image manipulation via triangulation
fTetWild - Fast Tetrahedral Meshing in the Wild
Experiment - Under-development functionalities for Graphite/Geogram
geometrize - :white_square_button: Geometrize is a desktop app that geometrizes images into geometric primitives