libera/#shirakumo - IRC Chatlog
Search
23:42:48
paulapatience
Shinmera, seeing as you have wrapped several C libraries that I can see, I was wondering if you ever encountered situations where a library keeps a pointer to one of the user's structs and requires it to stick around. How did you deal with such situations?
23:43:16
paulapatience
Basically I'm wrapping an FEM library with Clasp, and the library I'm using often relies on this
23:43:46
paulapatience
For example, if I create a FiniteElementSpace, I need to give it a pointer to a Mesh, but it doesn't take ownership of it or anything
23:44:14
paulapatience
And Clasp would free the Mesh pointer if the garbage collector gets to it because it's not reference anymore on the Lisp side
23:44:49
paulapatience
I would prefer not to require the user of my library to keep track of what needs to be kept in scope, because that's not what you usually have to do in Lisp
23:45:52
paulapatience
What I've settled on for now is wrapping each C++ class in a Lisp class. The Lisp class has a raw slot for the pointer to the C++ class (wrapped in some kind of std::unique_ptr by Clasp), and another slot where I can dump references to whatever needs to be kept around
23:47:05
paulapatience
But say for instance I request a Cell from the Mesh. In this library, the Cell getter returns a pointer to the Cell, and obviously the Mesh has to stick around until I'm done using the cell
23:47:52
paulapatience
So I would need to instantiate a class for each cell I access, which can get into the millions for large cells. It seems wasteful when iterating over the cells of a mesh.
23:48:12
paulapatience
Anyway, I was wondering what your experience is, and if you might have any thoughts.
23:50:36
paulapatience
By the way, I will likely use at least parts of your manifold library, as for the first objective of my PhD I wrote a mesh generator in Common Lisp. Incidentally, I ported a C++ implementation of CLOSEST-POINT-ON-TRIANGLE, and I did spend the time factoring out the common subexpressions (there is a comment to that effect in your code).
23:52:13
paulapatience
I also will likely use cl-gltf. I don't know if it interests you for your game engine, but I have also written parsers and emitters for various mesh formats (so far STL, OBJ, PLY, OFF, only parser for VTK), and intend to add more.
23:57:30
paulapatience
I ported the C++ library TriangleMeshDistance to be able to calculate the SDF of a triangle mesh (that's where I ported the CLOSEST-POINT-TO-TRIANGLE function, though presumably its implementation is based on the standard algorithm), and it uses a sphere-based bounding volume hierarchy. I was curious to try different algorithms to use the fastest one, as I would like the computation to be as fast as possible.
0:01:09
paulapatience
One more thought on iterating over mesh cells: if making instances of cell classes is too costly, another option I considered is to allow the user to iterate over the raw pointers only, so no need to call make-instance. That would be the escape hatch I guess.
6:07:43
Colleen
<shinmera> I'm interested in more formats, though for obj I also already wrote a library
6:09:34
Colleen
<shinmera> As for the GC question... there's no way to "keep it under wraps", I'm afraid. The lack of GC will leak somehow. In all my wrapper libs there is a manual FREE call to dealloc stuff, and in Trial I frequently complain about how much I hate my loader system that is supposed to manage that part.
6:10:29
Colleen
<shinmera> For the cells in particular, I assume there is some kind of delimited extent to their lifetime, though, right?
6:11:25
Colleen
<shinmera> For instance, I don't see it really happening that you keep a ref to a cell, but not also the mesh
6:12:34
Colleen
<shinmera> You could lock the cell access behind a macro that forces a reference around the block. Eg: (defmacro with-cells ((mesh) &body body) `(let ((,meshg ,mesh)) (flet ((get-cell (..) ..)) ,@body)))
6:13:43
Colleen
<shinmera> Feel free to submit PRs to extend manifolds, since it's a toolkit it would be nice to just have, well, more stuff in it
9:03:18
paulapatience
Where did you put the OBJ library? I was wondering for my own parsers if it would make more sense to have a single library for all the formats, or one library for each.
9:05:21
paulapatience
My parsers I actually wrote to be as fast as I could possibly get them, so the code is actually not very nice to look at, but I could just make them conform to however you wrote them when submitting PRs.
9:09:10
paulapatience
(For example, my first STL parser was slower than meshio's, which is written in Python, and I couldn't believe it... until I looked at the Python code and saw that they just skipped parts of each line and treated it as something like a CSV file. So basically I parse only what's absolutely necessary for my mesh objects and ignore the rest, so my parsers will gleefully accept invalid
9:13:11
paulapatience
For calling free at the end of your wrappers, what is wrong with adding a finalizer for it? Unless the libraries also initialize other resources than memory, like file handles, etc.?