I'm implementing an entity system in a game engine which is based on the Artemis framework. My question is, how can I wrap an existing rendering engine (like Ogre or Irrlicht) under this framework?

Should I create a component to wrap each mesh, texture, animation class
and wrap the rendering loop as a system in my framework? What should I do?

  • \$\begingroup\$ There might not be an unambiguous "best way" to solve this problem. To narrow down the answers, try editing your question to describe more of what you've tried so far, and where you're running into problems, or what types of criteria you consider higher priorities in evaluating solutions. \$\endgroup\$ – DMGregory Jun 14 '16 at 0:16
  • \$\begingroup\$ In my engine, I have a RenderSystem that renders all entities with a Render component. Mesh and Texture are components as well. Like @DMGregory stated, there's no "best way" to solve this problem. I've come to my own conclusions after many hours of research. Check out the Bitsquid engine blog. Don't look too hard at Artemis, IMHO. \$\endgroup\$ – Stradigos Jun 14 '16 at 4:06
  • \$\begingroup\$ @Stradigos ,So you are saying that no existing game engine implements ECS in its purest form \$\endgroup\$ – Dr.MSM Jun 14 '16 at 16:53
  • \$\begingroup\$ I'm saying that the architectural decisions you make will be entirely dependant on what you're trying to do and what you're willing to sacrifice for it, both personally (hours and hours of research) and in the engine itself as trade offs. It can't be all things, so it must be what you specifically need and what the hardware allows for. Look up Mike Actons talk on data oriented design for more. \$\endgroup\$ – Stradigos Jun 16 '16 at 4:15

Should I create a component to wrap each mesh, texture, animation class
and wrap the rendering loop as a system in my framework?

No, you should definitely not create a component (in the "entity-component" sense) for each of meshes, textures, animations, et cetera. What good is a texture component attached to an entity without any of the other rendering components? You'd just be creating abstraction, overhead and complexity for no reason.

What should I do?

Don't think too hard about it. It's not magic.

Entirely independent of your entity/component system, your rendering system should be able to take a description of a rendering task and queue that task for rendering. A "rendering task" is fundamentally just a structure containing a mesh reference, texture references, shader references and shader constant information, animation references, and transformation information; one structure containing everything necessary to "draw something." Major existing rendering engines provide this functionality in one form or another.

To tie your rendering system into your entity system, create one component type which simply acts as a "visual" or "portrayal" component. This component simply holds the rendering description for that entity, and provides access to it so it can be manipulated or updated or whatever.

The processor associated with these visual components simply collects them all and hands them off to the real renderer, which can batch or sort them as needed and do the actual rendering.

  • \$\begingroup\$ This is a subjective answer to a subjective question. \$\endgroup\$ – Stradigos Jun 16 '16 at 4:11

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.