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.

[RobboNJ69]

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 (150 mb) image, though, so I will have to run more tests on what works in practice.

Wow! Are you trying to show dust and carpet fibers in your maps? lol

[Trenloe]

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 (150 mb) image, though, so I will have to run more tests on what works in practice.
DPI doesn't match to dots-per-grid-square on a map - unless you're exactly matching a grid square to be physically one-inch on your screen. It may seem the same, but it's actually not when looking at computer image dpi, because you can save a map at 300dpi through a graphics app but still have 50 dots-per-grid-square. In FG we tend to think of pixels-per-grid-square. :)

Oh, and you're going to have to get used to using compressed images in FG - be it classic or Unity. 150mb file size is way too big for efficient processing and terrible for sharing with players.


Will Unity be 64 bit?
Yes.

[LordEntrails]

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 and less crashes are always a plus when dealing with large map images.
So as mentioned, dpi/ppi doesn't mean anything on a screen. Those are printing terms :)

So, if you make a map that is 100 pixels per 5 ft square, whether it crashes FG or not has to do with the total number of pixels the image has. i.e. 15k x 15k pixels is a huge image, and when opened into RAM uses up lots of memory, and hence crashes any 32 bit program. It doesn't matter if that image is 50 dpi or 600 dpi/ppi.

I believe Gimp and other programs will tell you under image properties how much memory an image takes when opened (it's different than file size). Or of course you can open it in Paint or such and see what the process size it.

[Weissrolf]

Wow! Are you trying to show dust and carpet fibers in your maps? lol

This is a 100% crop from a 100 ppi image. The original already is low on quality (blurred square lines), but I am using specialized software (Topaz Gigapixel AI) to get rid of aliasing staircasing and invent new details into objects (like the open book on the table). With maps from Pathfinder adventure paths I also get rid of compression artifacts.

30621

Unfortunately the software does not identify all parts of the image, having problems with the blurred ground floor and most of the grass patches. But the furniture, papers, books and other details on the map are much improved over the original image and 100 ppi is close to my own display's native ppi. And with other images this works superbly well.

Word of warning: Your browser may (by default) resample the image even when you set it too 100% zoom, this depends on your OS display dpi settings and browser settings.


DPI doesn't match to dots-per-grid-square on a map - unless you're exactly matching a grid square to be physically one-inch on your screen.
Which I do, at least close to my own physical screen. This is why I called 100 dpi a sensible compromise for todays' screens (will have to check the specs of my group members' screens for a good compromise). I calculate the physical size of the map to make its squares physically match 1 inch (or 2 inch for the example map above), additionally I resample to the target DPI (printer) or PPI (FG). I tried 100 ppi for FG both as uncompressed TIFF and high quality JPEG, but that crashed the program. Next I will test if this is an issue of file-size or of total pixel dimensions.


It may seem the same, but it's actually not when looking at computer image dpi, because you can save a map at 300dpi through a graphics app but still have 50 dots-per-grid-square.
I specifically resampled the image to match 100 pixels per physical inch. Since this specific map comes with 10 ft squares each square is 200 px. You can check this with the example posted above.


Oh, and you're going to have to get used to using compressed images in FG - be it classic or Unity. 150mb file size is way too big for efficient processing and terrible for sharing with players.
150 mb is nothing on my desktop computer, but for sharing purposes it makes sense to compress the images. I listed uncompressed size to give a better understanding of the bitmap size of one single large map. At 92% quality YCbCr (no subsampling) this already squeezes down to 20 mb JPEG size, more compression certainly is easily possible. But FG crashes with the 20 mb file, too, so its not about original (compressed) file-size.


So, if you make a map that is 100 pixels per 5 ft square, whether it crashes FG or not has to do with the total number of pixels the image has. i.e. 15k x 15k pixels is a huge image,
My test image is 6299 x 8268 at 100 ppi, which corresponds to only 150 mb uncompressed memory being used.


and when opened into RAM uses up lots of memory, and hence crashes any 32 bit program.
According to some other forum post FG can address up to 3.5 gb on 64 bit Windows. Faststone Image Viewer can display a 1.9 gb 22677 x 29764 px image within its 32-bit address space without crashing, so FG crashing with a 150 mb image is not even close to any memory limits.

[LordEntrails]

My test image is 6299 x 8268 at 100 ppi, which corresponds to only 150 mb uncompressed memory being used.
Yep, depends on file format and what FG uses to display the image. Stuff I don't know enough to comment on.


According to some other forum post FG can address up to 3.5 gb on 64 bit Windows. Faststone Image Viewer can display a 1.9 gb 22677 x 29764 px image within its 32-bit address space without crashing, so FG crashing with a 150 mb image is not even close to any memory limits.
Yep, but if a player of your is on 32 bit Windows them then are limited to about 1.3GB total process size.

[Weissrolf]

6299 x 8268 x 24 bit (RGB) = 149 mb

File sizes of uncompressed file formats (like uncompressed TIFF) usually closely correspond to the real memory usage of an image, plus some minor overhead.

You can turn this into a 5 mb JPEG and it will still use 149 mb memory after being loaded. Compression then just serves the intend of sharing it with other players over a supposedly slow net connection.

[Trenloe]

This is a 100% crop from a 100 ppi image. The original already is low on quality (blurred square lines), but I am using specialized software (Topaz Gigapixel AI) to get rid of aliasing staircasing and invent new details into objects (like the open book on the table). With maps from Pathfinder adventure paths I also get rid of compression artifacts.

30621

Unfortunately the software does not identify all parts of the image, having problems with the blurred ground floor and most of the grass patches. But the furniture, papers, books and other details on the map are much improved over the original image and 100 ppi is close to my own display's native ppi. And with other images this works superbly well.

Word of warning: Your browser may (by default) resample the image even when you set it too 100% zoom, this depends on your OS display dpi settings and browser settings.


Which I do, at least close to my own physical screen. This is why I called 100 dpi a sensible compromise for todays' screens (will have to check the specs of my group members' screens for a good compromise). I calculate the physical size of the map to make its squares physically match 1 inch (or 2 inch for the example map above), additionally I resample to the target DPI (printer) or PPI (FG). I tried 100 ppi for FG both as uncompressed TIFF and high quality JPEG, but that crashed the program. Next I will test if this is an issue of file-size or of total pixel dimensions.


I specifically resampled the image to match 100 pixels per physical inch. Since this specific map comes with 10 ft squares each square is 200 px. You can check this with the example posted above.


150 mb is nothing on my desktop computer, but for sharing purposes it makes sense to compress the images. I listed uncompressed size to give a better understanding of the bitmap size of one single large map. At 92% quality YCbCr (no subsampling) this already squeezes down to 20 mb JPEG size, more compression certainly is easily possible. But FG crashes with the 20 mb file, too, so its not about original (compressed) file-size.


My test image is 6299 x 8268 at 100 ppi, which corresponds to only 150 mb uncompressed memory being used.


According to some other forum post FG can address up to 3.5 gb on 64 bit Windows. Faststone Image Viewer can display a 1.9 gb 22677 x 29764 px image within its 32-bit address space without crashing, so FG crashing with a 150 mb image is not even close to any memory limits.
Lots and lots of info you're posting here - and it makes me concerned because you really, really, really need to start thinking a lot smaller for use within a client/server VTT environment, even in FGU under a 64-bit environment. FG is not just about maps, it has lot of other complex functionality, whereas FG Unity might be able to cope with large maps, if you're overloading either the GM or player side then other aspects of the VTT can run very slowly - making your gaming experience pretty painful - but, hey, you'd have nice maps! ;)

And, slightly related, if you want to match one FG grid-square to one physical inch on the TV screen, then you can use this FG extension, no matter what pixels-per-grid square your map is setup in Fantasy Grounds: https://www.fantasygrounds.com/forums/showthread.php?33834-Map-resize-to-TV-resolution-for-Face-To-Face-games

[Weissrolf]

I just had a look at the FG version of "Hallod's Hideout" map from the PF2 "The Fall of Plaguestone" adventure, it seems to be using 62 PPI.

Unfortunately FG's UI scales maps with both its own UI scale setting and Windows display DPI setting, even combining both. So setting map size to "Original size" leads to different image sizes depending on the combination of these settings. I hope that Unity will improve UI scaling (especially fonts).


...whereas FG Unity might be able to cope with large maps, if you're overloading either the GM or player side then other aspects of the VTT can run very slowly...
Could you explain why FG will run slowly when there is still enough memory free after loading "nice maps"? Loading the "Hallod's Hideout" map at 100 PPI and zooming/scrolling around in it does not even tax my CPU enough to make it leave lower power saving clock-rates. So besides the memory imprint what else could go wrong?

Speaking of memory imprint:

I noticed that FG reserves about 3 times more private memory than the size of the 62 PPI image, both the one provided by the FG adventure module and my own version. So a 20 mb uncompressed image makes FG reserve about 60 mb private memory. With my 100 PPI image it reserved about 2.5 times the image size, so 50 mb turned 125 mb. When the image is closed FG only releases part of the memory and then takes another few seconds to release the rest again.

[LordEntrails]

Could you explain why FG will run slowly when there is still enough memory free after loading "nice maps"? Loading the "Hallod's Hideout" map at 100 PPI and zooming/scrolling around in it does not even tax my CPU enough to make it leave lower power saving clock-rates. So besides the memory imprint what else could go wrong?

Because if it takes 1 or 2 minutes for you to share an image with your players, that's a bummer. "Here', let me share this image with you" (hold on, it's coming, I swear...).
Because you can't control what your players are doing. Some of them will open multiple images at a time and not close them.
Because some players might be on 32 bit windows. Or might be running as a different screen resolution or Windows Scaling than you.

So what an image looks like on your screen, and how it appears when you do an "Original size" really doesn't matter. Because it is going to be different for every player.
Players are going to (and they should) resize image windows, move them around, and change the zoom on the images.

I'm not surprised about your observations with private memory and images. Not sure why it does that, maybe because that image might have a mask layer and a pointer layer, so 3 times the size would be expected. But it does mean that you will run into process size limits sooner than you might otherwise expect.

Look, nobody is saying you can't use flashy images, we are just saying that in our years of experience it's not needed or worth it. IMO, it's not worth the time you are putting into it :)

[Weissrolf]

Ok, so mostly only memory and bandwidth limitations to consider. In my fixed group of players I would have control over that. Good to know.

Concerning "Original Size": This is how maps are loaded by default. Being scaled twice (program + Windows scaling) leads to huge windows that don't fit the screen. Even at 100% some map windows don't fit my 30" screen (2560 px) when being opened, so I personally I would prefer if maps and images were not automatically scaled at all.

In the context of this thread I used the function to calculate the ppi of paid FG content (Paizo adventure), which turned out to be 62 ppi for the map I checked. Since I prefer to buy such content anyway, this is what I will be playing with if I ever try to GM an online game.

There are some other issues with scaling, but I reserve that for another thread once Unity is out.

[Trenloe]

Concerning "Original Size": This is how maps are loaded by default. Being scaled twice (program + Windows scaling) leads to huge windows that don't fit the screen. Even at 100% some map windows don't fit my 30" screen (2560 px) when being opened, so I personally I would prefer if maps and images were not automatically scaled at all.
Original Size will display within the FG window on a one-to-one pixel base. Of course, if you're then using scaleui and windows application scaling, these will be applied as well - we don't want FG to be overriding application scaling.

There are various re-scaling options to set the image size the way you want it - giving all users the option to setup the image window relevant to their setup and scaling. See the video here: https://www.fantasygrounds.com/forums/showthread.php?34902-Very-cool-map-Kiskstarter-finishing-soon-great-VTT-maps&p=304700&viewfull=1#post304700 Once you've set the size and position of a window, that window will open at the same size and position where it was closed (with only a couple of exceptions for key system windows).

[LordEntrails]

When opened "original size" a 4500 x 4500 pixel image will be opened at one image pixel per screen pixel. Hence 100% zoom or full size. Hence it opens larger than the FG window. If you resize the image before you share it, or use resize > small you will be fine.

In general, you just have to understand how FG "thinks".

[Weissrolf]

I do understand how resizing works, but do not agree with FG's logic.

- "Original size" should not upscale the image when Windows and/or FG scaling is used, this is not original 1:1 size anymore.

- "Original size" should not increase the windows/maps/images border to exceed the desktop size. Using "Resize -> Small" can even lead to the window vanishing completely from the desktop if it has been moved too far upwards before. Just keep the border inside the FG window like when a map/image is opened for the very first time.

Is there any way to reset a window position and zoom to factory defaults (like opened for the first time)?

[Trenloe]

I do understand how resizing works, but do not agree with FG's logic.

- "Original size" should not upscale the image when Windows and/or FG scaling is used, this is not original 1:1 size anymore.

- "Original size" should not increase the windows/maps/images border to exceed the desktop size. Using "Resize -> Small" can even lead to the window vanishing completely from the desktop if it has been moved too far upwards before. Just keep the border inside the FG window like when a map/image is opened for the very first time.
Well, I disagree with your logic - 1) FG should not override operating system scaling. And 2) for a lot of people who use FG for face-to-face games, opening the window full size is a nice thing.

[LordEntrails]

Reset window position.... yes but I'm not sure I recall exactly... I think if you delete the windowstate.xml file from the campaign and then relaunch FG. Do that at your own peril!

As for resize small, I've never seen that cause a window to disappear. If reproducible it might be a bug for the house of healing.

In terms of window scaling, you can always add a suggestion to the wishlist, but since these types of things are personal preference and would change known behavior for all users, it is unlikely they would be adopted. But, not my call to make :)

[Weissrolf]

No (known to me) imaging (display or editing) software applies system scaling to image content, only ever to UI elements. Browsers and PDF viewers do apply system scaling to image content to keep things in line with text content and usually they offer some way to turn this off or workaround it.

Using "Original size" does not resize the window to full desktop size like FG does when you open an image/map for the first time. Instead it draws the borders well outside the desktop regions for larger maps (Hallod's hideout) even on high resolution desktops. Where is the exact use in that compared to scrolling inside a properly bordered window?

Trying to decrease the border size via CTRL-mousebutton-movement can lead to the content being upscaled slightly (by some pixels). Trying to use "Resize -> Small" can lead to the window vanishing off the screen when its upper left corner is already too far off the screen (because the oversized window had to be pushed upwards). It's a very strange handling on in-application windows and 1:1 zooming that I never consciously experienced before in any software. So it's at least mildly confusing.

There also is some problem with saved window placement when scaling is switched, but I recognize we already went far too off-topic and I reserve such bug reports for when Unity hits. Also please feel free to move all my off-topic posts elsewhere or delete them to clean up this thread.

Coming back to the original topic about image memory consumption: Why does FG seem to use 2.5 to 3 times the memory of what an image actually consists of (in 24 bit RGB data)?

[Trenloe]

No (known to me) imaging (display or editing) software applies system scaling to image content, only ever to UI elements.
Actually, there are plenty - just search for them via google.

But, anyway, as I've said multiple times - you *need* (I mean, *really* need) to stop bringing your super top quality, massive pixel resolution, in-depth print quality image preconceptions to a VTT designed to allow people to play table top RPGs over the Internet. If you're seriously expecting all the things you've been posting then you're going to continue to be disappointed. Sorry, but this is simply the realistic truth of what a RPG VTT is going to do. Yes, graphical "stuff" will be improved in FG Unity, but not to the level that you're expecting. Please manage your expectations!

[LordEntrails]

Scaleui and window placement is a known issue. I believe this is because window positions are defined in number of pixels from top left. FGU might be be taking a different approach though.

[Weissrolf]

I know IrfanView, Faststone, XnView, ACDSee, Lightroom, Photoshop, Paint.net, GIMP and lots of others. Of course none of these would ever apply UI scaling to the image content they are displaying/editing when an image is displayed at 1:1 (100%). This is UI usability stuff and thus has nothing to do with pixel-resolution expectations. I am experiencing these usability issues with content/maps created and sold by your shop. I am not bitter or disappointed or anything, just reporting the challenges I face.

Originally I hoped that I could just reuse the images I already created for printing, so that I don't have to do two versions for printing and VTT. I understand that this is not practical, especially due to bandwidth reasons (30-40 mbit upload bandwidth here).

Anyway, my question was about FG's memory usage for opening *any* image, and thus more on-topic to this thread. The 62 dpi image of "Hallod's hideout" from "The Fall of Plaguestone" PF2 adventure corresponds to 20 mb of pure image data, yet FG uses 60 mb of private memory to open the corresponding map window.

So I am curious why the overhead is so large? I also wonder why the overhead of my 100 dpi image was only 2.5 times instead of the same 3 times (should I check again)? Is this expected behavior?

[Weissrolf]

Reset window position.... yes but I'm not sure I recall exactly... I think if you delete the windowstate.xml file from the campaign and then relaunch FG. Do that at your own peril!
Thanks for the hint. This works, albeit it does reset *all* windows positions, not just single ones. So "peril" might be the correct description. ;)

[Trenloe]

I know IrfanView, Faststone, XnView, ACDSee, Lightroom, Photoshop, Paint.net, GIMP and lots of others. Of course none of these would ever apply UI scaling to the image content they are displaying/editing when an image is displayed at 1:1 (100%). This is UI usability stuff and thus has nothing to do with pixel-resolution expectations.
Again, you're "expecting" Fantasy Grounds to be a purely image viewing application - it is not. Any scaling of the UI (be it in FG or via the operating system) matches throughout all UI elements. A FG image (map or flavour image) is not just a static image - it contains a grid, links, tokens, mask, pointers, etc.. These are not graphics applications image tools with layers etc.. So please try not to thing of Fantasy Grounds as the same as any of the purely graphical applications you mention!


I am experiencing these usability issues with content/maps created and sold by your shop.
To be perfectly clear here - no one who's responded to you in this thread works for SmiteWorks - we are all unpaid community members who try to help out. It is not "our" shop. I just wanted to make that perfectly clear.


Anyway, my question was about FG's memory usage for opening *any* image, and thus more on-topic to this thread. The 62 dpi image of "Hallod's hideout" from "The Fall of Plaguestone" PF2 adventure corresponds to 20 mb of pure image data, yet FG uses 60 mb of private memory to open the corresponding map window.

So I am curious why the overhead is so large? I also wonder why the overhead of my 100 dpi image was only 2.5 times instead of the same 3 times (should I check again)? Is this expected behavior?
As has been mentioned a few time, dpi means little for an onscreen VTT image. The size is all about total pixel dimensions. And if you're really talking about pixels per grid square - those are just that, pixels per grid square, not dpi or ppi. This may seem a purely academic distinction, but it really isn't. Again, please shift you thoughts from purely graphical, print quality thought, and move it to a VTT application designed to allow people to play RPG systems.

A FG image will frequently have a FG grid superimposed, have FG links embedded in the image database record (which are then superimposed on the map), etc. then there are many things that will increase the memory that Fantasy Grounds uses to display one image compared to another. And, let's be realistic here, accurately estimating memory use in a dynamic application is virtually impossible without specific code in the application designed to do so - all you can do is a rough estimate. 2.5x vs. 3x is within 20%, which is close enough for the inaccurate measurement method used.

[Weissrolf]

...These are not graphics applications image tools with layers etc.. So please try not to thing of Fantasy Grounds as the same as any of the purely graphical applications you mention!
I am fine with that, but then consider not calling it "Original size", because it clearly is not original once it is scaled. This is where the confusion stems from. And again, this should not increase the borders of the map window outside the desktop area (aka off-screen).


To be perfectly clear here - no one who's responded to you in this thread works for SmiteWorks - we are all unpaid community members who try to help out. It is not "our" shop. I just wanted to make that perfectly clear.
Sorry for mixing this up. I thought you were an employed moderator.


As has been mentioned a few time, dpi means little for an onscreen VTT image. The size is all about total pixel dimensions. And if you're really talking about pixels per grid square - those are just that, pixels per grid square, not dpi or ppi.
Ok, this is where you are confusing things and unnecessarily complicating things with semantics. There are image standards, these include dpi/ppi for image being embedded in the image file for viewing applications (like FG) to properly scale images. Additionally the grid in FG usually represents one inch on a printed map (depending on the game), so pixels per grid practically equals pixels per inch. Of course size is about total pixel dimensions, but when we talk about memory and then mention a mere 62 ppi image pulled from FG released content then I expect both of us to recognize what this represents.

That being said, I specifically presented the math behind how image data size is calculated in the 149 mb example. You could have derived from this example that I do know what we both are talking about instead of (somewhat rudely) keeping to insist that I don't understand the topic at hand. We are talking about memory consumption of image files, here is the abstract math:

Width x Height x 8 bit per channel (24 bit for RGB without alpha) = total bits of an image / 8 = total bytes of an image / 1024 = kbytes / 1024 = mbytes. With uncompressed image formats like TIFF and PNG this mostly corresponds to the final file size, save for some minor overhead.

The original image of "Hallod's Hideout" from the PF2 adventure PDF is 2002 x 2597 px at 62 px per grid square (encoded as 62 dpi in the file format). FG's version bought as a module must be close to these dimensions, give or take some dozen pixels.


And, let's be realistic here, accurately estimating memory use in a dynamic application is virtually impossible without specific code in the application designed to do so - all you can do is a rough estimate. 2.5x vs. 3x is within 20%, which is close enough for the inaccurate measurement method used.
I retested this and it turns out that this time the small images only use about x2.5 (up to x2.68 for the external file) and the large one about x2 (up to x2.5 for a short time, but then some memory is released again).

Every time I load the 20 mb map I see FG's private memory increase by about 50 mb (give or take a little). Every time I close the map FG releases said private memory again, with the last few mb taking a few seconds. I can repeat this dozen of times and FG reproducibly keeps allocating over 2 times the private memory that the pure image data would take up. Notice how I did not write x2.5 here, because sometimes it happens that not all memory get freed up again when the map is closed, so with more memory usage to begin with the next opening of the map may only take around x2.3 times the image data.

This is quite a lot, especially when larger images still use up around at least 2 times their data, instead of just a fixed overhead for pins and overlays and whatnot. Someone suggested this to be due to several layers being put on top of each other.

My question is whether this is expected behavior? If so then it should be specifically listed in a "Memory Reference Guide".

[Trenloe]

There are image standards, these include dpi/ppi for image being embedded in the image file for viewing applications (like FG) to properly scale images.
No. No. No. dpi/ppi embedded in an image file have nothing at all to do with how a map in FG should be displayed on the screen. This is what we’ve been trying to tell you *multiple* times. Forget dpi/ppi when it comes to FG images, because they are for physically printing images where actual dots per inch on a sheet of paper mean something. Please stop thinking that dpi/ppi embedded in an image have any impact whatsoever on how FG should display an image! I know you have these preconceived ideas that FG is a graphical application and should adhere to graphical physical print quality standards, but FG is not that type of application, and it doesn’t need to be. Please, as has been asked many times, stop thinking of FG this way. If you’re expecting FG to adhere to these high quality image for printing standards then you’re going to continue to be disappointed. And FGU won’t do anything differently in this aspect than FGC already does - because it doesn’t need to!!!

[Weissrolf]

And to clarify. I don't think that FG does anything wrong with the memory allocation of images. Paint.net uses at least as much memory for opening the same test image and Photoshop uses a *lot* more. This is why I ask if this is "expected" and provide the information for others who want to know about memory usage with images/maps in FG.

[Trenloe]

My question is whether this is expected behavior?
Yes.

[Weissrolf]

No. No. No. dpi/ppi embedded in an image file have nothing at all to do with how a map in FG should be displayed on the screen. This is what we’ve been trying to tell you *multiple* times. Forget dpi/ppi when it comes to FG images, because they are for physically printing images where actual dots per inch on a sheet of paper mean something.
I know that you keep telling me that and I keep disagreeing. When you want your FG grid to match the grid of an original D&D/Pathfinder adventure as printed (or PDF) then the DPI of the image file matches *exactly* the grid size in FG. Pixels per grid are interchangeable with pixels per inch then, because Pathfinder adventures use a 1 inch grid.

The FG grid size of Pathfinder's "Hallod's hideout" is 62 pixels, this corresponds to a 62 dpi image file when FG's grid is meant to match the Pathfinder grid. Of course we know that those hard-coded map grids in printed adventures are grossly misaligned and thus hard to correctly measure, but overall you get the same "original" image size when you match ppi with ppg (pixel per grid).

Here is the original sized FG map (aligned grid) right beside a 62 dpi imported version (hard-coded misaligned grid, extracted and resampled from PDF):

30649


And FGU won’t do anything differently in this aspect than FGC already does - because it doesn’t need to!!!
I don't expect FGU to handle file embedded DPI information differently than FGC, it is correctly handled as it is. I hope it will generally handle scaling better (especially window borders and fonts).

It might or might not use more or less memory for opening the same image, that depends on internals. Its current overhead is known now, I will take another look once Unity is out, knowing that it becomes less important for a native 64 bit application anyway.

[Mortar]

Thanks for the hint. This works, albeit it does reset *all* windows positions, not just single ones. So "peril" might be the correct description. ;)

Don't delete the windowstate.xml.

Look through it and delete any <imagewindow> references you see, that will just clear those saved locations.

[Mortar]

A couple of other thoughts for you to think about.

I didn't see it mentioned, but once you load an image the player client handles it differently than the GM's. It can use up to 4 times the memory on a player client. I am not aware if that has changed.

Second your internet speed means nothing to the players downloading the files from you, if they have a lower grade internet than you that 150mb image you shared with your players will cause havoc in your game.

[Weissrolf]

Thanks for the hints, including the one for windowstate.xml. Of course I never meant to share a 150 mb uncompressed image over the web, but it still should not make FG crash when being loaded. Sharing a 20 mb JPEG version over a local network would be less of a problem, but it would still eat at least 150 mb memory once loaded, likely over 2 times as much after overhead.

My above example of "Hallod's Hideout" is embedded as 1.02 mb JPEG file in the module DAT file that I bought from SW. Judging from my external 62 dpi image of same "original" size this turns into about 20 mb of uncompressed image data once the JPEG is loaded. Then overhead is added for a total of around x50 times the memory being used compared to the JPEG file size (x2.5 compared to uncompressed image data).

I will take a look at how much memory the same map eats on a client. Again this ought to be less problematic with 64 bit Unity and even the current 3.5 gb limit would not be problematic as long as FG does not crash for no apparent reason.

[Trenloe]

I know that you keep telling me that and I keep disagreeing. When you want your FG grid to match the grid of an original D&D/Pathfinder adventure as printed (or PDF) then the DPI of the image file matches *exactly* the grid size in FG. Pixels per grid are interchangeable with pixels per inch then, because Pathfinder adventures use a 1 inch grid.

The FG grid size of Pathfinder's "Hallod's hideout" is 62 pixels, this corresponds to a 62 dpi image file when FG's grid is meant to match the Pathfinder grid. Of course we know that those hard-coded map grids in printed adventures are grossly misaligned and thus hard to correctly measure, but overall you get the same "original" image size when you match ppi with ppg (pixel per grid).

Here is the original sized FG map (aligned grid) right beside a 62 dpi imported version (hard-coded misaligned grid, extracted and resampled from PDF):

30649
And here's your 62 "dpi" image saved at 600 dpi from Adobe Photoshop:

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

And here's the two images, side by side in FG - one with 62dpi embedded in the image and one with 600dpi embedded:

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

They are displayed exactly the same. The pixels per grid square are exactly the same - because the grid has been drawn at 62 pixels per grid square. Nothing at all to do with embedded image DPI - Nothing. At. All.

I have worked with the original PSD files from Paizo for a lot of their maps and they have the embedded dpi at widely differing values - some at 600 some at 300 some at 72, but in the end it doesn't matter, because that is just an embedded marker that is used for printing - FG doesn't read it at all. What matters is how many pixels there are per grid square - because that is all that FG will look at, it doesn't do anything with the dpi embedded in the image file (see my second screenshot above) it makes no difference.

Ask anyone on these forums who does commercial conversions of modules - the map images received from the publisher will rarely have a dpi that matches the actual dots-per-grid-square - because it doesn't actually matter for displaying on a computer screen.

Here's an example of a PSD I received from Paizo last year for the Doomsday Dawn playtest. Each grid square is 50 pixels - see the ruler measuring tool - 500 pixels over 10 grid squares:

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

But, this image is set at 300 pixels per inch in it's embedded image data:

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

So, if as you say, the dpi/ppi of an image directly related to the dots-per-grid-square, why does the dots per grid square on this image (50) not match the dpi/ppi of 300? Because, as I've said many, many times in this thread - for displaying images on a computer screen, and in particular maps in Fantasy Grounds - dpi/ppi is not read, because it doesn't make any impact on how the image is displayed - it is all about physical pixels, and how many pixels per grid square are drawn on the actual image - FG does not automatically draw it's grid on an image, that needs to be manually drawn or manually set by the module developer.

[Mortar]

I am not sure if Unity will change this behaviour but typically the players reached the memory limit far before the GM ever gets close. I just opened up one of the development campaigns I am working on in FGU.

SavageWorlds ruleset with SWADE PG and SWADE GM guide, plus the Wiseguys Player's Companion and Don's Guide that I am working on, as well as the Wiseguys theme. Memory usage on my client started 791mb, but have rapidly climbed up to a high of about 1200mb and is currently at 1171mb.

[damned]

the relevant measure is pp5s (pixels per 5' square)!

[LordEntrails]

I want to make sure no one is getting cranky... I know their is some exasperation, but lets all make sure we maintain the good will and assumption of good intentions of everyone on this forum.

About the only thing I want to add (again) is that change in UI behavior is something that should be suggested on the wishlist. And, in most cases behavior is a preference, what someone is used to, and changing the behavior of an application that has been around for decades and has a very large user base is something not taken lightly.

[Weissrolf]

Edit: No getting cranky here, I do like deep technical discussions to learn from (including my errors) and share information. This thread still is about image memory usage and the compromises and different work approaches within those limits.


And here's your 62 "dpi" image saved at 600 dpi from Adobe Photoshop:
Indeed, except that in your 600 dpi image 600 pixels do not equal a one inch grid box in any software that cares to use dpi information. In Photoshop the squares will measure as 0.1 inch instead of 1 inch now. Since FG does not care for this, we can ignore that for pure FG VTT usage, though, especially when FG's own grid overlay is used. But when you try to import the original PDF map with hard-coded grid trying to match the size of the module image then dpi is your best way of measuring, because we users don't get to see the pixel dimensions of the module images.


They are displayed exactly the same. The pixels per grid square are exactly the same - because the grid has been drawn at 62 pixels per grid square. Nothing at all to do with embedded image DPI - Nothing. At. All.
When you want the imported image's dimensions and hardcoded grid to match the module's grid-size of 62 pixels then DPI based resampling is the way to get there. When images are only used within FG and you don't care to align dimensions between module maps and imported maps then yes. FG's module maps all seem to use different grid sizes for the same adventure anyway. But when for discussion of memory usage we need to create matching image files then grid boxes and dpi become the measure to use. This way we can find out what image sizes are used by prepaid modules.

Personally I need my maps both printed and (maybe) online, so it is more convenient to resize the map in order to match 1 inch per grid box (Photoshop selection tool helps with measuring) and then resample to a DPI according to the output medium (print and/or VTT). The "Hallod" map comes with 0.4 inch grid boxes when extracted from the PDF at 96 dpi, so it needs to be upsampled by 250% to print correctly. Instead of wrapping my head around different image dimensions for both usage cases I just stay with the 250% magnification factor (=output size in inch/cm) and then apply DPI resample factors accordingly. I have to do the calculation for printing anyway and then enter the output size in Topaz Gigapixel, also due to limits of the software when trying other input methods. From there I just change the dpi to either match my printer or the FG grid, a 62 pixel grid then becomes 62 dpi at original map print size dimensions in inch/cm.

All that being said I noticed that the image files embedded in FG modules are of much higher visual quality than what comes with the PDF. Even the extra paid for "interactive maps" PDF files are of bad image quality (in one case the map on the front-page was higher resolution than the one inside). The German PDF maps are of higher quality and resolution at least. So this would be a good reason to just use bought module maps, on top of them already being pinned with encounter information.

One reason against module maps would be that the module grid usually is different to the original grid from the adventure PDF. That may or may not work well, depending on the particular map/encounter. Originally I hoped that I could just import my own maps as a layer underneath the pinheads in FG, but that does not seem to be possible. It might not be necessary due to the higher quality of FG maps anyway, so less work is always welcome.


I have worked with the original PSD files from Paizo for a lot of their maps and they have the embedded dpi at widely differing values - some at 600 some at 300 some at 72...
I suspect that the 300 and 600 dpi ones were intended for HP or Canon printers at Paizo to see what they roughly look like on paper (maybe even with color proofing). But I do not claim to have any real knowledge about that.


...but in the end it doesn't matter, because that is just an embedded marker that is used for printing - FG doesn't read it at all. What matters is how many pixels there are per grid square - because that is all that FG will look at, it doesn't do anything with the dpi embedded in the image file (see my second screenshot above) it makes no difference.
You are correct as far as displaying the images in FG is concerned. Calculating image dimensions on dpi basis still is a better way of getting consistent image quality in FG. Telling me to keep dimensions below 2048 px is of little use when map sizes can vary so widely. How am I supposed to squeeze a 82 inch sized map into 2048 pixels while still providing a visually pleasing experience? What about a 10 inch sized one that is supposed to be of roughly equal visual quality? Calculating images for proper print sizes and then resampling dpi values for VTT usage is much more predictable. I always know what the image will roughly look like at 62 dpi (62 pixels per grid box) with dimensions depending on the specific map.


Ask anyone on these forums who does commercial conversions of modules - the map images received from the publisher will rarely have a dpi that matches the actual dots-per-grid-square - because it doesn't actually matter for displaying on a computer screen.
Again, you are correct for pure displaying on computer screens in software that does not care about dpi interpretations, even more so when the source image files are of high enough quality. But when your source files' quality is so bad that you need to do heavy lifting to get something workable then consistent or at least predictable output quality can better be achieved via dpi based processing (with the bonus of more convenient printing outside a VTT).


So, if as you say, the dpi/ppi of an image directly related to the dots-per-grid-square, why does the dots per grid square on this image (50) not match the dpi/ppi of 300? Because, as I've said many, many times in this thread - for displaying images on a computer screen, and in particular maps in Fantasy Grounds - dpi/ppi is not read, because it doesn't make any impact on how the image is displayed - it is all about physical pixels, and how many pixels per grid square are drawn on the actual image - FG does not automatically draw it's grid on an image, that needs to be manually drawn or manually set by the module developer.
And maybe because it was originally created using high resolution and proper measuring tools available for creation, possibly with 300 dpi printing as potential original target (or compromise). It was then downsampled to a measly 50 pixels per square before being handed over to you, not caring for embedded dpi information due to knowing FG to be the target. All pure speculation of course.

But yes, I agree, since FG does not interpret these dpi values for any of its own functions and uses a pure pixel based grid it really doesn't matter for this usage case. Personally I might not be happy with the visual quality/detail on this particular map and thus opt to resample it. One way then would be to just arbitrarily use different pixel dimensions, another way would be to properly resample for map size and destination dpi. With the latter approach again offering more consistent results and the added benefit that once I settle for a dpi/quality compromise I can always go back to the same values (dimensions then varying with each image). Or less convoluted: if 75 pp5s was my go-to goal then resampling everything to 75 dpi is the easiest way to go about it.

These are two different approaches. You can opt for constant memory size (pixel dimensions) or constant quality (dpi). Both achieve different goals via different compromises and both are valid for their different intents. Personally I like my computer's memory being put to full use, that's what I bought it for. Tests will have to show if this is still valid with clients being connected and maybe even running the FG server in a (Synology) virtual machine. Different goals, different means to reach them.

[LordEntrails]

You are correct as far as displaying the images in FG is concerned. ... How am I supposed to squeeze a 82 inch sized map into 2048 pixels while still providing a visually pleasing experience? ...
You won't. But you if you decide you want 150 pixels per 5ft square, then you are might find that a 12k square pixel image won't work in FGC :(


These are two different approaches. You can opt for constant (memory) size (pixel dimensions) or constant quality (dpi), ...
As long as the approach you chose doesn't crash the application.

As you are aware, you can greatly exceed the 2048x2048 pixel recommendation, but the recommendation is there for a reason, and part of that reason is that most users are not aware of what's going on int he background and if FG crashes they get upset, frustrated, and if we are lucky they come to the forums to ask how to solve the problem. If "we" are not lucky, they switch to a different VTT platform and badmouth FG without knowing the reasons behind their poor experience.

Personally, I exceed the 2048 pixel, 1MB, and 50 pixel per 5ft square ALL the time. But that's because I;
1) know what I'm doing
2) test process size impacts prior to game time
3) actively manage what content/images is shared with my players so they never experience crashes or other memory related issues
4) get my players to connect early when I have large images to share and I mark them for preload so they are already downloaded when I decide to share them

You can (and I encourage you to) do something similar, but "we" (the community) don't want to actually change the image recommendations for FGC because we don't want it to negatively impact the experience for users that don't want to be so actively engaged like you and I.

[Trenloe]

Telling me to keep dimensions below 2048 px is of little use when map sizes can vary so widely.
Actually, it's everything. Don't dismiss it as "of little use" - the recommendation is there not based on image quality, it's there based on FG memory use and efficient image processing. You can have one or two images a little bit bigger than this, but the *very firm* recommendation is to get maps below 2048x2048 pixels. This is the firm recommendation and shouldn't be ignored as "of little use".


How am I supposed to squeeze a 82 inch sized map into 2048 pixels while still providing a visually pleasing experience?
If by 82 inches you mean 82 grid squares across, then you're basically not supposed to use a map that size as a single image - split it up into smaller images. Make it 4 images with each grid square being 50 pixels.

In the end, you disagree with me. Therefore, you basically don't believe what I'm saying. All I can recommend is that you endeavor to keep each of your images within the FG Classic recommendations of 2048x2048 pixels (approx. 4.2 million pixels) and less than 1MB file size if possible. JPG files with compression that leaves the image good enough to view, but helps keep the file size down. These recommendations are based off years of experience using FG, supporting FG and come from the developers - not me. If you ignore them, then FG Classic probably won't run efficiently. If you have any issues in future, then please remember this thread and what we were trying to get across.

[notrealdan]

Dots/pixels per "inch" do not matter to FG, since inches are irrelevant to both the game mechanics and the VTT software. Game rules typically don't say "a medium size creature occupies 1 inch on your game board." They say something like "a medium size creature occupies one 5-foot square" (or similar depending on your game system), and this can be represented in different ways. Though they are typically 1 inch grids on a physical battlemap, that is a matter of physical world convenience and that has no relation to a VTT. Each player/DM will likely have a different size screen and be zoomed in to a different degree. So, for the VTT to know how to scale the grid, it only needs to know how many actual pixels long each side of that grid is, and that defines what a "5-foot square" is. It doesn't know or care how large in inches that will be displayed on anyone's screen.
1 square = X pixels = 5 in-game feet.

For the "82 inch sized map" typically for very large maps there will be a low-quality version for DMs with relatively few pixels per grid, plus smaller, higher-quality images that are individually shared with players (as Trenloe described). The DM versions will also often have pins, secrets, notes, etc. not meant for the players.

[Weissrolf]

Here is what irritates me. As a new user I am told to run my car at walking speed with the handbrake kept engaged so that I don't risk a crash!? The information we new users really needed instead was the speed limit and handling of the car. And what's with instilling so much fear of crashing in us new users? Is FG such an unstable program? Did I spend money on bad software?

Frankly it seems to me that FG and its new users are given a bit too little credit for their capabilities.


You won't. But you if you decide you want 150 pixels per 5ft square, then you are might find that a 12k square pixel image won't work in FGC :(
Except that it does work. I can load my 82" dungeon map at 150 pp5s, which corresponds to 9449 x 12402 px. On top of that I can concurrently load the same image at 100 pp5s, 75 pp5s, 50 pp5s, load all prebuild battle-maps and GM maps of the "Fall of Plaguestone" module and external versions of "Hallod's hideout" at 100 and 62 pp5s. Neither does FG crash, nor does it run out of memory.

Private (non swapable) memory usage on the server is around 2.2 gb at this point. A client loading all of the same maps from the server uses a bit less than 2 gb then.


As long as the approach you chose doesn't crash the application.
Again, what's with the crashes? I voluntarily made FG exceed its memory limit and it did not crash, but produce an error popup upon trying to load more images. When you are close to the memory limit it can also happen that you exceed the limit via actions other than loading more images, again I got a whole bunch of errors, but no outright crash.

There were some instances where FG misbehaved unexpectedly:

- When FG is left alone for 20-30 minutes (with no measurable CPU, SSD, network load happening) then most of the reserved private memory becomes shareable (as in can be swapped out to SSD). Memory usage dropped from 2.2 gb to less than 0.5 gb on the server and from 1.9 gb to less than 0.8 gb on the client. At this point you need to watch out to not cross the virtual memory size limit even when Task-Manager lists FG as only using much less memory.

- When the client computer went to standby after leaving it alone for too long FG had serious issues redrawing its UI, throwing dozens of graphic-driver related errors in its popup and eventually not being usable anymore (most of the UI staying black and the process mostly being unresponsive).

- When I tried to directly load TIFF files created by Topaz Gigapixel FG crashed right away. This is half a problem of FG and of Gigapixel, because the latter creates TIFF files that are not readable by all other applications, but still a lot of other applications can read them. The solution then is to rewrite the TIFF file with a more compatible program or just use JPEG for practical purposes (transfer to client) anyway.


As you are aware, you can greatly exceed the 2048x2048 pixel recommendation, but the recommendation is there for a reason, and part of that reason is that most users are not aware of what's going on int he background and if FG crashes they get upset, frustrated, and if we are lucky they come to the forums to ask how to solve the problem. If "we" are not lucky, they switch to a different VTT platform and badmouth FG without knowing the reasons behind their poor experience.

Well, FG should include the means to keep users happy instead of asking them to better walk than drive for safety reasons. There are some very odd memory allocation things happening, like FG allocating nearly double the memory of even Photoshop (as in 1.2 gb vs. 0.65 gb) when opening the same image. And that weird sudden switch of private memory to shareable for no apparent reasons.


Personally, I exceed the 2048 pixel, 1MB, and 50 pixel per 5ft square ALL the time. But that's because I;
Here is my "new user" perspective on these lowest common denominator kind of suggestions. I bought the adventure module "The Fall of Plaguestone" for FG. It includes 4 files larger than 1 mb, it includes several maps larger than 2048 px on at least one side and nearly all of its maps use more than 50 pp5s. I even counted, out of 9 battlemaps there is only 1 at 48, 1 at 62, 5 at 75 and 2 at 78. So 50 pp5s seems to be the exception rather than the norm.


1) know what I'm doing
FG should help with that. If it is loading too big an image or running low on memory then a clearly readable error message would go a long way of informing the users what they are doing wrong.


2) test process size impacts prior to game time
Graceful error handling that does not render the FG process mostly unusable should be the norm. Don't instill fear in your users, but confidence.


3) actively manage what content/images is shared with my players so they never experience crashes or other memory related issues
I recognize that this is more mandatory with users whose system you don't know. In a regular group it should be easy to find out if anyone is still on a 32-bit OS (most are not) or a generally slow system.


4) get my players to connect early when I have large images to share and I mark them for preload so they are already downloaded when I decide to share them
This is a bandwidth problem, not a memory problem. And what a problem it seems to be, so much so that I may have to file a bug-report. I get less than 3-4 mbit transfer speed over a local gbit connection that is otherwise perfectly fast. I only saw one single 15 mbit spike, and even that is excruciatingly slow.


You can (and I encourage you to) do something similar, but "we" (the community) don't want to actually change the image recommendations for FGC because we don't want it to negatively impact the experience for users that don't want to be so actively engaged like you and I.
As a new user myself the way of presentation (crash, crash, crash) and understatement of FG's capabilities leaves a negative impression about the software. I am very sure this is not your intention at all, but that's what I get from all of this. It should be made more clear that these recommendations are just a starting point for the uninitiated and nowhere near the capability limits of FG.

[Mortar]

Except you haven't said whether you shared those monstrous images with a player.

From experience...those images will crash a player's client long before the GM client crashes.



Yes, image handling has improved in FGC, but you will still run into the limitations of a 32 bit app. Images are still handled differently by a player's client.

[Weissrolf]

Except you haven't said whether you shared those monstrous images with a player.
Yes, I did, when I listed the memory consumption on the client/player side compared to the server side. The client used about 10% less memory compared to the server, loading all the same images as shared by the server (after an awkwardly slow transfer).


Private (non swapable) memory usage on the server is around 2.2 gb at this point. A client loading all of the same maps from the server uses a bit less than 2 gb then.
Later I also mentioned that the client switches to different private vs. shareable memory numbers compared to the server.


From experience...those images will crash a player's client long before the GM client crashes.
Not at all. And if it did then there would be a bug in the software, because software should not crash just because it is loaded with big images well inside its memory limitations.

Again I need to ask, what's with all the crashes? Is this software badly implemented? Should I have kept my money until it is fixed? This is the picture you are painting for me as a new user.


Yes, image handling has improved in FGC, but you will still run into the limitations of a 32 bit app. Images are still handled differently by a player's client.
My experiment was extreme compared to what people (including myself) load in a single session. It still worked and I provided the data. It also demonstrated that FG uses a lot more memory than the actually image data (about x2.3 - x2.7), this is unexpected to me and may be something that needs optimization.

[Mortar]

Go ahead, load up just one of those images plus the rulebooks a player needs. FGC is well over a decade old, with networking architecture that is showing its age. FGC won't see any more major optimizations which is why they have been working on the Unity client. FGC also doesn't have an intermediate server. The link is between the GM and players only.

Did you load anything else with those images in your tests?

FGU is far from optimized at this point and they are still working on bug fixes for it.


Here are some screenshots of my FGC client with and without a theme. At the start I am using over 500mb without images shared, and you can see what I have opened in my library.



Add the combat tracker with enemies on it, a map with tokens...

[Trenloe]

Like I said a few times - Fantasy Grounds is not just about loading images and showing them to players. At least not in 99% of the use cases of most people. Fantasy Grounds is a Virtual Table Top (VTT) that allow you to play RPGs with your friends online. Image sharing is a tiny part of that. There's PC sheets, there's NPC sheets, there's the combat tracker (actually a very key part of Fantasy Grounds), there's reference manuals, there's hundreds of spells, hundreds of feats (in PF2 which seems to be what you're looking at), and many-many more things that FG does and handles than just opening a bunch of images.

The information we've given you, as I've already mentioned, is based off years of experience running FG in real-world, multi-players, full-on RPG gaming campaigns that run over many sessions and end up with thousands of data records being shared, opened, accessed, etc..

We're trying to guide you, "as a new user", to get the best out of the current FG application that can easily be overloaded in a real-world gaming environment. Especially based off the massive image files you were quoting - so, yes (sorry), based off what you expected FG (a 32-bit application) to handle we did have to try to manage your expectations. And you seem to be taking exception to this. And, yes, we have given you "the speed limit", but you've chosen to ignore that.

Quite a few *very experienced* FG users have tried to give you real-world experience feedback on how to use FG reliably in this thread. And, I'm sorry, all you do is either ignore that hard gained experience or complain about us not giving you (a brand new user with, you admit, very little experience of this application) the benefit of the doubt - when all of your "testing" is not actually in a real-world, multi-session environment; and the images you keep referring to are too big for Fantasy Grounds. Too big! Please listen to the many people trying to help you, otherwise you will experience issues - not in your simulated testing, but soon in a real-world gaming situation - which is the last place you want to start having issues.

The bottom line is, try to at least take on board what we're saying. We're not being negative, we're being realistic. We have thousands of hours of FG gaming experience, and tens-of-thousands of FG forums posts - a lot of which involve helping users out with various issiues - incuding when their 2 year campaign has crashed and died because they overloaded the system, for example. Yes, this does happen.

Hey, if you think you know better, then go nuts and good luck to you. Otherwise, please take on board what we're saying. And, also, please stop complaining about people who are being realistic and trying to help you. Yes - we're trying to help you avoid the mistakes and pitfalls that a lot of us have experienced in the past.

Your choice.

[LordEntrails]

Perhaps instead of thinking of your analogy as we are suggesting you drive your car at a walking pace, instead we are pointing out the Speed Limit. Which in a car is a Recommendation, not a requirement. A speed limit is there not because in any given situation your car is going to explode, you are going to lose control or their is a collision that is going to happen. Rather a speed limit is a speed that is decided is safe for the vast majority of drivers in the vast majority of vehicles in the vast majority of traffic conditions will be able to operate safely.

Guess what? Even when people follow the speed limits, accidents still happen. Guess what? Lots and lots of people drive faster than the speed limit everyday and never get in accidents. Perhaps that is because they are more aware, or drive a better car, or traffic conditions are above average or they are just lucky. It does not mean that the speed limit does not have value. And when you get in an accident (FG stops revealing an image mask) and you were driving 105mph (sharing 15mb image files) what is the cop going to tell you? "Duh, what did you expect?"

If you don't like warnings, if you don't want recommendations, if you won't accept advice, don't ask for them. If you want to know exactly what the memory limits of FG are, then they are exactly the same as every other 32-bit application. And if you research that topic you will then know that is is highly dependent upon exactly what operating system version, build, and settings are for that piece of hardware.

You can choose to work with the software to get the best out of it you can, or you can fight it. That's the same thing I tell users after implementing a $40 million software project. It's the same thing I tell people looking at a $40 VTT.

[Weissrolf]

Go ahead, load up just one of those images plus the rulebooks a player needs.
I did not invest in rulebooks other than the adventure yet. Not being able to handle character sheet printing (for LR2) and seeing the software problems/limitations listed in this thread I am not sure if I should invest more money in it before Unity hits. That being said, I mostly bought it for the tactical console and character organization (including print when I didn't know better). This weekend I will decide about the core rulebook, I already own the PDF, but it's still not cheap.


FGC is well over a decade old, with networking architecture that is showing its age. FGC won't see any more major optimizations which is why they have been working on the Unity client. FGC also doesn't have an intermediate server. The link is between the GM and players only.
At less than 4 mbit the networking architecture shows some serious performance problems.


Did you load anything else with those images in your tests?
The adventure module, the PF2 playtest rules and Bestiary. I did another test with lots of other stuff opened alongside the large maps, including tokens and the combat tracker.

30692


FGU is far from optimized at this point and they are still working on bug fixes for it.
My hope is that Unity lends itself to some intrinsic optimizations, especially concerning memory management when images are handled. We will see.

[damned]

no one is trying to impose limits on you
if the large images are working for you and the performance is acceptable for you then go for it

i cant answer for the devs on the minutiae of your questions but my thoughts are the limitations, including those of graceful error handling or warning, are a combination of:
engine capability
development resources
development priorities

there are no hard and fast numbers on what can or cant be done because there are no hard coded limits
the limits are what your combination of gm specs, players specs, network connectivity and engine capability afford

fg is certainly not perfect but it does its strengths pretty well
fgu will have improvements in many errors, and continue to gain new improvements over time
but it will still have a swag of limits and some may be hard limits and others will likely be based on the environment and engine

please do realise that the people responding to this thread have also been spending their own valuable time and energy to try and answer your questions and provide some guidance

[Weissrolf]

Well then, I will give the experienced users the benefit of the doubt and give the software and my own limited tests the doubt.

This means that I will keep my own images at sane sizes and resolutions, orientated on the prebuild adventure module. This also means that I will not create higher detail images to replace those coming with prebuild adventure module, as it does not seem to be worth the effort then and the prebuild maps are already of considerably better quality than the PDF ones. Work spared.

I am happy to accept advice and always prefer to work with software instead of fighting it. This does not mean that I accept all designs and implementations, though, and you really are painting a rather bleak picture about the current state of the software. On Monday I will try the combat tracker (especially in comparison to Hero Lab's), that will be decisive for further investments.

[LordEntrails]

If you have other questions, let us know. We will be happy to help.

[Bidmaron]

Hey, weissrolf, if you are a PF2 fan you should love the ruleset. It is already quite awesome and powerful and the developer has even more spectacular plans for it that he keeps unfolding almost every week.
The program isn’t perfect, but it is nevertheless awesome! And I dare say you will in short time sing it’s praises. Nothing else comes close.
You will absolutely want to have the CRB and other available materials.

[Weissrolf]

I will keep that in mind. Thank you.