All Encompassing Image & Module Memory Reference Guide

[RobboNJ69]

I've been DMing with FG for a couple of years now and it's going great. I want to add some additional campaign & background material, but I don't want to bog down the system. I've seen plenty of discussion on what the ideal individual map sizes are as well as token sizes, but I haven't been able to find a definitive reference to what uploads impact the game. For instance: Maps uploaded, but not shared? Tokens in the Host but not used, etc. I'm hoping to create a single reference source for that information. Side note: I'm hoping for factual information based on the architecture of the software, not necessarily anecdotal references. While interesting, personal experiences are very subjective and based too much on system/network specs.

Specifically, what impact does the following have on load times and system resources, For the DM and separately for the Players (since I'm pretty sure it's a different impact).

1. Maps/Images in the images folder that are not shared with players. Does this slow the system down? Are they ignored until they are shared? Point of reference: most of my campaigns have a bunch (>12) maps, all around 3500px on a side. (I like big maps and I can not lie. You other DMs can't deny...) I've never had any performance issues, but I also only share one or two at a time. Theoretically, can I have dozens as long as they aren't shared with the players or opened during the session?

2. Tokens in the Host folder that are not brought into play: I.e. not shown on a map or attached to an NPC/Character. Do they count towards memory use? Or is it only once they are brought into play?

3. Maps/Images in campaigns other than the active one being used. I have 3 or 4 campaigns created, do the maps in those count? Or only what is in an active (live) session.

4. Map Mods That are uploaded (ready for play) but not 'loaded' in the library. Do they count? Or only when the mod is loaded and available in the image library? Or do they only count when shared with players?

5. The number of Token Mods you have available to 'load', but not actually loaded. Do they count or impact the memory/resources of the system? I've seen the threads about creating Mod libraries of tokens, so I imagine they don't count unless loaded, but I want to be sure.

6. The number of Map Mods you have available to 'load', but not actually loaded. Same as above, but I don't want to assume Tokens and Maps are handled the same way.

7. The number of Reference books available to the DM, but not the players. Does having all the bestiaries and reference books loaded slow down the game overall or only slow down the player's connection if shared?

8. The number of Rule Sets available. We only play PF. Does it impact the performance to have 5e and all the others in the rulesets library?

Anything else that should be known or considered?

As always - thanks in advance for any info!

Robbo

[LordEntrails]

1) No
2) These impact the GM/host memory use as FG loads them all when the campaign is loaded. You can see this simple by testing campaign start times.
3) Nope
4) No. The GM/Host client does not load an image (I'm not talking tokens) until it is opened. The player/client loads all images that are shared int he campaign upon start.
5) Token Modules, no, tokens in the host or shared sirectories, yes.
6) No
7) No (EDIT: except they do impact load times of the object lists since their are more items in those lists, but text alone is not a memory hog, images are.)

In short, host and player clients behave differently when it comes to images. Host only loads images when opened, Clients loads all images on campaign join. Tokens in the host folder are loaded on host start. Tokens in the shared folder are loaded by host and client upon campaign start/join.

You can test all this by starting a second instance of FG using localhost and monitoring process size via Task Manager.

[Trenloe]

Host only loads images when opened, Clients loads all images on campaign join.

Since v3.3.7 (released a year ago) the client only loads images when they’re opened.

[Trenloe]

1. Maps/Images in the images folder that are not shared with players. ... Are they ignored until they are shared? Point of reference: most of my campaigns have a bunch (>12) maps, all around 3500px on a side. (I like big maps and I can not lie. You other DMs can't deny...) I've never had any performance issues, but I also only share one or two at a time. Theoretically, can I have dozens as long as they aren't shared with the players or opened during the session?

Yes, the memory use is not really impacted until an image is opened. If you have maps larger than the recommended 2048x2048 pixels then it’s OK to have one or two a little larger than this shared at a time - but don’t go nuts and always consider you, and the players, monitoring the memory use of the FantasyGrounds.exe process.

Keep in mind that 3500x3500 images use about three times the number of pixels that 2048x2048 images use. If you use one of the layer extensions this would be nine times!

[Weissrolf]

When I prepare Pathfinder maps for printing at native DPI of my printer I easily get over 25000px on one side (Strange Aeons asylum map). Until FG turns 64 bit I better not load any of these 2 gb images then.

That being said, even the original file is 4200px on one side at its native 72 dpi, so I am glad that images only use memory when they are loaded and hope for 64 bit when Unity comes.

[damned]

if the image is 2gb its still going to suck when you share that with players. 64bit or not.

[Weissrolf]

Of course, like I wrote these are the images I prepare for printing and half the DPI would likely be sufficient anyway. At this size you also run into TIFF incompatibilities with several different programs and combinations of TIFF compression, so things get ugly even on a local desktop basis.

I converted my test dungeon (Briarstone Asylum) to 100 dpi. This resulted in a 150 mb uncompressed TIFF file for the whole dungeon.

[LordEntrails]

Since v3.3.7 (released a year ago) the client only loads images when they’re opened.

Thanks, gotta remember that!

When I prepare Pathfinder maps for printing at native DPI of my printer I easily get over 25000px on one side (Strange Aeons asylum map). Until FG turns 64 bit I better not load any of these 2 gb images then.

That being said, even the original file is 4200px on one side at its native 72 dpi, so I am glad that images only use memory when they are loaded and hope for 64 bit when Unity comes.

When it comes to image resolution I always try to think of it from a different aspect. What resolution is your computer screen and how close are you going to zoom in? That to me is the absolute max resolution you should have your images at. So to do the math say you are doing 3200 x 1800 screen resolution, are you going to zoom in more than maybe 6 squares high? So 6 squares across 1800 is 300 pixels per 5 foot square. (Which is much much higher than the nominal 50). But that to me sets an absolute max. And then I normally don't ever zoom in that far and typically use 100 pixels per 5 ft myself, besides, I prefer larger distance maps and would rather have more space for the encounter to develop than a prettier picture. Another use is for tokens, since most tokens are one square, any toekn above that resolution is only going to be seen if someone zooms in to fill their whole screen.

[RobboNJ69]

Thanks for the quick response, everyone!

A couple follow up questions for clarification:

Since v3.3.7 (released a year ago) the client only loads images when they’re opened.

By "opened", does that include "Pre-Loaded" or literally opened on their screen?
So...
Map in DM Library, But not shared, nor opened. - No memory issues for anyone.
Map in DM Library, Opened on DM side, but not Shared or Pre-loaded - impact on DM Resources, but not Clients.
Map in Opened by DM and Shared or Pre-loaded But not Opened by Clients - impact on DM resources Only.
Map in Opened by DM and Shared or Pre-loaded - impact on DM and Client resources.

Sorry for being so exact, but I want to write this up clearly for everyone else and I want to make sure I have it right. Thanks Again!

[Weissrolf]

At 100 dpi/ppi (pixel per inch) you get 100 px per 5 ft grid square (1 square = 1 inch). 100 dpi seems like a sensible compromise for current displays, albeit I would prefer 150 dpi. Fantasy Ground already crashes trying to load the 100 DPI image (both TIF and JPG), though, so I will have to run more tests on what works in practice.

Will Unity be 64 bit? More usable memory is always a plus when dealing with large map images.