#13 Pxory support : better memory and performances


Hi all,

Assimp use its own structure to store the datas (textures, vertices, indices, uv, etc...), but most of the application have their own scene graph or structure !

It will be fine that assimp use the 'Proxy' pattern, this way :

class IMeshProxy
int GetIndicesCount();
int GetIndice(int index);
vector3 GetVertice_P(int index);
uv GetUV(int index);


This way it will be possible to create our own proxy and Assimp will play directly with our structure/objects/graph !

It is usefull for hughe scene because with the current version we have 2x the data in memory, the Assimp one and our own structure that we copy.
Also, once Assimp has imported we have to convert it !

Of course, Assimp can provide its own default implementation of the objects (like today) based on the proxies.

BTW, I just describe the basic principle but it has to be well done to support all kind of scene graph etc...


  • I don't believe this will be feasible.

    - we would need to rewrite *everything*
    - there are huge differences between scenegraphs and I doubt we can offer an interface that fits to everybody.

    Assimp is not intended to be used for loading at runtime but rather as an offline content processing tool (i.e. you load a file using assimp, convert it to your own optimized file format and save to disc).

    Of course it *can* be used at runtime, but in this case one needs accept the memory overhead.

    Bye, Alex

  • While this might be a good idea to reduce memory overhead, it's not feasible for Assimp. The scene data is processed 5 to 20 times from what the format-specific reader reads to what you get back from Importer::ReadFile at the end. Using a callback interface like your proposition would mean to determine the last post processing step and have it submit all scene nodes, materials, meshes and other data via the interface. All previous post processing steps and the loaders themselves would still need to have all data in memory. You'd save nothing.

    Apart from that: a callback interface is very C++ specific. It would make ports to other languages problematic.


    • status: open --> closed