Vectrosity - fast and easy line drawing

Can I use this to draw a path of a projectile in real time ?

I want it to look like this. It needs to look like a tube renderer

 

There isn't really a way to get it to look like a tube renderer.

--Eric

 

Hi Eric,

Thanks for the reply. But is there any way i can create a mesh that looks like a tube in code at run-time ?

I've tried using TubeRenderer script in Unity wiki. But haven't had much luck.

 

Yes, but this topic is about Vectrosity only. It would be best to start a new topic for that.

--Eric

 

Hi Eric!

I have a little problem using Splines. I have a NavMesh path and i want to draw a Spline trough the waypoints of the path. It works but in some cases the spline makes a loop. I think this may be because of the distance between two points is too short to make a curve correctly. If this is the case, what can i do to avoid this whitout change the waypoints positions.



Cheers!!

 

You could use a bezier curve instead of a spline, perhaps, and compute the control points for the curve?

--Eric

 

Thanks Eric. I'll try to use A* Pathfinding with a grid that will have the nodes at the same distance to avoid this problem. It would be hard for me to place te bezier controls for a simple task like that!

Cheers.

 

This looks great, but all of the demos crash my computer if I mess them for a few seconds. (6 month old $2.5K MacBook Pro, using FF or chrome)... Kind of scared to buy it. Whats the deal?

 

Maybe some issue with your Unity plugin? Or the browsers? No issues with crashing here (Mac Pro, Safari, Firefox), and I haven't heard any other reports of that. I think it's a pretty good bet that I wouldn't have them up if they did crash under normal circumstances, yes? That would be spectacularly bad advertising. I've uploaded a standalone of one of the demos here.

--Eric

 

Hi Eric, about a year ago you answered my question about why lines updated with .Draw3D() would jitter if they were drawn any more than a small distance away from the world origin (I noticed jitter after only moving 700 units from the origin). Your above solution worked great for the issue I had back then, where I was just trying to draw lines that would remain fixed in place around the camera regardless of the camera's position in space.

Now I'm trying to achieve an effect of trailing ribbons behind moving objects like the old game Iwar (example image of the effect I'm after): http://www.projectrho.com/public_html/rocket/images/spacewartactic/iwar02.jpg

The ribbons remain fixed in space and the vessels create more ribbon segments as they move. This helps the player understand how the vessels are moving through space around them.

But the ribbons drawn this way with .Draw3D() jitter, especially if the camera is moving. The solution to use .Draw() instead fixes the problem, but then the ribbons no longer behave as part of the 3D scene and will not be occluded by objects in front of them. Any ideas about a solution or maybe a fix if it is a precision problem as you surmised? I'm sure lots of people would want to be able to draw 3D lines in space some distance away from world origin.

Thanks for Vectrosity and your amazing support!

Tam

 

Do you have a small script which demonstrates the issue? I tried moving everything in the orbit demo some 5K units from the origin as a test and there doesn't seem to be any jitter when moving the camera around.

--Eric

 

Hi Eric, here's a test script which you should be able to attach to a standard cube in a new empty scene.

https://dl.dropboxusercontent.com/u/11025048/github_attachments/VectorTrailTest.cs

It should set up the camera position and cube position automatically. See the setup code in Start() if you need to change anything.

There's some seemingly superfluous things in there like the Lists, as this is a cut down version of my actual script. The lists may be useful anyway in case you want to run loops over all the vectorlines in the scene etc. I use the lists in my real (and much more complex!) script to slowly fade the trail segments and remove the oldest ones after a set time.

This example sets the box at 5000 units from origin. Everything appears fine at first but after a few seconds (once the trail curves away and nearly touches the bottom of the view when I try it) you'll see the jitter begin suddenly. This example is using Draw3DAuto. I think the jitter starts at around 700 units or less from origin if you create a foreach loop which is calling .Draw3D() instead on each vectorline, but that method seems redundant as it's what I think Draw3DAuto does anyway. I can provide an example of the .Draw3D() method I was using too if you like, but the script above shows the jitter issue in some form at least.

Thanks again!

Tam

 

The issue seems to be the WorldToScreenPoint/ScreenToWorldPoint round trip for Draw3D lines, but unless Unity switches to doubles instead of floats I'm not sure what I can do about that. However, since you're using 1-pixel lines, you can actually bypass that and use VectorLine.useMeshLines = true, which will fix the issue and have better speed too.

--Eric

 

Thanks Eric, the lines are now rock-solid even at 50k units from origin!

 

Would it be possible to add a meshlines solution in a future version that allows > 1-pixel lines and line materials? Perhaps it simply cannot work that way, but it'd be nice if it could. I don't mind the 1 pixel line solution as a quick fix, but it looks much nicer to have the ability to define a wider line with a material of some kind.

 

There's no way for MeshTopology.Lines to be anything more than 1 pixel wide or to use textures; that's a Unity limitation.

--Eric

 

Hi Eric,
I'm getting unexpected behaviour when the main camera is rotated 180 degs (0,180,0) and offset from the origin e.g. (22,7,10). Vectrosity works when the main camera y rotation is zero i.e. looking down the z axis but it appears not the other way.
Unfortunately the project is quite old so rotating the camera means a massive change to all the 2D assets (yes was a newbie mistake from years ago!). It was working on Unity 3.5.7 and a early version of Vectrosity but the recent upgrade to Unity 4.5 and Vectrosity 3.0 has broken it with the rotated main camera. Vectorline.Draw is working but the resulting VectorCam settings look wrong.

Any ideas on how to make Vectrosity work in this set up?

 

I'm not aware of any changes that would cause Vectrosity to not work with a rotated camera. It works in all the demos with Unity 4.5. Make sure you're calling Draw3D after moving the camera, or use Draw3DAuto.

--Eric

 

Hi Eric and others.
I just bought Vectrosity and it seems neat an all, but it does not support C# Lists.
How would you suggest I should approach dynamic lines such as dynamically breaking ropes with Vectrosity? Do I need to create new Line and ToArray() every frame? Not very effective approach.

Thanks
- J

 

Ah I think I got it from documentation. I should use discrete lines that are defined per segment. Hmm. What if the amount of segments are dynamic - any tricks?

 

The standard technique is to allocate the largest number of points you would use, and then only use some of them. You don't necessarily need to use a discrete line; you can use .drawEnd to change the last point drawn.

--Eric

 

I'm having trouble after loading a new scene with a "Vector Object Not set up" error. It appears as if the Line Manager is not getting created the second time. If I try to create the object manually then I get a "Vector Object not set up" error.

Everything works when I first load the scene, but when I load a new scene thereafter, I get this error and my lines don't draw properly. As far as I can tell, everything is being completely cleaned out between scene loads, so I don't understand why everything is set up properly in the first load but not the second load. It's the same scene, just new game data.

 

What version are you using? 3.0 had a fix regarding that.

--Eric

 

OK cool I will check my version - yep, looks like I'm in 2.3. Will grab newest and report back!

 

Also can you clarify best practices here? Should I manually destroy VectorCam and LineManager in the new version, or is that automatic?

 

They're handled automatically so you shouldn't destroy anything.

--Eric

 

Well I just downloaded the latest package, 3.0u, and what happens is that when I load a new level, the old VectorCam and LineManager objects stick around and I get a "Vector Object not set up" error.

So for instance, I create a new game where I use lines, then quit to main menu. The VectorCam and LineManager are now in my main menu scene. Then I load another new game and get the error.

Even weirder: when I delete the VectorCam and LineManager objects from my Main menu sceneand then create a new game, the lines work properly (no error) but the colors are now faded. The VectorCam is created, but there is no LineManager now.

 

How are you drawing lines exactly? The line manager and vector cam objects are supposed to persist through scene changes.

--Eric

 

Hold on, belay last. I think I missed the upgrade package after downloading. I need to make a few code changes to reflect some of the 4.3 upgrades (i.e. set texture scale etc) and then I'll report in.

 

All issues resolved, thanks for your help.

 

Eric,

I just purchased Vectrosity and so far I really like it. I am having an issue however that I cannot seem to find the solution to. In the editor I have a 2dsprite that represents a body of water and when the scene loads I am replacing this rectangular sprite with an arbitrary number of "columns" which are made up of segments in a VectorLine. I am later updating the top portion of each segment so objects can splash in the water and make waves. Everything seems to be working fine except that all of my segments do not appear as I move my camera around.



As my camera moves the lines in the above image vanish and random numbers of their neighboring lines appear. What you should see is a solid block of red lines stretching across the image.

I have verified that all the segments are there and it is not a spacing or width issue.

Here is how I am setting up my line:

Code (CSharp):

1.  
2. void Start()
3. {
4.         int numSurfaceParticles = 100;  //arbitrarily chosen
5.  
6.         numSurfaceParticles = Mathf.Min(Mathf.Max(1, numSurfaceParticles), 32766);  //32766 is max segments
7.         float particleWidth = liquidBounds.size.x / numSurfaceParticles;
8.  
9.         float liquidBottom = liquidBounds.min.y;
10.         float liquidTop = liquidBounds.max.y;
11.         Vector3[] points = new Vector3[numSurfaceParticles * 2];
12.  
13.         float xPos = liquidBounds.min.x;
14.         float zPos = liquidBoundarySprite.transform.position.z;
15.         string name = liquidBoundarySprite.gameObject.name;
16.  
17.         for (int i = 0, j = 0; i < points.Length; i++)
18.         {
19.             points[i].x = xPos + particleWidth * j;
20.  
21.             if (i % 2 == 0)
22.                 points[i].y = liquidBottom;
23.  
24.             else
25.             {
26.                 points[i].y = liquidTop;
27.                 j++;
28.             }
29.  
30.             points[i].z = zPos;
31.         }
32.  
33.         vectorLine = new VectorLine(name, points, liquidMaterial, particleWidth, LineType.Discrete);
34.         vectorLine.Draw3D();
35. }

In the above script "liquidBoundarySprite" is the sprite that represents the body of water in the editor and "liquidBounds" is the renderer.bounds of that sprite.
I then update the line using vectorLine.Draw3D() in the Update() method.
I am using an orthogonal camera which is set with VectorLine.SetCamera3D(Camera.main) in the Awake() method.
I have tried using the following materials from your materials folder:
VectorLineColors
ThickLine
VectorLineBasic
VectorLine

Any thoughts on how to fix this?

Thanks.

 

Is it an issue with the lines not being drawn on top of a sprite? In that case you can use VectorLine.sortingOrder to make sure it's rendered in the correct order.

--Eric

 

I found the issue but I do not know what the solution is. In my script above I get the width of the segments as "particleWidth" by dividing the bounds size.x property by the number of segments I need. The value I get is several hundred times smaller than I would need each segment width to be. I thought maybe it was my camera which is set to 150 pixels per meter, or my liquidBoundarySprite which is imported with a scale of 100 pixels per meter, but the value being calculated for "particleWidth" should be the same no matter what these scales are because it is the number of Unity units wide.

If I hardcode the width to a little over 200 times the calculated width I get the correct result I am looking for.
Is VectorLine dependent on the camera's pixels per meter value or maybe screen resolution?

I should also point out that when I use particleWidth to set the x value in the vector3 for each segment they are placed at the correct world coordinates. I simply cannot use the same value for the actual width of the segment.

 

The unit of measurement for line width is pixels.

--Eric

 

Hmm...I find that odd. Wouldn't using pixels be against Unity's normal usage of arbitrary units so that different resolutions will display objects the same size? I would understand that being the case on 2d lines but lines that exist in the environment should probably be sized by the same units as other game objects. Just my opinion. I am looking at the code but I am having trouble seeing where I can change this to use non-pixel units. This way a 2.0f (unity units) line will display the same size in any resolution. Without this ability it is impossible for me to calculate the line size that would perfectly fit across a mesh renderer's bounds.

Thanks.

 

The idea of Vectrosity is that it's used for vector-type lines where they have a thickness that doesn't change depending on distance; for example orbit lines (see Kerbal Space Program) and such where you want them to have a consistent look. There's no simple way to change that to use other units.

--Eric

 

It's (almost) new version time! It looks like the changelog for 3.1 will be:

Additions:
• VectorLine.trigger, for setting whether a collider made with VectorLine.collider is a trigger or not.
• VectorLine.smoothColor, for setting whether line segment colors should be interpolated or not. This works with SetColor in addition to SetColors.

Changes:
• VectorLine.SetColorsSmooth is removed, since .smoothColor makes it unnecessary.
• VectorLine.collider works with lines made with Vector3 points now, in addition to Vector2 points. This works for both Draw and Draw3D. Note that the colliders are still 2D and only work with 2D physics, so the camera shouldn't be rotated or else the collider won't match the line.
• VectorLine.SetCameraRenderTexture has an option to pass in CameraClearFlags, so you can use other values besides SolidColor (such as Depth).
• DrawPoints can use viewport coords (VectorLine.useViewportCoords = true).
• The VectorLine.GetPoint* functions can optionally use an index variable as an out parameter, which will contain the line segment index that corresponds with the distance. e.g., if a distance of 500 is located on the 10th line segment, then the index will be 9 (since 0 is the first segment).

Fixes:
• StopDrawing3DAuto works correctly.
• Fixed issue with SetLine/SetRay time value not working.
• Line colliders work correctly with minDrawIndex/maxDrawIndex/drawStart/drawEnd.
• Line mesh bounds update correctly if the vertical screen size has been changed but the horizontal size is the same.
• EndCap.Back works with Draw3D.
• Fixed problem with VectorLine.Selected not working with .drawStart if the line segment widths haven't been explicitly set.
• VectorLine.Selected works with lines made with viewport coords.
• The VectorLine.GetPoint* functions work with minDrawIndex/maxDrawIndex.

--Eric

 

Hi Eric, where do existing customers go to download latest Vectrosity versions and sign up to notifications? I couldn't find a link for that on the website. Thanks! -Tam

 

If you bought from my site, you get an email sent when a new version is released, if you signed up for update notifications. (See the email that was sent when you first bought if you haven't.) If you bought from the Unity asset store, then you can download new versions there the usual way, but there's no notification mechanism.

--Eric

 

Hey Eric. I've created a spline in Vectrosity and added Meshcollider. By duplicating the spline(each with a meshcollider) I can move physics objects along the spline (think of a rollercoaster). However, issues arise as I need to use a raycast - and the 'cheat' of having a duplicate spline with a collider no longer works as the spline obviously has no 'depth' (Z). I completely understand that this wasnt what Vectrosity was intended to be used for, but aside from generating a bunch of additional verts, is there any other way or trick you know of that could give the mesh depth so a raycast would register a hit?

Thanks!

 

I don't really know of a way aside from adding verts/triangles to make the mesh have some depth.

--Eric

 

Running into this as well, and unfortunately I'm not able to place control points as the curve is built off of data. Would there be any way of getting centripital catmull-rom packaged with the next version? I gave it a shot with the source, but wasn't able to get it to work.

 

OK, I'll take a look.

--Eric

 

Yes Eric! It would be really nice!

Thanks!

 

After utilizing my mad C++ conversion skillz (read: winging it and hoping for the best), the initial results seem promising:



--Eric

 

Hi Eric,
Any plans to support Oculus Rift?

 

Nice One Eric!

Just what we need!

Thanks!

 

Beautiful! Thanks man. Any chance of posting your code? I'd really appreciate it.

 

Nope, but it's part of the 3.1 update. Which is available...wait for iiiiiiiiit...now! (On my site; submitting to asset store next.) Revised changelog:

Vectrosity 3.1

Additions:
• VectorLine.trigger, for setting whether a collider made with VectorLine.collider is a trigger or not.
• VectorLine.smoothColor, for setting whether line segment colors should be interpolated or not. This works with SetColor in addition to SetColors.

Changes:
• VectorLine.SetColorsSmooth is removed, since .smoothColor makes it unnecessary.
• VectorLine.collider works with lines made with Vector3 points now, in addition to Vector2 points. This works for both Draw and Draw3D. Note that the colliders are still 2D and only work with 2D physics, so the camera shouldn't be rotated or else the collider won't match the line.
• VectorLine.SetCameraRenderTexture has an option to pass in CameraClearFlags, so you can use other values besides SolidColor (such as Depth).
• VectorPoints can use viewport coords with Draw (VectorLine.useViewportCoords = true).
• The VectorLine.GetPoint* functions can optionally use an index variable as an out parameter, which will contain the line segment index that corresponds with the distance. e.g., if a distance of 500 is located on the 10th line segment, then the index will be 9 (since 0 is the first segment).
• VectorLine.MakeSpline uses centripetal Catmull-Rom splines now instead of uniform, for better and more accurate curves, particularly those with spline points that are close together.

Fixes:
• StopDrawing3DAuto works correctly.
• Fixed issue with SetLine/SetRay time value not working.
• Line colliders work correctly with minDrawIndex/maxDrawIndex/drawStart/drawEnd.
• Line mesh bounds update correctly if the vertical screen size has been changed but the horizontal size is the same.
• EndCap.Back works with Draw3D.
• Fixed problem with VectorLine.Selected not working with .drawStart if the line segment widths haven't been explicitly set.
• VectorLine.Selected works with lines made with viewport coords.
• The VectorLine.GetPoint* functions work with minDrawIndex/maxDrawIndex.

Regarding the Oculus Rift, it apparently works well if you use SetCamera3D and then Draw3D for any lines you have, for each camera.

--Eric

 

Nice!

Thanks a lot!