[RELEASED] Ara: the ultimate trail renderer

Hi everyone!

A few months ago we were looking for a versatile trail renderer in the store, but noticed that none of the existing ones covered all our needs. Sure, there's specific trail renderers tailored for this or that use case, but unfortunately not flexible enough to be the one and only solution used regularly in multiple projects.

So we made our own that we've been using internally for some time now, and decided it's time to share it with you.

Ara is a trail renderer that can do most of the stuff you'd ever want a trail to do:

• You can enable/disable emission by just using a toggle.
• Combines time and length based curves for color and thickness.
• Can emit trails both in local and world space.
• Spline based smoothing (specially useful for fast moving objects).
• High quality corners: sharp, blunt or round.
• Supports view-alignment, local transform alignment or constant alignment.
• 100% scriptable: you can get the current list of points in the trail, modify them, remove or add points, or you can provide your own list of points every frame.
• Each point provides: position, velocity, lifetime, color, orientation, thickness and continuity information, not unlike particles in a particle system.
• Physics: gravity, inertia, damping...
• Extremely performant: zero garbage generation/frame.
• Clean & commented C# code included, runs in all platforms.

It also includes a few scripts that use its API to cover specific use cases (skid marks, electrical arc effects), to get you up and running.

We've used it to make tron-like vertical trails, electric jolts, dynamic smoke, weapon trails, skid marks, as a 2D/3D line renderer, and tons of other stuff. I hope it will prove as useful for you as it did for us .

It's going to be available in 1-2 weeks. Its price will be 30$. Let me know what you think!

PD: In case you're wondering, "ara" is maori for "path" or "trail".

 

Ara is now available in the Asset Store:

Ara Trails

Plans for the future:
- Built-in tools for easier line rendering.
- GPU-based trail generation, for accurate shadows and faster rendering.

Any feedback is most welcome!

 

Fantastic asset! Really happy with how this is setup and documented.

I'm having some performance issues though once the trail exists for more than 2 seconds or so. The profiler shows me a ~10ms spike for Scripts under the Camera.FireOnPrecull() function. I'm on unity 2017.1 and I'm in VR (Single Pass Stereo). Any help is appreciated.

 

Hi knup_!

Glad you found Ara useful! .

If you could share a profiler pic in deep profile mode, it would be very useful to diagnose this. 10 ms is way too much for trail rendering, so I'd bet there's something else coming into play, or the trail geometry is exceptionally dense.

PD: you can send the pic to our support email (found in the .pdf included with the asset) so that we don't clutter the forum with back-and-forth support messages

cheers,

 

Thank you for resolving this issue so quickly over email. Great asset and support!

 

Get it here or any of our assets and help us with this affiliate link https://goo.gl/gUwoUJ

 

Does Overall > Space > Local mean I can render a trail on a child object, and the visible trail will also inherit the parent object movement?

Thanks for helping me understand. I need something like that for an endless game with "treadmill" style world movement.

 

Here's the explanation of both modes:

Local mode: the trail component is added to a child object, parent movement will not cause the trail to appear. Only local-space movement (that is, when the child moves relative to the parent) will cause the trail to appear.

World mode: the trail component is added to a child object, both parent movement and child movement will cause the trail to appear. That is, As long as you see the child object move in world space, a trail will appear.

cheers!

 

Ok cool. Thanks for the explanation.

Do you know any way to move an already rendered trail with a parent?

Kind of hard to explain. Perhaps an easy example would be a character running while spinning a revolver in his hand. Even though the character is moving forward, having the spinning gun produce trails within local space instead of world space.

 

That's exactly what Ara's local space mode does.

It cannot be done with Unity's default trail renderer, which is always generated in world space. Also, since it does not give you access to the rendered mesh or the trail points, you cannot move it yourself.

 

Sold! Plus some nice features in there as a bonus. Will download shortly, appreciate your help.

 

Just want to mention that it's working out great! A nice set of editor features and things you can do in code. It's proven to be very useful in my case.

 

I'm glad it works good for you! If you could write a small review in the store, it would certainly help us

 

Unfortunately, I can't get this asset to work while using the Lightweight Render Pipeline (LWRP), I am using Unity 2018.1.2f1. Please help, I don't want the money I paid to go to waste.

 

hi, im lokking to buy the trail renderer, but before i have 2 questions, in my project, with the standar unity trail renderer i have 2 problems:
the trail is for precise movements (up, down, left, right only), and in the corners, when i change direction i get this error in the mesh, so the mapping of the texture break there


also, the mapping, even if i choose to tile, its wrong, like repeating the last part of the texture, so the middle part is only shown in the start of the trail and nowhere else.
using this texture:

i get this result:


can you confirm me if your Asset is good for my case?

 

Hey, even though I'm not the developer, from my testing I'd say this asset is perfect for what you are going for!

 

I don't know where or if I can request a feature, however, I really think there should be an option to add an offset to the trail! It would really help with cases where you can't have the trail on a child object.

 

Hi, I have a performance problem with this asset, even after lowering some settings it still takes about 10 ms for 4 trails each 5 seconds long. Also, it attaches itself to any camera rendering so the performance cost is multiplied. Is this expected?

 

Hi there,

Depending on the density of your trails (how many points they spawn per time/length unit) yes it could be normal. Keep in mind this is a managed (C#) plugin, while Unity's own trails are completely unmanaged so they will have better performance.

Also, trails should be rendered from each camera and they should orient themselves to that particular camera point of view, so the trail mesh must be recalculated for each camera rendering them. This is just the way trails work.

 

Why couldn't you have the trail on a child object? As long as the simulation is performed in world space, it will behave exactly like it would using an offset. I cannot think of any situation where this would be an issue...

 

So sorry for the late response. I actually did use a child object in the end, I was just suggesting that It would be a nice feature to have.

 

Found it is pretty heavy on the camera.fireprecull() . Unfortunately not usable for me on mobile / VR projects because of the hit it takes. Took up around 50% of the CPU at 18ms for I believe 6 trails in the scene.

 

Hi, using Ara Trail Renderer is it possible to force the alignment of the trail so it always spawn in a fixed direction? example: you move a sword pointing forward, the trail does not start spawning perpendicular to the sword movement, Unity Trail Renderer does this and most other assets we tested also have this issue.

Is it possible to change the trail size dynamically during gameplay? like a sword changing size while the trail is playing?

Thanks!

 

Yep, just use local alignment mode and orient the trail so that it points along the sword. The promotional video starts with a guy wielding a sword, done using this method.

To change the size of the entire trail (including the already emitted one), simply set its "thickness" value at runtime. Note that another value ("Initial thickness") allows to to change the size of the trail that will be emitted from now on, respecting the existing trail.

 

Hi @arkano22, We are noticing a large amount of time spent in culling from the ara trail renderer in VR. I note that another user above had the same problem, is it possible we are using an outdated version of the asset, or is it just quite heavy on the culling in general? In particular, I'm noticing large spikes in FireOnPreCull in the camera when I rotate the VR hat from side to side, and a big drop in culling when I disable the trails (we have 8 running)

 

Hi Alex,

FireOnPreCull does not perform any culling by itself. It is a method called by Unity right before camera culling takes place, trails use it to generate and render a mesh oriented to the camera that is going to perform culling. This is important to ensure the trail looks at the camera.

In VR with 8 trails, you're effectively building trail meshes 16 times per frame. Keep in mind however that DeepProfiling has a great impact on performance and measured times, however.

 

Is there a way to keep the tile textures in place (for example car tracks, after some time tiles are pulled in)

 

Hi,

Simply increase the duration of the trails ("time" parameter)

 

I'm trying to make it work with LWRP in one of our projects but I'm unable to do so , what am I missing?

 

https://www.reddit.com/r/Unity3D/comments/9ieosd/did_the_new_scriptable_render_pipeline_system/

Seems that the SRP and the Graphics API (which we use) do not play nice with each other yet.

 

Didn't solve the problem, since after the time passed, the trail is pulled in! The tile texture have to stay all the time at their fixed position (until they have completely disappeared). The trail is all the time on.

 

Ok, so you want the entire trail to have a lifetime, right? So that all points disappear at once.

You can set the time parameter to infinite (or a very high value), then disable the entire trail itself when too much time has passed, using a custom script.

Or, since you can modify the trail points, simply set their lifetime to anything you deem appropriate. For instance, once you find a discontinuous point in the trail, set all lifetime values until the previous discontinuity to a given value. That would make each trail "segment" disappear at once.

 

Hi there. I recently got the Ara Trails package but it is not working as expected. I am using Unity 2018.4.1f1

The ElectricalArc and Walls sample scenes work fine but MiscTrails, SwordTrail and TireTrack do not work.
There are no trails rendering for those scenes. Have you seen this before?

 

Hi @arkano22
We've recently been using your ara trails package and are really enjoying it! However, we were wondering if there was a way to change the sorting layer of the ara trail as we would like the trail to render above our sprites which are set to a higher layer than the defualt. Is this possible?

 

Have you thought about updating the plugin using c# jobs?

 

any updates regarding this issue?

 

Hi there,

In LWRP, Unity does not call the usual rendering callbacks. Special callbacks are used. Replacing Camera.onPreCull with RenderPipelineManager.beginCameraRendering in in both OnEnable() and OnDisable() enables LWRP rendering.

If you write to support, I can provide the updated script. The next version will include the ability to switch between both render callback functions.

 

Using jobs for this task has zero advantages, as trail generation is not paralellizable at all. It is inherently serial, as each trail point depends on the data calculated for the previous one, you can't calculate each point independently. So we won't be using jobs.

However, using the new mathematics library and vectorization should help, so we're evaluating it.

 

Wouldn't it make sense to calculate all the mesh data outside the main thread? In any case I was talking about parallelizing multiple trails. Currently the perf cost of trails scales linearly with the amount of trails.

 

Thing is, trails must be oriented to the camera you're currently rendering with, and each trail might be rendered by different cameras. So you cannot decouple mesh calculation and rendering, at least I cannot think of a way to do that right now (might be doable by expanding the trail points in the vertex shader, but that would require to use custom shaders). Will think about it, there's potential gains to be reaped there.

 

I have the same issue @arkano22. How exactly does rendering work for this asset? The trail seems to render as if it's set to Sorting Layer = Default and Sorting Order = 0. In 2D, regardless of its world position, it always seems to render in that order. This is an issue for me because I use sorting layers/order for a lot of things, and it's unlikely that I would want every trail to render on the same level.

 

I think most usecases have only one camera rendering. We had the asset from other project and would have used it for performant missile trails (you can have a hundred of these in the worst cases).

 

We use Graphics.DrawMesh() to perform rendering. As far as we know, Unity does not (yet) allow to set sorting layers when using DrawMesh(). Can only be done with the built-in renderers.

 

Well, in editor you have two cameras being rendered: the game view camera and the scene view camera. Many people have both visible at once.

Having a special codepath that only works for one camera, and doesn't work properly in editor, does not sound good to me.

 

Yeah it wouldn't be pretty for most users. In our case we managed to get what we wanted by using a global particle system with trails (which by the way, drag the texture along so you have to config them just right -_-) and updating the particle positions manually, though we lost culling as a result.

 

Oh okay, that's disappointing but thanks for the reply. I might be able to work around this for my use case because I'm only using the trail in a specific situation, but this definitely limits the asset's viability in 2D. If Unity enables a way to support sorting layers in the future then please consider implementing it. This asset generally works better than the built-in Trail Renderer (no more jagged lines!), and it would almost be perfect for 2D if not for this one factor.
Still, good job with the asset anyway; overall it's a lot less unpredictable and error-prone than the built-in one.

 

Hey, bought the asset last year at some point, very happy with the rendering and the results. Have not touched it since initial testing, and have a basic question:

I am using the trails for wingtip vortices, and would like to toggle emit on/off based on a value. Is there a quick & dirty way of doing this? I saw there's an emit toggle just like unity's trails, so I am guessing it's trivial?

(Sorry, haven't checked documentation yet, thought I'd just try it here first)

 

Turns out I should've just checked the example scripts, it *was* trivial

BUT: a follow-up question!

Can I access the "initial color" value? I'd like to try and tween this instead, as right now turning the emit on/off results in some choppy visuals, where the trails cut on/off at the threshold value...

 

The use case that matter for performance is the game context, where there is usually only one camera used to render the trail.