Question Why Unity has no automatic memory management system?

I mean irc engines like Unreal automatically control which resources are needed at which time, by storing the last access time and unloading resources which has not been accessed for a while. For example if mesh has been rendered it's timestamp is updated, preventing it from being unloaded. And if mesh has been unloaded it's data is loaded back next time it is accessed again.
In Unity there's no such system, only two options are Resources.UnloadUnusedAssets() and using systems like Addressables, which are unreliable cause they require manual control of asset lifetime from a user.
Is there any reason for Unity not to have memory management solution?

 

Because unity is built on assumption that you know what you're doing and do not need babysitting.

Automatic unload can cause cycling of resources and slowdown. For example, if meshes that hasn't been seen for a while are automatically unloaded, then such engine will unload half the level you haven't yet seen and when you go to that part the game will freeze or stutter while loading resources back. It is not a desirable behavior.

Traditionally games loaded entire level at a start, and kept all resources in memory for performance.

 

This has reasons but not enough to justify lack of memory management for me. All problems you described have their solutions. As usual, automatic memory management operates within some memory budget, before it is overrun none of the resources are typically unloaded. If you need some asset to stay in memory no matter of what there is also usually option to keep it untouched. Stutters are usually combated by using asynchronous asses uploading pipeline. Textures are left at their lowest mip level and meshes are kept at lowest mip level, etc. Whole system is very flexible.

Actually Unity itself has a bit of such thing in a form of Mipmap streaming system. Though it only applies to a textures. Any other type of asset such as sound, mesh, animation, etc are not affected.

If considering Unity as oriented only towards a smaller games, where whole mass of assets on a level is enough to sit in memory at same time, Unity approach makes more sense. But this really limits the use of a high-quality stuff, limiting visual fidelity of a game cause of memory limitations.

 

The key word is "for you". Unity has no obligation to justify anything to you specifically or match your expectations.

The problem is that memory management of resources is unnecessary and is not a required feature which is highly likely to cause problems rather than help. Implementing your own thin veiled pool like that is also incredibly easy.

Then you'll have "ghosts". Placeholder representations in place until assets finish loading.

It doesn't limit a thing. With current toolset you could go to high fidelity visuals without an issue. Many people did that. Also asset unloading is separate from texture and level streaming.

 

Yeah, maybe. Problem is that i do not have access to Unity source code and thus have no option of implementing such system myself. Doing it from script-only is impossible, cause it would require tampering with Unity internal systems, not exposed to a C# part of an engine.

That's not really possible the way i want it. I realize now Unity is not meant for high loads i need for my game and it's my own mistake for choosing wrong engine for the job.

Thats quite common thing encountered even in high-budget AAA games. There's no better option available afaik.

It actually does. Keeping several gigabytes of asses in memory puts quite a strain on end user PC. Especially when only part of them are needed at a specific time.

 

To put it in a pragmatic way: Because open world games are more of an after thought for Unity at its core. Almost no built-in tool is really prepared for it. For example terrain which has no streaming capabilities.
Instead you are "supposed" to work with scenes which do handle this resource loading on unloading as a side effect. It allows to guarantee to your player that nothing within the scene will cause lag spikes from resource loading.

When you are advancing, pushing Unity towards open world etc. memory management is just part of what you have to take into account.
Not to say that some smart feature as you propose it wouldn't be nice to have.

 

You don't need it. Wrap underlying systems, use facades.

Your user shouldn't ever see a ghost. If the user does see a ghost, that means the game was not exactly well designed, and fails to fetch resources with sufficient speed. It is a flaw that needs to be addressed.

Several gigabytes on a modern system is a joke. If it was terabytes of assets, there would be a point.

However, if you consider this t o be a limitation, then it is a red flag indicating that you may be trying to go over your budget (like trying to build life-sized earth while working solo) or are getting sidetracked by an interesting programmer's problem which has nothing to do with your project.

 

There's not much to add here, cause this is thoughts i share with you. Unity is clearly not meant for an open world game. Problem is it is not written anywhere. Had to come to this conclusion only after experimenting enough

My belief is Unity could benefit from so many things improving the handling of assets, but this is never going to be done, cause in majority Unity is a small games, where all of Unity drawbacks are much less pronounced.

 

Maybe i am not understanding you, but i can not see how any of this would solve the memory issue?

It all depends on a project and a user PC configuration. No mater of what, seeing ghost is better than experiencing stutters.

I got myself in kinda odd situation, where i have to develop using already existing and quite large asset database. I cannot alter it or change gameplay to make it more in-line with the way Unity handles assets. The prototype was developed using Unity so i just continued with it.
This is not exactly related to a topic tho.

 

Wrap resources you want to unload, track lifetimes, nuke them when they expire, releasing memory.

They're equally bad. There should be neither ghosts nor stutters. Ghosts kick user out of the world, and also do not have proper visual feedback.

 

Aww... i see. I got some assets management system in a project, which attempt to track lifetimes of asset. Problem is that i can never know if say a mesh was rendered last frame or not (i can do it with SRP but it would require to tamper quite a lot with a renderer tho). It would never be as smooth and reliable as builtin solution anyway.

There are games and game engines which are basically built upon the idea of keeping minimal amount of assets in memory an constantly streaming in and out. The most glaring example i able to recall is the Rage game made by ID software. When run on low-end hardware it can be constantly seen streaming mips in when camera is rotated. But if not for such system it probably would not be able to run at lower end PCs at all.

 

Considering the many times I've been told "Unity is intended to be easy and for everyone" when complaining about something being limiting, either this argument is a load of bull, or Unity doesn't really have a clear direction and they just do whatever without a plan.

I also find it funny arguing against such a feature when Unity already stutters like an [old broken truck?] when something as simple as a new shader appears on screen, and all their pre-load shader systems do not work, but the potential of stuttering for an actual useful thing is reason enough to not want a new feature.

Also

So does garbage collection, but we consider C# to be a good thing for Unity.

@crowmaster Unity is only good if you want to release some ad infested crapware on mobile, or want to do tiny prototypes, for everything else it just sucks and I don't see things changing for many years (if ever).

 

AFAIK, Unreal doesn't work quite like that.

What Unreal does have that Unity doesn't in that area is that their garbage collector applies to everything, including assets. This means that if you destroy all instances of a mesh in the scene and there are no more references to that mesh anywhere in memory, the mesh will be unloaded automatically the next time the garbage collector runs.

Unity doesn't do that. At least not exactly. There are three ways to unload an asset in Unity:

1. Call Resources.UnloadUnusedAssets(). This will scan the memory to determine which assets are no longer referenced and unload them. This is an expensive call that can take hundreds of milliseconds to complete, so not suitable for unloading stuff seamlessly during gameplay. Unity does this automatically when you load a scene non-additively.
2. Calling Unload(false) on an asset bundle will unload all assets loaded from it, even if they are still being used.
3. Resources.Unload() will unload an asset that was loaded using the Resources API.

You can also Destroy() the asset, but you might not be able to easily reload it.

Now, why does Unity have these limitations? It's mostly due to the way Unity is architectured and the way C# works. Unity is ultimately a C++ engine and assets in it are C++ objects with C# wrappers.

It's easy to implement reference counting in C++ by using constructors and destructors, which are called deterministically. But finalizers in C# don't work like destructors in C++ and there are performance implications when using them. I'm not sure how feasible it would be for every C# asset wrapper class to have a finalizer.

Now, nothing of this has much to do with unloading assets that "haven't been rendered in a while". Unreal doesn't do that. I assume the OP is thinking about world streaming and such, where things get loaded and unloaded automatically based on the camera position, which is different, and is something that Unreal offers out of the box. Unity doesn't have any of that, you need to roll your own or use a 3rd party asset.

 

Ah, yes. SRP and its lack of OnPreCull and OnPreRender. That can indeed cause a problem, but maybe it would make sense to request better culling hooks rather than automatic unload? Custom hooks have many applications, and overall more useful than auto unloader, whose application is (in my opinion) somewhat niche.

See, there's a difference between "ghost" and "low level of detail". While Rage certainly could stream in absurdly low level of details, it has never produced a single ghost. At least I don't remember ever seeing one.

Ghost usually correspond to MMO-like behavior, where the new player loads in as either glowing ball of light, or some placeholder character, and t hen details stream in. You can actually see it in VRChat, which is made in unity, where newly loading players are displayed as a gray robot model which has nothing to do with their actual appearance.

"Mip quality drop" is annoying but it is more acceptable than failure to display anything, stutter or a placeholder ghost object.

Note that mip streaming does not technically ever unload anything. The texture object persists in memory, it is just engine can choose to allocate fewer resources to it. Which is a bit different from nuking objects completely.

 

Except there's multiple open world games made in Unity, including one of the more popular ones on the market right now. "You have to figure things out for yourself" means that, by its very nature, Unity is not meant for any one specific style of game and instead is meant for all sorts of games.

 

Unity is literally used for genshin impact, so @crowmaster you are talking absolute nonsense.

I recommend actually learning gamedev before making random assertions about it.

 

somebody has made 2d card games for phones with unreal, doesn't mean thats what unreal is purpose built for or that it is the most appropriate tool for the job.

And how does anybody here know what crowmaster does or does not know? They might have more gamedev experience than anybody else.

Definitely not absolute nonsense - I'd say its just the sort of advice people coming to unity with ideas about making open world games need to see so they can have a notion to test things out thoroughly before making commitments.

 

We can infer based off of their statements. Both in this thread and in past threads. Same way you would gauge anyone else really. Because no one goes around with a list of "here's what I've learned".

 

doesn't look dumb to me. just asking technical questions in an intelligent way.

 

Have you only skimmed this thread?

 

No i read it, and its the same old same old.

Person is clearly coming to face with some limitations of the engine that cannot be seen from the surface, they are trying to figure out with help from community if there is an engine shortcoming that they have to deal with, or maybe something they simply don't know, etc. Asked in a completely neutral way.

But Unreal was mentioned, so the fanboys (and why???) just denigrate the developer for not deving hard enough - just spend the next 15 years learning how to write engines yourself and then you can solve these problems, don't be a baby.

All the people who say this sort of thing I am pretty sure only use unity for business app type stuff, or mobile games, or apparently spend 90% of time just saying nonsense on forums. It's why productive people stay away from public forums, which is a shame because public forums are easiest access and it would be great if anybody could easily find discussion that's not just internet troll types making everything a weird ego battle - but instead diligent people trying to learn and share.

 

Didnt they buy source code from Unity and modify the engine, including data streaming? I guess such stuff is not available for a "regular" indie dev

I would expect some data streaming solution from Unity with DOTS...since its data to handle so data oriented tech stack should be easy to handle it

 

There are multiple assets for this in the asset store. There isnno inherent limitation in the engine, just that they do not provide it out of the box.
Source code access is useful for the last 10% to a AA game, but not really necessary, I'd say.

 

It's there: https://docs.unity3d.com/Packages/com.unity.entities@1.0/manual/streaming-overview.html

For non-DOTS there's SECTR: https://assetstore.unity.com/packages/tools/terrain/sectr-complete-2019-144433

or World Streamer 2: https://assetstore.unity.com/packages/tools/terrain/world-streamer-2-176482

 

Okay so going over your post history, you have a habit of trying to get Unity to do everything your way rather than actually learning how the engine works and adjusting your workflow accordingly. My guess is you either:

1. Have experience with another engine and want Unity to just do everything the same way as it
2. Have experience with working directly from libraries and want the Unity workflow to match that

You need to meet each engine on its terms, understand its functionality, and work from there. Otherwise you're just going to keep butting heads with the way the engine actually works.

 

You mean Genshin Impact? We don't know exactly how much effort devs had to put and how many challenges overcome to conclude if it was reasonable. Also considering how much money was involved into Genshin development, it is reasonable to assume devs had acces to Unity source code and been able to modify it and made changed they needed.

 

My background is from-scratch development using C++ as well as making modifications to already existing game engines. So when i using Unity i expect it to give me as much development freedom and adding convenient high-level options on top of it. My problem with Unity is it does many thing in very implicit way and not very good at it. This leads to developing ugly hacks and workarounds, to make thing behave the way i want. I feel like i spending extreme amount of time redoing the work which i expect to be here out of the box.
And you might say "adjusting your workflow accordingly" but some thing are simply not there. You either hack then in with rusty nails or learn to live without these needed features.

 

Instead of discussing the topic you choose to attack my personality instead for some reason. I never doing this myself and do not get others behaving this way. If you can add something considering the thematic of our discussing, then please.
Hope this thread wont be moderated into oblivion just because of this. I probably not going to reply to stuff like this anymore, to not cause a personal argument.

 

Oh, is it Tuesday again? Time for the weekly "why isn't Unity's core organized the way I like from other engines" thread.

I get your point, crowmaster, but get ours. Each engine makes certain assumptions that work well for their main userbase. It doesn't sound like you enjoy Unity's approach and you accept asset ghosting and other limitations that the other engines have so you don't need to manage your game's behavior yourself.

 

Tbh maybe you right and i am mistaken it being Unreal. I've been inspecting engine code several years ago and it had this system i've been talking about. I've been not working with recent versions of Unreal 4-5 so maybe i should change the OP post to not mention the Unreal as example.

 

I didn't attack you in the slightest. I said we can infer the range of capabilities of a person based off of the posts that they make and that was it. If you're coming away feeling attacked maybe the problem with this thread is not one of actual game development knowledge but instead one of spoken/written language.

 

Genshin Impact is one game and there are many others, some of which you can find in the WIP section of this forum, more of them you can find on Steam. You are making a lot of assumptions here because...

...of this.

You need to adjust your workflow. The things that aren't there don't require "hacking in with rusty nails or living without them." For instance, I went back through some of your earlier threads and you just assume there are things missing from Unity that are explicitly there but you assume they aren't. For instance:

Flipbooks do not prevent using other UV modifiers. These are things you can add at the shader level. The ideas you had for 2 and 3 are what you assume to be the hacks, but in fact are the worst possible way you could do things. I've made animated textures that work with flow maps pretty trivially using absolutely bog standard shader code.

Here's another. What you want is Clip(). It's just Clip(). Here it is in action. The clip is discarding based on a noise texture but there's also an actual alpha value, which is why you can see the sprite behind it. You can easily modify the standard shader to do this.



You need to learn how to use the engine and its workflow. There are definitely problems with the engine, but they aren't the ones you're saying.

 

It actually does. Flipbook just modifies texture coordinates so they point at specific sub frame of a whole texture. Now imagine you need to also pan this texture. If you do this, panned texture wont align with subframe and instead will be shifted grabbing texels of another sub frames, creating undesired effect.

I've implemented this in my own custom shader, this does not actually cancel the fact that Unity builting Standard shader does not support alpha + cutout mode.

 

I just wish Unity gave me a bit more control of its low-level stuff. I am not even asking for it to be implemented out of the box. I just asking to give me access to as much API as possible, so i can tamper with the engine the way i want.

 

There are entire math functions that are perfectly suited for this. This is basically the domain of things like Frac(). Again, these are things I have implemented in multiple different contexts. You are inventing problems.

 

I've thought of a way this could be implemented - by manually wrapping UV coordinates inside the flipbook frame using some math. It just felt too complicated for at at the moment to investigate further. Maybe this is the method you trying to teach me? If you got a real working shader using flipbook uv mapping + other uv effect i'd be very grateful if you share me a link.

 

You just apply the UV effects based on the index of the flipbook.

 

I've been thinking of what you said for quite a while but in the end i still have no idea. I need a link on some guide or vid preferably. Tried searching for it myself to no avail, sorry.
(to be more precise i am not talking about tiled textures rn, i am talking about flipbook uv + uv panning effect)

 

Well, that's my original background as well, but you'll need to throw all this knowledge away. It is not incredibly useful, It'll get in your way, you need to get used to component architecture. Then things wil click.

Treat unity like you would treat Qt framework.

That's because you're approaching it from a wrong angle. You can complete a game in hours with unity that would take 6 or 7 months from scratch. If you currently cannot do that, you need to adjust your workflow.

Unity material has uv offset uv scale parameters. You can alter that at runtime.

You can also write a shader, with parameters you can alter at runtime, which applies flipbook effect.

That will reduce your flipbook to something like 10 lines of code where you'll be setting a material parameter. Then you can make it a component using material property block.

Oh, SURE, you could actually regenerate the mesh each frame, but why would you want to do that? It takes more effort.

You don't NEED low-level stuff. It is a waste of time and it will get in your way. But if you insist, there's native plugin api, low level graphic functions within GL, you can generate your own meshes and so on. You can also implement your own font renderer based on glyph data. Except you never NEED to do it.

 

Idk, i feel like i need to investigate the flipbook issue some more. I got some idea of how it might work using Frac function, but i need to try and test it first.

I am not inventing problems. I got an issue i've been trying to deal with, i've been trying to google the solution, i've been asking for it on a forum - got zero answers. Where i got first info on it? In a topic completely unrelated to original problem.

 

You are.

With C++ background, it takes about 2 months of using the engine, before the component system clicks and you realize that all the C++ knowledge you have is not exactly helpful. That solutions are solved using small tiny scripts with minimum amount of logic. That you don't need all the advanced stuff you can do. And before googling, you need to learn basics of the engine which means reading unity manual, and scanning through script reference. Certain things do not even need programming.

For flipbook, basically you can control material. You can write shaders. You can also make shaders which will play flipbook without scripting.

You can also use unity sprites and implement manual frame switching. You can generate sprites automatically from a texture using asset preprocessors, if you want to. If you want to generate mesh yourself, you ALSO can do that, though the shader will be faster.

Once you get rid of desire of "doing things YOUR way", you can get things done. Also, unity allows fairly low level access to APIs, unlike Unreal Engine, for example. If you desire a real hardcore experience, however, then the go to framework would be naked libsdl. Your development speed, however will drop by a huge amount.

Speaking of which, for issues remember that ChatGPT is available, and while it is relentlessly being dumbed down by OpenAI, this thing can help with general queries related to unity.

 

Let's assume Shader Graph, but the concept works the same for shader code.

If the flipbook is 4x4 frames/cells, then the Flipbook node will essentially take the UV that you give it and scale it down to 25% and offset it to select the right portion of the image. There's nothing that says you have to give it the original UV coordinates. If you modify the UV coordinates from the model and give it UV coordinates which are wrapped according to Fraction node and an offset, what do you think will happen?

Input UV -> Add your scrolling offset e.g. (0.33,0.67) -> Fraction -> Flipbook UV

 

Few more arguments why flipbooks are less convenient than true animated textures
1) Sub frame layout is a property of a texture, but it is actually used as a property of a material using this texture. I cannot simply plug flipbook in, i need to also provide shader with correct number of sub frames. This means every time i want to change my flipbook texture, i also need to update all the materials using this texture
2) Requires explicit shader support. I cannot just plug in my flipbook texture into a standard Unity shader for example.
3) Puts extra stain on a GPU. Computing flipbook uv coordinates is a relatively expensive
4) Cannot be used in places like UI cause UI uses its own shader without flipbooks support.
5) Maximum size of sub frame is at least 2 times less than maximum supported texture size

Easiest way for me would be just simply adding animated textures support inside the very Unity core. But it is obviously impossible. Thus i am forces into less flexible, performant and convenient way of using flipbooks.

 

You think i do not know Unity well for some reason, even though i actually diven deep as much as this engine allows me to.

All i want is to plug animated texture into a shader without much headache. This is pretty helpful for creating animated fires, for example. Yes this can be done with particles, but this is has different looks and also less performant solution.

I dont want to do thing my way, i want to do things the most easy and straightforward way i am allowed. The less steps and processing method requires, the better.

Unreal has full source code provided and it is even allowed to make changes to it for your own project IRC. How Unity could be more low level than that?

I'd like to think i know a bit more about Unity than a ChatGPT does...

 

That's premature optimization. You think it "puts extra strain" without actually measuring it. You're also getting sidetracked. You could've solved this already, instead of that you're looking for ideal solution.

It is based on questions you ask and things you say.

Animate UVs. It is a couple of lines of code. Extremely trivial to do.

Those are synonymous. There's workflow you want, the workflow is your way. You think your workflow is straightforward, but that's not the case.

Unreal source is a behemoth. Modifying source code requires a very skilled C++ programmer. Code dives are not easy, and source code is not friendly. I know because I've dealt with this before.

Despite not providing source code access, unity allows you to do low-level shader hacking, all the way down to direct API calls, though this means using native plugin API. In case of Unreal you're not even exactly allowed to write your own hlsl, draw calls through through several layers of wrappers While in unity you can directly draw triangle, without making an object. For example, couple of years ago, for the heck of it, I wrote a unity shader that was rendering raytraced CSG primitives based on distant fields in unity view, and they were integrated with native lighting and shadows system. In unity, this is simple. In Unreal, I wouldn't even bother.

That demonstrates the difference in philosophy. In Unreal you are not supposed to touch anything. You can, but it was not made for this at all. In unity you have more freedom. You can roll out your own rendering pipeline even.

That's extremely unlikely. ChatGPT is extremely knowledgeable of unity, the issue is it hallucinates and knows of an old unity version, plus it cannot reliably maintain long dialogue.

I'd expect it to be able to provide comprehensive information at least on the level of experienced user. The talking box cannot think, but can remember many things. So the first step in "How do I X" would be to ask it.