Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LineSegment is not a proper line #3

Open
5argon opened this issue May 29, 2019 · 1 comment
Open

LineSegment is not a proper line #3

5argon opened this issue May 29, 2019 · 1 comment

Comments

@5argon
Copy link
Owner

5argon commented May 29, 2019

The LineSegment is just a rectangle. But what is a "real line" as in we dragged a pencil over a piece of paper? Surely it doesn't look like a rectangle. It need two more things : line cap and line corner.

LineSegment will not support rendering corner or end cap mesh even in the future, but I am thinking of making CornerSegment and LineEndCap for those, and assemble 3 of them into a complete line with one another component (with a list of corner points instead of start-end). In all, line renderer will render 3 kind of meshes in batches. (Assuming vertex resolution of corners and caps are fixed, which you should for batching performance)

@5argon
Copy link
Owner Author

5argon commented May 30, 2019

This is a full overview of my vision of a line. What I have today is the yellow rectangle with red crosses as from-to of LineSegment. In full line, the terminal red cross will get an additional Entity that renders the cap with appropriate vertices resolution (if 1, it is a triangle) and a corner one. But this case is too easy because the corner is 90 degree.

Screenshot 2019-05-30 16 07 33

Consider only this case, instead of specifying from-to of red crosses like before, the real line's list of points would be red to purple cross, then to the final red cross. We would need a new mesh piece on that corner without number, and the 1, 2, 3 would be via the same rectangle mesh scaled appropriately depending on line width. (They are each, a perfect square of half of line width)

Now, the cap could be the same thing as this corner mesh x2. So if the corner and cap has the same vertices resolution, we have more mesh batching potential here. Since we will use only 2 kinds of mesh to get the entire line.

In summary we require 3 input points to generate a total of 5 points.

The inner border is sharp, I don't know should I do something about that or not.. In vector software, if we create a rounded rectangle with 0% corner it would look sharp too. Here's what happen when it's not 0. But I think this is too sophisicated to be rendered efficiently since we no longer able to make only few kind of meshes and assemble them.

licecap

More importantly, this is 90 degree corner. Could we really manipulate the corner so that it works for any degree without introducing a new mesh? I could see the cap will just have to be rotated to fit the current angle, but I have no idea about the corner.. for example this mitre join. How could we fill the corner efficiently while trying to preserve the rectangle shape of the line? Mesh assembling approach breaks down in this case.

Screenshot 2019-05-30 16 25 46

..or, is there any "efficient corner"?

For example we make a special case for solid material (no gradients either) where the mesh is allowed to overlap, and somehow we could get the corner with some rectangles and a rotated version of end cap piece?

Maybe it is inevitable to implement triangulation for corner pieces, and we keep batching for only line segment and its caps. Maybe someone will turn off the corner for performance by themself, since when the line is small enough corners and caps will be less noticable. And with an option to change the line so that the line segment rectangles meets at the same point (without "purple cross") like what we have today to accommodate that. (which will create a small intersection, would be negligible when material is solid color)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant