Vectrosity - fast and easy line drawing

Thanks for the fast reply. I don't understand the workaround at the moment. I tried modifying the function that used maxDrawindex to use drawEnd instead, but I'm still getting the sawtooth pattern.

Code (csharp):

1.  
2. function SetMinMaxDrawingIndex(){
3.     trailLine.drawEnd = trailIndex;
4.     trailLine.minDrawIndex = trailIndex-1;
5. }

 

First, I'd like to say that Vectrosity is a superb product, with way more options that I would have expected, plus stellar documentation. I also love that you can pull one little DLL into a project and you've got everything.

What I'd like to do in my game is draw a circle in front of a particular camera's forward vector and set the radius based on world units. I do have a somewhat complicated camera setup, which may be part of why I haven't actually seen a circle yet. I've got four cameras set up to render objects on different layers and all four have different depth values. (in stereoscopic 3D mode it's actually 8 cameras) Basically I start with very far objects and work my way to very near objects (the closest being a first-person cockpit).

I'm using MakeCircle and have tried a number of things, such as VectorLine.SetCamera to be the camera I want, setting the depth and layer values, making the line's gameObject be a child of the movement camera, and passing in the camera's transform to Draw3D(). Rather than get into tons of detail on all of the things I've tried, I'll just ask: What's the proper way to set this up?

Is that even an appropriate use of Vectrosity? I'd consider just using the LineRenderer, if that's an easier approach to this particular scenario.

Thanks!!

UPDATE: After some more experimentation (using Draw() instead of Draw3D() for now), I did get the circle to show up, but not like I expected. The units are all funky. I set it to the camera's position and rotation, but it's pushed out about 300 game units in front of the camera. Normally my far plane on the camera doesn't go anywhere near that, but if I temporarily set it out to 300, I can at least see it.

Is there anything funky with unit scaling in Vectrosity when moving a line's GameObject around?

 

Try also taking out minDrawIndex and using drawStart instead.

In general I'd advise not moving the GameObject around, but instead passing in a transform to use with Draw or Draw3D, and moving that transform. If using Draw, the units are in pixels, and while the lines do exist in 3D space still (somewhere), they aren't intended to be viewed by normal cameras in that case.

--Eric

 

Aha, thank you very much, that was super helpful. Yeah, I created a dummy GameObject and used its Transform to position my circle and used Draw3D(Transform) and now it works perfectly!

 

Hi! I am currently considering using your asset to draw laser lines. I want to know if it is possible to draw 3D lines in the way where some parts of the line could be hidden by any closer object - does 3D sorting work? How many draw calls are required per line? Can I use particle-additive shader? Can I render 3D line (3D means here that it should be sorted with other objects) with independent from distance to camera width? I don't want my laser to become thicker at the opposite end.

Could you provide a video with some in-editor settings/coding demonstration?

Do you sell the full source code or dll only?

Can I use your asset in the webplayer?


Excuse me that I didn't read the previous 112 pages to find the answer

 

Thanks. Unfortunately I don't think that'll work for me here since this gives me just a tiny snub of a tail rather than a growing trail (since drawStart 'erases' all parts of the line before the passed index).

 

Yes, you can draw lines in 3D space where they are occluded by other objects. There's one draw call per VectorLine, and each VectorLine can have many independent line segments if desired. You can use any shader for the line. The lines are always drawn so that the width is consistent; this is actually the point of Vectrosity.

Maybe sometime. Doing video properly is a lot of work and I don't know that it's worth it, what with all the examples I already have on my site.

You get both.

Yes, it works on all platforms (except Flash).

Well, OK, I'll let it slide this time.

You could try leaving .minDrawIndex out altogether. Anyway I'm working on the next version now.

--Eric

 

Im trying to setup "endcap" for my vectorline.

Code (csharp):

1. VectorLine.SetEndCap ("Point", EndCap.Front, lineMaterial, frontTex);
2. line.endCap = "Point"; 
3.  

but I keep on getting this error

Code (csharp):

1.  
2. VectorLine: end cap "Point" has already been set up
3. UnityEngine.Debug:LogError(Object)
4.  

why is that?

 

As the error says, the end cap has already been set up. You only do that once.

--Eric

 

sorry but Im not sure what you mean, Im still at lost here. Sorry again.

 

Page 23 in the docs describes how to use end caps in some detail, and the EndCap demo scene has a working example of using end caps.

--Eric

 

Code (csharp):

1. if (!endCapArrowSet) {// do once ;)
2.     VectorLine.SetEndCap("Point", EndCap.Front, lineMaterial, frontTexture, backTexture);
3.     endCapArrowSet = true;
4. }

Hi Eric,
I am drawing a series of discrete lines that I want to be able to select. Unfortunately, when I iterate through my list of lines, index keeps getting set to -1. I realize it would be difficult for you to evaluate without seeing everything but I am trying to do something very simple like this in Update()...

Code (csharp):

1. if (Input.GetMouseButtonDown(0)) {     
2.     for (var i : int = 0; i < lineArray.length; i++) {
3.         line = lineArray[i];
4.         if (line.Selected (Input.mousePosition, extraThickness, index)) {
5.             line.SetColor(Color.red);
6.         }
7.     }
8. }

Any thoughts?

Thanks for your time!
Craig

 

The index will be set to -1 if Selected returns false. Perhaps you want to use break in the loop as soon as Selected returns true?

--Eric

 

Yeh, I got that from the documentation but it never really sunk in. I have determined my issue was screen points. Thanks for your timely response!

 

New version soon! Here's a demo of one of the new features.

--Eric

 

Finalized changelog ahead, still have to do more testing and updating docs:

Vectrosity 3.0 (yes, this means you can expect some breakage, although nothing major)

Additions:
• VectorLine.GetColor function, which returns the color of a specified line segment.
• VectorLine.SetWidth function, for setting the line width of a specified line segment.
• VectorLine.GetWidth function, which returns the line width of a specified line segment.
• VectorLine.collider property, which adds a 2D collider to a line when drawn. Only works with Draw, not Draw3D. Requires Unity 4.3 or later.
• VectorLine.physicsMaterial property, for setting the PhysicsMaterial2D of the collider. Requires Unity 4.3 or later.
• VectorLine.sortingLayerID and VectorLine.sortingOrder, for getting and setting the sorting layer and order-in-layer of lines. These control the drawing order in the same way that they do for sprites, and can be used to determine the drawing order when lines are mixed with sprites, as well as other lines. Requires Unity 4.3 or later.
• VectorLine.matrix, which is like drawing a line while passing in a transform, except you supply your own matrix. So the way the line is drawn will be modified by the supplied matrix.

Changes:
• Requires Unity 4.0 as a minimum now, and Unity 4.3 for some functions (as mentioned above).
• In the spirit of "just set things once when creating the line and forget about it," some functions and function overloads have been removed and replaced with properties (see the upgrade guide for more details):
- Removed SetTextureScale, and added textureScale and textureOffset properties. Instead of "SetTextureScale (1.0)", do "myLine.textureScale = 1.0", and the texture scale will be set automatically when using Draw(), instead of having to call SetTextureScale manually. Likewise, use "myLine.textureOffset = 0.5" instead of passing 0.5 into SetTextureScale.
- Removed Draw/Draw3D overloads that accept a transform, and added drawTransform property. Instead of "Draw (transform)", do "myLine.drawTransform = transform" after creating the line, and use Draw/Draw3D as normal.
- Removed DrawViewport function and added useViewportCoords property. Instead of "DrawViewport()", do "myLine.useViewportCoords = true" after creating the line, and use the Draw function as normal.
• VectorLine.SetEndCap can optionally take an offset value, which will offset the front and back caps by a percentage of the cap's length. For example, using -1.0 for the offset will subtract 100% of the cap's length, so that the line will be as long as it would have been without the end caps. (Since end caps are normally added to the length of the line, which is what happens if you use 0.0 for the offset.)
• VectorLine.Destroy can accept arrays or generic Lists of VectorLines/VectorPoints.
• A value of 0 for VectorLine.maxDrawIndex no longer means "draw all the points". Instead it's set to "the length of the points array minus 1" by default. Using 0 now means "don't draw any points".
• Removed VectorLine.useMeshQuads, since there was no real advantage to using it, and potential drawbacks depending on the platform.

Fixes:
• Fixed the "fix" for the Joins.Fill/extraneous triangle issue in Vectrosity 2.3, so now it works right (for reals).
• Fixed issue where lines using Joins.Fill with end caps could get messed up in some circumstances.
• VectorLine.SetColor sets end cap colors.
• The VectorLine.GetPoint functions return the correct point if the line is drawn with a transform.
• Lines drawn with Draw3DAuto won't generate error messages when loading new levels.
• Using a texture scale works with 2D lines that are drawn with a transform.
• Using a texture scale works correctly with lines drawn with viewport coords.
• End caps for 3D lines have the correct proportions when using Draw (as opposed to Draw3D).
• VectorLine.maxDrawIndex is clamped properly when setting.
• Updated some demo scripts to work properly when switching resolutions.

--Eric

 

Awesome! Thanks for listening, Eric!

 

Hey Eric,

This is a rather simple question which I'm sure has been asked before...unfortunately the search thread function isn't really working, so I'll have to ask again.

Basically, I don't understand the interaction between Vector lines and other game objects. I wanted to create an octagon that surrounds my player (2D top-down game) as a shield, but I can't get it to follow the player object. I tried doing

Code (csharp):

1. myLine.Draw(player.transform)

which didn't help...the shield rotates along with the player but always stays at the spot where I drew it using MakeCircle. Also: When I give the player.transform.position to MakeCircle, it always draws it at Screen coordinates (0,0). The same happens when I do this:

Code (csharp):

1. void Update()
2. {
3. myLine.vectorObject.transform.position = player.transform.position;
4. }

The shield just does not follow the position of the player, instead it just keeps sitting in the corner. I tried attaching the scripts to both the camera and the player itself, but with the same results.

So basically my question is: How do I change the position of a Vector and make it follow another game object?


Thanks a lot for Vectrosity Eric. I'm still learning and struggling but I can already tell it's an amazing tool.

 

Sounds like you're getting caught in the difference between screen space coordinates and world coordinates. Basically lines drawn with 2D points always use screen space coords, so moving a transform by 5 units, for example, would only move the line by 5 pixels. To fix this for this situation, use 3D points (Vector3). You can still draw 3D points with Draw as an overlay, just like 2D points—lines are only drawn as "real" 3D objects in the scene if you use Draw3D.

--Eric

 

That was exactly it. I just had to use Vector3[] instead of Vector2[] to store my points and voilà. Thanks a lot, Eric!

 

Version 3.0 is out now! See the changelog above. If you bought from my site, you should get a notice by email, if you've subscribed to email notifications. I'll submit it to the asset store next.

--Eric

 

As always, a great product and thanks for providing a very clear upgrade guide, making it totally painless to move to 3.0.

 

I'm getting these everywhere with the update...

Code (csharp):

1. Assets/VectrosityDemos/Scripts/Curve/DrawCurve.js(14,20): BCE0004: Ambiguous reference 'VectorLine': Vectrosity.VectorLine, Vectrosity.VectorLine.

Reverting to keep the workflow moving.

Upgrade sounds great though!

 

Sounds like you have Vectrosity imported twice.

--Eric

 

Yup. Sho nuff.

c:

 

Vectrosity is 50% off on my site and the Unity asset store!

--Eric

 

Any idea when 3.0 will hit the asset store?

 

It depends on how long it takes for them to approve it.

--Eric

 

Vectrosity 3.0 is on the asset store now! There's currently a small potential issue if you're using Unity 4.3: the default DLL is intended for Unity 4.0-4.2, and will cause an error with the CreateHills demo script, if you import the VectrosityDemos package. To fix this, remove the DLL and import the Vectrosity_Unity4_3 package instead, or the VectrositySource package. If you're using Unity 4.0-4.2, then there won't be any problems, so you can ignore this. I just uploaded a packaging update that addresses this issue.

--Eric

 

Is there an easy way to swap line.drawStart with the line.drawEnd?
I'd like to animate part of the line in both ways from start to end and from end to start.

Edit:
I used System.Array.Reverse(line.points3) and it works.

 

I have a question concerning the memory consumption of Vectrosity, and particularly the VectorPoints class which I've been using extensively.

Its behavior when storing object references is very strange to me - there's something there that I just don't understand. I replicated my results in a very simple test setup. Basically, I've got one script:

Code (csharp):

1. using UnityEngine;
2. using System.Collections;
3. using Vectrosity;
4.  
5. public class TestClass
6. {
7.  
8. }
9.  
10. public class VectorPointsMemoryTest : MonoBehaviour {
11.  
12.     VectorPoints[] vectorPointsArray = new VectorPoints[2048];
13.     Vector2[] points = new Vector2[2048];
14.     TestClass[] objectArray = new TestClass[2048];
15.  
16.     // Use this for initialization
17.     void Start ()
18.     {
19.         for (int i = 0; i < vectorPointsArray.Length; i++)
20.         {
21.             VectorPoints newPoints = new VectorPoints("Test_" + i, points, null, 1);
22.             vectorPointsArray[i] = newPoints; // This costs around 470mb?!?!
23.         }
24.  
25.         for (int i = 0; i < objectArray.Length; i++)
26.         {
27.             VectorPoints newPoints = new VectorPoints("Test_" + i, points, null, 1);
28.             TestClass newObj = new TestClass();
29.             objectArray[i] = newObj; // This is for free (no memory increase)
30.         }
31.     }
32. }
33.  

I put this script on an otherwise empty GameObject in an empty scene; it doesn't even have a camera. The scene consists of one GameObject, which has that one script above attached to it.

Notice the second line inside the for-loop, which just stores the VectorPoints object in an array. The behavior I don't understand is that line's memory cost - when run, the process consumes approximately 470 more megabytes of memory, than when that line is commented out. This behavior can be seen both in the editor and in stand-alone builds. This is a total mystery to me. The array to hold the VectorPoints references is globally declared and initialized in the top of the class, so I'm assuming it gets allocated (with a bunch of nulls) by the runtime regardless of what I choose to do with it afterwards. The line,

Code (csharp):

1. vectorPointsArray[i] = newPoints;

just stores an object reference, right? It shouldn't consume memory to replace a null in that array by an actual reference, right? So why does it cost me 470MB RAM to set 2048 object references? It's my understanding that an object reference is basically a wrapper around a pointer, so if the code compiles against 32 bit architecture, I expect the memory cost of that array to be something in the order of 2048*32bit ~ 8kb when it gets allocated, and then no

Interestingly, that behavior is what I get if, instead of VectorPoints, I store references to objects of some class. That is what occurs in the second for-loop. The memory cost remains the same with this line commented in or out:

Code (csharp):

1.  objectArray[i] = newObj;

So, err... what gives? I get the feeling I've missed out on something grossly simple, but I just don't get it this time. ;-) What is it with VectorPoints that has such an incredible cost when storing references to its objects?

PS: I forgot mentioning that memory cost was measured as that of the entire process in Windows' Task Manager.

 

I would assume it's the mesh, since each VectorLine object needs a unique mesh that has one quad for every point in the array, at 108 bytes per quad for the vertices, triangles, UV, and color data. (More if you use normals, and more still if you use tangents.) So for 2048 points, that's 216K per VectorLine for the mesh, and therefore 432MB for 2048 meshes of that size.

--Eric

 

I think you're right it's the mesh. Your calculation seems very plausible. I just don't understand why I incur this cost purely from storing the references in the array. In the test, I instantiated the VectorPoints objects in both cases. It's storing the references afterwards that seems to demonstrate a difference I can't explain.

Edit: Actually, now that I think about it, do you think it's because retaining the reference forces Unity to keep a copy in managed memory which would have otherwise existed solely in Unity's non-Mono part?

 

It's nothing to do with references that I know of; the meshes are always created whether you're using them or not, so you have 432MB allocated for the meshes when you create all those VectorLine objects.

--Eric

 

*nod nod* That was my understanding as well. But... it doesn't get me closer to understanding why storing the reference makes a difference. I call "new VectorPoints(...)" in both cases. The line that just saves the reference has a cost similar to the full 2048 meshes. If I comment that line out (and still instantiate the VectorPoints objects), then memory consumption is noticably 450-ish less.

 

If I run one loop, and then run the other loop, in both cases I get about the same memory increase. Both are creating 2048 VectorLine objects, so that's what I'd expect.

--Eric

 

Okay... That's interesting. I'm a little at a loss then. But it's very possible the code sample I provided doesn't replicate the behavior I'm seeing well enough. In that case, I apologize. I tried to simplify it a bit, but I'm still seeing the memory difference quite clearly. By the way, I feel compelled to say that this whole thing is just me polling your knowledge of computer science. At this point, it doesn't really have anything to do with supporting Vectrosity, which works as intended. So you should feel free to, you know, tell me to bugger off and study some more myself.

If you're interested, however, please try to run this simplified script:

Code (csharp):

1. using UnityEngine;
2. using System.Collections;
3. using Vectrosity;
4.  
5. public class VectorPointsMemoryTest : MonoBehaviour
6. {
7.     VectorPoints[] vectorPointsArray = new VectorPoints[2048];
8.     Vector2[] points = new Vector2[2048];
9.  
10.     void Start()
11.     {
12.         for (int i = 0; i < vectorPointsArray.Length; i++)
13.         {
14.             VectorPoints newPoints = new VectorPoints("Test_" + i, points, null, 1);
15.             vectorPointsArray[i] = newPoints;
16.         }
17.     }
18. }

When I do that, the process takes up this much memory:



Next, please try to run this:

Code (csharp):

1. using UnityEngine;
2. using System.Collections;
3. using Vectrosity;
4.  
5. public class VectorPointsMemoryTest : MonoBehaviour
6. {
7.     VectorPoints[] vectorPointsArray = new VectorPoints[2048];
8.     Vector2[] points = new Vector2[2048];
9.  
10.     void Start()
11.     {
12.         for (int i = 0; i < vectorPointsArray.Length; i++)
13.         {
14.             VectorPoints newPoints = new VectorPoints("Test_" + i, points, null, 1);
15.             //vectorPointsArray[i] = newPoints;
16.         }
17.     }
18. }

When I run that, the process takes up this much memory:

http://imageshack.com/a/img42/7184/zijl.png

That's a memory drop roughly corresponding to the amount you calculated for the allocated VectorPoints. But it results purely from not storing the references. The lines themselves are still created. I can't explain that, unless it's got something to do with what Unity keeps in managed memory.

 

With your code, both scripts report the same memory usage with the profiler, and Activity Monitor shows the same memory usage for Unity, which is what I would expect. So unless it's somehow a Windows thing for some unknown reason, I don't know what else to say. But yeah, should probably make a new topic at this point.

--Eric

 

Sure thing. I'll try that and see if I can get someone with a windows machine to reproduce the results. I wouldn't be too surprised if it's an OS thing. Thanks for your time!

 

Hi Eric,

I'm currently trying to (do the oh-so-common) follow a path and erase behind it, and I'm at a loss. Functions to get points all seem to return Vector2s (e.g. GetPoint()) rather than indexes, so I can't update the line.drawStart relative to the player's position along the line. Ideally I'd love something along the lines of:

Code (csharp):

1.  
2. int GetPointIndex01(float distance){
3.     return closestPointIndexRelativeToNormalisedDistanceAlongLine; // Pretty incredible variable name, you can use it if you want ;)
4. }
5.  

Is there a function like this built in in some form? I could obviously increment the drawStart based on a time I manually match to the player's speed, however that seems like a slightly messy work around.

Any help is appreciated!

 

Additionally, in trying to implement the temporary solution I hinted at above, firstly it seems that GetPoint01()'s normalised measurement is based off the entire possible line, rather than the drawStart/End positions. So if I don't draw all 500 points, let's say I only draw 250, then dist will only get to 0.5 when it has reached the end.

Likely related, I've noticed something happens with the line calculations when updating the drawStart and not initiating SetDistances().

Code (csharp):

1.  
2. if(dist < 1.0){
3.     dist += Time.deltaTime * speed;
4.  
5.     Vector2 splinePoint = line.GetPoint01 (dist);
6.  
7.     transform.position = GetWorldPoint(splinePoint);
8.  
9.     // Without the below, the above works as expected, the object follows the path and stops at the end.
10.  
11.     currentLineIndex += Time.deltaTime * lineEraseSpeed;
12.     line.drawStart = (int)currentLineIndex;
13.     line.Draw();
14. }
15.  

My understanding of drawStart means that it should shorten the line visibly, but without running SetDistances(), my calculated line length should remain the same, so my gameObject should reach the end of the line and stop, no matter what happens to the line before it. However in action, when the line erasing reaches the last node, the gameObject bounces down to Vector3(0,0,0), I presume because this is the next point in the array.

I'm sure I'm misinterpreting a function here, any help would be greatly appreciated!

 

"closestPointIndexRelativeToNormalisedDistanceAlongLine" is an excellent variable name. I expect you're right, having the ability to get the point index would be useful. About the Vector3.zero thing, you can prevent that by making sure drawStart and drawEnd don't exceed the actual number of "used" points in a line.

--Eric

 

I have a feeling you've answered this already, but there are far too many posts to sort through and the search thread function seems to be useless.

I'm trying to make a vector game (like TankZone) but the MakeWireframe function draws tris, which clutters the mesh. The TankZone demo seems to be broken when I import the package and I can't seem to figure out how the objects are rendered through that.

Basically, how can I draw a wireframe that's made of quads instead of tris?

 

The demo imports correctly; make sure you're not using some kind of mobile platform, since as described in the docs it's intended for desktop. You can use the LineMaker editor tool to create vector objects made from quads (or other shapes).

--Eric

 

I started with your line drawing example, which sets the drawEnd as you draw the line. (If endCaps are enabled, however I removed that check so it always happens.) When I update the drawStart, the object travelling the path also speeds up. My theory is that even though I'm not updating 'SetDistances' changing the drawStart seems to affect GetPoint01, speeding my object up because it thinks it should be further along the line. (The speed increases more and more with each increase of drawStart.)

I also had another thought for a function, though it's one I could plug into myself easily enough. I just figure you might have a more efficient way than iterating through an array, it's basically to get the array position of a point closest to a set of coordinates. e.g.:

Code (csharp):

1.  
2. int GetArrayIndexAtVector(Vector2 position){
3.     return closestIndexOfLineArrayToPositionInWorld; // © gumboots 2014
4. }
5.  

Basically so that if I dragged a line into another line, I could find what point I was at and duplicate the line array after that position so that my new line connects on and follows the already existing one.

 

It's true that drawStart and drawEnd do affect GetPoint. However, min/maxDrawIndex don't.

--Eric

 

Ah ok. I had thought that min/maxDrawIndex was for points that don't change. e.g. Tracing out a line, you don't need to keep drawing where your cursor has already been so you increase minDrawIndex to leave that as is. Unless I'm wrong, does that mean to utilise min/max I should set minDrawIndex to 0 and reposition each point after the GameObject crosses it to Vector3.zero?

 

Well, min/maxDrawIndex may not be appropriate for what you're doing; I was just pointing that out.

--Eric

 

Ah, haha. I think this part of the reference guide is where I got confused:

However upon rereading I see that the two sentences aren't connected, just my mind playing tricks on me, hehe. Do you have designs to implement my aforementioned function into the next release? (Getting the array index of a point at x distance along a line.) If I can link the point to the GameObject's position, I could simply reset the GameObject's normalised position to 0 each time I delete a point, therefore not being affected by the reduced line length. In theory.

 

Yep.

--Eric