Trail mesh with uvs [COMPLETED]

Hi! I would like to implement a custom trail vfx on a transform node with the trailMesh, using a uv animated texture. Mainly to keep perf as high as possible. Eyeballing the src, it seems the trailMesh uses a tubular ribbon. I’m not certain if the texture will map around it correctly. Should I roll my own custom trailmesh or is this one up for discussion?

1 Like

The TrailMesh class updates positions and normals for the trail vertices each frame. I’m not sure how using an animated texture would help gain some performance? I think you would want to use an animated texture instead of creating and updating new vertices, in which case TrailMesh won’t probably help. Note that setting a texture to the TrailMesh material won’t work because no texture coordinates are generated for the trail vertices.

By uv animated texture, I meant to keep perf as high as possible w/o sacrificing artistic flexibility. It could be done with just 1 user authored 256x256 grayscale texture in an nme (blended with alpha, noises etc). So its perf should not be adversely affected even for thousands of trails on screen.

Exactly, the src doesn’t seem to be setting uvs, which is why I’m raising this request. A PR to make the trailmesh be setup with UVs so users can use textures in its material. I don’t want to create/update trailmesh vertices, just hope to have texture coordinates added for it.

It opens up a new can of worms, as UVs mean billboard settings as well and many other stuff. Lemme see if I can find a unity equivalent to illustrate the use case better…

I found these off a quick look on YT:
ghost trails
tut on stylized trails
and loads more, just search vfx trails as keywords.

future ref, this is for trail mesh creation which is another big topic in vfx itself:
sword slash

Do these help ?


This PR adds texture coordinates to the trail mesh:

Once it is merged, this PG will work:



Couple of stuff
a) the UV seam is along the back of the trail mesh, I could rotate the texture ( But it would be nice if users could author textures according to left-right convention instead of up/down?
b) the four verts right at the start of the trail mesh is compressed so when the cube rotates, you see an inconsistent presentation, ie, transparency on 1 side, breaking the trail effect.

I’m wondering if the ribbon should taper off or it should remain as a flag? hrmm…

I turned on wireframe and noticed that the trailmesh is really dense, the inspector is showing 1k faces for trailmesh in above PGs. Could there be an option for the user to select the number of segments they need ? akin to what the meshbuilder already uses?

const trail = new BABYLON.TrailMesh("new", cube, scene, {options}, true);

So options now hold diameter, length, segments etc. Oh, we could have a doNotTaper flag in the options. Textured trails would prefer not to taper off the trailmesh while non-textured trails can choose to. Will this break back compat?

1 Like

The japanise answer with a Katana sword :slight_smile:
trail in GPU | Babylon.js Playground (


I think that the “right” orientation will depend on use case / texture. You can use the texture properties (u/vScale, u/v/wAng, u/vOffset) to make it fit the way you want.

As for your other comments, we could certainly improve the TrailMesh class, if anyone wants to take it on!


My schedule opens up March/April, I can submit a PR then.

1 Like

To all those interested/using trailmesh, I’ve upgraded the codes in the below PG. Its a breaking change if committed, so I’d like to gather as much feedback as possible. No idea who else/devs might be interested, pls help ping as well.

Try it out, play with it. Lemme know what else is wrong/missing/needs rework. Off the top of my head, I’m thinking of modifying _sectionPolygonPointsCount to cater for non-square meshes, maybe, circle or simple plane. But I don’t want to overburden devs/bloat the repo unnecessarily.

Thanks for reading, cheers ! :slight_smile:

Local bjs repo fails npm install :(, might commit via other means, no rush for now…

1 Like

What is the breaking change ? and could both behaviors not stay in the code for back compat ?

Deprecating the original constructor:
const trail = new BABYLON.TrailMesh("trail", sphere, scene, 1.5, 100, true);

With the new constructor:

let opts = {
const trail = new BABYLON.TrailMesh("trail", sphere, scene, opts, true);

A one-liner upgrade, if you will.

Do we want to keep the old code? Did we keep the old code for mesh creation? I dun remember…

  • Added sections in options. Users can now create trails with circular cross-sections (sections:8/16/whatever) or double-sided planes (sections:2).
  • Fixed a bug with incorrect normals in update();

Can’t think of anything else to add, I guess this is as final as it will ever be…now to get my blasted local repo to work…

1 Like
 // put the last bool parameter of the new interface into the opts obj
class TrailMesh {
 constructor(name, mesh, scene, optsOrDiam, len?, someBool?) {
  if(typeof optsOrDiam === "number") {   
     //old interface
  // ...

There goes my beautiful constructor! :sob:

In other news: I made a little demo. This feature request is solved! Enjoy!