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
This post has been closed. You can still view previous posts, but you can't post any new replies.

Dynamic Lighting - One Sided Dynamic Lighting

Definitely +1
This is a Canvas-related request, and it's something we will get to in the unknown future.
Most definitely +1. Would allow things like "Hill Advantage" from RTS games like Warcraft and Starcraft to be implemented.  Unable to see up a hill, but when on top, you can see everything else.
+1 Waiting patiently....
+1 everyday till its done!
+1, this would be extremely useful! Right now the only workaround I know is to add temporary walls when players are on the lower side, and delete them when they climb up. It's doable but slows things down.
+1 as well, so many maps would be easier to run/maintain with this type of feature.  Thinking people beseiging or defeding a castle. 
Henry said: I agree with this idea! I don't know how hard it would be to implement, but I just recently made a multi-tiered map as well, and it became a problem that the players could see beyond cliffsides that rose over their line of sight. In addition, I had a player standing a distance from a cliff, and they were able to look down the cliff and see the loot they should have only been able to see if they were right at the cliff edge... Maybe we could have a height layer , that calculated being able to see down the cliff face depending on where the player is standing away from the cliff? I'm not sure how the calculations would work, or if it would be too taxing, but it would be a nice little feature, especially if you could mark where your player's eye level height was on their token to calculate line of sight against. I don't know. What you want is a first step towards 3D maps/landscapes. I'd totally support a standalone roll20 application that uses 3d terrains. :->
+1, would be amazing
1515086067
Brian C.
Pro
Marketplace Creator
Compendium Curator
3D or multi-level should probably be in a separate Suggestion thread all its own. However 1-way viewing walls and elevation changes like viewing across a castle wall could be handled by being able to define zones on the map and which zones can see another zone. So someone on a castle wall can see outside the wall, but the attackers outside can only see the first five feet of the wall.
+1
+1
+1
+1 !
Seems like everything I vote for is a canvas request.  Maybe I should learn canvas and work for Roll20.
+1
+1... trying to do the lighting for a map whith canyon and cliffs... it would be useful here
+1
+1 
+1
+1
+1
+1 and please add "blocks movement" flag if you are going to allow lines with optional "sides" to your BSP tree or whatever you have going on there :)
+1
+1
1528428093
DLB
Pro
Translator
+1
+1
+1
+1
+1
Well, I like the idea for the purpose of allowing players to see more of the map art without granting vision past it.  To that end, it would be nice as a feature for map elements and tokens that you can toggle  (specifically for .png images with edges that can be defined by their alpha) .  It would live in the right-click menu, and it would automatically paste an identical "poly-outline" of the image to the dynamic lighting layer set to be visible itself, but not permit vision beyond its opposite-facing "normals".  This would also cut down on users having to draw intricate poly-lines in the dynamic layer itself  and that would drastically reduce the amount of time it takes to produce a working dynamic lighting solution for a map.  The other awesomeness here is that the "poly-line" function that would draw these "shapes" for us, would also automatically create the "normals" so that we wouldn't have to designate them by hand.  This kind of stuff exists in lots of editors, so I can't take credit for these ideas, but I have no real idea how easy or hard this would be to implement.  My fingers are crossed for this to become a thing in Roll20, though.
+1 on SilverKnightGG 's suggestion. I like it.
+1. I would love to have two features that have been discussed so far: polygon/line flag to block movement, and are see-through for dynamic lighting. polygon/line flag to block movement, and are see-through for dynamic lighting in one direction. For that second bullet, it could be done by using vectors for the lines at draw-time. For example: If I draw a line from the top-middle of the map to the bottom-middle: tokens on the left side can see the right side, but not the other direction. If I draw a line from the bottom-middle of the map to the top-middle: tokens on the right side can see the left side, but not the other direction. Just my two-cents. ;-) Also, regarding SilverKnightGG's idea: SVG files might make sense for this... I can see a world where I can store the map's bitmap art as a jpg/png locally, and the dynamic-lighting line-work as an SVG. This allows me to keep all of this offline and load things into Roll20 when needed.
+1 on Ammo's ' add "blocks movement" flag' idea...
+1 on Siliceous's 'vector' direction idea.  The direction of sight could always be towards the right of the direction the line in drawn in, so no need to set it, just draw. Would be awesome to have a toggle for 'blocks movement' as well as choosing visibility of 'none' (current), 'one-way' or 'full'. With this we can have transparent barriers and automatic terrain reveals when passing a non-blocking line (one-way non-blocking line drawn 5' away from the cliff edge).
+1 as well... a toggle for movement and visibility (none, one way and full) that was mentioned would be incredible. Been wanting windows for a while now.
+1 this is so necessary, whenever we are in a battle with some kind of elevation it just becomes unreal, the players can't see tokens they should be seeing, and thus behave differently. It just gets the players out of character because of not having a faithful representation.
+1
+1
+1 elevation doesn't work without this. :(
+1
+1 
+1
+1
+1 Just ran into this problem in game.
I definitively vote for that! +1
1547574019
Kenton
Forum Champion
Translator
This suggestion has headed into a few different directions, so, we’re responding to the original idea posted, "One sided Dynamic Lighting." We totally see the utility in the idea. The primary problem is going to be performance, so launching this is going to need some additional research. We won't be able to start development until after other blocking updates are made to the Virtual Tabletop. In the meantime, we'd like to collect specific ways would you use a Dynamic Lighting tool that only blocks vision and light from one direction. We’ve heard: An object that a character can see, but blocks light and vision beyond it (see the tree trunk, but block beyond the tree trunk) Dealing with characters on different elevations Windows, One-way mirrors Please let us know other ways you would like to use this feature in your games.
Can you clarify what you mean by "blocking updates?" Are these updates that are prerequisites for the changes this suggestion requires? Or are they updates to a subsystem that deals with calculating what blocks a token's vision? I am fairly sure it's the first, but with the language of this suggestion could make this response confusing to some.
1547738883
Kenton
Forum Champion
Translator
Rabulias said: Can you clarify what you mean by "blocking updates?" Are these updates that are prerequisites for the changes this suggestion requires? Or are they updates to a subsystem that deals with calculating what blocks a token's vision? Sorry, I can see why that's a confusing response to a suggestion that deals with Line of Sight on the VTT! Before we add additional objects that calculate the visibility on the VTT, we want to improve the performance of those functions. Those updates to the software need to be complete before we add additional elements that complicate the calculation and rendering.