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

Dynamic Lighting Sightlines blocked by non-existant walls

1678903760

Edited 1678904801
So I've had this issue with a few of my maps where I've created fairly simple sets of walls and torches on the lighting layer, and when using a test character to move around the map I'm seeing invisible walls that are seemingly blocking line of sight for players. I'm not sure where these are originating but it would be helpful to see if others have solutions for this issue. ^ Here I have my lighting layer open showing the walls I've used around the map to block line of sight, as well as torches placed around where light sources will be. ^ This second image is what my player sees when in the game, there is a diagonal \ invisible wall that is blocking their sightline to the right. ^ This third image shows what the player sees when they move past the invisible wall to the right, now their sight is blocked from where they came. I'm interested to know whether this is a common glitch, and whether this is an easy work around. Kind Regards, Diplonio :)
1678904807

Edited 1678904856
Gauss
Forum Champion
It looks like you used freehand to draw your walls. That is most likely the cause. Replace all your freehand walls with polygon/line walls.  If you would prefer not to do all of that, you can copy your page, then remove the freehand walls one by one until you find the particular freehand wall causing the issue. Then on the original replace that particular wall.
I can't tell for sure from your map, but it looks like the walls are drawn freehand. This creates a burden for dynamic lighting, and has some unpredictable effects. If you replace the lighting lines with the line segment tool, instead of freehand curves, does this still happen? In my experience, I can have pretty complicated walls made up of line segments without triggering problems. As a pro user, you may also want to get the DLEllipseDrawer mod for the API. It's available on the one-click menu. It works to turn ellipses drawn on the DL layer into polygons which suppresses some problems. It won't help with converting freehand drawings however.
1678904961

Edited 1678904991
Kraynic
Pro
Sheet Author
It looks like you are using the freehand tool to draw dynamic lighting lines.  You should try redrawing it using the tool that lets you draw segments instead.  Freehand basically creates a very large number of wall/points to calculate light from, and eventually webgl (or whatever) just gives up.  Basically, never use the free hand tool for dynamic lighting lines and this sort of thing should go away. Edit:  Well, we all piled on, didn't we....  :p
1678906506

Edited 1678906619
David M.
Pro
API Scripter
You might want to check out my PathEditor script. It has a "Simplify" command that reduces the number of points in freehand drawings. It might save you from having to re-draw everything with the polygon tool. You can always use the script to tweak a few of the vertices after simplification if they lose too much resolution around tight corners.  See example of Simplify in use here . This reminds me: I need to add this script to the one-click repo...
Thanks guys! I had a feeling that might be the case, I'll stick to lines from now on! Cheers! Diplonio
Ugh I was having this same issue. Having to use the polygon tool for stuff like caves that aren't straight lines sounds like a chore and a half. I'm very sad this was the cause. 
1679017991
Gauss
Forum Champion
Lucas S. said: Ugh I was having this same issue. Having to use the polygon tool for stuff like caves that aren't straight lines sounds like a chore and a half. I'm very sad this was the cause.  I never found that to be the case. Just keep laying down points while doing the line.  Click (left click), move mouse, click, move mouse, click, move mouse, click...etc until the line is drawn, then right click to end the line. It goes pretty quickly. 
You can also end a line by pressing the escape key, so segments don't have to connect into complete polygons.
1679067519
Gauss
Forum Champion
Valerie M. said: You can also end a line by pressing the escape key, so segments don't have to connect into complete polygons. Right click does the same thing. :)
1679068086
keithcurtis
Forum Champion
Marketplace Creator
API Scripter
As a matter of practice, the current advice from the developers (and the technique used by the conversion team) is to use several shorter segments rather than one long continuous line, as well. This is more efficient for the rendering engine, and makes edits much easier. It's faster to replace one short line than to redraw an entire perimeter.
1679069055
David M.
Pro
API Scripter
That's interesting, Keith. Are you saying that given the same number of vertices and cumulative length, having a larger number of path objects is more efficient for the LoS / ray tracing algorithm? Since I use ParhEditor a lot to tweak complex paths (more segments per path object), it's acrtually easier for me to have fewer path objects. Hmm, if you confirm the interpretation above, that's something I'll have to keep in mind in the future if I start to have lag issues.
1679069981
keithcurtis
Forum Champion
Marketplace Creator
API Scripter
Here's an example, using the map above. There is no hard and fast rule for the most efficient line length, it ultimately works out to a matter of preference, with the only guide being fewer points to calculate = better performance. Again, this is what I have been taught through my work as a conversion contractor, and the advice of the development team. In my rework of the lighting above, i have done the cavern outline in several segments rather than one continuous path. This has fewer points by a couple of orders of magnitude than a freehand line would produce, and has the additional benefit of letting me redraw a small segment rather than the whole line if I need to edit. Not as big a deal on a cavern map, but on a "dungeon" map, this could be invaluable in fixing a discovered light leak or misplaced edge. I have used a different color for each segment, for clarity. This is not recommended for an actual map.
1679070406
keithcurtis
Forum Champion
Marketplace Creator
API Scripter
As an alternative, here is a method I sometimes use for caves. This works best if you are not using lines to hinder movement. One line (red) separates the major areas, and then smaller lines (green) just control sightlines on corners. Depending on the map, this can be quicker to draw, and is extremely editable. It also works best for maps where the background is black.
1679070749
keithcurtis
Forum Champion
Marketplace Creator
API Scripter
David M. said: That's interesting, Keith. Are you saying that given the same number of vertices and cumulative length, having a larger number of path objects is more efficient for the LoS / ray tracing algorithm? To answer this more directly, given the same number of vertices and cumulative length, I am not certain if there is any performance difference. If you are using a script to break apart lines that need editing, then you might not need to worry about number of paths . But without that (which would be true for all plus users, and probably the majority of Pro users), then using the same number of points, but already separated into more paths makes a difference in terms of editability.
Ah amazing thanks Keith, I really like the use of those lines to cut the sightlines on corners I think I will start doing that too!