I'm generating a trail from particles and then I want to turn this into strands.
Is it polywire the only solution in order to mesh it?
Polywire is very slow, with lot of particles it takes forever.

I'm editing this post because I realized there's more and it probably makes sense to explaining what I'm trying to achieve.

First off, here's a screengrab from a quick setup I did in 3ds Max with Pflow:



What I did in this case is pretty simple. I have a plane, deformed by some noise. The plane is moving and rotating from A to B to C.
I've selected a few vertex on the plane and within Pflow I'm emitting form the selected vertex. Than I'm creating the trail. I can choose what to use in order to mesh the particles, in this case I'm using spheres for both the tip of the particles (here in white) and the strands (in blue), but I can choose any other geometry or a different mesh.

Here's what I'm doing in Houdini.
I created the plane, grouped the vertex and created a Source Particle Emitter.
I've got rid of the Gravity, added a Pop Wind to add some noise.
Lastly, added a trail to the Source Particles and.. I'm stuck.
Particles are not connecting to each other, plus when I tried in a different scene with a generic particle emitter (with particles moving faster than this), they do connect, but the polywire slows everything down.

Any hints?

P.S. hope having modified my original post is fine and is not confusing.

Have a look at this thread:

https://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=34941&view=previous&sid=d6f822c43e5106f470d2a8062d669b45 [sidefx.com]

They present two methods there to render the curves directly and have them look like tubes.

Thank you Martin!

Hm.. it seems the methods explained in that thread are mainly about shading the geometry, which is fine only in my case I would need real geometry output, which I could modify after the fact.
Then, how to shape the geometry, that's another question, I'll look into that later (like for instance tapering it).
Unless deformations and tweaking the shape of the particles are possible with the methods described in that thread, than I guess I need to keep looking for an alt solution.

▲ ▲

Any idea?
I'm not sure what I'm doing wrong with my setup, but I'll keep trying.

Here's a screen shot and the file attached:

No one?

You could sweep the wires.
You could probably generate the tubes with VEX or VOPs, but that's rather complicated and a (big) speed gain is not guaranteed.


During development you can probably use fewer particles to speed things along.

Before changing the PolyWire, it looks like a huge chunk of the time is spent cooking the import_source node a lot of times on every frame. Since the Trail SOP is set to have trail length 100, try setting its cache size to something like 101, or maybe even 240, instead of 2. When it's less than 100, it may have to cook the import_source node up to 100 times on each frame.

Next, it looks like all of the trails are straight. Is that true in general, or does it just happen to occur in the HIP file you submitted? If you can Resample the trails down to have fewer vertices, any approach to making the wires would be much faster. If you want to adaptively resample based on how close to straight the curves are, it's a bit more complicated, but if you know that no changes smaller than 0.5 units matter, the Resample SOP is an easy way to simplify curves. That bottoms out at 12 fps for me with PolyWire's Divisions set to 8.

For the actual wire geometry creation, you can almost certainly get something that's *significantly* faster than PolyWire, but it'll be much less intuitive. If you're up for heading down that road, I can try to whip something together and explain it. In a nutshell, I'd be doing the following:

1) Create a single, triangulated, polygon soup tube at the highest resolution that will be needed.
2) Copy it for the maximum number of tubes that will be needed.
3) In the Attribute Wrangle SOP, with Run Over set to Points, with the first input (#0) being the tubes, and the second input (#1) being the trail curves:
3.0) If the current point does not correspond with a trail that has appeared yet, just set @P to {0,0,0}.
3.1) Figure out which trail in input #1, what proportion of the way along the trail, and which location around the circumference of the tube in input #0 this point corresponds with.
3.2) Figure out where the corresponding position is in the trail, that proportion of the way down the trail.
3.3) Figure out what direction to put this point in relative to that point in the trail, and set @P to that position.
3.4) Set @N to the direction from 3.3.
4) Add a visibility group, to hide the tubes that don't correspond with a trail that's appeared yet, just in case. (If this makes things slower, you can remove this step.)

It's a bit clunky, but this has the big advantages that:
* The topology isn't changing from frame to frame, and it was kept the same in a way that SOPs can track it, and the viewport will know that it doesn't need to re-send topology information to the graphics card. It also means that no SOP will have to waste time trying to figure out what topology to create, which is what PolyWire usually spends most of its time doing.
* Normals are automatically computed, and the geometry is already triangulated, so the viewport doesn't need to compute normals or triangulate the geometry.
* Polygon soup primitives are much lighter memory-wise than polygon primitives, and if you want to, for example, add a colour (Cd) attribute to them, most of their data can be referenced, instead of being copied. I'd recommend adding any colour before the Attribute Wrangle, if it's going to be the same on each frame.

The challenge: getting a consistent reference frame along the length of the trails, to avoid sudden large twists.