I have run into this problem for my own game engine currently being designed. The method I used was to store the all the loaded textures into a hash table with the path as its key: std::unordered_map<std::string, Texture>. This data structure will be managed by a ResourceManager or whatever you want to call. Every time you want to retrieve a texture you query the ResourceManager with the key. If it doesn't exist, the ResourceManager is responsible for instantiating the texture and return a pointer. Basically something looks like this

Texture *ResourceManager::getTexture(const std::string &path, const TextureType& type)
{
    auto t = m_textures.find(path);
    if (t == m_textures.end())
    {
        return loadTexture(path, type);
    }
    return &t->second;
}

And the relationship between Texture, Material and Mesh (and shaders) can be as follow:

Meshes contain vertex shader and pointers to the material, and materials will have the fragment shader object and pointers to the textures whom the fragment shader will use. And all three kinds of objects and shaders can be stored using the method we discussed above. So when you import from Assimp you will load all the resources separately and only reference each other. The above structure will be useful when you want to dynamically use material and meshes. for example, you can give your brick material to the human mesh or the wall mesh.

I have run into this problem for my own game engine currently being designed. The method I used was to store the all the loaded textures into a hash table with the path as its key: std::unordered_map<std::string, Texture>. This data structure will be managed by a ResourceManager or whatever you want to call. Every time you want to retrieve a texture you query the ResourceManager with the key. If it doesn't exist, the ResourceManager is responsible for instantiating the texture and return a pointer. Basically something looks like this

Texture *ResourceManager::getTexture(const std::string &path, const TextureType& type)
{
    auto t = m_textures.find(path);
    if (t == m_textures.end())
    {
        return loadTexture(path, type);
    }
    return &t->second;
}

And the relationship between Texture, Material and Mesh (and shaders) can be as follow:

Meshes contain pointers to the material, and materials will have the shader program object and pointers to the textures whom the fragment shader will use. And all three kinds of objects can be stored using the method we discussed above. So when you import from Assimp you will load all the resources separately and only reference each other. The above structure will be useful when you want to dynamically use material and meshes. for example, you can give your brick material to the human mesh or the wall mesh.

I have run into this problem for my own game engine currently being designed. The method I used was to store the all the loaded textures into a hash table with the path as its key: std::unordered_map<std::string, Texture>. This data structure will be managed by a ResourceManager or whatever you want to call. Every time you want to retrieve a texture you query the ResourceManager with the key. If it doesn't exist, the ResourceManager is responsible for instantiating the texture and return a pointer. Basically something looks like this

Texture *ResourceManager::getTexture(const std::string &path, const TextureType& type)
{
    auto t = m_textures.find(path);
    if (t == m_textures.end())
    {
        return loadTexture(path, type);
    }
    return &t->second;
}

And the relationship between Texture, Material and Mesh (and shaders) can be as follow:

Meshes contain vertex shader and pointers to the material, and materials will have the fragment shader object and pointers to the textures whom the fragment shader will use. And all three kinds of objects and shaders can be stored using the method we discussed above. So when you import from Assimp you will load all the resources separately and only reference each other. The above structure will be useful when you want to dynamically use material and meshes. for example, you can give your brick material to the human mesh or the wall mesh. Where you put your shader program object depends on you. I choose to put it on the mesh, so that every time I relink the material with the mesh I can relink the program easily.

I have run into this problem for my own game engine currently being designed. The method I used was to store the all the loaded textures into a hash table with the path as its key: std::unordered_map<std::string, Texture>. This data structure will be managed by a ResourceManager or whatever you want to call. Every time you want to retrieve a texture you query the ResourceManager with the key. If it doesn't exist, the ResourceManager is responsible for instantiating the texture and return a pointer. Basically something looks like this

Texture *ResourceManager::getTexture(const std::string &path, const TextureType& type)
{
    auto t = m_textures.find(path);
    if (t == m_textures.end())
    {
        return loadTexture(path, type);
    }
    return &t->second;
}

And the relationship between Texture, Material and Mesh (and shaders) can be as follow:

Meshes contain vertex shader and pointers to the material, and materials will have the fragment shader object and pointers to the textures whom the fragment shader will use. And all three kinds of objects and shaders can be stored using the method we discussed above. So when you import from Assimp you will load all the resources separately and only reference each other. The above structure will be useful when you want to dynamically use material and meshes. for example, you can give your brick material to the human mesh or the wall mesh.