No, but the idea is that you update the 3D lines whenever the camera moves, so they always face the camera. You can use DrawLine3DAuto for this if you don't want to do it manually.

Click to expand...

So how does DrawLine3DAuto actually work? i.e. I am getting performance issues? where the line flickers and tries to catch up with how it should draw itself if I have the globe rotating. I assume this is because it is trying to recreate the geometry so the ribbon faces the camera every frame? A square or hexagon shaped tube (although adding more polys) would prevent this... How would you approach this if you need the line to be in the 3D scene (occluded etc) but also look and perform correctly during animation of its parent?

Volunteer ModeratorModerator

Adding geometry for a tube would look wrong and would run slower. There shouldn't be any performance issues; the orbit lines in the orbit demo, for example, use DrawLine3DAuto and there's no flickering or anything. It sounds like you may have more than one thing attempting to control the line movement, creating some conflict. You might consider using a VectorManager object, so that the line object essentially behaves like a standard GameObject but is drawn with Vectrosity.

Sorry Eric, one more question: Does minDrawIndex and maxDrawIndex work on lines that are made by VectorManager.ObjectSetup ?

i.e. I'd like to make it appear like the lines are drawing (in 3D, while parented to another object and with polys always facing the camera) and I've successfully used maxDrawIndex with DrawLine3D before, but it doesn't appear to be working in the Update if I try to change that property on the line passed to VectorManager...?

MyLineNULL ends up being the parent GameObject that the vecrosity line gets created at? And myline is the line that I can modify in the Update? when I modify myline.maxDrawIndex in Update nothing happens - what am I missing?

Thanks, this works for me too now. My problem was that I did not set the maxDrawIndex to 1 in the start to begin with.

Though I am a little confused and am not sure if there is a bug here though it's likely again to me doing something wrong. Would you check out this simple script and see if there is a bug in Vectrosity? I just create a scene with 5 Empty GameObjects named NULL_Line1 through 5. This draws a 50 segment line. All works fine until you try to change the minDrawIndex or set the maxDrawIndex to something less than it was when Start() executed.

Running this and hitting the F5 key shows 2 segments (as if the first segment is not erased properly?) instead of moving where the segment is being drawn along the line. Can you test this on your end and tell me what I am doing wrong or if there is a refresh command or something that gets minDrawIndex to work, or maxDrawIndex to work when set to something less than it already is?

Volunteer ModeratorModerator

Min and maxDrawIndex won't remove segments that are already drawn; they are just an optimization so that, for example, the entire line doesn't have to be recomputed if you're just adding some points at the end and not changing any of the earlier points. See the DrawLinesMouse example script. If you want to remove segments, you can set the relevant points to Vector3.zero and redraw the line.

Unity Technologies

So, speaking of which... I've just started looking into the best way to do this, and have not gone far... If I had a HUD being drawn by Vectrocity, and wanted to toggle the whole shebang on and off... Is there and easy shortcut? Having done little to no research except ask?

Volunteer ModeratorModerator

Yes, you can use VectorLine.active. If the HUD is made of more than one VectorLine, then you'd toggle .active for each one. Another possibility is to just disable the vector camera, if the HUD is the only thing being drawn by Vectrosity. In this case you can get a reference to the vector camera by doing "var cam = Vector.SetCamera();" at the start and do "cam.enabled = false/true".

Min and maxDrawIndex won't remove segments that are already drawn; they are just an optimization so that, for example, the entire line doesn't have to be recomputed if you're just adding some points at the end and not changing any of the earlier points. See the DrawLinesMouse example script. If you want to remove segments, you can set the relevant points to Vector3.zero and redraw the line.

so if I wanted to change the drawmouse sample scene so that I could hold down the right mouse button and the lines would be erased from the last point drawn to the first, I would cycle through the linepoints arrays and set each point to vector.zero?

hey guys, this may relate to my last question, but I'm using code similar to mouse draw sample code except it allows drawing multiple lines as separate vector objects. I've been pondering if there is an easy way to create an erase tool? any thoughts?

Volunteer ModeratorModerator

Not really an easy way that I can think of. Unless you have a solid-colored background, in which case just make a line the same color as the background and have it draw on top of the other lines. It's not really erasing, of course, but it would look like it. Otherwise I think you'd have to scan through the points in the line arrays and compare them to the current mouse position, and zero out the closest match if it's within a certain distance.

Not really an easy way that I can think of. Unless you have a solid-colored background, in which case just make a line the same color as the background and have it draw on top of the other lines. It's not really erasing, of course, but it would look like it. Otherwise I think you'd have to scan through the points in the line arrays and compare them to the current mouse position, and zero out the closest match if it's within a certain distance.

--Eric

Click to expand...

both of those seem like pretty good ideas, thanks Eric, except those erased areas won't be drawable again...perhaps drawing every new line at a z distance a small bit closer to the camera than the last?

Volunteer ModeratorModerator

both of those seem like pretty good ideas, thanks Eric, except those erased areas won't be drawable again...perhaps drawing every new line at a z distance a small bit closer to the camera than the last?

Click to expand...

That sounds like it would work; you can use VectorLine.depth for that.

I thought I had a Vectrosity issue but it turns out to be something else.

I came across a C# implementation of a Delauney triangulation solution which works like a treat (Unity editor view on the left), but as you can see in the image to the right it goes all wonky on the lower parts of the triangulation while running on an iPad:

My gut is telling me it has something to do with decimal precision? Care to take a look?

I`m not a coder, so even though your tool looks interesting to me, I can`t use it. The only way I can use your tool is if vectrosity would be integrated with Playmaker. After I`ve seen your examples I had the feeling that Vectrosity openes so many possibilities, but not for me.
Having Vectrosity-Playmaker actions, things will be a bit different. I think this will give me the possibility to draw lines at runtime, change the collors and thicknes according to the gameplay, changing them from dotted lines to continuos lines, etc.
Do you think is possible to develop/integrate Vectrosity and Playmaker for users like me?
Thank in advance for your answer.

Volunteer ModeratorModerator

I don't own Playmaker, so I doubt it will happen. I'd strongly suggest learning to code. By nature, "no-coding" tools are quite limited (this being a prime example--you can't use third party utilities without someone doing extra development). I'm not against them...I think they have their place, and are useful in some circumstances, but in the end they're no substitute for code. I started using Unity after 9 years in graphic design, so no point playing the "but I'm an artist" card.

(By the way, this isn't an invitation for a general debate on no-coding tools...that's been done to death elsewhere. Vectrosity-only posts here, thanks. )

Volunteer ModeratorModerator

I would guess that's the result of not using the right shader/material. I can't think of anything that would cause that in Vectrosity. One thing though, if you're doing that DestroyLine/making a new VectorLine a lot, I would recommend not doing that, and just making the line once.

I'm relatively new to using Vectrosity (nice work, Eric, it seems very robust and easy to use). I have the basics up and running nicely, but now I'm trying to apply it to a more complicated situation.

In the scene I'm working on, the main camera has an ambient animation on it (it sways around a bit as a character walks), but I have a problem with the texture on the line "swimming" around a bit as the camera moves. Basically, I'm using SetTextureScale to force a 1.0 aspect, but as the camera moves, the texture slides around a bit on the 3D line which is drawn.

Probably there are some inefficiencies in there, as I'm still trying to learn the syntax (there are some redundancies, but I don't think that affects the problem).

My only thought is that I could use the transform of the camera to somehow to compensate for its movement (or something). I can't quite wrap my head around what I should attempt to solve this. Hopefully this all makes sense.

The reason that I'm updating the line in LateUpdate() is that I will eventually be moving some of the anchor points around dynamically, and need the line to update accordingly.

Volunteer ModeratorModerator

I would guess the sliding is because the line is changing length, and SetTextureScale makes sure the texture always stays proportional regardless of the line's length. Maybe you should just do SetTextureScale once in Start, and not in LateUpdate? I'm not sure what effect you're going for.

I guess I could explained things a little better. Using the above script, I've set up 4 points, between which I'm drawing the continuous line. The line uses a chain-link texture.

In the final game, the plan is to have the middle two points move around to create the illusion that something heavy is hanging from the chain. But currently... even when no points are being moved, the texture slides around. To be more precise, the mapping appears locked at the beginning of the line, but looks to scale slightly in and out across the length of the line as the camera animates.

If I remove the animation from the camera, everything works perfectly, so it's at least related to that in some way.

The camera isn't affecting the line, in any way that I can see. The points of the line aren't moving.

Strangely, when I remove the SetTextureScale from LateUpdate, the texture behaves properly -- no swimming around. The only problem is, without that line in there, when I move a point, it will stretch incorrectly (ie. it won't hold it's 1.0 texture aspect).

Edit: it's the same issue if I use Vector.DrawLine3DAuto(); to update the line, instead of using Vector.DrawLine3D in LateUpdate()

For example, this code produces the same effect. No swimming around, but the line texture stretches when I'm pulling around points in the line:

Volunteer ModeratorModerator

To be more precise, the mapping appears locked at the beginning of the line, but looks to scale slightly in and out across the length of the line as the camera animates.

Click to expand...

That is indeed how it works; the mapping is locked at the beginning, and scales the UVs so that the texture is always the desired aspect. If the texture is changing, that means the length of the line is changing. Maybe only slightly, but enough that the scaling would be visible. It seems to me that you shouldn't set the texture scale in Update, only once when the line is created and again when the points are moved.