In ECS ( Entity Component System ), the “Component” is the main data for engine.

So, every rendering objects need Mesh data.

But, some objects have same Mesh data.

Like this, how to manager sharing data in ECS?

Just put in Component? or Make new Manager for Mesh?

Then, I think that the solution is making new Manager for Mesh and Shader there are sharing all of part in engine.

And, rendering object and others have some component that call Mesh Manager and get their Mesh Info not just copy Mesh Data each other.

I wonder how other people make desing for this situation in custom engine.

I don't use ECS but I do have to handle mesh data. How you do it partially depends on your underlying API and where you want to draw the line between your engine and low-level interface. For instance, in DirectX12 and I think Vulkan also, you have to make sure your meshes aren't deleted while they are still in use. This is because you can have “in-flight” frames and so even if you are rending one frame, the previous frame may not be completed yet. You don't have this issue with DirectX 11 or OpenGL.

In my case a mesh has mesh-data and a material. The material further has a shader-set, which is just the shaders it uses, and a property-set which includes any constant data, such as constant buffers, textures and so forth. The mesh-data is the actual vertexes and indexes (if needed). Meshes can share mesh-data and materials. And materials can share shader-sets and property-sets. There is a reference countering system to keep track of when things are no longer being used.

Everything I've talked about above GPU meshes, although they can be referenced on the CPU. I also have CPU side meshes that get converted to the GPU mesh via a set of template classes.

How you would set this up in ECS I'm not sure, although I can imagine a few ways. Probably how you do this is going to vary a lot depending on your exact needs. My mesh system is set up primarily for LOD, where things change constantly. That might be overkill for you.

Even in ECS, “mesh data” is usually a shared asset of some sort. So you'd have some sort of managment for meshes of all sorts (files, base primitives, custom meshes)… and optimally, your component would only store a pointer to which mesh should be rendered; and your system will then render that mesh using your render-implementation. It doesn't make sense to tie mesh-logic closely to ECS, as you'll be using meshes in many places even outside of ECS, like when rendering a position-gizmo in the editor (and for the love of god, please don't handle those cases with invisible entities in the scene…)

I second Juliean,
To me the meshdata isn't an actual game data, it is just an asset like a texture of some sorts. It should then be loaded, stored and destroyed only by the associated library. Graphically-wise (just made that up) your components are just here to keep track of what's happing in the service (graphic library for example) layer at a very basic level (like position and the ids of used assets [mesh data, texture, mapping…]). The actual value and type of the assets will only be known to the specific lib and associated layer that will process it.

The facade pattern is quite usefull here , it allows you to store an id in your component that would refer to the actual mesh data used by the graphic service while still being loose coupled.