I’ve been having this issue for a while now. Sometimes when trying to free move model it either won’t move, or move incredibly slowly and then just stop. The only way I have found to stop it is just deleting all the models and starting over. Seems to happen more often with more models on the workspace. Happens on all available builds.
Hi @bh51512. Can you tell me a little about your setup? What’s the browser / OS? How many models do you have on the platform? Also, which mode are you using? FDM, CAM, Laser, etc?
Just a bystander’s thought:
This might be an acute instance of something more chronic than specific to free moving models on the workspace.
It seems like KM’s UI burns a lot of cycles spinning on something that probably wasn’t intentional. Moving the mouse pointer around is usually so automatic that it happens below conscious awareness. IME when the pointer passes over a KM window, it gets “heavy” and sluggish, which continues for a noticeable moment after passing out of the KM window - like there was still a queue of events to clear. Possibly @bh51512 has found a case where that escalates badly.
I’m using chrome with too many open tabs on windows 10 on a crap old laptop – which maybe helps to expose a suboptimal behavior that otherwise goes unnoticed.
It’s a minor nuisance very far down my list of things to care about.
I don’t see anything like that when using a mouse with a mobile browser.
KM is a very intensive WebGL application. I’ve spent a good deal of time optimizing performance through object compaction and other interactive elements. For example, KM pauses GPU rendering if you stop interacting with the interface for 1.5 seconds. Right now in 2.3 there are two render modes: 3d paths and lines. In 2.2 there are 2d paths and lines. I’m going to re-introduce 2d paths in 2.3 before it becomes the next production release. This will afford 3 levels of GPU compute complexity so you can select the one that feels comfortable for your hardware.
When the KM interface stutters, it’s usually not because of a GPU processing backlog. KM won’t schedule another frame until the previous one completes. Some frames just take longer to compute. Reducing object complexity is the only viable route to better performance.
It’s possible in the case @bh51512 is reporting that KM is caching some data and not letting go. That would cause the browser to slow down because of memory pressure. This is something on my todo list to look into.
Windows 10 latest build, happens in both Firefox and Chrome. i7-4770k, 8GB ram, Nvidia 970
Using for CNC, anywhere from 1-20+ models. I have a V1 Engineering CNC set up to 24x48".
The issue happens more often with the more models I have but still happens even with a few.
I have noticed that if I just let KM sit for a few minutes it sometimes gets better. If I clear all models on the workspace and re-add them that fixes it until it decides to do it again.
@bh51512 can you use the new profile -> export feature with include workspace checked and email the resulting .b64 file to me? sa@grid.space
I’ll try to replicate here.
thanks
1 Like
Looking at the workspace and settings you sent over, it’s clear what’s going on. Contouring is by far the most memory and cpu intensive operation in KM. Memory usage is roughly (area * (1/tolerace)) while processing time is (mem * tool_diam^2). In your workspace, you have a large number of large pieces, all being contoured.
These are flat parts, so I’m not if there is a benefit to using contouring. I would suggest instead enabling an offset stock then settings z top offset to something like 1 which will force the roughing operation to clear the surface. This is both faster and more efficient.
in the D14 release tonight, clear faces under roughing will also clear the top of the part, eliminating the need to play games with stock and z top offset
The heavyweight rendering doesn’t seem to be a problem. That’s in line with that I’d expect from my hardware.
The mundane 2D UI stuff really bogs down for me. Example: I can roll the pointer down the column of ‘settings’ category buttons. Then the mouse-over-button highlights roll down the column – about a week later in computer time. While KM is otherwise idle. Contrast with rolling the pointer across >20 open browser tabs: tab highlighting tracks the pointer very closely.
To me it smells like some incidental function burning several orders of magnitude more cycles than necessary for some reason that will be trivial when discovered – and like maybe Brandon has found a way to aggravate that.
Oh - at hazard of meddling: I think Brandon was talking about something different.
More UI interactivity than slow slicing.
And now thread hijacking: “clear faces” was a helpful addition, thanks for that.
So far, I’ve been happy to use it with material that already has a clean top surface that I’d like to leave as-is. So I’d like an option to clear faces not including the top surface.
I’ve replicated the problem. It’s a simple bounds issue. If you increase the workspace of your device so the parts are hanging off, they move freely. I’ll see what I can do to make this more intuitive.
At present, if any part is hanging off the platform, it messes up all drag operations. This was to prevent dragging objects beyond the bounds. But if the object is already outside the bounds, it’s broken.
will do. another checkbox coming.
1 Like
@bh51512 Brandon, the move issues should now be resolved for parts that were outside the platform boundaries. Please confirm this is working for you when you get a chance.
thanks!