Your thoughts on high res Maps & Tokens?

[celestian]

Of course I am biased. We are all biased!

From my perspective you cant see all that high res detail - to see the detail means you can only see a tiny part of the map.
I think high res maps look amazing, but most of the time people just dont notice.

You can't tell me you cannot see a dramatic difference between these.



and this.



The first one is what is required to function within FGC.

[LordEntrails]

Of course you can see the difference in those two images at that zoom level.

What I always ask or think about when it comes to map and token resolution is how zoomed in are people going to typically zoom in to when playing? (Yes they might zoom in to see detail.) For most cases, something like 10 squares high is probably a pretty typical zoom level? Then if you look at typical screen resolution ... which varies all over the place, but lets say 1080 for height. That means for that setup, if it is typical (which is probably typical for a significant number of folks) means that a five foot square is about 100 pixels.

Now, you could look at a high resolution setting for a larger monitor of say 1800 pixels, then your 5 foot square is 180 pixels. I think that gives a reasonable upper resolution of say 200 pixels per 5 ft square. To me, anything above that is not actually for play, but for people to zoom in so they can see how cool something looks. It doesn't mean their is not value in those higher resolutions, but to me that can be considered a secondary consideration.

Thoughts?

[celestian]

Of course you can see the difference in those two images at that zoom level.

What I always ask or think about when it comes to map and token resolution is how zoomed in are people going to typically zoom in to when playing? (Yes they might zoom in to see detail.) For most cases, something like 10 squares high is probably a pretty typical zoom level? Then if you look at typical screen resolution ... which varies all over the place, but lets say 1080 for height. That means for that setup, if it is typical (which is probably typical for a significant number of folks) means that a five foot square is about 100 pixels.

Now, you could look at a high resolution setting for a larger monitor of say 1800 pixels, then your 5 foot square is 180 pixels. I think that gives a reasonable upper resolution of say 200 pixels per 5 ft square. To me, anything above that is not actually for play, but for people to zoom in so they can see how cool something looks. It doesn't mean their is not value in those higher resolutions, but to me that can be considered a secondary consideration.

Thoughts?

My players zoom in to the room about as close as the above images depict. I use similar zoom when I DM. It's really disappointing seeing all the pixelated room details... sometimes it's so blurry you can't tell it's anything.

At a minimum I'd like 100 pixel per unit (square) on 5 ft on a single level of a map. I'd LOVE 200. That does mean most higher res maps will no longer fit in FGC I expect.

[doredras]

I've always been confused about the image size recommendations wrt FGC's memory usage and I'd like to understand it better. For the sake of this post, lets assume network speeds are not a factor, everyone has modern PCs with lots of RAM, and the highest image quality is desirable.

FGC is 32-bit, so the application memory limit is 2GB iirc? That seems like a LOT. Sitting here now, my DM instance of FG with a bunch of modules, tokens, etc loaded is around 250MB. Yet, the max recommended file size for images is 2MB - that is really tiny!

Lets say I used a 50MB image file for a map. How does this impact the memory limit? The only explanation I can think of would be if FGC kept EVERYTHING on the player side in-memory, even when it wasn't opened, so eventually those 50MB images would add up. That doesn't make any sense from an architecture perspective though - I assume FG must cache assets to disk and load them when appropriate, managing its memory usage effectively?

Thanks for any insight, would love to understand better. The recommendations strike me as from a period when the average player was on dialup with 512MB of system memory, where tiny assets make much more sense. But it could be I am missing something important! It's just hard to see where the 32-bit 2GB limit becomes relevant.

Edit: Just connected to my own table, and memory usage went to ~800MB for the player instance and ~400MB for the DM instance. That is still a lot of headroom, but it makes me worried that FG may in fact be pulling everything shared with the player into memory all the time?

[Trenloe]

I've always been confused about the image size recommendations wrt FGC's memory usage and I'd like to understand it better. For the sake of this post, lets assume network speeds are not a factor, everyone has modern PCs with lots of RAM, and the highest image quality is desirable.

FGC is 32-bit, so the application memory limit is 2GB iirc? That seems like a LOT. Sitting here now, my DM instance of FG with a bunch of modules, tokens, etc loaded is around 250MB. Yet, the max recommended file size for images is 2MB - that is really tiny!

Lets say I used a 50MB image file for a map. How does this impact the memory limit? The only explanation I can think of would be if FGC kept EVERYTHING on the player side in-memory, even when it wasn't opened, so eventually those 50MB images would add up. That doesn't make any sense from an architecture perspective though - I assume FG must cache assets to disk and load them when appropriate, managing its memory usage effectively?

Thanks for any insight, would love to understand better. The recommendations strike me as from a period when the average player was on dialup with 512MB of system memory, where tiny assets make much more sense. But it could be I am missing something important! It's just hard to see where the 32-bit 2GB limit becomes relevant.

See the detail I give in post #7 above. File size affects image share time, number of pixels in the image impact FG memory use. Image files have some level of image compression in them so you cant just think that a 1MB file size takes up 1MB when opened. When FG (or any other application) displays that image on screen the data is not compressed and each pixel takes up the same amount of memory (depending on the colour depth being used on the computer). Then you add tokens to the map, drawing, masking and pointers and the memory use keeps going up and up. Have two or three big images open and, along with all of the library data, PC data, etc. all loaded into memory, you can soon start pushing a 32-bit applications memory limit - which is over 3GB when on a 64-bit operating system. We get a not insignificant number of users having issues that are caused by them running out of 32-bit application memory.

So, the recommendations still stand at this point in time - keep images to 2048x2048 pixels or less, and try to keep file size to less than 1MB. But file size is less important as that only impacts sharing to the players - if the GM has a fast upload (not everyone does), or patient players, then this might be less of an issue...

[doredras]

See the detail I give in post #7 above. File size affects image share time, number of pixels in the image impact FG memory use. Image files have some level of image compression in them so you cant just think that a 1MB file size takes up 1MB when opened. When FG (or any other application) displays that image on screen the data is not compressed and each pixel takes up the same amount of memory (depending on the colour depth being used on the computer). Then you add tokens to the map, drawing, masking and pointers and the memory use keeps going up and up. Have two or three big images open and, along with all of the library data, PC data, etc. all loaded into memory, you can soon start pushing a 32-bit applications memory limit - which is over 3GB when on a 64-bit operating system. We get a not insignificant number of users having issues that are caused by them running out of 32-bit application memory.

So, the recommendations still stand at this point in time - keep images to 2048x2048 pixels or less, and try to keep file size to less than 1MB. But file size is less important as that only impacts sharing to the players - if the GM has a fast upload (not everyone does), or patient players, then this might be less of an issue...

Ahh, you're right, I had forgotten to think through compressed vs uncompressed sizes.

Some quick research tells me uncompressed a .jpg (24-bit) is 3 bytes/pixel, which for a 2048x2048 image (4M pixels) comes out to ~12MB uncompressed. Even with some overhead that is still tiny. A resolution 4x as high (8192x8192), at 67M pixels, comes out to 192MB uncompressed. You definitely wouldn't want a dozen of those open at the same time, and that resolution is probably more than anyone needs, but that's still less that 200MB in-memory as compared to a 3GB limit, so I still feel like I'm missing something? How are people getting to 3GB? *IS* every image loaded into memory, open or not? Or are people just loading, like, 20000x20000 res images into FG?

I swear I'm not trying to be a jerk, I trust that the limit is suggested for a reason, I just can't seem to make the numbers add up to get there.

[LordEntrails]

The only explanation I can think of would be if FGC kept EVERYTHING on the player side in-memory, even when it wasn't opened, so eventually those 50MB images would add up.

Unfortunately, in FGC this is true. The GM client does not, but the player client opens every image and token shared with it into memory. Hence why players see this long before a host ever will.

Also, don't forget, most maps have a mask, which is the same size (not sure about color depth) as the image. So the process/RAM size of these images might just double as well.

[doredras]

Just to see what would happen, I loaded an 8.6MB jpeg (8192x8192) into FG while connected to my own table.

Memory usage before loading the image:
DM instance: 260MB
Player instance: 815MB

First, I opened the image on the DM side. Memory usage went from 260MB to 775MB, or an increase of around 500MB. That's quite a bit more than the 192MB uncompressed size anticipated for that many pixels at 3 bytes/pixel, so something else is going on I wasn't accounting for - some overhead related to FG image tools? Still, well well under the limit.

Then, I shared with the player. Memory usage on the player side went from 815MB to 1437MB, or an increase of over 600MB. It isn't totally clear why the image would be larger in-memory for the player, there must be some overhead even beyond what there is on the DM side.

When I closed the image on the player side, the memory usage dropped back to 815MB - thank goodness, FG is managing memory and (I assume) caching the image to disk when not open. That question is answered.

Adding a mask to the image increased the memory required by the DM instance by another several hundred MB, from 775MB to 1038MB. Strangely, it didn't impact the memory of the player instance at all until I revealed a section of the mask, at which point the player instance also shot up several hundred MB, from 1437 to 1706. Interestingly, when I *closed* the image on the player side player memory usage jumped up again to 2.2GB before dropping back to 815MB - I assume as part of the caching process?

I didn't think to add a grid etc but I'm sure that would also have added overhead.

So, my takeaway here is that there is quite a bit of additional memory usage in FG, separate from the display of the uncompressed image but dependent on its size. As such, something as big as 8192x8192 (which is pretty unnecessarily big) is probably only safe as a single, primary map being used - more than one of them would definitely exceed 3GB. Still though, 2048x2048 seems pretty conservative, there is a lot of headroom there.