Heavy performance issues seemingly related to a large map

[ikeaboy]

Hi,

We had severe issues last Friday when using a rather large map with lots of walls, doors and lights.

We are using Rolemaster classic ruleset on Unity. There were three players on the session.



Token movement slowed to a crawl - moving them over a longer distance required several drags
While moving tokens on map, everything else became frozen - opening menus etc was not possible
Die throwing got corrupted in some way - the throw results occasionally did not register at all. Combat tracker stopped registering the throws, too. Basically the system went stone age on us.
In general the whole platform became near unusable


Earlier used two maps fared a lot better. They were smaller in size and had less elements (walls, doors, lights) on them. We were able to play through them quite well. On one earlier map we had plenty of enemies, too (30) and that was no problem. On this problem map there were only 3 enemies in combat, but the slowness was there even without enemies or combat. Just trying to move a single token on the map is near-impossible.

Mine and our players computers are rather capable, so the bottleneck should definitely not be there.

I'm the GM and my old comp has following specs:
- Core i5-7600K
- GeForce 1060
- 32GB RAM
- WIN10

My new comp has following specs:
- Ryzen 7 5700G
- GeForce GTX 3070 Ti
- 16GB RAM
- WIN11

Similar specs for the players. There is no noticeable difference in performance between my old or new comp in this matter. The issue is reproducible every time on that map.


I have a feeling that the perf used to be better a couple of months back, when I created and tested the map. However, this was the first time we played the map.


--> Have I reached the limit of the capabilities of the SW with this map? Can it really stress the system so much if the map is this size? This would make my life as a GM a lot harder in the future, as I'm planning even much larger maps and scenarios.

508765087750878

Br,
_petteri

[Sulimo]

I cannot tell for sure, but it looks like some of those LoS points overlap a bit. If you can simplify the number of points, it should help. There is a new (as of a couple of months ago) to simplify the LoS, it may not work in your case, but I cannot really tell because the image is too small (see screen shot below).

How big is the map, the preview you have attached looks pretty small?

The larger the map, and the more LoS nodes, the more it will impact performance.

Here are some things you can try, (https://fantasygroundsunity.atlassian.net/wiki/spaces/FGCP/pages/1638006786/Reducing+GPU+Usage) but there is only so much that can be done with really large maps.

One thing I noticed helped, was to make sure token locking was on. That way, the players are not all trying to move their tokens at the same time. It helps out quite a bit.

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

[Trenloe]

Waht @Sulimo said.

Plus: what size (width x height in pixels) is the image?

How many PCs and NPCs in the combat tracker and on the map?

Please compile your logs while running this campaign and attach the resulting ZIP file here. Details on compiling the logs here: https://fantasygroundsunity.atlassian.net/wiki/spaces/FGCP/pages/1242136781/How+to+Compile+Logs

[ikeaboy]

Simplify -function seems not intelligent enough to handle this. Tried it on a few places with unsatisfying results.

The map has endless nooks and crannies that I wanted to carefully model with the walls to get realistic light and shadow. The wall creation was heavy enough the way I did it (with overlapping sections). Trying to make it pixel-tight without overlapping would likely drive me crazy... :P

Not quite sure how to measure the size of the map. But here is a close-up from the center. Note that I have for instance modelled the individual bars of grate doors to create realistic shadows for them.

50881

Total image size for the base map is 12800x13440px, 57MB

[Trenloe]

Total image size for the base map is 12800x13440px, 57MB
That's over 172 million pixels. It's recognized by the developers that FGU does currently struggle with large maps. At this point the general recommendation is 4,000 x 4,000 pixels (16 million pixels) - so you're over 10 time the recommendation.

[ikeaboy]

That would seem to explain the issues faced. Gotta compress the map, then. Do you know of issues with the given amount of walls/entities on my map? Just something to know before I start re-drawing all those walls on the new and smaller map...

[Trenloe]

That would seem to explain the issues faced. Gotta compress the map, then. Do you know of issues with the given amount of walls/entities on my map? Just something to know before I start re-drawing all those walls on the new and smaller map...
It's an ongoing process for the FGU developers to improve performance. Ultimately, the more calculations the system has to make will result in a slower system. The more occluder lines you have on the map, the more calculations will be made for each token. The more tokens you have on the map, the more calculations have to be made. The more pixels on the map, the more calculations. The more light sources, the more calculations. The more movement being done in a short period of time (e.g. if the players all move their tokens around regularly - maybe exploring) the more calculations that have to be made. And so on...

So, in order to help, try to keep occluder lines simple. Make more complex shapes boxy - maybe a square in the middle of a pillar, for example. Remove redundant nodes.

[Sulimo]

The more LoS nodes (the places where they connect up), the more of a performance hit.

Just looking at your close up, there are redundant nodes (nodes inside of walls), get rid of those.

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

[ikeaboy]

Wishing some quick improvements on the map management of FGU. The ability to run realistic maps was one of the main drivers for me to upgrade to it. Dropping my base map quality to 40px/map square to get it to overall 4000x4000px makes it dead ugly - can't see any of the details anymore.

[Sulimo]

Additionally, I am assuming this is a Door (kinda hard to tell). Looks like a bunch of Terrain Occluders?

Try using the Door Occluder instead, it will have less nodes.

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

The Door Occluder needs to be a closed polygon, but you can make it a square, rectangle, or really any other shape.

Here is a rough example, I don't have your image to use, but I suspect this would work better than the Terrain Occluder.

https://i.imgur.com/7ld8us7.png


I usually just put the Door occluder over the threshold, despite where it is drawn on the map.

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

[ikeaboy]

Nope, it's not a door. It's a gate made of iron bars. It's supposed to be see-through and the bars are supposed to make individual shadows. A door blocks all light - not the same thing. It looks really cool with light. I'm really big into things looking cool - it makes a big effect on the immersion. But presumably too heavy for the system. Shame.

I see your points on reducing the amount of occluders in general and especially reducing their overlapping. It's just really hard to snap to the existing lines - it's supposed to do that, right? Not for me. Snap would make it muuuch easier. I gotta overlap to ensure no light sneaks through the gaps.

[Trenloe]

Dropping my base map quality to 40px/map square to get it to overall 4000x4000px makes it dead ugly - can't see any of the details anymore.
I know it's not a great solution, but maybe consider splitting the map up into smaller maps. The main gotcha with this is that the exploration history of a token is retained only for the current map the token is on - there is a commuity extension that allows the saving and reusing of previous exploration history, but I've never used it (so I can't recommend it), I don't know if it could possibly contribute performance issues in itself, and it's a paid for community extension - but it's available here if you're interested: https://forge.fantasygrounds.com/shop/items/224/view

[Zacchaeus]

Use windows for bars. You can add a shadow occluder as well if you want a shadow.

[ikeaboy]

Use windows for bars. You can add a shadow occluder as well if you want a shadow.

Thanks for the hint, will try this!

[ikeaboy]

I know it's not a great solution, but maybe consider splitting the map up into smaller maps. The main gotcha with this is that the exploration history of a token is retained only for the current map the token is on - there is a commuity extension that allows the saving and reusing of previous exploration history, but I've never used it (so I can't recommend it), I don't know if it could possibly contribute performance issues in itself, and it's a paid for community extension - but it's available here if you're interested: https://forge.fantasygrounds.com/shop/items/224/view

Yeah, was thinking about that, but maybe I'll try something in between now first. Lowering the overall size to 6kx6k px. That would have a 60px/square resolution that looks semi-decent. Have another map that size and it worked ok, so maybe this one would too...

[Sulimo]

Nope, it's not a door. It's a gate made of iron bars. It's supposed to be see-through and the bars are supposed to make individual shadows. A door blocks all light - not the same thing. It looks really cool with light. I'm really big into things looking cool - it makes a big effect on the immersion. But presumably too heavy for the system. Shame.

I see your points on reducing the amount of occluders in general and especially reducing their overlapping. It's just really hard to snap to the existing lines - it's supposed to do that, right? Not for me. Snap would make it muuuch easier. I gotta overlap to ensure no light sneaks through the gaps.

It does Magnetic snap for the nodes. I have noticed some oddities from time to time if I am really zoomed in, but it works for the most part.

https://i.imgur.com/3DqAUX6.png

[ikeaboy]

It does Magnetic snap for the nodes. I have noticed some oddities from time to time if I am really zoomed in, but it works for the most part.

https://i.imgur.com/3DqAUX6.png

Only for the nodes? Not the lines, themselves?

[Sulimo]

So far as I am aware, only the nodes snap. So you would bring a line close to another node and you should see it snap to the existing node.


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

[ikeaboy]

Yep, nodes snap. Was using rectangles when making the walls for the given map to make the job easier. Another benefit in using them is that they tend to align better - my free hand is not that accurate to make single lines exactly horizontal or vertical, especially when you need to draw so many. No patience to be that accurate on that scale. Rectangles do not seem to snap in that way. Only lines. Gotta use the lines then.

[Sulimo]

Hold Shift to get the Lines to snap in 45° increments, that should make it easier.

[ikeaboy]

Hold Shift to get the Lines to snap in 45° increments, that should make it easier.

Gotta love you, mate. Thanks!

[Zarestia]

If you upload your campaign, be sure to do it on a filesharing service (Google Drive, OneDrive, etc.) as the forum has max upload for .zip of ~10 MB.
I'm interested to test said map myself.

[ikeaboy]

If you upload your campaign, be sure to do it on a filesharing service (Google Drive, OneDrive, etc.) as the forum has max upload for .zip of ~10 MB.
I'm interested to test said map myself.

Sure, can do that tomorrow.

[Laerun]

There are also other factors that have been suggested for sluggish performance in addition to large images with LoS. The map included in this post is certainly suspect.
There could also be some other things that add to the memory load and the performance of the table. Reducing the size of encounters, which generally includes several combatants at one time on the combat tracker and have quite a few tokens attached to the encounter.
Sometimes, video card settings have been suggested to change the vsync setting, this was included in the troubleshooting process and documentation on the Fantasy Grounds Unity Atlassian. This performance might also be contributed to having too many sources shared.
Also, things such as having more than five or six players at a time could also make things harder on the performance as well. Three people should not be bad though.

https://youtu.be/TPqaVDlE-ho

[LordEntrails]

Something to keep in mind when adding LOS occluders along a complex wall; It's nice to think about "realism", but you can't forget practicality (performance) as well as what is actually going to be used.

Tokens only get placed in 9 places on each square (center, corners, edge middles). So any resolution of an occluder that is more refined that that is really not going to benefit LOS much. Practically this means that you don't need to follow jagged wall edges with a resolution of more than 1/2 grid.

The other thing to think about is zoom level; from a practical perspective, how close in are you going to be zoomed in when you are actually playing? (i.e. in combat, not when you zoom in to look at how cool the map is). I would generally consider this to be ~10 squares tall. Of course depending upon your screen resolution, say this is typically less than 1800 pixels high (and most are much less than that), so simple math tells me that any grid of more than 180 pixels is wasted. And from a practical point, most time I'm zoomed in more like 20 squares, which means 90 pixels per square.

[ikeaboy]

If you upload your campaign, be sure to do it on a filesharing service (Google Drive, OneDrive, etc.) as the forum has max upload for .zip of ~10 MB.
I'm interested to test said map myself.

Here's the campaign folder:
https://drive.google.com/file/d/1VXlLWu_RNzjkeJTERePbFX0KapXJf6CA/view?usp=sharing

Catacombs Battlemap 4 is the missbehavin' one.

[Zacchaeus]

Yes, that map is colossal and it's also a .png file. Exporting it from Photoshop as a medium .jpg file will half it's size and reducing the resolution to 4000x4200 brings it down even more to around 4Mb which should be fine.

[Trenloe]

Here's the campaign folder:
https://drive.google.com/file/d/1VXlLWu_RNzjkeJTERePbFX0KapXJf6CA/view?usp=sharing

Catacombs Battlemap 4 is the missbehavin' one.
Thanks for providing the campaign file.

Doing some testing with a GM instance and a player instance of FGU on the same computer the maps appeared OK (took a while to open, due to the number of pixels) but once open on the GM and player side I was able to use it OK.

However, when I added a single light effect to one of the PCs on the combat tracker (the effect was LIGHT: light 60 which has no animation) that is when the system slowed to a crawl for me and I got similar to what you described in post #1.

@ikeaboy - Did the issue go away when you reduced the size of the map?

[ikeaboy]

Thanks for providing the campaign file.

Doing some testing with a GM instance and a player instance of FGU on the same computer the maps appeared OK (took a while to open, due to the number of pixels) but once open on the GM and player side I was able to use it OK.

However, when I added a single light effect to one of the PCs on the combat tracker (the effect was LIGHT: light 60 which has no animation) that is when the system slowed to a crawl for me and I got similar to what you described in post #1.

@ikeaboy - Did the issue go away when you reduced the size of the map?

Ah, you're right! I always tried it with a character having token light! Can't say if the issue went away as I didn't have time to recreate all the walls, doors etc on the smaller map, yet. Will do that some day this week, when I have the time. Will then try to get one-two players to try it out with me.

Btw, there were no issues with the other two catacombs maps (1 and 2). They are significantly simpler and smaller, though.

[*Neuro*]

Total image size for the base map is 12800x13440px, 57MB

This software and your connection cannot handle 57mb map, I would stay well under 5mb.

Personally I try to stay around 1mb or below.

[Trenloe]

This software and your connection cannot handle 57mb map, I would stay well under 5mb.

Personally I try to stay around 1mb or below.
For clarification and to not cloud the discussion in this thread: yes, the recommendation is to keep image file sizes low as the file size of the map affects sharing time to the players. Once shared and the players have downloaded the map, purely the file size (not the number of pixels) wouldn't have an impact on what's being discussed in this thread.