This trail renderer example was working, and now seems to be broken in the latest version of the engine.
Issue: After a few seconds, the end of the trail seems to be stuck to the center of the object.
Here’s a third party mod on the trail renderer. From the video, you can see that it used to work, but it’s not working in the latest version of the engine.
Issue: After a few seconds, the trail disappears.
I’m not sure if the two issues are related ( dynamic mesh modification )
I’m not sure I can reproduce the issue … it seems to work ok for me over a 30 seconds I tried? Can you show a screenshot of the problem?
You can see the end / green part of the trail is focused on the center of the screen, rather than following of the “ribbon”
I cannot reproduce the issue on my side too, that should be something browser/device specific.
I haven’t had an issue with our wip game, using Unity WebGL here. This is way more complex of a project than the trail renderer, and it seems to handle the graphics end of things well.
I’m using Windows 10, GTX 1070 ( latest drivers ), Microsoft Edge. It also happens on Chrome.
How bizarre, I haven’t seen that issue either. That build in the screen above Mal is from an much older build. 1.35.2
Do you have a high refresh rate monitor?
April 15, 2021, 3:30pm
Hmm, I don’t see the problem on my side. The trails look fine. I tried on:
Ubuntu / Windows, GPU Potato, Edge / Chrome
This is it running in Chrome, played from the editor…
Any errors in the developer console?
The laptop screen runs at 120Hz, I have a 2nd monitor attached as well that runs at 60 - I see the issue on both.
I’m not seeing any errors on the developer console.
I’ve just tried this on Edge with a Windows 10 VM and can’t replicate there either
It looks like a logic issue and the last lot of vertices are not being updated but why only your machine
April 16, 2021, 12:02am
I was able to reproduce this by changing the timer incremental step. After digging the source code, it appears there are a couple of issues.
@Mal_Duffin could you check how does my fork works for you?
Performance optimization. Preparing the vertex data loop can be shortened, because the vertices array (depending on the vertex life time), may be much larger than the resulting typed array, so we can break the loop early.
The issue is in the variable size of the vertices array, which then dictates the number of indices that the mesh should consume. Depending on the frame’s delta time, the vertices array can grow, and as a result the vertex buffer will use invalid indices in the last part of the buffer. That part will depend on the indices overflow size - this is the erroneous part of the ribbon on the screenshot. I changed it so that the amount of indices is limited to either the vertices array length (double of it actually, since it contains vertex pairs) or the constant max vertices, whichever is smaller.
The reason it “worked” before, is because the last part of the ribbon didn’t live long enough to show the problem.
@LeXXik, I look at that when I’m back in the office on Monday
@LeXXik - that worked great!