FGU using GPU at almost 100%

[Jacknight]

Hello,

I just bought FantasyGround Unity a days ago, and I'm surprised that, even if ti works ok so far, it's using around 90%-95%of my GPU (while my CPU is Under 60-65% load) most of the time, even when it's the only software running and I'm not doing anything with it (no window opened).

My Laptop is still a good one (HP Spectre), and I can play to games requiring a real use of the GPU for 3D computing.

So this is not making any sens for me.
Are you aware of such issue ?
I know that nowadays, developpers are making too much use of object oriented programmation in defiance of the old school optimization of their algorythms with standard variables resulting in loops making over use of object's methods, and ignoring all the processes going on behind those methods. Such approache makes them losing the big picture view of the overall algorythm.

Many thanks

[JustMark]

I've been running into similar issues.

I have an i9 with 32GB of ram, and when running FGU I often end up with 7 cores at 100%, fans on full blast and really slow performance. This can be with just me using it to configure a campaign. Server version is 2020-04-17

[Whaley]

I think they have done a great job getting the performance way down. See attached image, i launched it as "Run as Admin" and had multiple windows open. I even launched one as a GM and one as a player to see comparisons. Was running a combat with about 20 enemies as well.

33936

[pindercarl]

I've been running into similar issues.

I have an i9 with 32GB of ram, and when running FGU I often end up with 7 cores at 100%, fans on full blast and really slow performance. This can be with just me using it to configure a campaign. Server version is 2020-04-17

A couple of follow-ups: 1) It sounds like you are running a laptop. Is this correct? 2) Are you using the integrated graphics or a dedicated GPU? Thanks.

[JustMark]

Hi,

Yes, it is a laptop.
GPU is a Radeon Pro 560X 4 GB.

[lozanoje]

Hi,

Yes, it is a laptop.
GPU is a Radeon Pro 560X 4 GB.

It has also an integrated card, maybe a Intel UHD Graphics 630, what pindecarl is asking you is if you are using the integrated video card or the Radeon 560x when executing the program.

Most programs run by default with the integrated card and you have to force them to use the other card.

[damned]

I think they have done a great job getting the performance way down. See attached image, i launched it as "Run as Admin" and had multiple windows open. I even launched one as a GM and one as a player to see comparisons. Was running a combat with about 20 enemies as well.

33936

It is best to not run applications "As Admin" other than for troubleshooting.

[JustMark]

It has also an integrated card, maybe a Intel UHD Graphics 630, what pindecarl is asking you is if you are using the integrated video card or the Radeon 560x when executing the program.

Most programs run by default with the integrated card and you have to force them to use the other card.

Hi,

The system is using the Radeon for FGU.

Mark

[Whaley]

It is best to not run applications "As Admin" other than for troubleshooting.

Yes, I agree normally, however from others posts they said running it as admin made it more stable and faster. I have since ran it normally and had similar results as when I ran it as admin.

[LordEntrails]

Yes, I agree normally, however from others posts they said running it as admin made it more stable and faster. I have since ran it normally and had similar results as when I ran it as admin.
I read those posts. Personally I am highly suspicious that they had any type of evidence to support such a claim.

[pollux]

I read those posts. Personally I am highly suspicious that they had any type of evidence to support such a claim.

Also color me skeptical. I think this is a case of people connecting when the matchmaking server is overloaded, seeing poor performance... then running as admin and connecting later when the matchmaking server is in better shape, seeing better performance... and failing to correctly identify where the improvement came from.

In general, if FGU is properly installed with the expected permissions on your data folder (it by default it is), running as admin is at best unnecessary. I could imagine several bad things that might come out of it as well.

[JustMark]

Ok, further to the issues I reported before, I have moved FGU over to my iMac Pro, which has 32GB, RadeonPro Vega 56 8GB, and 8 core 3.2Ghz Xeon W processor.

I was running FGU for about 10 minutes, and I was the only person using it. I was creating an effect for an upcoming game, and the CPU's shot up to 100%. As soon as I shut down FGU, all the CPUs returned to normal.

Here is a screenshot showing the process utilization:

34175

[pindercarl]

Ok, further to the issues I reported before, I have moved FGU over to my iMac Pro, which has 32GB, RadeonPro Vega 56 8GB, and 8 core 3.2Ghz Xeon W processor.

I was running FGU for about 10 minutes, and I was the only person using it. I was creating an effect for an upcoming game, and the CPU's shot up to 100%. As soon as I shut down FGU, all the CPUs returned to normal.

Here is a screenshot showing the process utilization:

34175

Thanks, JustMark. This is very much looking like an issue that is, if not Mac specific, Mac evident.

[vaughnlannister]

I've been running into similar issues.

I have an i9 with 32GB of ram, and when running FGU I often end up with 7 cores at 100%, fans on full blast and really slow performance. This can be with just me using it to configure a campaign. Server version is 2020-04-17

Hey, noticed with the recent update that cpu is much lower. Are you seeing the same results?

[JustMark]

Hey, noticed with the recent update that cpu is much lower. Are you seeing the same results?

Hi,

The issue I ran into yesterday on my iMac Pro was with the latest version (04-17)

I'm trying to be able to reproduce this reliably. It seems to have been happening when I was using the Combat Tracker. I was cycling through turns rapidly to test some effects. Will see if I can make this happen again reliably today.

[qdwag]

I have seen the same on my MacBook Pro with the Vega graphics card. FGU idle drives my cpu to 50%. Nothing else running. The minute I load a map the fans kick in and it drives my cpu to 100%.

There are no players connected and the game’s hosted via LAN. It’s been like this since I got FGU 2 months back. I think the recent optimisations have helped a little because in the past, just having FGU open alone would drive all my cpu cores to 100%, constant.

It would be so nice to see FGU working like FG Classic soon.

[JustMark]

I have seen the same on my MacBook Pro with the Vega graphics card. FGU idle drives my cpu to 50%. Nothing else running. The minute I load a map the fans kick in and it drives my cpu to 100%.

There are no players connected and the game’s hosted via LAN. It’s been like this since I got FGU 2 months back. I think the recent optimisations have helped a little because in the past, just having FGU open alone would drive all my cpu cores to 100%, constant.

It would be so nice to see FGU working like FG Classic soon.

Just to add to qdwag's comment - my FGU games have always been LAN based too.

Another note, if I leave FGU running on my system, it can do so for hours without any CPU issues.

As a simple test, I have had it running now for several hours with no interaction. I just switched to it, brought up the combat tracker (5 players listed), and then just repeatedly hit the Next Actor button. Went through 15 rounds, and now my CPU cores are all at 100%.

[CherenkovGlow]

Thanks, JustMark. This is very much looking like an issue that is, if not Mac specific, Mac evident.

I've experienced similar symptoms on Windows. However, I am connecting to a game running on a MacBook. I'd be surprised if that's relevant to GPU usage, but stranger things have happened!

I'm running on a Surface Pro 3, driving a 4K monitor at 29 Hz with 150% scaling of the Windows UI. FGU's ScaleUI is set to 150 also. I have a Surface Dock connected to the computer, but the monitor is connected directly to the Surface Pro's mini-DP port rather than via the dock, because I've been having trouble getting the dock to reliably detect the monitor's full resolution capability.

The FGU version is 4.0.0 FREE (2020-04-17). The GM is hosting the game on Ultimate edition on a MacBook Pro. Same version of FGU I believe.

My system specs are:

Intel Core i5-4300U CPU, nominal base clock 2.5GHz, max turbo 2.9GHz, 2 physical cores, 4 logical cores
8 GB RAM
Intel "HD 4400" integrated graphics running the "latest" stock drivers available from Windows Update, version 20.19.15.4568 (timestamped 2016-12-16!)
256 GB integrated SSD storage
Windows 10 Pro version 1909
The game is using the Savage Worlds Adventure Edition (SWADE) Weird Wars ruleset.


It's certainly no supercomputer but it can handle all my other 2d apps just fine.

When the app is running, GPU usage sits at 100% in the "Task Manager->GPU->3D" subcategory and the fans spin up to max. Unfortunately the Surface Pro 3's poor cooling capability means that the CPU actually throttles badly when the GPU is experiencing sustained max load. It was downclocking the CPU to as low as 0.8 GHz! The whole computer became very laggy.

Next time I connect to the game I would be happy to collect any more data that you would like for further troubleshooting. I'm a software developer myself (industrial rather than gaming) so don't be shy about asking me for technical stuff.

34192

[qdwag]

I've experienced similar symptoms on Windows. However, I am connecting to a game running on a MacBook. I'd be surprised if that's relevant to GPU usage, but stranger things have happened!

I'm running on a Surface Pro 3, driving a 4K monitor at 29 Hz with 150% scaling of the Windows UI. FGU's ScaleUI is set to 150 also. I have a Surface Dock connected to the computer, but the monitor is connected directly to the Surface Pro's mini-DP port rather than via the dock, because I've been having trouble getting the dock to reliably detect the monitor's full resolution capability.

The FGU version is 4.0.0 FREE (2020-04-17). The GM is hosting the game on Ultimate edition on a MacBook Pro. Same version of FGU I believe.

My system specs are:

Intel Core i5-4300U CPU, nominal base clock 2.5GHz, max turbo 2.9GHz, 2 physical cores, 4 logical cores
8 GB RAM
Intel "HD 4400" integrated graphics running the "latest" stock drivers available from Windows Update, version 20.19.15.4568 (timestamped 2016-12-16!)
256 GB integrated SSD storage
Windows 10 Pro version 1909


It's certainly no supercomputer but it can handle all my other 2d apps just fine.

When the app is running, GPU usage sits at 100% in the "Task Manager->GPU->3D" subcategory and the fans spin up to max. Unfortunately the Surface Pro 3's poor cooling capability means that the CPU actually throttles badly when the GPU is experiencing sustained max load. It was downclocking the CPU to as low as 0.8 GHz! The whole computer became very laggy.

Next time I connect to the game I would be happy to collect any more data that you would like for further troubleshooting. I'm a software developer myself (industrial rather than gaming) so don't be shy about asking me for technical stuff.

34192

Sounds identical to what I am seeing here, albeit a different OS.

[JustMark]

Just a quick update. I ran a 5 hour Starfinder session tonight with 5 players and everything worked like a charm. I didn’t experience any of the high cpu rates that I had experienced recently.

[qdwag]

What OS were you using? Can you send a screen shot of FGU within the task manager?

[JustMark]

What OS were you using? Can you send a screen shot of FGU within the task manager?

I'm running MacOS 10.15.

I'll grab some screenshots next time I have it running.

[vaughnlannister]

I have had similarly results its running much more smoothly, my fan will start to turn when I open up images or new windows, but it doesn't seem that bad as it used to be.

[qdwag]

You're right, it's slightly better. But as I am typing this, FG is sitting in the background taking up 47% of my CPU for no reason at all. It's being incredibly hungry for CPU bandwidth that could be used on my other apps.

FG Classic is like butter. Can't wait for the day FGU gets that optimisation.

[JustMark]

I've been running FGU for about 3 hours today and have been actively configuring a campaign. Last week I would've had fans blaring, but as I said, last nights game, and today's configuration have had no issues. I realize my desktop is probably beefier than most with a Xeon processor, but you can see from the following CPU graph that the cores have essentially been idle.

34256

[qdwag]

I just loaded a 800pixel map and a 2 tokens. No player connections, hosted on LAN.

My Macbook pro fans took off after a minute and look what happened to my CPU. This is crazy. Note: It's been 10 minutes so far and the CPU bandwidth has stayed locked at that point.


Check out this screenshot of my Activity Monitor (https://prnt.sc/s54oro)

[vaughnlannister]

Yes the new update kind of worsened things a little, were just going to have to be patient. I'm thinking early June that the most rough edges will be smoothed out.

[qdwag]

Today, FGU hit a new record high. 185% CPU. Fans on my Macbook Pro sound like a jet engine.

Have a look at this screenshot (https://prnt.sc/s68tpq)

What I did different this time was turn on wall building on a 1000x1000 px map. That's all it took and the CPU is sitting constantly at that % even when FG is in the background.

[Copernicus219]

I consistently see my cpu nearing 100% as well as ram usage around 4Gb and sometimes I'll open assets and it will shoot up to 8-9Gb. There are some serious performance issues happening with FGU, as someone else said, FGC for me ran smooth on the same laptop (aside from the port forwarding problems I had with it) Also, I don't know why this was mentioned, but my laptop always uses my nvidia GPU for FGU.

[qdwag]

Radeon Vega gpu on my Macbook Pro.

FGC is definitely smooth as butter, but I guess it doesn't have all this other LOS functionality. I'd rather sacrifice the LOS functionality for now for smoother FGU performance. I can't install FGC on my Catalina OS.

[Old Man Dice]

On my Mac mini with 2 core and 16G memory I see the CPU spike to 110-175% while using Unity depending on two things: if I stretch the UI across two screens and open LOS maps. If I reduce the UI to one screen, CPU usage drops to about 80-90%. When I open maps, I need to keep them as small as possible. The bigger I make a map, the higher the spike in CPU usage.

I wonder if this is the reason FG has suddenly shut down for some of my players three days ago (Sunday, May 3)

[qdwag]

From what you’re saying, it sounds correlated.

[Atarsamak]

Hi all,
I just purchased FGU ultimate and I have the same issues of excessive GPU usage on both my PCs. One is aNUC7i5BNH the second one is a laptop LEnovo Yoga 3 Pro 1370. Both screens have a relatively high resolution (a 4K monitor for my NUC and 3200x1800 for my laptop). Actually, I trsted FGU Ultimate on the NUC and the Demo version on the laptop. As soon as I open FGU, already before joining or creating a campaign, the GPU runs at 100% of usage.
Of course this is nothing new in this thrad. I'm posting just because I collected some information as some of you suggested that it is related to the window size (as expected). I attach a plot showing the GPU and CP usage vs window size in pixels (actually I measured it in cm an then converted into million of pixels). I'm not sure if this information can be of help. Anyway, I hope this issue will be fixed as soon as possible as it makes FGU almost unusable.

Thanks

35482

[Zarkamorta]

Hi, I am seeing a similar effect and posted my observations in an earlier post.

Might be worth to collect all the information in one thread:

Hello,

Though performance enhancements might be implemented at a later stage, I would like to report the following issue. FGU maxes out the GPU while just sitting idle after starting a campaign.

I‘m running FGU on a Surface Pro 7:

Windows 10 Pro 1909 (latest build)
Intel GPU Driver 26.20.100.7641 (latest build)
FGU v4.0.0 Ultimate (2020-04-28, last update 2020-05-06)

Intel Core i5-1035G4 (4 cores, 8 threads, 1.1 GHz to 3.3 GHz max. on all cores)
Intel Iris Plus Graphics G4 (0.8 TFLOPS FB32, 1.6 TFLOPS FB 16)
8 GB RAM

Though this is not graphic monster, it packs considerably much more punch than previous Intel GPUs.

For performance measurements I’m using the 5E Sample Campaign (LAN, Theme – Simple Gray, just starting the campaign, not opening any windows, not using any effects):

FGU not running (CPU 2%, 2 GHz, 3.0 GB RAM, GPU/3D 1%, 0.2 GB VRAM)

FGU 2736x1824 – native resolution (CPU 7%, 1 GHz, 3.5 GB RAM, GPU/3D 90-99%, 0.4 GB VRAM)

FGU 2052x1368 (CPU 8%, 1 GHz, 3.5 GB RAM, GPU/3D 50-55%, 0.3 GB VRAM)

FGU 1368x912 (CPU 8%, 1 GHz, 3.3 GB RAM, GPU/3D 30-35%, 0.2 GB VRAM)

So basically, the CPU is not really stressed, not much RAM and VRAM used, but the GPU ist stressed strongly (scaling with resolution).

Basically, I’m wondering where does the GPU load come from and what is going on in the background, since I’m having no additional windows (maps etc.) open and I’m not using any effects.

If you need any other measurements please let me know.

[Zarkamorta]

Here is also also a collection of threads from other users posting similar GPU problems:

Expected performance with GPU at higher resolutions:

https://www.fantasygrounds.com/forums/showthread.php?52018-Expected-performance-with-GPU-at-higher-resolutions

New FGU User wondering why it is so slow:

https://www.fantasygrounds.com/forums/showthread.php?55067-New-FGU-User-Wondering-why-it-s-so-slow

Graphics processor maxed out just opening program:

https://www.fantasygrounds.com/forums/showthread.php?56355-Graphics-processor-maxed-out-just-opening-program

NVIDIA GTX 1070 Performance and FGU maxed-out memory and clock speed:

https://www.fantasygrounds.com/forums/showthread.php?51753-NVIDIA-GTX-1070-Performance-and-FGU-Maxed-out-memory-and-clock-speed

FGU minimised window with 5E Sample Campaign uses about 6% CPU and 29% GPU:

https://www.fantasygrounds.com/forums/showthread.php?57698-FGU-minimised-window-with-5E-Sample-Campaign-uses-about-6-CPU-and-29-GPU

CPU issues on Mac (and Win):

Performance:

https://www.fantasygrounds.com/forums/showthread.php?57628-Performance

Will the final version have great programming? CPU usage of 500%+:

https://www.fantasygrounds.com/forums/showthread.php?57612-Will-the-final-version-have-great-programming-CPU-usage-of-500

Mac performance:

https://www.fantasygrounds.com/forums/showthread.php?52929-Mac-Performance

Really high CPU usage:

https://www.fantasygrounds.com/forums/showthread.php?53289-Really-high-CPU-usage


Will add more at a later stage.

[Zarkamorta]

Hi,

comparing recent builds I can report so far no performance improvements:

FGU v4.0.0 Ultimate (2020-04-28, last update 2020-05-06):

CPU 7%, 1 GHz, 3.5 GB RAM, GPU/3D 90-99%, 0.4 GB VRAM

FGU v4.0.0 Ultimate (2020-05-14, last update 2020-05-15):

CPU 7%, 1 GHz, 3.5 GB RAM, GPU/3D 90-99%, 0.4 GB VRAM


System:

5E Sample Campaign (2736x1824, LAN, Theme – Simple Gray, just starting the campaign, not opening any windows, not using any effects)

Surface Pro 7
Windows 10 Pro 1909 (latest build)
Intel GPU Driver 26.20.100.7641 (latest build)

Intel Core i5-1035G4 (4 cores, 8 threads, 1.1 GHz to 3.3 GHz max. on all cores)
Intel Iris Plus Graphics G4 (0.8 TFLOPS FB32, 1.6 TFLOPS FB 16)
8 GB RAM

[Malosar]

Since it's using Unity and rendering 3D using the GPU, with these usage numbers I'm wondering if FGU isn't frame capped at all. So it's literally redrawing at hundreds of fps to the limit of the GPU. You get this sometimes in games menus where the developer doesn't frame cap the menu and it operates at ridiculous frames.

[LordEntrails]

Since it's using Unity and rendering 3D using the GPU, with these usage numbers I'm wondering if FGU isn't frame capped at all. So it's literally redrawing at hundreds of fps to the limit of the GPU. You get this sometimes in games menus where the developer doesn't frame cap the menu and it operates at ridiculous frames.
At one point in time I think I remember the devs saying that was the case, but then they said they put in a 30 fps cap, but then raised it to 60fps because of complaints. BUT, that's from memory and I could well be misremembering.

[Malosar]

At one point in time I think I remember the devs saying that was the case, but then they said they put in a 30 fps cap, but then raised it to 60fps because of complaints. BUT, that's from memory and I could well be misremembering.

ah awesome, good to know, thanks! Yes, 60fps would be ideal.

[Zarkamorta]

Hi,

yes, there is frame capping taking place.

Just got the FPS counter of Xbox Game Bar working:

60 FPS for 5E Sample Campaign, Simple Gray, just starting the campaign, not opening any windows, not using any effects

32 FPS for 5E Sample Campaign, Simple Gray, Battle Map01 open and zoom to fit, not using any effects

25 FPS for 5E Sample Campaign, Simple Gray, Battle Map01 open and zoom to fit, just using one effect (rain)

So something within FGU is really sucking a lot of GPU performance.

[Atarsamak]

Hi,

in my case, the data I get from Xbox Game Bar are not in agreement with those from Task Manager. Both provide the same values for CPU usage but for GPU Xbox Game Bar tells 0% while on Task Manager I read 100%. And I can tell you that Task Manager is the one correct (from the fan noise and the heat coming from the PC....).
There has to be something wrong with FGU, for sure, a bug. I can't believe it is something due to a poor project development from the ground up resulting in such a bad use of resources.
After all, it's a Pre-release.... let's wait. I'm patient.

[Zarkamorta]

Hi,

my readings on the GPU load in percentage are also from the Task Manager and by how hot the computer runs I can tell that those readings are real.

Within the Xbox Game Bar I also do get strange readings for the GPU. Though, those are measured in GB. So it think this is not the GPU load.

What I took from Xbox Game Bar are the FPS readings. Though, it's tricky to get Xbox Game Bar working for FPS readings:

Not seeing the FPS info after completing FPS setup
When you set up the FPS counter in Xbox Game Bar, your user account will be added to the Performance Log Users group (if your account is the administrator for the device or the administrator has added your account to the group). If you’re not seeing the FPS counter after restarting your PC (Request access button still appears in the FPS tab), verify that your account was added to the Performance Log Users group by typing Computer Management in the desktop search box, selecting Local Users and Groups > Groups > Performance Log Users. If you’re not seeing your account in the Members box, request access again from the FPS tab in the Game Bar Performance overlay, then restart your PC.
If you’re still not seeing FPS info after retrying access, manually add your administrator account to the group by typing Computer Management in the desktop search box, selecting Local Users and Groups > Groups > Performance Log Users, pressing Add, then following the prompts. Restart your PC for the changes to take effect.

Taken from:

https://answers.microsoft.com/en-us/xbox/forum/all/fps-counter-not-showing-in-xbox-game-bar/2d6508ac-f970-4b2c-9291-dd6f41181f96

I also do hope this performance issue can be fixed further down the road. At the moment, I cannot playtest FGU due to the performance issues.

[Atarsamak]

Hi Zarkamorta,

in my case GPU usage is in % also in the Xbox Game Bar. Se the picture. Sorry for the quality, for some reason both print screen and the Xbox snapshot did did not work. I took a picture with my mobile.
Anyway, I agree with you about having a hot PC. From the point of viw of speed I could stil test FGU (it is not exceedingly slowed down) but I do not beleive the PC hardware could stand t for long....
I prefer not to take the risk....

35496

[qdwag]

I’m surprised how long this thread has gone on for without any comments from the dev?

[pindercarl]

I’m surprised how long this thread has gone on for without any comments from the dev?

The issue with over-taxed GPUs is not universal. We have so far only been able to collect anecdotal evidence from users. There are some similarities, but no silver bullets. It primarily seems to impact laptops with integrated video hardware, but that is not consistent. Ironically, it also seems to impact expensive portables (Surface Pro and MacBook Pro) more than others. But that could also be confirmation bias based on who reports based on expectations. I did discover this week that on a new MacBook Pro, I can get FGU to spin up the fans. It's our first, in-house reproducible case and will hopefully lead to some better diagnoses.

[qdwag]

Thanks for replying Pindercarl. Much appreciated.

[Zarkamorta]

The issue with over-taxed GPUs is not universal. We have so far only been able to collect anecdotal evidence from users. There are some similarities, but no silver bullets. It primarily seems to impact laptops with integrated video hardware, but that is not consistent. Ironically, it also seems to impact expensive portables (Surface Pro and MacBook Pro) more than others. But that could also be confirmation bias based on who reports based on expectations. I did discover this week that on a new MacBook Pro, I can get FGU to spin up the fans. It's our first, in-house reproducible case and will hopefully lead to some better diagnoses.

Thanks for replying Pindercarl. I‘m glad that the issue is under investigation with the devs.

Do you see the problem also under Win 10 on said MacBook Pro?

In any case, I am more than willing to help test things out on my Surface Pro 7!

Please let me know, if you need any additional information or if I should test something.

[Atarsamak]

Hi Pindercarl,

thank you for posting. Actually I would not call the plot I posted on May 11th, 2020 at 03:57 "anecdotal" but I agree that the information is probably incomplete. For example I didn't even report the OS.... sorry (it's Windows 10). Let me know which type of data you need or if I can be of help by making some more tests.
I also understand that probably I have a wrong perception of the problem since I experience it on two PCs (out of two). Specifically NUC7i5BNH (W10 Enterprise) and Lenovo Yoga 3 Pro 1370 (W10 Home), therefore, I expected it to be quite common but, of course, 2 is certainly what can be called good statistics ;-).
I also understand that people with dedicated graphic cards and "gaming oriented machines" PCs do not experience any problem, they have more than enough enough "power". However, I would be curious to know if they notice an unusual GPU usage nonetheless. Since however the screen resolution (and FGU window dimension) is clearly influencing the usage, I would restrict the comparison on users using a 4K screen.
I'm afraid that many people who, at the moment, do not perceive any problem, they will as soon as they move to a 4K monitor on the same PC. But, again, just my (probably biased perception).

Anyway, from my point of view, I'm eager to help with some tests if you think this can be useful. Who knows if it's a FGU problem or of some specific driver, or what else? Well, that's what tests are for.

That said, I'll wait until FGU will no longer be considered "Early Access" and then, depending on whether it will be "usable" or not decide if ask for a refund, switch to FGC (I don't think so I'm intersted in LOS), or buy a new PC with more graphic power (but, in my opinion, it should be overkilling for a software like FGU).

[pindercarl]

Hi Pindercarl,

thank you for posting. Actually I would not call the plot I posted on May 11th, 2020 at 03:57 "anecdotal" but I agree that the information is probably incomplete. For example I didn't even report the OS.... sorry (it's Windows 10). Let me know which type of data you need or if I can be of help by making some more tests.
I also understand that probably I have a wrong perception of the problem since I experience it on two PCs (out of two). Specifically NUC7i5BNH (W10 Enterprise) and Lenovo Yoga 3 Pro 1370 (W10 Home), therefore, I expected it to be quite common but, of course, 2 is certainly what can be called good statistics ;-).
I also understand that people with dedicated graphic cards and "gaming oriented machines" PCs do not experience any problem, they have more than enough enough "power". However, I would be curious to know if they notice an unusual GPU usage nonetheless. Since however the screen resolution (and FGU window dimension) is clearly influencing the usage, I would restrict the comparison on users using a 4K screen.
I'm afraid that many people who, at the moment, do not perceive any problem, they will as soon as they move to a 4K monitor on the same PC. But, again, just my (probably biased perception).

Anyway, from my point of view, I'm eager to help with some tests if you think this can be useful. Who knows if it's a FGU problem or of some specific driver, or what else? Well, that's what tests are for.

That said, I'll wait until FGU will no longer be considered "Early Access" and then, depending on whether it will be "usable" or not decide if ask for a refund, switch to FGC (I don't think so I'm intersted in LOS), or buy a new PC with more graphic power (but, in my opinion, it should be overkilling for a software like FGU).

Anecdotal regarding the number of data points (systems), not the quality of the data. To date, we have not found the commonality of systems exhibiting the issue. For example, I have an older Mac Mini that does not have the issue, yet the new MacBook Pro does. Additionally, the MacBook Pro does not suffer from an over-taxed GPU when running FGU in the IDE, but does when running the release build. None of the Windows boxes used by the development team has the issue, but we have reports from users that do. It could be something as simple as the graphics drivers attempting to "help" the application by throwing all its resources at drawing something that does not require that many resources. We're still in the discovery phase of determining which buttons, knobs, and switches may be the root cause among all the various end user configurations.

[Atarsamak]

Thank you for the clarification. Good to know that you have some systems suffering from the same problem and that you are keeping an eye on it.
My PC is a dual boot Windoes 10 / Linux so in the future, if a Linux version of FGU will be confirmed, I could also give it a try.
Anyway, I'm available for any test you consider useful.

[Draco Oricalcinus]

I'm not sure this information will be helpful, but I noticed in the thread that there was already suspicion that the performance issue is related to integrated GPU machines.

Macs may come with a combination of GFX card configurations. Some have a discrete card, others have an integrated card, some have both. The combo configuration allows the mac to automatically switch between the two cards to conserve power when GPU intensive tasks are low.

Using this tool (https://gfx.io) while running FGU I noted that FGU seems to force my mac to use the discrete GFX card instead of allowing it to use the Integrated card. This would necessarily pull more power, generate more heat, activate the fans, and if may result in thermal throttling of the CPU.

These two older articles discuss what’s needed to support the Multiple GPU configuration for the Open GL graphics library. (I assume, perhaps incorrectly, that Open GL libraries are likely to be used in FGU so that the graphics code is consistent across platforms and developers don't have to code for Direct X and Metal separately. )

https://developer.apple.com/library/archive/qa/qa1734/_index.html

https://developer.apple.com/library/archive/technotes/tn2229/_index.html

In addition I found these two Unity reference pages: https://docs.unity3d.com/Manual/SL-PlatformDifferences.html , https://docs.unity3d.com/Manual/OpenGLCoreDetails.html


My mid 2012 machine is :
Model Name: MacBook Pro
Model Identifier: MacBookPro10,1
Processor Name: Intel Core i7
Processor Speed: 2.3 GHz
Number of Processors: 1
Total Number of Cores: 4
L2 Cache (per Core): 256 KB
L3 Cache: 6 MB
Hyper-Threading Technology: Enabled
Memory: 16 GB
Boot ROM Version: 257.0.0.0.0
SMC Version (system): 2.3f36

Intel HD Graphics 4000:

Chipset Model: Intel HD Graphics 4000
Type: GPU
Bus: Built-In
VRAM (Dynamic, Max): 1536 MB
Vendor: Intel
Device ID: 0x0166
Revision ID: 0x0009
Automatic Graphics Switching: Supported
gMux Version: 3.2.19 [3.2.8]
Metal: Supported, feature set macOS GPUFamily1 v4

NVIDIA GeForce GT 650M:

Chipset Model: NVIDIA GeForce GT 650M
Type: GPU
Bus: PCIe
PCIe Lane Width: x8
VRAM (Total): 1 GB
Vendor: NVIDIA (0x10de)
Device ID: 0x0fd5
Revision ID: 0x00a2
ROM Revision: 3688
Automatic Graphics Switching: Supported
gMux Version: 3.2.19 [3.2.8]
Metal: Supported, feature set macOS GPUFamily1 v4



I hope this information is helpful.

[pindercarl]

Unity uses DirectX on Windows and Metal on OSX. Using developer tools to switch between GPUs (integrated and discrete) during runtime have resulted in almost no difference. The percentage of GPU usage for integrated hardware is slightly higher than the discrete GPU, which is to be expected. We've had reports of this on both Macs and Windows machines. The anecdotal evidence suggests that it affects laptops more than desktops, but it isn't exclusive. Given that it affects some computers, but not others with the same specs, it is unlikely that it is at the application level, but is specific to some installations. Just to help fill in some of the data, what version of OSX are you running? Thanks.

[Draco Oricalcinus]

Mohave. I’ve not updated to Catalina so I can still run FGC.

Good luck tracking this down.

[pindercarl]

Thanks, Draco. The most common cause of the GPU running to 100% (other than running an application that is too complex for the GPU, e.g. "but does it run Crysis?") is that the vsync or framerate has been overridden by external GPU management software. Are you running any utilities or modified the default settings for your graphics hardware?

[Zarkamorta]

Thanks, Draco. The most common cause of the GPU running to 100% (other than running an application that is too complex for the GPU, e.g. "but does it run Crysis?") is that the vsync or framerate has been overridden by external GPU management software. Are you running any utilities or modified the default settings for your graphics hardware?

Hi Pindercarl,

At least in my case, I don‘t think that this is what‘s going on.

I get the following readings in the FPS counter of Xbox Game Bar on a Surface Pro 7:

60 FPS for 5E Sample Campaign, Simple Gray, just starting the campaign, not opening any windows, not using any effects

32 FPS for 5E Sample Campaign, Simple Gray, Battle Map01 open and zoom to fit, not using any effects

25 FPS for 5E Sample Campaign, Simple Gray, Battle Map01 open and zoom to fit, just using one effect (rain)

So unlimited framerate is not the issue.

I also went through the hassle of installing a fresh Win 10 Pro (just updating Win 10 Pro to the current build, no additional tools or programmes besides FGU). Same problem.

Afterwards I installed Intel Graphics Command Center to see if I can find any useful settings to fix the issue. Also with no success.

Do you have any information coming from Unity Profiler on the issue?

[pindercarl]

Hi Pindercarl,

At least in my case, I don‘t think that this is what‘s going on.

I get the following readings in the FPS counter of Xbox Game Bar on a Surface Pro 7:

60 FPS for 5E Sample Campaign, Simple Gray, just starting the campaign, not opening any windows, not using any effects

32 FPS for 5E Sample Campaign, Simple Gray, Battle Map01 open and zoom to fit, not using any effects

25 FPS for 5E Sample Campaign, Simple Gray, Battle Map01 open and zoom to fit, just using one effect (rain)

So unlimited framerate is not the issue.

I also went through the hassle of installing a fresh Win 10 Pro (just updating Win 10 Pro to the current build, no additional tools or programmes besides FGU). Same problem.

Afterwards I installed Intel Graphics Command Center to see if I can find any useful settings to fix the issue. Also with no success.

Do you have any information coming from Unity Profiler on the issue?

To date, I have only reproduced the runaway GPU on a MacBook Pro 16. And that was one time. I have not been able to reproduce since, so I suspect it is unrelated. What's the GPU usage in the three scenarios you outlined above?

[pollux]

At least in my case, I don‘t think that this is what‘s going on.
I get the following readings in the FPS counter of Xbox Game Bar on a Surface Pro 7...

This sounds like it could be "but does it run Crysis" syndrome.


The Surface 7 appears to ship with one of two (or three, are the G1 and G4 different?) integrated graphics options: https://www.microsoft.com/en-us/surface/devices/surface-pro-7/tech-specs
The fastest option with the i7 CPU is not fast: https://www.notebookcheck.net/Intel-Iris-Plus-Graphics-G7-Ice-Lake-64-EU-Laptop-GPU.422866.0.html Note many 0-fps entries, and many single-digit FPS entries.
The slowest option in the i5's is like 30% slower than that: https://www.notebookcheck.net/Intel-UHD-Graphics-G1-Ice-Lake-32-EU-Laptop-GPU.422873.0.html


The fact that you you have a low-power GPU and that your FPS is dragging as you start up the more "demanding" workloads in FGU suggests that your card is actually maxed out rather than triggering a consumption bug. An interesting test and bit of info would be to know what resolution you're running at, and does FPS go up if you reduce resolution. I'll be it does, and we're just seeing your GPU be maxed out by legitimate work.

[Zarkamorta]

To date, I have only reproduced the runaway GPU on a MacBook Pro 16. And that was one time. I have not been able to reproduce since, so I suspect it is unrelated. What's the GPU usage in the three scenarios you outlined above?


So “60 FPS for 5E Sample Campaign, Simple Gray, just starting the campaign, not opening any windows, not using any effects “ corresponds to “FGU 2736x1824 – native resolution (CPU 7%, 1 GHz, 3.5 GB RAM, GPU/3D 90-99%, 0.4 GB VRAM)”

“32 FPS for 5E Sample Campaign, Simple Gray, Battle Map01 open and zoom to fit, not using any effects” and “25 FPS for 5E Sample Campaign, Simple Gray, Battle Map01 open and zoom to fit, just using one effect (rain)” correspond to GPU/3D 100 %.

Yes, GPU load scales with resolution:

FGU not running (CPU 2%, 2 GHz, 3.0 GB RAM, GPU/3D 1%, 0.2 GB VRAM)

FGU 2736x1824 – native resolution (CPU 7%, 1 GHz, 3.5 GB RAM, GPU/3D 90-99%, 0.4 GB VRAM)

FGU 2052x1368 (CPU 8%, 1 GHz, 3.5 GB RAM, GPU/3D 50-55%, 0.3 GB VRAM)

FGU 1368x912 (CPU 8%, 1 GHz, 3.3 GB RAM, GPU/3D 30-35%, 0.2 GB VRAM)

@Pollux: But I beg to differ, in my opinion it is not a “will it run Crysis” issue. Though the Surface Pro 7 is not graphic monster, it packs considerably much more punch than previous Intel GPUs (Intel Iris Plus Graphics G4 - 0.8 TFLOPS FB32, 1.6 TFLOPS FB 16).

And FGU is not Crysis. Or at least I hope it is not. In the scenarios outlined above FGU is basically sitting idle with nothing to render.

And from my understanding there are many users out there running FGU on a Intel GPU.

PS: There are users having similar issues with other GPUs:

NVIDIA GTX 1070 Performance and FGU maxed-out memory and clock speed:

https://www.fantasygrounds.com/forums/showthread.php?51753-NVIDIA-GTX-1070-Performance-and-FGU-Maxed-out-memory-and-clock-speed

[pindercarl]

I agree that this Surface Pro appears to be GPU bound, but it shouldn't be. I have a MacMini with a less powerful integrated GPU and it is not GPU bound. We also have reports of users with dedicated GPUs having similar issues. In the first example (5E Sample Campaign, Simple Gray, just starting the campaign), FGU is drawing around 14k triangles. That's it. There isn't any post-processing or anything else running. It certainly isn't vertex bound. Reducing the resolution suggests that it is pixel bound, but again, I wouldn't expect it to be. Zarkamorta has helped to eliminate runway FPS as an issue in this case, which is progress.

[Atarsamak]

This sounds like it could be "but does it run Crysis" syndrome.


The Surface 7 appears to ship with one of two (or three, are the G1 and G4 different?) integrated graphics options: https://www.microsoft.com/en-us/surface/devices/surface-pro-7/tech-specs
The fastest option with the i7 CPU is not fast: https://www.notebookcheck.net/Intel-Iris-Plus-Graphics-G7-Ice-Lake-64-EU-Laptop-GPU.422866.0.html Note many 0-fps entries, and many single-digit FPS entries.
The slowest option in the i5's is like 30% slower than that: https://www.notebookcheck.net/Intel-UHD-Graphics-G1-Ice-Lake-32-EU-Laptop-GPU.422873.0.html


The fact that you you have a low-power GPU and that your FPS is dragging as you start up the more "demanding" workloads in FGU suggests that your card is actually maxed out rather than triggering a consumption bug. An interesting test and bit of info would be to know what resolution you're running at, and does FPS go up if you reduce resolution. I'll be it does, and we're just seeing your GPU be maxed out by legitimate work.

I agree on the fact that a high resoution is most probably a critical point for those (like me) who do not own a "gaming" PC but nevertheless use a 4K monitor. However I tend to disagree on what you call "legitimate work". When I set FGU fullscreen, my GPU runs at 100% already at the splash screen, before opening or creating a campaign. In my opinion, if that's not a bug, it's a poor use of resources. The GPU is clearly doing unecessary work. The only reason I would expect the GPU to be doing "legitimate work" would be when LOS is activated. In that case I could understand I'm asking too much from integrated graphic card (even if we are not talking about highly detalied 3D rendering of a moving object but only about light tracing and shading).

Well it could be a good excuse to buy a gaming PC... ;-)
The problem is that if FGU requires high end PC that would probably mean I'd loose half of my players and that's something a can't accept. In that case I'll probably have to opt out.

[lostsanityreturned]

Well it could be a good excuse to buy a gaming PC... ;-)
The problem is that if FGU requires high end PC that would probably mean I'd loose half of my players and that's something a can't accept. In that case I'll probably have to opt out.

I wouldn't expect purchasing a high end PC to matter much atm, the program is horribly unoptimised and I expect it to change in the future (that or Smiteworks will simply nolonger have a product and have to scrap it :P )

I am having performance hitches with a 2080ti, 3900x (ryzen), 32gb of low latency high speed ram, on a fast m.2 ssd.

One moment it will be running fine, the next I am fighting frames in the single digits while moving a character.

[Draco Oricalcinus]

I've made no modifications nor am I running any utilities that would affect my GPU. My "performance" gaming days are decades behind me.

[Zarkamorta]

I agree that this Surface Pro appears to be GPU bound, but it shouldn't be. I have a MacMini with a less powerful integrated GPU and it is not GPU bound. We also have reports of users with dedicated GPUs having similar issues. In the first example (5E Sample Campaign, Simple Gray, just starting the campaign), FGU is drawing around 14k triangles. That's it. There isn't any post-processing or anything else running. It certainly isn't vertex bound. Reducing the resolution suggests that it is pixel bound, but again, I wouldn't expect it to be. Zarkamorta has helped to eliminate runway FPS as an issue in this case, which is progress.

Hi Pindercarl,

Meanwhile, I installed Intel Graphics Performance Analyzers. (I also updated the GPU driver to 27.20.100.8190 with no change in FPS or GPU load).

I took a frame snapshot for the test scenario 2736x1824 – native resolution, 5E Sample Campaign, Simple Gray, just starting the campaign, not opening any windows, not using any effects.

Again this translates to CPU 7%, 1 GHz, 3.5 GB RAM, GPU/3D 90-99%, 0.4 GB VRAM, 60 FPS.

From the Graphics Frame Analyzer I get the following reading:

35917

Full Frame 10870 µs, 92 FPS

Early on there is a log for draw indexed which takes up 5157 µs of the 10870 µs. Bottleneck is the pixel backend.

Further, larger spikes are 2120 µs for resolve subresource (bottleneck not available), 1538 µs and 1352 µs for two other draw indexed (bottleneck is geometry transformation).

Going through all the logs, I get mainly the bottlenecks pixel backend and geometry transformation.

I hope this helps. Since my knowledge with Intel GPA is very limited, I’m not sure what to look for.

Of course, I’m more than willing to perform other measurements (e. g. for map opened and using effects) or send you the frame snapshot for an in-depth analysis.

[Zarkamorta]

PS:

Here is also an overview for the test scenario 5E Sample Campaign, Simple Gray, Battle Map01 open and zoom to fit, just using one effect (rain):

35918

Full Frame 27067 µs, 37 FPS

Things are getting a little bit more complex, main bottlenecks are (poorly prioritized):

pixel backend
geometry transformation

(sampler)
(setup backend)

((rasterization))
((early depth / stencil))

[Zarkamorta]

PPS:

In addition, an overview for the test scenario 5E Sample Campaign, Simple Gray, Battle Map01 open and zoom to fit, using no effect:

35919

Full Frame 24991 µs, 40 FPS

Main bottlenecks are the same as above (poorly prioritized):

pixel backend
geometry transformation

(sampler)
(setup backend)

((rasterization))
((early depth / stencil))

[pindercarl]

PPS:

In addition, an overview for the test scenario 5E Sample Campaign, Simple Gray, Battle Map01 open and zoom to fit, using no effect:

35919

Full Frame 24991 µs, 40 FPS

Main bottlenecks are the same as above (poorly prioritized):

pixel backend
geometry transformation

(sampler)
(setup backend)

((rasterization))
((early depth / stencil))

Thanks for the info. The bottleneck on stencil buffers is particularly interesting. As soon as I wrap up work on the LOS refactor, I already plan to look at writing custom clipping to remove our reliance on stenciling. It is a known issue that we often run out of stencil buffers. I'll have a look at batching while I'm in there. It is possible that we are not batching textures as well as we could. Thanks again for the additional metrics.

[Zarkamorta]

Thanks for the info. The bottleneck on stencil buffers is particularly interesting. As soon as I wrap up work on the LOS refactor, I already plan to look at writing custom clipping to remove our reliance on stenciling. It is a known issue that we often run out of stencil buffers. I'll have a look at batching while I'm in there. It is possible that we are not batching textures as well as we could. Thanks again for the additional metrics.

Hi Pindercarl,

Though, the much bigger problem seems to be pixel backend and geometry transformation. It would be good to carry out a differential analysis. Comparing my readings with readings from a flawlessly performing system (with similar specs). In my opinion that would help to pinpoint the problem.

[mah25]

Just some feedback on the GPU issue. I have a 2012 iMac and Unity just slams the GPU.

2012 iMac - MasOS Mojave 10.14.6
2.7 GHz Intel i5-3335S 4-cores
NVIDIA GeForce GT 640M 512 MB
16 GB Ram

At FGU start up - GPU ramps to over 60% and CPU use is under 25%
36014

With just a campaign loaded - the GPU spikes to nearly 100% and drops to around 75%

36019

With a single map with no tokens - the GPU pegs at 100% with the CPU around 25%

36044

I know it's an older machine, but never seen the GPU pushed so hard with not much going on. I still edit video (not 4K) on it with no problems.

[mah25]

Just some feedback on the GPU issue. I have a 2012 iMac and Unity just slams the GPU.

2012 iMac - MasOS Mojave 10.14.6
2.7 GHz Intel i5-3335S 4-cores
NVIDIA GeForce GT 640M 512 MB
16 GB Ram

At FGU start up - GPU ramps to over 60% and CPU use is under 25%

36045

With just a campaign loaded - the GPU spikes to nearly 100% and drops to around 75%

36046

With a just one map opened - the GPU pegs at 100% with the CPU at around 25%.

36047

I know its an old machine, but I still edit video (not 4K) on it with no problems.

[benmxs]

Hi guys,

we were facing simliar GPU problems in our new campaign with FGU yesterday. Had to fall back to the classic version. It's already our 2nd try with FGU. With regards to the acceptance of the app this develops towards a show stopper in our gaming round. Spending the whole evening with this again.

Only some people were facing the issue, seems like the high-end laptop faction only. My laptop (Dell XPS15 9560 with 32 GB RAM) was sweating in before unknown ways even when only the updater dialog was open. Not even the mouse pointer was running smoothly any longer.

I would really appreciate help here, please let me know if I can support in any ways.

Regards,
Ben

[StoicalZebra]

Yes same issue here with the latest build: 2020-06-30

2018 Mac mini
OS X 10.15.5
3 GHz 6-Core Intel Core i5
8 GB RAM
Intel UHD Graphics 630 1536 MB

GPU maxed constantly. CPU was fine.
Very Laggy character movement on the map. I had to have my DM move my icon around.

FGU was nearly unplayable. The GPU spikes had been noticeable in previous FGU builds, but not this bad.

[benmxs]

Any updates on the issue from the official side on this topic?

[zelannii]

need some guidance here. Clearly FGU can run off lesser GPUs, but on MBP it's consuming more than most video games on the dedicated GPU. even when I minimize the window to the background and it could not possibly be rendering, with no players connected to the game, it's grinding the GPU and thus the fan on the MBP runs at 100%. As we're gaming online in this pandemic, that also means the microphone is picking up the fan noise. Since I am the GM, I can't just keep muting all the time to keep that out. Was never an issue with FGC, only FGU.

MacBook Pro (16-inch, 2019)
2.6 GHz 6-Core Intel Core i7
16 GB 2667 MHz DDR4
AMD Radeon Pro 5300M 4 GB
Intel UHD Graphics 630 1536 MB
Using external second screen at 1440v resolution via Anker docking station so onboard GPU must be used to run the display, can't disable.

[vaughnlannister]

@zelannii, do you use a headphone set? The mic will be then further away from your MBP which could reduce it from picking up noise, also there are ways you can suppress background noises on discord for instance, but I am not aware of how well it works.

Yes I am with you on the need for optimisation on the macside, when opening a map my CPU is in the 100-130% range, I'm also running zoom which sucks up another 60% CPU. So hopefully they will be able to optimise it a bit more.

My best advice would be to run FGU in a bare-minimum set-up use very few extension and load only the modules you need. That greatly reduced the lag I was getting during gameplay with my DnD group. Which might reduce CPU/GPU.

I'm running a Macbook air 13-inch 2020, so its not an old model either like yours.

[caste381]

It has also an integrated card, maybe a Intel UHD Graphics 630, what pindecarl is asking you is if you are using the integrated video card or the Radeon 560x when executing the program.

Most programs run by default with the integrated card and you have to force them to use the other card.

It's a good point. However, I do not see heavy graphics in FGU to justify the need for a dedicated graphic card. It should work just fine with an integrated one.
I have software with 3d graphic which perform much better than FGU on my integrated card.
In my opinion it's just a matter of code optimisation

[AdamGM72]

I've also been running into this issue - for some reason FGU wants to run on the High Performance GPU (GeForce MX250) on my Dell Inspiron 15 rather than the Integrated Graphics, and this causes the fan to run full speed (and quite noisy). Note that this is occurring even with FGU running and not displaying any windows other than Chat, so it's not a CPU / GPU intensive situation. I suspect that Unity is somehow involved - either Unity (being a gaming / graphics platform is specifying that FGU run on the best graphics available, or the Graphics environment in Windows 10 or the laptop hardware? is causing this.
Either way it's an undesireable circumstance.
I've tried setting the NVidia 3D setting to force it to run on the integrated graphics, and even tried the "Run with graphics processor" option for FantasyGrounds.exe, still with no change.

39738

[Moon Wizard]

As far as I know, the FGU code does not do anything to choose video cards specifically; it just implements a 3D environment with multiple cameras to display all the various objects.

What percentage of utilization is the GPU running at for the tabletop for you? Mine runs at about 30-50% when idle; and fluctuates up and down depending on what is being looked at.

Regards,
JPG

[The Demiurge]

My question was erased from the forum and it was in regards to the macbook pro. You had responded Moon Wizard but the post was removed... Did you remove my post...?

Anyhow, FGU is not working as promised... Also when I download the mac version for FGU, I'm being forced to download ver. 4.00 on FGU for the Macbook. My question, is that the most recent version?? You asked me to download the most recent version, I did and it still spikes my battery usage and my fan kicks into high gear as if there is malware, BTC mining software or even a bloated ad one would come across on the reddit forums that causes the fan and cpu to run way too hot... I know there's a version out there that is later but it might be for windows, not sure...

Please confirm the most recent version for FGU on a macbook is 4.00. Is it 4.00? If it's NOT then the fantasy ground website is not up to date and is directing to download an older version of FGU...

Finally, I can't download the older version of FGC as supposedly the older FGC works without spiking the CPU... I updated my macbook for security reasons etc as most rational individuals do.. I will not downgrade the mac OS to where there are bugs and exploits so I can add FGC and Im not going to dual boot etc...

[The Demiurge]

My question was erased from the forum and it was in regards to the macbook pro. You had responded Moon Wizard but the post was removed... Did you remove my post...?

Anyhow, FGU is not working as promised... Also when I download the mac version for FGU, I'm being forced to download ver. 4.00 on FGU for the Macbook. My question, is that the most recent version?? You asked me to download the most recent version, I did and it still spikes my battery usage and my fan kicks into high gear as if there is malware, BTC mining software or even a bloated ad one would come across on the reddit forums that causes the fan and cpu to run way too hot... I know there's a version out there that is later but it might be for windows, not sure...

Please confirm the most recent version for FGU on a macbook is 4.00. Is it 4.00? If it's NOT then the fantasy ground website is not up to date and is directing to download an older version of FGU...

Finally, I can't download the older version of FGC as supposedly the older FGC works without spiking the CPU... I updated my macbook for security reasons etc as most rational individuals do.. I will not downgrade the mac OS to where there are bugs and exploits so I can add FGC and Im not going to dual boot etc...

[Trenloe]

My question was erased from the forum and it was in regards to the macbook pro. You had responded Moon Wizard but the post was removed... Did you remove my post...?
This thread?

https://www.fantasygrounds.com/forums/showthread.php?62287-Porting-over-FGC-(solo)-adventures-to-FoudryVTT

[The Demiurge]

I guess it's still there. :P

[LordEntrails]

Anyhow, FGU is not working as promised... Also when I download the mac version for FGU, I'm being forced to download ver. 4.00 on FGU for the Macbook. My question, is that the most recent version?? You asked me to download the most recent version, I did and it still spikes my battery usage and my fan kicks into high gear as if there is malware, BTC mining software or even a bloated ad one would come across on the reddit forums that causes the fan and cpu to run way too hot... I know there's a version out there that is later but it might be for windows, not sure...

Please confirm the most recent version for FGU on a macbook is 4.00. Is it 4.00? If it's NOT then the fantasy ground website is not up to date and is directing to download an older version of FGU...

Finally, I can't download the older version of FGC as supposedly the older FGC works without spiking the CPU... I updated my macbook for security reasons etc as most rational individuals do.. I will not downgrade the mac OS to where there are bugs and exploits so I can add FGC and Im not going to dual boot etc...

Version 4.0.0 is the latest version of FGU. BUT both the application and the updater will have date codes associated with them. This will tell you if you have the most recent version. Currently FGU application latest date code is 2020-09-24 and the Updater most current is date code is 2020-09-17.

FGC does not have older versions. You can only load the most current version of FGC, which is 3.3.11. But that version is not compatible with Mac o/s/ Catalina because it uses WINE which is a 32 bit application and Catalina does not run 32 bit apps.

If you mean the previous version of FGU, then you can access it via the "Prev" channel under advanced settings.

[Atarsamak]

Hi Moon Wizard,
did you ever try connecting your PC to a 4K monitor? I'm asking because, as I wrote in a previous post, I have the GPU running at 100% whenever I use it full screen on high resolution monitors (either my desktop with a 4k monitor or my laptop, a Lenovo Yoga 3 Pro on 3200x1800). I'm just curious to know, for peolple like you who are not experiencing the problem, what is the GPU usage when connecting to a 4k monitor. Thanks.

[The Demiurge]

"We're all wondering, though, how will apps run on day 1, when this first Apple Silicon Mac releases this year. ARM Macs running on Apple Silicon in 2020 seemed unlikely before this past week, as developers will want time to translate their apps from the Intel/x86 structure to the Apple Silicon/ARM code. Fortunately, Apple's also got a weapon in their back pocket that allows them to release Macs before everyone's caught up."

I'm wondering if FGU is currently looking to be ported over to the new macbook "silicon" ARM arch. Is this in progress? Maybe working with the ARM would be better for macs moving forward considering the heat/fan issues that have plagued FGU.

On a positive note I installed FGU on a 2019 Acer Predator 1660ti 16GB ram with Nvidia drivers up to date... and it run flawlessly. No fan issues at all.

[Sulimo]

"We're all wondering, though, how will apps run on day 1, when this first Apple Silicon Mac releases this year. ARM Macs running on Apple Silicon in 2020 seemed unlikely before this past week, as developers will want time to translate their apps from the Intel/x86 structure to the Apple Silicon/ARM code. Fortunately, Apple's also got a weapon in their back pocket that allows them to release Macs before everyone's caught up."

I'm wondering if FGU is currently looking to be ported over to the new macbook "silicon" ARM arch. Is this in progress? Maybe working with the ARM would be better for macs moving forward considering the heat/fan issues that have plagued FGU.

On a positive note I installed FGU on a 2019 Acer Predator 1660ti 16GB ram with Nvidia drivers up to date... and it run flawlessly. No fan issues at all.

The CPU utilization issue was something Moon Wizard (https://www.fantasygrounds.com/forums/showthread.php?61744-CPU-max-utilization-issue-on-MacOS-when-using-combat-tracker-is-duplicatable&p=544526&viewfull=1#post544526) commented about a week or so ago, it was a .net library issue, not sure if next release meant the one for the 24th, or if that one is still in progress.

I am not a dev, but for the ARM CPU at a minimum they would need to procure an actual development kit from Apple so they could start the process. Baring that, they would need to wait until there are Apple Silicon Macs available for purchase. Depending on resources available and/or funding, this might not happen right away.

I would guess they are fully aware of the shift that Apple is making. I also believe they have some time. It took Apple 3-4 years to switch from PowerPC to x86 chips back in the '00s. Apple announced the switch to x86 in 2005, and the first macOS version to require an Intel (x86) CPU was macOS 10.6 released in 2009. So the devs have some time to work out the logistics of how they want to make the switch. Apple says they will take 2 years, but I suspect that might end up being drawn out a bit.

I actually wonder about the future of Apple Silicon. Apple and Nvidia have some bad blood between them, with Nvidia purchasing Softbank (the makers of ARM), I wonder what Apple will have to say about that.

[LordEntrails]

The shift to ARM is one of the reasons FGU uses Unity. FG/SmiteWorks won't be the one making the investment in ARM changes, instead Unity will be the ones doing that and FG will just be updating the Unity engine version as appropriate.

[The Demiurge]

Excellent to hear!! I can't wait to put FGU on the new silicon macbook pro as it's not happening on my 2014 macbook pro with the high cpu usage issue currently..

[AdamGM72]

My assumption is the Unity configuration that is chosen by default for the FGU environment includes features that push the GPU on a mobile (MX) graphics card to the point where it goes into 'high use' mode. FGU may need to have some 'Graphics Quality' settings that allow users to reduce the graphics usage, particularly on lower specced graphics machines.

[Atarsamak]

The CPU utilization issue was something Moon Wizard (https://www.fantasygrounds.com/forums/showthread.php?61744-CPU-max-utilization-issue-on-MacOS-when-using-combat-tracker-is-duplicatable&p=544526&viewfull=1#post544526) commented about a week or so ago, it was a .net library issue, not sure if next release meant the one for the 24th, or if that one is still in progress.

I am not a dev, but for the ARM CPU at a minimum they would need to procure an actual development kit from Apple so they could start the process. Baring that, they would need to wait until there are Apple Silicon Macs available for purchase. Depending on resources available and/or funding, this might not happen right away.

I would guess they are fully aware of the shift that Apple is making. I also believe they have some time. It took Apple 3-4 years to switch from PowerPC to x86 chips back in the '00s. Apple announced the switch to x86 in 2005, and the first macOS version to require an Intel (x86) CPU was macOS 10.6 released in 2009. So the devs have some time to work out the logistics of how they want to make the switch. Apple says they will take 2 years, but I suspect that might end up being drawn out a bit.

I actually wonder about the future of Apple Silicon. Apple and Nvidia have some bad blood between them, with Nvidia purchasing Softbank (the makers of ARM), I wonder what Apple will have to say about that.

I'm not running on Mac. I'm afraid this will not fix my 100% GPU problem....

[The Demiurge]

I moved over to a PC for the time being. Make sure you have all drivers updated... Maybe you have a driver issue and need to roll back one update.

I use Nvida drivers but I haven't updated to the most recent patch seeing what people are posting. Ill update in week actually and take a chance. I'd be surprised and dismayed. Maybe my 2014 mac with 16 GB cant' handle FGU...? Not sure but I have no problems what so ever my 2019 Gaming PC with FGU except now the license states, ERROR. I emailed support about the issue but haven't heard back from them yet...

[AdamGM72]

Another thing that may help this - is anyone working on / aware of any GeForce Game Ready Settings (https://www.nvidia.com/en-us/geforce/geforce-experience/games/)? Could this be a way to 'limit' the graphics usage on lower end machines?

[AdamGM72]

This is further supported by some more observations from today; I have taken my laptop to the office and it is now connected to dual displays through a USB dock using DisplayLink. I get far lower GPU usage, ~10-15% for exactly the same display windows in FGU as I did when using the native screen. In both cases the Task manager indicates that the GPU is being used to render FGU, but it is obviously not needing 100% GPU usage. CPU usage is similar in both cases.

[pablomaz]

Hey, guys.

I've been having this same issue. FGU is using between 98-100% of my GPU (as a GM or as a player), which is a pretty old model, OK, but NOTHING I ever ran on this machine used up so much of it.

Windows 10 64bits
i7-4810MQ 2.80GHz
16GB RAM
GPU GeForce GTX860M 3GB

As someone before, I tried setting FGU to be run on the integrated graphics, but it didn't work. It only happens with FGU. FGC runs smoothly like a jazz pianist.

I couldn't find any meaningful response to this issue, which is obviously caused by FGU. Am I missing something here?

Thanks,

[Moon Wizard]

Do you have a copy of the campaign folder that is having the issue?
What windows were open at the time?
How many creatures are in the combat tracker?

Thanks,
JPG

[pablomaz]

Do you have a copy of the campaign folder that is having the issue?
What windows were open at the time?
How many creatures are in the combat tracker?

Thanks,
JPG

It happens with any campaign. Just created a new 5E campaign. No extensions nor modules loaded. No creatures on the CT. No players connected.

When the game is merely open, idle: 65-70% of GPU usage. All it takes is to open a single image (a very light 960x960 223kb jpeg) and GPU usage jumps to 93%.
I loaded the PHB, created several PCs and then populated the CT with them plus two creatures, and it was close to 95%.
(I'm talking about FGU usage of GPU alone.)
It's not much of a difference when I open my regular campaign, with extensions and modules open and no more than 9 creatures on the CT (94-96%). As the session goes, then it reaches 100% easily and constantly.
Oh, every single time I minimize FGU window to check another thing on the PC it goes up to 99%-100% as well, no matter what's happening on FGU.

[Chadarius]

OK so I am having the same issue. FGU was taking almost 100% of my GPU (Nvidia 1060) and it eventually crashed my whole laptop because it overheated. Last week I switched fantasy grounds over to running on my Nvidia GPU instead of the Intel one to get better performance. It seemed to run OK when I was testing it but tonight it was a total disaster. My laptop is literally too hot to touch and we've cancelled the rest of the game while my laptop cools down.

It was running a map with about 20 tokens on it. I had the tracker and about three other windows open. I wasn't doing much of anything interesting. This is a gaming laptop and I've run really hardcore games on it with out issues. It seems strange that a relatively static app like FGU would need anything more than a few percent of my Nvidia 1060 to run.

I also noticed that it seems to run even higher when another app is running in the foreground?

I'm not running any extensions other than a font extension to use the Liberation Sans and Liberation Serif fonts at a slightly larger size than the default.

[Chadarius]

So I let my GPU cool down and started everything back up again and the GPU utilization was back down to a more normal 8-10% while running FGU in the foreground or background now.

So I think something must trigger the GPU getting spiked wide open. I'll keep an eye on it and see if I can figure out what might be doing it.

[pablomaz]

So I let my GPU cool down and started everything back up again and the GPU utilization was back down to a more normal 8-10% while running FGU in the foreground or background now.

So I think something must trigger the GPU getting spiked wide open. I'll keep an eye on it and see if I can figure out what might be doing it.

I'm not that lucky. Still a hot mess last night again.

[The Demiurge]

The new 13" macbook pro ARM will be released next month.

The developers MUST purchase this model and if applicable the rumored 12" macbook pro, and see if the CPU / GPU usage is also spiking on these base model laptops. Neither the 13" or 12" will have dedicated GPU's (I highly doubt they will) but they will have quadcore cpu's instead of dual core cpu's.

I know that Foundry's VTT is a little less intensive on the the cpu but not by much...

Either way they need to be tested out to see if the 12" and 13" ARM model macbook pro's can handle FGU this November.

[LordEntrails]

Actually, it will be up to the developers of the Unity platform to first test out Unity on the new platform etc. Then once Unity itself is supported on ARM, then FGU can be updated to use whatever updates in the numerous Unity libraries FGU uses to support ARM. Don't expect ARM support for Unity or FGU next month. Personally I wouldn't expect reliable ARM support until 12 months after release of a new architecture. But then again, I've never like being on the bleeding edge.

[Valyar]

The industry won't jump immediately on the ARM-based Macs bandwagon. Apple also realize that and mentioned in the keynotes that Rosetta 2 will support the users in the transition period, until applications are ported to ARM where possible. The whole thing is **** move from Apple, but it is their second nature.

[Recurse]

Actually, it will be up to the developers of the Unity platform to first test out Unity on the new platform etc. Then once Unity itself is supported on ARM, then FGU can be updated to use whatever updates in the numerous Unity libraries FGU uses to support ARM. Don't expect ARM support for Unity or FGU next month. Personally I wouldn't expect reliable ARM support until 12 months after release of a new architecture. But then again, I've never like being on the bleeding edge.

Unity already has support for Apple Silicon. Obviously no computers that have Apple Silicon are available yet and timing of the rumored Mac laptop are just that, rumors. Agreed that it's a ways off for wide support. Regardless, I'm looking forward to what developers do with this, and of course FGU =)

Straight from the Unity developer themselves:
https://blogs.unity3d.com/2020/06/22/unity-coming-to-apple-silicon/

[pablomaz]

"At this point, the program is running great and we don't expect any more critical updates."

It's kind of revolting to read that, having to deal with FGU using 100% of my GPU.

[Moon Wizard]

Carl and I have talked about this a fair amount over time. We're not sure that the Unity engine respects the target 60 fps frame rate we set on all systems; or those systems are running at a lower than 60 fps in hardware. We've suspected this for a while; but I was a bit leery of changing a core setting. Carl reached out to pablomaz, and was able to verify that it worked in their scenario. So, we're going to give it a run in the next release build.

So, we're going to switch back to synch FPS to OS display frame rate (depends on OS and monitor) by default. Then, we're going to add a "/vsync [0-4]" command to allow us to adjust this option with users that might still have connection issues, until we're sure we understand completely. (0 = fixed 60 fps, 1 = match OS frame rate, 2 = half OS frame rate, 3 = third OS frame rate, 4 = quarter OS frame rate)

Regards,
JPG

[pablomaz]

Carl and I have talked about this a fair amount over time. We're not sure that the Unity engine respects the target 60 fps frame rate we set on all systems; or those systems are running at a lower than 60 fps in hardware. We've suspected this for a while; but I was a bit leery of changing a core setting. Carl reached out to pablomaz, and was able to verify that it worked in their scenario. So, we're going to give it a run in the next release build.

So, we're going to switch back to synch FPS to OS display frame rate (depends on OS and monitor) by default. Then, we're going to add a "/vsync [0-4]" command to allow us to adjust this option with users that might still have connection issues, until we're sure we understand completely. (0 = fixed 60 fps, 1 = match OS frame rate, 2 = half OS frame rate, 3 = third OS frame rate, 4 = quarter OS frame rate)

Regards,
JPG

John (and Carl), thanks for assessing this issue. Can't wait to see that up and running... Hopefully it will solve this problem, or minimize it...
Regards,

[Frodie]

I am fixing to get a new video card just to run FGU, any suggestions on what to get.

[Neovirtus]

I am fixing to get a new video card just to run FGU, any suggestions on what to get.

https://www.fantasygrounds.com/forums/showthread.php?50373-FGU-Early-Access-Overview-and-Download

See System Specifications there. For Video Cards the minimum is 2 GB of RAM, they recommend 4 GB. There are new cards coming out right now (Nvidia 3000 series, and AMD's RX 6000 series are being announced tomorrow I think). While all the new stuff is definitely overkill for FGU, it is also going to be the best performance for the money. By buying older cards new or used, you'll be able to pay less, but you'll get less performance/$. It all comes down to what your budget is, and if you're interested in high end gaming performance or just running FG.

[pablomaz]

Hey, guys.
Just to let you know now I'm a aware that a player of mine is having the same issue.

[Moon Wizard]

The system frame rate matching change just went to Live channel. In this build, by default, the frame rate will match the system frame rate (defined by OS and monitor).
To override, you can type "/vsync #" into chat window while tabletop is running. You should only use if you've reported an issue, and we've asked you to try some other settings.

Regards,
JPG

[EllivasKram]

I have users with let’s say less than ideal specs of laptops. Recently unity has been hammering my machine and theirs with GPU Max’d. Admittedly with 20+ NPC’s. I turned off LOS in the end and used masking until the encounter was finished.

I have tried /VSYNC 2 and I have noticed my machine is a lot cooler and I’m going to ask my players to do the same. Any reason this is an issue. Seems to be fine on testing.

I have gone from 80% GPU to 36%. I’m hoping some of the recent lag for my PC’s will be gone as my machine has more resources for servicing their connections.

Am I just not understanding correctly how limiting GPU usage, like this , affects the unity engine local and remote user experiencing sluggish performance issue. On initial testing user experience is improved with /vsync 2 in my laptop.

GPU intel HD Graphics 620 and i5 and 4K monitor

N.B. I would say reversing the locked refresh rate is a good thing. It added sluggish performance for me. Now it’s just 80% load on default /VSYNC and I can adjust.

[Moon Wizard]

It affects how smoothly that graphics move on the screen including dice and tokens. At lower high vsync rates, the Unity engine and graphics card are basically skipping frames to improve performance.

Regards,
JPG

[caste381]

Hi All,

QQ: I understand there is a lot going on around testing and improvement. That's great to hear.
What I fail to comprehend is why the CPU/GPU is being heavily utilised when no one is doing anything? Or even without players connected. Surely in those cases we are just dealing with a static image with no need to dynamic calculations? I would expect utilisation close to 0%.
I am comparing this to the behaviour I see in other software. Especially apps that should be heavier than FGU but perform much better.
Unless I am missing something.
Thank you

[pablomaz]

The system frame rate matching change just went to Live channel. In this build, by default, the frame rate will match the system frame rate (defined by OS and monitor).
To override, you can type "/vsync #" into chat window while tabletop is running. You should only use if you've reported an issue, and we've asked you to try some other settings.

Regards,
JPG

Hey, Moon Wizard.
I'm glad now I have the ability to limit the fps - I don't believe anyone needs FGU running with 60fps (my system default). I've been able to test it for a couple of hours (no players connected), and GPU usage has been drastically reduced when caped to 30fps and, especially, to 20fps (apparently good enough for dice rolling and token movement).

Why you don't recommend everyone setting vsync, though?

I couldn't thank you guys enough for taking care of this issue. I'm glad I'll be able to run FGU as smoothly I used to run FGC from now on and I hope you guys figure it all out with a permanent solution.

[Moon Wizard]

@pablomaz,
To me personally, I notice the difference between 60fps and lower frame rates. (i.e. dice rolling, window dragging, token movement). Also, this does not appear to be a general issue for all users. When running at the default vsync 1 (60fps on my machine), I only see 20-30% GPU utilitization, and 2% CPU utilization.

@caste381,
There is a misunderstanding that FGU is somehow a simple static application. However, we're using a game engine (Unity) which requires frames to be drawn at the given frame rate, regardless of whether anything changes on screen. Also, FG is a platform, so we have to build it so that any combination and number of tabletop windows/fields can be displayed in addition to 3D dice. Also, many other games can downscale graphics when needed for performance, which isn't something we can do without directly affecting the end user experience. I'm not saying that there are not more optimizations that we could make in the future, but the focus is on making FG perform all the functions that it needs to and that we would like it to. The new vsync setting is to allow people with video cards which struggle with the Unity engine settings to scale back the frame rate.

Regards,
JPG

[caste381]

@pablomaz,
To me personally, I notice the difference between 60fps and lower frame rates. (i.e. dice rolling, window dragging, token movement). Also, this does not appear to be a general issue for all users. When running at the default vsync 1 (60fps on my machine), I only see 20-30% GPU utilitization, and 2% CPU utilization.

@caste381,
There is a misunderstanding that FGU is somehow a simple static application. However, we're using a game engine (Unity) which requires frames to be drawn at the given frame rate, regardless of whether anything changes on screen. Also, FG is a platform, so we have to build it so that any combination and number of tabletop windows/fields can be displayed in addition to 3D dice. Also, many other games can downscale graphics when needed for performance, which isn't something we can do without directly affecting the end user experience. I'm not saying that there are not more optimizations that we could make in the future, but the focus is on making FG perform all the functions that it needs to and that we would like it to. The new vsync setting is to allow people with video cards which struggle with the Unity engine settings to scale back the frame rate.

Regards,
JPG

Thank you. That’s very clear now.
Regards.

[pablomaz]

@pablomaz,
To me personally, I notice the difference between 60fps and lower frame rates. (i.e. dice rolling, window dragging, token movement). Also, this does not appear to be a general issue for all users. When running at the default vsync 1 (60fps on my machine), I only see 20-30% GPU utilitization, and 2% CPU utilization.

@caste381,
There is a misunderstanding that FGU is somehow a simple static application. However, we're using a game engine (Unity) which requires frames to be drawn at the given frame rate, regardless of whether anything changes on screen. Also, FG is a platform, so we have to build it so that any combination and number of tabletop windows/fields can be displayed in addition to 3D dice. Also, many other games can downscale graphics when needed for performance, which isn't something we can do without directly affecting the end user experience. I'm not saying that there are not more optimizations that we could make in the future, but the focus is on making FG perform all the functions that it needs to and that we would like it to. The new vsync setting is to allow people with video cards which struggle with the Unity engine settings to scale back the frame rate.

Regards,
JPG

Oh, I DO notice the difference, but if I have to choose between great performance + good enough fps or painful performance + as good as it gets (60) fps, no doubt I will chose the first option...
My machine is still pretty good by many standards, but certainty not as a gamer laptop - not anymore. Running anything on 1920x1080 at 60fps will be a pain. There's no need for me to see those yellow dice rolling that smoothly, man. :- )

Well, thanks again, Moon Wizard!
Best regards!

[Weissrolf]

FGU having to constantly redraw the screen even when nothing happens is one drawback compared to FGC. In Classic there is zero screen drawing and no GPU/CPU usage when nothing moves, screen output is effectively frozen unless you happen to move the mouse over certain elements.

[caste381]

FGU having to constantly redraw the screen even when nothing happens is one drawback compared to FGC. In Classic there is zero screen drawing and no GPU/CPU usage when nothing moves, screen output is effectively frozen unless you happen to move the mouse over certain elements.

That's exactly what I could not get my head around. It did not make sense until JPG explained the architectural difference. I find it strange though that Unity will not account for that and automatically adjust the framerate. Every piece of software I used in the past does it and the FPS drops to zero if there is no movement.
Anyhow, I am not a developer and probably I do not understand the implications

[Headshot Robot]

Thought I might add my 2 cents.

I was also getting 80% utilization on a 2080ti with the latest updates. After checking in Steam I saw that FG was running at 2300 FPS. I had to enable Vsync for FG in the Nvidia control panel to bring it in line.

Thanks for all the hard work, guys. Love the app.

[caste381]

A friend of mine mentioned that Unity supports on demand rendering, which would lower frame rate when nothing is changing on screen.
It might be a superfluous question but could this feature help?

[pindercarl]

Thought I might add my 2 cents.

I was also getting 80% utilization on a 2080ti with the latest updates. After checking in Steam I saw that FG was running at 2300 FPS. I had to enable Vsync for FG in the Nvidia control panel to bring it in line.

Thanks for all the hard work, guys. Love the app.

Thanks. As you have discovered, you should not disabled vsync in the graphics settings. I would be hard pressed to come up with any graphics card settings that would have a positive impact on FGU.

[Headshot Robot]

Never disabled it, I just don't keep it on every program by default. Sometimes 500+ frames is what i want. Maybe others have the same setup.

[pindercarl]

A friend of mine mentioned that Unity supports on demand rendering, which would lower frame rate when nothing is changing on screen.
It might be a superfluous question but could this feature help?

OnDemandRendering allows the programmer to temporarily reduce the frame rate. It does not detect when such an action would be appropriate.

[caste381]

OnDemandRendering allows the programmer to temporarily reduce the frame rate. It does not detect when such an action would be appropriate.

Oh, I see. Thanks for answering!

[pindercarl]

Never disabled it, I just don't keep it on every program by default. Sometimes 500+ frames is what i want. Maybe others have the same setup.

The default global OS setting for vertical sync is "Use the 3D application setting." If this is not your setting, then you have overridden the value. I just want to make sure that I'm understanding the situation and this is not a bug. Thanks.

[Headshot Robot]

The default global OS setting for vertical sync is "Use the 3D application setting." If this is not your setting, then you have overridden the value. I just want to make sure that I'm understanding the situation and this is not a bug. Thanks.

Yup, you're right. Thanks again.

[Neovirtus]

I've had reasonable performance since all the optimization of lists went out so I had never thought to characterize it, but this discussion made me curious. My FGU is correctly limiting itself to 144Hz, but tasks as simple as resizing a window or dragging the window around the display area cause the FPS to tank. I ran a 60 second test and during that time I just dragged the Image window around, opened a couple images from modules, zoomed in and out, etc. My minimum FPS was 39 (!!!).

System:
Acer Predator PH315-52
Geforce GTX 1660 Ti
Intel Core i7-9750H @ 2.60 GHz
16 GB RAM
1920 x 1080, 144 Hz

Campaign loaded:
v4.0.1 Ultimate (2020-11-10)
No Players Connected
D&D 5E
Theme: D&D - Official
Multiple Desktop Decal options loaded

Modules Loaded:
A homebrew NPC Module
Rob Twohy 5e Conditions & Effects
Rob Twohy 5e Effects Coding - Spells
DMG
MM
PHB
Tome of Beasts 2
D&D RftLW
Archetypes of Eberron
Creature Codex
Unearthed Arcana
MToF
VGtM
XGtE
Exploring Eberron

I know it's a lot of modules... but I'd be surprised if that increased the load due to moving a frame around, or loading an image.

[Weissrolf]

Problem is that FGU is CPU (single-thread) bottlenecked. You can throw all your GPU power at it, but it won't matter much.

[Neovirtus]

Problem is that FGU is CPU (single-thread) bottlenecked. You can throw all your GPU power at it, but it won't matter much.

There are lots of games that are single threaded, and still perform fine. I don't think it's the albatross you make it out to be, but I could be wrong.

[Weissrolf]

Those games are either optimized accordingly then or suffer from the same issues. Once the one CPU core is fully loaded something has to suffer, be it frame-rates or other processing.

Let's say this in another way: FGU hardly even taxes my RTX 2070 Super, but my frame-rates still drop when the single thread is overloaded.

[caste381]

The last couple of updates look great on Mac. Well done!
However, the high CPU/GPU utilisation still persists, even with no players and an empty campaign. Is there anything I can provide to help troubleshooting?
Thanks

[pablomaz]

The last couple of updates look great on Mac. Well done!
However, the high CPU/GPU utilisation still persists, even with no players and an empty campaign. Is there anything I can provide to help troubleshooting?
Thanks

caste381, did you read the last couple of pages of this thread? /vsync for the win!

[caste381]

caste381, did you read the last couple of pages of this thread? /vsync for the win!

Hi Pablo. Yeah, been following this for a while now. I did use the /vsync, which halves utilisation down to 20/30% but performance is very poor. Let's face it: /vsync is a hack and does not solve the core issue: when nothing is happening on screen, there should be virtually no resources utilisation. This is what I see with all other software, even much more graphically elaborate than FGU

[pindercarl]

Hi Pablo. Yeah, been following this for a while now. I did use the /vsync, which halves utilisation down to 20/30% but performance is very poor. Let's face it: /vsync is a hack and does not solve the core issue: when nothing is happening on screen, there should be virtually no resources utilisation. This is what I see with all other software, even much more graphically elaborate than FGU

Can you post your results with each vsync setting (/vsync [0-4])? Thanks.

[caste381]

Can you post your results with each vsync setting (/vsync [0-4])? Thanks.

Hello. Please see screenshots below.
They were taken on a new, empty LAN 5E campaign. One JPG open (a banner from this forum).

Thank you.

41117
41118
41119
41120
41121

[pindercarl]

Hello. Please see screenshots below.
They were taken on a new, empty LAN 5E campaign. One JPG open (a banner from this forum).

Thank you.

41117
41118
41119
41120
41121

The numbers for VSYNC1 appear aberrant, but I can extrapolate the numbers from the other three data points. What hardware are you running?

[caste381]

The numbers for VSYNC1 appear aberrant, but I can extrapolate the numbers from the other three data points. What hardware are you running?

Hi Pindercarl.
These screenshots were taken on a MacBook Air 2020 with maxed CPU and RAM: 1.2 GHz Quad-Core Intel Core i7, 16 GB 3733 MHz.
Please note I had the same problem with my previous hardware, a MacBook Pro 2018 2.7 GHz Quad-Core Intel Core i7, 16 GB 2133 MHz. I haven't tested this laptop in the last few months, though.

Thank you

[Daso]

So, we're going to switch back to synch FPS to OS display frame rate (depends on OS and monitor) by default. Then, we're going to add a "/vsync [0-4]" command to allow us to adjust this option with users that might still have connection issues, until we're sure we understand completely. (0 = fixed 60 fps, 1 = match OS frame rate, 2 = half OS frame rate, 3 = third OS frame rate, 4 = quarter OS frame rate)

Regards,
JPG

woah! this is huge! could this setting be moved to the settings window instead of it being a console command only? I had no idea this existed, but it'll help out a lot of players with slower systems.

[caste381]

Hello,

Are there any updates re data I sent back in November?
Thank you.

[Moon Wizard]

I asked Carl about this; but he said that the info you sent shows 50% GPU at /vsync 0; scaling down to 20% GPU at /vsync 3. It is expected that there is a non-trivial baseline for GPU utilization, even for just the basic tabletop.

Regards,
JPG

[Weissrolf]

Task-Manager (and most other software) measures GPU utilization based on the current GPU clock-rate. So when GPU load is low and GPU clock-rate is lowered to save energy then the measuring software will display a higher GPU load.

Disabling my GPU's power-saving option and opening the default set of FGU windows results in about 6.3% GPU load at 1605 MHz on my RTX 2070 Super. The same FGU windows measure as 34% with power-savings enabled at 405 MHz.

PS: I don't understand the use for offering /vsync 0. It neither syncs nor fully reaches 60 fps. It does lower load to around 6% on my rig, but only because of slightly lower fps and frame-times are less smooth.

[pablomaz]

Hey guys.
/vsync stoped working after that huge update last month? GPU usage is going through the roof again.

[EllivasKram]

When people say my RTX2070 is fine. It makes me laugh. I would hope that card wouldn’t even notice a GPU load at all. In the world that surely FGU needs to be in to have a significant and healthy user base the GPU requirements need to be a little more sensible.

Maybe SW can suggest 3DMark scores required for features like LOS and VISION

[Neovirtus]

My laptop has a 1660 Ti gfx card and performs just fine. I think the issue is certain configurations causing inordinate amounts of gpu load, and not that a 2070 is required, as it certainly isn't.

[Weissrolf]

FGU 4.1 beta - RTX 2070 Super - energy saving disabled (!) = fixed clock-rate

No LoS, no lighting:
https://i.imgur.com/NNvRxM8.png

LoS, no lighting:
https://i.imgur.com/hv1yiHl.png

LoS, lighting:
https://i.imgur.com/GF8Oyae.png

LoS, lighting, Vsync 4:
https://i.imgur.com/tyeFxTb.png

[LordEntrails]

It seems like the higher end cards try to do more, and hence load themselves up. I'm using a NVidia K1100M on an old (~2006) Precision M3800 and don't have any issues.

[Weissrolf]

Most of the time FGU is CPU limited and thus doesn't even fully utilize the GPU (= fps drops due to CPU).

[Sulimo]

When people say my RTX2070 is fine. It makes me laugh. I would hope that card wouldn’t even notice a GPU load at all. In the world that surely FGU needs to be in to have a significant and healthy user base the GPU requirements need to be a little more sensible.

Maybe SW can suggest 3DMark scores required for features like LOS and VISION

One of the issues that MW has mentioned is if the Video Card Drivers are overriding the FGU setting. Most video drivers have the capability to enforce their settings, and that basically ignores the /vsync setting in FGU.

See if there is a setting in your graphics driver to tell it to not override FGU.

[Vyder]

This pic is with one map open trying to edit the LOS already on the map. I'm getting frequent hourglass/white screen. Sometimes with every click of the mouse.

44961

[Weissrolf]

Hourglass/whitescreen is a CPU overload scenario, in which case the GPU load should even drop. So usually it is a different kind of problem.

[Vyder]

Hourglass/whitescreen is a CPU overload scenario, in which case the GPU load should even drop. So usually it is a different kind of problem.

I'm not seeing much CPU use when this is happening. Task manager shows around 30% when i get the hourglass/whitescreen. Any idea what to check?

[Weissrolf]

This is because FGU mostly only uses a single CPU core, more specifically the LUA engine does. When this core is maxed you see the result as the application "not responding" to Windows anymore. You can throw dozens of (unused) cores and lots of money at the problem, but it will not improve (except CPUs with high single-core performance = winner).

I wonder if a more current LUA engine would at least improve performance, despite still being single-threaded (FGU uses an old version)?!

[Vyder]

This is because FGU mostly only uses a single CPU core, more specifically the LUA engine does. When this core is maxed you see the result as the application "not responding" to Windows anymore. You can throw dozens of (unused) cores and lots of money at the problem, but it will not improve (except CPUs with high single-core performance = winner).

I wonder if a more current LUA engine would at least improve performance, despite still being single-threaded (FGU uses an old version)?!

Is there a way to monitor what each core is doing?

[Vyder]

Now i see it. One core goes of the chart when i get the hourglass/whitescreen. I did have a bunch of console errors at one point earlier today saying something about a token and LUA. I have re started a few times since so i don't see the errors anymore.

44962

[GM BK]

It appears I'm running into this issue as well. It's a slightly older laptop, about 7 years. It's my back-up, but I like to prep from it. Any help would be much appreciated :)

44963

[LordEntrails]

It appears I'm running into this issue as well. It's a slightly older laptop, about 7 years. It's my back-up, but I like to prep from it. Any help would be much appreciated :)
Which issue? If you are not seeing performance issues or lag, then you can be ok running at near 100 percent GPU. That's to be expected with some GPU drivers as they lower the GPU clock speed to save power and use closer to 100 percent.

If you are seeing actual performance issues in FGU, the you need to tell us which ones, as well as your ruleset, extensions, modules loaded, and what you are doing. For instance; if you running on a 10 GB map with 200 combat tracker tokens and 10,000 LOS elements, yea, any machine is going to have performance problems. But on the other hand, if you are running 5E with no extensions and just the SRD modules loaded and using one of the simple maps from the FG Battle maps and only have 8 tokens on the map, then their is an issue.

Gotta provide the details so we can help figure out what's up :)

[Moon Wizard]

@LordEntrails has the correct idea for how GPU performance should be viewed and/or identified as an issue.

Also, just a quick note that Carl added some performance improvements to the blurring routines that were causing higher GPU usage than expected in some lighting scenarios. That beta release went out today.

Regards,
JPG

[Vyder]

I'm not sure if my issue is GPU or CPU. I get the hourglass/whitescreen very often for a few seconds at a time when editing the keep on the boderlands high res map. I did not have this problem when adding the LOS it only started happening when i went back to clean it up. When i have players join i get the hourglass/whitescreen every few minutes. The map also crashes FGU when i lock the map and hit the arrow to make the window goto background. If the map is unlocked it will not crash but loose the movement widget. I have 4 layers ,PC high res, High res, Paint layer and a LOS layer. I have 7 PC's in the combat tracker and no pre loaded npc's on the map. I do have all the pins on the map for the module.

2e
New Campaign
Tried with and without Extensions. Using AudioOverseer and Keep on the boderlands decal.
KoTB, PH, MM and DMG
Win 10, 16 gig memory, Amd fx-9550 CPU, Hd Radeon 7900 GPU

[Moon Wizard]

Can you provide a copy of the campaign folder zipped up via a file-sharing link?

We would be testing without extensions of any custom graphics installed. If you are using an image outside the campaign folder, please provide that with the campaign folder as well.

Thanks,
JPG

[GM BK]

Which issue? If you are not seeing performance issues or lag, then you can be ok running at near 100 percent GPU. That's to be expected with some GPU drivers as they lower the GPU clock speed to save power and use closer to 100 percent.

If you are seeing actual performance issues in FGU, the you need to tell us which ones, as well as your ruleset, extensions, modules loaded, and what you are doing. For instance; if you running on a 10 GB map with 200 combat tracker tokens and 10,000 LOS elements, yea, any machine is going to have performance problems. But on the other hand, if you are running 5E with no extensions and just the SRD modules loaded and using one of the simple maps from the FG Battle maps and only have 8 tokens on the map, then their is an issue.

Gotta provide the details so we can help figure out what's up :)

I guess I should've mentioned that performance has taken a hit. :) Mostly I see it when I click on something or try to input text. It hangs for a second or two.

I don't run any extensions, my version is bare bones, and all I'm usually doing is prep work... building NPC's, importing images, creating story entries, etc. Nothing fancy, and I'm the only person logged on.

Hope that helps and thanks for chiming in! :)

Edit: All other stats look good. Processer is under 50%, as is RAM usage as well. The only thing that's up there is GPU. That starts at 70%, but as soon as I start doing stuff it jumps to 90%

[Vyder]

Can you provide a copy of the campaign folder zipped up via a file-sharing link?

We would be testing without extensions of any custom graphics installed. If you are using an image outside the campaign folder, please provide that with the campaign folder as well.

Thanks,
JPG

https://drive.google.com/file/d/1Xt7Y8_LK1V43_qidEb7STudmAhIT3CjV/view?usp=sharing
https://drive.google.com/file/d/1uzK4QyxGflkv-rmp97XaZAI1lg0kokaQ/view?usp=sharing
https://drive.google.com/file/d/16aWk1quOeXy6m33AFRiXQpVU8jHyqoj4/view?usp=sharing

[caste381]

Is anyone aware of where/if something can be changed on a Macbook re graphic drivers to reduce utilisation?

Thanks,

[LordEntrails]

Is anyone aware of where/if something can be changed on a Macbook re graphic drivers to reduce utilisation?

Thanks,
chat command
/vsync #
where # is 0, 1, 2, 3, or 4

[Weltenbrand]

Could the vsync options and the meaning of the numbers be out in the Fantasy Grounds Unity User Manual?
I always have to search the meaning inthe forum.

[caste381]

chat command
/vsync #
where # is 0, 1, 2, 3, or 4

Thank you.

For me that command does not really solve the issue as utilisation is only marginally reduced or performance is badly affected

[Weissrolf]

It seems that CPU and GPU performance issues are mixed up in this thread.

[caste381]

It seems that CPU and GPU performance issues are mixed up in this thread.

On my Macs I have always experienced both high CPU and GPU

[Moon Wizard]

@Vyder,

I got your module. The image is very large (150 mega-pixels). It bumps memory usage on my machine from 2.6GB just loading campaign to 6.2GB loading that high-res map. I'm also seeing that the number of occluder points on the map is very high and very detailed which can have an impact when LoS is on. I also see hesitations every few seconds.

I will forward this to @cpinder to see if there are any optimizations that can be made; but most likely, you're going to have to use a lower-res version of the map (or maybe the one included in the module).

Regards,
JPG

[Vyder]

@Vyder,

I got your module. The image is very large (150 mega-pixels). It bumps memory usage on my machine from 2.6GB just loading campaign to 6.2GB loading that high-res map. I'm also seeing that the number of occluder points on the map is very high and very detailed which can have an impact when LoS is on. I also see hesitations every few seconds.

I will forward this to @cpinder to see if there are any optimizations that can be made; but most likely, you're going to have to use a lower-res version of the map (or maybe the one included in the module).

Regards,
JPG

Thanks for taking a look. I have the same problem when i use the one that came with the module. Every few minutes i get the hourglass/whitescreen. Is there anything on my end i can try? Per my specs i listed will upgrading any of those help? My GPU is a bit outdated but the rest isn't very old.

[pindercarl]

Thanks for taking a look. I have the same problem when i use the one that came with the module. Every few minutes i get the hourglass/whitescreen. Is there anything on my end i can try? Per my specs i listed will upgrading any of those help? My GPU is a bit outdated but the rest isn't very old.

I did not see this indicated in any previous post, but what resolution are you running? A 4K display, for example, can push FGU just as hard, or harder, than a complex map.

[Weissrolf]

PC Windows 10 - Caves of Chaos-PC_highres:

Windowed mode - window resized to fill full screen - zoom to match desktop/max mode content
https://i.imgur.com/XokF2U1.png

Desktop/maximized mode - supposedly zoom to fit
https://i.imgur.com/kRej12X.png

Why do I write "supposedly"? Because not only do the two maximized modes turn mild GPU load into GPU overload, but zoom to fit/fill also only shows a small portion of the map. In windowed mode zoom to fit works properly.

https://i.imgur.com/Be1zsK9.png vs. https://i.imgur.com/e8h0jYN.png

So the map itself is not much of a problem on my system, but going desktop/max size is. Here is the load of the small SW "Battlemap01" for comparison, no difference compared to the large campaign map in windowed mode, but desktop/max is just as low as windowed when Battlemap01 is used.

https://i.imgur.com/RiGDnVj.png

I'd start from there. If needed I can test this map on a Macbook Pro 2018 for comparison.

[Weissrolf]

On a side note: When I first tested Battlemap01 I noticed that all LoS "shadows" were very low-res (large stair-steps, as in dozens of pixels, not single ones), just like the low res shadows of various older games (Battlefield 2 comes to mind). Then I wrote the last post, returned to FGU (unfortunately also maxed the window once more) and now the "shadows" are normal again. No difference in GPU load between the two different "shadow" resolutions, though.

[MrDDT]

Thanks for taking a look. I have the same problem when i use the one that came with the module. Every few minutes i get the hourglass/whitescreen. Is there anything on my end i can try? Per my specs i listed will upgrading any of those help? My GPU is a bit outdated but the rest isn't very old.

It's much less to do with the res of the image and almost all to do with the number of LOS points and tokens on the screen. If you cut those down, you will find it doesnt lag near as much.
However, the more you push into things like image size and LOS points the worse it gets. I tend to use very large images and do not have problems until I start adding a ton of LOS points. You can ez find out if its LOS or not by simply turning off LOS and see if it still has the issue.

[MrDDT]

I did not see this indicated in any previous post, but what resolution are you running? A 4K display, for example, can push FGU just as hard, or harder, than a complex map.

I run at 5760 x 2160, and I have no issues on maps unless LOS points are high. Even small maps or low res with a lot of LOS points can have issues. My GPU is a little older too on a 1080TI.

[Vyder]

I did not see this indicated in any previous post, but what resolution are you running? A 4K display, for example, can push FGU just as hard, or harder, than a complex map.

16 gig memory, Amd fx-9550 CPU, Hd Radeon 7900 GPU
Im not running 4K. My monitors are 1900x1200

[Weissrolf]

Thanks for taking a look. I have the same problem when i use the one that came with the module. Every few minutes i get the hourglass/whitescreen. Is there anything on my end i can try? Per my specs i listed will upgrading any of those help? My GPU is a bit outdated but the rest isn't very old.
The only thing you can throw at FGU is a CPU with the highest possible per core performance. Multiple cores do next to nothing for you, you need high clock-rates and large caches. GPU likely doesn't matter in your situation unless maybe its VRAM is too small. But even with the most powerful desktop CPU in the world current FGU performance will be a let-down for your use-case (and partly mine).

FGU's performance just isn't good enough for having many LoS elements on a map. I blame FGU more than I would blame your hardware. You could disable LoS and do manual unmasking, but then you would forfeit one of the main reasons to switch from Classic to Unity.

I think the main problem is that with every token movement FGU calculates all LoS points on the map, regardless of the fact that the token only sees a small fraction of them (up to the next wall). Even masking other regions out does not help there. I consider this either a bug or at least bad design.

And now comes the workaround that helps us get around FGU's limitation and get on with life until the issue is maybe fixed:

https://i.imgur.com/yb8rj4T.gif

- Create a duplicate of the original LoS layer.
- Disable the original LoS layer.

- On the duplicate LoS layer delete *all* LoS areas that your party is not going to play in for the current session!

This will cause FGU to only calculate the LoS points that you left intact on the duplicate layer. It shouldn't calculate all those invisible behind walls points anyway, but it does, so we need to trick it into submission.

- Next session you delete the duplicate LoS layer and create a new duplicate of the original LoS layer. Wince and repeat.

One hint for your campaign: You use two nearly identical high-res images on top of each other, seemingly only to switch on/off the room labels. I would ditch the extra map to save RAM and instead stamp those room label letters onto a single map as an extra layer. Main problem I see is that I did not find a way to switch visibility on/off for GM only, without cycling through "Visible to all".

PS: After restarting FGU the large Caves map does not overload my GPU anymore when the map windows is maxed. Still looks like a bug that should not happen.

[caste381]

The only thing you can throw at FGU is a CPU with the highest possible per core performance. Multiple cores do next to nothing for you, you need high clock-rates and large caches. GPU likely doesn't matter in your situation unless maybe its VRAM is too small. But even with the most powerful desktop CPU in the world current FGU performance will be a let-down for your use-case (and partly mine).

FGU's performance just isn't good enough for having many LoS elements on a map. I blame FGU more than I would blame your hardware. You could disable LoS and do manual unmasking, but then you would forfeit one of the main reasons to switch from Classic to Unity.

I think the main problem is that with every token movement FGU calculates all LoS points on the map, regardless of the fact that the token only sees a small fraction of them (up to the next wall). Even masking other regions out does not help there. I consider this either a bug or at least bad design.

And now comes the workaround that helps us get around FGU's design flaw and get on with life until the issue is maybe fixed:

https://i.imgur.com/yb8rj4T.gif

- Create a duplicate of the original LoS layer.
- Disable the original LoS layer.

- On the duplicate LoS layer delete *all* LoS areas that your party is not going to play in for the current session!

This will cause FGU to only calculate the LoS points that you left intact on the duplicate layer. It shouldn't calculate all those behind many walls points anyway, but it does, so we need to trick it into submission.

- Next session you delete the duplicate LoS layer and create a new duplicate of the original LoS layer. Wince and repeat.

One hint for your campaign: You use two nearly identical high-res images on top of each other, seemingly only to switch on/off the room labels. I would ditch the extra map to save RAM and instead stamp those room label letters onto a single map as an extra layer.

PS: After restarting FGU the large Caves map does not overload my GPU anymore when the map windows is maxed. Still looks like a bug that should not happen.

Really good points.
In my case, C/GPU ramp up even with no LOS or no map at all. Even without players connected or modules loaded.
Personally, I would accept a suboptimal LOS calculation while moving tokens around. However, as soon as tokens stop, there should be no/very little utilisation.
No refresh/recalculation needed should correspond to an Idle C/GPU

[Weissrolf]

Unity keeps drawing frames until it hits the VSync limit, there is no real "idle" time anymore like there was with Classic.

That being said, one of my players is on a seriously, seriously, very seriously under-spec PC, but he still can play once I disable LoS on complex maps (even with lots of extensions running).

So your problems seem to be Mac specific and thus need different handling. I never used FGU on Mac, despite owning a MBP (bootcamped to Windows).

[Vyder]

PC Windows 10 - Caves of Chaos-PC_highres:

Windowed mode - window resized to fill full screen - zoom to match desktop/max mode content
https://i.imgur.com/XokF2U1.png

Desktop/maximized mode - supposedly zoom to fit
https://i.imgur.com/kRej12X.png

Why do I write "supposedly"? Because not only do the two maximized modes turn mild GPU load into GPU overload, but zoom to fit/fill also only shows a small portion of the map. In windowed mode zoom to fit works properly.

https://i.imgur.com/Be1zsK9.png vs. https://i.imgur.com/e8h0jYN.png

So the map itself is not much of a problem on my system, but going desktop/max size is. Here is the load of the small SW "Battlemap01" for comparison, no difference compared to the large campaign map in windowed mode, but desktop/max is just as low as windowed when Battlemap01 is used.

https://i.imgur.com/RiGDnVj.png

I'd start from there. If needed I can test this map on a Macbook Pro 2018 for comparison.

I can only use the map in windowed mode. Hitting the arrow in the top right of the image window with the image locked crashes FGU. But if i unlock the image and hit the arrow it works but i loose the widget and most of the map is off the screen gone. when my players hit the arrow they dont crash but cant use FGU because like you said for some reason it puts a massive strain on there systems.

[Weissrolf]

I can only use the map in windowed mode. Hitting the arrow in the top right of the image window with the image locked crashes FGU.
Ah, that was the difference between my two tries. Image locked = maxed out GPU (2070 Super, even when overclocked), no lock = only 3% more GPU load compared to windowed.

[Vyder]

The only thing you can throw at FGU is a CPU with the highest possible per core performance. Multiple cores do next to nothing for you, you need high clock-rates and large caches. GPU likely doesn't matter in your situation unless maybe its VRAM is too small. But even with the most powerful desktop CPU in the world current FGU performance will be a let-down for your use-case (and partly mine).

FGU's performance just isn't good enough for having many LoS elements on a map. I blame FGU more than I would blame your hardware. You could disable LoS and do manual unmasking, but then you would forfeit one of the main reasons to switch from Classic to Unity.

I think the main problem is that with every token movement FGU calculates all LoS points on the map, regardless of the fact that the token only sees a small fraction of them (up to the next wall). Even masking other regions out does not help there. I consider this either a bug or at least bad design.

And now comes the workaround that helps us get around FGU's limitation and get on with life until the issue is maybe fixed:

https://i.imgur.com/yb8rj4T.gif

- Create a duplicate of the original LoS layer.
- Disable the original LoS layer.

- On the duplicate LoS layer delete *all* LoS areas that your party is not going to play in for the current session!

This will cause FGU to only calculate the LoS points that you left intact on the duplicate layer. It shouldn't calculate all those invisible behind walls points anyway, but it does, so we need to trick it into submission.

- Next session you delete the duplicate LoS layer and create a new duplicate of the original LoS layer. Wince and repeat.

One hint for your campaign: You use two nearly identical high-res images on top of each other, seemingly only to switch on/off the room labels. I would ditch the extra map to save RAM and instead stamp those room label letters onto a single map as an extra layer. Main problem I see is that I did not find a way to switch visibility on/off for GM only, without cycling through "Visible to all".

PS: After restarting FGU the large Caves map does not overload my GPU anymore when the map windows is maxed. Still looks like a bug that should not happen.

That is a great workaround thank you. Fingers crossed.

Edit: I turned off LoS and was able to hit the arrow with the map locked with no performance issue after re sizing the window a bit to bring the widget back. If i dont re size its like playing on dial up.

[Weissrolf]

Yes, disabling global LoS helps with that. Curiously turning off *all* layers does not.

[Vyder]

Yes, disabling global LoS helps with that. Curiously turning off *all* layers does not.

Stretch FGU half way across a second screen and after hitting the arrow when the performance is terrible slightly resize the window. Night and day.

[MrDDT]

Thanks Weissrolf for putting all that work into showing people what is the problem and how much.

[caste381]

Unity keeps drawing frames until it hits the VSync limit, there is no real "idle" time anymore like there was with Classic.

That being said, one of my players is on a seriously, seriously, very seriously under-spec PC, but he still can play once I disable LoS on complex maps (even with lots of extensions running).

So your problems seem to be Mac specific and thus need different handling. I never used FGU on Mac, despite owning a MBP (bootcamped to Windows).

Thanks.
Is this by design? Certainly having the software recalculate stuff that does not change does not make sense?
Re the Mac specific problem: I would tend to agree. However, It appears to not be dependent on the OS.
I installed Win10 over bootcamp and I get very similar results with a basic campaign with no players connected. See screenshot
44996

[LordEntrails]

Thanks.
Is this by design? Certainly having the software recalculate stuff that does not change does not make sense?
Re the Mac specific problem: I would tend to agree. However, It appears to not be dependent on the OS.
I installed Win10 over bootcamp and I get very similar results with a basic campaign with no players connected. See screenshot
44996
Yes, it's the way the Unity engine works. It is designed to draw as many frames as the computer is capable of doing. The FG Devs have done some things to prevent that, in most cases, but sometimes Unity and the computer works against them doing that. Hence why they have implemented the chat command "/vsync" so that in those cases the user can override the Unity behavior and explicitly set frame rates.

[caste381]

Yes, it's the way the Unity engine works. It is designed to draw as many frames as the computer is capable of doing. The FG Devs have done some things to prevent that, in most cases, but sometimes Unity and the computer works against them doing that. Hence why they have implemented the chat command "/vsync" so that in those cases the user can override the Unity behavior and explicitly set frame rates.

Thanks for the answer.
As mentioned earlier, the vsync option impacts performance. Isn’t there any way to keep things smooth and reduce only unnecessary frames?
Leaving spikes while dragging tokens, for instance, and apply something similar to vsync only when nothing needs to be calculated?

[LordEntrails]

Thanks for the answer.
As mentioned earlier, the vsync option impacts performance. Isn’t there any way to keep things smooth and reduce only unnecessary frames?
Leaving spikes while dragging tokens, for instance, and apply something similar to vsync only when nothing needs to be calculated?
Maybe in the future. right now I assume it is not a priority for the devs since it works for most situations and their is a work around. But, over the years I've used the program, their are always periodical efforts spent on performance.

[Weissrolf]

Theoretically FGU could lower the frame-rate by itself when nothing is moving on screen. This would work to lower GPU load at idle times. That being said, most of the time CPU processing is the bottleneck and leads to serious fps drops anyway.

[caste381]

Theoretically FGU could lower the frame-rate by itself when nothing is moving on screen. This would work to lower GPU load at idle times. That being said, most of the time CPU processing is the bottleneck and leads to serious fps drops anyway.

That’s what I have been struggling to understand. The Unity documentation seems to support the possibility of controlling frame rate:


Turn based games, such as chess. Players spend time waiting for other users to make their move or thinking about their own move. During periods of low activity, you can lower the frame rate to prevent unnecessary power usage and prolong battery life.

[LordEntrails]

As said, it's not that it can't be done. Just that it has not been done. Therefore one can draw the conclusion that it is not a development priority right now.

[Weissrolf]

It has been done with the /vsync option. FGU could use this already implemented part to lower fps when little to nothing is happening (no fx, no scrolling, no zooming, no panning).

I am in the process of testing FGU performance on my Macbook Pro 2018, on which up to now I only used Classic on. 100% GPU load at Vsync 1 or 2 with accompanying high CPU load looks worrying. My current assumption is that FGU uses GPU routines that don't play nice with Intel CPUs' internal graphics. Maybe also some conflict with shared memory and cache (between CPU and GPU).

[caste381]

It has been done with the /vsync option. FGU could use this already implemented part to lower fps when little to nothing is happening (no fx, no scrolling, no zooming, no panning).

I am in the process of testing FGU performance on my Macbook Pro 2018, on which up to now I only used Classic on. 100% GPU load at Vsync 1 or 2 with accompanying high CPU load looks worrying. My current assumption is that FGU uses GPU routines that don't play nice with Intel CPUs' internal graphics. Maybe also some conflict with shared memory and cache (between CPU and GPU).

Same behaviour on my MacBook pro 2018 and air 2020

[Vyder]

The only thing you can throw at FGU is a CPU with the highest possible per core performance. Multiple cores do next to nothing for you, you need high clock-rates and large caches. GPU likely doesn't matter in your situation unless maybe its VRAM is too small. But even with the most powerful desktop CPU in the world current FGU performance will be a let-down for your use-case (and partly mine).

FGU's performance just isn't good enough for having many LoS elements on a map. I blame FGU more than I would blame your hardware. You could disable LoS and do manual unmasking, but then you would forfeit one of the main reasons to switch from Classic to Unity.

I think the main problem is that with every token movement FGU calculates all LoS points on the map, regardless of the fact that the token only sees a small fraction of them (up to the next wall). Even masking other regions out does not help there. I consider this either a bug or at least bad design.

And now comes the workaround that helps us get around FGU's limitation and get on with life until the issue is maybe fixed:

https://i.imgur.com/yb8rj4T.gif

- Create a duplicate of the original LoS layer.
- Disable the original LoS layer.

- On the duplicate LoS layer delete *all* LoS areas that your party is not going to play in for the current session!

This will cause FGU to only calculate the LoS points that you left intact on the duplicate layer. It shouldn't calculate all those invisible behind walls points anyway, but it does, so we need to trick it into submission.

- Next session you delete the duplicate LoS layer and create a new duplicate of the original LoS layer. Wince and repeat.

One hint for your campaign: You use two nearly identical high-res images on top of each other, seemingly only to switch on/off the room labels. I would ditch the extra map to save RAM and instead stamp those room label letters onto a single map as an extra layer. Main problem I see is that I did not find a way to switch visibility on/off for GM only, without cycling through "Visible to all".

PS: After restarting FGU the large Caves map does not overload my GPU anymore when the map windows is maxed. Still looks like a bug that should not happen.

How do i copy the letter/numbers and stamp them on a new layer?

[Weissrolf]

I am in the process of testing FGU performance on my Macbook Pro 2018, on which up to now I only used Classic on. 100% GPU load at Vsync 1 or 2 with accompanying high CPU load looks worrying.
After more testing I can rule out that the 100% GPU load is just a side-effect of aggressive down-clocking on the Macbook's part. As the MBP fans kick in very late the CPU (=GPU) hits 100°C.

https://i.imgur.com/ThCnRAr.png

What I noticed when I did a GPU load test using the "Caves of Chaos" map with disabled LoS: Around zoom-to-fit size GPU load is highest. The more you either zoom out or in the more GPU load drops down to a difference of over 30%, first hardly, then slightly and then quite abruptly with every step. Once zoomed in far enough GPU load stays lower, even when the image is panned around.

This happens on both the Intel CPU based GPU on the bootcamped MBP (Windows) and on my desktop 2070 Super. The difference being that my 2070S goes from 9% to 6%, while the MBP goes from burning hell overload 100% down to less than 70%.

I also tried replacing the Intel GPU driver with the non hardware accelerated Microsoft VGA driver. Obviously no more measurable GPU load then, but increased CPU load in return.

Curiously the GPU memory usage on the bootcamped MBP increases from 300 to 1500 mb once the campaign and map are loaded, but only to around 1000 mb on the desktop 2070S.

PS: I made FGU crash when I tried to switch the locked map from windowed to desktop/max. An extra FGU window popped up at some point, maybe the Unity crash handler doing stuff?

[Weissrolf]

How do i copy the letter/numbers and stamp them on a new layer?
There are letter tokens coming with FGU. You can stamp them in as tiles.

[Vyder]

There are letter tokens coming with FGU. You can stamp them in as tiles.

Thanks for all your help.

[dimonic]

I have been running FGC for a while (Ultimate user) without problems under Linux. i7-4600 with 12 GB ram, SSD. I run games for 4-6 players, Osric and 5E, using Discord for voice. no other extensions. I had the opportunity to try out FGU (Unity) for 3 months because of GaryCon, so I copied my data folder and tried that. I was very impressed by the Linux install btw. I also ran two sessions simultaneously to test the LOS and light sources in the beta and the test went very well.

Then I tried it for my AD&D game last night (2E, Player's Handbook and Osric loaded). FGU took about 3 times longer than FGC to start up. It pegged my CPUs close to 100% utilisation and stayed there. Discord became unusable (set to for audio only). I tried google meet which was pretty much the same. I heard everything garbled if at all. My players heard 10s delayed echos of everyone. I shut down everything except FGU and Discord to no avail.

I switch back to FGC and everything went back to normal. Everyone could hear me on google meet. I could hear everyone. So - glad the trial didn't cost me anything.

[damned]

I would try on your computer - and on players computers that might be on the lower side - type into chat:

/vsync 0
/vsync 2
/vsync 4

try each one and see if any of them improve your experience.

[tahl_liadon]

.
so i took some time to scan this thread from the beginning. some points i gathered:

lots of testing from mac users
fgu is still an issue while running on mac (slow, resource-draining, etc)
at least one bandage fix (vsync?) but seems like it went away with last major update
still no fix for issue

is this a correct read and summary, or did i miss seeing a solution somewhere?

if there isn't an official solution, what is the expectation for continuing development and fixes for mac,
or is dev efforts currently only being focused on fgu running on native pc?
.


...FGU took about 3 times longer than FGC to start up.
It pegged my CPUs close to 100% utilisation and stayed there. Discord became unusable (set to for audio only).
I tried google meet which was pretty much the same. I heard everything garbled if at all.
My players heard 10s delayed echos of everyone. I shut down everything except FGU and Discord to no avail...
.
dovetailing to the discord issue:

mbp 2019, 16", 2.6hz i7, 16gb ram, amd radeon pro 5300m 4gb + intel uhd 630 1536mb
catalina (10.15.7), parallels, fgu (pc)
fgu on virtual pc environment
discord native on mac
the image shows what happened after about 3 hours in using fgu as a player
after which fgu was nearly unresponsive and discord issue didn't go away after restarted both
ultimately rebooted system to get back to normal


https://www.fantasygrounds.com/forums/attachment.php?attachmentid=45314

[charmov]

I basically had to upgrade after FGU fried my 2011 MBA. Now using refurb m1 Mac Mini and it's easy better. It will use lots of cpu to start, +100% but then after /vsync 4 goes down to about 15% to 30% depending what's going on.

I had to upgrade anyway except i wasn't able to back up my campaigns before i got the dreaded 3 beeps meaning logic board was toast. Still hope for target mode or removing it's ssd.

For those with older systems back up your ****!

[LordEntrails]

.
so i took some time to scan this thread from the beginning. some points i gathered:

lots of testing from mac users
fgu is still an issue while running on mac (slow, resource-draining, etc)
at least one bandage fix (vsync?) but seems like it went away with last major update
still no fix for issue

is this a correct read and summary, or did i miss seeing a solution somewhere?

On some Macs its an issue. Not all.
vsync is still available, it has not gone away.
Performance issues are not a single "fix". They usually involve many incremental fixes.

As often requested by the devs, the best way to help them is to include both player and gm logs via "Compile Logs" shortly after an event has happened. Including if you can details of what was happening, what steps caused the issue to occur, and system information.

[tahl_liadon]

.
thx, @lordentrails.

[Linkicecold3000]

I experience this same issue with my Razer Blade 15 RZ09-02705E76-MSU1 Laptop running Windows 10. I have tried forcing FGU onto both my integrated GPU and the beefy one, but in both cases it runs my machine so hard you'd think i'd been playing Doom Eternal at full settings and the cooling can barely keep up. I'm talking 90-100% GPU usage at length when it's literally the only thing running.

[LordEntrails]

I experience this same issue with my Razer Blade 15 RZ09-02705E76-MSU1 Laptop running Windows 10. I have tried forcing FGU onto both my integrated GPU and the beefy one, but in both cases it runs my machine so hard you'd think i'd been playing Doom Eternal at full settings and the cooling can barely keep up. I'm talking 90-100% GPU usage at length when it's literally the only thing running.
Have you tried any of the solutions discussed in this thread? I know it's long, but there are usually solutions.

In short, some graphic drivers override FGU's behavior and try to drive the Unity engine as hard as it can. Hence utilizing the entire GPU. Inside FGU you can try the chat command "/vsync 0" or a number 0-4. You can also check your driver settings to fix application performance. Not allowing it to override, or forcing it to 60 fps, or other performance settings.

[damned]

welcome Linkicecold3000

use vsync. for some (unknown to me) reason your (and some others) computer is refreshing the screen as fast as the gfx card can handle.
that is causing the load and heat issues.
use vsync switch to have some input in the refresh rate and it will most likely help.

try in order

/vsync 0
/vsync 2
/vsync 4

[Moon Wizard]

Also, make sure that your graphics driver is respecting the application's graphics settings. I know that NVidia/Radeon offer options in their control panels to override application settings.

Regards,
JPG

[dimonic]

Have you tried any of the solutions discussed in this thread? I know it's long, but there are usually solutions.

In short, some graphic drivers override FGU's behavior and try to drive the Unity engine as hard as it can. Hence utilizing the entire GPU. Inside FGU you can try the chat command "/vsync 0" or a number 0-4. You can also check your driver settings to fix application performance. Not allowing it to override, or forcing it to 60 fps, or other performance settings.
Thanks, that made a HUGE difference on my system. Would it be too much to ask that the system default to a reasonable (say 20/s) frame rate? I am not going to get killed because some twitchy player on aderal shoots me before I finish redrawing after all. This is a turn based game.

[Neovirtus]

Thanks, that made a HUGE difference on my system. Would it be too much to ask that the system default to a reasonable (say 20/s) frame rate? I am not going to get killed because some twitchy player on aderal shoots me before I finish redrawing after all. This is a turn based game.

I believe that FGU is set to default to 60 fps, but some rare driver settings/bugs occasionally cause the system to override that. So if I'm remembering correctly, what you're asking for is already implemented, you just happened to fall into the unfortunate group of people for whom the defaults were overridden for one reason or another.

[dimonic]

You could be right - and I hold that even 60 fps is unnecessary for a system like fantasy grounds. Also - a question - does the client frame rate have any impact on server performance?

[lostsanityreturned]

You could be right - and I hold that even 60 fps is unnecessary for a system like fantasy grounds. Also - a question - does the client frame rate have any impact on server performance?

Yuck.

Don't set the bar that low, having a choppy stuttery experience is not acceptable. 30fps is an awful goal to have for software with any moving elements

[damned]

I think lower frame rates affect the dice rolling appearance.
I think they tested setting a default of 30fps and it was negatively received.

[Weissrolf]

Lower frame-rates also introduce visual lag with every click and change you do and makes things like moving windows look more erratic.

Personally I used 30 fps (or 20) for games like Civilization and Total War while playing on laptops in order to keep them cool/quiet. This can even work with games like WoW. But on a desktop PC with strong hardware I prefer higher frame-rates for smoother experience and less lag.

[dimonic]

On the subject of frame rates: [https://www.cnet.com/news/smooth-movies-are-high-frame-rate-films-a-good-idea]. We have enjoyed 24 frames per second as an industry standard for decades. I suspect the computer industry has sold you on high resolution and high frame rates mostly to sell new hardware.

[Weissrolf]

Movies use deliberate blur to make 24 fps work. And there is a big difference between just watching a movie (one-way) and interacting with a user-interface (two-way).

[LordEntrails]

Regardless of my personal preferences/thoughts, the larger gaming community expects 60fps. So it's probably best that FGU targets that frame rate for default. Fortunately, we have /vsync and driver settings for those who want/need more or less.

[lostsanityreturned]

On the subject of frame rates: [https://www.cnet.com/news/smooth-movies-are-high-frame-rate-films-a-good-idea]. We have enjoyed 24 frames per second as an industry standard for decades. I suspect the computer industry has sold you on high resolution and high frame rates mostly to sell new hardware.

As someone who worked in an optical laboratory for 4 years of my youth (Essilor), please don't make statements like this without doing more research first. Human vision (and our brains processing of this information) is far more complex than people believe.

Our brain will notice a lower framerate of something we control directly more than we will notice something we have little to no impact on (such as a recording).

Higher framerates aren't snake oil, an application we directly interface with is not a film.

[dimonic]

Wow - it's like I stepped on someone's toes and poked them in the eye.

All that happened was I installed the new version on some half-decent hardware, and it worked like crap and killed my game until I went back to classic. I posted about that here and was told about the vsync setting. I tried it, and it worked. Great. How dare I ask why this shouldn't be the default FOR A TURN BASED TTRPG. Silly me - I must be too old to play with the cool kids.

[dimonic]

As someone who worked in an optical laboratory for 4 years of my youth (Essilor), please don't make statements like this without doing more research first.

Don't be daft. Of course I am not going to do a load of research before airing my opinion on computer graphics. This isn't court, or a debating society, or even a design committee. It's just some people trying to troubleshoot program bugs on the internet. Sigh. Now you have gone and left a bad taste in my mouth about Fantasy Grounds - and you probably don't even work there.

[damned]

lets stay civil people.
text responses can often appear very black and white and often come across more strongly than they were intended

[LordEntrails]

... and you probably don't even work there.
SmiteWorks employees have the SmiteWorks tag under their name. I don't believe any of them have responded to your issues in this thread.

[lostsanityreturned]

Don't be daft. Of course I am not going to do a load of research before airing my opinion on computer graphics. This isn't court, or a debating society, or even a design committee. It's just some people trying to troubleshoot program bugs on the internet. Sigh. Now you have gone and left a bad taste in my mouth about Fantasy Grounds - and you probably don't even work there.

" I suspect the computer industry has sold you on high resolution and high frame rates mostly to sell new hardware. "

This above statement suggested that you believe I and others are foolish and have simply been hoodwinked by the industry to sell new hardware, if you wish to voice such an assertion/supposition I do expect a base level of knowledge regarding the topic.
I feel it is important to highlight this given the extremity of your last two statements and suggestion that you feel victimised as that wasn't my intent.

[dimonic]

Regarding level of knowledge - I believe the link I posted was "a degree of research". I did in fact read that for "reality" based video, the need for high frame rate exists, and for "fiction", a slower frame rate has become accepted and preferred by most. My statement was too general, when I should really have been focused on this specific game.

For people who are playing fast action, 1st person shooters, flight simulators and driving simulators, frame rates of 60+ are good, and better is (perhaps) better, and high definition is good, and very high definition is (perhaps) better, I do believe there are diminishing returns, and that it is not in the interest of the hardware industry to inform or educate you on that fact.

For this particular game, I still find it hard to see how one can justify the default setting breaking the game for a (perhaps small) but significant percentage of real world users of the program, in order to give the presumed majority of users the benefit of their very powerful graphics systems in such a way that does not improve actual gameplay whatsoever. I may not have a great deal of experience in optical perceptions and computer graphics, but I do make a living developing working software for technical and scientific users, and our number one job is to not piss off the users. If it worked yesterday, it has to work today and for all the people it worked for yesterday. New features be damned (if they are at the cost of the existing users).

[LordEntrails]

Good observations, and discussion.

As I implied, I too don't have a personal need for 60 fps. But I also understand that VTTs don't have the same user base or user expectations of technical and scientific software. There is a large spectrum of expectations from VTT users. Some want nothing more than the ability to share a map/image and maybe a pointer to go with it. Others want more. Perhaps maps with tokens and combat automation. Some want video images, moving maps. Others want 3D avatars, and even 3D dungeons that might even be viewable in first person perspective unique to every player.

FG has positioned itself over the years as a premium VTT. Regardless of the details of such a classification, a huge segment of the VTT market thinks premium VTTs should have 60+ fps. Right or wrong, realistic or even impactful for game play, those are the expectations from a large segment of the market. And though I don't know numbers to support, I suspect there is a lot larger segment of the premium VTT market who wants 60+fps than would be alienated by performance on low end hardware that something like vsync won't resolve.

In the end, I hope everyone makes their opinion known and then I trust SmiteWorks to make the decisions to support the best for the overall community (and not overly weighed by any vocal minority).

[damned]

I may not have a great deal of experience in optical perceptions and computer graphics, but I do make a living developing working software for technical and scientific users, and our number one job is to not piss off the users. If it worked yesterday, it has to work today and for all the people it worked for yesterday. New features be damned (if they are at the cost of the existing users).

This argument has been made/had both ways many times over the last 6 years. FGU has been designed to be as backward compatible - with FG products/code and at the same time has dropped support for many users/platforms in that there is no longer a 32bit version and Win 7/8 official support has been dropped. The whole industry makes decisions that force upgrades all the time. At the same time FGC had been dropped by Apple because it was 32bit only. Times change things move on.


New features be damned

Im not a new feature. Im a gnarly old one!

[Weissrolf]

I think the argument goes the wrong way around. FGU should not (ab)use so much processing power for what it does, aka 60 fps should not be "game breaking" to begin with.

[damned]

I think the argument goes the wrong way around. FGU should not (ab)use so much processing power for what it does, aka 60 fps should not be "game breaking" to begin with.

I don't know the inner workings or what's happening under the hood. 60fps is needed for the dice animations to look smooth. I don't know if unity always redraws the entire screen every time it if it can just redraw the changed bits. It appears it is doing the whole screen. If it's a unity game engine feature then it is what it is. If it's the way FGU is programmed hopefully it will be improved upon.

[dimonic]

FG has positioned itself over the years as a premium VTT. Regardless of the details of such a classification, a huge segment of the VTT market thinks premium VTTs should have 60+ fps. Right or wrong, realistic or even impactful for game play, those are the expectations from a large segment of the market. And though I don't know numbers to support, I suspect there is a lot larger segment of the premium VTT market who wants 60+fps than would be alienated by performance on low end hardware that something like vsync won't resolve.


I don't think we are talking about low end hardware here, unless an i7 4600 with 12 GB ram is considered low end nowadays. /vsync 2-4 does appear to resolve the issue for me, and also makes very little difference to the visuals with the exception of the dice roller which appears more "suspenseful" at lower frame rates. Also (as these fora attest) there are many people with higher-end hardware, and powerful graphics cards that are having issues. I agree, and do not recommend the developers take the same approach that scientific software developers take. 64 bit machines only is fine. Requiring a certain CPU level and amount of Ram is fine. I honestly would draw the line at requiring a dedicated GPU. There are some TTRPG gamers who do not actually play video games - and many more who wish to play their RPG using a laptop (and not the honking desktop in the basement or bedroom), for many good reasons. I was considering a dedicated laptop for my gaming table.

I have a big machine with a GPU in the basement. I work on it all day. Then I play RPGs in the evenings with my friends, in the living room. I have choices. I can always use roll20 instead. I can continue using FG Classic. If it turns out that Smiteworks want to abandon laptop hardware in favour of GPUs I think they are bucking the trend which is heading away from large dedicated gaming hardware, and are actually following a shrinking (but vocal) audience into a narrowing niche as mainstream machines and gaming as a whole are going portable in droves. Perhaps this niche will be fine for Smiteworks - only the future can tell. It does seem that I will have to wait and see if I should spend the money to upgrade to Unity (which I once spent gladly on Classic).

[Moon Wizard]

Please remember that the FG client is always evolving.

Currently, we are aware of certain scenarios that cause performance issues; but those are also features that are not in FG Classic and may or may not be in competitive products. If you are monitoring the Laboratory thread where we are discussing the beta version, you will see that these issues are front and center, and we are spending a lot of time reviewing and fixing internally. (as well as working to fine tune use cases, since many of these features are "subjective" as to what users want.) Also, every time we add an enhancement to the existing feature set, the combination of features usually incurs even heavier performance, so we are constantly rebuilding and fine tuning as we go.

To the specific point of frame rates, we have tried lower default frame rates (and have an option /vsync for you to experiment with); but they make the FX/dice look choppy. So, it's still a manual/hidden option. We believe that we can eventually fine-tune the engine to improve performance in most real-world scenarios, so that this is a moot point.

On a related note, we believe that the hardware utilization on non-Windows machines is different than Windows machines; but we believe this is a Unity game engine consideration (since we do the same things on both platforms). We're hoping that moving to the Unity game engine 2020 LTS version (just released last month) will help smooth out those differences; but we have to wait until we get the lighting release (v4.1) out before we introduce that large of a change.

Regards,
JPG

[EllivasKram]

I know you will crack this and you will be working until you do.

But I’m very tempted to say ‘nvidia GEForce streaming’ or similar could be an Avenue to explore.

Implemented right we could all have always on servers for our player base for a monthly fee and horse power to run full features at full frame rates. We can’t run FGU without a decent Internet connection so the FGU user base shouldn’t be balked by the streaming requirement of at least 15-20mbps.

[LordEntrails]

I have a big machine with a GPU in the basement. I work on it all day. Then I play RPGs in the evenings with my friends, in the living room. I have choices. I can always use roll20 instead. I can continue using FG Classic. If it turns out that Smiteworks want to abandon laptop hardware in favour of GPUs I think they are bucking the trend which is heading away from large dedicated gaming hardware, and are actually following a shrinking (but vocal) audience into a narrowing niche as mainstream machines and gaming as a whole are going portable in droves. Perhaps this niche will be fine for Smiteworks - only the future can tell. It does seem that I will have to wait and see if I should spend the money to upgrade to Unity (which I once spent gladly on Classic).
I ran FGC and run FGU on 10 year old laptop with minimal problems. That helps to indicate that the performance issues with FGU are not easy/simple to solve since it appears that often newer more capable hardware actually runs poorer than older less capable hardware. And I don't use vsync either.

[EllivasKram]

What campaign you running as some are more problematic than others.

[Sterno]

I ran FGC and run FGU on 10 year old laptop with minimal problems. That helps to indicate that the performance issues with FGU are not easy/simple to solve since it appears that often newer more capable hardware actually runs poorer than older less capable hardware. And I don't use vsync either.

Agreed that it's not simple/easy to solve, but your anecdotal evidence is hardly enough to suggest that newer hardware runs poorer than older hardware. You need a lot more fixed variables (same campaign, same map, same window size/resolution, refresh rate, etc) in the comparison before you can even start to say newer hardware is less performant.

[Jiminimonka]

Agreed that it's not simple/easy to solve, but your anecdotal evidence is hardly enough to suggest that newer hardware runs poorer than older hardware. You need a lot more fixed variables (same campaign, same map, same window size/resolution, refresh rate, etc) in the comparison before you can even start to say newer hardware is less performant.

LE was not saying that.

[WasGreg]

Where can I find how to manually adjust this frame rate? Choppy dice means very little to me, but a 90+% GPU load and heating of graphics card is annoying to no end. It had always been strangely high, but after my last update Friday 4/23/2021, it is in the high 90's for load.

[Zarestia]

Where can I find how to manually adjust this frame rate? Choppy dice means very little to me, but a 90+% GPU load and heating of graphics card is annoying to no end. It had always been strangely high, but after my last update Friday 4/23/2021, it is in the high 90's for load.

There have been only ruleset updates in the last weeks/months which shouldn't impact performance afaik. You're on LIVE and not TEST, right?

Chat commands:

As long as you don't override the values with your graphic drivers it should be like this (vsync 0 and vsync 1 might be swapped, not too sure):

/vsync = shows configuration
/vsync 0 = 60 fps
/vsync 1 = OS defined frame rate for monitor (default)
/vsync 2 = 1/2 OS frame rate
/vsync 3 = 1/3 OS frame rate
/vsync 4 = 1/4 OS frame rate

MODERATOR: Updated /vsync details.

[Egheal]

Just to let you know about the /vsync command on my rig.
GPU : Nvidia RTX 2070 Super, GPU : Ryzen 9 3900X, Ram 32Go@3200MHz. Windows 10. Using Fraps for reading FPS.
/vsync 0 = 60fps with or without image, lights, LOS.
/vsync 1 = 383fps with image, lights, LOS. = 865fps without image.
/vsync 2 = 365fps with image, lights, LOS. = 838fps without image.
/vsync 3 = 387fps with image, lights, LOS. = 845fps without image.
/vsync 4 = 366fps with image, lights, LOS. = 854fps without image.
Note 1 : these values are rough averages, the fps score is always fluctuating around them.
Note 2 : moving a token with light around the map is going to change these values a lot, from 365 to 85 for a fraction of second then to 245, up to 370...
moving the same token on vsync 0 : i get a stable 59-60fps, and if i go crazy with it (i.e. very rapid movements) there is some drops to 34fps.
Note 3 : with vsync 1, 2, 3, 4 my GPU usage is at 100%. With vsync 0 i am around 30-35% with spikes at 55 moving tokens crazy style.
Hope that could help.

[Moon Wizard]

When using /vsync, please note that your graphics driver control panel options can override the OS default settings to try and run at "max" frame rate all the time. In general, you should make sure that your graphics driver is respecting the "application-specific" frame rate settings.

Regards,
JPG

[Egheal]

When using /vsync, please note that your graphics driver control panel options can override the OS default settings to try and run at "max" frame rate all the time. In general, you should make sure that your graphics driver is respecting the "application-specific" frame rate settings.

Regards,
JPG

Thanks a lot for this precision. I thought that my Nvidia panel was on "let the 3D application decide" but it wasn't!
Using this setting i am back to normal behaviors:
/vsync 0 = 60fps
/vsync 1 = 60fps
/vsync 2 = 30fps
/vsync 3 = 20fps
/vsync 4 = 15fps
i use two 2560X1440 60Hz monitors.
I wonder if, in some (a lot of?) cases, the problems of lag and performance issues with the FGU test version are perhaps related to this specific point.

[Moon Wizard]

It more likely has to do with machines running "hot" or "high fans" than it does performance issues. The performance issues usually indicate that something is taking too long to compute each frame, which actually lowers frame rate and GPU usage.

Regards,
JPG

[WasGreg]

Sorry for my rude post earlier. Was tired and upset with other issues when I started to research this one. I have had my nappytime and properly compartmentalized :)

My GPU load is running in the 90+%. Consequently, my graphics card is heating up to what I believe to be dangerous levels for continued PC health. What can I do to help resolve this issue?

This issue seems to have come to a head with the last update I installed 4/23/2021. My load was always in the 50-60 range with spikes before. I run a temp gauge in the background b/c I had issues with a previous comp a few years back, and have become paranoid about losing another.

Will check my driver settings with respect to "let the 3d application decided" It was exactly this. I wonder if NVIDIA had an update that changed this. I have no memory of ever going to this setting since getting this computer.

My equipment:
desktop/tower
processor Intel (R) Core i5-7400 cpu @3.00GHz
RAM 8 GB
Display NVIDIA GeForce GTx 1050 Ti (primary) motherboard Intel(R) HD graphics 630
one monitor

Campaign:
Castles & Crusades
A0 module with LOS running on the two dungeon maps. walls, doors, and secret doors. No environmental, delete NPC tokens after encounters.
I use the server cloud.

[Zarestia]

Thanks to Moon Wizard for correcting my faulty memory :)

First things first: A full-fledged 3D Game using 99-100% of your GPU normally isn't a problem, unless you got some faulty cooling, fans or somehting. Nearly every half-modern graphically heavy game causes that much GPU load. FGU is created with a game engine but isn't really comparable to a 3D game (too technical, offtopic).

Your specs seem totally fine and shouldn't cause a load of 90%.

A few questions:
- Can you take a screenshot of the upper right-hand corner of the FGU launcher (so we can see what version and what channel you use)?
- Is this happening only when having a map open?
- Is the map put in the background?
- Is it only one map or every map?
- Is it happening in a fresh campaign without extension?


Is your NVIDIA card the primary/active GPU? There have been some cases where the onboard GPU is the primary/active one. I think NVIDIA has a control panel in the tray where you can see what application goes through your GPU (AMD user here).

[WasGreg]

Thanks to Moon Wizard for correcting my faulty memory :)

First things first: A full-fledged 3D Game using 99-100% of your GPU normally isn't a problem, unless you got some faulty cooling, fans or somehting. Nearly every half-modern graphically heavy game causes that much GPU load. FGU is created with a game engine but isn't really comparable to a 3D game (too technical, offtopic).

Your specs seem totally fine and shouldn't cause a load of 90%.

A few questions:
- Can you take a screenshot of the upper right-hand corner of the FGU launcher (so we can see what version and what channel you use)?
- Is this happening only when having a map open?
- Is the map put in the background?
- Is it only one map or every map?
- Is it happening in a fresh campaign without extension?


Is your NVIDIA card the primary/active GPU? There have been some cases where the onboard GPU is the primary/active one. I think NVIDIA has a control panel in the tray where you can see what application goes through your GPU (AMD user here).

Though I feel the issue has been resolved( my load is currently about 17-20% and my temps run about 32-40 degrees now from 88+ degrees and about 97%), I would be glad to answer the above requests.
46126
The situation was happening as soon as I started loading FGU.
With or without maps in background I would have the issue.
With all maps or without any maps I would have the issue.
I never started another fresh campaign since the issue started, but I did load a test 5e campaign, and the issue existed there as well.
According to the dxdiag my NVIDIA card is showing as the graphics card in use.

Not very comp savvy, I am sorry to say. But I must say, that by simply changing the settings suggested by Moon Wizard had dropped my GPU heat by almost 50 degrees and my GPU load by about 60+%. It definitely seemed to solve my issues.

EDIT I have cats, and perhaps I need to do another blow out of my fans if a 90+% load shouldn't cause excessive heat. I do this every other month, but mayhap with the rise of heat they are shedding more. :) So, perhaps I had two issues. Thanks again for input.

[Weissrolf]

I think the main problem is that with every token movement FGU calculates all LoS points on the map, regardless of the fact that the token only sees a small fraction of them (up to the next wall). Even masking other regions out does not help there. I consider this either a bug or at least bad design.

And now comes the workaround that helps us get around FGU's limitation and get on with life until the issue is maybe fixed:

https://i.imgur.com/yb8rj4T.gif

- Create a duplicate of the original LoS layer.
- Disable the original LoS layer.

- On the duplicate LoS layer delete *all* LoS areas that your party is not going to play in for the current session!

This will cause FGU to only calculate the LoS points that you left intact on the duplicate layer. It shouldn't calculate all those invisible behind walls points anyway, but it does, so we need to trick it into submission.

- Next session you delete the duplicate LoS layer and create a new duplicate of the original LoS layer. Wince and repeat.
I just tested this again and the workaround still seems valid.

[caste381]

I just tested this again and the workaround still seems valid.

Brilliant. However, high utilization is a problem even without any maps open.
It looks like an issue with unity itself, or the way it is used

[Weissrolf]

FGU doesn't play well with (CPU internal) Intel graphics at all. It's been a while since I last checked that, though, so maybe things have improved since then. On my RTX 2070 Super FGU is almost exclusively CPU bottlenecked and often can drag down FPS to a halt (while the GPU is mostly idle).

[bmos]

FGU doesn't play well with (CPU internal) Intel graphics at all. It's been a while since I last checked that, though, so maybe things have improved since then. On my RTX 2070 Super FGU is almost exclusively CPU bottlenecked and often can drag down FPS to a halt (while the GPU is mostly idle).Back in Feb 2021 I ran some games off of an Intel 8th i3 gen laptop with /vsync 4 and, while it was certainly slow, I didn't find it unstable.

[MrDDT]

My FGU runs at like 5% CPU. I do think FGU needs to have some optimizations but I'm not sure what is causing the slow down for people sometimes. I know LOS/MapSize/TokenAmount has a major issue for a lot of stuff.

[Weissrolf]

It's 5% CPU because it is a single core out of your multi-core CPU. I suspect that you use an 8-core CPU? Then 1 logical core out of 16 would max out at 6.25%, which often is rounded down for display.

[Weissrolf]

Back in Feb 2021 I ran some games off of an Intel 8th i3 gen laptop with /vsync 4 and, while it was certainly slow, I didn't find it unstable.
I sometimes use FGU on a Macbook (usually Windows, but gave OS X a few tries). It's certainly slow there, but indeed not unstable. Originally I bought FG to use as GM at the table, just for handling bought adventure paths with encounters being ready-made for the combat tracker and all description and rules in one package. But the pandemic pushed us to VTT use where I usually run FGU on desktop PCs and only use the laptop during vacations.