-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Nightly Build Crashes During Render of Complicated Object #5069
Comments
The help output shown does not have Manifold enabled (it would show up with a trailing asterisk
(I've edited the original post for code formatting) |
Having 180*360 points on your spike ball is quite a lot. Testing here, this easily exceeds the RAM on my machine of 16GB. Even 180*45 is enough to crash for me. Watching the memory usage with a task monitor i can see it spiking up before the crash. I don't think there's a bug here unless manifold is possibly using more RAM than expected. (Hard to say what RAM requirements should be for a problem of this magnitude) |
Here is one way to workaround, which I just managed to do:
|
You don't even have to create a separate file: Just wrap the partial theta sweep in a |
Anyway, I think we can close this as an expected OOM crash, Edit: Actually, I think this is a symptom of a real issue, possible related to Manifold caching not being fully implemented (cache object always measure zero bytes). That, combined with pairwise unions, we may be setting ourselves up for unbounded memory allocations. |
@pca006132 I think this may be a good illustration of why we want elalish/manifold#764 to be addressed. |
another thing is that manifold is not really optimized for memory usage. |
Parsing design (AST generation)... |
Interesting, maybe someone can use gdb to see what is causing it to crash? |
I am not entirely sure why it crashes for you on windows, but it is definitely running out of memory for me on Linux. I think maybe in your case it is already paging out, and the OOM killer decided it is using too much memory and kills it. |
To help illustrate where I think all the memory goes:
FYI: I'm working on optimizing the binary tree building part of this (exploring Manifold's batch mechanism), but the unbounded cache still needs addressing. |
In addition, the cache will make manifold unable to flatten the tree internally because it thinks that the node may be reused in a different part. This is why I said caching may cause performance issues and we probably want a better cache policy. |
Right, as a start we probably shouldn't cache nodes that are not actual OpenSCAD nodes (like intermediate nodes in a binary tree described above). |
Looking more closely at this, I think this will run OOM even if we disable the cache and remove don't run it in multiple threads, but ideally we should be able to do better than this considering it is not really containing many points. The problem here is that those spikes often have large AABB, causing the collider to give n^2 pairs, which is bad in terms of memory usage as well as running time. Wonder if there is something we can do here @elalish. Maybe we can have a fallback to boolean3 that process each collision pair one by one without getting the full collision array when there are too many collision pairs? Probably need to change quite a lot of stuff though. |
If the total number of intersections isn't huge, but the potential intersections is, then |
OpenSCAD nightly build OpenSCAD-2024.03.23-x86-64 with Manifold consistently crashes while attempting to render (F6) the attached complicated model after about 15 minutes.
To Reproduce
Attempt to render (F6) the attached model.
Expected behavior
Successful render or a graceful failure.
Code reproducing the issue
Environment and Version info (please complete the following information):
OS Name Microsoft Windows 11 Home
Version 10.0.22621 Build 22621
System Manufacturer Acer
System Model Predator PH315-54
System Type x64-based PC
Processor 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz, 2304 Mhz, 8 Core(s), 16 Logical Processor(s)
BIOS Version/Date Insyde Corp. V1.12, 6/7/2022
Hardware Abstraction Layer Version = "10.0.22621.2506"
Installed Physical Memory (RAM) 16.0 GB
Library & Graphics card information
OpenSCAD Version: 2024.03.23 (git 0ac066a)
System information: Microsoft Windows 11 (10.0.22621) x86_64 16 CPUs 15.77 GB RAM
User Agent: OpenSCAD/2024.03.23 (git 0ac066a) (Microsoft Windows 11 (10.0.22621) x86_64)
Compiler: GCC "13.2.0" 64bit
MinGW build: MingW64
Debug build: No
Boost version: 1_81
Eigen version: 3.4.0
CGAL version, kernels: 5.5, Cartesian, Extended_cartesian, Epeck
OpenCSG version: OpenCSG 1.5.0
Qt version: 5.15.11
QScintilla version: 2.11.2
InputDrivers:
GLib version: 2.70.2
lodepng version: 20210627
libzip version: 1.5.2
fontconfig version: 2.14.2
freetype version: 2.13.2
harfbuzz version: 7.3.0
cairo version: 1.16.0
lib3mf version: 1.8.1
Features: fast-csg, fast-csg-safer, fast-csg-debug, manifold, roof, input-driver-dbus, lazy-union, vertex-object-renderers-indexing, textmetrics, import-function, predictible-output
Application Path: D:/Downloads/OpenSCAD/OpenSCAD-2024.03.23-x86-64/OpenSCAD-2024.03.23-x86-64
Documents Path: C:\Users\red\Documents
User Documents Path: C:\Users\red\Documents
Resource Path: D:/Downloads/OpenSCAD/OpenSCAD-2024.03.23-x86-64/OpenSCAD-2024.03.23-x86-64
User Library Path: C:/Users/red/Documents/OpenSCAD/libraries
User Config Path: C:\Users\red\AppData\Local/OpenSCAD
Backup Path: C:/Users/red/Documents/OpenSCAD/backups
OPENSCADPATH:
OpenSCAD library path:
C:/Users/red/Documents/OpenSCAD/libraries
D:/Downloads/OpenSCAD/OpenSCAD-2024.03.23-x86-64/OpenSCAD-2024.03.23-x86-64\libraries
OPENSCAD_FONT_PATH:
OpenSCAD font path:
C:/WINDOWS/fonts
C:/Users/red/AppData/Local/Microsoft/Windows/Fonts
C:/Users/red/.local/share/fonts
D:/usr/local/share/fonts
D:/usr/share/fonts
D:/usr/X11/lib/X11/fonts
D:/System/Library/Fonts
D:/Library/Fonts
C:/Users/red/Library/Fonts
GL context creator: WGL (old)
PNG generator: lodepng
GLEW version: 2.1.0
OpenGL Version: 4.6.0 - Build 30.0.101.1273
GL Renderer: Intel(R) UHD Graphics
GL Vendor: Intel
RGBA(8888), depth(24), stencil(8)
GL_ARB_framebuffer_object: yes
GL_EXT_framebuffer_object: yes
GL_EXT_packed_depth_stencil: yes
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: