Crop and extent line renderer

Hi there!

I need an advise about the line renderer.
I have a path a gameobject is following, and I need the player to see this path (its a list of Vector3). So I set up a line renderer going through the list covering every Vector3.
The point is, that while the object is moving over the path, the Vector3 points behind the object are deleted and the path is calculated further by that amount.

Example:
I have a path going through 6500 points (list of 6500 Vector3), the object moves along this path. After some time it passed 200 of those points. These 200 points are removed from the list and new 200 points are calculated, so the total path length is stable. I do that due to performance.

But to align the line renderer to the new path, I need to go through all 6500 points and pass them to the line renderer one by one, instead of cut away the last 200 points and simply pass the new 200 and leave all other points in between untouched (same way the list is handled). Is there a more elegant and less calculation-heavy solution?

Ah, and how can I choose towards which camera the line is facing? I have multiple cameras in action...

Greetings

 

LineRenderer does have a SetPositions() method so you could set them all at once.

System.Array.Copy() will let you performantly copy sub-parts of arrays around.

I kinda doubt that copying 6500 (or even 6300) Vector3 objects is actually causing a bottleneck... is it?? Did you see that this is a problem in the profiler??

I would more imagine that the bottleneck is in blasting that to LineRenderer, which in turn has to stand up all the correct ribbon geometry, including corners and mitering and facing the camera, to do what you want.

DO NOT OPTIMIZE "JUST BECAUSE..." If you don't have a problem, DO NOT OPTIMIZE!

If you DO have a problem, there is only ONE way to find out. Always start by using the profiler:

Window -> Analysis -> Profiler

Failure to use the profiler first means you're just guessing, making a mess of your code for no good reason.

Not only that but performance on platform A will likely be completely different than platform B. Test on the platform(s) that you care about, and test to the extent that it is worth your effort, and no more.

https://forum.unity.com/threads/is-...ng-square-roots-in-2021.1111063/#post-7148770

Remember that optimized code is ALWAYS harder to work with and more brittle, making subsequent feature development difficult or impossible, or incurring massive technical debt on future development.

Notes on optimizing UnityEngine.UI setups:

https://forum.unity.com/threads/how...form-data-into-an-array.1134520/#post-7289413

At a minimum you want to clearly understand what performance issues you are having:

- running too slowly?
- loading too slowly?
- using too much runtime memory?
- final bundle too large?
- too much network traffic?
- something else?

If you are unable to engage the profiler, then your next solution is gross guessing changes, such as "reimport all textures as 32x32 tiny textures" or "replace some complex 3D objects with cubes/capsules" to try and figure out what is bogging you down.

Each experiment you do may give you intel about what is causing the performance issue that you identified. More importantly let you eliminate candidates for optimization. For instance if you swap out your biggest textures with 32x32 stamps and you STILL have a problem, you may be able to eliminate textures as an issue and move onto something else.

This sort of speculative optimization assumes you're properly using source control so it takes one click to revert to the way your project was before if there is no improvement, while carefully making notes about what you have tried and more importantly what results it has had.

 

Thanks, thats a very good answer with more information than I asked for.
Exactly posts like yours are very helpful to improve the understanding of what we do while coding stuff.
My concern was that going through 6500 (less or more) positions and passing them each frame is a lot of work even for a computer. And you are right, it doesn't slow down the system yet, but its just a module in development that will interact in a way more complex scene later on.
Maybe using a few stretched billboard particles passing along the trail instead of a line renderer also does the trick then.

 

This is why humans (myself included!) are bad at guessing performance.

A single LineRenderer could have as few as 2 verts per segment (plus 2 at one end). I say "could" because I am not going to represent how the LR will behave, but I've seen it do as good as 2X, where X is the line position count.

A bunch of billboarded particles would need to all have positions individually computed to disperse along the line in a way that looks good, and each one would likely have 4 verts, and none of them would share verts with each other.

Therefore even a single stretched particle per segment of your LR would already be twice as many vertices as just using the LR. Any less and there would be gaps in your line.

Seriously, performance analysis is not something we humans can do. We need to use tools such as the profiler, and a methodical approach such as that identified above.

You should make your game and you should have fun doing it... odds are unless you go nutso crazy you won't have performance issues, and when you do, the steps above are the only reasonable way to approach the issue.

 

Well, I tried around e little bit, and while watching the profiler, calculating the line renderer for 10'000 points each fixed update (I did it there, cause the path also is influenced by physics), had an average of 0.82ms.
What I did now was set up a resolution-factor for the iteration; so with a factor of 25, the for loop will step up for 25 instead of 1.

for (int i = PathResolution; i < PositionList.Count; i += PathResolution)

{

PathLine.SetPosition(i / PathResolution, PositionList[i];

}

By that, the line renderer has to cover only 400 points, and for the player, it still looks very smooth. With that, the profiler shows an average time of 0.066ms. Good improvement with a satisfying result:



Result with 400 points for the line renderer over a path with 10'000 points (gravity simulation).

 

As I am learning here quite well, I would like to spin this thread some more with a related question.

I use the gravity prediction script two times at the same object, script1 and script2. Both are the same scripts and calculate the gravity influenced path ahead identical using a coroutine. I can let the script recalculate the path at will and it will do that from scratch.
Now, there is some anomaly I can't figure out. If I let one script recalculate the path in 'midair', its path will cover the other path precisely; so the calculation from scratch comes to the same result as it would without a recalculation.
BUT, if I disable the script just for 1 frame and make a recalculation then, the paths wont match. The starting condition for both calculations are the same (it always starts with transform.position and rigidbody.velocity as a base, those will be identical in both cases), the calculation are identical, the result isn't. Why is an identical calculation not really identical? Same calculation, same time, same parameters, parallel iteration, different result...

The blue path is recalculated after a short disabling of the script, the orange path is the reference:



The coroutine that calculates the path:

Code (CSharp):

1. IEnumerator CaculatePath()
2.     {
3.         IsCalculating = true;
4.  
5.         //Starting values
6.         Impulse StartImpulse = new Impulse
7.         {
8.             Position = transform.position,
9.  
10.             Velocity = Rb.velocity + GetGravity(transform.position)
11.         };
12.  
13.         ImpulseArray[0] = StartImpulse;
14.  
15.         //Calculations
16.         for (int i = 0; i < PathLength - 1; i++)
17.         {
18.             Vector3 CurrentVelocity = ImpulseArray[i].Velocity;
19.  
20.             Vector3 CurrentPosition = ImpulseArray[i].Position;
21.  
22.             Vector3 NewPosition = CurrentPosition + CurrentVelocity * Time.fixedDeltaTime;
23.  
24.             Vector3 NewVelocity = CurrentVelocity + GetGravity(NewPosition);
25.  
26.             ImpulseArray[i + 1].Position = NewPosition;
27.  
28.             ImpulseArray[i + 1].Velocity = NewVelocity;
29.  
30.             if (i % CalculationsPerFrame == 0) yield return null;
31.         }
32.  
33.         IsCalculating = false;
34.     }