koobas.hobune.stream
linerenderer lags behind object positions
Hi,
I have a problem with the line renderer lagging one frame behind the target positions. the line renderer positions are set to the position of two transforms like this:
for (int i = 0; i < Points.Length; ++i)
{
LineRenderer.SetPosition(i, Points[i].position);
}
I already tried using Update, FixedUpdate, LateUpdate and OnRenderObject to set the position. Neither of them worked. It seems like it is the line renderer itself which updates too late. Does anybody have a fix or workaround? Maybe changing the execution order or forcing the line renderer to update?
had the same problem and found a solution!
reposting my post:
Okay, there are multiple solutions to this.
The one I used in the end uses the Application.onBeforeRender delegate like this:
private void OnEnable()
{
Application.onBeforeRender += UpdateLineRenderer;
}
private void OnDisable()
{
Application.onBeforeRender -= UpdateLineRenderer;
}
If you dont want to use delegates, another way would be to move the script on a camera of your choice and use OnPreRender().
This function will not be called if the script is NOT on a camera!
private void OnPreRender()
{
UpdateLineRenderer()
}
sources:
https://docs.unity3d.com/ScriptReference/Application-onBeforeRender.html
https://docs.unity3d.com/ScriptReference/$$anonymous$$onoBehaviour.OnPreRender.html
Great ! Its Works Thanks $$anonymous$$ate
@michaelfelleisen hello, I had the same problem, and I used
void LateUpdate () { Application.onBeforeRender + = UpdateRoute; }
it worked on playermode, but as I compiled the game it doesn't work.
Peaj,
I have exactly the same problem. it's because the "UseWorldPosition" is checked. When I go local, no more lag.
no solution for now on my side.
I found out that in my case the problem is related to VR motion tracking. As the position of the controlers is being updated at the latest possible time the linerenderer would have to be updated even after that. Sadly it does not seem to be possible to change when the linerenderer is being updated. The same problem occurs when attaching UI elements to the controlers btw.
indeed, exactly the same prolem for me. In VR, I attached my line to the controller ... So, I have this "lags". (I had already noticed the concern with the UI, but it was less disturbing ...) there is still a real problem ... Too bad the late update is not triggered after the detection of the position of the controller.
use lateUpdate to update the points because setting position when its rendernig cuase the lag try late update works well,use Late Update
The LineRenderer does not have its own update cycle or anything. So putting your code in different update functions won't change anything, at least not for the LineRenderer. It's the code itself that lags behind for some reason.
First off, you can make sure the loop isn't faulty by removing it. Use LineRenderer.SetPositions instead, which sets all points at once rather than one by one in a loop.
Then, check the code that puts the data in your Points array. The data that is put in this array might actually be a frame behind. For example, if your objects move in Update and your script reads their positions in Update as well. Since you tried LateUpdate (which is a good idea in this case) and it didn't work, your problem seems to be more complex. Can't tell more though without knowing the code in question.
Thanks for your reply. I already tried SetPositions and it didn't make any difference.
The linerenderer connects 2 objects. A kinematic rigidbody which is a child of a S$$anonymous$$mVR controller and a non kinematic rigidbody which is connected via spring joint.
The offset happens at the controller child. I can only get rid of it by using local space for the linerenderer which then leads to an offset on the other end.
So maybe the problem is when and where the S$$anonymous$$mVR controller positions are being updated. I thought it should be Update but maybe I'm wrong.
Then again it seems odd to me that updating the linerenderer in LateUpdate does not work because it should be right before rendering and could only be wrong if transform positions change after LateUpdate. I really just use the transform position (of a child) of the controller object.
