Poor Performance After Yesterday's Update

[allpraisethedm]

I updated Fantasy Grounds last night to check to make sure everything was working fine for our game that we had scheduled today, as I'm excited and happy with what I've seen so far with Lighting, and also saw some improvements with brightness as it was sometimes hard for just even me to see the map when I was drawing lines on certain maps. From what I could tell, everything was loading well enough last night.

We started a game today at 8pm and everyone was having issues interacting with the map, which is large, as it's a custom map for Dungeon of the Mad Mage 6th level. Initially, no one could move their tokens, moving their view on the map was extremely delayed, targeting was either delayed or they just couldn't see it, but I could as a DM, double but if I moved something or targeting something on the map, only I saw that, all my players were still looking at the same positions. They also couldn't see any changes in the Combat Tracker. I posted in the Discord with a bit of my frustration and was asked to post here to help investigate.

It was odd, as a DM everything seemed to be working OK other than some noticeable but manageable lag. I didn't notice it using any of the resources heavily (3.8GB of 32GB RAM, 3090 at 40% GPU usage, i7 10700K at about 6% CPU usage). I'm also on Ethernet with gigabit Comcast internet if that impacts at all.


When did performance go down? -- After the update the released last night my performance went down, I asked my players to update at the beginning of the morning today long before tonight.

I will also say that we tried the next update to see if that helped at all and it had little to no effect. What did work a little bit, I found, was after resetting everyone's FoW. Then they were having a bit of a better time, but performance was still a bit laggy and I had to roll for them a few times.


Ruleset used? -- 5e


Modules/Extensions loaded? -- I believe all of my players likely have all of the Players Guides that are available loaded for them. Extensions are just:

Official Fonts
Theogeek's Improved Critical
Theme: Wood
Decal Xanathar's Guide

Modules for me I have (which I concede I can probably unload some):

Candlekeep Mysteries
Dungeon of the Mad Mage
D&D LA Forge of the Dawn
D&D Lost Mine of Phandelver
Crypt of the Sun Lord
DM's Guide
Elemental Evil Companion
Monster Manuel
PHB
Sword Coast Adventurer's Guide (Player's)
Ebberon Rising from the Last War (Player's)
Unearthed Arcana (Player's)
Curse of Strahd (Player's)
DM's Guide (Player's)
Explorer's Guide to Wildemount (Player's)
Mordenkainen's Tome of Foes
Tasha's Couldron of Everything
Xanather's Guide to Everything (Player's)


Which maps (module, custom, etc.)?

Custom Map, got it from reddit: https://www.reddit.com/r/DungeonoftheMadMage/comments/azfw4f/maps_of_the_mad_mage_the_lost_levellvl_6/?ref=share&ref_source=link

Created LoS awhile ago, not too long after Unity was available from the Kickstarter, and then added lighting for all of the stone pillars and the character tokens. Attaching that export to this post.

Maybe it's because I have it all as one layer? I have no doubts that I'm doing something weird/unexpected. Or maybe it's just because it's a big 'ole map, resolution of 6500x8375.

--

What I'll probably try next is just creating a new campaign and starting fresh with some of the exports of the old one, as it has a several maps of that same size now. For the current map I'll make Lighting it's own separate layer as I see that's how it's being done the videos featuring it.

[Moon Wizard]

The map I downloaded from that link is 7800x10050, and 12.2 MB. That's a pretty hefty image; so I guess I'm surprised you didn't see any issues previously. But, I can also see that the FoW would build up a lot in a map that large and detailed.

I'll send on to our image developer (who is currently out for a few days).

Regards,
JPG

[Moon Wizard]

If you can still reproduce the performance slowdown with the current campaign, we usually like to get a zipped up copy of the campaign folder in order to be able to make sure we can recreate as closely as possible.

Thanks,
JPG

[kevininrussia]

I did a test 4E game with 5 players logged in this evening. Map is 5500x6300. About 20 lights defined on the map. 6 enemy tokens on map.
Had all the same issues as OP. Started with lag then after about 15 minutes nobody could move their tokens. Had everybody exit and restarted FGU. Logged back in and same issues. Switched back to the Live server and everything ran relatively smooth.

[SilentRuin]

I had the same problem in the thread I just posted - never saw this one or I'd have added it in here.

[Weissrolf]

3090 at 40% GPU usage
The driver likely clocked down the card, so percentage is relative. Was this using the map image in a windows or did you maximize/fullscreen it?

[Efreet]

We had the same problem last night. We thought it was a connection problem, but no. We tested by direct connection and by the cloud. It was fixed when I turned off the ambient light option. But with the light it was impossible to play. We were playing level 3 of the mad mad dungeon with the map that came by default (basic map).

[Jaegar]

I was having similar issues with regular FGU, without lighting.

[allpraisethedm]

If you can still reproduce the performance slowdown with the current campaign, we usually like to get a zipped up copy of the campaign folder in order to be able to make sure we can recreate as closely as possible.

Thanks,
JPG
Yeah I'll see if it happens again pre-session on Wednesday with my SO after trying a few different things. Since the campaign folder compressed is ~70mb, just upload it to Google Drive and link it here?


The driver likely clocked down the card, so percentage is relative. Was this using the map image in a windows or did you maximize/fullscreen it?
Maximized.

[Weissrolf]

For clarification: I did not mean maximized FGU window, but just the map window. Did you use the arrow button in the upper right window corner to maximize the map window between (left) chat and (right) side-bar? Or did you use the button twice to make the map go full-screen and cover even chat and side-bar (keep forgetting the FGU internal names for these two different modes)?

Try running the map in windowed mode instead. You can still drag it to the large size, just don't use the upper right arrow button.

[Sterno]

With FOW causing performance problems in larger maps, is there any way we could get an option to simply disable it so that players only see what they can actually see, but don't retain the "memory" of what they explored? It'd be a preferred style for me anyway even if it didn't apparently have better performance too.

[kevininrussia]

With FOW causing performance problems in larger maps, is there any way we could get an option to simply disable it so that players only see what they can actually see, but don't retain the "memory" of what they explored? It'd be a preferred style for me anyway even if it didn't apparently have better performance too.

I'm hoping they add an option to turn off LOS history. The devs can adjust the LOS history brightness so it should be possible to turn it to black (off).

[Weissrolf]

I'm hoping they can fix the performance issues so that using LoS history is not a problem. We pay for pretty maps and screen estate, so having most of the screen turn black all the time would be a waste.

[kevininrussia]

I'm hoping they can fix the performance issues so that using LoS history is not a problem. We pay for pretty maps and screen estate, so having most of the screen turn black all the time would be a waste.

Its not a performance issue. Just don't want map history.

[Weissrolf]

But you posted that in a "performance" related thread as a reply to a performance related post, so I naturally assumed that your wish was performance based. :P

[Laerun]

I updated Fantasy Grounds last night to check to make sure everything was working fine for our game that we had scheduled today, as I'm excited and happy with what I've seen so far with Lighting, and also saw some improvements with brightness as it was sometimes hard for just even me to see the map when I was drawing lines on certain maps. From what I could tell, everything was loading well enough last night.

We started a game today at 8pm and everyone was having issues interacting with the map, which is large, as it's a custom map for Dungeon of the Mad Mage 6th level. Initially, no one could move their tokens, moving their view on the map was extremely delayed, targeting was either delayed or they just couldn't see it, but I could as a DM, double but if I moved something or targeting something on the map, only I saw that, all my players were still looking at the same positions. They also couldn't see any changes in the Combat Tracker. I posted in the Discord with a bit of my frustration and was asked to post here to help investigate.

It was odd, as a DM everything seemed to be working OK other than some noticeable but manageable lag. I didn't notice it using any of the resources heavily (3.8GB of 32GB RAM, 3090 at 40% GPU usage, i7 10700K at about 6% CPU usage). I'm also on Ethernet with gigabit Comcast internet if that impacts at all.


When did performance go down? -- After the update the released last night my performance went down, I asked my players to update at the beginning of the morning today long before tonight.

I will also say that we tried the next update to see if that helped at all and it had little to no effect. What did work a little bit, I found, was after resetting everyone's FoW. Then they were having a bit of a better time, but performance was still a bit laggy and I had to roll for them a few times.


Ruleset used? -- 5e


Modules/Extensions loaded? -- I believe all of my players likely have all of the Players Guides that are available loaded for them. Extensions are just:

Official Fonts
Theogeek's Improved Critical
Theme: Wood
Decal Xanathar's Guide

Modules for me I have (which I concede I can probably unload some):

Candlekeep Mysteries
Dungeon of the Mad Mage
D&D LA Forge of the Dawn
D&D Lost Mine of Phandelver
Crypt of the Sun Lord
DM's Guide
Elemental Evil Companion
Monster Manuel
PHB
Sword Coast Adventurer's Guide (Player's)
Ebberon Rising from the Last War (Player's)
Unearthed Arcana (Player's)
Curse of Strahd (Player's)
DM's Guide (Player's)
Explorer's Guide to Wildemount (Player's)
Mordenkainen's Tome of Foes
Tasha's Couldron of Everything
Xanather's Guide to Everything (Player's)


Which maps (module, custom, etc.)?

Custom Map, got it from reddit: https://www.reddit.com/r/DungeonoftheMadMage/comments/azfw4f/maps_of_the_mad_mage_the_lost_levellvl_6/?ref=share&ref_source=link

Created LoS awhile ago, not too long after Unity was available from the Kickstarter, and then added lighting for all of the stone pillars and the character tokens. Attaching that export to this post.

Maybe it's because I have it all as one layer? I have no doubts that I'm doing something weird/unexpected. Or maybe it's just because it's a big 'ole map, resolution of 6500x8375.

--

What I'll probably try next is just creating a new campaign and starting fresh with some of the exports of the old one, as it has a several maps of that same size now. For the current map I'll make Lighting it's own separate layer as I see that's how it's being done the videos featuring it.

Big ole maps do create a lot of performance impacts. Even though we have a modern Unity software and it's 64 bit, it does not mean we are able to run everything full tilt. Limitations are mainly from bandwidth, the actual file size and Windows paging limitations, and of course, having too many books, extensions, and other things loaded, like thousands of tokens, etc. (like me). More than six players is not optimal, having other things running on the background of your computer, and running low or out of physical hard drive space can also cause issues. Comparing FGU to a modern video game has less merit than knowing how each program works side by side in regards to being optimized into a more universal configuration. MMO and non direct-connect games are designed to run on a shared cloud server, not locally like FGU. Video memory is a thing, locally. The dungeon of the Mad mage is really ridiculous in regards to map sizes, even by Smiteworks standards. Smiteworks even has its own suggested image sizes for maps at 2000x2000 pixels dimensionally. Go any further than that dimensionally, and all you end up doing is scrolling in and out, and moving your map all the time to re-center and zoom in. A medium quality map, under 10 Megabytes is more ideal, especially when sharing content with players over the internet. Everyone has different bandwidth capacity, so that is a bigger, non-fantasy grounds problem, especially IF wirelessly connected or hosting. Books can be unshared or unloaded until leveling up or creation characters. You might leave the PHB open for your players to swap spells, but the only books you really need at the time of play is your adventure, the PHB, and maybe one or two other modules, depending. IN conclusion Bandwidth, file size (dimension & physical HD size), and the amount of 'shared' content does make a huge difference. The more images and maps you share, the more bandwidth is required. Unshare handouts and maps that you have already cleared, or no longer need... The only maps I share are battle maps, or some sort of regional map. Battle maps are typically around 1800x1800 or less. The mad mage map can be represented with tiles if you have the art subscription or your own tiles. You can use the huge map as a regional overview map with pins to your own map creations. A room or two create with tiles is not too bad as far as time. The size suggestions are NOT trying to place limits on our personal experiences, but, it is trying to compensate for the fact that most people have bandwidth issues.

Some potential tips & suggestions:
https://youtu.be/45NWboX58rg (Wireless)
Suggested graphical sizes: https://fgc-kb.fantasygroundscollege.net/knowledge-base/image-formatting-sizes-suggestions-for-fantasy-grounds-vtt/https://fgc-kb.fantasygroundscollege.net/knowledge-base/image-formatting-sizes-suggestions-for-fantasy-grounds-vtt/
45490

[Weissrolf]

I don't agree with the "large maps should be avoided" sentiment. First of all, any map used in FGU is small in comparison to photos done by phones even. 2000 x 2000 px is just 4 megapixels, that's a post-stamp of an image nowadays. Also, this is the very first sentence about Unity's enhancements over Classic on FGU's Kickstarter page:


64-bit support to allow for more content (quality and quantity)

It's a major selling point, yet we get worse performance out of even the same maps we used in Classic.

Even the "bandwidth" argument is kind of moot, because those large(r) files only get uploaded once to every player client and then stay cached on their own local drives. I downloaded a campaign from another forum user to test performance issues, its main map is compressed down to only 16.3 mb for 14800 x 10200 px. My internet line can upload that to a user in less than 4 seconds. FGU takes longer to open a single ruleset module than to upload this large image.

The real bottleneck in FGU is CPU performance of its single-threaded Lua 5.1 engine and likely lacking performance optimizations. Now we get lacking GPU lighting optimizations on top of that. In another thread I suggested to take a look at the Lua 5.1 Just-In-Time compiler, it may improve on the CPU bottleneck many-fold. No idea if anyone from SW looked at that, though, as there were no answers to that suggestion.

[Moon Wizard]

Asset and content size will always be a factor. Any program will have problems if you overload it. If you've ever opened up large images in Photoshop (or other photo editing software), that's a closer approximation of what FG is dealing with from a graphics perspective. The advantage that video games have is that they get to offer a canned experience and have hundreds of engineers; whereas we are working on a general purpose framework without being able to assume anything about the graphics being fed in, and working with a team of three engineers. Also, network bandwidth is always a consideration when passing large amounts of data.

Also, you have to consider that just because your machine is a high-end machine and your network connection is high-speed; you can not assume that all your player machines are high-end machines and have high-throughput connections throughout their home.

On a general point, I would ask that you not apply your guesses to the way our system works in other people's threads, as they are not helpful and just create distractions to getting to a reproduceable test scenario.

If there are issues, we ask that people post as much detail as possible for us to recreate. High-level statements and random performance metrics don't give us any information to work with in order to investigate and fix.

Regards,
JPG

[Weissrolf]

Of course size will be a factor. Bu my system is a high-end machine with fast network connection speed and still suffers from bad performance even with images bought from SW's own shop. That was the point. Don't repeatedly just blame it on image size and network bandwidth, it turns into an excuse. The culprits and bottlenecks of FGU lie elsewhere.

[Weissrolf]

And to clarify: I have complete sympathy for you being a small team. But that doesn't release you from taking responsibility from delivering what you promise to work instead of blaming users for "holding it wrong".

FGU performs calculations on the full image despite tokens only seeing up to the next wall (LoS line). FGU causes load so high that a rather expensive 2018 Macbook Pro cannot deal with it. FGU causes high GPU load on high-performance graphic-cards while displaying a blank white image. These are either bugs or consequences of bad design, which a small team has harder times tackling than a large one. They still need to be tackled, though, while asking users to be patient instead of blaming them.

[SilentRuin]

And to clarify: I have complete sympathy for you being a small team. But that doesn't release you from taking responsibility from delivering what you promise to work instead of blaming users for "holding it wrong".

FGU performs calculations on the full image despite tokens only seeing up to the next wall (LoS line). FGU causes load so high that a rather expensive 2018 Macbook Pro cannot deal with it. FGU causes high GPU load on high-performance graphic-cards while displaying a blank white image. These are either bugs or consequences of bad design, which a small team has harder times tackling than a large one. They still need to be tackled, though, while asking users to be patient instead of blaming them.

Nor does it release you from not stating "I'm guessing here but" instead of acting like you know it for sure. IMHO. I'd not bother engaging in some sort of "I know better" - I don't disagree that there are other performance issues going on right now in TEST server - but really... Duplicating it and providing campaign data is how you show you know what your talking about. Not just stating what you think it is. As the saying goes "put up or..." well that sounds to harsh - but you get the drift.

[Weissrolf]

Performance issues have been replicated and SW can have all the campaign data they need. That's not the problem here. Also not much guessing going on here, unless explicitly stated.

And frankly, if image size was the main culprit then this would just point to design problems again. There is no need to calculate stuff that's not visible or meaningful to gameplay anyway. For example, Foundry (any many other games) only calculates and displays animated FX for areas currently visible by a token, CPU/GPU load decreases accordingly.

FGU is in fact very capable at displaying even enormous images, except for memory consumption being too high for the size of images being displayed. You only run into problems when LoS then calculates vision through two dozen closed walls from one end of the image to the other.

[SilentRuin]

Performance issues have been replicated and SW can have all the campaign data they need. That's not the problem here. Also not much guessing going on here, unless explicitly stated.

And frankly, if image size was the main culprit then this would just point to design problems again. There is no need to calculate stuff that's not visible or meaningful to gameplay anyway. For example, Foundry (any many other games) only calculates and displays animated FX for areas currently visible by a token, CPU/GPU load decreases accordingly.

FGU is in fact very capable at displaying even enormous images, except for memory consumption being too high for the size of images being displayed. You only run into problems when LoS then calculates vision through two dozen closed walls from one end of the image to the other.

This is about TEST in laboratory. You realize this correct? For example the 100% duplicatable test case I provided to SW has nothing to do with your theories here. Provide your 100% duplicatable test with a small campaign made specifically for this with a step by step procedure to show them and they can fix it. But really? Your theory here? Does not match what I see. For example...

https://www.fantasygrounds.com/forums/showthread.php?67564-Latest-test-game-in-TEST-server-that-was-painful&p=592039&viewfull=1#post592039

They fixed the blackout one already with this type of "here is what it does" and hopefully they will fix the lag case. But your "have all the campaign data they need" is ... I'm too polite to say. But build your campaign and step by step PROOF and stop just shouting about what you think the problem is.

[Weissrolf]

My main theory here is that repeated "your image is too large" is not the way to improve the software, even less so the Beta.

[SilentRuin]

My main theory here is that repeated "your image is too large" is not the way to improve the software, even less so the Beta.

Exactly. Theory. Prove it or just hope it gets magically fixed and stop theorizing.

[celestian]

My main theory here is that repeated "your image is too large" is not the way to improve the software, even less so the Beta.

I agree in this case. Even a modest map will be 15 meg and 8Kx8K. I really don't want to hack up maps into smaller pieces because the platform can't deal with it. I was hoping we'd get past that in FGU. I get they are concerned about users with older systems and bad connectivity but do not make that the baseline for the rest of us.

[Moon Wizard]

That particular point is a valid discussion point.

Here is the information I have on image size:

* According to Carl, the size of the graphic asset should not have an affect on display performance directly.

* However, Carl has also repeatedly stated that the following items do affect performance:
** Size of the image window view. (i.e. pixels needed to be drawn)
** Number of tokens
** Number and placement of LoS blocker points
** Number of lights (lesser)

* Therefore, the size of the image "does" impact the above points, because larger images typically have larger numbers of all the other pieces of information. Large image files usually equate to larger data overall.

* Also, users typically want to open those "larger" images in larger windows to "see more"; which impacts the image view size which does impact performance.

* On a similar note, I still personally look at Photoshop as an example of a program that does similar things with layers, and how it definitely is performance impacted by large images 10Kx10K or larger. So, I'm not completely convinced that asset size does not have an impact; since it does take more memory, more load time and more network transfer time.

Regards,
JPG

[Weissrolf]

Here is a comparison of a single large image, no walls, 1 token in both FGU and Foundry on the same hardware. FGU's performance is considerably worse to begin with and it surely won't get better once more assets are added to the map.

https://www.fantasygrounds.com/forums/showthread.php?67225-Very-high-GPU-load-03-16&p=592285&viewfull=1#post592285

[HywelPhillips]

I hope the FG team will take this in the spirit in which it is intended. I'm a big fan of FGU's capabilities, it's my platform of choice. It is a hugely difficult thing to rewrite all the code base into a new framework and maintain products which date back a decade or more. It's a huge achievement to do it with a small team, and I think we all salute you.

We're here because we want to help the platform deliver on its promise. But it does have significant performance limitations that need to be addressed. I run FGU on an iMac or iMacPro that are a couple of years old but among the fastest machines Apple has ever produced, with maxed out memory, SSD and GPUs. I can edit and colour grade 4K video professionally on these machines.

FGU isn't - or at least from my back-of-the-envelope calculation shouldn't - be doing as much GPU-intensive math as a 3D game running at full stretch. For all the lighting and rendering multiple points of view for all the tokens, it should be dealing with 2D spaces, not 3D spaces. As Weissrolf has reported there are reasons to point to algorithmic improvement to reduce the LOS workload rather than limiting the size of user assets. I don't want to have to abstain from using features like lighting because of performance issues on a top-spec machine.

There's also no doubt that the single-threaded nature of a lot of FGU's processing is a serious limitation. I have nine cores sitting idle, one fully loaded and a spinning beach ball every time I search assets for "pumpkin". That's not a bandwidth issue - that's an inefficient search algorithm which not only incurs that time penalty the first time it does a search, it incurs it all over again when you move to page two. And again for page three. There's no caching implemented there, for example, which would at least moderate the problem it if there is no more efficient search algorithm available. And really the rest of FGU shouldn't freeze while the asset window has to go away and do a big old disk search.

Performance can be a bugger to improve, but there are some serious bottlenecks right now which need to be addressed. On the plus side I don't see any fundamental reason why it cannot be improved, since other products have achieved it. Happy to help with the testing when I can, but others are more set up to do it more efficiently than I am, I think.

Cheers, Hywel

[SilentRuin]

Here is a comparison of a single large image, no walls, 1 token in both FGU and Foundry on the same hardware. FGU's performance is considerably worse to begin with and it surely won't get better once more assets are added to the map.

https://www.fantasygrounds.com/forums/showthread.php?67225-Very-high-GPU-load-03-16&p=592285&viewfull=1#post592285

I trust that is in TEST as your posting it here? Also - I also trust you mailed them the campaign with step by step instructions to duplicate it. Else... you know. They have to duplicate it with what you have.

[Weissrolf]

Of course it is Test, especially with Live not offering Lighting yet (and performing better with pure LoS).

But no, I don't just spam SW with campaign files without being asked for it.

[SilentRuin]

Of course it is Test, especially with Live not offering Lighting yet (and performing better with pure LoS).

But no, I don't just spam SW with campaign files without being asked for it.

You have a problem. You can duplicate it. But you have to be asked to send it in?

I've seen them ask for multiple examples in many threads for TEST. Are you saying they have to personally ask you?

[Sterno]

Geez, hug it out already.

[damned]

Guys please drop the to and fro.
Please remember that the strength of words written down on a forum reply are often interpreted differently from reader to reader and from their initial intent.
Everyone is working towards building the product to the best of its capabilities (and limitations).

[allpraisethedm]

We have a session tomorrow night, so I'm on now testing it out. I created a new campaign with just the bare minimum, imported the image, then quickly drew in walls and placed lights and immediate slow down in performance once I started manipulating a player token. Then I reduced the amount of lights, as with the current map, each "quartz pillar" gives off bright light I had about 54 light sources. So I reduced that to 1 light source per little room and three in the main room, 9 in total. It's significantly better, but still not super great, so we'll see how manageable it is tomorrow night.


We had the same problem last night. We thought it was a connection problem, but no. We tested by direct connection and by the cloud. It was fixed when I turned off the ambient light option. But with the light it was impossible to play. We were playing level 3 of the mad mad dungeon with the map that came by default (basic map).
I don't want to get this comment lost, because I think it's pretty important. I brought up the 6th level map from the paid DotMM module in a fresh campaign, added a light for each quartz pillar, and after dropping a player token in, performance is noticeably bottoming out. I had another client connect to my game, and it was even worse for them, but I suppose not as bad as it was last week, double but that's probably because it's just 1 client connected. For example, with token movement lock on, I had them move 60 feet, on my (DM) screen it took ~10 seconds, and on the player's side it took 20ish seconds.

I attached a zip file of the minimalistic campaign that I was able to reproduce the issues with.

[kevininrussia]

We have a session tomorrow night, so I'm on now testing it out.

Good luck, let us know how it goes. I had a game on the test server last week with 6 players. After 15 minutes nobody could move their tokens and I could barely move them. Basically FGU stalled to unresponsive. I would be curious if the performance is improved from last week. The players did remark on how the lights added to the atmosphere. :-)

[Moon Wizard]

@allpraisethedm,

Thanks for the example; I've passed on to @cpinder.

Thanks,
JPG

[Weissrolf]

* However, Carl has also repeatedly stated that the following items do affect performance:
** Size of the image window view. (i.e. pixels needed to be drawn)
Image window and FGU window at smallest possible size (screenshot shows the real size of the whole FGU window!):
https://i.imgur.com/AnHlvIr.png

Image window at smallest possible size, FGU window maximized:
https://i.imgur.com/mBORGWC.png

Image window at largest possible size, FGU window maximized:
https://i.imgur.com/mBORGWC.png


** Number of tokens
** Number and placement of LoS blocker points
** Number of lights (lesser)
All of these should only be calculated when they are visible, including any FX! And in my above example no tokens, LoS blockers or lights were used at all. Only the image was imported.


* Therefore, the size of the image "does" impact the above points, because larger images typically have larger numbers of all the other pieces of information. Large image files usually equate to larger data overall.
Only if FGU keeps calculating all points of data at all times, even those that are not visible by tokens, either on-screen or off-screen. This should not happen.


* Also, users typically want to open those "larger" images in larger windows to "see more"; which impacts the image view size which does impact performance.
As shown in my above screenshots, currently it hardly does matter at all. Performance is always bad.


* On a similar note, I still personally look at Photoshop as an example of a program that does similar things with layers, and how it definitely is performance impacted by large images 10Kx10K or larger.
Photoshop usually works locally, it then only calculates those pixels that are edited, except for some effects that can only be applied to the whole image. Here is a Render->Lighting Effect filter applied to the whole 14800 x 10200 px image in real-time:
https://i.imgur.com/R3Nzduz.gif


So, I'm not completely convinced that asset size does not have an impact; since it does take more memory, more load time and more network transfer time.
Of course load times and transfer times increase with increased image size. But we are discussing live usage here, well after any load times have happened. Files are only transferred once and then cached, load times only happen once. And you did not yet care to improve the latter for PC clients yet, despite them being far worse (longer) compared to GM hosts.

And all that being said, again, FGU should not calculate all pixels of a map when only a small part is visible anyway. You can take a look at how Foundry handles this, FX are only active where visible, even disclosed FoW areas only animate FX when a token can see it. And even when the whole map + FX is visible to the GM then GPU load is considerably lower than current TEST. Furthermore every single client can specifically disable soft shadows, token vision animation, light source animation and/or zoomed anti-aliasing. CPU/GPU load decreases accordingly.

[rhagelstrom]

With FOW causing performance problems in larger maps, is there any way we could get an option to simply disable it so that players only see what they can actually see, but don't retain the "memory" of what they explored? It'd be a preferred style for me anyway even if it didn't apparently have better performance too.

I would up vote this as a feature request

[Laerun]

Image window and FGU window at smallest possible size (screenshot shows the real size of the whole FGU window!):
https://i.imgur.com/AnHlvIr.png

Image window at smallest possible size, FGU window maximized:
https://i.imgur.com/mBORGWC.png

Image window at largest possible size, FGU window maximized:
https://i.imgur.com/mBORGWC.png


All of these should only be calculated when they are visible, including any FX! And in my above example no tokens, LoS blockers or lights were used at all. Only the image was imported.


Only if FGU keeps calculating all points of data at all times, even those that are not visible by tokens, either on-screen or off-screen. This should not happen.


As shown in my above screenshots, currently it hardly does matter at all. Performance is always bad.


Photoshop usually works locally, it then only calculates those pixels that are edited, except for some effects that can only be applied to the whole image. Here is a Render->Lighting Effect filter applied to the whole 14800 x 10200 px image in real-time:
https://i.imgur.com/R3Nzduz.gif


Of course load times and transfer times increase with increased image size. But we are discussing live usage here, well after any load times have happened. Files are only transferred once and then cached, load times only happen once. And you did not yet care to improve the latter for PC clients yet, despite them being far worse (longer) compared to GM hosts.

And all that being said, again, FGU should not calculate all pixels of a map when only a small part is visible anyway. You can take a look at how Foundry handles this, FX are only active where visible, even disclosed FoW areas only animate FX when a token can see it. And even when the whole map + FX is visible to the GM then GPU load is considerably lower than current TEST. Furthermore every single client can specifically disable soft shadows, token vision animation, light source animation and/or zoomed anti-aliasing. CPU/GPU load decreases accordingly.

This was or is a useful post apologizing from earlier comments.

[Moon Wizard]

@Weissrolf,

* The size of the application window is irrelevant, just the size of the image view. You may disagree with whether off-screen textures should be calculated; but it's a moot point because there is no real good reason to keep textures off screen in a game. Most people just close the windows. If having windows off screen using up resources is an issue for you, you should close the windows.

* There is no magic solution to determine whether to calculate tokens/blockers/lights when they are "visible", since you can only determine if they are visible by calculating them.

* Larger data means more calculations; regardless of where things are visually located to the user interface. The visual interpretation of the data can't happen until the data is processed.

* Carl is the expert on the drawing routines, but I know that he has spent a lot of time setting up precalculated values/textures and working to minimize updates needed.

* There are obviously some items we are working through that aren't working as intended; but this is also a beta test where we expected to work through use case and performance issues.

* On a related note, you are often picking apart every post that is made by us; telling us how wrong we are doing things; and asking for responses in detail. I would suggest that this is not the best use of our time. Detailed examples of campaigns and exact steps are what can help us solve.

Regards,
JPG

[Weissrolf]

* The size of the application window is irrelevant, just the size of the image view. You may disagree with whether off-screen textures should be calculated; but it's a moot point because there is no real good reason to keep textures off screen in a game. Most people just close the windows. If having windows off screen using up resources is an issue for you, you should close the windows.
Ok, so out of three examples you take the one example that I only put up for comparison while completely neglecting the real elephant in the room? With the image/map window being sized down to its very minimum size (first! example) load is just as high as with the window being maxed.

Furthermore, 3D application/game resolution does have an impact on every game out there. So it wasn't too far off to check if application window size affects GPU load. I did a quick check changing Windows screen resolution and noticed that I have to restart FGU to make it recognize the change. I suspect the same is true for application window sizes. But again, it was 1 out of 3 examples for comparison.


* There is no magic solution to determine whether to calculate tokens/blockers/lights when they are "visible", since you can only determine if they are visible by calculating them.
Once vision hits a solid wall (occluder) there is no need to calculate any further. Anything behind the wall is not visible except for some exotic magic/sci-fi antics.


* Larger data means more calculations; regardless of where things are visually located to the user interface. The visual interpretation of the data can't happen until the data is processed.
And I demonstrated that Foundry VTT can handle the same large data at considerably lower load. So it's not the data, it's the software. Stop blaming your users for FGU's current shortcomings, that's no way to improve your product.


* Carl is the expert on the drawing routines, but I know that he has spent a lot of time setting up precalculated values/textures and working to minimize updates needed.
Thanks and claps to him. Does that mean we have to only applaud your TEST software instead of poking at the issues? Well then, FGU TEST works great! No problems whatsoever here! Feel free to publish it right away! Yay!


* There are obviously some items we are working through that aren't working as intended; but this is also a beta test where we expected to work through use case and performance issues.
As long as you deny the existence of issues even with hard evidence being presented then no improvements are to be expected.


* On a related note, you are often picking apart every post that is made by us; telling us how wrong we are doing things; and asking for responses in detail. I would suggest that this is not the best use of our time. Detailed examples of campaigns and exact steps are what can help us solve.
Currently I mostly present you with data from empty campaigns, because the issues are so obvious and easily reproducible. I present hard measuring data compared to many others' vague "it's laggy" feedback and repeatedly asked if more information was needed. No answer = they are fine with what they got or they just hate it. No need for me to waste time on niceties then if my content isn't interesting to begin with.

It's your product and your company, you can do as you please, but "your map is too large" will almost always be the wrong answer for users with high-power systems after FGU being marketed "to allow for more content (quality and quantity)".

[Jiminimonka]

Ok, so out of three examples you take the one example that I only put up for comparison while completely neglecting the real elephant in the room? With the image/map window being sized down to its very minimum size (first! example) load is just as high as with the window being maxed.

Furthermore, 3D application/game resolution does have an impact on every game out there. So it wasn't too far off to check if application window size affects GPU load. I did a quick check changing Windows screen resolution and noticed that I have to restart FGU to make it recognize the change. I suspect the same is true for application window sizes. But again, it was 1 out of 3 examples for comparison.


Once vision hits a solid wall (occluder) there is no need to calculate any further. Anything behind the wall is not visible except for some exotic magic/sci-fi antics.


And I demonstrated that Foundry VTT can handle the same large data at considerably lower load. So it's not the data, it's the software. Stop blaming your users for FGU's current shortcomings, that's no way to improve your product.


Thanks and claps to him. Does that mean we have to only applaud your TEST software instead of poking at the issues? Well then, FGU TEST works great! No problems whatsoever here! Feel free to publish it right away! Yay!


As long as you deny the existence of issues even with hard evidence being presented then no improvements are to be expected.


Currently I mostly present you with data from empty campaigns, because the issues are so obvious and easily reproducible. I present hard measuring data compared to many others' vague "it's laggy" feedback and repeatedly asked if more information was needed. No answer = they are fine with what they got or they just hate it. No need for me to waste time on niceties then if my content isn't interesting to begin with.

It's your product and your company, you can do as you please, but "your map is too large" will almost always be the wrong answer for users with high-power systems after FGU being marketed "to allow for more content (quality and quantity)".

Weissrolf.

You seem to deliberately miss the point all the time. Either that or you do miss the point, I am not sure which.

Get the "map is too large" words unstuck from your head and read what was typed by Moon Wizard.

[LordEntrails]

Long detailed responses are a waste of time. The time it takes Moon to read through and comprehend your detailed post is time he can not spend on improving FGU. Therefore hopefully he is not reading them in detail. Therefore the time you spend writing them is not a good use of your time.

What has been asked of you is to provide a short, repeatable, with step-by-step instructions and a consolidated data set that can quickly be understood, the issue repeated and the data available for testing.

Doing more than that is slowing down the development of FGU. As a user who wants to see FGU improve as quickly as possible, please stop spending developer time in inefficient ways. Thank you.

[Sterno]

I say this fully knowing that I'm contributing to all the noise appearing in this thread, but guys, Moon Wizard doesn't need a bunch of posts coming out to defend him and FGU. He can (and has) replied to Weissrolf directly, in this thread and others. They can argue with each other and we can stay out of it.

If you're truly worried about all that reading Moon has to do that takes away from his time fixing FGU, maybe help keep the signal to noise ratio higher by not piling on or repeating what he's already said.

Edit: I'm just going to update this rather than post a response and add to the noise, but guys, seriously, you don't have to get the last word in. You're on one hand complaining about Weissrolf's "spam" while feeling the need to respond to him and complain every time he posts in a thread. You're not helping your own cause if lowering the spam is actually what you care about. You've made your opinions about his posts known. You're just repeating them ad nauseum at this point, and making the cycle continue.

[LordEntrails]

Correct, Moon does not need anyone defending him. Nor was I defending Moon or FGU in anyway.

Effectively spamming the forums with the same complaint in multiple posts across multiple threads with lengthy yet unhelpful details and not the details that have been repeatedly asked for by the developers may look impressive, but it is detrimental to the community and the development of FGU.

[allpraisethedm]

Unfortunately two folks didn't show up last night so I couldn't see what it was like with 4 people connected, but the game was working a lot better after reducing the amount of light sources, which admittingly is a ridiculous amount (54) if you go by what the official module says there are. I haven't updated nor have my players yet since reporting the issue originally.

[Weissrolf]

Effectively spamming the forums with the same complaint in multiple posts across multiple threads
... which I was specifically asked to re-create for each issue, because my collective "Feedback" thread was deemed too convoluted. You may also have noticed that I lately went to the length of posting links to other threads where issues overlap instead of re-posting the same statements/screenshots in multiple threads. Well, it's hard to please everyone...


...with lengthy yet unhelpful details
When measurements are unhelpful then god help us, because sometimes faith is better than science.


and not the details that have been repeatedly asked for by the developers
Like step by step explanations and campaign files when asked for (and meaningful, because posting empty campaigns with empty images seems more like spam to me).


may look impressive, but it is detrimental to the community and the development of FGU.
Yes, if everyone stays lucky-go-happy with software getting released in an unfinished state then the community is well served. But enough of that sarcasm now, a little kid needs some help getting some socks on her feed to prepare for a bicycle tour.

[Jiminimonka]

...

[SilentRuin]

Last worditis... an affliction many of us suffer from ;)

[Jiminimonka]

Last worditis... an affliction many of us suffer from ;)

Not in this case. I edited it. Feel free to get the last word in, before Weissrolf resumes.

[SilentRuin]

Not in this case. I edited it. Feel free to get the last word in, before Weissrolf resumes.

Was referring to his posting. And... well... sometimes mine ;)

[Jiminimonka]

Was referring to his posting. And... well... sometimes mine ;)

Hahaha! OK. :)

[LordEntrails]

MOD: closed