[BUG] Phantom walls created from svg.

[ekerstens]

Describe the bug Adding an svg as the walls for a map is adding phantom walls that don't exist in the svg.

To Reproduce

1. Add the attached walls png onto the map layer.
2. Add the attached svg as the walls layer.
3. Set Blocks vision/light
4. The walls mostly work, but random lines are added that don't exist in the svg.

Expected behavior Expect the mapping of walls to match the paths in the svg.

Screenshots Shows one of the random lines

Desktop (please complete the following information):

• OS: MacOS
• Browser chrome
• Version 89.0.4389.114 (Official Build) (x86_64)

Map files: Archive.zip

[PalasX]

I left a lot of documentation on the process for doing this with cavern style donjon maps here: https://github.com/Kruptein/PlanarAlly/issues/641

The bulk of it is, use GIMP image editing software, and do this: start with your flipped monochrome BMP smooth it out by selecting FILTERS -> LINEAR MOTION BLUE -> Length 10, Angle 0. Find the edges with FILTER -> EDGE-DETECT -> EDGE... -> Algorithm Sobel, Amount 2 FILE -> Export -> some file.bmp, this will be what we use for potrace. "potrace.exe -u 1.333333 -s -O 1 "some file.bmp" The resulting SVG file should be nice and optimized and small. a 160x160 grid map will have an svg smaller than 400kb.

Can you document your process for creating the SVG? I had some weird extra lines added when i was using some online SVG converters. the process above worked every time.

[ekerstens]

My method was

1. Export player map from donjon
2. Import into gimp and set the white to the alpha channel
3. Convert to SVG

For SVG conversion, I used https://www.pngtosvg.com/ which added the random lines and inkscape which didn't seem to register at all. I will give your method and potrace a try; thanks for the thorough documentation!

[PalasX]

Most of the online converters i tried gave me similar issues. Let us know if potrace does the trick! Good luck :)

[ekerstens]

potrace worked like a charm. I took the player map from my cavern style donjon map, and converted it without any modification other than changing the file format to bmp and flipping the image. The resulting walls work like a charm. Since the walls are hidden anyway by FOW, I used the standard map style to avoid having to change the map to monochrome. The cavern is pretty small, so I didn't worry about any smoothing, though if working with a bigger map I would follow some of the steps you took. Can you share how you came to the correct potrace settings of unit=1.333 and curve tolerance of 1?

Since it seems flipping the image is a common and only occasional problem that comes up, I wonder if it is worth adding a toggle next to the walls to flip them in the modal, next to the add walls button? This way, when the issue comes up, it can be a quick toggle to fix.

[PalasX]

EDIT: Compeltely forgot to remind you to use GRID:NONE when creating your donjon player map, the grid lines confuse the hell out of potrace sometimes. most times. have you tried the steps outlined in this comment: https://github.com/Kruptein/PlanarAlly/issues/641#issuecomment-817076144 ??

that was it. original reply below. :EDIT

I used the curve optimization of 1 because it worked, and lowered the filesize of the SVG. you can certainly use lower, but 1 seems to be reliable.

i came up with the unit conversion of 1.333333 because i didnt want to type any more 3's than that :) It was because of a difference in pixels per grid square i was getting from an online SVG converter. donjon player maps default to 50px per unit, as does PlanarAlly, so im not really sure why i kept doing it? It keeps working though. I wouldn't know if other values work, as i have written my script to automate this process already, and will prrobably never type the command out manually ever again ;P

as for setting the flipping as a toggle inside PlanarAlly, i have to disagree. Flip your input data if you have to. its trivially simple to flip an image before running it through potrace, so why try to accomplish svg flipping in javascript in a web browser when its so much more efficient to do it anywhere else?

I also usually use the standard map style, as it's monochrome already like you said. i still run it through edge detection so that i end up with an SVG of only lines, and not filled in areas. for larger maps, it seems PlanarAlly's processing all those filled in spaces into shapes can get hung up. If you try a colossal sized cavern style map and it works for you without having to edge detect first, let us know!

When im done running the playermap through potrace to make the walls SVG, i usually use a more stylized version of the map to show my actual players, created with DonJonPainter: https://github.com/donjon-painter/donjon-painter

Alas, since im no longer manually drawing all the walls, the players dont get to see a lot of the "wall" textures, or any of the pretty parts of the map that they couldn't get to. Think it's possible to modify "Blocks vision" with a togglable option of "but you can still see X grid units beyond it" where X is 0.0 to max view distance? Just a crazy thought ;)

[ekerstens]

I tend to turn off grids anyway so I can resize the map as needed to planar ally's grid. I've got it all working, though my maps are pretty small so I haven't had to do any optimizations. The bug can close but I'm keeping it open right now for the ongoing discussion.

You make a good point about the flipping being probably much harder to implement from a javascript perspective. The one thing that is weird to me is the fact that it flips upside down only sometimes.

I really like the idea of a sort of "offset" on walls to be able to see map assets/walls/etc. One thing I can imagine being tricky would be knowing which direction to offset from a line.

[PalasX]

Good point about directionality for the semi-transparency offset, im guessing it would have to be omni-directional. MOST of the time the players are only supposed to be on one side of a wall anyway, right?

As for the image flipping, looking back, there was only a single map that i didnt have to flip, and im not even sure anymore if i used potrace to create the svg or if i did it in one of the online vectorizers. i had a lot of randomly named SVG files in my test directory at the time. I do wonder what it is about the SVGs that potrace outputs that makes them flip vertically from the input source in the first place?

[ekerstens]

What's interesting about the SVGs, is that when I open them in chrome or inkscape the render in the same orientation as the source image. It is almost as if there is some information that tricks Planarally into flipping them.

Agree that the offset is probably in a single direction, since most likely the players aren't inside the walls looking out (except maybe edge cases like the 5e spell meld with stone). Being omni-directional though would probably be the easiest approach; since it could be combined with the tracing calculations within the vision system. Would this be a location wide setting, or an item wide setting? I could imagine a scenario where for the most part you want to show some depth to the walls, but somewhere on the map doing that for a really skinny wall would reveal the other side.

[PalasX]

The SVGs are undergoing a transform applied to the entire structure, where it's been scaled in the Y axis by a factor of -1, which flips is vertically. I have no idea why potrace or any other vectorizer application does this. The effect is that the SVG data is still upside down, but its also being displayed upside down, so it looks normal.

[Kruptein]

Hey just checking in, is there an actual issue with PA's interpretation of certain svg's or is it more a problem of generating good fitting svgs?

[PalasX]

i THINK the issue is in generating good input SVGs. Since ive found a working method, i havent done much extra testing on whether setting a transform scale +x,-y (flipping the svg internally) is being handled sanely by PlanarAlly, but it seems to be following specs.

[ekerstens]

I've mostly had success using the above technique with potrace, but have run into a scenario where it still interpreted an extra wall. Let me see if I can dig up the example.

[ekerstens]

Okay, I was not able to replicate the phantom walls issue when I tried to regenerate an SVG for the map which I previously had problems with, so I must have had an issue in the svg generation. I did however play around a bit with the transform, and it seems that this transform is ignored by Planarally. So whereas other svg viewers show the negative y scaling double flipped (correctly) it is ignored by Planarally therefore requiring the manual flip. Included is a folder with an example. Note that the inverted and un-inverted svg files are identical except the y scaling was flipped in the univerted version. They display differently in SVG viewers (tested with inkscape) but the same in the tool. SVG Test.zip

[Kruptein]

Ah cool, thanks for providing that zip!

[Kruptein]

A change to svg handling was just merged to dev, PA should now properly handle scale and translate transforms on svg files (which includes vertical flips). It also now properly implements bezier curves which are a likely cause for some phantom walls.

See https://github.com/Kruptein/PlanarAlly/pull/825 for details