You could use a ParticleEmitter to emit a solid-color circular particle at every trail position, with the same lifetime / transparency sequences as the trail. That way, if you look at it from behind, the trail will appear to be somewhat solid due to the circular particles, and won’t disturb the trail visually too much (?) when viewed from the side because it will have similar width to the trail. This will only work if your trail is a solid color though (and I haven’t actually tested if this will look good at all, just an idea that popped up).
Crude sketch:
I do this for the image I shared above (IMAGE EDITED OUT) for the front of the trail, and it works out pretty well.
The parabola thing is really just a procedural mesh, nothing more. And I’m pretty unlikely to ever make it publicly available because it’s such a narrow use-case and we can’t add much useful configurability to it. Maybe in the future.
I love Trails as they are and everyone else does too, I think what a lot of people are asking for is a sort of combo between Trail and ParticleEmitter/BillboardGui where the image always faces the Camera, that way there’s a sort of “pseudo volume” to the image that ParticleEmitters don’t really do right. This, and again I’d really like if there was some kind of Vector3 force setting (i.e. Acceleration) for Trails like ParticleEmitters have.
I would make a feature request topic but I don’t want to ask for too much, I know this is still a pretty new and advanced feature as it is.
Can we have some features for Trails that would make them configurable to a point where they can behave like flags or capes, or better yet some sort of separate cloth physics adornable?
Right now it feels like I’m rolling out toilet paper.
While you might be able to get the Trail Effect to act like a flag or cape, that’s really not what it’s designed for.
We do have another outstanding request for a cloth type physics object and we are looking into ways to be able to provide that type of functionality but we don’t have an exact solution or a timeline at this time.
Still, we welcome suggestions for new types of functionality and I would recommend creating a new thread in the Feature Request section to talk about what problems you are trying to solve.
Also - You may want to change the title from ‘Coming Soon’ - it could be a bit confusing for people who may not understand the meaning of ‘Live’ in production release terms.
Edit: More pictures
i think the rendering limits of trails shouldnt be focused on the lifetime ; rather a engine based maximum value of how many trails a device can display on the screen.
For example lets say on graphics 10 a pc would be limited to like hmm … 200 trails ?
so any new added trail would either be not visible until the lifetime of the oldest trail on screen comes to an end .
OR the newest trail would appear but the oldest trail on screen would go invisible or fully disappear ?
just a suggestion ,…, i dont know much at all about computer graphics …except of that most engines have a limit on how much is visible on the screen ; and not simply how long something is visible.
Since limiting how much is visible is optically sometimes more pleasing then annoying lifetime limits.
Why is this necessary? I can use twice the amount of trails I need in my project and I’m still not getting any frame lag. TheNexusAvenger was talking about a different problem, he wants the trails to have a max length for aesthetic purposes (not performance).
