Roll20 uses cookies to improve your experience on our site. Cookies enable you to enjoy certain features, social sharing functionality, and tailor message and display ads to your interests on our site and others. They also help us understand how our site is being used. By continuing to use our site, you consent to our use of cookies. Update your cookie preferences .
×
Create a free account

Icon Sizes for Rollable Tables? Also, 3D Rollable Tables?

What is the correct size for Rollable Table Icons? Also, is there a way to do a 3D version of Rollable Tables that match the number of sides found on typical dice?
1466907004
Scott C.
Forum Champion
Sheet Author
API Scripter
Compendium Curator
Im not aware of a size requirement for the table icons. they will scale to the chat (to some extent) and you can scale them as you like as a token. Are you trying to replicate an actual dice?
Mostly just trying to make sure Roll20 mangles my Rollable Table icons as little as possible...
1466910576
Lithl
Pro
Sheet Author
API Scripter
There is not currently a means to provide a custom texture for 3d dice, however selecting alternate skins for dice is a planned feature, which very likely may include uploading arbitrary skins.
What about the Rollable Table Icons? Also, it would be nice if we could apply an SVG of our choosing per face, rather than having to use something so bulky as a texture.
1466960646
Lithl
Pro
Sheet Author
API Scripter
Tenacious Techhunter said: Also, it would be nice if we could apply an SVG of our choosing per face, rather than having to use something so bulky as a texture. A texture for a 3d model is just an image conforming to some standard shape. Most systems even allow for arbitrary scale, so long as the shape is the same. I'm not aware of any 3d rendering system capable of using SVG for textures, but transforming an SVG into some bitmap format is fairly simple.
So... about that Rollable Table Icon size...
1467058808

Edited 1467058823
The max width and height of Table Item images are set to 30px when rolled in the Text Chat. Here's the relevant CSS: .diceroll .didroll img {     max-width: 30px;     max-height: 30px;     vertical-align: middle; } Was this what you were looking for?
Yes, that’s exactly it ! Thanks! Please note that this differs from the Quantum Reroll png, which is 32 pixels; so this information really helps! You should update the Wiki with it!
Great! I added the info to Roll20 Image Dimensions .
SVG is probably better for 3D geometry dice than raster graphics because you can directly associate the face geometry with the image file; if you do it right, it doesn’t need additional cropping to the face shape; whereas a regular raster texture with pixels would need that cropping, and the association between 3D geometry and texture geometry wouldn’t be obvious.
1467126329
Lithl
Pro
Sheet Author
API Scripter
Tenacious Techhunter said: SVG is probably better for 3D geometry dice than raster graphics because you can directly associate the face geometry with the image file; if you do it right, it doesn’t need additional cropping to the face shape; whereas a regular raster texture with pixels would need that cropping, and the association between 3D geometry and texture geometry wouldn’t be obvious. Do you have any experience with 3d rendering? Generally, a set of UV coordinates are used to map the 2d image into the XYZ space of the model. You don't want one image per face, because that would use up way too much memory (especially when you're not talking about simple geometric shapes like dice, but rather models with 20,000+ faces). The texture geometry isn't always completely intuitive for complex models if you just look at the image, but you can get a pretty good idea usually, especially for organic shapes like people and animals. Here's a cheetah texture: Looks a lot like a cheetah-skin rug, yeah? Obviously, drawing directly on the texture like this would be horrendous for the artist, but there are many tools to make things easier, generating the 2d image after the fact. Simple figures are a lot easier, and don't even need special tools, you just need to know where the lines are that you need to color inside of, and maybe  what rotation each face should be at (depending on the UV coordinates, all the faces might  be oriented the same way in the texture, but an automatically-generated UV unwrap probably won't be). After some quick searching for people using SVGs for 3d texturing, it looks like there exist tools to do so... but they're simply rendering the SVG to some bitmap format at a specified resolution.
SVGs do have to be rendered into raster at some point to fit within the raster-based pipelines graphics cards use. My point about SVGs is, raster graphics don’t have an integrated coordinate system; SVGs do . So instead of having to cross-check back and forth, or use some intermediate file to manage where the texture should be printed onto the geometry, you know exactly what you’re getting, because it’s just one easily managed file.
1467173000
Lithl
Pro
Sheet Author
API Scripter
You would still need UVs to translate from the texture space to 3d space. The only thing SVGs are saving you on is storage space, and storage is cheap. Meanwhile, the SVG is costing you in memory as you convert it to raster.
No, you wouldn’t. You would just specify a single reference coordinate from which to print the SVG, which would probably just be that face’s origin. You would scale the dimensions of the SVG to the geometry within the SVG itself . “O.K., this face of my pentagonal d12 has its origin up here, and the pentagon is arranged like so, so I draw everything inside that border, and leave everything outside transparent. This is a piece of cake!”. One file, geometric translation and texture combined. You may or may not be right about whether the SVG to raster conversion would happen via the CPU rather than the Graphics Card; I’m honestly not sure how well graphics cards support vector graphics these days; there’s no corresponding buzzword feature. Regardless, without some evidence to that effect, I’m inclined to disagree. I’m happy to concede that point if you have some evidence that the SVG file itself wouldn’t just be thrown at the GPU itself, but, without that, we should probably give up that line of inquiry; it doesn’t do either of us any good to debate something so poorly documented.