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

Images for dynamic lighting?

1614281220

Edited 1614281286
So I've been using the dynamic lighting feature for many years now and this is something I haven't seen answered. Normally to create an obstruction, I draw lines and shapes in the DL layer with the drawing tool and the software maps out the rays of light and shadow accordingly. Also I know that I can upload images to other layers in the gamespace and then copy them to the DL layer and they don't behave as objects I create in the DL layer with the drawing tool. So my question is this, how does Roll20 know the difference? Or more specifically could I create similar line drawings in GIMP for example, save them as GIF or PNG files with a transparent component upload them into the object, GM or map layers then copy them to the DL layer have then work as shadow casting obstructions?
1614286013
Brian C.
Pro
Marketplace Creator
Compendium Curator
Objects made with the drawing tool maintain the data on their vertices, a critical component for the Dynamic Lighting calculations. Images will not work.
1614301226

Edited 1614301290
I believe an SVG file works, and is how The Aaron's Walls API script (<a href="https://app.roll20.net/forum/post/7785026/script-walls-svg-path-importer-for-dynamic-lighting-now-with-advanced-fog-of-war-support" rel="nofollow">https://app.roll20.net/forum/post/7785026/script-walls-svg-path-importer-for-dynamic-lighting-now-with-advanced-fog-of-war-support</a>) works, but I have not used it.
1614316149

Edited 1614316201
Rabulias said: I believe an SVG file works, and is how The Aaron's Walls API script ( <a href="https://app.roll20.net/forum/post/7785026/script-walls-svg-path-importer-for-dynamic-lighting-now-with-advanced-fog-of-war-support" rel="nofollow">https://app.roll20.net/forum/post/7785026/script-walls-svg-path-importer-for-dynamic-lighting-now-with-advanced-fog-of-war-support</a> ) works, but I have not used it. If so, that could be very useful! Thanks for the tip Rabulias! For example I could generate a map in other software, GIMP for example, use the more sophisticated editing tools there to automatically generate a wall/obstruction SVG without all that tedious tracing by hand and then: upload the map image (PNG, JPG), move it to the map layer, stretch and squish it to a size I like. upload the the SVG file the map or object layer copy to the DL layer Delete the the copy of the SVG from step three. Stretch and squish the SVG in the DL to the size I like. Turn on dynamic lighting. Done. Right?
1614321941

Edited 1614322080
Oosh
Sheet Author
API Scripter
Not quite - if you read the post in that link, you'll need to parse the SVG with an online tool before running the script. You don't actually dump the SVG on to the canvas. The walls are just a load or coordinate arrays, not a bitmap. From the look of Aaron's post, if you have your map image selected on the canvas when you run the script, it will use that for scaling &amp; positioning. I think (only dealt with DL lines a little) the points are all stored as [X,Y] coordinates: the number of pixels from the origin (top left corner) of a bounding box containing all points in that path. There are extra Bezier coordinates for curves, but you don't need to worry about that since they don't work with DL. Once you've imported your paths, you can group them all together to easily resize them if you need to tweak the map.
1614332257
Brian C.
Pro
Marketplace Creator
Compendium Curator
Just a note: resizing DL lines leads to unexpected results with AFoW and LDL. It seems to work properly with UDL.
I tried Arron's wall script out and it works just fine! Immensely speeds up the use of dynamic lighting!
Thanks for correcting my bit of misinformation about the SVG file, Oosh.