Thank you for a great video! In my experience rigid Vertex translation/rotation is particularly useful on mechanical background elements; Ventilation fans, Window blinds/shutters, Cogs, Pistons, Tank treads etc. Places where you don't need the same control/fidelity as on your hero assets, and don't want to pay the SkeletalMesh tax. I might be wrong, but I do think your shader example will create unwanted results, if the gun is rotated, as your translation/rotation vertex offsets are all calculated in World- and not Local-Space? Anyway, good stuff!
Yes, you are correct. The vector input of "NormalizedRotationAxis" pin on the "RotateAboutAxis" and "FixRotateAboutAxisNormals" nodes need to be transformed from local space to world space, as does the final output of any linear transform in order to get correct behavior in the example shader during rotations. Thanks for the comment!
@@lifeartstudios6207 so what's the answer for mobile pipeline? (I dont have a phone game yet to test.) To animate guns, Is it better performance to use Material haxs + the Transform code (from local space to world space)? Or better to use Skeletal mesh (bones) to animate small parts? Ty.
@@kenalpha3 as with most things it depends on your project and needs. If it's strictly a phone and not something like VR you will probably be able to get away with vertex animations or at least a combination of vertex animations with blueprint timeline based animations with additional static meshes. Unless you doing something funky like showing the chain fed belt of a gun being loaded in then you likely can get away with simple transform related things. If you could explain a little bit more about your project I could probably give you some more information
Good point here, I have an example which is XCom 2 made by Firaxis Games. In that game you often see pigeons wandering on the ground with head bobbing animation. If you look closely enough, you will see that animation is done with vertex shader. The pigeons are low poly models probably with less than 100 verts and the animation looks so funny. They didn't implement complex behavior tree for pigeons since I sometimes saw 2 or even more pigeons randomly walking into each other which indicates that the pigeons don't have physics or even box collision. They just move.
Thank you very much for the idea, I found it very interesting and have been looking into it for a few hours now :) One thing that you sort of neglected to mention however is the care you have to take with respect to the coordinate systems. The setup you show in the video will not work properly as soon as the mesh is rotated within a level. Getting the local coordinates is a bit weird, I actually resorted to transforming (1, 0, 0) and (0, 0, 0) to world coordinates and then subtracting them to get the forward vector with the required rotation. I am sure there are better ways but I am a noob when it comes to the material editor xD
You are correct, you do need to do some local to world space transforms for this type of animation to work if you change its base rotation. Thanks for watching!
I never said they weren't, just that in some instances they are not needed and that they do have an increased performance cost compared to static meshes. Many people don't know that there are other options like vertex animation which is also widely used in the game industry. In fact, the concept shown here predates skeletal animation systems in games.
@@TechArtAlex This was super interesting and definitely warrants more research. I'm not quite caught up on how animation works engine wise, but I can see how this might have real memory/cpu savings.
@@kaos88888888No no. Nanite combined with UE5 on static meshes is much more performant than typical skeletal meshes, along with the fact that nanite does not currently support skeletal meshes. If you can use a static mesh whenever possible, such as attaching static meshes to skeletons, you’ll have a much better performance. And especially in Unreal, since it’s using Nanite.
Theres definitly cost savings in some cases. But its really hard to build systems or frame works around a system like this. Like doing synced reload animations with the player. Plus every moving mesh would need unique materials to drive that kinda deal which is more overhead in terms of development. I def would like to see a class of mesh that was something inbetween a static mesh and a skel mesh. Cause yeah, a skel mesh is overpowered for something like a gun or a chest opening but it offers the flexiblity for animating in a normal pipeline
Definitely the biggest weakness of this technique is the lack of pipelines and tools. At the end of the day, if you can hit your frame time targets with better supported workflows, then this might invite more trouble than it's worth. But that said, Epic is interested in these techniques so hopefully we'll see more tooling. They use it extensively in Fortnite's building animations, and also the original UE5 teaser used vertex animation for the swarm of insects. Thanks for watching.
Perhaps you could make a base material for lets say guns. Have have child material for each type of gun. Each gun will follow common template. Below are two types of guns. They use same index (alpha channel) for each part of gun. Than you can have exposed vector and rotation variables for each part you want to animate and override in child materials. Than you only have to do this once really for all guns. (Numbers are alpha channel) Gun A - 0 : trigger - 1 : slide - 2 : hammer -3 : safety - 4 : magazine release Gun B - 0 : trigger - 3 : safety - 4 : magazine release
the question is why unreal doesn't allow users to import transform hierarchy and corresponding animation like unity which is the cheapest. I can't find an answer for that and it makes a lot of trouble especially if you just want to export an archviz scene or something in unreal with some door or windows opening/closing you have to convert the scene into skeletal mesh! it's just stupid
It may not be for some, but with enough skeletal meshes there will eventually be an impact. Every project is different, and sometimes skeletal tick isn't the issue that needs attention.
It really isn't. I mean I am always up got maximum performance and optimization however this sort of system is a lot of work to build and maintain and if all you get is a millisecond, you can probably shave off more through CPP and optimizing CPU instead of GPU.
@@lifeartstudios6207 true but here's another solution you could use with minimal impact as well: make it a static mesh and create all the morphs you want. Same features but less hassle than using UVs and masks and it also tracks normals. And again, I appreciate the effort however you have to consider the amount of work put into it versus the payoff. This, imo, is not worth the payoff at all.
Great video! Btw, in order not to perform all transformations for all vertices, you can use a branch that will accept the value of the mask as a condition.
An if statement runs the outcomes of both circumstances and throws away what isn't needed. So you're still doing the work you're trying to avoid. His masking and adding technique probably is better here
Could also do the trick they used on the nanite demo for the big boss. Animate normally, export the skeleton withou skins, attach the parts to the corresponding bones in editor. Voila, the animation is there, the parts are considered static meshes, added benefit, the animation can be reused for multiple similar guns.
@@TechArtAlex Well I didnt mean use nanite per se, although it would infact allow more meshes. But more of the fact the boss in the demo is a bunch of static meshes attacked the a classic skeleton that doesnt handle nanite itself.
Definitely, you can use vertex data, procedural data, textures and more. What makes the most sense will depend on the complexity of the mesh, and the animation. For example, you could make an insect wing animation similarly to how the trigger/hammer works in this video -or you could also linearly interpolate between a start and end position for a very cheap animation. More complicated animations will rely on the vertex animation texture method, which allows you to bake many frames of offsets and normals. This is good for objects with too many verts to do real time math on, or when procedural and/or vertex data alone isn't enough but will of course cost more memory.
My question becomes is the trade off of several static mesh components animated via bp more costly than this, at scale, on a mobile pipeline. Say for example I'm developing for quest. Less draw calls from instancing is a nice win (even though you have to manually handle instancing with a home brewed manager), but does the shader costs outweigh the draw call trade off. Better question, would animating the pieces via "custom data" or "per instance custom data" channels be a good option since you're GPU is now stuck waiting for the cpu to run it's updates. I'd think handling the lerping, pivot points, would be a great work flow win with custom data, but the bottle neck from cpu to gpu is certainly a big question. Lastly, when you're stuck dealing with a VR situation where you need to manually operate the components, something like a bolt action rifle would be tricky. You need to follow likely a vertex anim texture or some sort of curve data to do the positional and rotational information. Also, when is this really worth it for a gun. How many of the same gun is on a map honestly. If it's not a battle royal, I'd say not likely to be more than 10. 4 draw calls per separate mesh component + 1 for master material and + 1 for the instance material x number of guns ... 60 draw calls at best, vs 3 for instanced meshes. On a modern PC, who cares. On mobile and VR, sounds worth it. However, does this break the rules of auto instancing I wonder? Definitely food for thought, I'm going to include this as an example set up in the VR gun plugin I'm working on just in case. Thanks!
These are exactly the kind of thoughts I wanted to provoke when I made this video. Obviously a less conventional work flow like this has its challenges, but there are tons of creative possibilities.
If you have technical animator with skills to do so - then yes.. if not there are other techniques to optimize skeletal mesehs in unreal engine for example, allowing you NOT to tick each bone position on each frame.
@@MrSmith01 skeletam mesh component - optimalization. It allows to lower anim framerate by distance so basically lod anims, as well as setup behaviour of meshes that are in memory but arent seen - so colled, net relavant but visual culled and dedicated server
I finally implemented this and its so cool! My only problem is my triplanar mapping on my weapons doesn't move with the animation. The texture stays aligned to its original position. I am using a local triplanar function so i can move the gun and the textures follow, but this breaks it doesnt retain the "Local Triplanar":/
@@TechArtAlex Thankyou!!! that worked! Last problem is when i rotate my gun say 45 degrees, the trigger and hammer sort of warp and curve away front the gun, i tried using object space instead of world position but no luck. Any idea how to get this to work when rotating the entire gun other than just straight up and down?
@@Vylocity assuming all of the animations work as intended from the base rotation, you should be able to transform everything from local/object space to world space as the final step before WPO and it should work properly regardless of rotation.
@@TechArtAlex Yeah that makes sense, my animations look perfect before rotating the mesh. Ive tried adding that transform position node at the end of all the logic but my mesh literally disappear. I've tried a few different spots as well and cant get the rotations to follow the meshes rotation. I've triple check your logic as well :/
Hmm. Try a transform vector not transform position node. WPO are usually offset vectors, not offset positions. If that doesn't fix it, I'm not sure what the issue is. But I have been thinking about updating and re-making this video to fix some things I left out like local to world space transformation though.
it may be obvious but textures were never my thing, and no matter how many times i watch this video it does not make much sense to me im getting lost at the stuff, BUT would it be possible to animate vehicle using this? Tracks rolling, wheel suspension, turret rotating and barrel lifting in the turret? After some time i realized how the pivot works, i realized those colors are actually axis in which is part supposed to operate. How those Multiply fin into all this is beyond me, combine corrected is beyond me Id just like to know if i can animate my vehicles so they will aim where my mouse points and for wheels to spin when im driving, if its possible then ill try to get more into it
It can do vehicle animations, but you won't want it to do anything that needs a hotbox to be updated, since these changes are on the GPU only. That's part of why it is so efficient. So it would work well for the wheels spinning, but potentially not so great for a tank cannon turning. This is all about creating offsets. Don't worry too much about how I set my nodes up but instead ask how you would offset vertices over time to achieve the effects you're trying to do. For example, to spin a wheel you would need a pivot point to rotate around. You could store this in vertex color if you want. Then you can set up a rotate about axis node.
Thanks for this video! I wanted to ask, do you happen to know how I could keep the pivot point (made with a vec3 like your video) to keep its relative position when an object scales up and down? I'm running into issues where when my asset is shrunk or scaled my motion looks very different.
There should be an object scale node you can use to multiply your pivot point by. If your pivot is (3,3,3) and your scale is 2, you can simply multiply for the correct (6,6,6) pivot for example.
I'm curious how much of a big hit skeletal animations could be. Obviously you could have hundreds or thousands of them going on at once or something crazy for testing. Even in terms of the 0.03ms. If you have a couple dozen animations going on, lets say 50 and it goes up to 1.5ms ... How noticeable would that be?
1.5ms would be the difference between a game running at 60 FPS and about 56 FPS. Some hardware might see drops with just a few dozen skeletons, depending on the complexity of the rig and the mesh.
Why not attach static meshes/instances aka the pieces to sockets of a skeleton, just like the Boss character in the UE5 nanite demo project. They simply attach static meshes to the bones or sockets of the skeleton on the character. Can do the same with weapons, vehicles etc. and you retain the ability to easily manipulate the animations on runtime using IK etc. or hook the skeleton up to a Control rig.
once you have bones in, you pay bone performance tax look at comparisons between 5:30 when bones are in the model vs 6:30 where there are no bones in + if you socket something into a skeleton, the game will check every frame position of the socketed mesh so it will have performance cost as well
I think there are cases where doing that could be worthwhile. You would still pay a cost for a skeleton, but without any skinned verts it would be low. It would be more expensive than just storing transforms alone for a collection of static mesh components, so it's really just a question of if you need the features offered by a skeleton or not.
@@TechArtAlex Hey, awesome seeing you respond to an ancient video, didn't realize^^ Exactly, it's a trade-off. I have seen many do simplify to Vertex Animation for the higher lods on characters when they get far away or as many mentioned in other comments using vertex animation for cloth in the wind or vents spinning or other looping animation. The difficulty for me stems from vertex animations not being easily affected by all the features one gets from bones, additionally for animations that also have to blend between each other etc, thing will be easier keeping everything all in the same pipeline if they interact with each other. That said, examples for great vertex animation are Ghost of Tsuchimas leafs, which are fully GPU particles, with shader driven vertex simulation, which interacts with the game's awesome wind , and characters + collisions. @Drakuba I'm, not sure what you mean, yes a skeleton by itself has a performance cost. But it's a fraction compared to a skinned mesh. - "+ if you socket something into a skeleton, the game will check every frame position of the socketed mesh so it will have performance cost as well" It's a simple matrix transform. All game objects undergo multiple during rendering each frame, don't worry, one more doesn't hurt :D From Object to Parent to World to Screen (simplified), depending on parenting hierarchy etc etc.... Attaching individual meshes to sockets or directly to bones, as said, allows you to use nanite + instancing. When we are talking characters/vehicles or weapons i would do that instead of baking into vertex animations def. + they also have texture cost. A vertex animation as texture is mostly larger than an animation or morphs/shape-keys. Plus you can always switch to vertex animation at distances, or switch out the model for a skeletal mesh only when a character holds the weapon for example.
How about a skeletal mesh without anim instance? Like if I need it skeletal specifically for the Phat, would there be a noticable performance difference?
I haven't tested it personally, but it's probably worth exploring further. Ultimately if you need other aspects of skeletal meshes beyond animation, it leaves little choice.
You can check a box on skeleton meshes to run as static. Wish you could still run simple animations on then somehow. No morphs for example, just linear stuff and access bone hierarchies. Old engines had something like this, wonder why it got dropped.
@@lifeartstudios6207 It also disables simulations iirc, so not really useful for me. However, toggling that at runtime sounds like the best compromise for a reasonable workflow
I have spent some time to create a material function that does all the manipulation on the mechanical parts of guns. This should make it quite easy to integrate new guns into the game. Also I found that working with material parameters from C++ seems to give a bit more control rather than using animation blueprints (I previously used notifies to now when to eject cartridges for example - although in hindsight, blend spaces would also allow more direct control). Now I just need to measure if there is actually performance gain... so far it doesn't seem to be much faster (probably because the previous guns already enabled "RenderAsStatic" if they where not held by a character or the player).
The largest performance gain will most likely be in cases where the number of skeletal meshes would result in CPU bottlenecks. If you aren't CPU bound, it should still be faster though. Definitely interested to hear your results.
@@TechArtAlex So I ran some tests: - Simple greybox level of a warehouse with 2 floors some cover, lights - 13 characters (including 3rd person player) - all carrying hand guns - 9 playthroughs of the level for each version (handguns based on skeletal meshes and based on static meshes with shader based animations) - The measurements are the mean FPS per playthrough (the FPS did get better if I played worse since then the initial lower FPS averages out when less enemies are acting. But I think over all sessions I've played about equally good / bad for both versions) My results: - Skeletal Mean FPS: 97.0 - Skeletal Std. FPS: 3.83 - Static Mean FPS: 112.44 - Static Std. FPS: 1.18 The results imply that there are roughly 15 FPS gained through the introduction of the new guns and that the overall performance seems to fluctuate less. However, the methodology does have some flaws as already mentioned with longer play sessions generally giving a higher average framerate. In conclusion, I think I will keep both options available in this project. Since I use polymorphism to run the animations on the guns, I now have two C++ base classes, one for skeletal meshes and one for static meshes and the the NPC and player actors can use both in the same way. I hope this analysis can shed some light into the discussion. Thank you again for making the video, for me personally it was definitely worth it to look into.
Just a short idea by side , anyone tryed to use that method to attach a static mesh to a skeletal mesh .Modify the material to act like the skeletal mesh and than put Nanite on it ? So The low Poly SKeletal mesh holds Physic Asset. animBp , Postproces and that stuff an an 9.000.000 Polygons Static mash what you can than Animate with the control Rig.
good tips, nice to know :) but.... from revolver to minigun, all guns use only simple vectors and rotations, as animations.... isnt it even cheaper to use simple timeline transform nodes and static meshes, with no vertex maps ?
Splitting the mesh into multiple components traditionally would result in additional mesh and material draw calls, so it's not necessarily much cheaper. There are other pros and cons, but it may be worth exploring for some projects. With that said, Nanite can batch draw calls much better. It only requires one material draw call for any number of meshes that share the same material, which may make this method more viable than ever.
Vertex animations are great, but they are massively lacking when it comes to interactbility. No physics, no collision, it doesn't update the vertices for ray casting etc etc. Skeletal meshes aren't that expensive, I wouldn't worry that much about using them
It can update verts for raytracing, but it doesn't by default. It just requires updating the BVH every frame - same as a skeletal mesh - if you want the animation represented in RT reflections or shadows. But in many cases you won't need updated physics or collisions for many animations or possibly even the updated BVH so there's no point in paying the price for these. Skeletal meshes aren't that expensive in moderation. Crowds, swarms, or using it excessively for props absolutely can cause massive CPU bottlenecks. But yeah, it requires more custom tooling so it isn't a one size fits all solution. Sometimes it's also just plain simpler and cheaper than having a rig, or used in combination with one. One such case is the tentacles of the Kraken in Sea of Thieves. It used a traditional skeleton for the main tentacle, but vertex animation for the suckers. It's used all over in big ways and small, but often goes unnoticed and underappreciated. Thanks for watching!
this is so misleading, especially for an hero asset like a weapon in first person or third person attached to an already bone dense character...this issue should not exist or it's not worth to use alternative more time consuming methods. Like one comment said, this could be useful for an RTS, but that's pretty much it
If it were just one skeleton I'd agree, but often games will have literally dozens of on screen at once, and these techniques generally do not diminish the quality of hero assets. Besides, the video is more about the concept of vertex animation in general, not this specific application - a gun is just a simple and convenient demonstration that features both transformation and rotation and can be applicable to a wide number of projects. Every project is different and obviously not all will obtain the same benefits from vertex animation, but that hardly makes this misleading. Low end hardware, like mobile/Switch are another case where extreme lengths may be necessary to hit frame targets.
@@TechArtAlex then don't call it ''stop using skeletal meshes!'' like you discovered that they are not viable in the game industry, i stand by my comment, this is very misleading, i don't even know if it's wort for an rts since they're weapons would not have more than 1-2 bones anyway, we get it you are cool and in using 3000 nodes you can do the same, but it's hardly worth the time and money in development.
I show in the video how to test if the skeletal animation tick is bottlenecking performance. I say in the video that some situations require skeletal meshes, and others don't. I trust viewers are smart enough to decide when it is appropriate to use the tools I give them. No one is being misled into believing skeletal meshes are taboo. The entire point of the video is about thinking critically and making an educated decision.
@@TechArtAlex As i said, the title is pretty misleading and i had at least two beginners linking me this video telling me they won't use skeletal meshes, i had to explain that your video was indeed misleading.
Right, this technique or similar methods are often used for particles (which don't support skeletons) or large crowds, which would be too costly for skeletons. Most often, the animation is baked into a texture instead of created in the engine but which is better depends on the complexity of the animation, and the number of objects on screen. The texture will excel in large numbers, because the texture sample will be less expensive than recomputing normals in real time for a large number of objects.
Sticking with the example, isn't it simpler and faster to animate a simple hierarchy mesh? No bones or vertex morph shaders, just simple translates -> much less data and calculation. You might get 4 meshes instead of 1 in this case, but if you have the same material, the GPU will solve that in 1 draw call.
Historically this would mean 4 mesh draw calls, even with only 1 material call. But this idea is much more practical with nanite. It's definitely worth exploring, especially in fully rigid animation. Vertex Animation also works for semi-rigid and non rigid animation. I just stuck with rigid animation to keep things simple.
@@TechArtAlex I would find it strange that this old technique is not used by Unreal, when Unity and other engines are. The point of dynamic batching is that it renders the draw call based on material. If the pistol has its own material, then regardless of being made up of multiple meshes, it would be easily handled by the GPU api with one draw call.
@@hamuArt ua-cam.com/video/qx1c190aGhs/v-deo.html "Static Mesh Component Draws with the same Material Instance *and* StaticMesh will be merged unless..." Dynamic batching in the manner which Unity implements is often not an optimization, as the necessary CPU transformations often exceed the cost of the additional draw calls on the GPU. Per Unity's official documentation: "Note: Dynamic batching for meshes was designed to optimize performance on old low-end devices. On modern consumer hardware, the work dynamic batching does on the CPU can be greater than the overhead of a draw call. This negatively affects performance."
There are lots of cases where shaders can give the impression of simulation. Maybe we'll see cloth sims on the vertex shader achieve a similarly convincing result someday. Until then, it works pretty well for pre-baked vertex animated cloth sims, at least.
Super excellent video. Thank you. I'm curious on how this would work if at all with a ball joint or something more complicated like a 4-wheel vehicle. I see the value in it, because I can then use nanite for my vehicles & weapons, but how would I handle the suspension for example or animate with this method. (I know nanite doesn't work with Transparent and Opaque materials at the moment.).
Nanite also doesn't work with world position offset currently unfortunately, so this technique is only applicable to non-nanite static meshes. Therefore, the main reason to use this technique is generally solely if your animations are taking up too much frametime due to having too many skeletons ticking each frame. Another major reason would be if using a skeletal mesh is impossible, like within a particle system. In most games, there are only a small number of vehicles on screen at any given time, so I don't think there's much frametime to be saved with this technique. But ultimately you can always experiment if your project calls for it.
I think you've missed the point. Bones are less performance friendly than static meshes. Vertex animation is dramatically more efficient at runtime. If you don't need to reduce your skeletal animation tick, then sure, do what works for you.
Looks like a video from someone who discovered vertex animation for the First Time "yoo dude that's Amazing stop using traditional animation". It's not that simple, you didn't factored what makes a good animation, what an animator uses as tools to modify stuff, normals etc.
It's obviously not that simple, and I bring up the issues that vertex shader animations cause for normals in the video. But very frequently a lot of the tools available to skeletal animations are unnecessary. The video is already over 20+ minutes, at some point I have to leave it to the viewer to decide if their project can benefit.
@@TechArtAlex Probably is the gun example that isn't the best for this kind of animations, maybe stuff like antennas/poles in the wind are the perfect objects that can get the max out of the techniques with masks and a more "procedural" approach
Yeah those are great examples as well. I mostly just wanted to get people to think more critically about their animation choices rather than just jumping into the easiest (but costliest) solution. Thanks for the feedback.
That is a good technique for background animation but that will be very unpractical or limiting for an asset like a weapon in production because it will add a lot of complexity to manage weapons animation for developers. Instead of just blending poses or play animations from a (hopefully normalized ) list for a lot of weapons you will need to have a different implementation for each to control the shader uniforms with good timing, if you control that by blueprint instead of cpp it might even be a bigger hit when the animation is actually played . But well, that technique can be good if you need a ton of animations, that is why we animates grass, tree and other foliages with shaders instead of bones. There is also a video from coffee stain studio on Satisfactory where they show the work of a technical artist, and they do use that method to animate pistons on pipes, they spared a lot of cpu by moving animation from skeletal meshes to shaders, but they only need to control the frequency and amplitude of the piston from the gameplay
This was to show the concept of vertex animation in a basic, but often unseen form. It really wouldn't be that complicated to time the events, but I would make some changes in a production shader. Here's an example: You can store the timings in a vertex animation texture with a custom UV set which maps each animating part of the gun to an X position in a standardized way (This would also replace the need for vertex colors shown). The Y axis would be a timeline for these parts. The simplest way to do this is to have each Y position represent a frame of animation. Multiple animations can be stored along the Y axis, and multiple weapons can be stored in the X axis, since each only has a few moving parts. Then, the code/blueprint only needs to tell the shader what part of the texture to sample. A single material parameter collection could define all of those variables. Every project is different, and this kind of workflow is definitely not going to be suitable for all. But this video is really just to get people thinking about unexpected ways they can optimize their animations - not a tutorial. Thanks for watching and commenting.
@@TechArtAlex Interesting, that would certainly be a more complete way to manage it, and could even be automated from the 3D software to be able to work with "regular tools" ? Anyway i just wanted to voice my concern about maintaining that kind of system at larger scale, because it could look like an 100% win for less experienced users who may miss the other less desirable side of it, and the gun exemple don't seem to be the most fitting for that kind of optimisation . Otherwise the method is pretty legit .
Yup, a python script in blender could easily generate that kind of texture, for example. It's definitely accessible to indies, but it's not *as* accessible compared to just putting a skeleton in everything that movies. I just wanted to challenge that notion and get people thinking critically about animations and excited about technical art. There's been tons of great dialogue in the comments and I really didn't expect nearly as much attention as this video got.
You don't need a mass of meshes to spend half a millisecond or more. Check Stat Anim to see the frametime cost for your own project to decide if there is any benefit to cutting back on skeletons.
@@TechArtAlex Oh, of course profiling will tell you whether to opt for it or not. But 0.5ms to 1.0 for ONE single skeletal mesh like this asset is unlikely, unless you're driving a very complicated physics asset, or you've bound other events that are taking CPU time to particular animation asset events or physics events. This video is extremely helpful and I appreciate the tutorial, but your timings there make me wonder if you had other things firing hogging up that CPU.
@@albarnie1168 It is not a totally linear cost. The first skeleton will be more costly than subsequent skeletons because of the thread initialization, so if there are any skeletons at all, that cost can't be avoided. Skeletal mesh costs scale based on the number of verts and bones. Assuming it's the same skeleton being duplicated, I expect the ms cost per mesh should be mostly linear with each copy. This is why it often only takes a few dozen skeletal meshes before there is a noticeable impact on frame time.
@Joey Pla Definitely could be other factors. This was UE5 early access after all. I didn't take much time to profile since the asset was created specifically for this video and the performance benefits of vertex shader animation are well known and proven. Thanks for watching!
As far as unreal is concerned, this isn't an animation in the traditional sense. It will not be compatible with any of the animation blueprint nodes because it is not a skinned/skeletal mesh. Instead, you would use the blueprints to change the material's parameters. You could use a material parameter collection for example. You can also bake all of the animations into what is known as a vertex animation texture, and use blueprints to change which frames of the animation are being sampled to change what animation is playing. This works best for complex animations where doing real time math would be more expensive that a texture sample.
It depends on exactly what you're doing, but the most direct example would be through displacement maps. As far as I am aware bender only supports displacement within cycles renderer.
I have not watched the video yet, and I don't plan to use unreal so I want to ask first is this video strictly applies only to unreal engine or to 3D games in general?
Would this method actually affect the location of the mesh, when it comes to physics? For example, let's say I put a marble in the space behind the slide. I pull the trigger, the slide goes backwards. Does using vertex based animation mean it actually hit the marble and trigger physics, overlap and onhit code? I am making a game that has airbrakes on a ship, which rotate. When they rotate, I want them to potentially collide with objects. I currently use static meshes for this, but was considering using skeletal meshes.
It should function identically to the Rotate About Axis node. To get the correct behavior the inputs should be the same for both in most cases. Using the normal buffer visualizer is a good way to debug any issues with the node. If the inputs are the same, then there may be something wrong with how you are masking it or applying the output normals. Also check the pinned comment for some remarks about local/world space transformations I didn't cover in the video.
@@TechArtAlex hey thanks for the reply, I've got it to work somewhat but the results seem to get worse as the rotation increases, perhaps the pivot point for the node needs adding? I'm also blending these results with a normal map using the blend angle corrected normals node.
Although we discussed this privately I wanted to add a public comment for anyone who is having the same issue. Be sure to change the pivot of the normal fix if it doesn't share the location with your object pivot. I mistakenly omitted this because the rotations were so small and close to the origin, thus the error was not noticeable. Second, normal maps are directional, there is some math that needs to be done to change their directionality. In many cases this issue will not be noticeable. Here is a post with more information: realtimevfx.com/t/tangent-normal-map-rotator/3749/6
Yes, it is very common to make objects like chests out of skeletal meshes. Historically, doing it how you described would usually result in extra draw calls, so it was usually better to use vertex animations for such a thing. That may be changing due to Nanite, which can draw meshes with fewer calls. So depending on the project needs, it may be better to do it as you've described. I haven't tested how animating static Nanite meshes compares to Vertex Animation. That said, there will still be many cases where vertex animations are necessary, like more complex animations like turning pages of a book.
@@TechArtAlexLol, I still use meshes all the time, it looks good enough so whatever XD Plus I rarely ever need to make complex stuff like that. But it does make sense for super realistic games. I just don't have the time and patience.........
there are zillions of vector rotations going on inside a game, that's what bones are for....one chest opening/closing at a time will not kill your framerate
True, but this isn't really about one chest or skeleton. It's about identifying if skeletal ticks are a bottleneck in performance and some ways you can deal with it.
There are only two animating techniques that are used which is skeletal and morph target.skeletal is good for rotation movements and morph target is good for linear or translational movements.
There are not only two. Vertex shader animation is used extensively, especially for animations that would be impossible with more traditional techniques. There are many examples of this method being used in major titles.
That's a horrible idea. There are many ways to optimize skeletal mesh. But most importanly - there's no replacment for skeletal mesh. We are talking about pipeline - animation is done by ANIMATORS, not by technical artists or whoever makes complex materials in your studio. If you want a nice-looking animation made by animator, not restricted by vertex offset method limitation - you have to use skeletal mesh. Vertex math is a horrible method for your pipeline. It gives a horrible result, takes a lot of time and can't be done by animators.
If that is your takeaway, you've either missed the point of the video or perhaps didn't watch all of it. The point is to challenge the idea that just because something must move, it must be skeletal. It's not really about guns at all, but on a project level having tons of extra skeletal meshes everywhere that could be easily animated with textures or cheap math can save performance at scale. This is a proven solution to skeletal mesh bottlenecks and the fundamental technique is applied all over shipped games. A gun is just a convenient example of a common skeletal asset that often has only simple animations. It could just as easily be environmental props, crowds, small animals, etc.
Yeah, cool and all, but lets be real, its ridiculous. To animate like that is way more complex than it should be. it breaks as soon as you rotate the model in the world unless you do some math in the shader to get local coordinates, basically you are just moving the load from CPU to GPU in a very inefficient way, now you are doing animation with math. vertex offset in material and skeletal meshes all have its own use cases. This is a skeletal mesh case, not a material one, what about if you want to make skins and decals? what about attachable parts? The performance part is neglible. You would be wasting more time calculating the math for any change than just taking the hit, this would be like spending 10 bucks to gain a penny.
A couple of notes and caveats on this: Vertex shaders do not update mesh normals, so this only works for translation. This is also not an adequate workflow for animators if you are doing interacting reloads. There is a lot of optimizations you can make on skeletal meshes to reduce the cost. Static mesh bounds, update rate optimizations, visibility tick and manual ticking (not ticking the weapon when is not moving), as well as lod settings inside anim graphs can help a lot to bring the cost down. GPU skinning if you are not already using it makes skeletal meshes way more efficient. This is still an important technique to keep in mind. EDIT: i would also not recommend running performance tests in ue5 in its current state. Afaik skeletal meshes are much slower than they should be there and a lot of optimizations are not working for skeletal meshes (nanite is not enabled, so virtual shadow maps are very inefficient among other things)
You can also get rotations and manually adjust normals. For anything more complex than a transform or rotation as seem here you can use Vertex Animation Textures, and can bake the per frame vertex positions and normals into an image. But yeah, just another tool in the box.
transforming normals is just as easy as transforming vertices in ue4, only if you don't use a normal map. Normal map is also possible, but it is not effective and painful.
@@TechArtAlex Vertex animation textures are limited to meshes with 8192 vertices, though. A thing that you can/should do if you're doing a a complex non-deforming animation (like a weapon reload or weapon firing animation) is still build the skeletal animation, but have the imported skeletal mesh only have a single triangle, and then import all the sub-components as static meshes and attach those static meshes to the skeleton in the blueprint. This is what Epic did in the Valley of the Ancient demo for the big stone robot thing.
@@Fafhrd42 Vertex Animation Textures are not limited to 8192 vertices, they are limited to 8192 pixels of data. You don't have to map each single vertex to a single pixel and it would usually be wasteful to do so. In the example pistol asset, large groups of verts are moving together as a single unit and can share a single pixel with a VAT. This means that you could easily store every single gun animation for every single weapon from a typical game within a single texture sample in memory.
Yes, that kind environmental animation is one of the primary use cases of this technique. You would just input time * speed into the rotation angle, and something will spin nonstop.
cost in performance ??? - the player character rarely sees these sort of details, yet he's only using/reloading one gun at a time - the antagonist are so far away and move so fast, who the fuck would animate their guns ?
Performance cost depends on the number of bones and the vertex count of the mesh, as well as how many skeletons on screen. There are profiling tools to see what the cost is. Most games use animated guns for both the player and enemies. Vertex shader animations can also animate much more than just guns, this is only a simple demonstration of the concept.
The rotate about axis node I cover in this video is one way to do that. You can use a sine wave in the material to procedurally animate the flapping, for example. This is really no different than the rotating trigger/hammer of the pistol. You could also consider vertex animation textures, which is an extension of the concept I've shown here. The difference is it caches the full animation as a texture. As a result, it requires more texture memory than the method I've demonstrated, but allows for more complicated animations without needing as many real time calculations. Martin Donald has a great youtube video on this subject.
I knowed this method from water Materials but, i never saw it on special Object . Realy usefull ! I try to have always an eye on the Performance but to be honest i have no clue if Optimize it for real. To know one more thing what definatly Optimize , Helps.
really nice idea, my only concern is in the case that you need to swap and on the reload of the weapon, because that we normally do is animate the body bone of the weapon, to follow the new parent but the root keeping the original partent, but with static mesh we need to do that with a swap of parenting.
You can pass the bone transforms through as a material parameter. Or, baked vertex animation textures are also well suited for more complex animations. Ultimately, this video is less about guns specifically and more about relying less on skeletons in general, when possible.
Thanks for the tip!, Just like you said, I never even considered doing this for anything else than the foliage or trees in my game. I'm used to modifying textures in real time but I have almost no experience working with the vertex shader.
Fun fact: For early 3D games vertex animation was the only method for animation, including full character motion. Real time skeletal animation systems wouldn't widely emerge until the late 90s, with games like Half Life. Vertex animation has become somewhat of a lost art because skeletal workflows are easier, but they have an often overlooked cost. Thanks for watching!
@@TechArtAlex I just implemented this technique on a Home Safe static mesh with a numbered wheel mechanism using three RotateAboutAxis nodes (one for the safe door, the handle and the wheel) and managed to have it work perfectly!. The only issue I encountered is that since the wheel and the handle's normals are also affected by the rotation of the door there's a slight error in the normals in this two parts of the mesh I couldn't fix (again, barely noticeable, just adding the values gives a good aproximation), did you ever encounter a similar situation?. (I am currently Adding the normal corrections between each other and then blending them with the BlendAngleCorrectedNormals to the detail Normals of the safe).
@@manafon5398 Start by adjusting the wheel and handle normals, masking them out and adding together like shown in the video. Once they are working correctly individually, the combined output of this will be the input world vertex normals for the door's normal correction node. Now, the door will know about the changes in the other normals when it does the final correction. In my example, I simply left the input normal slot of those nodes blank because I didn't have any multi-layered correction like you do. Really awesome to hear that you were able to implement this successfully! Hopefully this comment will get your normals perfected.
And what if there should be attachments to this weapon? And lets say you have dozens of them in your game. And some of them can be attached to different weapons simultaneously and lets say to a different attachment point which is defined by a player. So the animator should setup every individual of them manually for every single weapon and every single attachment point? Just imagine the amount of work there. I think it will be so complicated to setup every single of those that it will be a complete nightmare to animate. And how you suppose to animate the magazine of the weapon? And other stuff with which player hands are interacting? The bolt for a bolt action rifile for example? The slide bolt for an MP5 for example? I mean at some point it will turn to be so complex to script that the cost of this system for a developer and the amount of potential bugs will be significantly more valuable argument than any perfomance advantage that you get.
There are simple solutions to all of these problems, and I've given examples in other comments to some of them already. This is a basic introduction to an array of advanced animation techniques, so if you miss the bigger picture it is easy to get lost on the details. There are infinite applications. I chose to demonstrate a gun because it has both transformations and rotations. The purpose of the video is to challenge the notion many beginners have that in order to have an animation, they must use a skeleton. I'm not really sure what point you're making about attachments because you would just use sockets in the exact same way as any skeletal mesh. If you either have the budget to spend on skeletons, or lack time and/or interest to use alternatives that's fine - But these techniques are proven and widely used.
Normally the issue with splitting a mesh into multiple objects is that each separate part could incur a draw call. There are ways to avoid this, like using the part masking technique shown in the video to mask out sections so that all of the objects can technically be the same mesh and therefore instance capable. I haven't tested, but because of the efficiency of static meshes there's a good chance this could still be more efficient than a skeletal mesh and it would not require manually adjusting vertex normals for rotation as in a shader driven approach. Perhaps one could even use a mixed approach, with vertex animation handling linear motion, and a separate object where rotations are needed. With Nanite, the ability to render static meshes very efficiently may also prove to be a viable alternative for rigid assemblies like guns.
@@TechArtAlex That's typically how it should be done in UE5 with nanite when your object is made of non deformable parts. That's how they made the giant in the demo. Even in ue4, the extra draw calls still have a lower impact than using skeletal meshes and if several players use the same weapon, the drawcalls count won't increase thanks to the static meshes auto instancing (you will still get extra draw calls for the cascaded shadow maps tho)
@@TechArtAlex I started using vertex animation textures a lot lately. Also, lots of Niagara mesh renderer for animating meshes. I just make a custom Niagara module that handles animation stuff.
Nope it will not cost much performance, unless you for eg. make RTS and enemy army each with such skeletal mesh gun. For when only player character has such animated mesh is fine. Single skeletal mesh does not make difference.
How many games featuring guns only feature one single gun? Shooters might have dozens of characters on screen at once and this method can easily halve the number of skeletons. Besides, I make it clear that the video is about the general practice of minimizing unnecessary use of skeletons, not this very specific application. It's very easy to profile what the cost is for skeletal meshes, and not all games will need the same level of optimization.
You microphone picks up everytime your lips smack and when you gulp and it triggers misphonia. Might want to have some kind of compressor on the microphone. Otherwise I'd have finished this video, even though I know you are talking about vertex animation and I wouldn't waste my time on it for a simple object. It makes logical sense, but its way more time consuming to setup and debug everything over a skeletal mesh. I'd use it only for peak performance optimisation or when I need repeating objects like crowds.
Right. Every project is different. Not all of them need this level of optimization and it is more effort to use a less traditional workflow. I'll try to improve on the audio - to be honest I didn't expect this video to take off so much otherwise I might have spent some time editing it. Thanks for the comment.
@@TechArtAlex it's all good. the misophonia is my issue, but I empathise with others who suffer from it so I like to point it out. Probably makes me sound like a douche :D
Зачем нужен весь этот геморой если скелет намного удобнее в использовании при этом его можно оптимизировать так что бы затраты были такими же как от статической модели
Sometimes it's better to make several meshes with the same material and textures and animate their transformation (instead of an advanced vertex shader), and simply rely on batching to save your ass.
Yeah, that can definitely work. You can even instance the mesh with a simple vertex masking. The advantage is you can render all the meshes and mats in a single call, and you don't need to recalculate the normal in the shader. Maybe I'll do a video on that too.
@Life Art Studios if you divide the world position of a vert by 0 it becomes "null" and disappears. Using a mask, you can control which part is or is not being removed by the vertex shader. This allows you to create an assembly of the different parts all using the same static mesh. Null verts do still have a cost associated with them, but they do not have a cost in the pixel shader as they won't occupy any screen space.
I understand the point, but I still think adding that many nodes in your material will slow down your game too. As it is harder to optimize GPU than CPU in most cases, I would continue using skeletal meshes.
Generally no, vertex animation is still usually dramatically faster despite some added shader complexity. It is widely employed in RTS games and other scenarios where it is impossible to have as many skeletons as required and meet performance targets. Vertex transformations on GPU are highly efficient and the math being done here is very simple. The true cost is the time spent using a workflow that is less convenient, when many games might perform fine with a few too many skeletons.
@@TechArtAlex Honestly, the only place that I'm thinking this might come handy is when animating a crowd. When we were testing out the frame rates for low-poly human models, what became a problem was that after we created 50 instances of the model, an idle animation dragged the FPS by 10. Other than that, for something that will require systematic and dynamic editing, such as a gun in your example, most teams will go with the industry standard method of using skeletal meshes.
Crowds are definitely the most relevant application of the technique, but I think you're underestimating the cost of skeletons. Consider your example of 10 skeletal characters, whose idle animations are already challenging some hardware. Now add in skeletal guns, or environmental objects and you've probably more than doubled the number of skeletons ticking every frame. It's up to each dev to experiment to see if they can net a savings in frametime. The purpose of this video is to show that there is another way, which is often overlooked.
This is done entirely within the material editor, and there is only a single static mesh component. But you would need some kind of code/blueprint to control movement in game.
No, this is about vertex shader animations on a basic level. Morph targets still require skeletal meshes (although I do have a video on how you can get morph-target like results on a static mesh)
@@TechArtAlex Thanks for the fast answere i worked just 2 weeks ago first tim with morphtargest for the livlink kid on ym first charcter ( Dragon) and wasn´t know that its just for skelletal mesh and i wil check it. Are vertex shader like wave materials ? Ore you know what i just watch the Video ,:D . If you need a Dragon Soon for unreal Engine may this is Something you like ua-cam.com/video/F0UufeKNhPo/v-deo.html Created in blender textured in mixer
Would it make sense to have a relatively simple skeletal mesh with static meshes attached to it, like they did with the ancient in the valley of the ancients demo? Or are you still losing performance due to there being a skeletal mesh?
In some cases it might be, like the ancient. It had so many polygons that it probably would've been impossible to do real time with a skeletal mesh. However, multiple static meshes are usually going to incur multiple draw calls. I think it could go either way.
@@TechArtAlex I was thinking you could do that in the pistol example with separate static meshes for frame, slide, etc, but if using multiple meshes is slower I guess maybe there wouldn't be any benefit.
@@sircod If you can draw all of the meshes in a single call, it might be more efficient. Nanite's render pipeline allows this, as could some clever shader tricks. If each mesh is non instanced, then having multiple draw calls may outweigh the savings.
Why would you have a mesh. You can of course make a rig using bones and attach each “static” mesh to each bone. The key is not to skin the mesh to a rig. Then it deforma the mesh. We just want to translate the mesh. If the transform is stored on the mesh itself or referred to a bone hierarchy matter little performance wise. I mean just classic setup used since the PS1 / Saturn days
Indeed. It doesn't really matter where the transform data is coming from. A mesh-less rig is a perfectly good source of animation data that can be passed to the mesh transform or shader. The bones will still incur some cost, but so will any method of producing the necessary transforms. Again you just have to be sure not to introduce extra draw calls doing so or else you'll just be trading one optimization for another.
I'm sure there are instances where this might be the best approach, but I question if it's worth it for most use cases. Animating a pistol through the vertex shader vs using a skeletal mesh might earn you, say, a tenfold performance increase per mesh, sure. But if that pistol with skeletal animations was already having a negligible impact on performance, and there are only ever going to be a few dozen guns at most in your game at any one time, then all you've really done is traded the ease and familiarity of using bones for a significantly less intuitive system that far fewer people understand. Unless you're targeting hardware from a decade ago or plan to have thousands of animated assets loaded into your game at a single time, it doesn't seem like a sensible approach.
It's definitely going to depend greatly on the project specifics, my main point is really just that we should ask ourselves if we actually need a skeletal meshes for the asset in question instead of just assuming anything that moves must be skeletal as many do. Almost any project can benefit, but like you say it may be negligible and not worth the effort or less convenient workflow. The pistol is just a convenient example of an asset that is often skeletal, and demonstrates both linear and rotational movements that could be fairly easily animated for the video.
6.27 you have Static mesh, and looking at SkinnedMeshComp Tick, they are not really related, and yes, it's performance costly when you have AnimationBlueprint.
Thank you for a great video!
In my experience rigid Vertex translation/rotation is particularly useful on mechanical background elements; Ventilation fans, Window blinds/shutters, Cogs, Pistons, Tank treads etc.
Places where you don't need the same control/fidelity as on your hero assets, and don't want to pay the SkeletalMesh tax.
I might be wrong, but I do think your shader example will create unwanted results, if the gun is rotated, as your translation/rotation vertex offsets are all calculated in World- and not Local-Space?
Anyway, good stuff!
Yes, you are correct. The vector input of "NormalizedRotationAxis" pin on the "RotateAboutAxis" and "FixRotateAboutAxisNormals" nodes need to be transformed from local space to world space, as does the final output of any linear transform in order to get correct behavior in the example shader during rotations.
Thanks for the comment!
@@TechArtAlex adding the transforms in would make this method just as slow as skinning
@@DarxDev see that's the sauce I've been thinking about. I wonder what the best option is for mobile pipeline. Or even, is hlsl a potential win here
@@lifeartstudios6207 so what's the answer for mobile pipeline? (I dont have a phone game yet to test.)
To animate guns, Is it better performance to use Material haxs + the Transform code (from local space to world space)? Or better to use Skeletal mesh (bones) to animate small parts? Ty.
@@kenalpha3 as with most things it depends on your project and needs. If it's strictly a phone and not something like VR you will probably be able to get away with vertex animations or at least a combination of vertex animations with blueprint timeline based animations with additional static meshes.
Unless you doing something funky like showing the chain fed belt of a gun being loaded in then you likely can get away with simple transform related things.
If you could explain a little bit more about your project I could probably give you some more information
Good point here, I have an example which is XCom 2 made by Firaxis Games. In that game you often see pigeons wandering on the ground with head bobbing animation. If you look closely enough, you will see that animation is done with vertex shader. The pigeons are low poly models probably with less than 100 verts and the animation looks so funny. They didn't implement complex behavior tree for pigeons since I sometimes saw 2 or even more pigeons randomly walking into each other which indicates that the pigeons don't have physics or even box collision. They just move.
Very fundamental concept presented here, thank you for this
Thanks for watching!
Thank you very much for the idea, I found it very interesting and have been looking into it for a few hours now :)
One thing that you sort of neglected to mention however is the care you have to take with respect to the coordinate systems. The setup you show in the video will not work properly as soon as the mesh is rotated within a level. Getting the local coordinates is a bit weird, I actually resorted to transforming (1, 0, 0) and (0, 0, 0) to world coordinates and then subtracting them to get the forward vector with the required rotation. I am sure there are better ways but I am a noob when it comes to the material editor xD
You are correct, you do need to do some local to world space transforms for this type of animation to work if you change its base rotation. Thanks for watching!
Very well explained! Thanks for the tip! I'm just starting out in Unreal Engine so you saved me before I got too deep.
do not get mislead, skeleteal meshes are widely used in the game industry, this video is damaging and misleading
I never said they weren't, just that in some instances they are not needed and that they do have an increased performance cost compared to static meshes. Many people don't know that there are other options like vertex animation which is also widely used in the game industry. In fact, the concept shown here predates skeletal animation systems in games.
@@TechArtAlex This was super interesting and definitely warrants more research. I'm not quite caught up on how animation works engine wise, but I can see how this might have real memory/cpu savings.
@@kaos88888888No no. Nanite combined with UE5 on static meshes is much more performant than typical skeletal meshes, along with the fact that nanite does not currently support skeletal meshes. If you can use a static mesh whenever possible, such as attaching static meshes to skeletons, you’ll have a much better performance.
And especially in Unreal, since it’s using Nanite.
dude thanks for not leaving your mic super quiet. please remake a bunch of tutorials in this style.
Really enjoyed the video man. Exactly what I needed!
Thanks! Glad it was useful.
Thank you sir! Just in time for my rifle animations.
Theres definitly cost savings in some cases. But its really hard to build systems or frame works around a system like this. Like doing synced reload animations with the player. Plus every moving mesh would need unique materials to drive that kinda deal which is more overhead in terms of development. I def would like to see a class of mesh that was something inbetween a static mesh and a skel mesh. Cause yeah, a skel mesh is overpowered for something like a gun or a chest opening but it offers the flexiblity for animating in a normal pipeline
Definitely the biggest weakness of this technique is the lack of pipelines and tools. At the end of the day, if you can hit your frame time targets with better supported workflows, then this might invite more trouble than it's worth.
But that said, Epic is interested in these techniques so hopefully we'll see more tooling. They use it extensively in Fortnite's building animations, and also the original UE5 teaser used vertex animation for the swarm of insects.
Thanks for watching.
@@TechArtAlex great example so I guess a main us of this technique would be for cinematic animations where large numbers of assets are needed
@@jameswales2122 Exactly, if you needed to have an army of thousands of units in a cinematic cutscene, you could achieve that with vertex animations.
I've been toying with the idea for a bit to write a "vertex animation blueprint" and system to deal with this.
Perhaps you could make a base material for lets say guns. Have have child material for each type of gun. Each gun will follow common template. Below are two types of guns. They use same index (alpha channel) for each part of gun. Than you can have exposed vector and rotation variables for each part you want to animate and override in child materials. Than you only have to do this once really for all guns.
(Numbers are alpha channel)
Gun A
- 0 : trigger
- 1 : slide
- 2 : hammer
-3 : safety
- 4 : magazine release
Gun B
- 0 : trigger
- 3 : safety
- 4 : magazine release
the question is why unreal doesn't allow users to import transform hierarchy and corresponding animation like unity which is the cheapest. I can't find an answer for that and it makes a lot of trouble especially if you just want to export an archviz scene or something in unreal with some door or windows opening/closing you have to convert the scene into skeletal mesh! it's just stupid
Yeah, Unreal definitely needs better non skeletal workflows.
i think its very true not everything needs to be rigged, though complex weapons i would still prefer that way
Definitely! Every project is different. Thanks for watching!
Thank you! Very insightful. Keep it up!
Is it worth it? Skeletal meshes are more straight forward and easy. I've developed games for mobile and never saw any impact on performance
It may not be for some, but with enough skeletal meshes there will eventually be an impact. Every project is different, and sometimes skeletal tick isn't the issue that needs attention.
It really isn't.
I mean I am always up got maximum performance and optimization however this sort of system is a lot of work to build and maintain and if all you get is a millisecond, you can probably shave off more through CPP and optimizing CPU instead of GPU.
@@philzan3627 circumstances depends really, when you're developing for oculus quest for example, everything matters
@@lifeartstudios6207 true but here's another solution you could use with minimal impact as well: make it a static mesh and create all the morphs you want. Same features but less hassle than using UVs and masks and it also tracks normals.
And again, I appreciate the effort however you have to consider the amount of work put into it versus the payoff. This, imo, is not worth the payoff at all.
@@philzan3627 can you use a static mesh with morphs? I've never heard of this
this would be great for npc guns where your face isnt right infront of the animation
Great video! Btw, in order not to perform all transformations for all vertices, you can use a branch that will accept the value of the mask as a condition.
An if statement runs the outcomes of both circumstances and throws away what isn't needed. So you're still doing the work you're trying to avoid. His masking and adding technique probably is better here
Could also do the trick they used on the nanite demo for the big boss. Animate normally, export the skeleton withou skins, attach the parts to the corresponding bones in editor. Voila, the animation is there, the parts are considered static meshes, added benefit, the animation can be reused for multiple similar guns.
Yes, nanite does change the landscape a bit. I'll need to test how the techniques compare.
@@TechArtAlex Well I didnt mean use nanite per se, although it would infact allow more meshes. But more of the fact the boss in the demo is a bunch of static meshes attacked the a classic skeleton that doesnt handle nanite itself.
Yes I understand what you mean.
Can you do insect wings flapping or a tank tracks using vertex data?
Definitely, you can use vertex data, procedural data, textures and more. What makes the most sense will depend on the complexity of the mesh, and the animation.
For example, you could make an insect wing animation similarly to how the trigger/hammer works in this video -or you could also linearly interpolate between a start and end position for a very cheap animation. More complicated animations will rely on the vertex animation texture method, which allows you to bake many frames of offsets and normals. This is good for objects with too many verts to do real time math on, or when procedural and/or vertex data alone isn't enough but will of course cost more memory.
My question becomes is the trade off of several static mesh components animated via bp more costly than this, at scale, on a mobile pipeline.
Say for example I'm developing for quest. Less draw calls from instancing is a nice win (even though you have to manually handle instancing with a home brewed manager), but does the shader costs outweigh the draw call trade off.
Better question, would animating the pieces via "custom data" or "per instance custom data" channels be a good option since you're GPU is now stuck waiting for the cpu to run it's updates.
I'd think handling the lerping, pivot points, would be a great work flow win with custom data, but the bottle neck from cpu to gpu is certainly a big question.
Lastly, when you're stuck dealing with a VR situation where you need to manually operate the components, something like a bolt action rifle would be tricky. You need to follow likely a vertex anim texture or some sort of curve data to do the positional and rotational information.
Also, when is this really worth it for a gun. How many of the same gun is on a map honestly. If it's not a battle royal, I'd say not likely to be more than 10. 4 draw calls per separate mesh component + 1 for master material and + 1 for the instance material x number of guns ... 60 draw calls at best, vs 3 for instanced meshes. On a modern PC, who cares. On mobile and VR, sounds worth it. However, does this break the rules of auto instancing I wonder?
Definitely food for thought, I'm going to include this as an example set up in the VR gun plugin I'm working on just in case. Thanks!
These are exactly the kind of thoughts I wanted to provoke when I made this video.
Obviously a less conventional work flow like this has its challenges, but there are tons of creative possibilities.
I'm gonna probably watch this alot more times before I ever master this lol
If you have technical animator with skills to do so - then yes.. if not there are other techniques to optimize skeletal mesehs in unreal engine for example, allowing you NOT to tick each bone position on each frame.
Hi! Could you explain how to not tick each bone position each frame? Many thanks!
@@MrSmith01 skeletam mesh component - optimalization. It allows to lower anim framerate by distance so basically lod anims, as well as setup behaviour of meshes that are in memory but arent seen - so colled, net relavant but visual culled and dedicated server
Optimalization options are waaay down after even shadow settings
@@3sgamestudio I definitely will check it! Thanks a lot!
I finally implemented this and its so cool! My only problem is my triplanar mapping on my weapons doesn't move with the animation. The texture stays aligned to its original position. I am using a local triplanar function so i can move the gun and the textures follow, but this breaks it doesnt retain the "Local Triplanar":/
Awesome! Change the world position node for the triplanar to exclude material offsets.
@@TechArtAlex Thankyou!!! that worked! Last problem is when i rotate my gun say 45 degrees, the trigger and hammer sort of warp and curve away front the gun, i tried using object space instead of world position but no luck. Any idea how to get this to work when rotating the entire gun other than just straight up and down?
@@Vylocity assuming all of the animations work as intended from the base rotation, you should be able to transform everything from local/object space to world space as the final step before WPO and it should work properly regardless of rotation.
@@TechArtAlex Yeah that makes sense, my animations look perfect before rotating the mesh. Ive tried adding that transform position node at the end of all the logic but my mesh literally disappear. I've tried a few different spots as well and cant get the rotations to follow the meshes rotation. I've triple check your logic as well :/
Hmm. Try a transform vector not transform position node. WPO are usually offset vectors, not offset positions. If that doesn't fix it, I'm not sure what the issue is. But I have been thinking about updating and re-making this video to fix some things I left out like local to world space transformation though.
it may be obvious but textures were never my thing, and no matter how many times i watch this video it does not make much sense to me im getting lost at the stuff, BUT would it be possible to animate vehicle using this? Tracks rolling, wheel suspension, turret rotating and barrel lifting in the turret?
After some time i realized how the pivot works, i realized those colors are actually axis in which is part supposed to operate. How those Multiply fin into all this is beyond me, combine corrected is beyond me
Id just like to know if i can animate my vehicles so they will aim where my mouse points and for wheels to spin when im driving, if its possible then ill try to get more into it
It can do vehicle animations, but you won't want it to do anything that needs a hotbox to be updated, since these changes are on the GPU only. That's part of why it is so efficient. So it would work well for the wheels spinning, but potentially not so great for a tank cannon turning.
This is all about creating offsets. Don't worry too much about how I set my nodes up but instead ask how you would offset vertices over time to achieve the effects you're trying to do.
For example, to spin a wheel you would need a pivot point to rotate around. You could store this in vertex color if you want. Then you can set up a rotate about axis node.
thanks, guess ill do a hybrid approach of bones for turret+barrel and wheels/tracks vertex animated
does eevee vertex animation texture support?
Unfortunately no, I don't believe that Eevee supports VAT/displacement so cycles must be used to see the effect in blender.
Thanks for this video! I wanted to ask, do you happen to know how I could keep the pivot point (made with a vec3 like your video) to keep its relative position when an object scales up and down? I'm running into issues where when my asset is shrunk or scaled my motion looks very different.
There should be an object scale node you can use to multiply your pivot point by. If your pivot is (3,3,3) and your scale is 2, you can simply multiply for the correct (6,6,6) pivot for example.
I'm curious how much of a big hit skeletal animations could be. Obviously you could have hundreds or thousands of them going on at once or something crazy for testing. Even in terms of the 0.03ms. If you have a couple dozen animations going on, lets say 50 and it goes up to 1.5ms ... How noticeable would that be?
1.5ms would be the difference between a game running at 60 FPS and about 56 FPS. Some hardware might see drops with just a few dozen skeletons, depending on the complexity of the rig and the mesh.
Big difference on quest when your target framerate is under 12 ms
Why not attach static meshes/instances aka the pieces to sockets of a skeleton, just like the Boss character in the UE5 nanite demo project.
They simply attach static meshes to the bones or sockets of the skeleton on the character. Can do the same with weapons, vehicles etc. and you retain the ability to easily manipulate the animations on runtime using IK etc. or hook the skeleton up to a Control rig.
once you have bones in, you pay bone performance tax
look at comparisons between 5:30 when bones are in the model vs 6:30 where there are no bones in
+ if you socket something into a skeleton, the game will check every frame position of the socketed mesh so it will have performance cost as well
I think there are cases where doing that could be worthwhile. You would still pay a cost for a skeleton, but without any skinned verts it would be low. It would be more expensive than just storing transforms alone for a collection of static mesh components, so it's really just a question of if you need the features offered by a skeleton or not.
@@TechArtAlex Hey, awesome seeing you respond to an ancient video, didn't realize^^
Exactly, it's a trade-off. I have seen many do simplify to Vertex Animation for the higher lods on characters when they get far away or as many mentioned in other comments using vertex animation for cloth in the wind or vents spinning or other looping animation.
The difficulty for me stems from vertex animations not being easily affected by all the features one gets from bones, additionally for animations that also have to blend between each other etc, thing will be easier keeping everything all in the same pipeline if they interact with each other.
That said, examples for great vertex animation are Ghost of Tsuchimas leafs, which are fully GPU particles, with shader driven vertex simulation, which interacts with the game's awesome wind , and characters + collisions.
@Drakuba I'm, not sure what you mean, yes a skeleton by itself has a performance cost. But it's a fraction compared to a skinned mesh.
- "+ if you socket something into a skeleton, the game will check every frame position of the socketed mesh so it will have performance cost as well"
It's a simple matrix transform. All game objects undergo multiple during rendering each frame, don't worry, one more doesn't hurt :D
From Object to Parent to World to Screen (simplified), depending on parenting hierarchy etc etc....
Attaching individual meshes to sockets or directly to bones, as said, allows you to use nanite + instancing.
When we are talking characters/vehicles or weapons i would do that instead of baking into vertex animations def. + they also have texture cost.
A vertex animation as texture is mostly larger than an animation or morphs/shape-keys.
Plus you can always switch to vertex animation at distances, or switch out the model for a skeletal mesh only when a character holds the weapon for example.
How about a skeletal mesh without anim instance? Like if I need it skeletal specifically for the Phat, would there be a noticable performance difference?
I haven't tested it personally, but it's probably worth exploring further. Ultimately if you need other aspects of skeletal meshes beyond animation, it leaves little choice.
You can check a box on skeleton meshes to run as static. Wish you could still run simple animations on then somehow. No morphs for example, just linear stuff and access bone hierarchies. Old engines had something like this, wonder why it got dropped.
@@lifeartstudios6207 It also disables simulations iirc, so not really useful for me. However, toggling that at runtime sounds like the best compromise for a reasonable workflow
I have spent some time to create a material function that does all the manipulation on the mechanical parts of guns. This should make it quite easy to integrate new guns into the game. Also I found that working with material parameters from C++ seems to give a bit more control rather than using animation blueprints (I previously used notifies to now when to eject cartridges for example - although in hindsight, blend spaces would also allow more direct control).
Now I just need to measure if there is actually performance gain... so far it doesn't seem to be much faster (probably because the previous guns already enabled "RenderAsStatic" if they where not held by a character or the player).
The largest performance gain will most likely be in cases where the number of skeletal meshes would result in CPU bottlenecks. If you aren't CPU bound, it should still be faster though. Definitely interested to hear your results.
@@TechArtAlex So I ran some tests:
- Simple greybox level of a warehouse with 2 floors some cover, lights
- 13 characters (including 3rd person player) - all carrying hand guns
- 9 playthroughs of the level for each version (handguns based on skeletal meshes and based on static meshes with shader based animations)
- The measurements are the mean FPS per playthrough (the FPS did get better if I played worse since then the initial lower FPS averages out when less enemies are acting. But I think over all sessions I've played about equally good / bad for both versions)
My results:
- Skeletal Mean FPS: 97.0
- Skeletal Std. FPS: 3.83
- Static Mean FPS: 112.44
- Static Std. FPS: 1.18
The results imply that there are roughly 15 FPS gained through the introduction of the new guns and that the overall performance seems to fluctuate less. However, the methodology does have some flaws as already mentioned with longer play sessions generally giving a higher average framerate.
In conclusion, I think I will keep both options available in this project. Since I use polymorphism to run the animations on the guns, I now have two C++ base classes, one for skeletal meshes and one for static meshes and the the NPC and player actors can use both in the same way. I hope this analysis can shed some light into the discussion. Thank you again for making the video, for me personally it was definitely worth it to look into.
@@dominikwerner6608 These are fantastic results - thanks again for following up. I'm glad it helped your project!
Just a short idea by side , anyone tryed to use that method to attach a static mesh to a skeletal mesh .Modify the material to act like the skeletal mesh and than put Nanite on it ? So The low Poly SKeletal mesh holds Physic Asset. animBp , Postproces and that stuff an an 9.000.000 Polygons Static mash what you can than Animate with the control Rig.
Unfortunately Nanite doesn't support world Position Offset.
I'm hoping that unreal datasmith at some point will be capable of importing constraints from parametric cad assemblies.
That would be awesome.
good tips, nice to know :)
but.... from revolver to minigun, all guns use only simple vectors and rotations, as animations....
isnt it even cheaper to use simple timeline transform nodes and static meshes, with no vertex maps ?
Splitting the mesh into multiple components traditionally would result in additional mesh and material draw calls, so it's not necessarily much cheaper. There are other pros and cons, but it may be worth exploring for some projects.
With that said, Nanite can batch draw calls much better. It only requires one material draw call for any number of meshes that share the same material, which may make this method more viable than ever.
Good job way more from this please asap Sir !
Appreciated!
Vertex animations are great, but they are massively lacking when it comes to interactbility. No physics, no collision, it doesn't update the vertices for ray casting etc etc. Skeletal meshes aren't that expensive, I wouldn't worry that much about using them
It can update verts for raytracing, but it doesn't by default. It just requires updating the BVH every frame - same as a skeletal mesh - if you want the animation represented in RT reflections or shadows.
But in many cases you won't need updated physics or collisions for many animations or possibly even the updated BVH so there's no point in paying the price for these.
Skeletal meshes aren't that expensive in moderation. Crowds, swarms, or using it excessively for props absolutely can cause massive CPU bottlenecks.
But yeah, it requires more custom tooling so it isn't a one size fits all solution.
Sometimes it's also just plain simpler and cheaper than having a rig, or used in combination with one. One such case is the tentacles of the Kraken in Sea of Thieves. It used a traditional skeleton for the main tentacle, but vertex animation for the suckers. It's used all over in big ways and small, but often goes unnoticed and underappreciated. Thanks for watching!
this is so misleading, especially for an hero asset like a weapon in first person or third person attached to an already bone dense character...this issue should not exist or it's not worth to use alternative more time consuming methods. Like one comment said, this could be useful for an RTS, but that's pretty much it
If it were just one skeleton I'd agree, but often games will have literally dozens of on screen at once, and these techniques generally do not diminish the quality of hero assets. Besides, the video is more about the concept of vertex animation in general, not this specific application - a gun is just a simple and convenient demonstration that features both transformation and rotation and can be applicable to a wide number of projects.
Every project is different and obviously not all will obtain the same benefits from vertex animation, but that hardly makes this misleading. Low end hardware, like mobile/Switch are another case where extreme lengths may be necessary to hit frame targets.
@@TechArtAlex then don't call it ''stop using skeletal meshes!'' like you discovered that they are not viable in the game industry, i stand by my comment, this is very misleading, i don't even know if it's wort for an rts since they're weapons would not have more than 1-2 bones anyway, we get it you are cool and in using 3000 nodes you can do the same, but it's hardly worth the time and money in development.
I show in the video how to test if the skeletal animation tick is bottlenecking performance. I say in the video that some situations require skeletal meshes, and others don't. I trust viewers are smart enough to decide when it is appropriate to use the tools I give them. No one is being misled into believing skeletal meshes are taboo. The entire point of the video is about thinking critically and making an educated decision.
@@TechArtAlex As i said, the title is pretty misleading and i had at least two beginners linking me this video telling me they won't use skeletal meshes, i had to explain that your video was indeed misleading.
afaik there was a tutorial on the unreal channel which used this approach for a birds niagara and an army battle sim
Right, this technique or similar methods are often used for particles (which don't support skeletons) or large crowds, which would be too costly for skeletons. Most often, the animation is baked into a texture instead of created in the engine but which is better depends on the complexity of the animation, and the number of objects on screen. The texture will excel in large numbers, because the texture sample will be less expensive than recomputing normals in real time for a large number of objects.
Sticking with the example, isn't it simpler and faster to animate a simple hierarchy mesh? No bones or vertex morph shaders, just simple translates -> much less data and calculation.
You might get 4 meshes instead of 1 in this case, but if you have the same material, the GPU will solve that in 1 draw call.
Historically this would mean 4 mesh draw calls, even with only 1 material call. But this idea is much more practical with nanite. It's definitely worth exploring, especially in fully rigid animation.
Vertex Animation also works for semi-rigid and non rigid animation. I just stuck with rigid animation to keep things simple.
@@TechArtAlex There is draw call optimization it's called draw call batching - dynamic batching. This is not even a new method.
@@hamuArt I don't believe that applies if they are different meshes, which would be true for an assembly.
@@TechArtAlex I would find it strange that this old technique is not used by Unreal, when Unity and other engines are. The point of dynamic batching is that it renders the draw call based on material. If the pistol has its own material, then regardless of being made up of multiple meshes, it would be easily handled by the GPU api with one draw call.
@@hamuArt ua-cam.com/video/qx1c190aGhs/v-deo.html
"Static Mesh Component Draws with the same Material Instance *and* StaticMesh will be merged unless..."
Dynamic batching in the manner which Unity implements is often not an optimization, as the necessary CPU transformations often exceed the cost of the additional draw calls on the GPU. Per Unity's official documentation: "Note: Dynamic batching for meshes was designed to optimize performance on old low-end devices. On modern consumer hardware, the work dynamic batching does on the CPU can be greater than the overhead of a draw call. This negatively affects performance."
I wish cloth simulation worked for static meshes
There are lots of cases where shaders can give the impression of simulation. Maybe we'll see cloth sims on the vertex shader achieve a similarly convincing result someday. Until then, it works pretty well for pre-baked vertex animated cloth sims, at least.
Yeah, in my case I'm actually stimulating something that needs physics on cloth (a ball hitting a net)
Super excellent video. Thank you. I'm curious on how this would work if at all with a ball joint or something more complicated like a 4-wheel vehicle. I see the value in it, because I can then use nanite for my vehicles & weapons, but how would I handle the suspension for example or animate with this method. (I know nanite doesn't work with Transparent and Opaque materials at the moment.).
Nanite also doesn't work with world position offset currently unfortunately, so this technique is only applicable to non-nanite static meshes. Therefore, the main reason to use this technique is generally solely if your animations are taking up too much frametime due to having too many skeletons ticking each frame. Another major reason would be if using a skeletal mesh is impossible, like within a particle system.
In most games, there are only a small number of vehicles on screen at any given time, so I don't think there's much frametime to be saved with this technique. But ultimately you can always experiment if your project calls for it.
@@TechArtAlex Thank you for your thoughtful reply.
Trying so hard to read the nodes here XD
My sight isn't what it used to be
Just realized you uploaded it in 4k. What a lad! TY TY
Thanks for watching!
my brother in christ would the collisions even work though? might aswell just make a component for the pivots in bp
No, collisions would not be altered by the vertex animation, so if that's important, then this is not the way to go.
Use model parts as bone of themselves -no need to re-invent a wheel here
Works fine with vehicles, works fine with guns
I think you've missed the point. Bones are less performance friendly than static meshes. Vertex animation is dramatically more efficient at runtime. If you don't need to reduce your skeletal animation tick, then sure, do what works for you.
Looks like a video from someone who discovered vertex animation for the First Time "yoo dude that's Amazing stop using traditional animation". It's not that simple, you didn't factored what makes a good animation, what an animator uses as tools to modify stuff, normals etc.
It's obviously not that simple, and I bring up the issues that vertex shader animations cause for normals in the video. But very frequently a lot of the tools available to skeletal animations are unnecessary. The video is already over 20+ minutes, at some point I have to leave it to the viewer to decide if their project can benefit.
@@TechArtAlex Probably is the gun example that isn't the best for this kind of animations, maybe stuff like antennas/poles in the wind are the perfect objects that can get the max out of the techniques with masks and a more "procedural" approach
Yeah those are great examples as well. I mostly just wanted to get people to think more critically about their animation choices rather than just jumping into the easiest (but costliest) solution. Thanks for the feedback.
That is a good technique for background animation but that will be very unpractical or limiting for an asset like a weapon in production because it will add a lot of complexity to manage weapons animation for developers.
Instead of just blending poses or play animations from a (hopefully normalized ) list for a lot of weapons you will need to have a different implementation for each to control the shader uniforms with good timing, if you control that by blueprint instead of cpp it might even be a bigger hit when the animation is actually played .
But well, that technique can be good if you need a ton of animations, that is why we animates grass, tree and other foliages with shaders instead of bones.
There is also a video from coffee stain studio on Satisfactory where they show the work of a technical artist, and they do use that method to animate pistons on pipes, they spared a lot of cpu by moving animation from skeletal meshes to shaders, but they only need to control the frequency and amplitude of the piston from the gameplay
This was to show the concept of vertex animation in a basic, but often unseen form.
It really wouldn't be that complicated to time the events, but I would make some changes in a production shader. Here's an example: You can store the timings in a vertex animation texture with a custom UV set which maps each animating part of the gun to an X position in a standardized way (This would also replace the need for vertex colors shown). The Y axis would be a timeline for these parts. The simplest way to do this is to have each Y position represent a frame of animation. Multiple animations can be stored along the Y axis, and multiple weapons can be stored in the X axis, since each only has a few moving parts.
Then, the code/blueprint only needs to tell the shader what part of the texture to sample. A single material parameter collection could define all of those variables.
Every project is different, and this kind of workflow is definitely not going to be suitable for all. But this video is really just to get people thinking about unexpected ways they can optimize their animations - not a tutorial. Thanks for watching and commenting.
@@TechArtAlex Interesting, that would certainly be a more complete way to manage it, and could even be automated from the 3D software to be able to work with "regular tools" ?
Anyway i just wanted to voice my concern about maintaining that kind of system at larger scale, because it could look like an 100% win for less experienced users who may miss the other less desirable side of it, and the gun exemple don't seem to be the most fitting for that kind of optimisation .
Otherwise the method is pretty legit .
Yup, a python script in blender could easily generate that kind of texture, for example. It's definitely accessible to indies, but it's not *as* accessible compared to just putting a skeleton in everything that movies.
I just wanted to challenge that notion and get people thinking critically about animations and excited about technical art. There's been tons of great dialogue in the comments and I really didn't expect nearly as much attention as this video got.
Curious. What were you doing that you were spending 0.5 to 1.0ms or more on animation? Or did you have these skeletal meshes in mass or something?
You don't need a mass of meshes to spend half a millisecond or more. Check Stat Anim to see the frametime cost for your own project to decide if there is any benefit to cutting back on skeletons.
@@TechArtAlex Oh, of course profiling will tell you whether to opt for it or not. But 0.5ms to 1.0 for ONE single skeletal mesh like this asset is unlikely, unless you're driving a very complicated physics asset, or you've bound other events that are taking CPU time to particular animation asset events or physics events.
This video is extremely helpful and I appreciate the tutorial, but your timings there make me wonder if you had other things firing hogging up that CPU.
@@TechArtAlex could some of this be the overhead of running the animation thread? I would like to see if that cost increases linearly
@@albarnie1168 It is not a totally linear cost. The first skeleton will be more costly than subsequent skeletons because of the thread initialization, so if there are any skeletons at all, that cost can't be avoided. Skeletal mesh costs scale based on the number of verts and bones. Assuming it's the same skeleton being duplicated, I expect the ms cost per mesh should be mostly linear with each copy. This is why it often only takes a few dozen skeletal meshes before there is a noticeable impact on frame time.
@Joey Pla Definitely could be other factors. This was UE5 early access after all. I didn't take much time to profile since the asset was created specifically for this video and the performance benefits of vertex shader animation are well known and proven. Thanks for watching!
Does this get messy when setting up the animations in blueprint?
As far as unreal is concerned, this isn't an animation in the traditional sense. It will not be compatible with any of the animation blueprint nodes because it is not a skinned/skeletal mesh.
Instead, you would use the blueprints to change the material's parameters. You could use a material parameter collection for example. You can also bake all of the animations into what is known as a vertex animation texture, and use blueprints to change which frames of the animation are being sampled to change what animation is playing. This works best for complex animations where doing real time math would be more expensive that a texture sample.
Can also use custom data channels so you don't need dynamic material instances per mesh
how do you tell blender to use GPU to animate vertices... especially when you're exporting to a game engine ?
It depends on exactly what you're doing, but the most direct example would be through displacement maps. As far as I am aware bender only supports displacement within cycles renderer.
I really miss in Unity how you could import animated rigid meshes.
I have not watched the video yet, and I don't plan to use unreal so I want to ask first is this video strictly applies only to unreal engine or to 3D games in general?
Vertex Shader Animation as a concept is applicable to 3D games in general, although much of the workflow shown here is pretty specific to Unreal.
It helped me a lot.
I Hope you record your future videos in 1080,
It's in 2k
Would this method actually affect the location of the mesh, when it comes to physics?
For example, let's say I put a marble in the space behind the slide. I pull the trigger, the slide goes backwards. Does using vertex based animation mean it actually hit the marble and trigger physics, overlap and onhit code?
I am making a game that has airbrakes on a ship, which rotate. When they rotate, I want them to potentially collide with objects. I currently use static meshes for this, but was considering using skeletal meshes.
It does not effect the collision mesh, so you have to manually account for such an event if needed.
@@TechArtAlex Thanks!
will vertex based animation works in unity please reply
Yes, Unity supports changes to vertex position in the shader, which allows for vertex shader based animations.
@@TechArtAlex if vertex animation is less costly, than why everyone make bone based animation on guns??
@@arunachalpradesh399 Mostly because it is easier to set up and implement. Every method has pros and cons.
im glad I ran into this video
Could you go into some detail about the Fix Rotation About Axis Normals node? I'm having a hard time getting it to work.
It should function identically to the Rotate About Axis node. To get the correct behavior the inputs should be the same for both in most cases.
Using the normal buffer visualizer is a good way to debug any issues with the node.
If the inputs are the same, then there may be something wrong with how you are masking it or applying the output normals. Also check the pinned comment for some remarks about local/world space transformations I didn't cover in the video.
@@TechArtAlex hey thanks for the reply, I've got it to work somewhat but the results seem to get worse as the rotation increases, perhaps the pivot point for the node needs adding? I'm also blending these results with a normal map using the blend angle corrected normals node.
Although we discussed this privately I wanted to add a public comment for anyone who is having the same issue.
Be sure to change the pivot of the normal fix if it doesn't share the location with your object pivot. I mistakenly omitted this because the rotations were so small and close to the origin, thus the error was not noticeable.
Second, normal maps are directional, there is some math that needs to be done to change their directionality. In many cases this issue will not be noticeable. Here is a post with more information: realtimevfx.com/t/tangent-normal-map-rotator/3749/6
In the indie space - of Unreal - you mean... no one does this in Unity
I dident even know that people did this... Why? Like for a chest, just make two meshes and rotate one to open. Bruh. (Code it that way)
Yes, it is very common to make objects like chests out of skeletal meshes. Historically, doing it how you described would usually result in extra draw calls, so it was usually better to use vertex animations for such a thing.
That may be changing due to Nanite, which can draw meshes with fewer calls.
So depending on the project needs, it may be better to do it as you've described. I haven't tested how animating static Nanite meshes compares to Vertex Animation.
That said, there will still be many cases where vertex animations are necessary, like more complex animations like turning pages of a book.
@@TechArtAlexLol, I still use meshes all the time, it looks good enough so whatever XD Plus I rarely ever need to make complex stuff like that. But it does make sense for super realistic games. I just don't have the time and patience.........
there are zillions of vector rotations going on inside a game, that's what bones are for....one chest opening/closing at a time will not kill your framerate
True, but this isn't really about one chest or skeleton. It's about identifying if skeletal ticks are a bottleneck in performance and some ways you can deal with it.
There are only two animating techniques that are used which is skeletal and morph target.skeletal is good for rotation movements and morph target is good for linear or translational movements.
There are not only two. Vertex shader animation is used extensively, especially for animations that would be impossible with more traditional techniques. There are many examples of this method being used in major titles.
Great informative video. Soooo much vocal fry though.
That's a horrible idea. There are many ways to optimize skeletal mesh. But most importanly - there's no replacment for skeletal mesh. We are talking about pipeline - animation is done by ANIMATORS, not by technical artists or whoever makes complex materials in your studio. If you want a nice-looking animation made by animator, not restricted by vertex offset method limitation - you have to use skeletal mesh. Vertex math is a horrible method for your pipeline. It gives a horrible result, takes a lot of time and can't be done by animators.
Some studios have the privilege of animators who are also capable technical artists, or want to learn. But every project is different.
A handful of gun bones going to really effect performance? Cmon. Optimize something else IMO. Time better spent elsewhere.
If that is your takeaway, you've either missed the point of the video or perhaps didn't watch all of it.
The point is to challenge the idea that just because something must move, it must be skeletal. It's not really about guns at all, but on a project level having tons of extra skeletal meshes everywhere that could be easily animated with textures or cheap math can save performance at scale. This is a proven solution to skeletal mesh bottlenecks and the fundamental technique is applied all over shipped games. A gun is just a convenient example of a common skeletal asset that often has only simple animations. It could just as easily be environmental props, crowds, small animals, etc.
KEEP USING Skeletal Meshes! and also use sliders to make player ajust the Mesh size. for Perfomace.
Yeah, cool and all, but lets be real, its ridiculous. To animate like that is way more complex than it should be. it breaks as soon as you rotate the model in the world unless you do some math in the shader to get local coordinates, basically you are just moving the load from CPU to GPU in a very inefficient way, now you are doing animation with math. vertex offset in material and skeletal meshes all have its own use cases. This is a skeletal mesh case, not a material one, what about if you want to make skins and decals? what about attachable parts? The performance part is neglible. You would be wasting more time calculating the math for any change than just taking the hit, this would be like spending 10 bucks to gain a penny.
waste of time.
Bro I'm like 2 minutes in and you haven't said anything yet, Jesus Christ
A couple of notes and caveats on this:
Vertex shaders do not update mesh normals, so this only works for translation. This is also not an adequate workflow for animators if you are doing interacting reloads.
There is a lot of optimizations you can make on skeletal meshes to reduce the cost.
Static mesh bounds, update rate optimizations, visibility tick and manual ticking (not ticking the weapon when is not moving), as well as lod settings inside anim graphs can help a lot to bring the cost down. GPU skinning if you are not already using it makes skeletal meshes way more efficient.
This is still an important technique to keep in mind.
EDIT: i would also not recommend running performance tests in ue5 in its current state. Afaik skeletal meshes are much slower than they should be there and a lot of optimizations are not working for skeletal meshes (nanite is not enabled, so virtual shadow maps are very inefficient among other things)
You can also get rotations and manually adjust normals. For anything more complex than a transform or rotation as seem here you can use Vertex Animation Textures, and can bake the per frame vertex positions and normals into an image. But yeah, just another tool in the box.
@@TechArtAlex true! I really want to get into using vertex anim textures more.
transforming normals is just as easy as transforming vertices in ue4, only if you don't use a normal map. Normal map is also possible, but it is not effective and painful.
@@TechArtAlex Vertex animation textures are limited to meshes with 8192 vertices, though.
A thing that you can/should do if you're doing a a complex non-deforming animation (like a weapon reload or weapon firing animation) is still build the skeletal animation, but have the imported skeletal mesh only have a single triangle, and then import all the sub-components as static meshes and attach those static meshes to the skeleton in the blueprint. This is what Epic did in the Valley of the Ancient demo for the big stone robot thing.
@@Fafhrd42 Vertex Animation Textures are not limited to 8192 vertices, they are limited to 8192 pixels of data. You don't have to map each single vertex to a single pixel and it would usually be wasteful to do so. In the example pistol asset, large groups of verts are moving together as a single unit and can share a single pixel with a VAT. This means that you could easily store every single gun animation for every single weapon from a typical game within a single texture sample in memory.
Hey simple question,
Can you with this method make an infinite rotation on a fanfor example ?
Yes, that kind environmental animation is one of the primary use cases of this technique. You would just input time * speed into the rotation angle, and something will spin nonstop.
@@TechArtAlex Oh thank you for your answer man !
cost in performance ???
- the player character rarely sees these sort of details, yet he's only using/reloading one gun at a time
- the antagonist are so far away and move so fast, who the fuck would animate their guns ?
Performance cost depends on the number of bones and the vertex count of the mesh, as well as how many skeletons on screen. There are profiling tools to see what the cost is.
Most games use animated guns for both the player and enemies. Vertex shader animations can also animate much more than just guns, this is only a simple demonstration of the concept.
Just a quick 26min video. Good content though, I'm not even mad.
Haha thanks! Trust me it could've been a lot longer!
@Alex I would like to learn how to make insect wings flap.
The rotate about axis node I cover in this video is one way to do that. You can use a sine wave in the material to procedurally animate the flapping, for example. This is really no different than the rotating trigger/hammer of the pistol.
You could also consider vertex animation textures, which is an extension of the concept I've shown here. The difference is it caches the full animation as a texture. As a result, it requires more texture memory than the method I've demonstrated, but allows for more complicated animations without needing as many real time calculations. Martin Donald has a great youtube video on this subject.
sorry, but this is honestly one of the most awful advice I've ever seen. don't title your video this way and mislead people.
It's hyperbole. No reasonable person is going to completely stop using skeletons because they learned a little about vertex animation.
@@TechArtAlex title and thumbnail the video appropriately. its clickbait
I knowed this method from water Materials but, i never saw it on special Object . Realy usefull ! I try to have always an eye on the Performance but to be honest i have no clue if Optimize it for real. To know one more thing what definatly Optimize , Helps.
would be great if you told us what "unreal" software you use
This was in UE5 but it works the same in pretty much any software that supports World Position Offsets.
really nice idea, my only concern is in the case that you need to swap and on the reload of the weapon, because that we normally do is animate the body bone of the weapon, to follow the new parent but the root keeping the original partent, but with static mesh we need to do that with a swap of parenting.
You can pass the bone transforms through as a material parameter. Or, baked vertex animation textures are also well suited for more complex animations. Ultimately, this video is less about guns specifically and more about relying less on skeletons in general, when possible.
Thanks for the tip!, Just like you said, I never even considered doing this for anything else than the foliage or trees in my game.
I'm used to modifying textures in real time but I have almost no experience working with the vertex shader.
Fun fact: For early 3D games vertex animation was the only method for animation, including full character motion. Real time skeletal animation systems wouldn't widely emerge until the late 90s, with games like Half Life.
Vertex animation has become somewhat of a lost art because skeletal workflows are easier, but they have an often overlooked cost. Thanks for watching!
@@TechArtAlex I just implemented this technique on a Home Safe static mesh with a numbered wheel mechanism using three RotateAboutAxis nodes (one for the safe door, the handle and the wheel) and managed to have it work perfectly!.
The only issue I encountered is that since the wheel and the handle's normals are also affected by the rotation of the door there's a slight error in the normals in this two parts of the mesh I couldn't fix (again, barely noticeable, just adding the values gives a good aproximation), did you ever encounter a similar situation?.
(I am currently Adding the normal corrections between each other and then blending them with the BlendAngleCorrectedNormals to the detail Normals of the safe).
@@manafon5398 Start by adjusting the wheel and handle normals, masking them out and adding together like shown in the video. Once they are working correctly individually, the combined output of this will be the input world vertex normals for the door's normal correction node. Now, the door will know about the changes in the other normals when it does the final correction.
In my example, I simply left the input normal slot of those nodes blank because I didn't have any multi-layered correction like you do.
Really awesome to hear that you were able to implement this successfully! Hopefully this comment will get your normals perfected.
And what if there should be attachments to this weapon? And lets say you have dozens of them in your game. And some of them can be attached to different weapons simultaneously and lets say to a different attachment point which is defined by a player. So the animator should setup every individual of them manually for every single weapon and every single attachment point? Just imagine the amount of work there.
I think it will be so complicated to setup every single of those that it will be a complete nightmare to animate.
And how you suppose to animate the magazine of the weapon? And other stuff with which player hands are interacting? The bolt for a bolt action rifile for example? The slide bolt for an MP5 for example?
I mean at some point it will turn to be so complex to script that the cost of this system for a developer and the amount of potential bugs will be significantly more valuable argument than any perfomance advantage that you get.
There are simple solutions to all of these problems, and I've given examples in other comments to some of them already.
This is a basic introduction to an array of advanced animation techniques, so if you miss the bigger picture it is easy to get lost on the details.
There are infinite applications. I chose to demonstrate a gun because it has both transformations and rotations.
The purpose of the video is to challenge the notion many beginners have that in order to have an animation, they must use a skeleton.
I'm not really sure what point you're making about attachments because you would just use sockets in the exact same way as any skeletal mesh.
If you either have the budget to spend on skeletons, or lack time and/or interest to use alternatives that's fine - But these techniques are proven and widely used.
@@TechArtAlex sockets have replication cost. I'd just use a bpi requesting a local transform and doing the quick math. That's how my gun plugin works
How does splitting the gun into multiple objects and just animating the moving parts by their transforms compare to skeletal and vertex animation?
Normally the issue with splitting a mesh into multiple objects is that each separate part could incur a draw call. There are ways to avoid this, like using the part masking technique shown in the video to mask out sections so that all of the objects can technically be the same mesh and therefore instance capable.
I haven't tested, but because of the efficiency of static meshes there's a good chance this could still be more efficient than a skeletal mesh and it would not require manually adjusting vertex normals for rotation as in a shader driven approach.
Perhaps one could even use a mixed approach, with vertex animation handling linear motion, and a separate object where rotations are needed.
With Nanite, the ability to render static meshes very efficiently may also prove to be a viable alternative for rigid assemblies like guns.
@@TechArtAlex That's typically how it should be done in UE5 with nanite when your object is made of non deformable parts. That's how they made the giant in the demo.
Even in ue4, the extra draw calls still have a lower impact than using skeletal meshes and if several players use the same weapon, the drawcalls count won't increase thanks to the static meshes auto instancing (you will still get extra draw calls for the cascaded shadow maps tho)
@@TechArtAlex I started using vertex animation textures a lot lately. Also, lots of Niagara mesh renderer for animating meshes. I just make a custom Niagara module that handles animation stuff.
@@AlenHR Vertex Animation Textures are amazing and highly underrated tools.
@@AlenHR ooh interested about your Niagara module
Nope it will not cost much performance, unless you for eg. make RTS and enemy army each with such skeletal mesh gun. For when only player character has such animated mesh is fine. Single skeletal mesh does not make difference.
How many games featuring guns only feature one single gun? Shooters might have dozens of characters on screen at once and this method can easily halve the number of skeletons. Besides, I make it clear that the video is about the general practice of minimizing unnecessary use of skeletons, not this very specific application. It's very easy to profile what the cost is for skeletal meshes, and not all games will need the same level of optimization.
Add this to the 1m things on my to-do list. Great vid.
You microphone picks up everytime your lips smack and when you gulp and it triggers misphonia. Might want to have some kind of compressor on the microphone. Otherwise I'd have finished this video, even though I know you are talking about vertex animation and I wouldn't waste my time on it for a simple object. It makes logical sense, but its way more time consuming to setup and debug everything over a skeletal mesh. I'd use it only for peak performance optimisation or when I need repeating objects like crowds.
Right. Every project is different. Not all of them need this level of optimization and it is more effort to use a less traditional workflow. I'll try to improve on the audio - to be honest I didn't expect this video to take off so much otherwise I might have spent some time editing it. Thanks for the comment.
@@TechArtAlex it's all good. the misophonia is my issue, but I empathise with others who suffer from it so I like to point it out. Probably makes me sound like a douche :D
Зачем нужен весь этот геморой если скелет намного удобнее в использовании при этом его можно оптимизировать так что бы затраты были такими же как от статической модели
Статические модели почти всегда дешевле скелетных. Но вам это может не понадобиться, если вы не ограничены ЦП.
Sometimes it's better to make several meshes with the same material and textures and animate their transformation (instead of an advanced vertex shader), and simply rely on batching to save your ass.
Yeah, that can definitely work. You can even instance the mesh with a simple vertex masking. The advantage is you can render all the meshes and mats in a single call, and you don't need to recalculate the normal in the shader. Maybe I'll do a video on that too.
@@TechArtAlex curious what you mean there about the instancing with vert mask.
@Life Art Studios if you divide the world position of a vert by 0 it becomes "null" and disappears. Using a mask, you can control which part is or is not being removed by the vertex shader.
This allows you to create an assembly of the different parts all using the same static mesh.
Null verts do still have a cost associated with them, but they do not have a cost in the pixel shader as they won't occupy any screen space.
Is this the same thing as using Shape Keys in Blender?
It's more like using a displacement shader in blender's cycles renderer, since it's driven by the material.
NO do not stop using!
I love it! Thanks
Thank you for the insights!
Would this work for a Bow or Crossbow?
I don't see why not. Perhaps a gradient mask could be used to reduce the strength of the effect towards the center of the bow arms, creating an arc.
I understand the point, but I still think adding that many nodes in your material will slow down your game too. As it is harder to optimize GPU than CPU in most cases, I would continue using skeletal meshes.
Generally no, vertex animation is still usually dramatically faster despite some added shader complexity. It is widely employed in RTS games and other scenarios where it is impossible to have as many skeletons as required and meet performance targets. Vertex transformations on GPU are highly efficient and the math being done here is very simple.
The true cost is the time spent using a workflow that is less convenient, when many games might perform fine with a few too many skeletons.
@@TechArtAlex Honestly, the only place that I'm thinking this might come handy is when animating a crowd. When we were testing out the frame rates for low-poly human models, what became a problem was that after we created 50 instances of the model, an idle animation dragged the FPS by 10. Other than that, for something that will require systematic and dynamic editing, such as a gun in your example, most teams will go with the industry standard method of using skeletal meshes.
Crowds are definitely the most relevant application of the technique, but I think you're underestimating the cost of skeletons.
Consider your example of 10 skeletal characters, whose idle animations are already challenging some hardware. Now add in skeletal guns, or environmental objects and you've probably more than doubled the number of skeletons ticking every frame. It's up to each dev to experiment to see if they can net a savings in frametime.
The purpose of this video is to show that there is another way, which is often overlooked.
@@MustafaBerkeGureltol If you have quite a few Skeletons using the same animations and are using UE4/5 you can look into the Shared Animation Plugin.
@@shannenmr which removes collisions from your mesh btw
Hello. When I put a bone animation I made in blender unreal, the animation works fine, but the bones are very small. How do we fix this?
same in ue4?
Yeah, exactly the same
When you say vertex shader, are you moving the components with a script?
This is done entirely within the material editor, and there is only a single static mesh component. But you would need some kind of code/blueprint to control movement in game.
IS this about morph targets ore an other way ? may i watch it than later but 30 mins for things i know.
No, this is about vertex shader animations on a basic level. Morph targets still require skeletal meshes (although I do have a video on how you can get morph-target like results on a static mesh)
@@TechArtAlex Thanks for the fast answere i worked just 2 weeks ago first tim with morphtargest for the livlink kid on ym first charcter ( Dragon) and wasn´t know that its just for skelletal mesh and i wil check it. Are vertex shader like wave materials ? Ore you know what i just watch the Video ,:D . If you need a Dragon Soon for unreal Engine may this is Something you like ua-cam.com/video/F0UufeKNhPo/v-deo.html Created in blender textured in mixer
Would it make sense to have a relatively simple skeletal mesh with static meshes attached to it, like they did with the ancient in the valley of the ancients demo? Or are you still losing performance due to there being a skeletal mesh?
In some cases it might be, like the ancient. It had so many polygons that it probably would've been impossible to do real time with a skeletal mesh. However, multiple static meshes are usually going to incur multiple draw calls.
I think it could go either way.
@@TechArtAlex I was thinking you could do that in the pistol example with separate static meshes for frame, slide, etc, but if using multiple meshes is slower I guess maybe there wouldn't be any benefit.
@@sircod If you can draw all of the meshes in a single call, it might be more efficient. Nanite's render pipeline allows this, as could some clever shader tricks. If each mesh is non instanced, then having multiple draw calls may outweigh the savings.
Why would you have a mesh. You can of course make a rig using bones and attach each “static” mesh to each bone. The key is not to skin the mesh to a rig. Then it deforma the mesh. We just want to translate the mesh. If the transform is stored on the mesh itself or referred to a bone hierarchy matter little performance wise.
I mean just classic setup used since the PS1 / Saturn days
Indeed. It doesn't really matter where the transform data is coming from. A mesh-less rig is a perfectly good source of animation data that can be passed to the mesh transform or shader. The bones will still incur some cost, but so will any method of producing the necessary transforms. Again you just have to be sure not to introduce extra draw calls doing so or else you'll just be trading one optimization for another.
I'm sure there are instances where this might be the best approach, but I question if it's worth it for most use cases. Animating a pistol through the vertex shader vs using a skeletal mesh might earn you, say, a tenfold performance increase per mesh, sure. But if that pistol with skeletal animations was already having a negligible impact on performance, and there are only ever going to be a few dozen guns at most in your game at any one time, then all you've really done is traded the ease and familiarity of using bones for a significantly less intuitive system that far fewer people understand. Unless you're targeting hardware from a decade ago or plan to have thousands of animated assets loaded into your game at a single time, it doesn't seem like a sensible approach.
It's definitely going to depend greatly on the project specifics, my main point is really just that we should ask ourselves if we actually need a skeletal meshes for the asset in question instead of just assuming anything that moves must be skeletal as many do. Almost any project can benefit, but like you say it may be negligible and not worth the effort or less convenient workflow. The pistol is just a convenient example of an asset that is often skeletal, and demonstrates both linear and rotational movements that could be fairly easily animated for the video.
6.27 you have Static mesh, and looking at SkinnedMeshComp Tick, they are not really related, and yes, it's performance costly when you have AnimationBlueprint.
Yes, I was showing that using a static mesh eliminated the cost associated with the SkinnedMeshCompTick for skeletons. Thanks for watching.