Pausing & Resuming Trail Renderer without timeScale?

Unity Engine
,
1

Good morning, Everyone.

I wanted to know how one might go about “pausing” or “freezing” a trail renderer (without the use of Time.timeScale**)** and then resuming afterwards.

RTM Crowd The manual mentions that “all points inside a TrailRenderer store a timestamp when they are born.” TrailRenderer.time counts forward from this point to determine how long the trail will be onscreen. However (as far as I can tell) this “timestamp” is not exposed anywhere and cannot be directly altered.

A handful of Internet searches all turned up the following thread (though I didn’t find it particularly helpful) :
Old Forum Thread Can I pause a trail renderer?

The “freezing” effect itself is easy enough to achieve with:
TrailRenderer.time = Mathf.Infinity;

This effectively prevents points from reaching expiration, but it doesn’t actually suspend their aging. As such, setting TrailRenderer.time back to its previous value causes all existing “frozen” points to immediately expire all at once (if they are already older than the specified amount of time).

I also tried using TrailRenderer.GetPositions, TrailRenderer.Clear, and TrailRenderer.AddPositions (together in that order). The result was visually identical, with all points appearing to expire at once (and with no new ones added).

Rough Example

For a rough example, this was something along the lines of:

float b = 1.0f;
Vector3[] a = new Vector3[TrailRenderer.positionCount];
TrailRenderer.GetPositions(a);
TrailRenderer.Clear();
TrailRenderer.AddPositions(a);
TrailRenderer.time = b;

Performed after the trail has had time to create visible points.

Thank you in advance for any and all assistance you may be able to provide.

1 Like
2

The short answer is that i don’t think you can do it.

The slightly longer answer is that, as you already deduced, the timestamps attached to each point are not exposed in any way. In theory, we could add a Pause script API, that keeps track internally of how long it was paused for, and advance the timestamps of all points, when unpaused.

Or we could expose the timestamps. I have thought about this in the past, but it seemed like it would expose something that was quite easy to break (eg new edge cases such as changing the birth/expiration order of points in the trail).

EDIT: Perhaps there is a 3rd party trail renderer on the Asset Store that can do it…

2 Likes
3

Thanks for your reply @richardkettlewell . I felt certain that there had to be a multiplier or something similar that I was overlooking or misusing. I’m rather glad to know that at least I was not missing something obvious.

I suppose I could manually keep track of how long a trail is meant to be “paused” and set TrailRenderer.time relative to that value. I haven’t tried it, but I suspect that this would cause the trails to take progressively longer to expire after every pause/resume.

I’ll have another look at the Asset Store and consider alternatives to the trail renderer in the meantime.

1 Like
4

Yes, extending TrailRenderer.time by the duration of the pause would work, but only for pre-existing points. Any new points spawned after the unpause would have the new, longer lifetime.

1 Like
5

So then it could be “cheated” afterwards using something like Invoke() to restore the desired lifetime after a specified period following the resume (not that this would be an elegant solution by any stretch of the imagination).

EDIT:

So, out of curiosity, I tested this. It works well enough for the purpose of demonstration. Here’s another “quick and dirty” example:
Quick & Dirty

float trailTime = 1.0f;
float pauseTime;
float resumeTime;

TrailRenderer trail;

void Awake()
{
     trail = GetComponent<TrailRenderer>();
}

void PauseTrail()
{
     pauseTime = Time.time;
     trail.time = Mathf.Infinity;
}

void ResumeTrail()
{
     resumeTime = Time.time;
     trail.time = (resumeTime - pauseTime) + trailTime;
     Invoke("SetTrailTime", trailTime);
}

void SetTrailTime()
{
     trail.time = trailTime;
}
3 Likes
6

Nice hack! :smile:

(just beware if you re-pause before that Invoke fires…)

2 Likes
7

Thanks! And yes, I did notice that. It should be a simple matter of canceling any pending Invokes ahead of PauseTrail() and/or adding a condition to SetTrailTime().

2 Likes
8

I replaced Invoke with a manual countdown set to trail time on Resume and decreased in Update, when the trail is not paused itself. When the countdown reaches 0, I reset the trail time.

If a second pause and resume occurs before the end of the countdown, the countdown is simply reset to trail time, so we delay the trail time reset. It works fine!

1 Like