Uploading of user created maps as a map

Hi there, I'm loving the program so far, but I have a minor suggestion: that entire maps created in other software which are files such as png or jpeg be uploaded as a map, full size. Then you could work on it from there. The reason I suggest this rather then just insert the map I made onto a blank map, is that it always has the tendency to be absolutely tiny on the editor and require re-sizing. Unfortunately, this usually ruins the image quality.

Thanks for your time.

I've noticed this, too, when I've dropped in my own map. What I was wondering – is the file actually physically reduced in size (is the app resizing a 2000 x 2000px map to 800 x 800, for example), or is the original image just being scaled down to a preset size to fit on to the page (just being scaled to 50% instead of resaved at a smaller image size).

This begs the question – how much space will a free Roll20 account have for storing these sorts of things? A 1000x1000 72dpi JPG is going to be significantly smaller than a 1000 x 1000 200dpi JPG. Also, if I prefer lossless PNG, I'm going to be using up more space.

200 dpi, why not?
But it doesn't say anything about how Roll20 treats graphics. Roll20 doesn't use a consistant scale. It uses "inches" which are squares and are probably 70 pixels across. You can use a very fudgy scaling about the "inches" (let's say a square is 1.23 inches) but not precisely decide on the pixels size.

The dots per inches in DPI have nothing to do with the inches on Roll20 (that are not inches anyway).

You'll only need 200dpi if you think you need to be able to zoom at around 300% during play (and then only if your inches on your document are a square across, which they should be if your map was one intended to be printed).

As I said elsewhere, it would be a good idea for Roll20 to drop that really akward way to display maps an tokens and have a scale of 1 pixel is 1 pixel. Then anyone can make his own calculations beforehand, knowing how his maps shall appear.

Did you select the map/background layer first? If you are in the token layer, it will scale your image differently than in the map layer (significantly smaller).

I just wanted to correct the perception (at least how I read it from the OP) that roll20 is actually editing the image to make it appear pixelated. If one's map looks undesirable at the zoom you want, you're going to have to look at your image size/resolution.

You are certainly right here. Roll20 doesn't seem to edit the maps. I just think it makes it quite difficult to work out beforehand your graphics by using units (inches) that have no reality on a digital medium.
Still Roll20 does edit the tokens to make them fit in one square. The only solution I have found (except eyeballing a resize) is to turn off the squares. Not really practical.

The problem is that I use tokens that are views from above; and, depending on the position, there can be some parts of the token extending from the square. As all tokens are snapped to a square, they don't look the same size anymore (you can see that effects on some of the screenshots used on this very site, those with Devin Night's tokens).
Enclosing them in a square shall let them keep their proportions, but not their scale. That's why I have to turn off the squares. I lose the snap to grid of the tokens, but all my maps have squares on them, so it is still workable.

I have not yet tried to use transparent padding. Can you reach through transparent pixels to another token that is under it or does it select the horse?

You know patrick, if you hold Alt it doesn't snap to the grid

You know patrick, if you hold Alt it doesn't snap to the grid

Yes, but then, you have to eyeball the resizing. It is quite frustrating to make maps and tokens which are at the same scale and then having to resize by sheer guessing graphic elements that were perfectly sized to begin with.
And then there is not much chance that the token shall snap centered on a square. Disabling the grid is probably easier, since I have a grid on my maps. The good news is that even with the grid disabled, the distance tool still works.
Handling of graphic elements is IMHO an area where Roll20 could be improved. The future marketplace would surely benefit from having elements that are scaled or sized in a predictable way instead of having to be fudged into the system.

What happens when the amount of space we have access to under a free account is maxed out? Do we have an option to manage the files? If we delete a campaign, with the assets from it delete from our account as well?

Another important thing to note about your art library is that you can't drag an object from your art library onto the tabletop. :(

Having—I don't know, reminded yourself that it is there?—you have to pull it up with a tailored art search in the standard art search facility before you can use it. I recommend thoughtful and thorough use of tags.

So if I'm reading what you wrote above correctly, if I have a map that is 2100x2100 and I want it at "full" resolution I should set it to be 30x30?

Because when I try that, it looks horrible and keeps looking horrible. The image I'm talking about is at this link (https://dl.dropbox.com/u/3463105/Ersetu%20Map%20-%20Terrain.png). The original image was 3000x3000 but that was too big to be allowed to be uploaded so I downsized it. On my computer it still looks good but when I upload it it's just a blurry mess (image attached). The full sized image looks much better (though not quite as good as I'd like because of reducing it to 2100).

Actually, just tried it at 90x90 and it looks much better that way so now I'm just confused.

I think you won't be able to get a good result as long as Roll20 shall forces resize on the maps.
Your best bet is to go for a size that is a multiple of a square size (70 pixels), 2100 in you case should equal 30 squares, make a Roll20 map the size of your map (30X30 squares), turn on snapping, place your map to cover the squares using snapping to fit the correct area, turn off snapping to avoid having your tokens shrunk inside the squares.
Not very intuitive and a lot of work just to have a map at native size.

Right, that's what I said I tried and when I did that it looked like crap. But when I took that same 2100x2100 image and stretched it to cover a 90x90 grid it looked fine. So it's as if it takes 3 squares to equal 70 pixels by 70 pixels instead of one.

So it's as if it takes 3 squares to equal 70 pixels by 70 pixels instead of one.

Which seems quite odd. But I don't really understand how Roll20 treats images. It makes preparing maps (and tokens) for Roll20 quite difficult.

Yes, it does. That's why I was hoping for some clarification from Riley.

I guess the problem I'm having is figuring out how big to make the page to fit a given image. So, if I have a 2100x2100 image what should I set the Page Size to in Page Settings? When I set it to 30x30 it used a down-resed version of the image, but when I set it to 90x90 it used the full res image.

Sorry for asking this, how are you uploading your map?

I am not seeing an upload button and I tried copying from photoshop and pasting it Roll20 and that did not work.

I don't understand what you mean by "forced resize". If you upload something at 2100x2100 pixels, and then make it 2100x2100 pixels in Roll20, it's the same thing as what you uploaded. Squares/the grid really have nothing to do with this.
....
So I guess I don't understand what the problem is that you're having.

I am afraid I have several problems with the way Roll20 manages the graphic elements, so, maybe my explanations can be a little jumbled (english being a second language doesn't help either). My problems are not exactly the same as Paul's, so feel free to move or delete this post if you think it is becoming too much OOT.

So, here are the problems I have encountered:

I make my own maps and tokens for gaming. I have used 128px/square elements and I am now working on a lot of "old school" 50px/square stuff.
http://toybox-sw.blogspot.be/search/label/Maps

Let's imagine I am trying to use the newer 50px/square maps (let's say a 20X20 squares map) and tokens in Roll20.
Now, if I upload a map on Roll20, I can either:
-adjust the squares to fit Roll20 squares, which means that a 1000 pixels map shall be stretched to 1400 pixels (that's the first forced resize)
-turn off the grid and try to eyeball its size to more or less 1000 pixels, because there is no way to force it to appear at native size
-make a multiple of 70px map (let's say 28X28 50 px squares, 1400X1400 pixels), stretch the map on 20X20 Roll20 squares and disable the grid. Now the map is displayed at 1 pixel is 1 pixel size (that's where Paul's problem lies, I think, because when a graphic element is not displayed at 1pixel/pixel, it tends to lose quality).

I would aslo like to point out that, when you say:

If you upload something at 2100x2100 pixels, and then make it 2100x2100 pixels in Roll20, it's the same thing as what you uploaded.

it is only partially true, because, it is true for 2100 (and any multiple of 70) but it is not true (and even impossible) for other sizes. You can not upload a 2000X2000 pixels map and make it exactly 2000X2000 pixels in Roll20 because there is no native size or pixel size control. Just a square and inches control (using inches as the unit only makes discussions more difficult because now you have the inches as "one square in Roll20" and inches as "dots per inch on your map").

The problem is the same with tokens, because Roll20 doesn't make a difference between size and scale.
-I make my tokens to be at the same scale as the maps, let's say 50px/square, but being the same scale does not mean that the token fit into a 50px square. If it has a weapon extending from its hand, it could be, for exemple 40X65 px. So, whilst being at the same scale as the map, the token shall be shrunk to fit into a square (that's the second forced resize).
-I can try to change the token size without snapping, but then I have to eyeball the resize of an element that needed no resizing.
And the last problem is with the grid, there is no way I can use it, with the problems mentionned above.

I can manage, and I have been able through some manipulations to use my stuff in Roll20 as it was intended.
But, it still means that I won't be able to share the stuff I make, because I can't expect other peoples to make the manipulations I have to go through to use Roll20.

I think that's where the problem lies: I have to fight the program to be able to have the program produce the result I want, which is basically "do nothing".

My maps and tokens are perfectly sized for being used together without any change.

If I was able to tell Roll20 to keep off, it would be good for me.

If I could set myself the scale of the squares (I know I can calculate a size in inches to trick the system, but frankly setting a number of pixels would be easier), it would be better.

And if I could set the center of rotation a token, it would be perfect (but that's not as important).

Sorry, if this post was quite long, but I wanted to be as clear as possible about what I think is the weakness of Roll20 in managing graphic ressources.

Sorry for asking this, how are you uploading your map?

I am not seeing an upload button and I tried copying from photoshop and pasting it Roll20 and that did not work.

It works with drag and drop.

If we all had a constant for Roll20's pixels per inch, this would be a good starting point for rescaling maps.

I've heard 70dpi, 72dpi, one map I de-rezzed and counted came to 69dpi. And every pixel drifts further out in the next square.

As far as I know, it is 70 px/square; whilst a square is called an inch, it has nothing to do with dpi. The dpi of your original map shall have no influence, as long as your squares are 70px long. If they are not, you are out of luck because there is no way to make a resize except through eyeballing.

My head hurts after reading this thread. However I'm also trying to figure out this Pixel to inch thing. What I'm doing is Copy Paste a pic from a PDF adventure into MS paint then I can use the Resize button(Pixels not Percentage) to make it as big/small as I want sometimes I get the grid to line up sometimes not. Mostly I'm just turning off the Roll20 grid. Is there magic Horizontal/Vertical Numbers for a each Roll20 Hori/Vert inch? Is there a easier way to do what I want? Also only the US Burma and Liberia still use the Imperial inch.... Just saying :)

For maps I have been using the Alt button to change map size without snapping to grid and changing the map settings to between .47 and .69 so that I can match up the grids on map and roll20. It takes a bit, but it works well. I have used this method for maps that have at least 50 x 50 square units and only loose a little bit at the ends.

Not sure if all the mathematics above are for something else, but with this I can play and see that the token when it moves onto a square on the map, that it matches the grid in roll20.

Yes, it works that way, but it is very approximative, takes time and tends to reduce quality. Whilst the maps could have been prepared beforehand, to work perfectly, if the system was less driven "by the pants". It would just need a "native size" setting.

And it is worst with the tokens than with the maps. Either you let them be squashed within a square or you resize them with an Alt button, but without anything to guide you (for the map, you still have some squares).

Whilst I like a lot of things in Roll20, graphic ressources management is something for which it is still inferior to other VTTs around (but, we are still in Beta, so, there is hope).

Yes, that would be really good. That would make it possible to have general maps in miles and tactical maps in feet or whatever.

Entering the dimensions of the token would work, I would just have to enter the dimensions of the token (or the map). Not always square, and maybe larger than one square, so, something like 45X83 should be possible. That would make it possible to work with graphic elements specifically prepared for the game.

Though, the possibility to just switch the tokens (or maps) dimensions to native size (with one pixel being equal to .... one pixel) would even be more useful, because then, there is no reason to enter anything and you would just have to load elements prepared for the game without any change.