[Models,Materials] Create LoadFromMemory versions of all Loaders

[JeffM2501]

It is currently not possible to load in several file types "from memory", such as Models, Meshes, Materials, and Animations. These loaders often reference other files and thus can not make use of a single "from memory" function.

To allow resource/asset management systems, raylib should allow the client code to install callbacks to handle all file reads, both binary and text. This will allow applications to provide file data from any location needed, or from archive or database files, while still maintain the ability for asset loaders to reference relative files.

The branch https://github.com/JeffM2501/raylib/tree/virtual_fs_hooks , has an example implementation of this for discussion.

Original issue text below

[Models,Materials] Create LoadFromMemory versions of all Loaders

Raylib has LoadTextureFromMemory, LoadImageFromMemor, LoadWaveFromMemory, and LoadFontFromMemory, but is missing.

LoadModelFromMemory
LoadMeshesFromMemory
LoadMaterialsFromMemory
LoadModelAnimationsFromMemory

This makes it difficult to load assets from an archive system or online.

I propose that the model and material systems be refactored to be able to expose from memory versions of these loaders.

The model loaders LoadOBJ, LoadIQM, etc.. all currently load the file data into ram before processing them, so it should be relatively easy to split the processing out from the loading into separate functions to make this possible with out any real maintenance burden or code duplication.

[JeffM2501]

A better option may be to have an installable callback that is used to get the data from a file, effectively replacing LoadFileText and LoadFileData. This would allow all file system access to be virtualized with less work.

[JeffM2501]

I have done an initial workup of what installable file system callbacks would look like in this branch in my fork. https://github.com/JeffM2501/raylib/tree/virtual_fs_hooks

Files changed.
JeffM2501@8cbdf2c

The changes are minimal and all existing functionality is preserved. These changes allow my asset management system to hook in and provide raylib with file read functionality. This means that once installed the user can just use all the regular raylib load functions as normal with virtual relative paths and the backend will figure out where the file data is (on disk or from an archive), and allocate the correct memory using the MemAlloc function exposed in raylib 3.5, allowing raylib to manage the memory as normal from then on.

[JeffM2501]

The more I look at this, the more I feel that the initial proposal will not work. Many of the model loaders load additional files such as materials and textures via relative paths. This means that a simple "from memory" type function can never work, since it is not possible to reference other data blocks in the same way that files can be referenced.

The only real solution to this is file IO callbacks.

I am going to rename the issue to be more in line with this concept.

[raysan5]

@JeffM2501 Yeah, I found the same problem when implementing the other Load*FromMemory() functions, Models are complex structures that could get data from multiple files: meshes, materials, textures, shaders... Actually, almost all Model fileformats (.obj, .gltf...) reference external files for the different types of data.

Agree that file IO callbacks is the best (and probably only) option.

I'm closing this issue, file IO callbacks is already on my list, together with the custom memory allocation callbacks.