Has anyone been able to get the unity trail render to reveal textures rather than have the texture move with the trail?
I’m trying to do a classic RPG trail, and want the trail to render the smoke, and keep the smoke uv static in world space.
3 Likes
Nope.
It’s been a request since forever. When they did the update to the trail renderer for 5.6 it was among the features they said they were implementing, but they implemented the tiling option instead thinking that’s what people were asking for. They now understand what people were actually asking for (since nearly everyone immediately asked why the tiling mode was broken), but as they’re no longer actively working on the trail renderer there’s no eta for that feature actually being implemented.
And thus, most of us continue to use custom solutions. There’s a few on the unity community wiki and on the asset store with different levels of features, but most of those at least do tiling properly.
You can kind of hack it with the new tiling option by having another script that counter offsets the material. 
1 Like
It’s so weird. I’ve had many conversations with engineers and tried to explain how the UV layout should work on trails but they never seem to get it without three discussions and many pictures. Once the engineer put a counter panning texture on it and thought no more was needed.
The simplest way I’ve said it is that there are two UV sets.
One covers the entire trail from 0 to 1 on both axis.
The other UV set tracks with distance traveled.
As long as you have those two UV’s, you can synthesize pretty much any other layout.
Does that seem clear?
Anyone have a better way of describing it?
2 Likes
Having programmers misunderstand or straight up tell me it wouldn’t be possible to have a trail work the way I wanted it to is one of the big reasons I pushed myself to level up my programming skills. Eventually I rewrote the trail system myself for that project, then had a bunch of the features get broken when the effects system got a major overhaul later by another programmer, including the UVs again. To be fair it was way faster after it was rewritten, because it went from a mesh based system like what Unity uses to an instanced one. The funny thing is changing the UVs back to how I wanted them to work made it even faster since you don’t have to recalculate them every frame.
The conversation usually goes something like this:
No, really, I do want the UVs to be calculated from the oldest to the newest point, not from the newest to the oldest.
Yes we need to calculate the distance between each point for this.
Yes, it should be world space distances, and no, that won’t be super expensive.
No, we don’t need to recalculate the UVs every frame, only when spawned, yes I know it’ll stretch if the points move.
No, you’re describing a line / spline renderer. Yes, they are different.
Now let’s talk about sword swing trails … Yes, they’re different too.
1 Like
In your example does the 0 to 1 uv along the length of the trail get scaled by distance between points, or is it just “index / numPoints”, because the later is what I get usually until I get it corrected.
There was also one case where a programmer wanted to implement the over lifetime color using the distance aware 0 to 1 UV set and I had to stop them.
1 Like
index / numpoints
As the endpoint fades its life, the uv lerps away from that segment so that the endpoint is 1 just as we kill that point.
You’ve helped me clarify my thinking significantly! 
1 Like
The UV endpoint over “1” trick is a good one to mention too, as it’s a nuance that’s not obvious, even for veteran effects artists and graphics programmers. I used a similar trick (actually using over interpolated negative color values in my case) in the original trail renderer I wrote, but it got lost in the rewrite and I forgot about it until quite late in the project before readding it using UVs. I’d say that UV is more accurately lifetime / lifespan with the last point only getting removed when the next point is “dead”.
1 Like
This is indeed still sat on our Roadmap, but we do want to get it implemented! So I make sure I understand it correctly, the only thing you’re missing is the ability to have the UVs generated in the opposite direction, right?
It is the ability to generate UV on the fly. Currently you set X amount of tiles across the whole tail. Instead, we want to control the overall density of UV - an ability to “reveal” UVs as trail moves. Also, UV should not shrink/stretch across the whole trail. I can submit an GIF showing the behavior later.
Having the UVs in the opposite direction is how it’s easiest to describe, but that’s not actually correct either. For a trail with an “infinite” life, just having UVs start at the oldest point would “fix” it vs the existing Tile texture mode, but trails usually have a limited life span so this explanation is insufficient. More explicitly it’s that the UVs are static from when the point is spawned and never changed.
This is how trails with the Tile mode currently behave in Unity.
This is how nearly everyone expects it to behave. (Ignore the shading differences, this was a quick hack.)
It’s still world space tiling, but the texture “stays put” as the trail pans across the world rather than being dragged along with it.
The other things discussed above are “nice to haves” that increase the quality of trails, especially with out having to increase the poly count or modify older segments, specifically the negative color / “over UV” trick, neither of which would work with how Unity’s trails and general particle shaders work.
6 Likes
Some obvious programmer issues with this implementation:
“But then we have to store the UVs for each point!”
Kind of, yes. If you really don’t want to do that just accumulate the distance the trail component has traveled and counter pan the UVs. As I mentioned you can use this technique already to get the trail component to act like the “expected” example. (I didn’t do this for the example, I just used a world space shader because it was faster to write and worked in this very controlled case.)
“But the UV range is unbounded!”
Yep. A trail that keeps emitting forever will eventually start having issues with UV precision. It’s one of the reasons why having scale defined on the trail emitter itself rather than on a material is useful as you can do stuff like break the tri strip and wrap the UVs at some hardcoded limit and not have to worry about the UVs not lining up. Or you could just warn that this is a limitation, or have a UV loop setting, or counter offset the UVs across the entire trail once some limit is reached.
1 Like
Thanks Ben - that allows me to clarify our roadmap item covering the issue.
As you describe - it’s not as simple as calculating the UV’s in the opposite direction, so I’ll have to give some thought to whether to store the UVs per point, or attempt some kind of counter-panning solution.
I also want the Trails to vanish more gracefully, instead of the last point popping out once its lifetime expires. Just mentioning that in case it is something else that bothers you about Unity trails
[quote=“richardk, post:12, topic:2664”]
I also want the Trails to vanish more gracefully, instead of the last point popping out once its lifetime expires.[/quote]
With the way Unity’s trails and general effects system are setup, having the oldest segment “retract” (like an inverse of how the first segment “extends” while still attached to the transform) would go a long way in improving Unity’s trails. The two methods I mentioned, negative color and “over UV” tricks are both ways to accomplish that same effect as that, but you don’t support negative colors since vertex colors in Unity are using a byte vector, and the “over UV” is for when the trail color is done via a LUT rather than stored per vertex. They all require allowing the last segment / point to exist beyond their intended lifetime, and only die when the second to last point’s life has expired.
It is, and it would let you reduce the vertex count on trails more easily if needed as with the current trail system you generally need to keep the min vertex distance small so the effective “framerate” of point spawns is around “30 fps”. My example gifs above actually unintentionally highlight the problem just because I wanted to space them out far enough to make sure the wireframe rendering didn’t hide the texture. 
To be fair it probably still won’t get me to use the built in trail renderer most of the time. My ideal trail system is one that’s treated more explicitly like a particle system with control over individual point positions after spawn. Things like per “particle” starting velocity, gravity, noise, starting size, and even lifetime ranges (if handled properly) are huge for making trails useful for effects. Also having control over color and size by lifetime fraction on top of “over length”. It’s the difference between having a trail that just looks like a line drawn behind something and having a trail that looks like smoke. I also like to do things like having the main UVs be both time based and distance based and not purely one or the other so that if the trail is moving fast or slow can change the appearance of the trail to a degree, as well as have mostly stationary trail emitters for things like rising smoke.
2 Likes
If you haven’t seen it already, I’d love to draw your attention towards https://forum.unity3d.com/threads/release-ribbonized-particle-trails.488820/
It’s a step towards more controllable Trails, by offering a new Particle System option to connect particles based on their age.
All feedback welcome here: https://forum.unity3d.com/threads/feedback-ribbonized-particle-trails.488821/
1 Like
Did this ever get any further, i still can’t make the trail’s uv’s stay in world space…
Hey, no sorry it’s still not possible.
We added a few different UV modes, but we need to make a few more changes to do world space UVs.
ok, cheers for replying so quick…
Has anyone managed a method of doing this with the current tools? offsetting uv’s based on distance traveled? or similar?
Probably gonna get best results from writing your own trail renderer using the line renderer!
I have a script if you think its useful, it only works if you add length to the trail renderer but not when its length is reduced! 
and yes it’s doing what you suggested, offsetting UV’s based on distance travelled. I just had this lying around so maybe you can modify it to fit your needs. Perhaps using a dissolve shader and dissolve it as it expires?
6 Likes
Cheers Ludvig, thats look useful…
Hows things going, where about are you working these days?