UE5

https://forum.unity.com/threads/amazon-open-sourced-lumberyard-renamed-to-o3de.1137019/

 

Does skinned mesh support work in DOTS animation yet?

 

Joachim Ante himself. CEO of the unity.

Animation package does. But dont expect running 10k skinned characters, or you may be disappointed. But personally I really dislike, how animation systems were written.

You can also write own animation systems, with custom shaders. But is heck a lot of work.

People also using different solutions, for animating huge count of characters.

 

I mean the real reason I want it to be properly supported by the animation package is because otherwise there's still no reason for me to do anything but bake some vertex data into a texture and animate that if I want loads of animated dudes or whatever.

I've written systems to automate that process, but it feels like the promises of DOTS that were made even early on three years ago are still years off, which was a problem even before the pandemic

 

Animation package does. But dont expect running 10k skinned characters, or you may be disappointed. But personally I really dislike, how system were written.

You can also write own animation systems, with custom shaders. But is heck a lot of work.

Unfortunately this still holds the true. DOTS animation is in limbo at current state, and for a good while. Baking vertices seems so far best options, if no need for skinning, or IK.

 

This is just wrong, as someone using dots in a medium sized project I see a lot of fear and loathing surrounding it, but regarding use of native collections quite frankly these are such minor things which are easily eclipsed by regular gamedev shenanigans.
There are a lot of things to criticize about dots currently, but manual management of native collections is really not one of them, its so brain dead simple even compared to something like pooling, which I presume any mildly complex gameobject centric project is forced to use in some form or another.

 

I need to catch up on ecs - dots, is there a good recap of the current situation? and tut?
I'm mostly interested in vectorization and multi threaded, what's more there is to it?

 

It does, and technically it has since 2019. Its very low level and very user unfriendly though, updates have been extremely slow so its a definite pain point in terms of user friendliness currently.

 

You don't need to catch up on anything, because featurewise its been more or less the same as it was for the past year and a half.

 

In case it's what you think I said, I don't think that "Unity lacks in features" in general, and I also don't think buying stuff from the Asset Store is the solution to that.

You talk about "AAA" studios, but the fact is that even if they are using Unity they absolutely have the capacity to make their own stuff. They don't need the Asset Store, and for a bunch of the reasons I listed they have good reasons to avoid it. Why rely on 3rd parties when they've got the resources to do it in-house, and probably better? Also note that a "AAA" studio can get access to the Unity source, so they have better access to extend the engine than most.

Second, the "huge expense" of buying Asset Store stuff for large projects isn't the licensing cost. Asset Store licenses cost very little. The real "huge expense" is the impact that a poorly designed asset could have on the project going forward. That's not to say it's a huge risk, because any competent developer in that environment could easily evaluate whether or not an asset will be a benefit or a burden. But my experience is that the majority fall into the latter category (and not necessarily at the fault of the vendor).

Back to the "lack of features", that's not really a complaint I've ever had about Unity. My perspective is pretty different to most forum users as I've been doing this kind of thing since before Unity was a thing, when reputable engines started at 6 figure prices, or you bolted your own stuff together. For me, important engine features are things like an effective toolchain to support all target platforms, a renderer that looks the same (and good) on all of them, a general purpose editor which I can extend easily. Past that I expect to be developing my own game-specific tools, so stuff like "who has the best built-in tree placement tool" and stuff does factor in, but only at a secondary level. If an engine comes with a bunch of built-in tools I know I'd have to make anyway then that's a point in its favour, but it's a long way down my list of priorities. Far more important is "how well does the tool set support me making the other stuff I also need?"

We are game developers. We will need to develop our own tools. Unless we're just making a tweak on an existing game it's not reasonable to expect that someone has already made the exact tools best suited to our unique thing. And these days there are quite a few engines which support us to do that really well. I care far more about that support than about the pre-existing tools built on top of it.

 

By catching up I mean I leapt frog the whole thing, because every unity stuff were premature I only dive when it mature enough for stuff I need, I only watched the original presentation, then the unite zombie stuff, and maybe one where they talk assembly stuff roughly.

Basically I want to survey its current state, but i stayed away enough i'm not sure the difference between dot and ecs is, except they are use generally together in discussion (my on the spot guess is that ecs is more the language stuff alternative to monobehavior, and dots is the underlying compiler tech that interface with ecs).

 

@neoshaman, I suppose this isn't really thread about DOTS. But since we are on mix of engines ...
Foremost, for catching up, there is tons of information there, answering what is DOTS.
https://unity.com/dots/packages#getting-started-dots

In brief, Unity DOTS, Data Oriented Technology Stack, is "collection" of multiple technologies.
The base one (with current classification) are Jobs (Experimental), Burst (Stable), ECS (Experimental).
Although, I am sure Jobs were stable once upon time. Should be completely fine for most use cases, if not using with ECS.
And there are some additional one, which are stated in the link above.
This tech has steep learning curve. So, if just starting, it will take quite a bit of time, to get deep understanding of different systems.

 

If your skinning and IK needs are extremely simple, you can bake per-area vertex animations through the use of careful masking and multiple textures. In a test system I had rudimentary limb control basically drawing from vertex colour data for index information and a couple extra textures. I could probably have gotten it all to work from a single texture that's basically tiled animation data but it was about that point I went "wait, why am I doing this? I'm making a game where no more than 10 characters will ever be on screen" and got back to work.

 

Let me wade in here, this is all highly speculative because it depends on what you're doing first and foremost. That being said, unless you're a billionaire and have been holding out on us you're not an equivalent to Epic games and you don't have a thousand people working on specific toolsets..

So if it takes dedicated, extremely knowledgeable teams years to implement specific tools how can you compete exactly? I have to reiterate this really does depend on project, your opinion won't reflect mine and that's something we have to consider whilst discussing these points. UE comes with a coherent / cohesive toolset dedicated to advanced 3D games which covers nearly every basis, in this saturated market where it's difficult to compete that provides one specific advantage over Unity. You spend your time creating content not developing features..

This isn't the XNA / Custom framework days and treating your development paradigm thusly as an indie working on "advanced 3D games" only serves to put one at a major disadvantage. Unity from my perspective is barebones.. Several of their core systems are inept for specific types of games, many features aren't complete and their generic implementation ethos means one thing to me, "more work".

Of course the simple solution to this is build smaller / less complex games that requires simpler features and / or tooling, although that puts us right back into the competitive product debacle. Strip your game back and the amount of competition rises therefore requiring a heavier marketing budget and so on.. Or one could just use the right tool for the job maybe? If someone has the budget, skill and time to pull off an advanced 3D game then Unreal is pretty much the best option right now.

I do agree with the support bit though..

 

DOTS is made up of three technologies together, but you don't have to use all three at the same time. I have seen some projects that use only burts and jobs for example... and this already benefits a lot in the performance of some projects. And it doesn't seem to be that hard to implement...

And currently the only thing that is not ready in the DOTS core is ECS (but it shouldn't take too long to do, as the most complicated part is already there) And Unity should work on some interesting solutions with DOTS once it is relatively ready. But, unfortunately, it takes time and Unity has not correctly estimated the time needed for this. Think for a moment, if DOTS was announced today, it would have a big impact and we wouldn't be discussing here whether it is worth migrating to Unreal. (And I think this is why Unity doesn't say anything about its internal lighting solution, so as not to make the same mistake)

Still, in the long run Unity and us users will eventually reap the rewards of this. Dots is a powerful technology that completely changes the basis of Unity

 

@stuksgens, DOTS it is not just 3 techs. It consist multiple techs. The 3 mentioned, are base one and advertised most commonly.

Also be careful regarding the state of individual packages. If you look into Package Manager, out of these 3 you will see, that jobs and ECS are marked as experimental.
Burst and jobs are with us for quite few years now, to be considered as stable (enough).
I personally don't recall having an issue with them.

 

Um... yeah? Do you want every post disclaimerd with "this is an opinion", and "it's ok for opinions to vary", and "I am not infallible" and "if you read this in the future things may have changed" and so on and so forth?

If you need something that Epic has specifically done or are doing then cool, use their stuff. If they haven't specifically done it and aren't specifically doing it then you don't need to compete with them.

And look, I agree that they're really good at what they do, but they're still human, you know? I get a distinct vibe that you're placing them on some imaginary high pedestal that nobody else can possibly attain.

 

I should just create a signature with a disclaimer, it would be far easier.

Have you read any of my posts? I spent a lot of time going through the downsides of using Unreal despite it being an unpopular opinion and oddly enough it seems to be the Unity forums where UE gets the most praise.

This has nothing to do with waxing poetic about Epic, the premise is extremely simple. They build 3D games, understand what tools are required and spend extensive amounts of time / money making sure said engine has everything it needs to make fortnite or tools for their AAA, AA and A revenue shares .. Of course I also meant general 3D games.. There's nothing "specific" about it, the engine is built ground up to cater to PC / Console 3D game platforms..

That creates a cohesive, well thought out and feature packed environment but that has nothing to do with Epic per se, it's just what happens when one makes advanced 3D games. I always thought Cryengine was the best platform for 3D despite its barrier to entry, the problems surrounding CE actually had little to do with the engine itself.

 

I think this puts you in the "has tons of experience" category.

For the people who are at the other side of that spectrum, I think the best thing is to have more like a modders approach. We want a premade toolset that is straightforward to use, and the best strategy for us is to make derivative games and find ways to work with our knowledge limitations, which means we can't stop production to build a tool for every thing we think we need. It becomes more a game of compromises, always asking, "well, do I really need that?"

And I think that's actually good for creativity. With knowledge and firepower a team can make whatever toolset they need, but then they end up in a bind where they spent too much money to make a thing and now there's a massive risk to make a return.

Way I see it, if I piggy back on someone who already spent the millions of dollars and took that risk and prevailed, then I can go further because I am not fighting the same problems somebody else already fought.

Using an engine that has tools perfectly suited for any game I'd want to make, and without much coding experience, I am able to to get most of the work I need to do done in fraction of the time an engine that requires me to make things from scratch allows.

I guess you have to look at long term time frame. Building a tool cost certain amount of time. Will it pay back? I think in most cases if the project isn't stretching on for years and expected to make back huge returns, then no, it's probably not worth it to build any tools that take more than like, a few days.

Anyway, not saying anything against any persons strategies, just offering mine.

Also, for the beginner, I think having a set toolset and workflow aids learning. It's pretty tough to get started from a blank canvas. Any artist can tell you that. This is why most start by copying other work, then modifying it, and only after quite awhile are they truly making anything totally from scratch.

 

Think it's pretty clear most people actually WANT to use Unity very much, which includes giving Unity a lot of their money. The problem is Unity has decided that they don't want our money, only film money or AEC money. That's the decisions they've made regarding internal budgets.

I say this with full confidence because that's the current shape and marketing of Unity today. It chases film and non-game industries.

Problem is Unity will find out to their cost too late, that game IS those markets and much more. Their competition knows this and has been taking that fact to the bank before and now. All Unity had to do was keep the TECH game centric, the latest game tech, the best optimisations, and then just market it with some tools on top to AEC and film. That's all that was needed.

Somehow though Unity managed to cook a banquet the hardest way possible for completely the wrong reasons, and well you know what happens when there's too many cooks.

Nobody actually asked for a banquet though, just a decent game engine that had a few film like tools on top like Cinemachine and Timeline.

At some point Unity's going to see that film doesn't really care about Unity and will just use them for minimal cost before it goes in-house or elsewhere.

"Realtime 3D"
"Metaverse"

These buzzwords mean very little in a market that's changing daily, not yearly or weekly. If you're responding, you're too late. You should have the best performance and scaling.

The engine that scales the best, outsells the rest.

 

Personally I couldn't care less one tool or another. I just saying same thing on repeat because what people were telling me a few years ago was, "unity is the engine most appropriate for beginners," and "unity can make huge world games no problem." But after putting this to the test, it seems to me the common wisdom (or at least what I percieved it to be) was opposite of reality.

Unity is presumably good if you are an experienced programmer/developer. If you are a beginner, I think the other options will get you from zero to published game faster and have more fun along the ride. THats just what I have found from short experience of a few years develloping games. I got no expectations and nothing attached to any engine - just tools I use and if one goes up or down this year I couldn't care less.

 

When I investigated unreal for the first time I was told that it has an alternative to Mecanim (it doesn't).

What is "a beginner"? There's always some level of proficiency you're requried to have or should be willing to acquire. And getting something basic done does not necessarily require "non-beginner" skill. And chances are that if you're running into a situation where you suddenly need to program, you're aimiing higher than a "beginner" would.

Going lower than unity would mean RPGMaker and GameMaker, by the way.

P.S. I remember a video on youtube I watched a long time ago where someone in their 50s or 60s was making a Mecanim tutorial. "See, now this skeleton is dancing". It was quite charming.

 

Yeah, maybe I worded it wrong. What I meant to say is that Unreal has more features out-of-the-box than Unity.

 

Any person who has been using the engine less than like, 3 years probably?

• Somebody who can't write their own tools
• Somebody who doesn't know how rendering works at a low level
• Somebody who can't make sense of the docs when people tell them to go read the docs because they lack prerequisite comp sci knowledges

In other words, 90% of the question askers coming to forums. People who have read many articles and forum post telling them how easy to make a game in Unity is, and that they shouldnt try Unreal because its more "advanced".

Like, coding with blueprints is as easy as it gets as far as I can tell. And like I've said a few times already, so far my experience in Unreal is that I spend 100% of my time grinding out work. But in Unity I felt like it was a huge pain to even get to where I could grind out any work. Had to build an entire infrastructure first, which was really difficult and I had to hire help to do so.

In unreal I just pay a guy a few hours a week to walk me through a few problems here and there, but I'm able to do almost everything myself. Now, if I got very particular about my needs and they were very different from the general Unreal workflow, maybe I start hitting problems. But thats something really only an experienced developer should be doing I think.
But for me, a beginner, I am more happy to stay within the confines set by an engine so long as it means I can get a game made faster and cheaper and have more fun along the way.

 

Like it makes sense that people who were making games before it was cool would see premade game engines and think its the easiest thing in the world.

But for noobies coming in, and coming into a competitive, oversaturated market filled with games that are more complicated than ever, the only way to jump in and have a chance is to take every advantage you can. And I think a bare bones engine is the one that offers least advantage to the noob.

I guess back when it was UE3 it was really obtuse and complicated? Maybe that is where the general wisdom came from. But if that is the case, Epic did a lot to make the engine more approachable and user friendly since then. I think so anyway. I just find it really easy to work in UE4 compared to Unity. Nevermind the rendering and advanced toolsets. That's not my concern. I just have a certain type of game I want to make, and if there was something as easy as RPG maker to get it done, that's what I would use. But so far, UE4 is the closest thing to RPG maker for the sort of 3d games I want to make.

Again, not downing on Unity so nobody needs to take personal, I just think the general narrative is flip flopped. Unity is the engine for expereienced developers, Unreal is the one easier for noobs.

And I think visual scripting will become the de facto method for writing games eventually.

 

Its most likely still too immature. Conversion is the last big workflow change that was introduced since those demos, where gameobjects get converted to entity data in a one way trip. Several years in and you still cant edit entity data via the inspector though at runtime.
Its best understood by taking a look at the samples repo(note its actually several projects, one plain ecs, one featuring physics, and then rendering). Play around with it, then if you have more questions the dots forum or discord can help.I'd say its pretty indicative of the current state of things. There is also an animation samples repo.

DOTS encompasses ECS. ECS is basically the architecture upon which you structure your game. It lends itself to be more data driven, see a real write up here https://docs.unity3d.com/Packages/com.unity.entities@0.17/manual/index.html and https://learn.unity.com/course/dots-best-practices.
ECS(the entities package) is designed to work hand in hand with Jobs(allows you to multithread work), Burst Compiler(vectorize your code), and a lesser degree Collections(a series of unmanaged types which can be used easily inside of jobs, and with burst).

You can use Jobs, Burst and Collections without ecs though, and I'd consider them mature enough to do so.

 

Actually, it's quite opposite. 99% of game elements aren't unique in any way. We continue to remix everything that happened before. That's true for all the art and entertainment.

It's extremely reasonable to expect that someone has already made most of the tools needed to create a video game.
Let's put our creators' egos aside, we are reinventing the wheel so often. We are wasting time we could focus on the very specific needs of a given game. It's reasonable to cut this wasted time to the minimum.

Most of the systems we use can be generalized. And this direction of all popular game engines. Although Unity takes its time

• The foliage system might be the same for most 3D games, if not all of them. Only assets are different.
• Every 3D games need tools for profiling and optimization of the renderer. It doesn't matter if someone modifies the renderer, every game would use a visualizer: showing quad overdraw, lightning complexity. Amount of draw calls. Unity lacks so basic rendering debuggers, that I'm always puzzled how rendering engineers validate their code changes?
  
• Every non-trivial 3D game needs scalability settings out of the box. It should take one morning to set up the UI panel to change all basic and advanced rendering settings. Otherwise, how 3D games can perform properly on a wide range of hardware?
• The list can go on... Unity doesn't provide common tools for 3D games. Although they do provide a lot for 2D games, I guess?
  
• You know, new renders shouldn't be available without all debuggers and workflow upgrades. Actually, they intended to complicate work by introducing 2 not compatible renderers in the single-engine.

Almost no studio in the world has a NEED to create its own particle systems, like VFX Graph or Niagara. The studio behind Gears 5 was probably the only one that built its own particle system in UE4, before Niagara times. Now they make a switch to UE5 and probably removing their own system.

The same goes for heavy animation systems - it's a huge effort even for AAA studios to build their own Sequencer/Timeline or things like Control Rig. That's why so many big studios actually switch to UE4.
Yeah, some of them could build own their tools. But they don't want to.
Even if they want, it requires a team of experts experienced in the given field to build a competitive system with an easy-to-use editor, good performance and it actually can handle ever-changing ideas/needs of designers and artists.

Most non-programmers hate their in-house engines because it's often painful to use. It's often impossible to build competitive tools during the lifespan of a single project. AAA studios spend a decade on that. That's not a viable tactic for smaller studios with the financial support only for the next project. So we need to "outsource" most of our tools

Only small portions of video game design/code/art are truly unique.

 

Returnal made their own particle/VFX system, for a while I thought they used niagara.

 

Totally, I don't want to make my own fire, smoke, water, or tree, etc. I think though my point was more around Unity isn't putting out any intuitive sophisticated designing tools and then making them work together in a perfomant fashion, instead relying on asset store developers to make systems. The issue though is that the assets work great as a "ship in the bottle", but once you start combining assets, it's not performant or very, very complex. As an example, the workflow to put a AAA style character into Unity with full body mocap including speech is really complex using a variety of 3rd party tools. The workflow for generating a performant dense AAA quality forest/city/desert is also complex with other tools & assets. I'm not against gamedevs using assets at all, most gamedevs don't really want to spend days or weeks in blender to make a barrel, so using assets is great for that. The issue though is more or less for tool systems where Unity isn't making any and just relying on the community to make these design systems, which, aren't performant.

To me, I feel Unity seems to be stuck in its vision (especially for HDRP) where it's at this odd crossroads when it comes to workflow for game design artists. It's falling down in character design, worldbuilding biomes, sound management, real-time global illumination, animation workflow for motion capture, and performant physics. These are the areas where Unreal has taken a closer look at what indie gamers are building and more importantly *how* they're building them. Unity hasn't done that yet and it's painfully obvious because they aren't making tools but rather just relying on the asset store to hopefully fulfil the needs of the artists.

Hopefully someone over there was paying attention to the UE5 demo and was like "uh... whoa" and can actually improve Unity for the better, but I think they're actually going to just hover where they are, focus on lowpoly 2/3D games, and keep HDRP chuggin' along with updates.

 

Not quite. It is easy to get started with, but if the size grows it is harder to deal with and requires more discipline than programming in C++.

And speaking of unreal, my experience was opposite. As in, a thing that was easy to do in unity would require a deep code dive to make it work.

For example, the big stuff:
1. In Unity you can use any animation of any character on any other character. They're interchangeable, due to Mecanim, so it saves time. In Unreal, the animation is part of the character.
2. Modular characters. You can just toggle things in unity and hide them. That's not the most efficient way to do it, but it works. In unreal, you have THIS instead: https://docs.unrealengine.com/4.26/...alMeshAnimation/WorkingwithModularCharacters/
3. Root motion. I think they might've fixed it at some point, but boy, was it a pain in the arse trying to reconcile a root motion character with builtin pathfinding.
4. Prefabs. Not sure about its current state, but the thing is, you can and always could build a level from prefabs by freely grouping meshes, then bake the lightmaps. In unreal at some point trying to group objects into prefab would create a blueprint, but said blueprint would create its child objects on spawn, would not correctly preview in blueprint editor, and the result would be exclued from lightmass baking process.
5. Lack of objects acting as folders was a lot of fun the first time around.

I believe noobies do not have any chance to begin with, because if they don't screw up in programming or art, they'll screw up in project planning and business decisions.

And the #1 priority of the noobie would be to stop being a noobie and learn some things.

It is unwise to cater engine to people that know nothing. You can offer them a better learning curve, but that's the extent of it. That's why I brought up willingness to learn, by the way.

 

UE4 does support this though, and it has for a very long time. It's even a more robust system than mecanim thanks to its rig system. It's one of the few things I miss when I'm not using UE.

https://docs.unrealengine.com/4.26/.../SkeletalMeshAnimation/AnimHowTo/Retargeting/

 

I've never been able to get anything worthwhile going with mechanim humanoid. Our go-to has always been generic due to game-like flexibility. Retargeting isn't so much of a problem for us, we tend to just try to get re-use out of the same model more than anything else.

If I really had to code retargeting - copying quaternions from one set of transforms to another with inverse offset - I would love it if Unity has a really optimised way of doing this. I'm sure it has somewhere. This would extend the life of generic quite a bit, so I'll investigate that. But, point being - humanoid is a bit of a gimmick that absolutely requires blendshapes to function else you end up with no real head rig / swapping heads becomes necessary etc.

I doubt many games or even pixar like films can cope using humanoid rig. It's a generic rig world out there.

 

I'm aware of that system, however, that's not a mecanim replacement, it doesn't work as well as mecanim, and retargeting has to be done in advance, and can't be done at runtime. (In practice results I had were that "sheath sword" animation turned into "slit your own throat" animation).

Meanwhile mecanim allows you to slap any controller onto anything and use any animation source.

See, the thing is the argument previously brought up spoke about "noobies, which are obviously not Pixar. And a "noobie" will not be making a proper generic rig by themselves because they can't.

Mecanim humanoid allows you a quick and dirty way to test something without worrying who is using which skeleton, and it just works. Not perfectly, but it does its job, and once you leveled up you can swap it with a generic rig, if you really want ot. Actually, I believe UMA depends on it, as it allows adjustments of character limb length. Which is something I pretty much never seen in an unreal game.

 

That has been my experience as well. Humanoid rigs have caused more issues than they've solved and retargeting is really of limited use.

 

@neginfinity ,

sounds like you didn't really make an earnest effort with unreal. That's fine, no reason you got to, but as already noted you missed some key features. And of coruse, when you are used to things being one way, everything will seem weird at first when you switch engines.

About catering engine to noobs, that's how you win. When you make your tech so easy a braindead moron can use it, you win. Big time. That's empowerment, and it brings in money. There is no benefit I can think of to not constantly striving to make your software easier to use, and making it easier to learn. (isn't this how unity got big in the first place? allowed more people access to engine when others had big paywall? empowerment)

If unreal makes it easier for me to finish games and earn money, then they earn. Nobody wins if it takes me longer because I have to become an expert over the next ten years before I'm ready to make something people will buy.

Also, keep in mind, i keep hitting on the point that this is my persepctive as a relative beginner. I have been doing 3d art for a few years and done general art for one published game, but when it comes to pretty much everything non-art related, I know almost nothing. So my forray into both engines is a relative clean slate.

You guys who have been coding for a long time are more likely to have habits and routines you are accustomed too. My message is only for other beginners.

And about the project growing - well that is exactly what a beginner should not be doing, so if visual scripting is becoming non-maintainable that's users own darn fault.

 

That's kinda rude things to say. I wrote plugins for the engine, and as I already said, I'm aware of features and ran into major problems with them. Yes, there are people who know more.

Catering for noobs is wrong. Empowering noobs is right, but for that the noobs must be willing to learn and that's why I listed that as a requirement. If you just "cater" to them, you'll be fleecing them (out of their time and or money). The one thing the engine developer would want is to grow noobs into professionals that brings in the cash.

There are also tradeoffs. Power tools have learning curve, and something without the curve typically lacks power. You aren't using RPGMaker or GameMaker, right? And that's because it lacks power.

What happened to empowring noobs here? The solution should scale all the way up, and not trap people when they aim too high.

 

Being able to retarget animations is covered in about 5,000 "how to get started with animation in unreal" videos, and it's right in the docs with step by step guides.

The rest of this is just argument for argument sake. You are misrepresenting things I said rather than trying to understand them. If you think I'm wrong, just make your case, but the things you pointed to don't hold up very well, and also don't have much to do with my general point that unreal makes learning the practice of making games easier (IMO).

I am sure it was different 5, 10, 15 years or more ago when many people here got started. But for me, coming in right now, it looks pretty different.

 

I really like this quote, because it illustrates one of the biggest problems I have with the tutorial communities that have sprung up around Unity. In general, they train perpetual novices, because the tutorial makers themselves don't know how to progress past the prototype phase. This isn't always the case, mind you, but it is definitely the norm. I feel like the content I've seen on learn.unity.com isn't that much better (often from the same tutorial makers who are themselves barely more advanced than novices.) Granted, I could be missing a plethora of great learning content since I didn't scour it.

 

I would also add that they are teaching bad practices propagated straight from unity3d documentation.

 

You're missing the point entirely.

All those articles are going to use subsystem that does not work the way Mechanim does. It's a different approach, different methodology based on the idea that an animation is an inherent part of a character.

And if you want Mechanim and runtime-swappable animations? You'll have to write it. Didn't you say something about wanting to do work and not code your own solution? Well, here you go. This is Unreal's area where it lacks out of the box features.

Yeah, it is not perfect in unity, but it is ABSENT in Unreal, and the current mechanism doesn't do the same thing.

 

Is that something that average indie developer is going to need to do?

And so what? Did I say unreal has everything and unity has nothing? I feel like you are just pointlessly defending unity against attacks not being made.

I don't even know what the practical benefit of that technique is. Sounds like advanced case usage to me. My perspective is which engine is helping me get work done as a beginner. I don't care if unreal will make certain advanced techniques more difficult. I won't be doing them anytime soon. My next three planned games involve little or no animation. I think I've made it clear I am not attempting to do anything advanced here, that's not my interest.

 

Not sure how he's defending unity?
he claimed a feature in unity is absent in unreal, you claimed that it isn't, he clarified that it is in fact absent. Now that you understand it, it's so what and you go on about how advanced it is or if it's useful at all?

No, you said it's in unreal -- turns out it isn't. I don't believe anyone talked about how important or unimportant it is. Even if he did, I don't follow your reply as he was just pointing out it's not there.

No matter how you see it, you are the one seriously defending unreal against imaginary attacks.

 

There will be no poking of ribs or indignant pointing, thank you everyone.

 

Yes, absolutely. Because it saves a truckload of animation time.

Where did "catering for the noobs" go?

At this point I could say "sounds like you didn't really make an earnest effort with unity " like you did earlier.

Mecanim is incredibly beginner-oriented, and it is something you'd want to use without an animation team, as this is what makes all the animation packs play nicely together. It is also not something you can easily write yourself, and it takes care of grunting work. Etc, etc.

It is one of the nice features unity offers.

 

Regarding mecanim, I got the most productivity from it just setting up standalone states and blend trees, then just calling crossfade in code. This saves so much spaghetti.

So really for a good time you just use it to set up the animation loops for things and crossfade between them in code.

 

Just curious, what would be a use case for this?

 

It's the same with Unreal tutorials. It can be quite bad if a given person (a junior) blindly follows Youtube tutorials, just accepting solutions that aren't too good technically... Tutorials authors tend to share their knowledge just after they learned basic stuff, no actual best practices, programming practices, etc.

It's also time-consuming to create a proper video tutorial so most people just prefer to show how "quickly click into things to make something work". And it doesn't matter if the presented solution is actually good enough to use in a real project.

So the junior comes to your team and you need to un-learn him/her bad practices.

 

Performance Optimization for Environments | Inside Unreal - YouTube

This is the sort of content that unreal has a lot of and I appreciate it.

Good tips in there, and importantly it's not just a list of "possibilities", but actual work flow strategies from people who've been busy making selling games. There isn't a ton of good content like this out there, but unreal does put a lot of it out. REally useful, I think, even if not using unreal engine. Just good best practices in general for game dev.

 

Have you played, say... Way of Samurai (4)? That game had martial forms and motions you'd collect, and upon completing the game bunch of times it would let you swap character's skin. Except the skin could have a different physique. Then you could make your own sword and your own sword style, combining every move you collected into your own moveset using point buy. There was a huge number of special moves. Then you could also make your own clothes, customize characters with attachments, and build your own sword from parts. By I digress.

Mecanim animation model unbinds animation from characters, and anyone can perform any action. And that is, generally a good thing. In comparison, unreal model suggests that any action you do should be prepared in advance and made compatible with existing skeleton, even if you retargeting it the moveset must be prepared in advance. That is a good thing if you're making cinematics or have a specific character prepared in advance, but it is not so good thing if you want to make customizable humans, and in general it means more work if you try to change something.

Another good example would be fighting games, especially where you can customize player character (Soul calibur, anyone?).