HywelPhillips
March 13th, 2021, 14:03
Hi,
The new lighting is great. When it is tuned up I'm really looking forward to using it.
I have noticed a slowdown issue with 4.1. This is on an iMac 2017 4.2 GHz core i7, 48 GB RAM, Radeon Pro 8192 MB, running off the built in SSD, MacOS High Sierra 10.13.6.
When everything is turned on, inevitably, performance suffers, which is expected.
But it is also hitting user interface performance outside of screen updates - mouse movement becomes laggy and jerky, which it ought not to do. Mouse clicks become very imprecise as a result. It's not the fastest Mac in the world but it's not a total slouch, and other demanding applications like editing or compressing 4K videos don't cause this system-wide mouse judder even when exercising CPU and GPU fully. So I think there's something a bit wrong with how the code is doing things compared with other applications and I suspect it is something to do with old-version-of-FGU LOS definitions.
The problem seems particularly marked with token lock on, having the tokens do their move path animation. The culprits seem to be line of sight and lighting.
Here's an example on a wilderness map. You can see how much the token slows down with those options turned on. What you can't see is that this slowdown affects everything, even mouse movement. I had to have nine goes at capturing the video because the mouse lag gets so back that I kept mis-clicking.
For sure this is a stressful test for the system. There's a big-ish map on a retina screen, masked FX on the water, FX myst, FX Time of Day over the top, a token with both light emission and darkvision, and terrain line of sight blockers. Nonetheless, there's only five lights (ambient, three torches and the wraith token), the number of occluder sections is pretty normal for an outdoor map, and there are only two tokens on the map. So I don't think it is entirely unreasonable to try with maps like this.
The issue for me is not the rendering lag or jerky frame rates, it that it spills over into affecting the mouse movement to the point that the system becomes almost unusable. I find myself moving windows constantly because the mouse pointer hasn't caught up with the movement by the time I click the mouse.
Interestingly, it doesn't seem to be using the CPU of the system. The fan's not coming on, and CPU usage is like 8% (barely taking anything from a single core).
GPU usage is pegged to the Max even with /vsync 4, though.
I haven't tried it on my iMac Pro yet which has a beefier GPU and is on Catalina instead of High Sierra, because that's my production machine. But I think there's some bug or need for tuning here because my regular iMac can run 3D graphics games at fairly high spec without hitting this mouse-judder system slowdown issue.
https://youtu.be/w5tIjJJHC9Q
This was in an otherwise pristine vanilla 5E campaign with just DMG, PHB, MM, Phandelver and my own module of battlemaps loaded. No extensions.
The battlemap had its LOS defined under an older version of FGU. I tried a fresh battlemap imported from a clean JPEG and didn't seem to encounter the same issue - GPU pegs out at 100% still even in VSYNC 4, but the mouse movement is not affected to anything like the same extent. Then I tried the original JPEG for this battlemap re-imported and quickly re-positioned most of the elements.
It's still a bit jerky rendering, pegging GPU at 100% and having tokens slow to move when GM approved, but doesn't produce the mouse lag and the Mac system remains responsive.
I cleared the LOS data from the original map from my module and re-did it, and it seems to have sped it up, too.
So my conjecture is that there's something FGU doesn't like with the old LOS definitions, maybe?
Cheers, Hywel
The new lighting is great. When it is tuned up I'm really looking forward to using it.
I have noticed a slowdown issue with 4.1. This is on an iMac 2017 4.2 GHz core i7, 48 GB RAM, Radeon Pro 8192 MB, running off the built in SSD, MacOS High Sierra 10.13.6.
When everything is turned on, inevitably, performance suffers, which is expected.
But it is also hitting user interface performance outside of screen updates - mouse movement becomes laggy and jerky, which it ought not to do. Mouse clicks become very imprecise as a result. It's not the fastest Mac in the world but it's not a total slouch, and other demanding applications like editing or compressing 4K videos don't cause this system-wide mouse judder even when exercising CPU and GPU fully. So I think there's something a bit wrong with how the code is doing things compared with other applications and I suspect it is something to do with old-version-of-FGU LOS definitions.
The problem seems particularly marked with token lock on, having the tokens do their move path animation. The culprits seem to be line of sight and lighting.
Here's an example on a wilderness map. You can see how much the token slows down with those options turned on. What you can't see is that this slowdown affects everything, even mouse movement. I had to have nine goes at capturing the video because the mouse lag gets so back that I kept mis-clicking.
For sure this is a stressful test for the system. There's a big-ish map on a retina screen, masked FX on the water, FX myst, FX Time of Day over the top, a token with both light emission and darkvision, and terrain line of sight blockers. Nonetheless, there's only five lights (ambient, three torches and the wraith token), the number of occluder sections is pretty normal for an outdoor map, and there are only two tokens on the map. So I don't think it is entirely unreasonable to try with maps like this.
The issue for me is not the rendering lag or jerky frame rates, it that it spills over into affecting the mouse movement to the point that the system becomes almost unusable. I find myself moving windows constantly because the mouse pointer hasn't caught up with the movement by the time I click the mouse.
Interestingly, it doesn't seem to be using the CPU of the system. The fan's not coming on, and CPU usage is like 8% (barely taking anything from a single core).
GPU usage is pegged to the Max even with /vsync 4, though.
I haven't tried it on my iMac Pro yet which has a beefier GPU and is on Catalina instead of High Sierra, because that's my production machine. But I think there's some bug or need for tuning here because my regular iMac can run 3D graphics games at fairly high spec without hitting this mouse-judder system slowdown issue.
https://youtu.be/w5tIjJJHC9Q
This was in an otherwise pristine vanilla 5E campaign with just DMG, PHB, MM, Phandelver and my own module of battlemaps loaded. No extensions.
The battlemap had its LOS defined under an older version of FGU. I tried a fresh battlemap imported from a clean JPEG and didn't seem to encounter the same issue - GPU pegs out at 100% still even in VSYNC 4, but the mouse movement is not affected to anything like the same extent. Then I tried the original JPEG for this battlemap re-imported and quickly re-positioned most of the elements.
It's still a bit jerky rendering, pegging GPU at 100% and having tokens slow to move when GM approved, but doesn't produce the mouse lag and the Mac system remains responsive.
I cleared the LOS data from the original map from my module and re-did it, and it seems to have sped it up, too.
So my conjecture is that there's something FGU doesn't like with the old LOS definitions, maybe?
Cheers, Hywel