Vectrosity - Fast and Easy Line Drawing

I am having trouble with the GetLength() function. I have made a 2D line in the editor and have attached a script with the following to the line object:

Code (CSharp):

1.  
2.     private VectorLine vl;
3.  
4.     void Start ()
5.     {
6.         vl = gameObject.GetComponent<VectorObject2D>().vectorLine;
7.         Debug.Log(vl.GetLength());
8.     }
9.  

Unity gives me the following error message:

ArgumentOutOfRangeException: Argument is out of range.
Parameter name: index
System.Collections.Generic.List`1[UnityEngine.Vector3].get_Item (Int32 index) (at /Users/builduser/buildslave/mono-runtime-and-classlibs/build/mcs/class/corlib/System.Collections.Generic/List.cs:633)
Vectrosity.VectorLine.SetDistances ()
Vectrosity.VectorLine.GetLength ()
Link.Start () (at Assets/Link.cs:19)​

Setting a breakpoint shows that vl is a valid vectorline with the expected number of points. I'm not sure what I am doing wrong. I did try adding SetDistances() beforehand but it gave the same error. This is Vectrosity 5.1 running on Unity 5.2.2.

Its likely me missing something obvious, apologies if it is.

 

Looks like I didn't update the SetDistances function in VectorLine.cs; "if (m_points3 != null) {" should be "if (!is2D) {".

--Eric

 

Thanks for the confirmation Eric. Is this something I can edit at my end or does it need a new build at your end? I did look for some source files but it seems to be a dll.

 

You can edit the VectorLine.cs script. The source is in the package called VectrositySource.

--Eric

 

Ah, separate package.

Thanks for the quick responses Eric. That solved it. Top notch support!

 

Hi sorry, I probably didnt look hard enough, but can drawn lines be interacted with like gameobjects? Can lines interact (collide/trigger) with each other and have physics applied to them? Thanks!

 

Use line.collider = true. Or maybe VectorLine.Selected depending on what you want to do.

--Eric

 

Hi, this is my first time using Vectrosity and I'm encountering a weird problem with End Caps. The cap seems to "smear" if the VectorLine is set to use Joins.Fill, but looks fine for Joins.None and Joins.Weld.

I'm currently on Unity 5.2.2p2. Any ideas?

Spoiler: Code snippet

Code (CSharp):

1. void Start()
2.     {
3.         // Setup line with empty point list
4.         VectorLine.SetEndCap("RoundCap", EndCap.Mirror, -1f, -1f, 2.0f, 2.0f, lineTex, capTex);
5.         pathLine = new VectorLine("PathLine", linePoints, 10.0f, LineType.Continuous, Joins.Weld); // Smearing if Joins.Fill is used
6.         pathLine.endCap = "RoundCap";
7.         pathLine.SetEndCapColor(Color.red);
8.         pathLine.textureScale = 1.0f;
9.     }
10.  
11.     public void DrawPath(List<Vector3> pathList)
12.     {
13.         // Clear old line
14.         linePoints.Clear();
15.  
16.         // Add new positions into linePoints
17.         for (int i = 0; i < pathList.Count; i++)
18.         {
19.             linePoints.Add(pathList[i]);
20.         }
21.    
22.         pathLine.Draw3DAuto();
23.     }

 

It's a bug, which I'll fix, though it's not really recommended to use Joins.Fill with textured lines; it's intended for solid lines.

--Eric

 

Hi Eric,

Loving Vectrosity overall. Have been using it for a while now. Great to get line stuff up-and-running quickly. So please take this complaint with that in mind.

The more I use it, the more I realize, it is super inefficient for dynamic lines. The good news is you can shave ~half of the time it uses ( order of ~miliseconds with just a thousand lines ) with very simple, non use-case specific optimizations. I got very good results with replacing your Lists O(n) with Dictionaries O(1). Of-course, some minor changes are required here and there to make sure you don't actually manually iterate a Dictionary, when you can just lookup the item you need.

For anyone else wondering how to get it running acceptably, you can also do use-case-specific optimizations. I got decent improvements with lazy line removal instead of in-iteration removal and surprisingly good results with abusing Dictionary keyvaluepair "locality" by bundling useful stuff ( aka Transform key for VectorLine values in LineManager, etc ).

I'm still experimenting with removing some of the branching in your core-loop, and that seems to be paying off as well.

Cheers,
T

 

Thanks! You're right that there are use-case specific optimizations you could do, but naturally those aren't going to work for a general-purpose utility. With all due respect, iterating through a Dictionary is over twice as slow as a List, so that's kind of the opposite of an optimization when it comes to drawing lines. Not to mention the increased memory usage, and the increased usage difficulty. Lists are only O(n) when talking about inserting/removing elements, which I don't think is something most people are doing constantly. The look-up time is far more important, and Lists are much faster in that regard. (Arrays are faster still, and Vectrosity used to use those, but the cost in flexibility was too high in the long run.)

--Eric

 

Hi,

None taken. Iteration is indeed slower, in all implementations (some negligibly so, others massively ). Memory use is higher, obviously.

However, lookup is much much faster ( lookup complexity in lists is linear , dictionary is O(1) due to its hash table-ness. ). And for drawing lines, where you mostly have the keys already, you can replace most iterations with direct lookups. Again, I'm not just speaking hypothetically and have profiled this with Vectrosity. This change alone reduced frame time by ~half.

Might be wrong however. Will keep testing

 

I've done plenty of benchmarks and profiling with Vectrosity using various collections and methods, believe me. Lookup with a List via index is O(1), and as I mentioned is over twice as fast as Dictionary; this isn't hypothetical either since I've already explored this.

In any case, it isn't actually all that relevant since collection lookup speed is a relatively small part of the overall process. Getting a value is minor compared to the math/logic involved after you have it. At this point the biggest optimization I could probably do is move some of the logic to a shader, but since that removes the ability for people to just use whatever material/shader they like, it hasn't seemed like a worthwhile tradeoff. Plus fiddling with shaders has more issues with cross-platform compatibility in my experience.

--Eric

 

Hi Eric,

Apparently, too early in the morning for me and got ahead of myself. Sorry.

The big speed improvement I saw was, in fact due to my use-case specific stuff. Made assumptions about what needs to be updated and how, removed failsafes that used to branch in various loops and essentially stripped stuff down. Tested the dictionary separately. No change, essentially. Time for more digging it seems, and shader work if it comes down to that.

Cheers,
T

 

Yes, sorry, even if using a Dictionary was 100X faster than List, it wouldn't make that much difference compared to the other stuff that has to be computed. One of the bigger issues, at least with Vector3 points, is Camera.WorldToScreenPoint, so I spent some time writing my own implementation, since I figured I could use optimizations such as using reference values instead of returning new values and so on. However Unity's native code implementation was something like 20% faster than the best I could do with all the tricks, so I had to give up on that. If there was any magic speedup I'd be all over that.

--Eric

 

Hi Eric,

Thought I would give you a heads up on some odd behaviour.

I was trying to change the color of a 2D line at runtime but it was working unreliably.

It looks like having a "Vector Object 2D" component open in an inspector during runtime seems to fight with the code assigned color and reset it back to the original a frame later.

In the same way, having the "Vector Object 2D" component open seems to auto call vectorLine.Draw() continually during runtime. This caused a situation where it didn't seem necessary to call Draw() in code after a color change but later caused a "bug" where the color change only worked when the object was selected in the editor.

Feel free to ignore if its by design. It just caused me a couple of hours of head scratching to work out what was going on.

- Si

 

Hi Eric,

Just to add something useful after wasting people's time here.
For my case, and what actually sped up my implementation is moving those calculations to world-space entirely. This made the massive difference I saw earlier. ( 2400 auto draw lines dropped from 16ms to 4ms --- edit2: make that 3 since it's easier to just parent the line objects instead of doing two matrix ops per quad ).

However, this might not be fine for everyone as you lose pixel-perfect widths and have to make due with world units. Also, welds might be finicky afterwards ( not using them myself at this point ).

Edit: Spent some more time with this and I think pixel-perfect widths can be computed for little cost as well, while keeping the rest in world-space. Will take a look at welds as well.

 

It's the result of having the VectorLine inspector open, yes...if the inspector says "do this" and your code says "do this other thing", one of them has to "win". I'll make that more clear in the docs.

Well, yes, if you remove all the stuff that makes Vectrosity do what it's designed to do, it will go faster. That's not really an option for me, though. But that's why the source is included, so you can make a customized version for user-specific things.

--Eric

 

Hi,

That's entirely true.

Here's what got me something I can work with for now. Just in case anyone else needs it. It "replaces" parts of the VectorLine Draw3D for loop contents. The matrix if and logic can easily be put back in, same for the other bits, if so inclined.

Just keep in mind you have to use world units for width with this. I might add the screen-space width calculation at some point but that defeats my current purpose.

Code (CSharp):

1.  
2.                 pos1 = m_points3;
3.                 pos2 = m_points3[i + 1];
4.          
5.  
6.                 //! center point and direction of line
7.                 lineCenter = (pos1 + pos2) * 0.5f;
8.                 lineDir = pos2 - pos1;
9.  
10.                 // cache premultiplied l here, we never use the l directly anyway
11.                 l = Vector3.Cross(lineDir, camFwd).normalized * m_lineWidths[widthIdx];
12.  
13.                 //! half dir directly
14.                 lineDir = lineDir * 0.5f;
15.  
16.                 //! cache some ops, it helps a bit
17.                 centerMinDir = lineCenter - lineDir;
18.                 centerPlusDir = lineCenter + lineDir;
19.  
20.                 m_lineVertices[idx] = centerPlusDir - l;
21.                 m_lineVertices[idx + 1] = centerMinDir - l;
22.                 m_lineVertices[idx + 2] = centerMinDir + l;
23.                 m_lineVertices[idx + 3] = centerPlusDir + l;

Hope this is fine, by Eric, to post here.

 

Vectrosity 5.2 is now available (on my site; submitted to asset store):

Additions:
• The VectorLine editor has the option to change the visual size of the gizmos used for manipulating line points.

Changes:
• Improvements in rendering for lines with 3D points, so that line segments, which have points that are far off-screen, maintain a consistent width and typically don't need to be subdivided into smaller segments to prevent culling.
• Properties such as showing point coords, show style, etc. in the VectorLine editor are persistent when selecting different lines.
• VectorLine.points2 and VectorLine.points3 are no longer read-only.
• VectorLine.canvas can be referred to before VectorLine.Draw has been called.
• Using ObjectSetup with Visibility.Static doesn't use a reference to the list of points supplied with the line, but instead creates a new list. (So it will work properly with more than one object using the same list of points.)
• Improvements in the way normals and tangents are handled.

Fixes:
• Fixed issue that would occur when adding points to a line, removing them all, then adding more points.
• Using VectorLine.AddTangents immediately after using ObjectSetup no longer throws an out of range exception.
• Fixed error that could occur with AddTangents if the line had been resized.
• Joins.Weld works correctly in the case where a line segment goes back over the previous line segment exactly.
• Fixed MissingReferenceException that could occur after stopping play mode with 2D lines.
• When setting VectorLine.lineType after creating a line, Draw3D works without errors.
• Fixed error that could occur in certain cases when using functions related to the distance of the line (e.g. VectorLine.GetLength).
• End caps work correctly with Joins.Fill.

Also TankZone is included for Vectrosity 5. I've removed Vectrosity 3 from the download, since pretty much nobody is on anything below Unity 4.6 these days, but if by chance someone needs it, send me a PM with your invoice number.

--Eric

 

Hi Eric,

Thanks for updatig Vectrosity so it's compatible with new Unity.

I have a question: For world-space-calculation reasons I've been using VectorLines3D in my game, as all my objects and collision detection (with lines) is being calculated in World Space. I was also using the canvas3D.sortingOrder and canvas3D.sortingLayerName to dynamically position different Lines layers in the Z order (in front or behind spriteRenderers).

To my disappointment I found that you've removed canvases from 3D lines, and now I can't seem to reproduce the desired effect in the game.

So my question is:
1. How can I move VectorLine3D in the Z order, as it was previously possible with the canvas.sortingOrder?

And if #1 is impossible, then my question number:
2. How can I easily recalculate all lines created from List<Vector3> - to List<Vector2>. At the moment changing Vector3 to Vector2 makes lines being rendered in completely different places than I want them to be. I need all the lines to be in the WorldSpace, as my whole game-logic is based aroud this concept.

Thanks for help.
Bests
Mike

 

Use Renderer.sortingLayer etc. Also you can use Vector3 points with Draw, which uses a canvas.

--Eric

 

Eric, thanks a million!
Renderer.sortingLayer did the job. Best support and product around
Have a nice one.
Bests,
Mike

 

It would be pretty slick if Vectrosity could create splines in editor mode as well as at runtime. Consider the feature requested!

 

Hi Eric,
Just ran into this issue trying to draw a bezier curve using Vectrosity. The camera used for Vectrosity is pointing straight down and it works pretty well when the curved line is short, but gets distorted at slightly longer distances.

Each square grid on the ground is 1 unit, so the distance drawn wasn't really that far. Red cubes are the line's bezier points drawn using Gizmo.

I'm on Unity 5.2.3f1 and Vectrosity 5.1 (latest version isn't up on Asset store yet).
Any ideas? Thanks!

Spoiler: Line settings

Code (CSharp):

1. ui_PathLine.throwPath = new VectorLine("ThrowLine", ui_PathLine.pointList, Screen.width * ui_PathLine.lineWidthMultiplier, LineType.Continuous, Joins.Weld);
2. ui_PathLine.throwPath.endCap = "ArrowCap";
3. ui_PathLine.throwPath.textureScale = 1.0f;
4. ui_PathLine.throwPath.material = ui_PathLine.material;
5. ui_PathLine.throwPath.smoothColor = true;

 

I'm assuming you're using Joins.Weld, which doesn't take Z into account for speed reasons, but it will look correct from the camera view. (The camera to which the line is oriented, that is.)

--Eric

 

Hello Eric, Recently I upgraded a old project that I did not code myself to unity 5.2.3
The only plugins it uses is Vectrosity, I bought the latest version of this btw.

The routine of delete old and import new did not work. I cannot tell which version I'm using but the project uses Vectrosity -> Image Based -> Glow Effect/GlowEffectDownSample and this is needed, I cannot seem to find these files in the latest Unity 5 version.

Basically on Unity 5, its just a pink screen when trying to run this effect, hence the need to upgrade.

Any tips and ideas?

 

Vectrosity doesn't use any image effects. It sounds like that might have been from the old Vectrosity demos, which used one or two effects from old Unity standard assets. But Vectrosity itself doesn't use anything like that. You can use VectorLine.Version to see what version is installed.

--Eric

 

Huum, I think your correct, very strange...do you still keep the demo files, maybe in the Unity 3/4 version, saves me from trying import all the assets into Unity.

 

Yes, The Vectrosity4Demos package contains the Vectrosity 4 demos. Note that the old standard assets won't work with Unity 5.2.

--Eric

 

I've switched to Joins.Fill and it works perfectly now. Thanks!
Any plans to have an option to enable Z calculation for unconventional uses in the future?

 

Not at this point, I'm afraid; I've looked into it before and it's a lot more complicated than it might seem (unless I'm overlooking something).

--Eric

 

Alright, I'll just make do with what's available. Thanks

 

In Unity 5.3f02, the DefaultLine3D material still doesn't work for colored lines. You mentioned earlier that we need to write our own shaders to make Vectrosity 5 work, can you give an example of the shader code or better, include a shader in the next release?

 

That was solved by using UI/Unlit/Transparent, which is what Vectrosity has been using by default for quite some time, but I had a last-minute issue where I discovered that no longer works in Unity 5.3 (specifically, being invisible). So I had to substitute something that at least showed up. Probably Particles/Additive would have been better, since that does use vertex colors.

--Eric

 

"GUI/Text Shader" seems to work, but I don't know how long that will be around; it's the text shader for the legacy GUI system rather than the new one.

Particles/Additive isn't what you'd want since that adds the colors and makes it overall brighter. "Particles/Alpha Blended Premultiply" seems to work though.

 

I'm having trouble getting a 3D line to appear on screen. Is there something obvious I'm doing wrong?

Code (csharp):

1.  
2. void Start ()
3.     {
4.         grenade = transform.parent.transform.gameObject;
5.         List<Vector3> curvePoints = new List<Vector3>();
6.  
7.         Vector3 anchor1 = grenade.transform.position;//0 anchor
8.         Vector3 control1 = (grenade.transform.position + Vector3.forward * 2.5f) + Vector3.up * 3f;
9.         Vector3 anchor2 = grenade.transform.position + Vector3.forward * 10f;//2 anchor
10.         Vector3 control2 = (grenade.transform.position + Vector3.forward * 7.5f) + Vector3.up * 3f;
11.         points = new List<Vector3>();
12.         points.Add(anchor2);
13.         points.Add(control2);
14.         points.Add(control1);
15.         points.Add(anchor1);
16.  
17.         myLine = new VectorLine("GrenadeLine", points, 2f, LineType.Continuous, Joins.Fill);
18.         myLine.SetColor(Color.green);
19.         VectorLine.SetCamera3D(Camera.main);
20.         VectorLine.SetCanvasCamera(Camera.main);
21.         myLine.Draw3DAuto();      
22.     }
23.  

 

I tried that and it works fine. Make sure the camera is positioned where it will be able to see the line. Speaking of cameras, you can remove the SetCamera lines since it uses Camera.main by default anyway.

--Eric

 

Oh I attached my script to the camera itself and it works fine now.

 

Hi, I recently updated to 5.2 from 5.0. I use Vectrosity for debugging projectile and melee traces and visualization of chunking (basically debug stuff in game). The 3d line colors do not seem to work anymore (it always shows white) (using SetLine, either as a param or just setting the color explicitly on the created VectorLine).

Also, I tried adding endcaps into the 3d lines for the first time, and for the life of me I can't get them to show up (after registering the endcap with your demo textures, and then setting the endcap to the result of SetLine). Do they work in 3d?

Note: Unity 5.2.3

 

Scroll up a bit and see the last few posts or so.

SetLine is for basic 1-pixel lines, so endcaps would not be visible. In most cases you should create a VectorLine object with the desired pixel width etc.

--Eric

 

Hi Eric,

How hard is it to use this in World Space?

I noticed that if I convert the generated VectorCanvas to a Screen Space Camera object, then to a World Space object, it does draw pretty well.

I need to hook up some objects with lines between them at runtime. But I really don't like the quality of the 3D lines. Can I draw into a VectorCanvas with it set to World Space?

I didn't see any demos of exactly that, so I thought I'd just ask in case there's a reason you didn't make one

Thank you,
-Chilton

 

Use Draw3D to draw lines in world space. There's no difference in quality between Draw and Draw3D.

--Eric

 

I'm thinking of the smooth curves in the _curves scene.

Can that be done in 3D as well? I don't mean with the handles, I'm just curious if I can create a 3D curve, of course

-Chilton

 

It's the same in 3D as 2D, except 2D uses a canvas and 3D doesn't. That only affects the exact method used for display, not how it looks.

--Eric

 

Is there any way you can set the parent the game objects created by 3d lines use? I.e. I want to move the mess of lines I create when debugging out of the scene root.

I tried drawTransform, but it looks like just a proxy, i.e. presumably you just run a lateupdate somewhere and update the lines based on the transform, but do not parent them to it.

 

Use VectorLine.rectTransform.

--Eric

 

Hi Eric!
How can I draw the line under UI and solider units?

 

Change the Vectrosity canvas to use screen space - camera and set the plane distance as appropriate.

--Eric

 

Hi Eric!Another question.
Why the line end disappeared.And I found a error in VectorLine.cs:1688.
The line type is LineType.Continuous, Joins.Weld.