- that’s not true at all. The whole idea is to get it right in Blender first. I have a rig that was created in Blender that looks crazy in Blender but works absolutely fine in UDK/UE3 (in Blender the bones are tiny and they all face along the z axis. But in UDK it looks perfectly normal.) The problem is figuring out the differences between how UE4 handles bones and how Blender handles bones, and making the adjustments in Blender. Which seems to have been solved with the above rig, which even has normal looking bones in Blender and works with UE4 animations.
LcSweeper - All these things are relative. There’s a link to a working skeleton right there. What could be easier than that? You can model around it in Blender or export it to either Mudbox or Maya and do the same. I work alone so I don’t have the time to animate every single movement and would rather use stock animations. If you want to do your own animations then you can use any skeleton/mesh/program in the universe so long as you can get the right .fbx format. The only issue is that when you want to use the UE4 animations - obviously the skeletons have to match. This is the issue. UDK and UE4 are basically freebies that Epic just gives away and as such usually only work with the tools they actually use to build the games they make. It’s a bummer, but I don’t blame Epic. It would be nice to have a sort of universal support for every single application but, for those of us who use software like Blender, which Epic probably does not use, there’s a different pipeline which we have to ‘invent’ on our own. Luckily they support and encourage that, they just don’t have the time or resources to do it all themselves while dealing with the other bugs and so forth.