-
Notifications
You must be signed in to change notification settings - Fork 336
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
Voxillization creates errant geometry #59
Comments
Do you know whether the geometry is watertight? Pure speculation, but (especially) CAD models from the internet often contain (probably even microscopic) holes or missing triangles. The geometry might look good, and some software programs might be able to deal with that, but for something like that might throw off the voxelization process. For “classical” meshers for FVM CFD, geometries usually must be completely watertight and often need a lot of preparation (if you don't yourself control the source CAD file) before the meshing works. |
This model has been fine for me in an OpenFOAM setup, presumably it should be fine here? There's a Zip of the STL in question in the OP (or click here: https://github.com/ProjectPhysX/FluidX3D/files/10855164/RB18_alligned.zip) GH doesn't accept raw STLs, but in this case it's the single STL in the ZIP |
@FCLC the stl mesh must be watertight for the voxelization algorithm to work properly. I've built in some failsaves for non-watertight meshes, but they aren't perfect. If you can't get the mesh watertight, to at least reduce artifacts, in this case you can override the voxelization ray direction to z-direction by inserting "direction = 2u;" between lines 224 and 225 in src/lbm.cpp. |
Can you try with lower mesh resolution? Could be an issue with very small triangles and floating-point accuracy during Möller-Trumbore. |
@FCLC yes specific single points can be problematic, when a ray crosses exactly on the boundary between two/multiple adjacent triangles. I've already implemented it mathematically clean as ">=" for lower and "<" for upper boundary on the intersection plane, but sometimes it still counts none/both triangles, and this will trigger an artifact column where inside/outside states are inverted. Probability of such edge/corner hits is increased when the triangle mesh is very fine compared to grid resolution, so either reducing mesh resolution or increasing grid resolution should help. I"ll think about how to further harden the algorithm to be more robust in such cases. Thanks a lot for your help! |
Sounds good! I'll close here. Also maybe worth mentioning: For some usecases, especially on "consumer" cards that don't have much VRAM, being able to maximize based on your hardware could be useful. Another small usability idea would be to allow zooming in and out using the + and - keys (either only through the numpad or also via the keys on the main part of the keyboard ). Idea is to be slightly less cryptic than the current |
@FCLC great suggestions, thanks! Will implement +/-. The L=automatic is a bit more difficult, but I can auto-rescale the box to 95% mem with a warning print if the input is too large. |
Other idea: showing what interactive rendering modes are active along side the simulation statistics? |
Hi Moritz,
Following up on the post from mastodon, I wanted to point out a potential bug. Specifically during the voxel creation phase when converting an STL mesh, the converter seems to be creating "fake" geometry.
Example of behaviour:
I'm running the latest version
The file in question is:
RB18_alligned.zip
And the code being run is:
setup.zip
The text was updated successfully, but these errors were encountered: