-
December 4th, 2019, 18:00 #11
- Join Date
- May 2016
- Posts
- 166
-
December 4th, 2019, 18:03 #12
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.
Yes.Private Messages: My inbox is forever filling up with PMs. Please don't send me PMs unless they are actually private/personal messages. General FG questions should be asked in the forums - don't be afraid, the FG community don't bite and you're giving everyone the chance to respond and learn!
-
December 4th, 2019, 18:17 #13
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.
Problems? See; How to Report Issues, Bugs & Problems
On Licensing & Distributing Community Content
Community Contributions: Gemstones, 5E Quick Ref Decal, Adventure Module Creation, Dungeon Trinkets, Balance Disturbed, Dungeon Room Descriptions
Note, I am not a SmiteWorks employee or representative, I'm just a user like you.
-
December 4th, 2019, 19:04 #14
- Join Date
- Aug 2019
- Posts
- 2,025
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.
briarstone_asylum_main_floor_by_bigrin42-danuhq1-edit (2)_cr.jpg
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.
Originally Posted by Trenloe
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.
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.
Originally Posted by LordEntrails
and when opened into RAM uses up lots of memory, and hence crashes any 32 bit program.Last edited by Weissrolf; December 4th, 2019 at 19:19.
-
December 4th, 2019, 19:34 #15
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.
Problems? See; How to Report Issues, Bugs & Problems
On Licensing & Distributing Community Content
Community Contributions: Gemstones, 5E Quick Ref Decal, Adventure Module Creation, Dungeon Trinkets, Balance Disturbed, Dungeon Room Descriptions
Note, I am not a SmiteWorks employee or representative, I'm just a user like you.
-
December 4th, 2019, 20:24 #16
- Join Date
- Aug 2019
- Posts
- 2,025
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.
-
December 4th, 2019, 20:37 #17
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/forum...-To-Face-gamesPrivate Messages: My inbox is forever filling up with PMs. Please don't send me PMs unless they are actually private/personal messages. General FG questions should be asked in the forums - don't be afraid, the FG community don't bite and you're giving everyone the chance to respond and learn!
-
December 5th, 2019, 00:00 #18
- Join Date
- Aug 2019
- Posts
- 2,025
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...
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.
-
December 5th, 2019, 00:15 #19Could 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
Problems? See; How to Report Issues, Bugs & Problems
On Licensing & Distributing Community Content
Community Contributions: Gemstones, 5E Quick Ref Decal, Adventure Module Creation, Dungeon Trinkets, Balance Disturbed, Dungeon Room Descriptions
Note, I am not a SmiteWorks employee or representative, I'm just a user like you.
-
December 5th, 2019, 10:30 #20
- Join Date
- Aug 2019
- Posts
- 2,025
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.
Thread Information
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)
Bookmarks