Polyline sharp angle issue

Avatar
nick russell
  • updated
  • Under Review

Hi Freya, thanks for the great asset. 

I have been using Polyline to create a pen tool and it works great, however I have noticed a bug when you create a sharp angle between consecutive points. I have attached a gif showing the issue:

Image 112

And here are my component settings:

Image 113

I would like to use the Rounded join type because it looks great as a pen, but the issue doesn't seem to happen on simple joins.

Thanks heaps,

Nick

Reporting a bug? please specify Unity version:
2020.1.4f1
Reporting a bug? please specify Shapes version:
2.3.0
Reporting a bug? please specify Render Pipeline:
Replies 7
Avatar
0
Freya Holmér creator
  • Under Review

this is unfortunately a hard problem to solve, and the solutions will likely be pretty computationally expensive if we end up having one. there might be a way to solve this case in a performant manner, but I haven't looked into it much yet because my priority has been real-time use, rather than maximum quality lines with no edge cases left. Anyway, maybe, is my answer, currently low priority!

Avatar
0
nick russell

Hi Freya, thanks for the update. I will see if I can work around the issue in the meantime. 

Avatar
0
torfi asgeirsson

Hey, just curious if you found a workaround for this other than using simple joins as I'm having this same problem.

Avatar
0
nick russell

No, I never found a solution to this unfortunately. 

Avatar
0
Freya Holmér creator

The upcoming update has a partial fix to this issue - preventing the very large overshoot (though not fixing all other problems)

Avatar
0
Andy

I can see this also - in such cases previously in my own code I have just drawn all of one line and all of the other after, not trying to turn the lines that overlap at both ends into a single piece of geometry because that is hard (& slow). If both ends of a line overlap (inner line-edge segments do not intersect) then possibly you have to just draw both separately and lose the perfect drawing. What you should not get is a distortion of the outline

tldr: the last fix does not appear to have fixed? much...?

Avatar
0
Freya Holmér creator

yeah, all of this is complicated for a whole host of reasons, to mention some:

  1. lines can be billboarded in 3D space, and need proper depth information (prevents 2D-based shortcuts)
  2. lines can have either screen-based or pixel-based sizing, and, individual points in the polyline can have separate thickness scales (prevents constant-width shortcuts)
  3. different join types affect the mitering shape and its bounds (prevents constant-length shortcuts)
  4. it needs to support partial transparency (prevents overlap/overdraw shortcuts)
  5. it needs to support anti-aliasing (prevents stencil buffer methods to avoid overlap drawing, and to some extent has issues with overlap too)
  6. it needs to be supported in existing render pipelines, without additional screen buffers (prevents masking based overlap avoidance)
  7. it needs to handle self-intersection gracefully. this is the thing that's currently broken (prevents taking shortcuts on assuming well-formed polylines)

The way it behaves right now (and the reason it gets weird in certain edge cases), is because I let go of point 7 to enable point 4, 5 and 6. Drawing each line segment separately and overlapping them fixes the specific case of round joins with an opaque blend mode, and with anti-aliasing off, but it doesn't fix miter or bevel joins since they still need to be clipped one way or another. It will double up anti-aliasing when opaque but alpha blended with overlaps, and when using partial transparency, the overlap will overdraw the joins

The ideal solution in terms of quality would involve a whole screen-sized render target on a per-polyline basis, where it draws the shape mask and depth into a buffer, and then renders into your scene, at, wherever is ideal in whatever render pipeline you're using. but this is, expensive, and time consuming to get right across all the platforms and render pipelines people might use.

I have ideas for how to get closer to a solution here, along with a general overhaul of polylines to support things like dashes, but it does involve limiting platforms to those who support StructuredBuffer, which means it has to support compute shaders

so yeah idk! There's no ideal solution, I think it's just a matter of picking which drawback to be ok with, and this depends on your use case, and with all my users, I have all use cases, and whatever solution I pick will be bad for some of those use cases ;-;


Customer support portal powered by UserEcho