Your thoughts on high res Maps & Tokens?

[Tailz Silver Paws]

Hello folks. I have a question for my fellow content designers. I've been approached by a few people asking for higher res, greater detail, images for maps and tokens. So that they can zoom in and see the detail. At first not many people asked for higher res image material, but slowly more and more people have been asking for it.

My response usually is: "Lower res is better as it means less information to share over the network and thus less lag, especially for lower end computers and people with lower end bandwidth connections to the internet."

But with the growth of computing power in most peoples computers, and the growth of network capacity, and the growth in animated maps, animated tokens, etc. I'm starting to wonder if that argument is starting to diminish.

So I'd thought I'd pose this issue for discussion with my fellow content creators. What are your thoughts about going higher res and higher detail?

Do we still have the trade off between processing power, and bandwidth? Or is too big still too big?

[Zacchaeus]

If you are talking about usage in Classic then there is no changes to recommended resolution and size since it’s still a 32 bit application and bigger computers and more bandwidth doesn’t overcome that limitation.

For Unity it can be bigger, but bandwidth and network speeds will still limit things to some extent as will performance on lower end machines.

[LordEntrails]

There will always be a trade-off, but I do think the predominance now if for more capable computers and a more common expectation of broadband. Now, remember, for FGC their still is the process size limit. but, FGU doesn't have that.

That said, I think peoples expectations are rising, and so I think higher resolution graphics are a reasonable expectation from creators. I would still recommend when possible to provide both recommended and high resolution versions.

[Three of Swords]

As a consumer, I want high-res, high-quality images. If I need lower-resolution, I'll reduce it myself. But I'm computer-savvy, so it's not an issue. Other DMs are not. So including both high and low-res images is probably preferable.

As for bandwidth, keep in mind that FGC (and FGU, I think) use the host as the server. And while download speeds may be good, upload speeds are reduced by some internet providers. Using my provider as an example, I just did a speedtest and got 115 Mbps download speeds (I don't pay for the highest tier), but I only get 11.5 Mbps upload speeds (roughly 10% the speed). So a 20 MB image file being sent to 6 players still takes a while.

[celestian]

The problem with how modules are distributed right now is you can't have a high res map/tokens for FGU and a "standard" res for FGC. IT's all or nothing and you're forced to use the lowest of the two.

Personally, I think there should be a way to have both types of images if they are available so that folks can make use of FGU's features. FGU gets the high res versions with LOS and FGC gets the low res w/o.

[damned]

I personally will only use the low res versions.
I see no issue with providing both from the customer side except that it probably costs you more to make and more to package up 2x the images so the product would likely cost more...

[Trenloe]

Two things about images in FG (both Classic and Unity):
1) Sharing speed is based on the size of the image file. There are steps that a artist/graphics designer can do to minimize the size of the base graphics file and still keep good levels of quality. For example, run all images through Pingo/Pinga after they've been sized and optimized appropriately: https://css-ig.net/pingo "Web (Lossless)" and "Extreme" compression level usually gives a 10-20% file size reduction.
2) Number of image pixels (directly related to resolution) effect the memory used by FG. So, as mentioned above, this is particularly of impact on FG Classic, and people running FGU with limited memory (there's plenty of people like that out there).

So, *always* keep image pixel size acceptable, and remember to run image files through a post process optimizer to minimize the file size.

[readymeal]

I personally will only use the low res versions.
I see no issue with providing both from the customer side except that it probably costs you more to make and more to package up 2x the images so the product would likely cost more...

I think Damned you are bias here due to the poor Internet connection we are getting in Oz. If i was not in the East Kimberley for work, i would be using my 5G...currently i am barely making it on 3G as the only 4G network is slammed during peak hours..

[damned]

I think Damned you are bias here due to the poor Internet connection we are getting in Oz. If i was not in the East Kimberley for work, i would be using my 5G...currently i am barely making it on 3G as the only 4G network is slammed during peak hours..

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.

[RunningHill]

I guess that maps and tokens can be used in other VTTs than FG. Providing in different resolutions would be nice. Dont some like photoshop offer batch processing so you can change all tokens?
At least the time to change resolution is less than it takes to make the map or token in the first place. Don't think it will change the price very much. At least I wouldn't charge for making a map in two different resolutions.

Then I make maps I do hate lower the resolution for the file size be reasonable. Things get blurry that was sharp. Would prefer keep them in high resolution. Since I have 500/500 bandwith I have no problem sending players 20 mb images.
Providing both options would be nice and even greater if it was an option in FG to switch between high or low image quality.

[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.

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

and this.

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

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.