I'm going to do everything I possibly can to get the algorithm to give you a boost. I've been looking for a way to do this for ages so I can keep different clothing items in separate files. This is perfect. Such a good video. Thank you!
Lol thank you so much, I'm glad it was helpful, I found it a little odd it's not super well documented, but honestly once I figured it out it's quite easy! I hope your project is going great~
Lol thank you for your kind words, a lot of times is easier than you might think, different languages are usually just a matter of different syntax. Thank you again for the kind words~
It is an awesome tutorial, thank you. What if I want to make an armor piece that has it's own advanced rig extending default one or separate individual rig? I mean, I have a default character rig and an armor piece that is attached to it, just as you shown in this video. I want to make, for example, an armor piece with a cape that is rigged individually, so that a part of this armor mesh (body part) is affected by the default character rig and the other part (cape part) is affected by its own individual rig made specifically for this cape. Is this even possible? I honestly don't want to mess around with a "default" character rig that would have all the possible bones for any clothing option present in game. Could you please clarify what's the best practice for implementing such things?
So this one is a super complicated subject and one that I've thought about for some time. There's several schools of thought in my head on the subject, but I would hazard a guess no one idea is the "Best practice" for it, as the best practice is unfortunately not a single unified solution, but I'll get to that in a moment; The first school of thought is that you have the a script which is inherited by any piece of equipment that requires a modified rig, it has a function to allow it to connect to an animation player and it simply transfers all animations to the new piece of equipment, which has a rig that has it's necessary bones (the cape bones for example), as well as all the normal bones it requires (maybe the shoulders and spine). This would probably require a lot of trial and error to get right, but theoretically it's possible, just difficult. The second school of thought on the idea is to have it bind to the primary skeleton but have the parts of it which are affected by the other bones be a separate mesh bound to the new bones (in this case the cape would be attached to a chain of bones but not to the body skeleton), this could once again got a script to pass the current body animation state to the cape for any actual animations, but an easier solution would just be to have it attached using a bone attachment node to the shoulders and then just run an independent physics simulation on that one (which is a another matter which for the sake of brevity I will not go into). Another idea is to try to directly modify the skeleton at run time, which is theoretically possible, and I've done some crazy stuff adjacent to it, but this would be crazy difficult. However I have directly edited animation data before with scripts, so it's should be possible to also dynamically merge animations as long as no bone names are identical, this would require a fair bit of research and a lot of experiments to pull off but honestly is intriguing enough to me to warrant further investigation (When I have time). Now I said that none of these are probably the best practice, my reasoning for this is that time and time again I have seen games simply employ the old "everything on the body always" approach, that is, to have the skeleton be everything that could be needed at all times, every attachment or modification, with plenty of extra bones for things like tails and ears if necessary, and just not always using them. This is obviously not what you had in mind, but unfortunately it almost always on a production level is far more cost effective to have a system like this, and just have everything animated always, then to spare programming hours to actually make a modular system. Also the for the performance side, honestly the painful truth is that a system like this will likely actually be higher performance than any of the other schools of thought, because it requires no complex code to make work, and at the end of the day extra bones is likely to just be higher performance. I have to imagine that is not the response you were hoping for, but at least it might clear it up for you~ Best of luck with your projects, and have a wonderful week!
@@Bonkahe I can't thank you enough for such a detailed response! All your ideas seem pretty practical to me except, maybe, for the third one only because I have no idea how could I modify animation data via scripts just yet. I was researching the web for a really long time trying to find a workaround for this "problem". I moved to unity from godot a while ago simply because I wanted a bigger community to learn from, and I was kinda surprised when I couldn't find a proper 3d rigged equipment tutorial that would answer my question. This year I moved back to godot, started relearning again, and I think I was more afraid of finding out that the solution is really simple and obvious one than "we have no better practice since it's not that justified in terms of man hours and performance". Thank you for what you do. Your reply definitely helped a lot!
5:52, in C# you don't have to do "ArmorPrefab.Instantiate() as MeshInstance3D", you can do "ArmorPrefab.Instantiate();". Anyway, very cool video, I actually need this in my project too.
So you are absolutely right, you can do it that. Mind you as far as I'm aware neither one has any definite performance increase, but it works perfectly fine either way, I honestly just write it as that because to me it's simpler, and it keeps it slightly closer to the gdscript version, but for sure always go with what is most comfortable! Thank you so much for commenting! I'm glad you enjoyed the video~
