Map sizing... Does anyone else do this?

1528928899
So I ran into this originally when I was creating maps for my own campaign and messing around with the tools. I see a lot of posts about the size of maps and limiting them to a certain area to help with performance. Something inside of like 70x70. (I can't recall exactly)  So when I began creating, this felt super limiting to my maps and overall designs. So instead of limiting myself in this way. I would create maps around 40x40 - 60x60 Then would go to the page settings and just half the grid size. (Set it to 0.5) So I would basically get double the space out of my 40x40 making it 80x80 or making a 60x60 into a 120x120. I've had no performance issues even with an entire dungeon in dynamic lighting and using effects, I've seen no loss in visuals(if anything they are slightly sharper for the sizing changes to the grid) Am I the only one out there who does this and not only that, but have made it a standard for all my maps? I'm mainly curious because I'm working on becoming a marketplace creator and I feel assets designed in this way I describe just are so much better and functional or am I crazy and this is just too much map to have to deal with for others?
1528932200
Nick S.
Marketplace Creator
Translator
Hi Steven, The general rule for marketplace assets is to create them at 140x140 pixels per "square", that way even while zooming in to 200% they'll look nice and sharp and users won't have to meddle with settings just to get a map going (the default grid size in roll20 is 70px per square). You can read more about the guidelines and possible performance impact due to sizing  in the wiki . Personally the only time I've had issues with performance in roll20 was when I tried to import the  entire Dead in Thay adventure map , with very accurate dynamic lighting (read: lots of small lines in the caves to fit every nook and cranny). However this can vary depending on each user's computer as well.
Steven R. is talking about adjusting the page grid size, not the pixel resolution of graphics on the page. I would be interested in this answer as well. I've been told that a 50 x 50 unit page set to .5 unit size takes up less memory than a 100 x 100 unit page size. If this is indeed true, I'd like to understand why. Either one sounds like 10,000 discrete spaces to track.
1528937251

Edited 1528937332
Nick S.
Marketplace Creator
Translator
Keith, My apologies in advance in case I misunderstood you question, but here's my attempt at explaining it. Suppose you have a 3500 x 3500 px image you upload to roll20. That would be a 50 x 50 page using default units at 70px per square. A default sized map at 100 x 100 units would need to be 7000 x 7000 px. If you were to half the grid unit size of the first 50 x 50 example, the page would have 100 x 100 squares, but those squares would be 35px each, and the image or blank background (the occupied area) would still be 3500 x 3500 px, as opposed to the default sized 100 x 100 map that would take up 7000 x 7000 px. In both cases they'd need to "track" 100 x 100 squares, but the total size of the tracking area is bigger using the default sized grid, which would account for the difference in performance, but also a huge difference in the quality of the image as well. That aside, I imagine most users never touch those settings and the advice on my previous post for marketplace content stands for that reason. They are guidelines however, and if Steven knows his content requires or plays better in a different way, perhaps he could implement that in his packs. I hope I was able to answer your question, and sincerely hope my math is correct as well. Cheers!
1528938653

Edited 1528938922
No worries Nick, your math is fine, and no offense taken. I've been a professional digital graphic and pre-press artist since 1988, and understand dpi, ppi, spi, and lpi*. I'm not concerned about graphic size at all. Throw out the map and work on a blank background. I'm talking about units on the page. I've been told that a 50 x 50 unit page set to .5 unit size takes up less memory than a 100 x 100 unit page size. As in the database tracking positions of items on the grid. This is what makes no sense to me. Steven R. is talking about changing the unit size of the grid. Nowhere does he mention pixel size or resolution. This could be a confusion in terminology, but I'm going on what is written. Steven R., could you clarify what you are asking? Are you looking to reduce the resolution of your graphics, in order to cover more squares? What is your intent in halving the grid unit size? There are two elements in play here, the overall pixel dimensions of your graphic (As Nick calculates above), and the number of discrete squares being tracked by the Roll20 engine. Both of these affect performance. But sacrificing one to improve the other leads to no net gain. (Unless the business I've been told is true concerning the database efficacy of halving the grid size, but again, this makes no sense to me.) In any case, halving the grid size to use a map of given pixel dimensions is just going to halve the resolution at any given magnification, as Nick says. ________________________________________________________________ * Actually, the only resolution that matters on a displayed Roll20 graphic is ppu , pixels per unit. :) Minimum 70, at 100% magnification. And as you say, the accepted practice is to oversample 200%, since battles are frequently zoomed in to subsections.
1528940745
The Aaron
Pro
API Scripter
I think the recommendation to stay below some particular size has more to do with the total memory size of graphics that would, on average, be used to fill the added space, combined with the increased complexity of whatever other details are added to the page (with the exception of Advanced Fog of War, which actually does scale with the size of the page because of it's implementation).  I think the scale at which those details and images are presented is immaterial to the actual performance. Put another way, it's easier to say " Try to keep your maps less than 80x80 " than it is to say " Try and make sure the total number of graphical elements isn't larger than 3000, the total memory used is smaller than 173megs, and the total number of vector points is fewer than 23,000. "  Particularly since you have no good way of measuring any of those things. In your example case of increasing the grid density, I bet you'd have identical performance (excepting Advanced Fog of War) by instead scaling the map up to twice it's size.
Good to know. I fight and die on the hill of digital graphics, but I tend to accept at face value something a programmer tells me about software performance. It didn't make sense to me then and I didn't debate it. I'm glad to have it debunked. Thanks.
1528954378

Edited 1528954751
I've also been a graphic artist for a very long time and understand compression, dpi, etc and how it does and doesn't affect screen display.  So my debate/question was why when creating larger maps is this almost not a standard, I can try and create a side by side to help everyone understand what I mean with the performance.  Most of what we create is created on a scale so large when Roll20 compresses it (outside of trying to blow something up 200% obviously) It loses basically no detail between being presented to a player a 1.0 grid size vs a .5 grid size.  I guess what I'm trying to get at mostly is why is the standard so large when the features perform best/better at a .5 in my personal experiences.  When I create in Photoshop for my Roll20 maps I work in either a 70x70 grid size (Defined in my Photoshop) or I work in a 35x35 grid size.  As I'm trying to become a creator I have now learned all the guidelines for creation as has been stated about the 140x140 sizing "standard", this just seems kind of out of control in terms of image sizing but I'm going to follow and create multiple versions and ask how different visually people see these maps.   With the performance thing, I don't think it tracks the grid size versus the unit size the same is what I'm saying, at least for performance via Windows 10 Pro on Google Chrome with GTX1070, 20G of DDR4 HS Ram and quad core i7 Ivy's.  I can 100% say that it IS NOT THE SAME for me.  When I kick the page size up to 120x120 for example and drop my map in there which fits at this size 100% pixel for pixel it performs worse than when I drop it on at 70x70 page size created pixel for pixel at .5 grid size.  I mean a 1920x1080 screen forces 88x88 pixel area into single displayed square at .5 grid ratio with "max" zoom. So putting all the logistics and discussing all the math and compression etc aside.  Maybe it's just my standards for play that i'm seeing as the issue here?  I've worked with a lot of Mike Schley maps before I started creating my own and his maps perform amazing at this same ratio.  Not gonna lie here, also not saying I won't do it to be a content creator to any level of requirement for the players, but there is a crazy standard being set. So people create maps at twice the size and then increase the grid size for it to be sharper?  So I should ignore my own personal design to adhere to this for players?  I'd rather not begin creating stuff that people are not going to want to use because of said standard.  Both of the Roll20 campaigns I've ran have loved the Mike Schley maps as well as mine and think they look really good, honestly that's why I'm trying to be a creator.  But to me it seems, if I'm correct about the "standard" what this ratio is honestly creating, nearly destroys the imaginative sense of D&D, am I alone in this?  Why would you need that much detail on a standard play map?  How often does anyone who creates content here even USE that level of detail effectively?  I take a room with desks, chairs, carpets, cabinets, beds, chests, sometimes pieces of paper and clothes strewn about for symbolization, a dagger stuck in wood and my group takes in what they can from that and I set the scene, is that not common practice for DM's in Roll20?  Just saying, at that level we could create that same pocket knife in the prior sentence add frayed edges on it, tiny minor blemishes, and a .5cm crack in the hilt and you could see with that level of pixel data for the grid if you zoomed in to even +30%.  Under this same logic do you show trip wires and wall traps visually in your maps?  I'm sorry, I just don't see Roll20 as a 2D version of a 3D image like that.  I see it as a layout, a map I drew for my friends with some colored pencils I had lying around and we're going to adventure that whole darn thing like in 1e.  Not here examining every detail of the map and go "nah let's move on, nothing here." - "Oh crap there's a trap!" Aren't the maps meant to be visual aids, not our actual visuals?  As I've been typing this out I've quickly realized, sorry if you read through it all, but that I am my own issue here.  I took a lot of my examples too far and I apologize for that, I'm just very passionate about these things in all the time I've been playing.  I do understand that we are in a new age and it's really cool to have the ability to add these details!  Because it truly is!  I do not mean to create that kind of argument. feel free for anymore input/discussion you have to the topic I would love to read it and see other peoples views.  I will just start testing the waters of what people like as I create. EDIT(Also thank you very much Aaron for that explanation of what is happening!  Some how I did not see that reply)
FWIW, in my own game, I frequently downsample or save with high compression/low quality jpegs, because "good enough" trumps slow performance for me. My take on it is that some people do prefer the quality of a map that at a 200% magnification is showing actual pixels. My take on it is that Roll20 is likely trying to accomplish several things by suggesting (but not enforcing) a standard. A) A uniform customer expectation in the Marketplace. People can be reasonably assured the images they buy will be free of compression artifacts and will look good at higher magnifications. B) A certain degree of "future-proofing". As displays increase in density and computers increase in processing power, higher resolution images will retain longevity. My suggestion would be to follow the guidelines, regardless of what your personal use case is if you are intending to produce for the Marketplace. As for your experience with changing the grid size to increase performance, now I'm intrigued. I've done it a few times in the past, but always dropped it, because I didn't like what it did to the tokens (the bars, controls and labels were all outsized compared to the graphic). But I've never noticed any performance difference. Admittedly, my computer is not a gaming rig and my specs are nothing like yours, but that should make the difference more noticeable, I would think.
1528993704
Yeah after much deliberation I do agree Keith and will make to the standard regardless.  As to the performance thing, rigs are so different it's really tough to narrow down that difference, but also the map size being used is relatively cut in half of what it normally would be to others.  Actually would basically be cut in a 1/4 of the amount of data.  This would probably be the biggest reason there is a performance difference.  But Roll20 being browser based has it's limits and I originally had not desired to push them with my 140 unit size maps.  I think I may just have gotten used to using the elements in the way I do and that's why it seems so natural to me.  In fact "blowing them up" as far as I see it, is probably going to be incredibley difficult for me to get used to haha.
1528997897

Edited 1528998042
I've been doing some thinking about this. It's possible that the performance hit comes with the way that graphics are rendered on the browser. If the graphics are tiled internally (and based on screen redraw problems, I suspect this to be so), then a 1 unit by 1 unit tile at half grid size only contains 1/4 the data per tile. The source file still at half resolution, so you're never going to see the level of detail you would for a 70x70 original tile, but the tile would be rendered and served over the internet at 35x35. (and then rendered by your browser at screen resolution, but that happens with all graphics and your computer is very fast at this). It's an illusory gain in image quality since you can't add data to bring it up to full res, but a real gain in performance, because you are dealing ins smaller tiles being transmitted from the Roll20 engine. I don't think that each grid square is a tile, of course, it's probably just a discrete and variable number of pixels. That would explain a big performance difference. I don't know if it's true, because I don't know what goes on behind the scenes to serve up graphics from Roll20, but it would be an explanation. In any case, the token interface goes to heck in a handbasket when you change the grid size to anything but 1 unit per grid, so it's probably best to just stick with the specs. I wonder if this has been contemplated and a proposal made in the suggestions forum to have the token interface size with the grid setting?
1528998688

Edited 1528999149
(My tokens automatically snap to the grid size, i'm confused what you mean there)  The token interface and rulers and such all work with each other, I have no issues with token sizing, rulers, lighting and such.  I presume the interface itself acts much like Photoshop, you can change the grid as much as you want and it just adjusts the snap setting and that is all.  But the actual page size becomes an issue when rendering and that's the ultimate difference I'm seeing.  I mean I have a world map that my players use in our campaign that is 29x30 page size and 1 unit is set to "31.57893" miles and the grid size is set to ".095"  (So somewhere around 305x410!) This has 0 performance issues at all.  I created it simply so my players could pull out their rulers and see  a single grid square is equal to 3 miles for travel estimations.  When I tried to do this with the page size first and create that same effect I almost got trapped on that map screen and unable to change it from it trying to draw the page so hard.  So there is something in the way it's designed that causes this effect. (I created this system because it falls in line with a random system I use for my players as well)
1528999077
The Aaron
Pro
API Scripter
The problem with a smaller grid is that the token bars don't scale their height, so you end up with stubby bars covering most of the token.  The Status Markers don't scale at all, so suddenly they are much larger than the token. 1.0 0.5 2.0
1528999516
I've never actually used bars for my groups, we are pretty old school about that, everything is done by "how does this creature look" etc and I guess we've never seen the indicators as that big of a deal, I feel like that wouldn't be a very hard thing to remedy either?  We just use simple portraits inside of colored token borders.  Maybe as an API scriptwriter you'd be the one to answer if that is at all possible.  I do not code almost at all, haha.
1528999689
The Aaron
Pro
API Scripter
It isn't something you can change from the API.  It's the nature of the way that Roll20 has implemented it.
1529000035

Edited 1529000102
Alright, I've just seen multiple scripts for custom markers.  So presumably I figured you could change the size.
Aaron, is it possible that the process I described above is explaining the performance difference Steven is seeing?
1529000657
The Aaron
Pro
API Scripter
I think it is possible, but unlikely.  I know that graphics do get chunked to speed up download and optimize display in fabric.js, but I don't think they are reduced in resolution when that happens.  There certainly is some adjustment of the size of graphics depending on where they are displayed and at what size, but it's unlikely to account for too much difference with a map as the sizes are just not the fine grained.
1529002121
I don't see how there isn't a difference here performance wise for others.  The page size is giving you more pixel space for art, as where the grid is just changing how you view the space you have.  It's caching all this data in the background.  If you created a 300+ x 300+ page size and tried to zoom out far enough to get the same effect as the map I use.  You can't even zoom out enough it's so large (About 21350x28700) and the ruler doesn't scale with zoom and is impossible to see at a certain point as well.  But either way it seems the compression of the image instead of a redraw from zoom creates the blur, like when using the .5 grid for battle and such as this topic was started on.  It seems the system has it's limitations regardless.  This grid concept works spectacular for my world map, however has issues with battle sized maps.  I've learned quite a bit form the discussion here though, which is the overall point and I thank you all very much for the insight.
I'm curious, then. The wiki is silent about this, but what is the intended use case for changing the grid size? Why not just make pages with more units?
1529004732
The Aaron
Pro
API Scripter
¯\_(ツ)_/¯
Thank goodness, it's not just me. I thought someone (maybe Silvyre) had explained it to me once upon a time, but Google is failing me. (I jut finally found out why the plus sign no longer works. Stupid Google, they should really send me a letter when they change something so fundamental)
1529051820

Edited 1529052542
Gold
Pro
keithcurtis said: In any case, the token interface goes to heck in a handbasket when you change the grid size to anything but 1 unit per grid, Workaround / Solution: Create a Page with 1 unit per grid size. Always create, configure, drop all tokens here.  (Maybe make a couple Pages, "Monster Tokens" and "PC Tokens"). Select the desired tokens and Copy (Control-C) the tokens, which you have created at your default size. Paste them onto the adventure Map page which has the Grid Size set to .5 which has other nice advantages like more discrete movement and positioning. Win! -------- postscript (P.S. I don't do the half-size page technique of Steven R the OP, I use .5 Grid more as a double x2-discreteness of movement positioning on same 100x100+ humongous size Pages that I'm known for making past the overheating warning limits.  A usual human size token now takes 4 small squares and has 4 centers of position to choose from, in the same graphics floor-space that would default allow 1 position. Tokens can now scoot closer together and hold hands, instead of always having an enforced linear gap of no touching. My usual Page Settings approach has proven to be usually too-taxing for Advanced Fog Of War but works nicely as long as AFoW is off. It works okay with AFoW but only on smaller page sizes (under 50x50 if not 25x25 with the .5 grid). I wouldn't enjoy token-based D&D on VTT as much without the refined discreteness of movement that .5 allows or even .2 or .1 sometimes. Don't care for the Checkers/Chess movement sensation in most non-board games. I feel like many game maps would be liberated by turning Grid Opacity to invisible, and Grid Size to .5, this really improves the showcasing of map art and movement within caves/tunnels or position relative to friends tokens).
1529067059
The Aaron
Pro
API Scripter
We actually play with the grid off. I just use the grid to set up maps. 
1529084307
Gold
Pro
The Aaron said: We actually play with the grid off. I just use the grid to set up maps.  Dig that. Even more discrete. Only thing I don't like is, it requires Mouse and (AFIK) does not enable keyboard movement of token (?).  A key combo to jump at least 10 pixels if not 70 pixels or somethin would assist me there.  There may be a key combo that bumps 1 pixel but it's too slow for movement across map pages.
Gold said: The Aaron said: We actually play with the grid off. I just use the grid to set up maps.  Dig that. Even more discrete. Only thing I don't like is, it requires Mouse and (AFIK) does not enable keyboard movement of token (?).  A key combo to jump at least 10 pixels if not 70 pixels or somethin would assist me there.  There may be a key combo that bumps 1 pixel but it's too slow for movement across map pages. This can be done on Mac/Chrome , and might be adaptable to other platforms. Simply save the token-mod movement commands to bookmarklets, and assign the menu items to hotkeys with the macro program of your choice. Won't work on Firefox.
1529086625
The Aaron
Pro
API Scripter
Oh, nice! One thing to be aware of is that moving with TokenMod like that won't respect Dynamic Lighting Walls blocking Movement. Which can be fine, depending on the character.  I had a Revenant Monster Hunter with a Ghost Psuedodragon Familiar that granted Ethereal movement.  Used TokenMod to walk through walls all the time. =D
That's cool. I just ran a scenario where the players were descending through a room of moving gears, like a giant clock. Every time they ended a move, if they failed a Dex check, they were moved 0-2 squares in a random direction. Just had to be careful never to run it if someone was only 1 square from the edge. :)
1529090158
The Aaron
Pro
API Scripter
I have a script that does something similar, which rebounding off the edges.
1529091499

Edited 1529091516
"Hello Aaron? Hey I'm at the airport and I have a flat tire. Could you— What? You say you have a script for that?" <looks at self-inflating tire which is also replacing tread and balancing itself> "Thanks!"
1529474937
Andrew C
Pro
Marketplace Creator
keithcurtis said: I'm curious, then. The wiki is silent about this, but what is the intended use case for changing the grid size? Why not just make pages with more units? Remember some stuff doesn't scale with zoom, such as the Ruler. So having a "large game distance" might work better on a "40x30 140dpi" map. As in, you build it to 40units by 30units at 140dpi per unit... and then ratchet down the grid size so that if you have to worry about an in game distance of 800ft you could set the page to 20ft units and 0.5 grid if you need 10ft resolution, or 0.25grid if you need 5ft resolution.
1529477153
Arthur B
Pro
API Scripter
keithcurtis said: "Hello Aaron? Hey I'm at the airport and I have a flat tire. Could you— What? You say you have a script for that?" <looks at self-inflating tire which is also replacing tread and balancing itself> "Thanks!" I just spit coffee on my screen now. Thanks.
Andrew C said: keithcurtis said: I'm curious, then. The wiki is silent about this, but what is the intended use case for changing the grid size? Why not just make pages with more units? Remember some stuff doesn't scale with zoom, such as the Ruler. So having a "large game distance" might work better on a "40x30 140dpi" map. As in, you build it to 40units by 30units at 140dpi per unit... and then ratchet down the grid size so that if you have to worry about an in game distance of 800ft you could set the page to 20ft units and 0.5 grid if you need 10ft resolution, or 0.25grid if you need 5ft resolution. How does this make a functional difference between that and building it at 160 units by 120 units (at 35 dpu*)? I.e. why does Steven R. report a marked performance difference between 40x30 at a grid size of one, vs a 40x30 unit grid functionally acting as a 160x120 unit map at .25? (Albeit with an unusable token interface.) ____________________________ *dpi doesn't mean anything in this context. Dots per unit s.b. the metric. We could just say that 1 unit = 1 inch, but that gets confused with the settings in a graphic editor (which also are not really per inch unless going to print). Safer to stay in the one parlance.
Again, for anyone trying to answer this, forget about graphic quality. Treat the base, original image size as a given. I'm asking about the performance difference from adjusting Grid Size. As a matter of fact, pretend there is no map graphic.
1529821867
Andrew C
Pro
Marketplace Creator
keithcurtis said: Andrew C said: keithcurtis said: I'm curious, then. The wiki is silent about this, but what is the intended use case for changing the grid size? Why not just make pages with more units? Remember some stuff doesn't scale with zoom, such as the Ruler. So having a "large game distance" might work better on a "40x30 140dpi" map. As in, you build it to 40units by 30units at 140dpi per unit... and then ratchet down the grid size so that if you have to worry about an in game distance of 800ft you could set the page to 20ft units and 0.5 grid if you need 10ft resolution, or 0.25grid if you need 5ft resolution. How does this make a functional difference between that and building it at 160 units by 120 units (at 35 dpu*)? I.e. why does Steven R. report a marked performance difference between 40x30 at a grid size of one, vs a 40x30 unit grid functionally acting as a 160x120 unit map at .25? (Albeit with an unusable token interface.) ____________________________ *dpi doesn't mean anything in this context. Dots per unit s.b. the metric. We could just say that 1 unit = 1 inch, but that gets confused with the settings in a graphic editor (which also are not really per inch unless going to print). Safer to stay in the one parlance. To the underlying machinery of roll20? Probably not heaps. But, the Ruler measurement doesn't scale with zoom. So if you want to be able to read the distances using Ruler, then you can't zoom out on the map very far. Hence a 40x30unit map divided into 0.5Grid sizes, is a bit more user-friendly than a 80x60unit map divided into 1.0Grid. A 20x15unit map divided into 0.25Grid starts shrinking the tokens to the point of impracticality as well. So I think you're looking at a 0.5Grid to 1.0Grid in general as the easiest interfacing options.