Vectrosity - Fast and Easy Line Drawing

Well, just the usual issues of getting transparency sorting to work at all, I would think.

--Eric

 

Greetings Vectrositarians. . .

Eric, congrats on the release of v4, looks awesome, will be upgrading very soon . . .

I've got a general Geometry question, but thought I might have better luck asking here given Vectrosity's capabilities, thanks in advance for the indulgence. . .

Basically, I need to convert a set of 2D points in 3D space from Cartesian coordinates to Polar coordinates. I've got a mandala consisting of a 3D line (3600 discrete segments) and need to map the points onto a hemisphere, and then curve the segments accordingly. Here's an example of one of the lines, looking at an X/Y plane, down the Z axis, with an orthographic camera:



So, how can I turn that into a dome? That's the question.

Any guidance / assistance / pointers that anyone could provide would be immensely appreciated!

Thanks!

==rr

 

If I'm working with real 3d lines with occlusion and all that good stuff, is there anyway to set line width in a non pixel-oriented way? As in, if I move the camera away from my line, the line appears thinner. Is this possible in current vectrosity or easily edited into the source?

 

Not at this time; Vectrosity was created to use pixels for the width.

--Eric

 

I'm using Vectrosity 3 to generate cubic spline arcs with approximately this number of lines (8x8x64) for visualizing neural synapse connections in Unity. You use the Vectrosity MakeCurve() and Draw3DAuto() functions. You have to manually set up the cubic curve endpoints and control points in order to approximate a hemisphere. See this link for details on cubic spline semi-circular arc control points:
http://digerati-illuminatus.blogspot.com/2008/05/approximating-semicircle-with-cubic.html
Unity rendering will get slow with this many cubic spline lines, so set your number of segments per line as low as you can get away with. You can vary the line segment width and color for each individual cubic arc. You need to be comfortable with Unity scripting and math in order to try this, but the results are very good.

K.N. Chaffin - Texas Tech University

 

@knchaffin -- Many thanks for the thoughtful response. This makes total sense, and would work easily if all of the segments began at the center and extended the full length of the radius -- but they don't, which, for me, is where the complexity arises -- if the beginning and end points of the line/line segment are somewhere in between, how would you calculate the proper curve for that segment? I'll take a closer look at the link to see if the answer lies within. . .

I've been scripting in JavaScript since the Netscape 1 days, so no issues there, and I'm coming to terms with Math -- the above object was actually generated using Johann Gielis' SuperFormula, and it was a small victory getting that to work smoothly . . . but I'm obviously not adept enough to know how to calculate spherical curvature from indeterminate points on a sphere!

Thank you again for your answer, I'll post back with findings.

BTW, would be interested to see the work you are doing with synapses -- can you post a URL? or PM me? Thanks!

 

I'm sure you could do what you want with Vectrosity 3, but getting the arc segment slopes just right will involve a good bit of work. Calculating the arc endpoints would be relatively easy, similar to how sky domes are procedurally created. I usually use oblate spheroids for that purpose. Just looking at your mandala image, it appears that you could probably use a hemispherical arc and modify the arc line segment colors and widths.


Here is a screen capture of a small portion of my human hippocampus simulation. The red and blue arcs are done with Vectrosity v3 where red represents higher synaptic efficacy and blue represents lower. This particular simulation has three layers of 256x256 neurons with synapse connections between neurons in the layer and between the layers. In this shot, each neuron is connected to 28 neighbor neurons within the layer. I can only display a small portion of the synapses due to speed issues, but this simulation is showing 8x8 neurons and their 28 synaptic connections for a total of 1792 cubic spline Vectrosity arcs. The neurons are rendered by TC-Particles with a material texture image of a neuron on each "particle". The color of the neuron represents the neuron activation level with red being higher and white being lower. The grayscale squares are actually texels in a texture and the brightness represents membrane potential. The simulation occurs on an NVIDIA CUDA board and the TC-Particles calculations occur in a DirectCompute shader. So, lots going on. It is fun to watch all of this evolving in time.

K.N. Chaffin - Texas Tech University Informatics Media Lab

 

I agree, this approach sounds viable, and is pretty much what I expected I'd need to do. There are two key processes that I need to get the exact Math formulae for, however:

1. Convert Cartesian coords to polar -- effectively an inverse Haversine or Vincenty formulae, or what you'd use to convert Lat/Lon to a 2D map. (see: http://www.movable-type.co.uk/scripts/latlong.html)
2. Calculate the proper arcs/curves, as mentioned.

I've no doubt it can be accomplished (I've done GPS coords to 2D plane in Unity before), just need to get my hands on the formulae! But yes, a fair amount of work, and hopefully the results won't kill performance . . . I guess I was hoping that Eric would step in and say that he's created the Magic Extrusion feature for version 4.2.

Thanks for posting the graphic of your synaptic simulation, really impressive . . . would love to see it in action (or a video?). Reminds me of what a Moog Modular looks like after a good hour or two of soundscaping . . . I guess in a way, patchcords and synapses are somewhat the same!

Cheers

 

I would avoid fully converting from Cartesian to polar. If you put a hemisphere of radius R over your 2D Cartesian XY plane, a point on the XY plane and under the dome has 2D coordinates x,y . The polar radius in the XY plane r=Sqrt(x*x + y*y). The distance z from this point up to the hemisphere in Z direction is z= Sqrt(R*R - r*r) giving you the 3D Cartesian coordinates of any point on the dome as x,y,z . You can adjust this to an oblate hemisphere by multiplying z by some constant such as 0.5 which will make an oblate dome with height of 0.5*R . Of course these are just simple coordinate projections and may not be exactly what you want and you would have to use the more complicated formulas that you mention above.

Regards,
K.N. Chaffin - Texas Tech University Informatics Media Lab

 

Wow, I think this is EXACTLY what I was looking for, huge, huge, thanks. Anxious to implement. . .

 

I had to come here to say, utterly fantastic. Been looking for 2D tools like this for a while and this library does everything I want. Always a fan Eric.

Edit: While I'm here... is there a way to match the collider to the line if I use the canvas in World space. I need to be able to travel along the line so I'm either stuck animating the line which means physics don't run properly. Is there a way to do that?

 

Thank you! If you're talking about 3D physics, I'm afraid not. I was never able to get 3D colliders working in a consistent way, given how Vectrosity works (line segments facing the camera, measured in pixels), so it's 2D colliders only.

--Eric

 

I actually mean the 2D colliders. Essentially the 2D edge collider is only exactly on the line if the line is drawn as an overlay. If the line is set to draw in the world (i.e. not locked to the camera) the collider isn't sized to it, rather the collider is still tiny and in the corner. Can the collider be scaled and translated to the "location" of the world space line, or is it incapable of working like that?

Additionally, if the latter is true. Would a line bound between 0 and 1 fits its collider, even in World space due to the viewport coordinates option?

 

Do you mean lines made with Draw3D (which uses canvas3D)? Those should match the collider, as long as the camera is orthographic.

--Eric

 

I got it working thanks, didn't realize I was using regular Draw. Thanks.

 

Version 4.0.2 is out:

Fixes:
• Changing VectorLine.textureOffset after adding points to .points2 or .points3, and before calling Draw, no longer causes an error.
• VectorLine.capLength is taken into account when using VectorLine.textureScale.
• Updated some scripts for Unity 5 compatibility.

Also version 3.1.3, which is updated for Unity 5 but otherwise the same as 3.1.2.

--Eric

 

Getting a lot of issues with using VectorLine.Destroy() any time I try to use it it crashes the Editor when I try to run it. Could be in particular due to C# using ref. Either way, can't find a clean way of Destroying the line objects in the canvas, other than disabling them.

 

VectorLine.Destroy is correct; it works fine here.

--Eric

 

Looks like you're trying to use the demos for Vectrosity 3 with Vectrosity 4.

--Eric

 

All of them.

--Eric

 

Back with more bothers! I was able to get deletions working, new issue occurring with the view frustum:



And the error(s):

Screen position out of view frustum (screen pos -1.#IND00, -1.#IND00, 1.000000) (Camera rect 0 0 644 280)
UnityEngine.Camera:ScreenToWorldPoint(Vector3)
Vectrosity.VectorLine Draw3D()
Vectrosity.VectorLine Draw3DAuto(Single)
Vectrosity.VectorLine Draw3DAuto()
Car:SetupLines() (at Assets/Scripts/Car.cs:117)
CarManager:CreateGeneration() (at Assets/Scripts/CarManager.cs:25)
CarManager:Update() (at Assets/Scripts/CarManager.cs:88)

Screen position out of view frustum (screen pos -1.#IND00, -1.#IND00, 1.000000) (Camera rect 0 0 644 280)
UnityEngine.Camera:ScreenToWorldPoint(Vector3)
Vectrosity.VectorLine Draw3D()
LineManager:LateUpdate()

Could this be because of Draw3DAuto()? Is it safer to use Draw3D() in LateUpdate()?

 

Strange, I've never seen anything like that before. Maybe the points are way (way way) out of the camera frustum, and it doesn't like that? You could try erasing points that are too far off-camera. Draw3DAuto just calls Draw3D automatically in LateUpdate; there's no difference doing it manually.

Maybe just delete the Vectrosity 3 demos first, then import the Vectrosity 4 demos. The demos are the same, but the scripts are updated to work with Vectrosity 4.

--Eric

 

I'm not sure how... I have this particular script drawing the outer edge of a PolyCollider2D with points bound between -1.5f and 1.5f I'll do some checking, could this be in part due to drawTransform being set to the Collider's transform?

 

Not sure; if you have an example scene that shows this issue, I can take a look at it.

--Eric

 

All the code should be in this repo github.com/dlawre14/genetic_cars

 

How do I set the line's mesh to face Vector3.up instead of the camera when rendering? Example below:

The red/blue sphere gizmos are the points the line is following, but the line's mesh gets contorted according to where the main camera is facing. Ideally I just want the Vectrosity line to be flat (normals facing up) and rendered on top of my tiled map mesh. The line doesn't follow the exact vector3 points, but seems to raycast to the camera and cause large inaccuracies and... unexpected results.

I'm using Unity 4.5.5f1, Vectrosity3_Unity4_3, and .Draw3DAuto() for rendering. I'm outlining the territory border for cities in my game, will Vectrosity be able to handle it?

 

Vectrosity is designed so that the lines face the camera, however the points should be in the correct locations, as shown in the spline demo (where the line passes through the spheres in 3D space). Perhaps you have some transform which is affecting the points? There's a bit of a hack where you can get the line to face another direction, where you use SetCamera3D with a camera oriented in the desired way.

--Eric

 

Hi Eric, was looking around at the sample scene. Wondering if I can change the material used for the line in the 'orbit' scene.

Thanks.

 

Sure, just assign a different material to the line instead of null (the default).

--Eric

 

Updated to the latest version and got this error when using MakeSpline. What I have done is that I have put a line round and round the circle and the longer I draw the line the more scewed the last points are and therefor I get points sticking out of the line. I also can't seem to get the end cap to work.



I stumbled upon another issue as well. The line is always offset from where it should be. But if I input Offset x: 0.5 y: 0.5 in the canvas it is spot on. Any ideas?

 

Do you have any example code that demonstrates the issue?

--Eric

 

Excuse me, may i save the line and edit it ?

 

Lines are typically created in code, so in that sense they can always be saved and edited, but there's also the LineMaker utility, which can create lines visually.

--Eric

 

So, with only Vectrosity i can't draw a line, save it and edit in next time ?

 

As I mentioned, Vectrosity is primarily used by coding. But there is a LineMaker utility included which you can use to create lines visually.

--Eric

 

i got it, thanks !

 

Sorry to bring this up again. I opened the Orbit scene, and theres no where I can assign the material to. I think I'm missing something here.

 

You'd need to make a public Material variable and use that in the script, since the way it's written just uses the default material (null).

--Eric

 

Hi Eric,

I'm using Vectrosity 4 (which is fantastic, BTW!) to draw some relatively complex shapes for an asteroids-ish game. My hope is to completely build the game with Vectrosity lines, so I'm setting myObject.collider = true for each of my shapes. I'm setting myObject.trigger for each object other than my player 'ship' to detect collisions. I'm having a weird issue though. Oh, I'm also using generic sprites to create each game element, with a script to draw the shape attached to each one.

With the game running I never end up having any OnTriggerEnter2D() events, so I figured I'd examine the colliders that Vectrosity is creating, and it seems like that's the problem. The collider is getting created, but it's extremely tiny and not at the same location as the Vectrosity lines I've drawn.

I'm absolutely positive that it's some stupid mistake I'm making. Here's the code I'm using to create my player ship. My code for the 'enemy object is essentially a cut and paste with the movement code removed. Excuse the simplicity of all this; I've just started making the game.

Code (CSharp):

1. using UnityEngine;
2. using System.Collections;
3. using Vectrosity;
4.  
5. public class ShipController : MonoBehaviour {
6.     public Material myMat;
7.     private VectorLine testLine;
8.     void Start () {
9.         transform.position = Input.mousePosition;
10.         Vector2[] linePoints = { new Vector2(5, 5), new Vector2(5, -5), new Vector2(-5, -5), new Vector2(-5, 5), new Vector2(5, 5),
11.             new Vector2(20, 0), new Vector2(5, -5), new Vector2(0, -20), new Vector2(-5, -5), new Vector2(-20, 0), new Vector2(-5, 5),
12.             new Vector2(0, 20), new Vector2(5, 5)};
13.         testLine = new VectorLine("PlayerShip", linePoints, myMat, 1.0f, LineType.Continuous, Joins.Weld);
14.         testLine.SetColor(Color.cyan);
15.         testLine.drawTransform = transform;
16.         testLine.collider = true;
17.         transform.Rotate(0, 0, 45);
18.         testLine.Draw();
19.     }
20.  
21.     void OnTriggerEnter2D(Collider2D other){
22.         print("trigger");
23.     }
24.  
25.     void Update () {
26.         transform.position = Input.mousePosition;
27.         testLine.Draw();
28.     }
29. }

 

Seems fine here (and simplicity is good)...I put the script on an empty GameObject, and put a cube in the scene for reference:



Are you doing something funky with the camera, maybe?

--Eric

 

Thanks for the quick reply!

Nope, I'm not messing with the camera at all. It's an orthographic camera, but I can't imagine that would create an issue. Otherwise it's just the default out of the box camera.

I tried doing the same, using an empty GameObject and not a sprite, and got the same behavior. I'll try creating an entirely new project, import Vectrosity 4, and see if anything changes. Thanks for your help!

 

I tried with an orthographic camera and got the same result.

--Eric

 

Thanks Eric!

I just created a new project, added an empty GameObject, attached that script, and got the same problem I've been having. I'm using Unity 4.6.0b17 with Vectrosity 4 (imported the dll). I just updated Vectrosity on Monday to the latest version from the asset store.

This is the strangest thing! If you want I can zip up my project and send it to you.

 

That could be the problem, since there are some issues which prevent <b19 from working properly.

--Eric

 

Ah, got it. I'll update to b19 and see what happens!

Edit: Just updated to b20 and I'm having the same troubles. Weird!

 

Hey Eric,

So, I've updated to the latest 4.6 stable release (b20) and neither triggers nor collisions are working for me. I've installed the demos and tried Hills out, since it includes collisions, and it works as intended. Not sure what's up! I don't feel like I'm doing anything stupid to cause a problem.

Any other thoughts about what I could try? Thanks!

 

It could be that you're trying to collide edge colliders with other edge colliders? That doesn't work as far as I know. If you use a continuous line in Vectrosity, it generates an edge collider, but if you use a discrete line, it generates a polygon collider.

--Eric

 

A new update is out, so Vectrosity 4 works with Unity 4.6f1:

Vectrosity 4.0.3

Changes:
• Requires Unity 4.6f1 or higher, although it currently won't work with Unity 5, until Unity 5 integrates the 4.6f1 changes (which it doesn't as of Unity 5.0b12). If you need to use Vectrosity 4 with Unity 5, stick with 4.0.2 for now.
• TankZone is included again.

Fixes:
• Works with RenderMode property changes in Unity 4.6f1.
• Joins.Weld with continuous lines using Draw3D works properly.
• End caps are drawn correctly when using Draw3D.
• Using a VectorLine.drawEnd of 0 with a discrete line erases the entire line instead of retaining the first line segment.
• VectorLine.active works. This also means VectorManager.ObjectSetup stuff works properly.

Note that VectorLine.active is working because I gave up waiting for the SetActive bug to be fixed and used a different method. This shouldn't make any difference in most cases, but the line GameObjects are not actually activated/deactivated, just in case someone was relying on that for whatever reason.

--Eric

 

OK, so I have purchased this happy asset. I'd like to say what I'm trying to do, and see if I'm taking the right approach, please. This is a C# visualisation project with some prefabs.

Goal: 3D blocks with a single pixel border. The blocks constitute a landscape. (No, this isn't some kinda Mindcraft thing.) As the camera zooms in or out, I want the borders to remain one pixel in width. (The user navigates the landscape entirely with the camera. S/he can then select individual cubes.)

What Didn't Work: I created prefabs of the 3D blocks using Quads (for separate shading), and added borders using stretched cubes (so the borders were slightly outside the blocks). As the camera zoomed, though, the borders became either too large, or too small. I bought a ton of assets, but none of were right.

Idea: Draw the borders in C# using Vectrosity. Re-drawn the borders whenever the camera moves or zooms.

Idea Concerns:

(1) I have no idea what the performance penalty is for this, if any. I guess there wouldn't need to be one, considering that one way or another, the lines need to be drawn.

(2) I'm assuming that lines the viewer wouldn't see will automatically not be drawn. By using the built-in primitives and assembling objects in the editors, this happens automatically. I have hundreds of millions of these cubes in a landscape.

(3) There's a lot of stuff that works automatically, and is very easy to deal with. This ranges from compatibility with other assets, to rendering (e.g. shadows), to selection and collision. What do I lose by using Vectrosity?​

Thanks, Bill

 

1) It would depend on the number of cubes, though it would be a little slower than stretched cubes (since the lines do have to be recalculated when moving the camera).
2) Correct, as long as you use the ObjectSetup function, which allows you to essentially treat VectorLines as standard GameObjects (so they are culled when not visible, etc.). However:

That's not going to work so well, I'm afraid. Unless maybe you make some sort of routine to only make VectorLines for visible cubes, then re-use the VectorLines with new cubes as the camera moves.

3) You wouldn't lose anything, since the lines would just be extra GameObjects, but see above about the zillions of objects.

--Eric