Roll 20 Recent Uploads Wont Empty Out
This post has been closed. Yous can still view previous posts, but yous can't postal service whatever new replies.
Uploading of user created maps as a map
How-do-you-do there, I'yard loving the program so far, but I have a pocket-size suggestion: that unabridged maps created in other software which are files such every bit png or jpeg be uploaded every bit a map, total size. Then you could work on it from there. The reason I suggest this rather so merely insert the map I made onto a blank map, is that it e'er has the tendency to be admittedly 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 ten 2000px map to 800 x 800, for case), or is the original paradigm just beingness scaled down to a preset size to fit on to the page (just being scaled to fifty% instead of resaved at a smaller image size).
The quality of your image directly depends on its resolution. Roll20 doesn't do annihilation to the bodily information that makes up your graphics. If your motion picture'due south resolution is too low, its going to look pixelated when you zoom in or enlarge the image in Roll20. A lot of web graphics have very small resolutions to optimize display performance in your browser (standard is typically 72 dpi). For big images like maps, you're going to demand a higher resolution than an prototype used for a treasure chest or token. If you're not suffering from a tight image upkeep, endeavour targeting at least a 200 dpi for maps, or try to prototype search for the biggest version of said map you can find. (A very big image can slightly commencement a low resolution)
This begs the question – how much space will a free Roll20 business relationship take for storing these sorts of things? A 1000x1000 72dpi JPG is going to be significantly smaller than a thousand ten 1000 200dpi JPG. Also, if I prefer lossless PNG, I'yard going to be using up more space.
200 dpi, why not? But information technology doesn't say annihilation about how Roll20 treats graphics. Roll20 doesn't apply a consistant scale. It uses "inches" which are squares and are probably 70 pixels across. You tin utilise a very fudgy scaling about the "inches" (let'due south say a square is 1.23 inches) but not precisely decide on the pixels size. The dots per inches in DPI have zip to practice with the inches on Roll20 (that are not inches anyhow). Yous'll only need 200dpi if y'all call up you need to be able to zoom at around 300% during play (and so only if your inches on your certificate are a square across, which they should exist if your map was one intended to be printed). As I said elsewhere, it would be a good idea for Roll20 to drop that actually akward way to display maps an tokens and have a scale of 1 pixel is ane pixel. Then anyone can make his own calculations beforehand, knowing how his maps shall appear.
If if recollect correctly from a podcast interview, everything that we are currently playing with in the beta is what the costless version of a alive account volition be. Presently, a costless business relationship affords yous a 100mb art asset budget. Y'all can check how much of your upkeep is used up by checking your account page. Similar everything with betas, this budget might be subject to alter over the lifetime of the beta procedure. It'll take some judgement calls on the GM to figure out what the resolution sweet spot he can work with.
Did you select the map/groundwork layer commencement? If yous are in the token layer, information technology volition scale your image differently than in the map layer (significantly smaller).
200 dpi, why non?.....The dots per inches in DPI have null to do with the inches on Roll20... Ack! Sorry, I work in print so I made a lazy impress vs. digital error there. I'm trying to recall of all the means a GM is going to get/make their maps. If they're making or scanning in their own maps then in that location will be a good idea of how far zoomed in they're going to exist in roll20. A small underground dungeon map won't need equally much zooming and panning effectually as one of those massive multi-session labyrinth complexes for instance. The latter is going to look badly pixelated if its using the same resolution scale/prototype size every bit the former. There'south also the trouble that some pre-made maps bachelor online are designed for a GM to print out and utilize, not as the battle map itself, simply equally a low res guide for the GM to describe out on the battle map. I just wanted to correct the perception (at least how I read information technology from the OP) that roll20 is actually editing the image to make it announced pixelated. If one'southward map looks undesirable at the zoom you want, you're going to take to look at your image size/resolution.
I just wanted to correct the perception (at least how I read information technology from the OP) that roll20 is actually editing the image to make information technology 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. Yous 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 foursquare. The just solution I have found (except eyeballing a resize) is to plough off the squares. Not really practical.
Are you referring to the snap squashing that goes on? The best set up I can think of right now is enclosing your token in a foursquare padding. Information technology certainly goes confronting the desire for file size optimization, and doesn't fix the issue of tokens pulled from the art resource library, but it at least prevents your tokens from getting contorted.
The problem is that I use tokens that are views from higher up; and, depending on the position, there can be some parts of the token extending from the square. Equally all tokens are snapped to a square, they don't look the same size anymore (you lot can see that effects on some of the screenshots used on this very site, those with Devin Dark's tokens). Enclosing them in a foursquare shall let them keep their proportions, but not their calibration. That'due south why I have to turn off the squares. I lose the snap to filigree of the tokens, but all my maps take squares on them, so it is yet workable.
This also gets really wonky when you lot're dealing with token creatures that have a 2sq 10 1sq dimensions. You can't rotate them, because they'll snap revert back to a 1sq x1sq in size. If y'all rotate it and so scale it to the correct size, they and so no longer snap to a square but snap centered to a gridline instead. I was experimenting with a horse graphic from the art resource library when I noticed this. I had to create a new horse token graphic that has padding on one side of the horse. The graphic technically took up a 4sq ten 4sq space, but at least it could be rotated.
I have not withal tried to use transparent padding. Can you lot reach through transparent pixels to another token that is under it or does information technology select the equus caballus?
The invisible part is still considered part of the token. Information technology would depend on what'due south on top of what. Say we accept a pc token that was positioned next with its horse token. The pc is situated inside the equus caballus's "padding infinite." If the horse token is layered in front of the pc token, you'll select the equus caballus even if y'all were trying to click on the pc instead. The padding trick isn't a perfect work around, but it makes moving and rotating funky shaped tokens on a grid board a little less frustrating.
You lot know patrick, if you concur Alt it doesn't snap to the grid
You know patrick, if you hold Alt it doesn't snap to the grid Yeah, just 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 and then in that location is not much gamble 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 futurity 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.
But to pop in and respond the earlier office of the thread: Roll20 doesn't do anything to the lower the resolution of the original file. It *does* create several different versions/files of every paradigm you upload. Let'southward take a hypothetical 2048x2048 pixel map. When yous upload information technology, Roll20 volition create several versions of the map: 200x200, 512x512, 2048x2048, and the original size (in this instance the same 2048x2048). And then depending on how large you lot go far on the tabletop, it volition employ the smallest version information technology can that is high enough resolution. So for example if you upload a loftier-resolution token but only use it at 70x70 pixels (the size of a i-inch square at 100% zoom), it will utilise the 200x200 version. Notation that it doesn't alter the pinch quality, change from PNG to JPG, etc. It simply creates those sizes then that information technology gives you a fast feel past giving you a smaller paradigm to download when you lot are using the image at small sizes. It also increases functioning of the rendering in your browser so the overall app is faster. If, though, you resize that map to 2048x2048 or higher, it will merely use the same original image that you uploaded. If you upload a loftier resolution image and it starts off small, then you resize it to make it very large, and it looks really pixelated, you may need to wait a few seconds, equally your figurer is probably downloading the college-resolution version, and Roll20 will bandy that in once it's finished downloading (so that you lot don't see the image disappear in the mean time). Let me know if this does not accurately describe the beliefs that you lot're seeing. Oh, one other quick note: your "quota" but takes into account the size of the original file. So even though in that example we are creating several other files which have up space, nosotros basically give yous those for free (they do not count toward your quota), since we consider it part of enhancing your user experience, and that shouldn't count against you lot :-)
What happens when the amount of infinite we have access to nether a free account is maxed out? Practice we have an option to manage the files? If we delete a entrada, with the assets from information technology delete from our business relationship also?
While I can't answer your first question, I tin can aid with the 2nd 1. Fine art avails you upload aren't saved equally part of a specific campaign. They all get added to your art library. When yous click on the star icon in the Art Library Tab this will open up a new window (called My Art Library) that includes all the fine art assets you've favorited from Roll20's existing resource library AND all the artwork you've uploaded for all your campaigns. Of import things to note about your library of imported assets: 1. If you deleted a slice of undesired custom artwork from your campaign, the artwork will still sit in your library. To remove information technology completely, you need to delete its entry from your art library. 2. If you upload the same file multiple times, multiple entries will exist created in your library. Fine art assets are not overwritten even if they share the same file proper name. It'due south best to make sure y'all don't have multiple copies of the aforementioned piece of art in your library.
Another important affair to notation almost your art library is that you tin can't drag an object from your art library onto the tabletop. :( Having—I don't know, reminded yourself that it is there?—you lot have to pull it up with a tailored art search in the standard art search facility before y'all can use it. I recommend thoughtful and thorough apply of tags.
Right now nosotros aren't actually strictly enforcing quotas. When nosotros practice start doing that, basically you just won't be able to upload anything until you lot are nether your quota (if you go over). To get over, you just delete anything you uploaded from your Fine art Library every bit Kristin said. Annotation that things you include from the Built In library (due east.g. Devin'south Tokens) and the Google Prototype search don't count toward your quota. Only things you lot upload from your computer yourself.
So if I'chiliad reading what yous wrote to a higher place correctly, if I accept a map that is 2100x2100 and I desire information technology at "full" resolution I should set it to be 30x30?
Considering when I try that, it looks horrible and keeps looking horrible. The prototype I'm talking about is at this link (<a href="https://dl.dropbox.com/u/3463105/Ersetu%20Map%twenty-%20Terrain.png" rel="nofollow">https://dl.dropbox.com/u/3463105/Ersetu%20Map%twenty-%20Terrain.png</a>). The original image was 3000x3000 just that was besides big to be allowed to be uploaded so I downsized it. On my computer it yet looks good but when I upload it it's just a blurry mess (prototype attached). The full sized image looks much better (though not quite as skillful equally I'd like because of reducing it to 2100). Actually, but tried it at 90x90 and information technology looks much ameliorate that way so now I'm merely confused.
I think yous won't be able to go a good outcome 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 instance should equal xxx squares, make a Roll20 map the size of your map (30X30 squares), turn on snapping, identify 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 simply to have a map at native size.
Right, that'south what I said I tried and when I did that information technology looked like crap. But when I took that same 2100x2100 image and stretched it to cover a 90x90 grid it looked fine. Then it'south as if it takes 3 squares to equal 70 pixels by 70 pixels instead of ane.
So it's equally if it takes three squares to equal lxx pixels by 70 pixels instead of one. Which seems quite odd. But I don't actually understand how Roll20 treats images. It makes preparing maps (and tokens) for Roll20 quite difficult.
Yes, information technology does. That's why I was hoping for some clarification from Riley.
I don't understand what you lot mean by "forced resize". If you upload something at 2100x2100 pixels, and then make it 2100x2100 pixels in Roll20, it's the same matter equally what you uploaded. Squares/the grid really accept nothing to practise with this. If you desire to see how many pixels the prototype is after you uploaded it, just utilise something like Chrome'due south Developer Tools to inspect the DOM and y'all'll run across that the image is the same resolution. Then I guess I don't empathize what the trouble is that you're having.
I guess the problem I'1000 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 fix the Page Size to in Page Settings? When I set it to 30x30 it used a downwards-resed version of the epitome, simply when I ready information technology to 90x90 it used the full res epitome.
Lamentable for asking this, how are you uploading your map? I am not seeing an upload push 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, information technology'south the aforementioned thing equally what you uploaded. Squares/the grid really take nothing to practise with this. .... So I approximate I don't understand what the trouble is that you're having. I am afraid I have several problems with the way Roll20 manages the graphic elements, so, perhaps my explanations can be a picayune jumbled (english being a 2nd language doesn't help either). My bug are non exactly the same equally Paul's, and so feel gratuitous to move or delete this post if y'all think it is becoming likewise much OOT. So, here are the problems I have encountered: I brand my own maps and tokens for gaming. I have used 128px/square elements and I am at present working on a lot of "old school" 50px/square stuff. <a href="http://toybox-sw.blogspot.be/search/label/Maps" rel="nofollow">http://toybox-sw.blogspot.be/search/characterization/Maps</a> Let's imagine I am trying to use the newer 50px/foursquare 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 ways that a 1000 pixels map shall be stretched to 1400 pixels (that'southward the first forced resize) -plough off the grid and try to eyeball its size to more or less 1000 pixels, because at that place is no way to force it to appear at native size -make a multiple of 70px map (let'south say 28X28 50 px squares, 1400X1400 pixels), stretch the map on 20X20 Roll20 squares and disable the grid. At present the map is displayed at 1 pixel is ane pixel size (that'south where Paul's problem lies, I think, because when a graphic chemical element is not displayed at 1pixel/pixel, it tends to lose quality). I would aslo similar to point out that, when you say: If you upload something at 2100x2100 pixels, and so get in 2100x2100 pixels in Roll20, it'due south the same thing equally what you uploaded. it is but partially truthful, because, it is true for 2100 (and whatever multiple of 70) merely it is not truthful (and fifty-fifty impossible) for other sizes. You tin can not upload a 2000X2000 pixels map and make it exactly 2000X2000 pixels in Roll20 because at that place is no native size or pixel size command. Just a foursquare and inches command (using inches as the unit simply makes discussions more difficult because now you accept the inches equally "i foursquare in Roll20" and inches every bit "dots per inch on your map"). The trouble is the same with tokens, because Roll20 doesn't make a difference between size and calibration. -I make my tokens to be at the same calibration every bit the maps, allow'southward say 50px/foursquare, only being the same calibration does not mean that the token fit into a 50px square. If information technology has a weapon extending from its manus, it could be, for exemple 40X65 px. So, whilst being at the same scale equally 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, only then I accept to eyeball the resize of an element that needed no resizing. And the last trouble is with the grid, there is no fashion I tin can utilize information technology, with the issues mentionned in a higher place. I can manage, and I accept been able through some manipulations to apply my stuff in Roll20 every bit it was intended. But, it still means that I won't be able to share the stuff I brand, considering I can't wait other peoples to make the manipulations I take to go through to apply Roll20. I think that'south where the trouble lies: I have to fight the plan to be able to accept the program produce the result I want, which is basically "do nothing". My maps and tokens are perfectly sized for being used together without whatever change. If I was able to tell Roll20 to keep off, it would exist good for me. If I could set up 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 up the centre of rotation a token, it would be perfect (but that's not equally important). Sorry, if this postal service 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 information technology Roll20 and that did not piece of work. It works with drag and drop.
If nosotros all had a constant for Roll20'due south 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 equally I know, it is 70 px/square; whilst a square is chosen an inch, it has nothing to do with dpi. The dpi of your original map shall have no influence, equally long as your squares are 70px long. If they are not, you are out of luck because there is no fashion to make a resize except through eyeballing.
My head hurts afterwards reading this thread. Notwithstanding I'grand also trying to effigy out this Pixel to inch thing. What I'k doing is Copy Paste a film from a PDF take a chance into MS paint and then I can use the Resize push(Pixels non Percentage) to make it as big/small as I want sometimes I get the grid to line upwards sometimes not. More often than not I'm but turning off the Roll20 grid. Is there magic Horizontal/Vertical Numbers for a each Roll20 Hori/Vert inch? Is there a easier way to practise what I want? As well only the US Burma and Republic of liberia still apply the Imperial inch.... But saying :)
For maps I have been using the Alt push button to alter map size without snapping to grid and changing the map settings to between .47 and .69 so that I tin 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 foursquare units and merely loose a little fleck at the ends. Not sure if all the mathematics in a higher place are for something else, only with this I can play and see that the token when it moves onto a foursquare on the map, that it matches the grid in roll20.
Yes, information technology works that manner, only it is very approximative, takes time and tends to reduce quality. Whilst the maps could accept 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 allow them exist squashed within a square or you resize them with an Alt button, but without annihilation to guide you lot (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 yet inferior to other VTTs around (but, nosotros are still in Beta, so, at that place is hope).
Okay, so revisiting this thread (because I am working on some rendering pipeline changes and information technology seems like a practiced time to figure this all out). Beginning off, nosotros are switching from "inches" to a more than full general "units". You lot will then be able to alter for each page in your Entrada what the "scale" of the map is (1 unit of measurement = seventy pixels = ____ ft/meters/miles/etc.). You can too modify the size that a square/hex is (1 grid square = ____ units). In add-on to that, it sounds like what you lot're wanting is to have an option so that you tin just enter the dimensions that y'all want a token to exist (eastward.g. 50x50) so yous don't have to eyeball information technology with the Alt key/resize tool. Would those two things solve this effect?
Yeah, that would exist really proficient. That would make it possible to accept general maps in miles and tactical maps in feet or whatever. Entering the dimensions of the token would work, I would just accept to enter the dimensions of the token (or the map). Not always square, and perchance larger than one square, so, something like 45X83 should exist possible. That would make information technology possible to work with graphic elements specifically prepared for the game. Though, the possibility to but switch the tokens (or maps) dimensions to native size (with one pixel being equal to .... one pixel) would even be more useful, considering then, there is no reason to enter annihilation and y'all would just have to load elements prepared for the game without any change.
wroblewskiwentown.blogspot.com
Source: https://app.roll20dev.net/forum/post/1043/uploading-of-user-created-maps-as-a-map
0 Response to "Roll 20 Recent Uploads Wont Empty Out"
Post a Comment