First of all, I would like to congratulate the developers for creating a very cool tool. I experimenting with different flexible models and I got good results from the gyroid infill with TPU material. The attached picture shows a child’s shoe that I designed and the sole was made in the above-mentioned way. The problem is that if I try to make a similar g code with a slightly larger model (I am experimenting with fully 3D printed shoes as well), the slicing is very slow and or freezes. I tried different browsers (including browsers specifically designed for gaming) and settings.
Regardless of the power of your PC, the browser sandbox usually limits memory usage to under 4GB. Gyroid infill is very memory and cpu intensive to compute. Can you try triangle, grid, or hex?
Hi, thanks for the answer. The situation is that for the appropriate flexibility in all directions, the gyroid infiill is the right one for this type of models. Yes it is likely that the browser’s allocation is causing the problem in terms of memory because the machine has a lot of memory. I will try other browsers and browser settings as well. Thank you.
Hi I tried out it in Opera Gx browser (A gaming focused browser) where the ram limit in this case is 64gb and while slicing the ram usage never exceeds 1.5 gb.
Hi. This thing can be recreated easily. I scaled up the default object five times and set the infill to gyroid and Fill Amount to 0.8. And same thing happening.
I have to mention that for some reason I got better printed results with the Kiri Moto Slicer than with other slicers on flexible models that don’t have walls and are made only of gyroid infill. And it would be nice if it worked with larger volumes as well.
Given the way I wrote the KM infill subsystem and in particular the gyroid fill, higher densities are very computationally expensive. I don’t have any quick fixes for this. I don’t know how prusa or other slicer’s do this computation faster. But perhaps because they are written in C they can take advantage of SIMD and other cpu native speedups.
Yes, I understand that since you are working in a higher-level development environment, you don’t have as much freedom for low-level things. Maybe memory isn’t the bottleneck? I checked and, the CPU usage is around 8 percent while the process is running. Maybe you could check why the process isn’t using more of these resources (CPU and RAM) when the environment (hardware and the browser) maybe would allow it.
If you have any option to do so in the environment in which you are develop in.
chrome performance monitoring tools only shows the CPU usage associated with the main UI thread, not the workers. those are pegged at 100% but you can’t see that in the browser.
Hi. I just checked the processes in task manager while the slicing process was running and for some reason it doesn’t seem to be using that much resources (cpu and ram).
how many cpus do you have? the worker thread that is doing the infill will peg one cpu. it’s not multi-threaded. so if you have 10 cpus, that’ll show up as 10% cpu load.
having said that, I revisited the code for the first time in a few years and there is significant room for improvement. I can speed up the single threaded performance as a square of the infilled area. multi-threaded coding is a heavy lift given the current architecture.
I’ve improved gyroid performance in the 4.1 beta branch. Hover the KM center menu and choose version 4.1 then shift + reload the page and test. The current beta version is 4.1.0.-D3
