2
\$\begingroup\$

A part of my game asset manager are divided into 3 layers.

1. Loader (Opengl-related) : MeshInternal, TextureInternal

A manager will ensure that 1 filename will be loaded only once.

2. Handle : MeshPtr , TexturePtr

This can be stored in game logic, and can be used in Material.
Each instance can be duplicated and can be stored by game logic.
They are just pointers to [1].

//game logic
MeshPtr meshptr=meshManager()->get(ROCKET_MESH);

3. 3D Material (Material)

It contained a fix amount of textures (e.g. lambertian, specular, emit, ...) and some tweaked color values (e.g. lambertian color multiplier).

It is stored by value, because each instance of in-game 3D-object may duplicated it and customize it to match its unique attribute (e.g. red=low HP).

Game logic will cache it by value.

//game logic
Material mat=material()->mat_ROCKET; //shallow copy work well
//can also be called using enum

Question

Although everything work really good, my fear arise.

I store [2] by value.  It means I stored [1] in term of pointer.
I store [3] & [4] by value.

I think it is inconsistent, especially when I look at example code in [2]&[3] above.

How to professionally avoid this type of inconsistency? ... or is it the correct way to go?
Are there any disadvantage/limitation of this design?

\$\endgroup\$
3
\$\begingroup\$

You want to be able to easily sort by material in order to render everything that has the same material at once. This helps a lot with efficiency. So it's almost definitely a bad idea to store materials by actual value though this may seem handy for some reason. Instead move to some kind of index into a materials array.

The rest is fine, logically speaking. Since they are variable size objects there is no reasonable way to put them all into a flat object so pointers are fine here.

\$\endgroup\$
  • \$\begingroup\$ +1 Thank! I use a library (with sophisticate internal sorting and caching) so I think it is not so inefficient. You mean you don't feel bad about the inconsistency "value vs pointer" (in the principle alone), right? XD (I thought there is some convention that I should make it consistent.) \$\endgroup\$ – javaLover Sep 17 '16 at 5:49
  • 1
    \$\begingroup\$ I would not use value for any of it because you are flattening your data. For example what if you then reload the material, what happens to all those copies? I'd keep it to all pointers, or something similar like handle or index. \$\endgroup\$ – Yudrist Sep 17 '16 at 5:58

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.