How do you implement trail into a real production?

Hello ! :smiley:

I have several questions about trails in a real production. My questions will be messy because it’s messy in my head (and I don’t speak english as a mother tongue, so sorry about that).
I have to make trails for differents character in our game, for differents attacks but I wander how do I really implement them?

I have decided to make mesh trail, out from a half circle instead of using normal trail.

But now I need to make them work in the game. Our programmers will be in charge of the code, but I’m trying to understand how i can make it work

So do you duplicate your mesh for each attack? or do you put 4 trails on the character Up, down, right, left? Do you use half circle or a circle? Do you attach the trail somewhere or only on the root? I have so many questions, I just want to know the process to integrate a mesh trail.

I’m the only vfx in ou studio and I’m lost x)

Thanks for your answers ! :smiley:

1 Like

Hey Kitiss, this can done in many different ways unfortunately there isn’t one straight answer.
The easiest i think would to add sockets, to the weapons/trail sources and spawn ribbons/trail particles form that as a source.

However this technnique will start to break if the animation is super quick or only has a few frames.
Another option would be to make custom meshes depending on the animation like Andreas glad’s tutorial: CurveSweeper - Intro to Houdini Engine // Houdini for Games on Vimeo

My advice, but this is coming from UE4 is to make your effects yourself with custom meshes and supporting particles inside the animation previewer. it looks like your working in Unity, so I’m out of my expertise here, but if there’s something similar to an animation timeline where you can trigger and position particle emitters you’d be able to get away with reuseing the above shown trail mesh you’ve made.

Hope this helps, goodluck!

Hello ! :smiley:

Thanks for your answer ! I know there’s several ways, but I’m just wondering which one should I use with a mesh. Because for exemple in an TPS when the character slash, it seems the trail don’t follow the animation but it’s the animated texture who follows the movement. But I can be wrong …

Yeah I’m working inside Unity, but it’s working more or less the same way as unreal :slight_smile:
So I made this mesh with my animated material and you, the way you make it, is to attach the mesh to a bone and make it rotate?

Thank you :slight_smile:

static mesh allows clean arcs for fast motion (clearly encircles hit_area for gameplay design as well) and will often need to be hand keyd with characters after imported into unity. keys are divided based on reuse triggered with mechanim(state-machine) and also to clean the division of labour between front_end / techart and vfx. when things change we want it to impact the least number of workers hours

1 anim ‘flash_’ - the on-off fade /tinting +any other material keys, scrolling etc … usually many of these are created with colors and timing on the arc prefab

1 anim ‘swing_’ = rotate a container, the mesh will be instantiated into this – the rotation will create the arc motion, usually only a few are needed for 90, 180, 360 w/ loop. again this is added in the mesh prefab

1 anim key ‘align’ = a container utilized in characters prefab to get VFX including ‘swing’ into the plane of action (diagonal, horizontal, vertical) – only needed if the character has numerous action animation. the less dynamic the less you need to align but usually for the future this type of setup is helpful

all of these anims are called in mechanim/state-machine. when characters execute a motion, pooling logic puts the mesh ‘flash’ into ‘swing’ onto the character and aligns it with the container, or inside it’s container if it needs local tracking motion

other VFX can be part of the align - these play simultaneously, or action triggers for pre-warm, and follow through’s. The align anim can cease updates just after the first frame.

pooling logic is used to migrate deactivated version(s) to characters when needed (rather than continuously update as multiple instances in every character) this way if 3 warriors have 6 different, single-swing attacks-- The maximum pooled into the world is 6 if all warriors do an attack at the same time… rather than x3 warriors needing each 6 on them == 18 instances

the same logic is used on VFX in general. no need to put your ‘fireball’ onto every character that can cast fireball. you’d want pooling to bring in the maximum number of instances needed. and when you want unique things added per character these are often placed in the character prefab, ( its own prefab played simultaneously through the state machine)
imho the build machine would strip out unique prefab as it’s own bundle and add it through front-end gameAnimation logic - as well as pooling logic; This is because should multiple people play the same character/ future-proofing the games ability to scale with assets

however… often much of the above may need to be flattened to save load time. it is always an agile dance in production.


Ho waw thanks ! :smiley: you said quite everything I wanted to know !

About anim key “align” do you put several meshes (vertical horizontal etc) already in the character but are called only when needed or do you put one and when it’s called depending on what’s called it will make some transform? What’s the best deal?

But ho my … thank you so much ! :smiley:

the align container would be on character prefab for its state-machine
swing is on top of the arc prefab with its state machine and parameters to call the action
and the mesh_ has a flash controller state-machine with its own parameters so you can mix-n-match colors + swing

getting them to play together will require a sandbox/proxy of gameplayAction (or debug console with an in-game debug area) – when setup it allows techart*/engineering to focus on supporting this rather than being involved in the nuance of characters in-game… so they won’t have to be involved when characters are created and iterated – but it is an investment that the art team (and they) will like down the road.

*depends if Techart / character techart handles all state-machine… I’ve seen this, and as it often involves interfacing with engineering for parameters/events to operate efficiently. i find it helps to have them oversee broad implementation to ensure art/engineering are working well with eachother and not inundated with authoring on the art, just a container of logic that allows artists to iterate + understand

1 Like