Performance considerations

[Ollinator]

Hey there!

First of all I'd like to thank you for your contributions, outstanding work there! I'm currently using your Luamachine to implement a mission editor and thinking about also adding support for custom assets using the glTFRuntime plugin.

Though i have some concerns about performance, specifically loading/spawning times. I noticed that even the simple example assets (duck and helmet) take about 500ms to spawn, probably due to reconstruction of geometry and textures out of the gltf file. I see you plan on adding async loading, this will surely help against the blocking, but imagining the loading of dozens (or hundreds!) of gltf assets for user mods the loading times are prolly going to explode...

One way to alleviate this would probably be to only load assets needed (both distance and logic based), but there would probably still be quite some popping in case too many assets are scrammed in one area.
Another way might be some kind of streaming, where only a low res version is spawned initially and is replaced with the higher res version once its ready; but I have no idea if gltf supports such?
And finally - and probably the one with the most work (though perhaps code from the unreal editor/engine could be adapted) - would be some kind of packaging mechanism, storing mods preferably as unreal paks and using builtin engine functions to load them. Which would add streaming for free, but its probably not permitted to ship unrealpak.exe or code from it with shipped games.

So thats just my featherbrained thoughts on the topic...hopefully not too much nonsense was said! ^^

Cheers!

[rdeioris]

@Ollinator regarding pak files, in luamachine there is already a pak files loader in the function library (exposed to blueprints too). It generally works, but building 'reusable' pak files is really hard and requires lot of compromises.

In the TODO list of glTFRuntime there is already LOD support (this is an extension to glTF specs, but i am planning to support manual LOD configuration by merging multiple glTF meshes as LODs in a single StaticMesh). This would allow you to load assets in a more 'advanced' way.

Finally, regarding performance, there are still optimization areas, but yes, the main time is spent in the various optimizations/checks made by unreal. For staticmeshes we can cut down time a bit with the ProceduralMeshComponent at the cost of higher rendering time. maybe this could be another option to add.

[spr1ngd]

@Ollinator have you implement any one of those performance optimization plans？or do you have other solution to accerate glTF loading?
i find two bottlenecks of loading , generate mipmap and load primitives.

• i try to generate mipmap use rendertarget2d. it done well..
• and i also want to parse primitive data use multi thread , could you offer some advices about load primitives ? @rdeioris

thanks.

[rdeioris]

@spr1ngd since the opening of the issue we got async loading for both static and skeletalmeshes. Currently the missing part is morph targets loading that is really slow and it is still not part of the async thread loader.

[spr1ngd]

@rdeioris Yes , i have try to use ActorAsync , but i encounter the ESPMode problem，i try to set PLATFORM_WEAKLY_CONSISTENT_MEMORY = 1 , but the problem still exists. The problem is samed with #11 ,but crashed in TMap. TMap does not support ThreadSafe.

[rdeioris]

@spr1ngd please share your asset on the discord server, there are literally dozens of reasons for the crash

[rdeioris]

closing as in the past few months lot of optimizations (included parallelism in lot of parts) have been added