Vectrosity - Fast and Easy Line Drawing

Thanks for the reply.
I probably need to look more into it when I find some time, but from what I've understood, in "2d mode" it draws on canvas not in world view, which makes it bit hard to design games sometimes.

 

Hi, thanks a lot for your reply. I installed the v5.3 and the error went away, sorry..my mistake..

I also made some progress on my beforementioned issue and managed to set up another canvas with ScreenSpace.Camera set to my main camera.

Now I have a different problem, though. When the game is not in 16:9 ratio (it's a 2d game), I rescale the main camera and letterbox the top and bottom with black boxes. This happens in Awake() on a Script attached to the camera.

Since I have the Vectrosity canvas for my line set to ScreenSpace.Camera, this screws up my positioning for the line somehow and I couldn't figure out how to avoid or fix this.
I set the Start and End Point of the line to points in the world space but as soon as I have a non 16:9 ratio camera it screws up the positioning, meaning it offsets the line about an inch to the top..

This issue does not occur when I use ScreenSpace.Overlay.

Any ideas?

 

I tried this and it seems to work fine with a ScreenSpace.Camera canvas. (Using AspectUtility.screenWidth / screenHeight rather than Screen.width / height for coords.)

--Eric

 

Hi!

Saw this product and wondering if it was possible to have custom end caps for the lines such as the example below? Looking for a easy way to draw lines to show the directions of ball movements in a sports sim!

 

I assume this is talking about the green lines? The most effective way to do that type of cap would be to have separate objects for the lines and caps, where you'd use LineType.Points for the caps.

--Eric

 

I'm a happy new user of Vectrosity. I am getting some strange behavior though when I have my Joins set to Fill. Here's an example where it should draw a 'V'.



I double checked my points to ensure I wasn't passing anything strange.



It does not produce the strange artifacts that point toward the origin when I use Join.None or Join.Weld. I'm using Unity 5.3.2f1 on Mac OS X 10.11.6, and this isn't a big stumbling block to my work since I have a workaround.

Thank you for your time and software.

 

Hi, can you post your points as code so I can test it, thank you.

--Eric

 

Hi Eric, is there any way to set segments active false/true instead of the whole line?

 

Probably the simplest way is to use SetColor to set a segment to a transparent color.

--Eric

 

Hi Eric,
as wrote also in the specific topic, i'd like a little guide to obtain an eraser tool with Vectrosity.
I have set the depth mask as line material and added the extra camera (depth only). I'd likee to know how to modify the draw script. So far i'm not seeing the texture erasing while moving around with the mouse.

Thanks

 

Thanks for the reply, I've already done that. I was looking for a way to utilize the performance savings of it when using a single discrete line with unneeded segments. I guess I'll stick with what I have as using separate lines is slower even with the active false/true function.

 

Rendering some transparent segments isn't really a performance concern; I wouldn't worry about it.

@RavenTravelStudios: the draw script isn't modified aside from adding the material; it's just the shader. Try making sure you have the material/shader working properly with some other object first. If that works, I'd need to know more about what your setup is.

--Eric

 

Thanks Eric.

Here's what i did so far:

1) I started from DrawLinesTouch sample
2) Switched Vectorline material to Depth Mask
3) The supplementary cam with Depth only field is set automatically when i start to draw.
4) I put a texture to the supplementary cam but moving around on with the mouse doesnt erase it

Please tell me what i have to do more for obtaining the eraser tool you put out in your web demo.

Thanks!

 

Are you using a 3D line? I'm not sure if it works with a canvas. Also, did you test the setup with some other object and not Vectrosity to make sure you have it correct?

--Eric

 

Hi Eric,

I have a 3d grid drawn in Vectrosity 5, with an orthogonal camera. It looks great until I lerp the projection matrix for the camera to a perspective view. Once this is done, the gridlines have a different thickness depending on the camera's rotation. Sometimes the grid looks good, but at certain rotations parts of the grid completely disappear, even though the camera is close to the grid and is pointed straight at it.

Is there a way to get the Vectrosity grid to appear uniform given my camera's perspective? For example, can I apply a projection matrix to the grid to match the camera, or is there a particular material/shader I can use to achieve the desired effect?

Thanks!

 

Have you redrawn the line after changing the projection matrix?

--Eric

 

Yes, the grid is drawn after the camera changes perspective. The problem appears to be with how the lines display with a perspective camera at different angles. Is there some issue with Vectrosity displaying lines with a perspective camera?

 

Actually, I can reproduce the problem with an orthogonal camera if I alter the camera's height while I rotate it around the map.

 

It's fine with a perspective camera; pretty much all the demos use a perspective camera for example. Perhaps the custom projection matrix is interfering with Camera.ScreenToWorldPoint and/or WorldToScreenPoint, since Vectrosity relies on those for 3D lines. If that's the case unfortunately I don't know if there's anything I can do.

--Eric

 

Regarding the orthographic camera, I changed the camera in the 3D grid example to use orthographic, and it seems to be fine when moving the camera around.

--Eric

 

Hi Eric,

I wrote my Vectrosity code a long time ago, and didn't realise I need different versions of the libraries for different versions of Unity. Perhaps if I rewrite my code to use the latest library then it will fix the rendering issues.

Thanks for your help

 

Yes, I would recommend using Vectrosity 5.3.

--Eric

 

Hi Eric,

The new libraries fix my problem with lines sometimes appearing very thin depending on the camera's rotation.

Incidentally, I think the previous problem was related to the fact that Vectrosity's 3d lines are planes. If the camera is moved so that some of the planes are viewed from side on, then the lines appear very thin, whereas the lines appear fat if the surface of the planes can be seen. Perhaps the camera is supposed to rotate the planes so that the surfaces are always facing the camera? Either way, the newest version of Vectrosity doesn't have this problem.

Thanks for your help

 

Yes, when you use Draw or Draw3D, the lines are updated so they face the camera.

--Eric

 

Hi Eric,

How do you create a new LineManager? It seems like one is automatically created when you create/draw your first line, but then if the LineManager is removed I can't see how to create another one.

Thanks

 

I would recommend not destroying the LineManager. It uses DontDestroyOnLoad so it survives scene changes.

--Eric

 

Thanks Eric. I can do this if necessary, but it isn't ideal because of how I've designed my object hierarchy... Is there a way to create a new one?

 

Not easily, sorry. It doesn't affect anything else to have it in the scene so it's best to leave it alone. It should be fine to make it the child of another object if you want, though I haven't tested it.

--Eric

 

Hi Eric,
I've got a question. In Unity Editor my solution works fine, but I can't see the lines on Android/iOS. I made some debug outputs and see that on the mobile phones I cant find the "drawLine.vectorLine.rectTransform".
Any idea how that can happen?

Also in the Editor I can see the "Go" above the "RectTransform" entry. But I can't access it with "drawLine.vectorLine.Go". Why's that?
How can I get the a reference to the created vectorLine object on mobile (rectTransform, gameObject, or something else)?

I create the VectorLine in a script:

Code (CSharp):

1. vectorLine = new VectorLine("vectorLine_" + this.gameObject.name, linePoints, lineWidth, LineType.Continuous);

Part of my code:

Code (CSharp):

1. private bool GetVectorLineMeshRenderer() {
2.     if (drawLine.vectorLine.rectTransform != null) {
3.         vectorLineMeshRenderer = drawLine.vectorLine.rectTransform.GetComponent<MeshRenderer>();
4.         if (vectorLineMeshRenderer != null)
5.             return true;
6.         else
7.             return false;
8.     }
9. }

Code (CSharp):

1. if (GetVectorLineMeshRenderer())
2.     vectorLineMeshRenderer.material.SetColor("_Color", new Color(1.0f, 1.0f, 1.0f, 1.0f));

Debug output to see what's wrong:

Code (CSharp):

1.  
2. if (drawLine.vectorLine != null)
3.     main.debugTextManager.AddText("1. drawLine.vectorLine.rectTransform: " + drawLine.vectorLine);
4. if (drawLine.vectorLine.rectTransform != null)
5.     main.debugTextManager.AddText("2. drawLine.vectorLine.rectTransform: " + drawLine.vectorLine.rectTransform);
6. else
7.     main.debugTextManager.AddText("2. drawLine.vectorLine.rectTransform not found");

1. output is fine, then in 2. I get "not found" on mobile devices.

Thanks

 

No, sorry. Vectrosity has no conditional code for different platforms and does not use any features that are platform-dependent. If anything ever doesn't work on a particular platform, it's a Unity bug and should be reported to them. However I've never seen any issues running on iOS, and the only platform bug I'm aware of is a certain Android model apparently has some kind of issue with non-power-of-two textures that affects end caps. I would be inclined to suspect the code that you're using for creating lines; for example I don't know how you end up with drawLine.vectorLine so it might be something in there. All the demos work fine on iOS, so I'd suggest checking to see what differences you can find between that code and your own.

It's not public (also it's not actually called "Go" but rather "m_go"). Use VectorLine.rectTransform.gameObject.

--Eric

 

EndCap offset Has bug.

offset is 0:



offset is -1



please help to fix it quickly

 

Hi @Eric,
thanks for your input. I tried out some things and saw that the created objects where "thrown into the unity hierarchy".

Code (CSharp):

1. vectorLine = new VectorLine("vectorLine_" + this.gameObject.name, linePoints, lineWidth, LineType.Continuous, Joins.Fill);

So I did the SetCanvas and now it works.

Code (CSharp):

1. vectorLine.SetCanvas(main.canvasManager.canvas);

Still strange that it works in Unity Editor without being under a canvas?
Cheers

 

Do you have a lot of segments? Only the last segment is altered when doing offsets, so if you want it to be pushed back further, make sure the last segment is at least as long as the end cap.

Only 2D lines (made with Draw) use a canvas. Draw3D lines do not use a canvas.

--Eric

 

Ok I double-checked and in the hierarchy there is no difference. I use

Code (CSharp):

1. vectorLine.Draw3D();

so it's a 3D line. But still without using SetCanvas the lines are not visible on mobile devices.
If I find some time I'll make a clean test project and try it out, but right now I don't have time for it.
Thanks

 

Well, there is a difference. With Draw lines are put on a canvas, with Draw3D they are objects in the scene and not on a canvas; do not use SetCanvas for Draw3D lines. Using this code:

Code (csharp):

1. var line = new VectorLine("Test", new List.<Vector3>([Vector3.zero, Vector3.one]), 2.0);
2. line.Draw();

Results in this:



This code:

Code (csharp):

1. var line = new VectorLine("Test", new List.<Vector3>([Vector3.zero, Vector3.one]), 2.0);
2. line.Draw3D();

Results in this:



Lines are visible on mobile devices either way under normal operation. If you're using some kind of custom shader that might be the issue. Also make sure you're using Vectrosity 5.3.

--Eric

 

I am sure is bug. wo I has 30 segments ,
My game arrows has different length. the long line i set DrawEnd to about 25 is ok. the short line i set drawEnd to 15 is ok.
I want set DrawStart to 0 And DrawEnd to 30 the endcap is corrent point to end position. i don't know how calculate the best Drawend count. please Test the Samples. or help me how to current drawend param

 

There isn't a bug, sorry, also nothing to do with DrawStart or DrawEnd. It's a limitation that the last line segment needs to be at least as long as the end cap if you want to move it back its full length, however this is necessary as you will see below. This is specifically mentioned in the documentation about end caps: "Note that moving the offset inward on lines with many very short segments (such as a circle) can result in unexpected behavior. As long as the segment just before the end cap is at least as long as the end cap, though, you’re good." Looking at your picture again, the line appears curved, so I expect the segments at the end are shorter than the end cap and therefore it can't be moved back effectively. To fix this, make sure the last line segment is at least as long as the end cap.

For example, here's a line with no end cap, showing the wireframe to make it obvious:



Since the last segment is longer than the end cap, adding a cap with an offset of -1.0 works fine:



But if the last segment is shorter than the cap:



Then you get this:



You can see that there's no feasible way to make this work. It's not a bug, just math.

--Eric

 

thanks Eric.

ok I learn the theory...
I change my line's segments for 10 ,even 5.. it not solved..
how to make sure the last segment is really long.. my line is always short..
sorry for my bad english.

 

I found my LineWidth is 20.
when i set LineWidth to 9.. is ok. but is too thin。

 

It's not about the number of segments, it's making sure the last segment is at least as long as the end cap. Please refer to the screenshots and explanation above.

--Eric

 

@Eric5h5 Is Vectrosity fully compatible with 5.4?

I've just upgraded to 5.4.1p1 (From 5.3.6) and using Screen Space - Camera canvas does not work properly anymore. Same thing happens if I use my own canvas or use VectorLine.SetCanvasCamera(Camera.main);

Lines are still rendered but off screen and very big...

Screen Space - Overlay or 3D works as expected.

 

You're right, the behavior of RenderMode.ScreenSpaceCamera has changed, and the line mesh is no longer transformed correctly in that case. Unfortunately I can't find any documentation about this change, and there doesn't seem to be any simple solution that I've found so far. I tried looking through the UI source, but unless I'm missing something, base canvas behavior isn't part of that. I'll see what I can do, but for now my suggestion is to have a canvas scaler component on the canvas, and reduce the scale factor so that the line appears correctly, although this will only work if the camera isn't rotated.

--Eric

 

Thank you for your reply & the workaround suggestion.

Currently I've reverted back to 5.3.6p5 as there were other problems, layer orders mixed up, cpu usage went up to 95% (from 50%) for the same project...

 

Just picked up the asset today. Having some trouble getting it to update a line at runtime

//create the new Vector Line
VectorLine vectorLine = new VectorLine("name_doesnt_matter_to_me", points, 2);

//grab the VectorObject2D component - line is a gameobject already in the scene drawing some dummy lines, I just want to change those lines
VectorObject2D lineRenderer = line.GetComponent<VectorObject2D>();

//Update the points
lineRenderer.SetVectorLine(vectorLine, lineRenderer.texture, lineRenderer.material);

I see in the inspector that the Points have updated in the existing object but the line on the screen remains unimpressed by my changes and sticks to its initial shape.

I couldn't find much in the documentation about making changes from code at runtime when using a UI line on a Canvas. If you have docs for that a link should be enough to get me going.

EDIT:
Just to clarify - I have a gameobject with VectorObject2D on a canvas in my scene and I have tested to see that it draws a line they way I like when I give it points. Now I just want to change the points on that same object.

 

See "Updating lines" on page 13 of the coding docs. You should keep a reference around for the VectorLine, or the list of points you used to make the VectorLine. Then simply change the points in the list or in VectorLine.points2/points3. Also please stick to the public API as described in the reference manual; using undocumented APIs like that is unsupported and may break.

--Eric

 

Thanks for the tip since I am also on the Unity 5.4.x also.

 

Eric5h5,

I am having a slight issue with end caps. It seems end caps are not appearing on the ends of each discrete line segment in a particular VectorLine object that I have. Is this the intended behaviour?

Kind regards,

 

End caps are only at the ends of lines, not segments.

--Eric

 

How does Vectrosity compare to the new Unity 5.5 Line/Trail renderer ? I'm certain Vectrosity has better features and is more flexible - but how about performance, could we expect Vectrosity to still be faster?

 

Well, the LineRender has some nice upgrades, but they're still solving somewhat different problems. The LineRenderer is world-space lines with perspective, whereas Vectrosity is fixed pixel-width lines and does 2D screen space as well. (And yeah, still has way more features. ) So it depends on what you're doing; for example redrawing a single 3D line every frame will be slower in Vectrosity. Although not by as much as I expected, since a large part of the CPU usage in that case is spent on converting screen to world points and vice versa, which the LineRenderer doesn't have to do, plus the LineRenderer is native code. I made a couple of comparison scripts that do approximately the same thing (attached to an empty GameObject):

LineRenderer:

Code (javascript):

1. #pragma strict
2.  
3. private var positions : Vector3[];
4. private var totalPoints = 500;
5. private var range = -15.0;
6. var material : Material;
7.  
8. function Start () {
9.     Camera.main.transform.position = Vector3(0, 0, -20);
10.     Camera.main.transform.eulerAngles = Vector3.zero;
11.     Random.InitState (1);
12.     positions = new Vector3[totalPoints];
13.     for (var i = 0; i < totalPoints; i++) {
14.         positions[i] = Vector3(Random.Range(-range, range), Random.Range(-range, range), Random.Range(-range, range));
15.     }
16.     var renderer = gameObject.AddComponent(LineRenderer);
17.     renderer.material = material;
18.     renderer.startWidth = .1;
19.     renderer.endWidth = .1;
20.     renderer.numPositions = totalPoints;
21.     renderer.numCornerVertices = 1;
22. }
23.  
24. function Update () {
25.     var newPos : Vector3;
26.     for (var i = 0; i < totalPoints; i++) {
27.         newPos = positions[i];
28.         newPos.x += Time.deltaTime;
29.         positions[i] = newPos;
30.     }
31.     GetComponent(LineRenderer).SetPositions(positions);
32. }

Vectrosity:

Code (javascript):

1. #pragma strict
2. import System.Collections.Generic;
3.  
4. private var positions : List.<Vector3>;
5. private var totalPoints = 500;
6. private var range = -15.0;
7.  
8. function Start () {
9.     Camera.main.transform.position = Vector3(0, 0, -20);
10.     Camera.main.transform.eulerAngles = Vector3.zero;
11.     Random.InitState (1);
12.     positions = new List.<Vector3>(totalPoints);
13.     for (var i = 0; i < totalPoints; i++) {
14.         positions.Add (Vector3(Random.Range(-range, range), Random.Range(-range, range), Random.Range(-range, range)));
15.     }
16.     var line = new VectorLine("Test", positions, 2.0, LineType.Continuous);
17.     line.Draw3DAuto();
18. }
19.  
20. function Update () {
21.     var newPos : Vector3;
22.     for (var i = 0; i < totalPoints; i++) {
23.         newPos = positions[i];
24.         newPos.x += Time.deltaTime;
25.         positions[i] = newPos;
26.     }
27. }

In this case the LineRenderer is over twice as fast. However I did notice some glitches with some of the line segments kind of jumping around when moving, which is rather problematic. (Bug report time I guess...it seems related to off-screen points, which I sympathize with having struggled with that myself, though Vectrosity is 100% stable in that regards now, as far as I know.)

--Eric