By preloading I mean the super easy setting in project settings->player->preload assets.
Let’s say in my gameplay I have a pool ready to spawn instances of a prefab.
For spawn time; does it make a difference if the assets of my prefab are preloaded ? Or since the instance are already instantiated are they already full loaded ? even if they have not yet made a single apparition ?
In other case, If my scene is fully loaded and the game is playing, why making some ui element visible for the first time do stutters or do blue textures like if they are not yet loaded ?
In a more general sense, how can I know if an asset is loaded or not ? how can I know if an asset is at risk of freeze on low specs if they are not loaded ?
And also, if my asset is a prefab with textures and sounds. Does adding the prefab alone in the pre-loaded list is enough to fully pre-load it ? Or the sounds and textures also need to be in the pre-load list ?
This is dangerously close to pre optimizing your game to where I would suggest just focus on making the game then going back to any issues you have, but since it’s more of a technical question it can be answered.
What you’re looking into is basically Lazy loading (meaning that certain assets like textures or shaders aren’t fully loaded into GPU memory until they are first needed.) this is a common practice for graphical elements.
Also you’re asking two different questions “How can I know when an asset is loaded” when you initialize a object it exists as memory so it is loaded in the application but that doesn’t mean that it’s being rendered by the graphics. So assuming what you are trying to ask is “how do you know when a object has been lazy loaded” (for something like UI) you can access a property to do a “hack”, like the properties width or height, you can force Unity to make sure that the texture is loaded and processed. Or load it off screen in your pool.
The game is done. I see sometime stutters and blue textures when first visible during pre release test. For the UI case, Is the “preload assets” enough to fix it ? with the texture at risk ?
Like mentioned the issue is with lazy loading. You can use preload assets but that doesn’t mean it’s going to be rendered. This is fundamentally an issue with when your ui is loaded into graphical memory.
I also wouldn’t suggest loading things like textures at application load because you’re just wasting memory. Preload asset in my opinion is for loading plugins and other libs that don’t run at start or awake or something that pre initializes the game with some api data.
Sometimes the best course of action is to put a giant black screen over the top of everything and remove it after a half second. Or if you have a loading screen, just leave it up another half second while the main UI comes up behind it.
This will almost always be a far far far less risky approach for fixing initial glitches than trying to implement something deeper into the project, touching more things. For instance preloading may mean memory is committed always, and in other future parts of the game this might cause issues.
100% of my games have a “zeroscene” that simply loads the main menu… that one-frame delay gets me out of so many annoying things through the ages. I started back when Unity3.5 used to report 640x480 resolution for the first frame of an Android app and my first frame would pick that up and use it. No more!
Preloading your textures off screen or specifically accessing the texture properties would fix this issue as well, I’m not familiar with how 3.5 offloads texture memory but all of these “textures not loading in for x seconds” comes down to lazy loading. If you’re happy with the black screen there’s nothing wrong with that, just explaining how to remove that extra step.
You guys can also easily test this with the profiler, you can see where the memory for your assets is being allocated and rendered.
What do you mean by preloading textures if you don’t use the preloaded-assets setting ? Is it hacky tricks like faking the use of it from a script ? what difference with using the preloaded assets list ?
At one time in the game all assets will be used at least one time and nothing will stutter again no ? I want the game to be in that state from the beginning. It’s a very small game with one scene. The loading/pre loading best practice are poorly documented and everyone has it’s own technique like to confirm this subject is a mess lol.
I’ve already gone into detail about what your issue is, and how to fix it, Kurt also gave you a suggestion, I think you need to step back a little and understand what the actual issue is and choose one of the recommendations we made to solve your issue.
Preloading an asset from the settings will most likely not solve your issue and it’s not a good solution (mentioned why above). Your assets are being lazy loaded you can solve that by one of the suggestions made to you above.
The documentation is fine if you understand memory, with preload assets assets are loaded at application start. What you are having issues with is (by the sounds of it) textures not being loaded into vram (this explains why it takes a few frames to display, you have your system memory and graphics memory VRAM, you don’t have to worry about system memory if you’re pooling because all of your objects are made and ready, if you don’t understand this take some time to learn about it.
Yeah the distinction between system memory and graphics memory worth to talk about because it’s not clear how differently they behave to me. I mean I know the graphics memory is reserved for texture but when they are loaded and when they are unloaded is not clear, as all of this is automated behind the scene. it’s not natural to know if your texture is already loaded and if it will be unloaded and loaded again later, and if only trying to render it behind a black screen or behind the camera will load it to vram or if accessing it’s properties is enough. not natural at all. there is no doc about that.
Lazy loading is a standard way in almost every application of handling graphics, even in mobile and web development. There is a clear distinction of what objects you instanciate and what unity does, graphics are handled by the api so that is a completely different system to creating a object , understanding more about development in general will cover these types of issues. This is why I don’t recommend jumping directly into a Game engine when starting with programming because you’re learning an Engine API along with a language. This is the hand holding that can trip you up if you don’t fully understand the whole process.
This is why I’m suggesting taking some time to understand the difference between your objects and your UI, there’s multiple ways for you to solve this problem, so test what ones were given and go with it.
Interesting. I kinda differ on that opinion. I think it is way more interesting to learn programming in a game context, making interactive wonderful toys to play with.
But your point is well-made, learning the big hairy UnityEngine API… I get that issue, but you kinda gotta.
As you might imagine, I have a canned thing about the process, just to sort of lay the grounds for “what you can expect.”
Your programming learning will be (largely) broken into broad areas of knowledge.
You may find these main buckets helpful to organize your learning:
C# language syntax (organization, structure, grammar, punctuation)
the .NET API (all the tools that come with C#: lists, dictionaries, file IO, etc)
the Unity API (everything in the using UnityEngine; namespace)
Beyond that mechanical stuff comes the interesting stuff: how to actually solve real world problems.
And alongside all of this are things like:
how to use Unity’s interface
how assets are imported
how Unity manages assets
how Unity connects things
You won’t learn it all at once. You will steadily layer on more and more knowledge as long as you are diligent and pay attention what you are doing.
You’re free to learn however you want, this is just my recommendation.
Yes but you’re missing classes, how they encapsulate data and behavior, and how objects interact is pretty much the standard in in understanding OOP, especially in Unity where components and game objects are central. Not understanding this to its extent can leave developers overly depend on MonoBehaviour and unity specific functions for everything, without fully grasping classes and object-oriented design or how to do something that doesn’t rely in the unity namespace.
Unity’s abstraction can sometimes obscure the underlying principles of C# and object-oriented programming, which are essential for development. How many times have you seen “How do I pass data from one class to another?”, this is covered in chapter 2 of any programming tutorial. Any chapter 2 in unity tutorials is going over the editor, something I don’t think you should be worried with when trying to learn how to program, it’s just adding more to remember and understand to an already complex system.
Having a base understanding will help with questions OP asked, it sounds like he has a basic understanding of objects they just seem to be missing how it’s structured behind the API. Based on my experience mentoring, hiring and training developers, I’ve found that having a solid foundational understanding of programming concepts leads to better long-term success when working with SDKs or APIs. Ideally to have a fundamental understanding first before jumping into a full blown application that’s made to make your job easier by handling all the heavy lifting for you.
I kinda consider that organization and structure from the first bucket above.
Totally agree. I just think learning it with interactive games has such a benefit in terms of giving a fun entertaining payback, at least compared to querying a database, that I think it’s worth it.
When using Split Application Binary on Android, there are chances for your assets fetched (via mostly reflection) on load might fail. This is because, the asset may not be packed in the resources of your base file. In this case, Preload assets will be helpful!
