What are the genuine limitations of Unity?

For us it always has been asset management. If your project has a lot of assets, need to load/unload/stream a lot of assets and huge scenes, you have 2 options: buy source license and hire a few programmers to customize unity for your needs, or use another engine. Although if you have so much money to create enough assets to cause problems, then you have enough money to buy the source license.

 

Rendering some part of the content to a texture to apply a simple shader effect on it that displays uniformly is really hard in Unity, especially for UI when employing URP camera stacking and post processing. Say you have cards Slay the Spire style made out of UGUI and TextMeshPro objects - good luck with dissolving all the content on the card in way that's consistent and can scale to handle any amount of cards where the effect displays asynchronously. Same applies to 2D Animation package skeleton objects.

Maybe I just need to learn more about graphics programming, as in more than 0 but it seems cameraless rendering to texture is not really a well supported workflow within Unity.

 

This is, of course, wrong.

Gigaya didn't need third party assets. Those same things could be developed by the Gigaya team. However, it would be a waste of resources to do so when third party solutions exist and are tested. This is not a limitation, but a strength. You'll find third party tools are used in all sorts of engines, even for simple projects. Unreal, Unity, Lumberyard, Cryengine, Gamebryo back when it was a thing, Ogre3D, these all had extensive amount of third party tools and extensions.

You've been trying to push this whole narrative about Gigaya for a while now despite having been proven wrong in at least two threads now and whenever somebody points out how you're wrong about it, you pick the goalposts up and start running.

 

Still, "Gigaya" wasn't rocket science, and I would find it alarming that they had to use a third-party solutions.
The question Is what was used.

 

"Not rocket science" is true, but so is "don't reinvent the wheel." From what I recall, one of the things they were using, for instance, was a character controller asset. Character controllers are something that, sure, you can build them from the ground up, but there's also a wide variety of them on the asset store that are specifically tailored for certain genres or for being generally robust. It wouldn't make sense to make one of those from the ground up in that case.

As for actual limitations of Unity: the adherence to the component system means that a lot of the classes for systems like the character controller (which is also generally a black box), cameras, line renderers, all these things can't actually be inherited from. This really runs afoul of Unity's strength of being incredibly extensible because it makes extending some systems a real pain in the ass. This is dramatically improved in more recent things, especially packages like the SRP stuff, but it also means that there's a lot of conflict there.

Especially with another limitation Unity has: releasing things before they're actually finished and presenting them as "production ready" when they don't even have feature parity with the things they're replacing. Like it or not, the development issues that Unity as an engine has impose some real harsh limitations with how you approach solving a problem.

 

Why?

Like if you wanted to change behavior of the default camera, but you don't have source and cant inherit from it, the only way you can do anything with it is to make a separate component? And that is just a PITA because it makes for extra separation where there doesn't really need to be?

 

It's not just about changing the behaviour of the default camera, but having access to parts of how the cameras work without having to jump through things like the command buffer system in BiRP or having to deal with the absolute nightmare that is getting into the systems of URP and HDRP beyond just their basic render functionality. There's a lot of reasons you might want to inherit and override the functionality of things like character controllers and line renderers.

 

It was custom built almost entirely by @Andy-Touch.

https://forum.unity.com/threads/gigaya.1257270/#post-7990074

 

Character controllers in Unity ECS are not black boxes. You need to differentiate MonoBehaviour from ECC since they are basically totally different engines. After using ECS for a few years I realized how limited Unity really is. Unity confines your options and thinking way more than people realize. Which is fine when you are learning.

At this point, I consider the MonoBehaviour part of Unity basically to be a toy engine. I remember years ago telling the developer of Unity's High-Level networking API that it was super unoptimized and not useable in a real game. His response at the time was that Unity wanted to make a system that children can use to network their games.

Unity needs to keep developing ECS that is the only hope Unity has of having a decent engine at this point.

 

I literally didn't say a single thing about ECS. I am not talking about ECS. I even made sure to say this was about the base functionality stuff.

 

IIRC, the only third party asset that Gigaya was using was a Volumetric Fog for URP; and we had a deal in place with the asset creator to integrate it as part of the project (I dont know specifics of the deal)

The CC was custom and using PhysX Rigidbody as it's core. We abandoned the built-in CC first week of development.

I think we might have been using DOTween aswell but my memory is fuzzy and its been a year since I looked at the codebase.

 

Given how I end up abandoning it about a week into prototyping this isn't terribly surprising.

 

I am certainly getting more than 3 hours out of my 8y old MBP when using Unity. Maybe 6-7 on my 15inch and 7-8 on my 13inch (for whatever reason even with new battery in 15 inch). When I only code, I may get about 10-12 hours out of those MBPs, but that's quite lightweight. Other software gets me about the battery life as using Unity. Only pre rendering (raytracing) in 3D software as well as Unreal eat battery away like crazy. At least on my machines.

 

Well, at least better than Unreal? At least a few years ago (don't know about current situation), I read an article about how Unreal's iOS performance is much worse than Unity's. Combined with my impression I got when running Unreal on my MBPs, I figured that may be about right and kept using Unity for apps ever since.

 

For 2D stuff. For higher end 3d (but still mobile) stuff I think Unreal still wins or at least it's comparable.

But also I think Unreal cares as much about mobile as Unity cares about the responsiveness of their editor, so I don't think Unity winning there is a big win, or if it qualifies as them being good?

Or maybe I'm just bitter, because I upgraded to 2021 for the latest release and to stop the game from crashing I've had to disable a whole bunch of Unity features because Unity features naturally decay with time it seems. Multithreaded rendering crashing on iOS was a new one for me.

 

It was about 3D, dropping the same assets (bunch of trees with a lot of alpha on their textures) into both engines and comparing FPS. I think Unity got about 2-3 times the FPS, but I can't find the source, unfortunately.
I do agree with the latter, though.

 

I'm talking about way more than 50% play testing, and the rest of the time doing editing of particle systems whilst they're playing or editing Animations, crafting timelines through their playback, adjusting post processing settings, testing camera moves, moving around through the full scene to edit positions and preview materials and lighting etc, adjusting animated materials, testing out audio configurations and mixers etc. Whilst doing these, the Intel Mac is HOT, the m2 Max is cold, but they're both burning through battery at a huge rate.

Coding is a whole different thing, and I don't consider this to be "using" Unity. I work in JetBrains Rider, which has come on in leaps and bounds on the Apple Silicon. Almost worth the upgrade in its own right, as its transformed it into feeling like a lightweight and rapid code editor, not a big, heavy IDE. I probably get about 12 to 15 hours (or more) out of Rider on the m2 Max. And about 5 or so on the Intel.

 

Don't know about Rider, but my 8y old machines still get me battery life that's in the same ballpark when using Sublime. I didn't mean using a code editor as using Unity. In fact, just to compare it with Unity.
Of course, Unity also includes features that are very taxing. Depends on how you use it. I rarely need to run graphics a lot. I see how it shows, I change it, done. Most of the work I'm doing is tweaking assets in edit mode, structuring hierarchy, importing assets.
The real question is: Have you tried Unreal and it, in fact, did perform better than Unity for the way you work? Other than that, you can't really compare, for example, tweaking a post fx stack for an hour with simple hierarchy tweaking or low cost editor automation.

 

Graphics heavy workloads in Unreal 5.2 about the same as Unity on m2 Max battery life - not good. Haven't tested with intel Mac, and probably won't. I feel like Unreal's Editor UI is more optimised than Unity. These two shouldn't be close, as they are, but even more worrying - I'm experimenting with a far more complex scene with a lot more lights and stuff going on in Unreal. Unity should be winning the battery battle by a mile, but it's not.

yes, I have all the optimisations to slow the rendering of the Scene and Game view activated in Unity.

2023.2 Unity feels absolutely horrible to work with due to UI issues, as well as that unoptimised nature of the UI.

Polygon editing in Maya is very lightweight on battery. Blender is less so, which was surprising, but Blender has a much busier UI that I think is doing much of that hit. I tend to think the updates to Unity's UI are needlessly excessive source of energy tax on CPU, storage due to the way that all works on the m2 when doing graphics and animation stuff, in Play Mode, etc.

Back to the OP's question... I'm beginning to think it's a concern to use Unity to target VisionPro, as at this rate it doesn't feel like a version of Unity will be ready to be serious about Apple Silicon (m2 plain in VisionPro), get stable and performant and document what can and can't be done with the hybridisation between URP/Builtin and the ARKit/RealityKit Materials they've chosen to use rather than metallising their own materials. There's only one other option - to directly use SceneKit/ARKit/RealityKit from Apple...

Unity should be nailing this, and focusing on it, and they should be doing the same for all of VR and Android and iOS gaming where they're a preferable choice for legacy reasons, but they seem to be still focused on DOTS for and HDRP in a battle for higher end legitimacy, a space where Unreal is the default choice for very good reasons.

Xcode, when using SceneKit or ARKit or RealityKit in Xcode for the same sort of works as I'm using Unity, it's much less taxing on battery life, with the exception of particles, which are oddly extremely unoptimised and about the only thing that creates any sense of heat out of the m2.

 

Maybe they are quite similar in performance, but i haven't seen or done any apples to apples comparison myself. Unreal mobile rendering lacks a some graphical features like SSAO, Reflections, realtime reflections etc. I have tested some graphically intensive 3d games made with unity like boat attack, Principles prologue, Wilderless and book of the dead mobile performing quite greatly on mid-high end phones, haven't yet seen that level of quality with unreal on mobile. Unity also has DOTS. According to my testing and knowledge unity still has edge over performance and graphics on mobile platform.