Pausing & Resuming Trail Renderer without timeScale?

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.

Spoiler: 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) :

Spoiler: Old Forum Thread

https://forum.unity.com/threads/can-i-pause-a-trail-renderer.141607/

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).

Spoiler: Rough Example

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

Code (CSharp):

1.  
2. float b = 1.0f;
3. Vector3[] a = new Vector3[TrailRenderer.positionCount];
4. TrailRenderer.GetPositions(a);
5. TrailRenderer.Clear();
6. TrailRenderer.AddPositions(a);
7. TrailRenderer.time = b;
8.  

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.

 

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.

 

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:

Spoiler: Quick & Dirty

Code (CSharp):

1. float trailTime = 1.0f;
2. float pauseTime;
3. float resumeTime;
4.  
5. TrailRenderer trail;
6.  
7. void Awake()
8. {
9.      trail = GetComponent<TrailRenderer>();
10. }
11.  
12. void PauseTrail()
13. {
14.      pauseTime = Time.time;
15.      trail.time = Mathf.Infinity;
16. }
17.  
18. void ResumeTrail()
19. {
20.      resumeTime = Time.time;
21.      trail.time = (resumeTime - pauseTime) + trailTime;
22.      Invoke("SetTrailTime", trailTime);
23. }
24.  
25. void SetTrailTime()
26. {
27.      trail.time = trailTime;
28. }

 

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().

 

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!