There are no GL-specific steps needed for file I/O. You can create a virtual filesystem with the --preload-file emcc directive or running file_packager.py separately, and then use standard C file IO to access the VFS for loading textures and models. E.g. I use custom dds/png/bmp/crunch/obj file loaders with hand-written C code across native and web, which work ok, as long as the files are packaged in a VFS for fopen() to work. Alternatively you can asynchronously load files and then use a custom 'load-texture-from-buffer-in-memory' api to feed data with gl(Compressed)TexImage2D and glBufferData, etc.
That said, there are some special paths possible with image loading. One is a built-in feature that uses browser image codecs to load up textures into a preloaded cache when texture files are loaded with SDL. This avoids having to run the image decompression codecs in JS to get some performance. However it is currently done all up front in the page preload step, so dynamic streaming cases are not supported atm. The other case is one that was discussed a few times in history, but there's no implementation in Emscripten, since it's a bit of a special case. If you currently load a VFS with --preload-file, then the data file will be XHRed by the browser, then copied to Emscripten HEAP, and then loaded by your C image codecs, and finally copied by gl(Compressed)TexImage2D to the GPU. But if you had your image data already in GPU-friendly form in the XHR request (e.g. DDS), you could handwrite JS code to directly feed gl(Compressed)TexImage2D calls from the XHR data, skipping a lot of texture memory ops in Emscripten C side. Although whether this is a win depends on whether you can afford to process it all directly in JS, since it pretty much requires uncompressed texture data from the XHR. Now, building Assimp "should work", since it's generic platform-independent C++ code (right?). However the last time I looked it had a lot of dependencies, so building all of them can require considerable build chain development for work Assimp specifically, and the resulting library can be quite large. I don't think Assimp uses threads so it should be safe. Do tells us how it goes if you plan on doing it, at least I haven't yet heard about any success stories on Assimp+Emscripten, so you will probably be the first to work on the build system for that project. Jukka On Mar 8, 2014 4:25 PM, "Michael IV" <[email protected]> wrote: > A question I have is how Emscripten deals with IO procedures as texture > and models loading.Are there some specific libs that are supported ?Or I > can just pick up anything like Assimp and use it ? > > Thanks. > > -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
