0
\$\begingroup\$

I'm making a fairly basic OpenGL 3D engine, at the moment. In this engine, when you load an object, you would write

manager->LoadObjFile("cube.obj");
manager->AddParent("uvmap.bmp", "cube.obj", "cube", glm::vec3(10.0f, 1.0f, 0.0f));

"uvmap.bmp" being the texture, "cube.obj" is the .obj file path, "cube" being the ID for the object.

My question is, at the moment, when it loads an object, it stores the object in a struct with all of the buffer data and an ID, the ID being the path of the obj file, so when I load an .obj, it runs through all of the already loaded files and compared the ID of each using strcmp, which obviously when there's thousands of items, is going to start to get a bit slow.... it does the same for AddParent, and most of my other methods (different vector of data than where the obj data is stored).

What would be best in terms of identifying items, an integer? I really don't know, I want this to be as high level, user friendly as possible, but want to keep it as optimized and as efficient as possible.

\$\endgroup\$
2
\$\begingroup\$

Using integer ID's allows you to keep all your objects in an std::vector<GameObject>. Accessing a vector by index is a constant-time operation.

If you want to keep using strings as object keys (having human-readable keys might be more convenient for the user), consider using an std::unordered_map<string, GameObject> to map strings to objects. It is usually implemented as a hashtable, which means search time is also constant (but a far longer constant than a vector).

But the question is if you need such object-ID's and a central object index at all. You could instead have an object-oriented API where manager->LoadObjFile returns an object and any manipulation of that object are then performed by calling methods of that object, not indirectly through the manager:

cube = manager->LoadObjFile("cube.obj");
cube.setTexture("uvmap.bmp");
cube.setPostition(glm::vec3(10.0f, 1.0f, 0.0f));
\$\endgroup\$
2
  • \$\begingroup\$ 2 cents: a good deal of the cost of the unordered_map in this case will be that of constantly hashing the string keys. That's just one of the reasons strings should be avoided internally if possible - expose them to tools or whatever but hash them up front and use the hashes directly. If you don't care about adding new resources on the fly, you can even devise a perfect hash function. \$\endgroup\$ – jmegaffin Apr 2 '16 at 22:51
  • \$\begingroup\$ Changed it all now so no strings are used at all, I went with the object oriented API but modified it in a way that worked best with my architecture Thanks \$\endgroup\$ – Rhino1181 Apr 3 '16 at 13:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.