Vectrosity - Fast and Easy Line Drawing

So, I added a 2nd " yield return null;" line
Now I have two lines " yield return null;" on lines 47 and 48

The error still occurs ... :-/

Fred

 

Hi, I need to do some specific graphs and im wondering if I could do them with this library.
I need to do a 3D plot like this one.

That image is from the plot on Matlab (that's why it is deformed), in my case I have a Julia backend and i want to plot those points in my Unity front end. But as I have to plot I can't use the world space x,y,z, Is there a way to do a plot like this?

Also I need to add another graph, it's almost the same idea but with the adition that i need extra lines around the first one.


Thanks

 

I'm testing with the code you posted and the error doesn't occur here with that change. What happens if you try using Visibility.Dynamic in ObjectSetup?

Yes, there's a LineType.Points option.

Sure, Vectrosity will draw whatever line you want, as long as you supply the points for it. There are also functions for curves/splines to make that easier.

--Eric

 

The error does not occur anymore, and I can see every VectorLine I create.
May I precise that objects that raised the error where not visible at creation ?
To be precise, I draw polygons on the surface of a sphere. The ones that are visible at creation do not raise error. The others do. (When using Visibility.Static)

 

The fix for Visibility.Dynamic was the same fixed I just posted for Visibility.Static, so if the former works the latter should also work (and does here, as I mentioned). It needs to wait an extra frame in Unity 5.6 because they put in some restrictions about accessing the renderer.

--Eric

 

Actually, this is not true in my case : even without the additional "yield return null;" line, there is no raised error using Visibility.Dynamic
So, for now, I still have the problem using Visibility.Static

Again, thanks for your support !
Fred

 

Hey, is there a way to plot lines and have the sensation of depth? Because sometimes and you can see in the video, when I render different lines it looks like it doesn't has depth.

Thanks

 

If you're referring to perspective, no, Vectrosity is intended to have consistent camera-facing pixel thickness lines.

--Eric

 

How could I change the line to don't look like paper?

 

I'm not really sure what you mean. Can you explain in more detail?

--Eric

 

I want to make the line looks like those red and yellow lines.


The ones I have looks like this ->

 

You'll have to use something else; Vectrosity is really not meant for anything like that, sorry. Those are full 3D objects, not lines.

--Eric

 

Hi Eric!

I email you via your website (but i keep feeling i didn't successfully send, so I ask here too)
I have a 2D line drawn on sorting order 3, and a big Canvas background image drawn at sorting order 3000.
The line renders behind the canvas in Unity editor perfectly.
But on IOS, the line is always above the Canvas?!
Would you have an idea what it could be?

(Heres some screen caps!)
https://drive.google.com/open?id=0B5ar8Hfz9lT5Ml9lTGVfdmNlQ0U

 

Hi, just to confirm, you set VectorLine.canvas.sortingOrder? If so, then it sounds like a Unity bug, since canvas sorting should work the same on all platforms.

--Eric

 

Ya its VectorLine.canvas.sortingOrder.. Im using Unity 5.3.8
damn.... ok.. I guess I'll have to test out some other Unity versions then >.<

 

5.3 is pretty old; the current version of Vectrosity requires 5.4 or later.

--Eric

 

Hi Eric!

First of all I'd like to thank you for your work with Vectrosity, I think it's an awesome asset.
I have a question on it, performance-wise is it better to use MakeRect to update lines or to move points with vectorLine.points2[] = new Vector2(x, y)? I don't remember if I've read somewhere that the Make method destroys lines and recreates them.

Thanks in advance!

 

Hi Eric,

Do Vectrosity 3D lines work well with VR or are there any limitations? I am interested in Google VR in particular, and I know it doesn't render screen space objects, so the Vectrosity lines would have be using some world space rendering.

(I tried searching this thread for the answer, but the forums don't like "VR" it says it is too short a string.)

Many thanks!

 

No Make* methods destroy lines, they just update the points. So if MakeRect makes your code simpler, you should use that.

Vectrosity lines do use world space, if you use Draw3D. I've heard from people using Vectrosity with VR but I can't verify it personally.

--Eric

 

Hey Eric!

I've bought Vectrosity quite some time ago and am finally getting around to implementing it in my game. Unfortunately, I'm facing a weird issue where VectorLines I create using

Code (CSharp):

1. VectorManager.ObjectSetup(lineObject, line, Vectrosity.Visibility.Dynamic, Brightness.None);

fade out the closer they get to other meshes. I want them to retain full visibility regardless of where they're situated in comparison to other meshes though. Is there any setting I need to change to do just that? To be clear, this is what the fading out looks like:



Another note: I'm not changing the colors of the nodes in any way.

Would be great if you could help me out!

 

Well, that's a new one...there's no fading in Vectrosity like that by default; you'd have to use SetColor specifically. Since you're not doing that, maybe a shader thing if you're using a custom material/shader? If not, try removing objects from the scene temporarily just to see if they're having some kind of effect. Also, I'd suggest not using ObjectSetup, since that's intended for making objects use Vectrosity as a renderer and it doesn't look like that's appropriate for this case.

--Eric

 

Here's where it gets interesting. It *has* to be some sort of distance based shader, but I'm not applying any special material to the line (neither textures for now). Here's with the terrain enabled and disabled. Note that in the third picture, it's also (albeit only slightly) affected by objects I placed there, so it can't be the terrain either. If you don't have any other ideas, I'll try getting some lines into a new scene and see what happens there.





As for your remark regarding ObjectSetup, the Line object is actually separate (child) from the node objects. I'm using ObjectSetup so lines change position depending on their GO's transform, is this not the correct approach in this case?

 

I'm just guessing here, but do you have "Soft Particles" turned on? If I remember correctly the default line material uses a particle shader and "Soft Particles" will fade when intersecting with scene geometry.

 

No, use VectorLine.drawTransform instead.

Ooh, good catch. Totally forgot about that.

--Eric

 

Hi, Vectrosity has been a lifesaver so far but I'm having a small problem. Apologize if the answer is obvious.

I'm working on a system of draggable nodes that will programatically redraw the lines between themselves to account for the nodes being moved. The way I'm doing it is probably horribly inefficient but there aren't planned to be that many nodes at a single time, and there's not much else going on in the scene.

This script I have is half working. A node can be targeted by any number of other nodes, and when dragged, all the lines redraw correctly and it looks great.

However when a node has multiple targets, only the first target line draws correctly, all the others are drawn once and then frozen. Any idea what could be causing this? Script is below. This script is attached to every node btw.

Code (csharp):

1.  
2.     public GameObject[] targets;
3.     public GameObject[] targetedBy;
4.     public VectorLine myLine;
5.  
6.     void Start () {
7.         for (int i = 0; i < targets.Length; i++) {
8.             myLine = VectorLine.SetLine3D(Color.black, transform.position, targets[i].transform.position);
9.             myLine.Draw3DAuto ();
10.         }
11.     }
12.  
13.     public void OnDrag(PointerEventData data) {
14.         // Change position of dragged node
15.         Vector2 mousePos = Camera.main.ScreenToWorldPoint(data.position);
16.         transform.position = mousePos;
17.  
18.         // Tell targeting lines to reload their target endpoints
19.         for (int i = 0; i < targetedBy.Length; i++) {
20.             targetedBy[i].GetComponent<Node> ().SendMessage ("ReloadTarget");
21.             targetedBy[i].GetComponent<Node> ().SendMessage ("ReloadPosition");
22.         }
23.  
24.         for (int z = 0; z < targets.Length; z++) {
25.             targets [z].GetComponent<Node> ().SendMessage ("ReloadTarget");
26.             targets [z].GetComponent<Node> ().SendMessage ("ReloadPosition");
27.         }
28.  
29.         // Tell own target lines to reload their startpoints
30.         ReloadPosition ();
31.         ReloadTarget ();
32.     }
33.  
34.     public void ReloadTarget() {
35.         for (int i = 0; i < targets.Length; i++) {
36.             Vector3 targetPoints = targets[i].transform.position;
37.             myLine.points3 [1] = targetPoints;
38.             myLine.Draw3DAuto ();
39.             Debug.Log (i);
40.         }
41.     }
42.  
43.     public void ReloadPosition() {
44.         Vector3 thisPoints = transform.position;
45.         myLine.points3 [0] = thisPoints;
46.         myLine.Draw3DAuto ();
47.     }
48.  

Thank you in advance for any guidance. Solution is probably obvious but it's been a long couple of weeks.

 

Draw3DAuto should only be called once when the line is created, also you should call the functions directly instead of using SendMessage. (Also just assign the points directly instead of making variables and assigning the variables, since that's an unnecessary extra step.) However that's unlikely to have any effect on the actual problem; I don't see right away what it might be. Try making extra debug statements so you can follow all the details of what's happening.

--Eric

 

Hi Eric,

Thanks for your reply. I took some of your advice and refactored the script into the following and now it does just what I need. Figured I'd share the solution:

Code (csharp):

1.  
2. public List <VectorLine> receivedLines = new List <VectorLine>();
3.     public List <VectorLine> sentLines = new List <VectorLine>();
4.  
5. public void OnDrag(PointerEventData data) {
6.         Debug.Log ("Dragging");
7.         Vector2 mousePos = Camera.main.ScreenToWorldPoint(data.position);
8.         transform.position = mousePos;
9.         foreach (VectorLine o in sentLines) {
10.             o.points3 [0] = transform.position;
11.         }
12.         foreach (VectorLine o in receivedLines) {
13.             o.points3 [1] = transform.position;
14.         }
15.     }
16.  

Now instead of the previous redundant mess, whenever a line is created it's put into a list on each node so the nodes know whether they're the origin or the destination point, then when they're dragged, they can change that value on each connecting line accordingly. Hasn't bugged out so far so hopefully this will work.

Thanks for your advice and for creating this plugin, it's been a great help.

 

Hi @Eric5h5

My puzzle game "noded" is just released and I wanted to let you know as all the lines in the game are made with Vectrosity, thanks for the great asset

 

That looks cool, great style!

--Eric

 

Hey, Any known problems (or fixes needed for 2017.02)? I'm just trying beta 6 and getting some odd errors. I've not investigated much yet but stacks are all Vectrosity so thought to put the question out there while I investigate in case someone says "oh, didn't you see that message that mentions 2017?" (I did search but didn't find mention.)

TIA

EDIT: p.s. It was working in 5.6.2. I upgraded and started seeing these errors.

 

OK, so regarding the first error, Mesh.Clear() parameter is no longer optional. Guess I'll switch to using Vectrosity source and fix.
2017.01 (and before) vs. 2017.02

 

I don't think I've tried it with 2017.2 yet; it's fine with 2017.1. Thanks for the head's-up!

--Eric

 

Hi! I've been trying out Vectrosity for the first time today, and I wondered if I'm examining the demo scenes wrong. Most of them have no vector lines in editor mode, spawning them in play mode, - so I tried scene view editing of lines in play mode, and immediately encountered these errors:

Code (csharp):

1.  
2. InvalidOperationException: This cannot be used during play mode.
3. UnityEditor.SceneManagement.EditorSceneManager.MarkSceneDirty (Scene scene) (at C:/buildslave/unity/build/artifacts/generated/common/editor/EditorSceneManagerBindings.gen.cs:165)
4. VectorObject2DEditor.UpdateLine ()
5. VectorObject2DEditor.OnSceneGUI ()
6. System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Reflection/MonoMethod.cs:222)
7. Rethrow as TargetInvocationException: Exception has been thrown by the target of an invocation.
8. System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Reflection/MonoMethod.cs:232)
9. System.Reflection.MethodBase.Invoke (System.Object obj, System.Object[] parameters) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Reflection/MethodBase.cs:115)
10. UnityEditor.SceneView.CallOnSceneGUI () (at C:/buildslave/unity/build/Editor/Mono/SceneView/SceneView.cs:2392)
11. UnityEditor.SceneView.HandleSelectionAndOnSceneGUI () (at C:/buildslave/unity/build/Editor/Mono/SceneView/SceneView.cs:1721)
12. UnityEditor.SceneView.OnGUI () (at C:/buildslave/unity/build/Editor/Mono/SceneView/SceneView.cs:1553)
13. System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) (at /Users/builduser/buildslave/mono/build/mcs/class/corlib/System.Reflection/MonoMethod.cs:222)

I suppose vector line editor code either shouldn't attempt to mark scene dirty if Application.isPlaying bool is true or it should lock away editing gizmos at play time.

 

That's true...honestly I never thought to manipulate lines in the scene while in play mode. Yeah, it's not something you're supposed to do.

Edit: on second thought, it wouldn't actually hurt anything, so just not marking the scene dirty as you say would be fine.

--Eric

 

@Eric5h5
Thanks!

Very satisfied with Vectrosity so far, started replacing all line drawing in our game with vector lines powered by it.

• http://i.imgur.com/DBxoV6F.gifv

I don't use native Unity UI, so I don't know much about canvas-related parts of Vectrosity, but world-space 3D line drawing works very nicely so far. I wonder if you could clarify a few more things. For instance:

• When you assign a material to a line using VectorLine API, is it intended behavior that Vectrosity directly edits the passed Material asset in the project, removing textures from it? I know it's possible to assign Textures to _MainTex property of line material using special methods provided by your API, but editing source project files from Play mode seems like unintended behavior to me.
• The gif above depicts a world-space 3D line composed from 2 to 15 world positions (with interval of about 3m), each with exactly identical height (Y component), with joining of segments disabled (line consists of individual quads). It's converted to a spline line with 5 segments per point. I wonder why, when Weld joining is enabled on that line, some of it's vertices sink into the ground or jump up and down erratically from certain camera angles? This only happens from certain camera angles, and it is not caused by missing 3D camera - line faces correct camera and scales properly at every frame, it's just that it sinks from certain angles when welding is enabled.
• How can I approach making world-space lines with fixed world-space width? In other words, setting line width explicitly in world units and disabling it's scaling based on camera. That might be useful, for example, for drawing world-space arrows which are meant to remain stable.
• To add to that case - how can I approach making world-space lines with billboarding disabled? That is, lines facing up (or, even more preferably, facing in a direction dictated by a parent GameObject). That would be useful for making world-space displays with vector-lines on them, on maps meant to be viewed from different angles and in other contexts where billboarding is undesirable.
  
• What is the proper way of fetching the GameObject housing the vector lines?
• If line GameObjects are safe to handle, is it safe to parent them and enable/disable their parents to control visibility of line groups? For example, I might want to create a group of lines visualizing data A (e.g. sight lines to enemy units), another group of lines visualizing dataset B (e.g. trajectories of movement) and to switch them on and off depending on my needs without creating them on the spot. It should be safe to just parent them to two empty GameObjects and switch those parents on and off, right?

P.S.: Bonus gif showing more lines used in different contexts:

• http://i.imgur.com/049NNaN.gifv

Having a lot of fun with this!

 

1) It's intentional (or at least a side-effect of the way it works), but not obvious, sorry about that. I'll clarify in the docs that materials should be instantiated, and the instance used for VectorLine.material, with 3D lines or else the material in the project is altered.
2) Since lines are camera-facing, points are altered when welding to make sure it looks correct from that perspective, which can cause changes in coordinates. Basically VectorLines aren't meant to lie flat on the ground. That said, I didn't see anything unusual in the gif.
3 + 4) That's opposite of what Vectrosity is intended for, so there isn't really a good way, sorry.
5) VectorLine.rectTransform.gameObject.
6) Altering VectorLine GameObjects is discouraged since it often interferes with Vectrosity behavior. It's better to use the Vectrosity API for stuff (e.g. VectorLine.active).

Thanks!

--Eric

 

Hello,
I have a question. Can this do an effect like a pencil line?. A drawing effect?. And if it can is it cpu intensive?.
Thanks.

 

If you mean something like this, then yes. How CPU-intensive it is depends on how many points you update and how often. (In that example, CPU usage is very minimal.)

--Eric

 

@Eric5h5
Is there a way to pool the lines and modify them after creation, instead of destroying/creating them on each use? For example, I'd like to create N circular lines with a fixed number of segments and then simply reposition them and change their radius from time to time, without paying any performance penalties from object instantiation and destruction.

Am I correct in assuming that methods like MakeSpline and MakeCircle simply move around the points used as foundation for the line mesh generator? If so, they are probably safe to call multiple times provided you do not request a different point count/resolution every time, which would allow me to pool everything nicely.

____

On another subject, are there any hidden issues with creating 3D VectorLine objects without ever calling Draw* methods on them? I'm trying out VectorLine splines as a way to drive unit trajectories and weapon trajectories, so I wonder if there are any tips for handling data-only non-rendered lines I might not know. Here is an example gif with spline-driven missile trajectories:

• http://i.imgur.com/bJYweCL.gifv

 

Destroying/creating lines isn't recommended; change the points in the line instead (adding/removing points is fine too). The Make* functions never destroy anything but only change points. I don't know of any issues with un-drawn lines...I wouldn't have thought of using Vectrosity for splines like that, but hey, if it works then go for it. (The game's looking really nice, btw.)

--Eric

 

Awesome, I love it when assets are developed with GC/pooling in mind. I'll use Make* functions a lot more then, glad to hear it's a viable route.

On a slightly related note, am I correct in assuming that animating lines is also best done with Make* functions? For example, if I want a circular orbit to grow to full size over time, starting with a small radius, I can just tween using a function calling MakeCircle with different values, right? That seems to be the best way to keep the line drawn correctly, since crude transform rescaling would naturally break camera projection compensation and screen-relative width.

P.S.: Thanks for your kind words!

 

Hell yeah, Make*-driven animation works great!

• http://i.imgur.com/GtURfyT.gifv

 

The Make* functions are just for convenience, so you don't have to write your own code for circles etc.; they don't do anything that user scripts can't do just as well. (And yes, anything I have on the store is specifically for a production environment, where it's as efficient as I can make it with no allocations unless absolutely necessary.)

--Eric

 

By the way, I forgot to say scaling a line can be done by using VectorLine.drawTransform, and scaling that transform. An empty GameObject is fine for that. Or VectorLine.matrix if you want to use a transform matrix directly without involving GameObjects.

--Eric

 

Ah, so accessing drawTransform for scaling won't disrupt screen-relative line thickness and camera billboarding. Nice to know!

 

Hello Eric,
I just migrated today from Unity v5.6.2 to 2017.2b08 (Vectrosity v5-4-2), and I've got an error now with Vectrosity after the migration, in the Update() :

MissingMethodException: Method not found: 'UnityEngine.Mesh.Clear'.
Vectrosity.VectorLine.Resize ()
Vectrosity.VectorLine.Resize (Int32 newCount)
InitScenew.Update () (at Assets/DemoScripts/InitScenew.cs:3974)

where the line 3974 contains :
line.Resize (selectIndex1 * 10); (line is a VectorLine)

Thanks,

 

See above.

--Eric

 

Did you succeed to solve the error ? I didn't find the right way to fix it in the source. Could you post the fix please ?

 

Hi, did someone find how to fix this error ? It raises multiple times when my application quits AND when I'm using Vectrosity. If I use another 3d line manager, the error does not raise.

 

Do you have any example code that results in this happening?

--Eric