- Performance in the UI is unworkably slow in large files whenever I make any edits. It locks up for minutes at a time. CPU usage is 1%, and memory use is very small. The preview doesn’t even begin–just the wire connection step locks up. This happens whether I’m previewing 2 nodes into my graph or the final mix.
- This happens on every edit in my larger files. It did not happen on earlier World Machine versions.
- Unfortunately I cannot share my file, but I did find this post reporting the same thing in the Help section: Best practices to improve performance working with big files - #2 by rsalvatore
Just updated to the latest WM and my projects are now painfully unresponsive. Can’t even use the shape editor.. time between selecting shapes and vertices measured in multiple seconds. What has happened?
Hmm. I’m definitely interested in more information to track this down - it’s certainly not expected behavior, so I don’t have any good workaround suggestions yet.
If you have a world file that demonstrates this problem that you can send to me at support@world-machine.com so I can investigate this behavior, that would be great.
+1 very slow ui with large files. I’ve noticed that the preview on the bottom right will trigger when making changes. Also I recall something about macros being an issue? I use a lot of them.
I also can’t share my files in question. @Stephen if you’re still waiting on a file I can slap something together on my personal setup.
@MP77, yes, that would be very helpful. I can try to investigate here without a repro, but it’s a much faster and more direct line to a fix if I have an example of the problem.
In my case, it doesn’t seem to be the Preview being the direct cause, at least.
Example, I just selected a shape generator that’s right at the start of my graph, locked that as the mini-Preview, then re-attached a wire to a node 5 or 6 steps in from that. That operation just took about 45 seconds. No automatic preview was running and I don’t even have a View window open other than the node graph.
I then turned on the auto-Preview at 1024 resolution (this file is currently set to 8192), locked the preview to the last node in the graph, and moved a wire near the end of the graph to bypass a small blur modifier and it just took about 90 seconds to complete the wire connection before the UI became responsive. The Preview didn’t show any incremental progress that time, it just was already done recalculating by the time I got control back when the wire visibly snapped into place. Throughout all these operations, my CPU usage is 1-2% and memory usage is maybe 40%.
Seeing if I can get a pared down version of this file where the issue still occurs.
I’ll have more questions later, but what GPU does your system have?
RTX 4080 16GB VRAM, driver version 32.0.15.8157
I have sent you an e-mail! Hope it helps. Thank you!
I’ll take a look at it soon and let you know what I find!
Just to make a public reply – I’ve reproduced the performance issue for large projects on my own system, and will say more here when a fix is available.
A further note - the fix for this will be in the next Dev Preview release.
Thanks, Stephen!
Is there a sense or a guess of when that release will occur?
Much appreciated!
in separate post “beyond heightfields” he said:
“I hope to get the first Dev Preview out within the next couple weeks for ya’ll to start playing with this!”
This worked for a while, but my file is once again slowing down waiting on certain individual nodes to update. Can you remind me if there’s a certain setting I should be looking for or some workflow I should be avoiding to keep this from occurring?
It seems to be Combiner nodes in particular causing issues this time–maybe it’s because I have too many instances of them in a single file?
Sorry to hear that you’re still bumping into this. I can’t repro the original problem anymore, but I wonder if its a different-but-related issue.
The current built has an issue where the interactive previewer on fast devices (Combiner would be a possible one) will attempt to build at a higher res than its already-built inputs, causing it to have to rebuild the ENTIRE node chain hanging off the device inputs at the higher res. That of course takes quite a long time, causing a freeze in the interaction. The next tick, the previewer sees that it took a long time and drops it back to a lower res, starting the cycle over again.
It’s a fairly pernicious and annoying condition that requires
- A device that processes very fast on its own (Combiner, Curves, Clamp, Layers, et al)
- A “Refine until resolution” setting in Program Config->Build that is high enough to let the previewer increase above:
- A partially-built world with inputs that are not full res.
Mitigations include:
- Reducing that Refine until resolution setting to something relatively low.
- You can also make sure the device you’re edtings’ inputs are all built at least to the refine-to level (the Preview-To command works), which will also avoid it.
You can use that second one to diagnose if the problem you’re having is this bug.
Obviously both of those mitigations have consequences to workflow and are annoying. The good news: this bug has already been fixed for the next version! I don’t have exact timing on that yet but it will be within the next week or so I anticate.
I am using Hurrican Ridge and I am also getting severe UI lag after some time and especially in bigger files. I know you already solved this topic but I wanted to ask if you could also improve for the current stable version not just the newest dev version? Unfortunately this makes working really painful, almost impossible at times.
Hi there,
I definitely understand how frustrating that UI lag is.
As you noted, the fix is already in the current build. I looked into back porting the fix to the older release line several months ago, but that portion of the app actually had large architectural changes that makes back-porting the fixes a substantial new body of work that would require its own new set of testing against regressions, etc.
The practical route is to install the Current build. You can run it side by side with your existing Hurricane Ridge release if you need absolute insurance, but I’ve worked quite hard at making the modern builds produce 100% identical results for old worlds as long as you don’t update the project or device version.
I know the ‘Active development’ build sounds scary, but for WM the current-development channel is essentially production ready and is tested fairly thoroughly before each ship. The label undersells it. As I talk about in this blog post, I’ve realigned the names of the release model to better reflect this:
Pretty much all active development (bug fixes included) go into the active named branch. The LTS builds are a snapshot of the final release(s) of each named branch. The current releases are not necessarily any less-tested than the LTS channel.
Thank you for the answer so I guess I have to renew my license then ^^ One thing that I noticed is that maybe adding to the problem is that I am using GPU compute but when clicking on “Platform info…” it doesn’t actually show my GPU. I am using a Laptop with an onboard GPU Chip and a dedicated GPU (3080M). Could it be that world machine is not recognizing my GPU correctly and that this adds on top of the performance issues?
Edit: The GPU is now recognized correctly but that doesn’t necessarily improve UI performance ^^
Thanks Stephen!
I look forward to the next bugfix release with this in it. You mentioned trying the “Preview to” command, but I’m unfamiliar with that. I know “Build to.”
Or do you just mean ensuring that the last node before the one I’m editing has been fully built to the final Preview resolution before beginning the edits and isn’t still updating?
-Ryan