[RELEASED] Customizable Weapon Trails

Asset Store Link

Web Player Demo

Advanced Customizable Weapon Trails features over 50 Particle Renderer trails and over 140 Trail Renderer Trails (12 textures each with 12 preset color/opacity combinations). Weapon Trails will work with any sized weapon and with any attack motion, not just a simple swipe.

All of the Demo Weapon Trails are included as prefabs, along with an extensive PDF explaining how to modify the trails to make your own, custom trails. Our trails are built from textures we designed specifically for this purpose in Photoshop, and the textures are included. All of the sizes, colors etc are very easily editable. No matter what kind of attack animation your models do, these trails will work. Swipes, slams, 360s, jumps -- all of it works with these trails.

Watch this thread to get updates.

 

Watched!

 

+1

 

I'm subscribed

 

Web player demo added!

http://www.sfbaystudios.com/weaponTrailsDemo.html

 

Demo updated to include two new animations in the rotation that show the look of attacks that aren't a simple "swipe" -- circle, jump and vertical slash attacks look great with these weapon trails.

 

Has been submitted to the asset store, pending review. If not today, probably monday or tuesday, unless they work weekends

 

Released!

 

Currently the web player link on the asset store page is leading to the wrong demo. We've submitted the update and added a link to the correct demo on the page it leads to, but the correct demo URL is: http://www.sfbaystudios.com/weaponTrailsDemo.html

 

Can u make camera in demo freely movable

 

Well, the character is moving -- do you mean just moving around in circles?

 

free camera so I can see the trail from different angles.

 

I'll see what I can do this weekend.

 

Weapon Trails is part of the Medieval Melee Sale! 50% off!

https://www.assetstore.unity3d.com/en/#!/content/20401

 

Can you add a demo scene so we can preview easily.

Also, I noticed your system uses AnimationEvent for Start/Stop, so it will have issues with animation blending as here. No fault of yours, but something Unity is "refusing" to fix

http://forum.unity3d.com/threads/un...on-developers-or-interns.268086/#post-1827616

 

There's a demo scene already posted on the page: http://www.sfbaystudios.com/weaponTrailsDemo.html

You can cycle through the effects. There's dozens of weapons you can cycle through as well, and modify the position offset of the trails so you can see what they'd look like for short weapons or long weapons etc. Some work better with others.

I'm not sure what you mean with the AnimationEvent? It's pretty simple -- just activate the trail object and it'll play, otherwise it won't.

 

I'm talking about a demo scene in the package. It makes it easier for people to see which to use, eg Trail12 doesn't really make a lot of sense to me.

The AnimationEvent is not about your package but the way Unity does its Animation Event. You expect two AnimationEvent to start/stop the fx, but when doing blending, Unity may not call the Stop event. You can read more in that thread to understand more about it.

 

Ah. Well, the trails don't have names because I didn't really want to think of clever names for them all, so instead they're numbered. The numbers correspond to the web player demo, if that works easier.

Perhaps a work-around for the animation even is to call it multiple times with a random number generated at the start of an animation, so that you don't accidentally stop one that shouldn't be stopped? I'd put the 2nd one in the start of the 2nd blended animation clip.

Or perhaps if you know the length of time the attack is active, then you could simply use a timer?

For the game I'm working on, I've noticed that from time to time and hadn't really figured out what was causing it (so thank you for letting me know!). It happens to me when the player gets hit in the middle of an attack, so I suppose that when I set all the "got hit" booleans and what not, I'll also specifically stop the emission on the particle. That could be the best bet -- identify what situations the problem may occur, since it's likely all non-normal situations, and add a line of code to disable the emission when that situation happens.

 

If you can a demo scene which shows the trails, it is better. I don't refer to the webdemo always but when I import in a new project.

Your best workaround is the timer but it makes the code setup quite ugly, especially on larger setup. I personally think Unity should fix it , but it it's not getting attention because some users don't see it as a problem and Unity QA don't think so too. Perhaps you can also add to that thread that you are facing similar challenge.

 

Unfortunately I can't do a demo scene with other peoples assets, and I do not have weapons/character/animation that I have made.

 

Hello @ sfbaystudios haven bought your rpg barbarian and weapon and asset, i decided to check your "weapons trail advanced and customizable" but i was not impressed unlike other product of yours. From the web player demo i watched, it the weapon trail curve is not smooth, it also seems slow(it still plays way after the animations. Doesn't look sharp). Again some of the effects doesn't look good. Could this be corrected by changing some of the settings? please explain

 

It's definitely an older package, and isn't officially part of the "Infinity PBR" set of assets. I wasn't able to figure out a way to make the curve more smooth -- it's based on the frame rate ,as the trail renderer goes in straight lines from point A to point B. At 60fps, it would be very smooth, but my demo on the laptop didn't run that high.

The trails are drawn each frame, but do not precede the weapon. So what you may be noticing ( the "slow" part) could be from the amount of fade-in time the particle has. You can easily adjust that in the "Color over Time" panel. Some of the trails actually disappear and come back a short while later, like echoes, using that option.

 

I should add, if I find a way to make the trails smoother, rounded between frames, I will do that. In theory it's possible, I just don't have the coding skills to know how to hack the trail renderer to my needs.

 

@ sfbaystudios do you have an idea of any asset in the asset store that can correct some of the problems or better still another trail that can show trail for all animations. I found "x-weapon trail" but it shows weapon trail when the model(blade master) is moving(when weapon is not been used). I was looking at the the barbarian game you created, the game looks great but the weapon trail is really bad.

 

Unfortunately I do not. When I made this one, it was because none of the offerings (this was 2+ years ago) were able to create trails in any direction.

 

I just purchased the Weapon Trails Advanced and Customizable asset in the unity store and I am very disappointed. The system is not working as advertised. In fact, it is absolutely not clear to me how I should set it up in order to make it work. I've read the manual but it makes no sense to me. Can I please get more details on how to implement it? There is a folder called "Weapon trails" and a subfolder called "Trail Renderers". The manual says nothing about these and only refers to prefabs (which both folders contain). I was expecting an out of the box solution but ended up with spending money for something I cannot use. Please advise.

 

Hi, sorry about that. Here's a video showing how to implement the trails.

 

Hi infinitypbr,
After looking into the particle and emission system I got it somewhat working yesterday already. But there is another bigger issue: Your trails work indeed when setting up everything in edit mode. If you then hit play and enable emission, the trail is showing up. However, if you instance the weapon the trail is attached to (aka create a clone), the trail will create a vertical pillar instead of a flat trail. It happens in 100% of all cases. I tried to experiment with the billboard settings but with no success. What Am I missing?

 

Is the emission disabled when you instantiate the weapon? The trail works by adding the effect to the line between the position in the previous frame, so if it is created at once, it could be going from some other position to the "instantiate" position, and then drawing the line.

 

The emission is not enabled during the instancing process. It gets enabled right before I send the trigger event to the animation controller (I don't use animation events to control the emission because they are unreliable) and disabled once the animation is completed. When I look at the trail prefab in the hierarchy during runtime the emission gets enabled and disabled at the proper times. We can assume that this part is working. Should I instantiate the weapon with the emission system enabled and disable it right after? Is that what you are saying?

/edit: just tried to instantiate the weapon with emission enabled, that did not resolve the issue.

here is what I basically do during the instantiation process:
weaponObjectMainhand = Instantiate(weaponConfig.Prefab, RequestMainhand().transform);
weaponObjectMainhand.transform.localPosition = _attachmentPoint.localPosition;
weaponObjectMainhand.transform.localRotation = _attachmentPoint.localRotation;

weaponObjectMainhand is a member field of type game object, same goes for weaponConfig.Prefab which holds a reference to the weapon prefab that has the trail attached to it. RequestMainhand() returns the game object it the hierarchy where the weapon will be instanced to (the players right hand in that case) and the last 2 lines transfer the previously set up location and rotation to the newly instanced weapon to ensure it's hold properly in the players hand (aka the weapon grip) which is another game object. I also disabled these lines to make sure they are not causing the weird behavior, which they don't. I hope that help. Let me know if you need more information.

 

Hmm...I'm not sure, but I'll think about it and maybe the answer will pop in my head.

Have you thought about including all weapons as prefabs on your character, and instead of instantiating them, simply turning them on/off as needed? The setup is more involved of course, but the overhead during runtime should be slightly less w/o having to instantiate the weapons, and I'd think it would also solve the problem at the same time.

 

Your suggestion would be a performance disaster. The final game will have dozens of different weapon types with even more variations added by a random item creator. All characters including NPC's and Critters are using the same weapons. It would mean that every single character is running around with every possible weapon in the game. The overhead would be massive compared to just instancing what a character needs when he needs it.

If you feel you cannot solve the issue, please consider refunding the order. At this stage, I cannot use your system anyway.

 

I think you're mistaken -- when turned off there is no overhead.

 

Unity still calculates the position and rotation of each GameObject, disabled or not. And each still requires memory (which is only logical because you usually do this to avoid the more resource intensive instantiating). However, if you only rarely instantiate a new item the performance hit is much lower compared to having a character running around with hundreds of disabled GameObjects.

Back to topic: Have you been able to address the issue / have you considered a refund?

 

You have to contact unity for a refund. I've made games with 60+ weapons on characters and not had any issues, but maybe you're targeting super low end devices or something, idk.

 

According to Unity they only handle refunds if it was a duplicate purchase, every other refund needs to be handled by the author of the asset. In case you want to discuss that too, here is the link to their FAQ: https://support.unity3d.com/hc/en-us/articles/205060439-How-do-I-request-a-refund-on-an-asset-
Maybe there is also a slightly more private way to discuss this part since it has nothing directly to do with the asset. How can I reach you?

 

Weird, the asset store doesn't give publishers any "Refund" button or anything like that. support@unity3d.com is the email given for support issues.

 

It reads everywhere in Unity's FAQ that the publisher has to authorize the refund and has to contact the support submitting the invoice number to them to get the process on the way. There is nothing I can do. Contacting Unity's support as a buyer is not leading anywhere because they will send me back to you.

 

I haven't seen that. I don't know what your invoice number is. Can you send it to me, and I'll email them?

 

I send you a private message yesterday with the details.