Is Loading OBJ mesh files from memory possible?

[Zimond]

I use Zip containers as media files for graphics and stuff. So far I was able to avoid having to use temp folders for extracting images or sounds by loading textures and sounds (via bass) from a memorystream directly but it seems that OBJ files can only be loaded from disk. Is that correct?

[lifepower]

In practical sense, OBJ files generally tend to be big. Some OBJ files used to test Afterwarp have sizes of ~26 Gb and when loading in ModelForge (or Afterwarp / AVX512 version, which uses double for mesh vertex coordinates), may occupy more than 64Gb of RAM during the process. Afterwarp loads OBJ files gradually by reading small chunks, but intermediate vertex data has to be kept in memory so that it can be re-arranged to an interleaved vertex buffer.

Also, remember that OBJ file comes with one or more accompanying MTL files, each of which may also come accompanied with one or more texture files. As a general-purpose solution, loading OBJ files from memory would require some API for "streaming" files in portions, and some API to provide all the necessary files. As MTL and texture files can be referenced by relative and absolute paths, this path structure would also need to be handled in some way. All of this would require significant boilerplate both in the DLL, Delphi, FreePascal/Lazarus and .NET. At least so far, the costs of maintaining this extra boilerplate completely outweighs its benefits.

There are few alternatives, however, that you could use. One approach would be extracting OBJ file to Windows temporary location (and temporary file name - there is Windows API to generate that) and loading it from there (in case of MTL file, if Afterwarp can't find the file referenced by OBJ file and no other material files have been loaded, it will try to load MTL file with the same name as OBJ, just changing the extension). This is something that is used quite often in practice. Another approach would be loading OBJ, then saving it to your own format (a naive approach is just dumping the contents of TMeshBuffer). Afterwarp has its own proprietary format used in a couple of examples, which is just a binary containing vertices, normals, and so on.

[Zimond]

I thought so that this is more complex than loading a texture. I used the windows temp folder in my old engine. I will just do so again. Thanks for the clear up