Again, until we discover the golden eggs. Yes I know it is not possible.
I’ve seen Dragonheir which has 2 in-game charge bars and they are 100% accurate. My question is. How have they done it?
It doesn’t make much sense to put signs to know where the code goes.
I suppose there is some way to tell it “if you have executed x function = 30%, if you execute…” if you execute the last functions I suppose it should be over 90%.
in C++ when Loading Packages directly Async you can utilize GetAsyncLoadPercentage(FName& PackageName) (this is a naked UObject function) when you call, it will pause the current Async progress, so be cautious about calling it too often, and can have some spin up weight.
in C++ if you have multiple Async Load requests queued (either by calling them sequentially, or by physically calling 2 after 1 has finished), then you can register a callback by either Lambda (this is kind of unsafe as it could go out of scope and become null) or through binding a multicast delegate to the OnComplete delegate FStreamableManager.RequestAsyncLoad(FSoftObjectPath&, FStreamableDelegate)
I was never able to get the Declare Delegate or the TFunction versions to work, but you can pass an object reference to give an existing void function, and even pre-generate the parameters that will be used)
if say you make 20 calls to the AsyncLoad each response will be like 5%.
for Blueprints: “Not that I am aware of”. if you know the Object should exist on disk, you can maybe quarry each resulting object to be loaded for if it isValid then soft calculate the percentage from that.
most loading “percentages” will be a lie (when it is tested, amount of memory available relative to the thing being loaded, complexity of construction). Unless you have perfectly subdivided your assets into equal parts.
(loading 10KB and 5MB if the 10KB is at 50% doesn’t mean that the full load is 25% complete)
Just in the way Malloc hands memory over can be inconsistent leading to 2MB taking magically 5x longer because it is a Tuesday, or the user has to many Chromium tabs open resulting in the system needing to utilize Paging. These are milliseconds of deviations at a time but they add up.
then the system might request 2 threads to go do something else making Asyncs be put on pause.
on top of all this when we check is important because when we check the system has to stop doing the load to then give the response just to avoid Race Conditions, and a loadSynchronous will pause execution directly.
I think the Epic team should implement this for the next versions. Why epic and not us?
Well, they know almost perfectly, or should know, where the UE5 code sequence starts to where it ends. Then, they should have some “checks” or even better, depending on what has been processed, have a completion.
(I’m going to make a freehand sketch)
Suppose that the code executes n classes of the UE5 class in addition to reflection itself that creates “your own classes” based on the engine (they are those that UE5 creates from your code).
Well, then, you could have a summation of the classes, that is, whether they have been executed. Make a count (of classes already completed) and estimate the percentage based on the count.
Yes it sounds very nice, and someone could provide C++ code, but there would be infinite ways to do it, the question is, which one really works or is correct?
What form did this study use? I notice that in the bars each “tick” the animation hangs a little.
the engine is a framework that does abstracts away and helps with different aspects we are also given the full versatility of C++ (most of it within UObject derived classes)
each game has different requirements for amount being loaded, size of the requests, and even how they are to be loaded.
Epic is very much “we give you the tools you choose how to use the tool for your own project” there are some things they do proscribe like the rendering pipeline, physics system, and a unified Asset Manager; but between source compilation and just .ini replacement/modification you can roll your own if you want.
I could want to load 5K to 20K blueprints into memory when the game starts to always have them sitting there when they are needed to save on sparse loads (these can have negative impact on some hardware and lead to segmentation and seeks),
I could alternatively want to load things in smaller clusters, or even individually, on demand to have lower average memory overhead, but can have higher total disk calls.
these are valid approaches, and will be dependent on your targets, and other design choices.
quarrying the progress of an asyncLoad on “tick” would be excessive, especially in a loading screen, because each check pauses the asyncLoad, yes you are giving the player/user “the most up to date value” but you are also making the load take longer, and it would be more performant to just Load Synchronously (even though for larger things this can cause what appears to be a hard lock even though the application has not frozen).
on top of that this is just loading the object code into memory this is not instantiating the objects, none of the code has been triggered at that point. the callbacks for OnAsyncLoadComplete() will only say whether or not the instantiation will cause a hang, or fail because the object code is not in memory.
