Performance Issues with decent system

[Booker Grimm]

Two of my players are having slow down issues with lighting enabled. The map I'm using does have a number of lights, but should this be slowing things down to a crawl?
Connection speed is fine and no issues and when I disable lighting they report no problem.

Just curious if anyone else is having major slowdown with lighting enabled.

Thanks.

[Zacchaeus]

https://www.fantasygrounds.com/forum...erday-s-Update

https://www.fantasygrounds.com/forum...at-was-painful

[zBeeble]

Urm... fix the foundation before you fix the trim. I have a s***t-kicking system. I have a 16 core threadripper, 64G overclocked RAM and a 2T NVME SSD. I have a lot of modules an extensions loaded (lots of rob2e, for example) but what I don't understand are the following slowdowns.

1. Minutes to load the campaign. It takes longer than Cyberpunk 2077 to get into my current campaign.

2. Scrolling slowdowns for large character sheets. Really... by 100 or so spells, it becomes "clunky"

3. palpable "seconds" to load a map.

All of these things are strange to me because I know what my system can do. There pretty much isn't faster disk available. Maybe a 10% single core advantage on the processor to some Intel things... maybe 25% better single core to the best AMD right now... but we aren't even loading 3D geometry...

[The Decepticon]

Urm... fix the foundation before you fix the trim. I have a s***t-kicking system. I have a 16 core threadripper, 64G overclocked RAM and a 2T NVME SSD. I have a lot of modules an extensions loaded (lots of rob2e, for example) but what I don't understand are the following slowdowns.

1. Minutes to load the campaign. It takes longer than Cyberpunk 2077 to get into my current campaign.

2. Scrolling slowdowns for large character sheets. Really... by 100 or so spells, it becomes "clunky"

3. palpable "seconds" to load a map.

All of these things are strange to me because I know what my system can do. There pretty much isn't faster disk available. Maybe a 10% single core advantage on the processor to some Intel things... maybe 25% better single core to the best AMD right now... but we aren't even loading 3D geometry...

It takes you minutes to get into a campaign? I never timed from when I clicked the button to getting into a campaign, but I would have to say it is no more than 30 to 45 seconds, if that. Most of the maps I have pulled up are pretty much instanteous and I never have to pause my game or wait for a map to load.

I will admit I have not had the issue with the spells as I have not had over 100 spells loaded on one character sheet. That's a pretty powerful wizard!

My system is no where even close to yours, so not sure why you are seeing those long load times.

[zBeeble]

It takes you minutes to get into a campaign? I never timed from when I clicked the button to getting into a campaign, but I would have to say it is no more than 30 to 45 seconds, if that. Most of the maps I have pulled up are pretty much instanteous and I never have to pause my game or wait for a map to load.

I will admit I have not had the issue with the spells as I have not had over 100 spells loaded on one character sheet. That's a pretty powerful wizard!

My system is no where even close to yours, so not sure why you are seeing those long load times.

Well... obviously, time-to-load is related to amount of data --- maybe you don't have all of rob2e. Whatever. 30 to 45 seconds is still too long. Cyberpunk 2077 loads in 10 or 15 seconds for the first time. loading a map is related to the map size and/or also all the rest of the stuff. My _complaint_ is that the constant multiplier on this amount of data is too large (if you want to be technical).

As for a 100 spells? Not hard for a 15-ish level wizard to have well over 100 spells. Not memorized --- and there inlies a clue --- when I have "combat" mode on --- only my 20 or 25 memorized spells + a dozen or so class/race abilities (which are coded as spells) is significantly faster (even to move the window around) than when preparation mode is active and all spells are visible.

Heck for a scroll wizard, their 14th level ability involves forgetting some number of spells to nullify incoming damage --- so they're literally _encouraged_ to have a large number of spells known.

[Moon Wizard]

Time to load is directly related to the number of products installed, as well as the number of assets (images/tokens) installed.

How many modules do you have in your module directory?
(Same for images and tokens...)

JPG

[zBeeble]

I have 144 modules. Maybe around 40 loaded ... 6 or 8 for the base game and things like tasha's, 2 for the module I'm running and about 30 for rob2e to automate things that really should be in the base game.

But that's not the thing... the average mod is (say) 5 megabytes compressed ... mostly of XML in the case of rob2e. These are taking 5 to 10 seconds to load each according to the debug output and there seems to be more delay that's not accounted for by that number. That's not a reasonable XML parsing rate --- this game is slow in so many ways that don't make sense. Optimization is required.

But the slow in loading is tolerable being before the game. Load all the 1-15 level cleric spells into a cleric and then go into preparation and scroll the character sheet up or down --- or even just try to move the window in preparation mode. That's painful.

[Moon Wizard]

With 40+ modules loaded, I'm going to suggest that you're going to see some performance issues. The compressed size of the data is not relevant; as the data has to be exploded into memory and objects created to represent each data node and record. I would suggest unloading any modules that you are not immediately using for a game. Just a suggestion.

We are aware that large lists have a performance issue; but have not been able to identify yet nor time to investigate heavily. This is worse on FGU, but still an issue on FGC. For clerics, we only recommend adding the memorized spells to the character sheet for the best performance.

Regards,
JPG

[zBeeble]

I get the temptation to "doctor when I do this it hurts" -> "Then don't do that" ... but ...

Is this project not boost-enabled? Are you not rich enough to afford good C++ coders?

... Sorry ... that was out-of-line. You should at least acknowledge that this _is_ a problem and it _is_ on a list somewhere. Acknowledging where it is on the list would be cool too .

The fact that a list of 100-ish spells can drag down the window-moving interface says to me that you need to move from an object system that touches everything in the stack when an item in the stack is touched to only touching the items that need be rendered _after_ the whole stack has settled. Simple, but often missed GUI simplification.

But further on, given that you should be able to walk many 100's of megabytes of data per second (possibly even several gigabytes) ... how does a list of 100 items slow you down anyways --- that just begs the astonishment.

And there lies the reason for my post. I realize some of what you done, but even given some of my most pessimal assumptions... there's got to be some glaring bits that are being overlooked. Buy yourself a profiler, maybe? I recall them costing the earth back-in-the-day (in the 1000's per seat), but it's sorely needed here.

Asking users to pare down their spell lists ... well... have you met my cleric? :-/...

[Moon Wizard]

One consideration that I think many people miss is that because the FG client is a platform with an API; there are a lot of things that we cannot assume about how each piece of code needs to interact with others, nor what APIs will be called. Every piece needs to implement every interface, which is much more memory and performance intensive.

As I mentioned in other places, we only have two engineers that work on the main client code (of which I am one; but I split my time working on ruleset code and answering questions too).

Given that, it would be nice to be able to point at an exact spot in the code, and say I'll fix that and it fixes everything. However, the FG engine is very complex and there is no simple way to determine exactly what piece of code is the problem. Believe me, we've worked with the Unity performance tools, and they are very limited as to the amount of data they can handle (which FG exceeds).

If this was a large pre-packaged game title, we would break things into levels, minimize textures loaded, and many more optimizations. However, as a general purpose platform, you can't assume any of that.

Regards,
JPG