Curve moving along mesh along vector field

Hi :slight_smile:
Drag a curve along a mesh moving through a vector field. I tried some things but I seem not able to manage it and get the curves along the meshes.

I tried the dodo plugin but I do not know yet how to make a tensor field.

Do you might know how to drag a curve along the mesh through a vector field;
or how to make a tensor field?

Thank you for your response :smiley:

problem curve along mesh 00.gh (51.8 KB)

Hi @ForestOwl,

One issue in your script is that you don’t treat your meshes as two separate items. This makes the flow curves jump from one mesh to the other. It’s an easy fix, if you simply provide each mesh with its individual flow field.

problem curve along mesh 01.gh (38.5 KB)

I don’t know the Dodo plugin and thus can’t assist you with that part!

However, another issue seems to be that the flow lines are not exactly kept on their respective mesh. I guess this is due to the fact that they are interpolated through the randomly charged vertices. Bigger charges might push the flow line away from the mesh!?

The whole flow field approach might not be an ideal one, depending on what your ultimate goal is?

A better approach could be an agent/particle-based system.
Each mesh vertex could be an agent with a position and velocity. The position is basically a 3d point and the velocity a vector that defines the direction, in which the particle travels at a certain speed.
Now, at each iteration/step the particle has to evaluate its next position on the mesh. Here you have to come up with rules that define the particles behaviour. Where do the particles steer towards? Do they cohere to or separate from each other? What are they restricted by, other than having to travel on the mesh?
This approach should be much more versatile and emergent than the random flow field!
Each agents position would be recorded for each iteration and the collection of positions could provide the trail curves on the mesh.

There are some plugins like Kangaroo 2, the BOID Library that is usually used in combination with Anemone, Quela, Culebra, etc. that can all handle agent based design.

As always, scripting would be the most versatile. Jake Hebert over on YouTube has an ingenious series on particle systems in GhPython. You can also look at @AndersDeleuran’s great mesh drainage Python script over on GtHub, which shows how to produce trails on a mesh.

Maybe, someone else can still help you with the Dodo and flow field approach, if you want to stick with that!

1 Like

That reminded me to just update the code. Found a bug that would cause particles on planar parts to throw an error (also added a multi threading toggle).

Edit: Here’s a quick implementation:

190430_MeshDrainage_00.gh (13.1 KB)

2 Likes

sounds fancy

Thank you @diff-arch for your explanation on this :smiley:
The curve does not attached to the mesh? But, that is intended right? Is it not possible to let it go along the mesh?
And thank you @AndersDeleuran for sharing that :smiley:

Are you talking about your GH definition? If so, as I’ve explained above, I believe that the flow line is interpolated through your randomly charged vertices. Since the charges are random, bigger ones will probably push the curve away from the mesh.
Is it intended? It’s just what your definition produces so far. :slight_smile:
I really don’t know, how you could control this!

Anders’s script produces drainage trail curves, whose vertices/control points are on the mesh. Whether their curve segments between the points are on the mesh, depends on the StepsSize variable. It defines the distance between each mesh point, the resolution of the curve so to speak. If it’s too big, the result might look off, since the points form a curve with too few vertices/control points.

Thanks, Anders! I noticed the error a while back, too. It’s caused by the projection of the negative unit z-vector to a plane, it is normal to (i.e. XY-plane). The result is a null vector that has no angle with the x-axis of the plane.

1 Like

Thank you.

And that is one ugly drawn frozen character. When it turned, I turned away. My god.
I needed to search another one to restore my sight, here an more refreshing animation of this cartoon character, specially for you.

You must have used a crappy gif-website. Go to https://giphy.com/ for better ones, please. :upside_down_face:
And thank you for your response. :slight_smile:

1 Like

@ForestOwl, I think this is what you wanted:

problem curve along mesh 00_LG.gh (111.2 KB)

1 Like

Thank you for your response Mr. Greco :smiley:
Do you might know if there is an example file of ‘making a tensor field’ available?

there you go :slight_smile:

construct tensor field.gh (8.7 KB)

1 Like

@diff-arch @AndersDeleuran

I have another question. I was trying to create a path from the white points to the other white points (entry points) while avoiding the blue points (barriers) and walk partly over the pint points (walkable areas).

(A) However, when trying to create the main path the boids does not complete the path from A to B (from the first white points to the other white points) (the white points start in the middle).
(B) And when trying to create side paths (see other flines) I cannot generate nor merge the flines to clear single ones with space between them.

For me, (A) is most important. Do you have any thought about a plugin that makes a route along the flowing flines from the white points to the white points on the other side?
Now, I can see a kind of path (yellow marking), but I cannot get it right. Do you might know something in order to get the path (yellow marking).

I do not want you to put to work for me, so, if it is a difficult question, please do not make the solution, but give me tips. Thank you. :slight_smile:

problem vector field curves 00.gh (89.7 KB)

I guess you first need a solid method for determining the white end point B of a white start point A and store it in a way that you can find and couple it with the start point (e.g.[[A, B], …, [X, Y]]), whenever you need the information.
You seem to have a system in place for determining the start and end points, so maybe a start point A could look for its closest end point B in a close group of end points or something similar? Can a given start point have an end point as target that has already been visited?

If you have the relation of the start and end points figured out, you can launch your particle AB
in this general direction in order to get to the end point. This direction or velocity ->AB would be best represented by a normalised vector from a start point A to the end point B. Each point pair now has a directional vector.
However, this means that your particle AB now would travel in a straight line from start point A to end point B, which you don’t want since you want to keep in on the mesh and maybe introduce some other rules?

Let’s say your particle AB generally moves by getting its current position iteratively incremented by its velocity. Currently the particle moves step by step in a straight line until it reaches the end point B.

To keep in on the mesh, at each iteration, you simply move your current particle position by the velocity vector. Since this point probably won’t be on the mesh anymore, you simply look for its closest mesh point, which will be your next particle position.

At this point it is up to you to introduce other rules in order to achieve your desired trail. Your particle could cohere to neighbouring particles, only be able to travel down, or follow a vector field.

Here’s a simple Python example that is easily extensible:

mesh_particle_01.gh (34.3 KB)

You can simply introduce other manipulations to the velocity vector of the particle before finding the mesh point and updating the current position at each step.
You can for instance introduce your vector field and at each iteration look for the closest field vector to the current position and velocity. The normalised average vector between both will be your new direction, which follows the flow field and aims for the end point.

If you solved all of this on a particle level, you can extend the script with a particle system class that handles multiple particles and interactions between these particles (if desired).

1 Like

Do you have any thought about a plugin that makes a route along the flowing flines from the white points to the white points on the other side?

Another approach entirely would be to implement Kangaroo instead. Here’s an example of finding geodesics on mesh:

But I don’t see any reason why you couldn’t further define the behaviour you’re looking for (i.e. using Kangaroo goals to align lines, repel points etc etc.).

1 Like

@diff-arch @AndersDeleuran

I appreciate your work very much and now looking on both of them.
But first, thank you for your very clear explanation. I see you and especially @diff-arch put a lot of effort in helping me. :smiley: Thank you both. :smiley:

I have one small question to @AndersDeleuran, as I said, I am looking into both given examples.
@AndersDeleuran I tried to download the file but when trying so, Discourse says that the page does not exist.

I tried to mimic the component of that image, but I could not get it work. Do you might know what I am doing wrong (please, see file below)?

problem vector field curves 01.gh (62.5 KB)

Yes there appears to be some issues with the Discourse file server! Afraid I don’t have the definition on my workstation. That said, the logic I implemented was pretty simple (see the comments in my screenshot):

  1. Anchor the two polyline endpoints.
  2. Explode the polyline to its segments and vertices.
  3. Pull the vertices to the mesh.
  4. Minimise the segments lengths.
1 Like

Here’s an updated version of the script, where the particle also follows your vector field.
You can control how strictly the particle follows the field with the FieldCohesion slider. A value closer to 0 means less cohesion and a value closer to 1 more cohesion.

mesh_particle_02.gh (80.1 KB)

3 Likes