CSG: Add new primatives: Triangular mesh, Voxelised Grid
fraseyboo opened this issue · 3 comments
I've been working on some more complex primitives that work within your CSG that might be of use for some users that have complex detector geometry that is hard to define implicitly. The detectors I've been simulating are for AGATA and as such are asymmetrical large-volume HPGe crystals with complex segmentation.
I struggled to create a good representation using your constructor so I wrote a primitive that can take any triangular mesh as an input (e.g. a standard stl, obj or ply file) and evaluate to the same level as your other primitives. The approach uses a generalised winding number for robust in-out segmentation. I've tested it with some simple geometry and it looks fine.
Here's a simple PoC using a modified version of your example, simple_mesh_simulation.pdf
Plotting works too however the 3D electrode plot takes some time to crunch through. Unfortunately for anything too complex the execution time and memory usage will crash the computer before completing, I've tried multithreading it but it's still too slow.
To solve this issue I decided to pre-evaluate the geometry on a voxelised grid and use that logic for geometry validation, the static nature of this method could limit spatial resolution however with small enough voxels I imagine true physical effects will be the limiting factor. Currently voxelisation is done externally in Python however I can likely implement a similar solution in Julia effectively using the code for the mesh primitive mentioned earlier.
Voxel evaluation is done on a regular grid to help speed up indexing, the approach works well however I'm not confident that the 'interesting' points are being properly passed. It's likely I can combine the two primitives to take in a standard mesh, voxelise it and determine the interesting points and then give that to the CSG.
Hopefully some of this is interesting to you.
Nice to hear from you again :)
This looks indeed very interesting. I don't know whether you followed our issues of SSD on GitHub,
but we are currently working on the refactoring of the CSG (#110). Including adding rotation and stretching of Primitives.
So you might be able to implement your detector geometry with our CSG soon.
Indeed, we are also interested in loading geometries from files like .stl, .obj,... in the future.
It would be really nice if you could provide a Julia environment Project.toml + Manifest.toml
with all the dependencies and their version which you used.
I looked into the pdf and I believe you are using some older packages
(e.g. GeometryTypes instead of the new one GeometryBasics).
It would also be nice if you could give us your notebook file and the config files as well.
So it is easier for us to have a look at what you did.
I already told @hervasa2 about your PR #41 and especially about your implementation of your winding number algorithm
as he currently started looking into surfaces and meshing for SSD.
I think it's been about a year since we last talked, it's nice to see this project is still actively being developed. I saw CSG (#110) and figured I should probably put in a proposal for these primatives before everything gets finalised. My apologies for not fixing my pull request back then, I had to focus on the main topic of my PhD (Pulse Shape Analysis methods for AGATA) and so my side-projects got neglected.
I've attached a zip of the build of SolidStateDetectors I'm using, I've only modified the files in VolumePrimatives but figured it'd be useful for completeness.
I've attached zips of the directory structure I'm using for both the mesh winding number and voxel grid methods, I haven't checked how absolute paths are interpreted though so there'll likely need some tweaking. I wouldn't recommend trying to run the AGATA mesh example unless you have a pretty powerful PC, it locks up my rig (i9, 32GB RAM) after a while. I'm not sure if that's an inherent issue in my code though. I switched to using a .jl file rather than a notebook as I thought that was causing the system thrashing, unfortunately the issue still persists.
I will close this. We refactored our CSG and now need the normal vectors of the surfaces of the geometry
in the drift of charge carriers (along surfaces). Thus, the in method alone is not sufficient anymore.
However, all primitives can also be translated and rotated now. So also your complex geometry could be configured in principle.