Map Scaling

I have been toying around with maps of ppi other than 70. The way this is implemented in roll20 is very strange. You have to set px under cell width, and then your grid sizes, the width and height are calculated at 70, so the cell count is off by PX/70 and the default scale of the map is 100%, meaning it's zoomed in to what is effectively 200%. On the map, all the graphics (conditions, nameplates, windows, doors, et al) are sized for 70px, so they are about half the size with 150 ppi. I didn't try 300, but I would imagine they are near unusable. Further, tokens copied from one map to another with different ppi have to be resized. It's such a hassle, I think I will go back to entirely using 70ppi. It's kind of a pain as Dungeon Alchemist doesn't have this scale, but it does have 72 which is close enough I'm hoping it will reduce the usability issues.  I'd love to hear if other people are using a px setting other than 70 and what they've done to work around the issues. 

Hi Wyrmwood! I'm not sure I follow your reasoning. 70 pixels per grid unit (ppu) is the display size. This is a screen measurement. Unless you are using a map that was produced at 70 physical pixels per unit, there will always be interpolation going on. If your map was produced at 140 ppu, then yes, when sized to meet the display size you will have 200% pixel density at 100% zoom. This is done all the time. This is actually desirable in many cases, as your map will display without loss of quality at up to a 200% zoom. Don't mess with pixel cell width unless you are dealing with extremely large maps and need to halve it. Resize the map image, not the grid. As for tokens coming in the wrong size, make sure you set your tokens up on a page that has a cell width of 1. Save the default token. When you drag it onto a page with a cell width of other than 1, it will automatically size appropriately.

Hi Wyrmwood,  I recently ran into another user trying to resize maps by resizing the pixels in the page settings rather than resizing the image. Is that what you are doing here? 

I use DA to draw maps, and I use them with a70 pixel grid. As others have noted, Roll20 really doesn't play well with other grid sizes. I agree that DA's 72dpi maps are a nuisance, but if you aren't using their import script (I don't), it's easy to resize the maps themselves to fit: after uploading and placing the map on the map layer, right-click the map, select Advanced / Set Dimensions, choose units instead of pixels, and set the dimensions to the number of squares on your original map (including any border).  I usually turn off the grid in DA also, but if you don't it will align with Roll20's grid if you size the map correctly (you can get some weird color effects on gridlines due to transparency though). You do wind up with a wasted square around the edge, since DA forces a minimum border of 1 square on exported maps. But the square gets used for overhanging objects if you export as a "limited perspective" map. I don't know how well that kind of resizing works with their lighting, as I don't use that aspect.

I thought I read you could do 140 at max for a sub and 70 as a free casual user. I just can't find where I read that. I used Dungeon Draft to make all my maps which goes up to 500-600%. I rarely make anything in that range but I have hit making my maps around 250% for detailed things I don't want people to see right away. Is there a way where I can get more than 250% out of Roll20 ? What is my max before it crashes or doesn't work ?  I normally run my maps at 140

The Keeper said: I thought I read you could do 140 at max for a sub and 70 as a free casual user. I just can't find where I read that. I used Dungeon Draft to make all my maps which goes up to 500-600%. I rarely make anything in that range but I have hit making my maps around 250% for detailed things I don't want people to see right away. Is there a way where I can get more than 250% out of Roll20 ? What is my max before it crashes or doesn't work ?&nbsp; I normally run my maps at 140 As far as I know, Roll20 doesn't limit this at all (directly, anyway).&nbsp; The only limit of map size is the file upload limit. What does limit you is that the VTT is rendered using WebGL.&nbsp; WebGL does have a hard limit.&nbsp; You can easily find out the limitations of your own system by going here: <a href="https://webglreport.com/?v=2" rel="nofollow">https://webglreport.com/?v=2</a> The main thing to look at is the "Textures" portion of the report.&nbsp; Specifically, the "Max Texture Size".&nbsp; Here is the report from my machine: That is claiming my max texture size is 16,384.&nbsp; That is the total pixel count in any dimension of an image rendered.&nbsp; To my knowledge (possibly flawed), the complexity of the image does not factor into this.&nbsp; My system (and most modern systems most likely) can render an image in WebGL that does not exceed that 16,384 in any direction.&nbsp; However, some older equipment, or possibly integrated graphics solutions will only be able to render half that, so 8,162. Let's say you have a default grid size layout (25x25) with an image that is only at the 70px per grid unit size.&nbsp; That is 1750 pixels per side (25ux75p).&nbsp; If you go by keithcurtis's suggestion, it is doubled bringing you up to 3500 pixels (25ux140p).&nbsp; That is still comfortably within the capabilities of even old less capable equipment.&nbsp; It is when you start doing large dungeons or cities where you can run into trouble.&nbsp; Take that grid up to a 50 by 50 and now an image that is 140p per grid unit is at 7k pixels and is approaching the limits of older or more limited hardware.&nbsp; Take that same 50 by 50 and push it to 175 pixels per grid unit (250%), you end up with 8750.&nbsp; More limited or older hardware simply can't render it. I have no idea how this factors in with other visual tasks the graphics part of the computer may be handling, and may vary wildly based on hardware.&nbsp; If you are close to max on the WebGL render, does that lag other visual things?&nbsp; No idea.&nbsp; How close to the pixel cap can you come and still be able to use dynamic lighting or explorer mode?&nbsp; No idea. It wouldn't surprise me if turning on all the bells and whistles of the vtt has an impact on the effective pixel cap.&nbsp; But it also wouldn't surprise me if the answer to how much is different from the rx5600xt that I used to use, the rx6800 that I have now, someone using a 4090, and someone using an older intel or amd cpu with integrated graphics. Edit:&nbsp; And this doesn't even get into the bandwidth of each individual in a game.&nbsp; I have had people that could or could not render map images based on whether their children were watching a streaming movie at the time.&nbsp; Not having enough bandwidth to download the image within whatever time the browser expects before giving up can be just as much of a factor as anything else.

" Let's say you have a default grid size layout (25x25) with an image that is only at the 70px per grid unit size.&nbsp; That is 1750 pixels per side (25ux75p).&nbsp; If you go by keithcurtis's suggestion, it is doubled bringing you up to 3500 pixels (25ux140p).&nbsp; That is still comfortably within the capabilities of even old less capable equipment.&nbsp; It is when you start doing large dungeons or cities where you can run into trouble.&nbsp; Take that grid up to a 50 by 50 and now an image that is 140p per grid unit is at 7k pixels and is approaching the limits of older or more limited hardware.&nbsp; Take that same 50 by 50 and push it to 175 pixels per grid unit (250%), you end up with 8750.&nbsp; More limited or older hardware simply can't render it." This is why you shouldn't use a single large image for a map.&nbsp; Best practice is a large lower quality image under multiple higher quality smaller images.&nbsp; Example: If you have a 50x50 (grid squares) higher quality image turn that into four 25x25 higher quality images and one 50x50 lower quality image.&nbsp; Next, put the 50x50 on the map layer, with the four 25x25 images on top.&nbsp;

Several more things to keep in mind: 70ppu is a very unusual resolution and virtually no maps captured from the wild will be able to be used without accommodation. The map will scale tokens dropped to meet a non 1:1 cell width, but the token interface remains fixed. At some choices this can make bars unreadable. Roll20 produces several internal resolutions of every image you drop into your art library. This is to improve efficiency of display (vaguely similar (but not really) to how Google maps works). Gauss' advice is very good (this is how extremely large maps are done internally for Roll20 products) but everyone will have a different rule of thumb as to when to switch over between one large map and several small ones. And to reiterate what was said above, in nearly all cases, scale the map, not the grid.

I totally missed your post above when I wrote mine, Kraynic. That's very insightful.

&gt;&nbsp; Resize the map image, not the grid. Well, sure, but essentially what this is saying is that roll20 only supports 70 px, which is not far from the argument I made initially. Yes, it supports other resolutions, but awkwardly and poorly. However, when you are coming from Dungeon Alchemist, and want to export the image, walls, doors and lighting, this is not an option, since it only supports 72, 150 and 300.&nbsp;If you have doors, windows, walls and lighting, you have to use one of those resolutions and edit the roll20 px or nothing will line up. I messed around with editing the coordinates in the UVTT file, and this is possible, if not a bit complicated. I may come back and revisit this, if exporting at 72 and adjusting the px is troublesome, but I imagine all the issues would be much less pronounced at 72/70 versus 150/70. DA also complicates things by giving you a "border", 4 cells for "normal" or 1 cell for "small", meaning a 21x11 map would be 23x13 if using "small". A typical screen viewport (1080p) supports about 22x12 without scrolling (27x12 if you hide the tools and chat). For custom maps, I try to keep them less than or equal to 44x24, to minimize both scrolling and map switching. But often times, I'm working from an existing map, so the dimensions can be all over the place. I've made some extremely large maps that have to be exported as lower quality jpg to fit under the 20mb limit. Other than that, they work just fine.&nbsp; I tested&nbsp; <a href="https://webglreport.com/?v=2" rel="nofollow">https://webglreport.com/?v=2</a> &nbsp;on two machines, a dedicated gaming pc and a laptop and both read&nbsp; Max Texture Size: 16384 . This only makes sense to me if&nbsp; WebGL doesn't utilize your GPU, yet right there in the opening description of webgl is&nbsp; &gt;&nbsp; executed on a computer's Graphics Processing Unit (GPU) I wonder if this is blocked by some flag. Well, according to chrome://gpu, &nbsp;webgl/2 h/w acceleration is enabled on both the laptop and the desktop. That px size must be a webgl limit, otherwise I'd expect to get different results from wildly different machines.&nbsp;

Wyrmwood,&nbsp; I don't think your problem is resolution, it is importing Dynamic Lighting.&nbsp; Roll20 works just fine with images of many resolutions. Where you have a problem is something that is outside the scope of Roll20, importing Dynamic Lighting from a program that sets it up in a way that doesn't work well with Roll20.&nbsp; I can upload a map image with a resolution of 150 (or whatever) just fine. People have been doing fine with that for nearly 11 years now.&nbsp;

Wyrmwood said: &gt;&nbsp; Resize the map image, not the grid. Well, sure, but essentially what this is saying is that roll20 only supports 70 px, which is not far from the argument I made initially. Yes, it supports other resolutions, but awkwardly and poorly. However, when you are coming from Dungeon Alchemist, and want to export the image, walls, doors and lighting, this is not an option, since it only supports 72, 150 and 300.&nbsp;If you have doors, windows, walls and lighting, you have to use one of those resolutions and edit the roll20 px or nothing will line up. I messed around with editing the coordinates in the UVTT file, and this is possible, if not a bit complicated. I may come back and revisit this, if exporting at 72 and adjusting the px is troublesome, but I imagine all the issues would be much less pronounced at 72/70 versus 150/70. DA also complicates things by giving you a "border", 4 cells for "normal" or 1 cell for "small", meaning a 21x11 map would be 23x13 if using "small". Unless you are always viewing at 100% zoom, the resolution is&nbsp; always &nbsp;interpolated.&nbsp; The map is always going to be scaled in some manner. This is just how images work.&nbsp; And unless your map is designed to end exactly on the edges of a grid measurement, you will also have to deal with placement on the VTT. &nbsp; "Roll20&nbsp; supports other resolutions, but awkwardly and poorly" is only true if you approach the process from certain expectations. I find it pretty straightforward: scale the map to fit the grid; it's going to be virtually resized constantly anyway. If there are issues with synergy with Dungeon Alchemist, that needs to be addressed programatically. I've never used Dungeon Alchemist.

Uploading an image independent of walls, doors, lighting and gridscale works just fine :-) All I'm really saying here is that adjusting the px is a poor way to get your non-70ppi images to work, but it's the only way for the correct placement of walls, doors and lighting (well, lighting doesn't work with DA but seems to work OK with dungeondraft). And I'm not the only one saying it :) I did find one really strange but very simple alternate solution. Export your universal vtt file from you favorite map maker at whatever resolution you desire. Use the sanitizer to copy the map data and save off the image as a jpg. Open the image in GIMP (or whatever you use for editing images), and scale to 70 ppi. Create a new page in roll20 and change the dimensions to match your new image. Copy the image over, align the image then edit the map, paste the data from the sanitizer into the image's GM Notes. Run !uvtt. Evidently, it performs the conversion for you (it knows the map is 70 ppi and the data includes the source resolution). Now everything matches roll20's default resolution and you don't have to redraw your walls, doors, etc. Any grid on the image will match the grid in roll20. Voila.

We'll have to agree to disagree on whether the resizing of the map is a poor solution. It makes far more sense to me than messing with page settings, which affects the rest of the interface. This also sounds like you are specifically addressing UVTT importer script behavior, not native Roll20 functionality. If you want better integration with Roll20's choice of 70ppu, then lobby Dungeondraft to make that a native export. As for why sizing of maps isn't automatic, it's because there is zero consistency with maps captured from the wild or produced from home sources. One map might by 70ppu, another 96ppu, another 57.8ppu. There is no way for a system to know the intended resolution. Furthermore, many, many maps are not cropped to the gridline, which would be essential for that 0,0 origin point to work. I would have suggested resizing to 70ppu in an image editor, but again, I don't use Dungeondraft, UVTT importer or anything like that. I wasn't sure if it might break something in the workflow of importing DL items. Maps and assets produced on the Marketplace now mostly have that information included as metadata, so that when you drag them from your purchases onto the VTT, they do snap to the grid automatically at the correct scale. And IIRC, a native image (unless it is very large) will import at native pixel resolution if dragged to the map layer. So saving an image at 70ppu and dragging it into the map layer from your desktop should result in a correctly sized map, if 1:1 at 100% zoom is your preference.

I don't think we disagree at all. Your first and last suggestion was to resize the image, not the grid px. I have stated multiple times, changing the grid px doesn't work very well. Yes, I export UVTTs from several tools, including dungeondraft. Dungeondraft already supports exporting at 70 ppi, so it works fine as is. There's no need to contact Dungeondraft. Their lighting seems to work just fine too. The issue is that roll20 is native 70 ppi (not just the grid, but the nameplates, conditions, markers, token size, UI elements) and only supports altering the grid - everything else is still at 70 ppi, so very tiny around 150 ppi and illegible at 300 ppi. It should just not support other resolutions if it's not going to perform the other resolution changes. I have contacted Dungeon Alchemist and they were the ones who suggested altering the cell width, but, as we agree, that's not a good solution. If someone is bringing in a non-70 ppi map, unless they don't mind the scale being wrong, they must adjust the cell width px value or resize the map to 70 ppi. This doesn't matter whether it's just an image or from a UVTT export that includes doors and walls. If you remember to select the map layer when importing, it does keep it at native resolution, but placing an imported map on the map layer should always occur at 0, 0, then if you want to move it you can. Instead, it ends up in a seemingly random location and must be aligned. Every time. This is backwards. However, using my previously posted solution, you can at least ignore the fact that some tools do not support export at 70 ppi.

I see better what you mean, and yeah, I think we agree more than disagree.&nbsp; I absolutely agree that the interface not scaling with the cell width is annoying. It's one of the few use cases I think is valid for using VTTES extension, since it provide that option (or did last time I looked). I typically only mess with the cell width when absolutely necessary. It's a pain in the neck when dealing with extremely large maps or maps with a baked in 10 foot grid that requires subdivision. I would be satisfied if the radial menu and token bars scaled. The 0,0 origin point works for maps that are an entire image, but would be a pain in the neck if constructing things with map tiles or placing "furnishings" on a bare map. Since an image will snap to 0,0, it's usually about a half-second's work to pop it in the corner. Having to travel to 0,0 for every item placed on the map layer would get tiresome.

OK, I'm a dork. I've used this feature before, but completely forgot about it :) The solution to size and alignment is far simpler than I'm making it. Just set your map size to something very small, like 2x2, then switch to the map layer and copy over the 70px image and it will ask if you want to adjust the page says. Say yes and the size is correct and the alignment perfect. Can't believe I forgot about this feature!

I hadn't even considered that that wouldn't happen automatically, but yeah, if the page is already larger than the map, it wouldn't trigger the feature. That's a good tip worth of a&nbsp; Tips n Tricks &nbsp;entry.