I like how freak out the unity community is and how nonpluss the godot community is.
Actually, Unity’s community reminds me of Lightwave’s just before it lost what marketshare it had left.
A few days ago I found that I couldn’t use properties in a Monobehavior script and have them show up in Unity’s editor. Not exactly the same but still annoying.
Ya I meant fields…still stuck on thinking in terms of unreal terminology. I did notice unity added generic field serialization so maybe we get properties next
Before we try to argue between UE5 and some future version of Unity with all of the DOTS fully implemented, let’s talk about real blocking issues that real people face today. For example, let’s talk about the 4GB (32bit) file size limit that has interfered with our ability to build large scenes in Unity.
Here are threads about the 4GB scene resources limit in Unity.
I originally posted about this bug in November 2016 when I ran into this problem using Unity 5.5. That bug remained in Unity until December 2019 when it was finally fixed in Unity 2020.1.0a19. The fix was never back ported into Unity 5.x, 2017.x, 2018.x, or 2019.x. The only way to get the fix is through the 2020.1 branch, which is still in beta. To this day, none of the production ready versions of Unity include the fix, so none of the production ready versions of Unity support scenes with more than 4GB worth of assets. Let that sink in for a minute.
In my case, I worked around the problem by splitting my scene into multiple scenes and then using the additive loading option to load all of the assets at runtime. That solution won’t work for every project, though. Some people used asset bundles to work around the problem. Either way, the bug causes a lot of game developers to waste days or weeks refactoring their projects late in the development cycle to work around a major blocking issue. This is literally a 32bit file size limit in the builds, including 64bit Windows builds. The limit was not well documented, and it did not show up in the editor. It was simply a left over 32bit limit that developers would run into in builds when they were testing and releasing their games.
Major blocking issues like this prevent Unity from really going after the 3D photorealistic gaming market. After all, a 4GB limit is pretty tiny when developers are pushing for photorealism. And as I mentioned above, none of the production ready versions of Unity include the fix for this blocking issue. The fix is currently only available through a beta version of Unity 2020.
wow, that is good to know. Is there like a bulletin board somewhere to get a quick glance at what major show stopping bugs like this are known to exist?
Lightwave! My first actual 3D program, actually, back in the Amiga days. Learning that is what got me my first job in video games.
I’m working with unreal in C++, and what you’re saying is not true at all.
Intellisense frequently breaks, Visual studio frequently fails recognize unreal specific macros and methods (like Array.Num()) and keeps peppering you with false positives, and documentation is minimal when it comes to C++ API and often absent. Blueprints cannot be used for plugins, last time I checked, and have poor readability compared to code and do not scale. Regarding blueprints just working, there are fun situations like when you create custom blackboard class in C++, have an instance of it as a data asset, and then update C++ code, the instance will fail to load and you’ll lose data. Additionally blueprints use binary format and you can’t diff them.
Actually I asked you to find documentation for FSkeletalMeshLODModel few pages ago, along with the example of creating skinned mesh asset through C++ Code. If you thought I forgot about it then I didn’t. Still waiting.
Long story short, hate unity all you want, love unreal all yo uwant, but don’t spread misinformation, please. No tool is perfect anyway.
I don’t know of any specific list. I just try to make sure I tell others about the issue I ran into, so they can work around it easier. If you find a list, though, post it in this thread.
Other blockers I have seen:
DX12 - unstable graphics in every version of Unity I have tested
Vulkan - completely black screen on Android
various VR issues (like image effects in single pass vs multi pass modes)
various stacked camera issues
I’m sure my list is a tiny subset of the blocking issues that have been find across all projects throughout the community. Most people have simply used DX11 instead of DX12 to work around DX12 problems, but DX12 is required for some of the preview tech. Eventually, Unity needs to get DX12 as reliable as DX11 in both the editor and in builds.
maybe that is something that could be useful for community? a stickied thread that moderator has to approve post to, where we can report show stopping bugs and workarounds only. not small things but the kind of thing that would throw a wrench in projects and cost a person days - also bugs that aren’t already easily googable I got at least one that I could report
You know, I’m starting to realize that I haven’t once seen superjayman post on these forums where he wasn’t talking about how great UE4 is and how awful Unity is in comparison. The guy is a walking Engine War Thread.
Actually it reminds me of the time when I was investigating engine differences on unreal forums. Asked bunch of questions, got a lot of excited and positive responses, like “yeah you totally can do the same thing as mecanim does”. None of the responses turned out to be true few months later though.
This kind of false advertising only creates negative impression of the engine (and its community) in the long term and nothing more.
I wouldn’t call it false advertising. Unreal Engine 4 was built to make certain kinds of games, and the framework was designed a certain way to maximize that flow. Unreal does have an animation state machine, but you can only use them for humanoid skeletons, and not for general animation state machines.
You really won’t see the true benefits/downsides of using a game engine unless you try using it for a few months.
That’s why I think we shouldn’t be debating what game engine we should be using. We should instead look at what one game engine is doing, and use that to show the benefits of bringing similar fixes/changes to another game engine.
The new revenue policy for UE4/5 is a perfect example. Why are game developers still paying Unity $50 a month for a dark skin, when you get all UE4/5’s features and source code out of the box, and you don’t pay anything until you make $1 million off game sales? Competition is good for practically all game engines (in most cases).
Unity can’t compete with tencents and fortnite though, not with unity 1.5
Fantasizing then.
If I am told that there’s a feature, and there’s no such feature upon the investigation, what am I supposed to call that?
Also…
As far as I’m aware, unreal animation state machine is skeleton-agnostic. For some incomprehensible reason everybody tries to use Unreal skeleton, but you’re not required to do that and can create your own. Unlike mecanim, skeleton topology is not hardcoded into the engine.
However, what I was speaking of is on-the-fly skeletal animation retargeting provided by Mecanim. Unreal does not have such feature. You can convert animation and attempt retargeting (the process is very likely to fail), but you can’t create humanoid character with random limb length at runtime and have it animated by a humanoid controller. Which is totally possible with Unity.
I had no idea Unity allows you to do this, but not Unreal. I knew of a project called UMA, which took full advantage of creating humanoid characters at runtime, and I don’t see any alternative frameworks in Unreal. It’s definitely possible to do the same thing in Unreal, but you’ll likely have to write some custom engine code to make it work seemlessly.
This is sorta the point of mecanim. You can use ANY humanoid animation on ANY humanoid. For example, if you have a soldier, you could use his animation on a gorilla, and so on. UMA takes advantage of that, that’'s how it handles limb length. You can also use this to quickly setup combatants. For example, I had a script once that would grab ANY humanoid character, then process the model, setup colliders, attach ai sensor, and place a weapon into correct hand.
In Unreal philosophy is different. Animation is part of the character and not something you can freely swap. Transfer of animation is possible, but retargeting is a process that is done in the editor and not on the fly.
Of course, there’s overhead, and mecanim is slower than “Legacy” animation. This has been brought up by @AcidArrow several pages ago.
On the “in” parameter on method parameters, you can configure the IDE to give an error instead of a warning if needed, and you can also suppress that per-case basis, which i think is an advantage in this particular case, not otherwise.
And the reason being that, for example, if you had “bounds2” passed into a method via a parameter with the “in” modifier and used bounds.Intersect(bounds2)
on it, which is a very old unity api, and while it doesn’t change anything in the passed in parameter, it would give a warning(error) because the api doesn’t have the “in” modifier, so it could be suppressed if needed w/o disturbing the old api.
The IDE settings can be versioned and enforced across the team on that particular project, tools like resharper, which i personally don’t work w/o, aid this even further.
As a result, you can get the c++ behavior in general, and more when dealing with old apis.
This sounds very weird considering assets aren’t serialized directly into the scene file. How did you manage to get the scene file to 4gb in the first place? (your original explanation doesn’t make sense considering how unity serializes scenes)