A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Calling all New Unity users! Join the Halloween Mods Showcase Challenge until October 31.
Discussion in 'Made With Unity' started by polyflow3d, Aug 18, 2019.
Here is gpu line renderer test for my upcoming editor tools. Seems mush faster than GL.lines ))
Looks cool. May I ask for a tutorial?
Added corners interpolation with costant thickness
Looks like something is wrong when rotating
TY. I am not sure that my practice is the best way to do this, I present this as a research project.
Implemented closed splines
It's definitely worth to try to so i eagerly waiting for a tutorial on this
Recently ran in to an issue with Handles.DrawAAPolyLine being really slow when needing to draw lots of lines. Would love to hear in more detail what you are doing so I can improve my person editor tools too!
Are you planning on releasing this at some point in some form?
I plan to publish this on AS for free. At least for first version.
1)I have done acute angles solving. Now it act much correct than built-in line render - not losing thickness, no flick when sign is changed.
2) added separated width and feather parameters.
3) all lines rendered by one drawcall
4) each line has own origin matrix
Looking forward to it. What does the API look like
Also, we need to draw a lot of lines, so we'd take every bit of performance we can get. Might be nice to be able to disable acute angle solving! Maybe worth keeping in mind while developing your solution.
Ok, i got it.
Currently, polylines use the same width and color for all vertices. Are there any cases where each vertex inside polyline requires a unique color and width?
Width no, color yes. But I can see width being useful for some cases.
We have the color fade from one to another. (2 colors) from start to end.
Pervertex color and with attributes is not a problem for the shader, but it increases the size of the vertex buffer that is passed to the shader. The buffer is updated each Repaint event, so the buffer should be as small as possible. So in the first version for polylines, I will implement the colors of the beginning and end only for.
Cool. It might be worth noting that the lines do not change very often in editor tools. Sometimes the lines do not change at all. So it would be good if we can initialise a line and redraw it many times, instead of resubmitting vertex data every frame.
Almost like creating a mesh once and rendering it multiple times.
As you can see the performance of dynamic lines is pretty good now : 1000 dynamic lines with 10 vertex tooks about 1.5ms CPU time. For compare - SceneView/Repaint event takes about 10 ms for empty scene.
So i plan to delay a "persistent" and simple polylines to next version and release package soon as possible.
I added a new primitive - a Dot and made a vector3 handle class based on it.
Dot also are drawen in screen space with fixed pixel radius and recieve world position as parameter.
Added separate thickness and color parameters for the beginning and end of polyline.
Prodigga, Is this allowed if the color interpolation inside the polyline is based on the index of the vertex? Or do you need distance based interpolation? Second one requires much more calculations.
That's probably fine.
This is a simple example of drawing in a GUI space that uses polylines.