# Entity/Component based engine rendering separation from logic

I noticed in Unity3D that each gameObject(entity) have its own renderer component, as far I understand, such component handle rendering logic.

I wonder if it is a common practice in entity/component based engines, when single entity have renderer components and logic components such as position, behavior altogether in one box?

Such approach sound odd to me, in my understanding entity itself belongs to logic part and shouldn't contain any render specific things inside.

With such approach it is impossible to swap renderers, it would require to rewrite all that customized renderers.

The way I would do it is, that entity would contain only logic specific components, like AI,transform,scripts plus reference to mesh, or sprite. Then some entity with Camera component would store all references to object that is visible to the camera. And in order to render all that stuff I would have to pass Camera reference to Renderer class and render all sprites,meshes of visible entities.

Is such approach somehow wrong?

• I removed the part of the question that asks "why does Unity do this," because it's (a) a second question and (b) not likely relevant to your actual problem. – Josh Mar 6 '13 at 16:23
• "With such approach it is impossible to swap renderers" 1) That's a bit of an assumption, it seems like the "renderer" component could just be a front end to whatever platform-specific rendering code it needs (pimpl idiom, for example) and 2) How much does that really matter for your needs? – Tetrad Mar 6 '13 at 17:37

Such approach sound odd to me, in my understanding entity itself belongs to logic part and shouldn't contain any render specific things inside.

In some entity systems, components only contain logic. In others, they only contain data. In yet others, they contain both. I'd certainly argue that putting the actual render commands (as in the OpenGL or D3D code) into the rendering component isn't ideal (see my answer here regarding the question "should objects render themselves?", which is the same principle under discussion). However, it is certainly possible to do so and even to do so in a fashion that allows the implementation of the rendering components to be swapped without having to alter the consumers of the component system. Doing so just involves any typical implementation-hiding technique.

It's acceptable, and common, to have a "visual component" that contains a reference to some renderable object that comes from the lower-level rendering subsystem and have that component export behavior or interface to allow the appearance data to be specified by other components (such as ones containing scripts).

The way I would do it is, that entity would contain only logic specific components, like AI,transform,scripts plus reference to mesh, or sprite. Then some entity with Camera component would store all references to object that is visible to the camera. And in order to render all that stuff I would have to pass Camera reference to Renderer class and render all sprites,meshes of visible entities.

Is such approach somehow wrong?

I don't really see what you gain by having a "camera" component. It seems like a very heavyweight operation inject into the entity system. Does, for example, the presence of the camera component mean that you always get a scene rendered from that camera's perspective? How then do you determine which of those scenes to present to the user, and where? It feels like -- without knowing more about this design -- you'd be shoving a lot of unrelated responsibility into the camera component. I'd prefer to see that responsibility handled by something external to the entity system.

Otherwise, that sounds like a perfectly usable system. It will have it's pros and cons, of course, but those will become apparent in practice and many of them will be specific to your needs and/or the needs of your game.

• Camera component have the value that they allow a view to be attached to a game object (like the player, a kill cam, etc.) and manipulated using the same interfaces and such that any other game object component uses. Separating the idea of a "view" from a camera certainly makes sense (where a view can have an active camera from the scene, be switched out, be assigned a specific viewport, be bound to an offscreen buffer, etc.). Super useful for cinematics, split-screen, security cams, etc. Having the camera manage visibility directly is a little off, though. – Sean Middleditch Jun 25 '13 at 2:23

You are right and wrong at the same time. The entity/component model is very flexible and that is one reason why it is used. What you very well point out is that it muddles the simulation (game logic) and presentation (graphic & sound).

The first thing to note is that a component does not mean that it will actually do something. For example a MeshRenderComponent may not actually render the mesh. It can be implemented as containing all relevant data and hand the actual rendering to a "system" of the engine.

This has two advantages. First, the entity can be fully instantiated on the server. All components that don't "work" on the server are just dumb data containers. The second, is that a system with all data resident can run tighter and more efficient loops, then when moving over components.

The quint essence, is that the data of entity/component model is muddled, but you can still keep the different systems properly isolated.

The second thing to note is, the good old question: "Does it matter?"

This is a way harder question to answer. From a software engineering standpoint the decision is clear, you have a pure simulation and a pure presentation layer. (Model-View-Controller) But when it comes to artists and level designers, it gets harder. You mention Unit3D and you may see where I am coming from.

A level designer says, I want this splash here over the waterfall. The engineer will implement a water simulation and determine where these effect need to go, the level designer just want to place it there, who cares that it is not perfectly accurate.

As it turns out the way that Unity3D muddles logic and presentation is how most non engineers actually think how things should work. (And don't try to explain why multi-player is so hard to implement with such a model...)

• Unity3D docs says, that Renderer components are actually rendering the stuff. The thing I also can't wrap my head around is that, as far as I know each component is being updated at fixed timestep. That means that if we believe what Unity docs say and the timestep is 40ms, then despite I could have 1000fps, in reality the entities visual representation would render/update only at 25fps? – Denis Narushevich Mar 6 '13 at 15:32
• That is Unity3D specific and I can't answer you that. Then again the 40ms probably relates to the logic tick time... not frame rate, since rendering just cannot be done "initiated" by the component. (Painters algorithm and all.) – rioki Mar 7 '13 at 13:20

It seems that Renderer is just a component (http://docs.unity3d.com/Documentation/ScriptReference/Renderer.html).

As far as I understand Renderer provides common functionality to more specific inherited components:

As far as I know Unity supports several underlying renderers for its various platforms, Direct3D and OpenGL among them:

Does Unity for PC use Direct3D or OpenGL?

So it must be possible to swap underlying renderers even if it is not available to end user (scripter).

If you have already read general information on component-entity-system architectures, then you know that entities are generally collections of components. A component may generally be anything including physics, animation, game logic etc. Why treat graphics differently?

Some component-entity-system architectures tend to put more logic in components, while some concentrate it all in systems and use components as pure data.

https://stackoverflow.com/questions/1901251/component-based-game-engine-design/3495647#3495647

• I agree, that graphical representation of entity should be component, but disagree, that any rendering should be done through component. The ball in real world have it's visual representation, but ball does nothing to be seen by man's eye, it's the light which delivers light particles to viewers eye. Than why entity comp should be doing any rendering? As written in unity docs "MeshRenderer renders meshes inserted by the MeshFilter or TextMesh.". So I'm trying to find out if it's common and if there is alternative approach which I could use in my realisation of simple entity/component engine. – Denis Narushevich Mar 6 '13 at 15:14
• @DenisNarushevich Ball emits reflected light in a particular way (texture) so it does something to be seen. Otherwise you can say that ball also does nothing to move - it's the unified impulse of its molecules that moves it. You "give" your ball a stream of raw light and it reflects it the way it wants and thus produces a rendering result. An eye is a different component that takes a stream of reflected light and transforms it into set of electric impulses. – Den Mar 6 '13 at 16:24
• @DenisNarushevich There is no "common" approach here. In my personal engine I only hold graphic data in rendering components and have a rendering system that iterates over components, but this is just my preference. IMHO you either put it in components or in systems. – Den Mar 6 '13 at 17:04

All i can say is GUI.Button is the worst kind of code any development team can write. This can lead to slow downs and what not.. Rendering and Logic in the same loop? Why then does Unity need an Update function? If Unity wanted to draw and run logic at the same time then it does not need any Update functions... In a team which is working on big projects handling code in the OnGUI() for logic is a disaster .. I'd rather not use Unity for this reason alone. Also the other reason is the concept of the Loading and Unloading meaning memory management is left on Unity to decide which is not at all ideal for any programmer. A programmer must know where and when memory is being used but Unity hides all of that.

As far as I come to understand Unity lets you create a lot of code and infact the full game in a matter of days if not a few months. But the time when you actually try and sell this game over PSN or XBOX you will repent why you chose Unity because now you have a game that works but you have no control of its memory management or FPS because of Rendering and Logic being written in the same code.

Also having rendering and logic in the same code makes it a mandatory to have lesser and lesser team mates working on the project. If one day you change the programmer your team will suffer.

In my view this Entity Component structure is not suitable for large teams making huge games. Try making an MMORPG on Unity3D ... you'll know what PAIN is! :D

• Unity is not an ECS, though it does use a form of component-based design. Also, its immediate-mode GUI is designed for tools and editors, not in-game HUDs and menus; if you use the wrong tool for the job, that's on you, not the tool. – Sean Middleditch Jun 25 '13 at 2:16