Unity map size

[arcanjl]

I know that the 'max' map size for classic is 2048, is it the same in Unity?

[Trenloe]

The maximum recommended map size in FG Classic is 2048x2048 pixels (just over 4 million pixels). This is the strong recommendation due to FG Classic only being a 32-bit application with limited memory available (even if the computer has lots of memory). Every pixel takes up FG memory when displayed. So the recommendation for FG Classic, with limited memory, is to keep the vast majority of maps to 2048x2048 or less. FG itself (Classic or Unity) doesn't stop you opening larger maps.

With FG Unity being a 64-bit application it has access to (in practical terms) all of the computer memory - so larger maps can be opened. Each pixel still requires processing, whether the application is 32-bit or 64-bit, more pixels mean more processing overhead- but at least the memory limits of FG Classic shouldn't be an issue.

Image file size should still be kept as low as possible to minimise file sharing times from the GM to the players.

[arcanjl]

Cool - ty!

[LordEntrails]

There have been reports of problems with 4MB+ image file sizes in FGU. Don't know if that is the case still or not. And it seems more like a network timeout issue than processing itself. Note, a 4MB image shared with 5 players is transferring 20MB from your computer. Which might not seem like a lot, but remember that your computer network is doing lots of other things and my experience indicates you will be lucky to get 10% of your network upload speed (which is usually 10% of your download speed).

[similarly]

Sorry to resurrect this old thread, but I had two questions on this topic:
1. Is FGU still having trouble with 4mb+ image files?
2. How are map TILES affected here? I'm using the Black Scrolls Sewer Map tiles, but I'm mapping a very large area, and I don't know how this map is going to be calculated as far as size, because it's made of just a few tiles. So if I have a large map, am I going to have a high file size because of area, or will it be lower because I'm using tiles? How does that work?

[Zacchaeus]

Unity can handle large map sizes.

The main consideration is the amount of time that it will take to upload a map shared with your players if it is very big. This will depend on a number of factors and it could take a while. So I'd still recommend a sensible map size. What that sensible size is, probably depends on your individual set up/number of players and a number of other factors. So there's nothing definitive as to what kind of limits are recommended.

If you are creating a map inside of Unity then it doesn't create an image in any normal sense. The image is created in the db.xml file in the campaign and consists of multiple lines of xml data. I am not sure what gets sent to the players if such a map is shared. I imagine that as well as the xml data the actual assets would also need to be sent to them but I am not sure about that. So it isn't going to be easy to determine the size of the map that you are sharing.

[similarly]

I had a HUGE castle (I remade Waterdeep Castle), and it came out 5000 x 5000 pixels. The ground floor was about 15 mb! The other floors less because they had more empty space. However, I realized I could tile it, and while I didn't do a perfect job (I can see lines here and there), it got the job done without reducing the graphics (because at 2500 x 2500, the graphics were SNES quality!). Got the map to under 3 mb with only a SLIGHT decrease in quality.

However, my big worry on the tile map was that I'm creating the stupidest thing ever: a complete map of the Waterdeep sewers! It's not exact according to a waterdeep sewer map I found online (because I'm using all right angles as much as possible, to preserve the tile LOS, because I'm lazy about THAT at least), but the map is enormous. Funny though: my computer hasn't hiccupped over it at all. Editing has been fast, slick and breezy. So I was kind of wondering about the size. Your explanation of assets and db.xml files leads me to think this tile system could be a real boost in the future.

[Weissrolf]

For fun, profit and network bandwidth tests I successfully loaded a 32000 px map with FGU. FGU uses quite a lot of memory per images, though, multiple times the real data of an image. While this may work on a GM's computer there might be players connected with less memory and processing powers.

That being said, one of my players uses a weak PC and internet connection, so even maps published in the sold adventure path are often too much for him in Unity (worked better in Classic).

Also keep in mind: *Every* image needs at least {pixel x pixel x 3 bytes} memory, in FGU more than that, regardless of what file size the JPEGs have. So a 3 mb low quality JPEG uses the same amount of memory as a 15 mb high quality one when pixel resolutions are the same.

[similarly]

That's interesting. I didn't know that. I might try the full-size image and see what happens. If the player are okay with it, I found something on reddit that will apparently allow me to pull LOS data from dungeondraft and include it in FGU.

[JimSocks]

I am getting a strange error from the console when trying to upload a large image in unity (and it uploads a blank image instead):
ERROR: Graphic Load: Unable to allocate pixels for the bitmap

[Moon Wizard]

Going to need some more information:

* Do you have a link to the map?
* How big is it in pixel dimensions?
* Do you get this right when you open the image record; or after you've looked in other windows such as Assets?
* What kind of video card do you have, and how much memory does it have?

Regards,
JPG

[Weissrolf]

I did a test using a 32k px image that previously could be loaded and displayed by FGU. Both 4.0.5 and 4.1 beta cannot even load its thumbnail in Assets and the image name keeps changing to names of folders belonging to one hierarchy up. The PNG version cannot be accessed via double-click and the JPG version returns the already mentioned error.

"ERROR: Graphic Load: Unable to allocate pixels for the bitmap"

When I find time I can do more tests at various pixel dimensions to find out at what maximum FGU fails to load images now. That is, if this information is wanted?!

[Weissrolf]

Well, there you go: 26k px images work, 27k+ do not.

[JimSocks]

I did a test using a 32k px image that previously could be loaded and displayed by FGU. Both 4.0.5 and 4.1 beta cannot even load its thumbnail in Assets and the image name keeps changing to names of folders belonging to one hierarchy up. The PNG version cannot be accessed via double-click and the JPG version returns the already mentioned error.

"ERROR: Graphic Load: Unable to allocate pixels for the bitmap"


This is EXACTLY what I get.


* Do you have a link to the map?
* How big is it in pixel dimensions?

Huge. 25857 x 25857 (about 200 inches square at 128 ppi). load times don't worry me at all for players- our setup doesnt have load time issues, and due to LOS I want it all on one map (it's a maze, so moving PCs between maps if I were to slice it up would mean they lose their LOS on the previous slice. For a maze, that's no bueno.)


* Do you get this right when you open the image record; or after you've looked in other windows such as Assets?

I get the exact scenario I quoted above from Weissrolf. Assets can't even show the thumbnail and it cycles through other folder names where the image should appear. On mouseover, the tooltip displays the correct filename, but when clicked the error pops up.



* What kind of video card do you have, and how much memory does it have?

I have a Geforce RTX 2080. The computer has 64gb of DDR4 3200 RAM, and a Intel i9 9900k chip overclocked to 5.1 Ghz

Hope this helps!

EDIT: I have also tried saving the file as a very low-quality jpeg- coming in as small as 30mb. No change in error.

[Weissrolf]

Huge. 25857 x 25857 (about 200 inches square at 128 ppi).

I can successfully load 19840 x 26040 px = about 500 megapixel, I cannot load 20800 x 27300 px = 552 mp. Since I could load larger images before, something between 4.0 and 4.0.5 must have changed.


EDIT: I have also tried saving the file as a very low-quality jpeg- coming in as small as 30mb. No change in error.
This only helps with file transfer time between GM server and player client. Once loaded any image is converted to uncompressed bitmap, no matter the file size. For your image that means about 2 gb RGB size in memory, or about 2.6 gb RGBA (alpha channel) size. This is CPU/main memory, not GPU memory (which I see 0.5 to 1 gb used on my 2070 when FGU is running).

Unfortunately FGU allocates about 3.5 times the uncompressed image size in memory, so a 2 gb image makes FGU allocate over 7 gb total memory. This is something that really should be improved on by SW. On the bonus side all normal image viewing, zooming and panning operations are smooth as can be, even better than some widely known image viewers.

[Sulimo]

It's not about FGU allocating more RAM for images. That is the nature of images. Image on disk has little bearing on how much RAM an image uses.

Overall Pixel (https://scantips.com/basics1d.html) count is more important for how much RAM an image uses.

[Pixel Amount in Width] x [Pixel Amount in Height] x [Bit Depth] x [Number of Channels] divided by 8,000,000 = RAM used.


So a 19840 x 26040 image with three color channels will take:

19840 x 26040 x 3 / 8,000,000 = ~193MB in RAM.

The file size on disk is likely to be much smaller than that.

This is for any Image in RAM, it does not matter what application is using the image.

[Weissrolf]

Seriously, did you even read my post where I explained exactly the same thing, but with correct numbers?

19840 x 26040 * 3 (bytes!) = 1549900800 bytes (not bits!) = about 1.5 gigabytes RAM.

FGU settles on 6.44 gb memory to load this image (peaks at nearly 7 gb), minus 0.33 gb to begin with = 6.11 gb private workset memory being used for loading a 1.5 gb image.

[Sulimo]

So, I forgot the Bit depth, mea culpa.

You could have understood that it was a very human mistake.

But no, you could not do that could you?

Learn some courtesy Weissrolf, you'll get a lot farther with your posts if you learn some humility instead of the arrogant attitude you constantly display.

You'll catch more flies with honey than you will will vinegar.

[Weissrolf]

Yes, it is very humiliating to write an explanation about technical details, just to have it directly (next post) replied with "it's not like that" just to get the same explanation (but worse).

That was very courteous and showed how my explanation was read and taken serious. It absolutely did not demonstrate how you only concentrated on the last paragraph and ignored everything preceding it. Thanks for the honey, very sweet and appreciative of my effort to analyze, report and explain these things. You are all soo very nice around here, a real treat. :o

Here are some numbers to think about. This is getting a bit off-topic, but the main issues is well explained and reported now anyway. Same 12k px image loaded into an empty campaign. 1. Unity, 2. Classic, 3. Irfanview.

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

[Sulimo]

Really!?

Jeez, I apologized (in case you do not know what mea culpa means), and you rant more.

You know, I have never blocked anyone in my time on the internet, but you may just earn the distinction of being the first. Congratulations I guess.

[LordEntrails]

So I believe the OP has not only been answered, but a working limit (500 Megapixels) has been identified. Thanks for testing and identifying that limit for now. I suspect in the future it may become a high enough priority for the devs to look further into.

MOD: closing thread

[Trenloe]

This forum has been without a workplace thread closing for... 0 days! How many days has it been? Three? Who had three days on the WR thread closure sweepstake?