[RELEASED] Ara: the ultimate trail renderer

Does this support HDRP in Unity 2019.4?

 

Hey guys! I'm thinking of buying this asset, but wanted to know beforehand, is this working on mobile, especially on ios? And how performant is it?

 

Hi there,

Yes, it works on iOS. Performance-wise, it really depends on what you need to do with it. It's heavier than the built-in trail renderer, that's for sure.

 

hqCorner has uv problem..
AppendFlatTrail() need to fix..

Code (CSharp):

1. // Append smooth corner mesh data:
2. if (hqCorners && cornerRoundness > 0)
3. {
4.     for (int p = 0; p <= cornerRoundness; ++p)
5.     {
6.         vertices.Add(data[i].position + corner);
7.         normals.Add(normal);
8.         tangents.Add(tangent);
9.         vertColors.Add(color);
10.         //uv.Set(vCoord, curvatureSign > 0 ? 0 : 1, 0, 1);
11.         if (quadMapping)
12.             uv.Set(vCoord * sectionThickness, curvatureSign > 0 && sorting == TrailSorting.NewerOnTop ? uvWidthFactor * sectionThickness : 0, 0, 1);
13.         else
14.             uv.Set(vCoord, curvatureSign > 0 && sorting == TrailSorting.NewerOnTop ? uvWidthFactor : 0, 0, 1);
15.         uvs.Add(uv);
16.  

 

Trail move fast and turn steep..
Sometimes.. .vertices are sticked.

 

Hi there,

This is because high-quality corners need a minimum displacement to generate a rotation center that falls in the trail centerline. Trail points very close to each other, in completely opposite directions (right then left, up then down, etc) will cause this. It is specially jarring for thick trails.

You can either reduce trail thickness, or increase the min distance setting of your trail, so that points are generated a bit further apart.

Also, remember that we don't offer support trough the Unity forums. There's a support email that you should write to: ara(at)virtualmethodstudio.com. Thanks!

 

Hi,

This fix breaks uv coords. Quadmapping is not compatible with round corners (as round corners are implemented as triangle fans). May I ask what your use case is?

 

Code (CSharp):

1. if (nextSectionBitangent.sqrMagnitude > 0.1f)
2.     correctedThickness = sectionThickness / Mathf.Max(Vector3.Dot(bitangent, nextSectionBitangent), 0.15f);

Vector3.Dot(bitangent, nextSectionBitangent) is too small when trun 90 degree..

 

First of all: pretty please, send your questions to our support email (ara(at)virtualmethodstudio.com). This not an arbitrary request, the reason is that looking for messages here on the Unity forums (or private messages, facebook, twitter, random YouTube videos comment sections, etc) makes it much harder for me to offer adequate support as I have to regularly log in in these platforms to check. This increases the time it might take for you to get an answer, the chances I might miss your question, and the time I spend looking for questions everywhere. It's a lose-lose situation. Redirecting all input to the official support means makes it much more efficient for everyone.

Now, answering your original question: Vector3.Dot(bitangent, nextSectionBitangent) is clamped to 0.15 for a very good reason. When drawing high-quality corners, the corner vertices are calculated as the intersection of the previous and next trail segments. For wide angle corners, this looks quite good (1st image below). As the angle becomes more acute, the distance between these vertices increases (2nd image below). For very acute angles, the distance is extremely large (3rd image). It becomes infinite for a 180º degree turn, as the previous and current trail segments are parallel. So, by clamping the angle, we avoid this artifact (4th image):



If you need it, you can reduce the clamping factor to get sharper corners, or increase it to make corners less pointy in close to 180º degree turns. Hope this clarifies it. cheers!

 

Is there a supported method of having points persist indefinitely? Like ignore the lifetime variable entirely and just have the trail point stay forever. I could just make it really long but that seems kind of hacky....

 

Not really an intended use case, tbh. The entire trail is processed every frame to smooth it out, move its points if physics is enabled, change their thickness according to current length, make the mesh face the camera, etc. Adding points without ever removing them will eventually make the trail very costly to update.

I think you're looking for a line renderer, which is a different thing. There, points have no physics/lifetime/length dependent attributes, etc.

 

Lol that would've been a smarter idea. I used it to generate a pipe system and ended up utilizing the bake script which worked out really well. Only issue is that I need to be looking at it head-on or it'll render weird.

 

I have a few questions before I buy

• Is URP supported?
• I want to use it for tire tracks, are the generated tracks projected on the surface? I mean like decals, so there are no floating tracks above the surface
• Is is possible to fade out the tire track over time?

Thanks!

 

1) Yes.
2) No, this is a trail renderer, not a decal projector. Track trails are a triangle strip floating above ground.
3) Yes, you can fade them over time and/or length.

Let me know if you have more questions. cheers!

 

Yes one more question, does the tiled texture stay in place?
The unity trail render moves the tiled texture all the time and I want it to stay in place like a car trail does

Thanks

 

Yes, it stays in place and you can choose the anchor point for the uv coords. So you can keep the texture aligned with the start of the trail, the end, or any point in between.

 

Thanks, just bought it!

 

I have a question, the decal system that I use needs acces to the mesh.
But ara trails does not use a mesh renderer in the inspector, how can I acces the mesh created by ara ?
And is there a way to expose the mesh renderer before runtime in the editor so the decal scrip will not trow an error because it cannot find the renderer?

Thanks

 

You can access the mesh like this:

Code (CSharp):

1. var mesh = trail.mesh;

Are does not use a mesh renderer because for most use cases, the mesh must be re-created and rendered once per camera (since it is a camera-facing triangle strip). Instead it uses Graphics.DrawMesh. However it's easy to slap the mesh to a MeshFilter/MeshRenderer like so:

Code (CSharp):

1. using System.Collections;
2. using System.Collections.Generic;
3. using UnityEngine;
4.  
5. [RequireComponent(typeof(MeshRenderer))]
6. [RequireComponent(typeof(MeshFilter))]
7. public class TrailMeshFilter : MonoBehaviour {
8.  
9.     public Ara.AraTrail trail;
10.  
11.     void Start () {
12.         if (trail != null)
13.           GetComponent<MeshFilter>().mesh = trail.mesh;
14.     }
15. }

 

I just found I need to have acces to the renderer, and bake the mesh per frame to be able to use it
and the mesh needs to face horizontal ( the decals will project from the top down )

Any tips on how I can make this integration?



Thanks!

 

Hi @arkano22

Do the trails all batch into one draw call if they use the same material?

How is performance on iOS/Android? If I use these for bullet trails, so I have say 20 trails at the same time? Since they go fast they dont need to look so fancy.

 

Only if you have dynamic batching enabled. Even then, it depends on the complexity of the trail.

Using particle trails would probably perform much better in this case. Ara is better suited to less, more complex trails than it is to many, very simple ones.

 

Sorry, I didn't see this message. Please use the official support email for questions, as I seldom check the forums.

Ara does not have/need a BakeMesh() function because the mesh is always accessible. No need to copy it like the built-in renderer does. You can just do:

Code (CSharp):

1. var mesh = araTrail.mesh;

 

@arkano22 Hello, is it possible to choose sorting layer and order in layer (like in built in trail renderer)? Can't find it

 

Hi, just wanted to let you know that the link at the start of this thread is redirecting to store home page. I had assumed it was no longer available before I read through the thread and saw recent posts.

 

Thanks for bringing this to my attention! I've updated the link .

 

Seems like initial velocity is broken in latest version in Unity 2020.3.21f1?

 

Hi Jakob,

Works fine for me, can you elaborate? what's the problem?

 

@arkano22
Hi! I'm implementing replay in our game and I was wondering what method you'd recommend for recording state of a trail over time and forcing it to blend between previously recorded shapes. A naive approach would be to simply copy out the points collection at a certain interval and reapply it from time to time, but that would involve an array of arrays per every single trail, which is not very optimal. Since the trail I'm interested in capturing doesn't move any points over time, I wonder if it's possible to implement replay with a single array, capturing every point emitted throughout the history of a trail and intelligently overwriting main points array with the subset of captured one. Main point array constantly removes points based on lifetime, so it can't be the place to store replay data, but if it's fed points from a superset containing all points ever emitted, that could make for a fairly compact and low allocation replay format.

 

I think I got it working. I just saved a point out every time it was emitted, with 2 additional fields (creation time and end time based on start time and lifetime). Then, I added a method for sampling the trail from that collection of recorded points, where I feed in a time input and only the points which overlap the specified time get written into points collection, with life field being set depending on time remaining to recorded end time. That gives me pretty good replay capability, I can scrub to any point in time with no issues.

 

Hi! I have a little question about this.When I have only one special effect, it works well, but when I increase the number of effects to 30, it becomes worse.What should I do about it？

 

Is there a need to buy this? I assume that with the latest Unity versions 2020 / 2021 / 2022... most functions of this asset should have become unnessecary? Or are there still functions which I'd generally miss with the standard unity trail renderer?

 

Well, not much has changed in the built-in trail renderer over the last Unity versions. You'd still be missing trail interpolation, spline-based smoothing, trail physics, color over time/length, access to trail point orientation/thickness from scripts, and a bunch other things.

If you're not missing any of these from the built-in trail renderer, there's no point in using Ara.

 

Hello, is it possible to choose sorting layer and order in layer (like in built in trail renderer)?

 

Hi,

No, unfortunately it's not possible since as of now since this is not exposed by Unity in any of the methods in the UnityEngine.Graphics class, used by Ara to draw meshes.