First off, don't be afraid to break parts of a process with the entity system into multiple passes.
Our scene (aka map) loader process loads map metadata. It's during this process where entity IDs get allocated and whatever metadata references components is used to create the necessary components associated to this entity ID. At this end of this first phase, the entity is in an inactive state and the components which have been allocated are stored in the various owning subsystems but are flagged as pending commits. (Think relational database here).
Once the entity has been constructed either by using a combination of prefab archetype data and map metadata or simply map metadata, the next step must begin. This next step is an inspection pass where systems or components (depending on your design) can look into an entity and determine what other stuff exists. If required, references to other systems or components can be obtained and stored.
Do be mindful of using pointers, particularly if they're not weak_ptr types. At any moment, any outside source could cause a component to be removed from an entity and if you depend on that component, have stored a raw pointer and do not have checks in place to eliminate the reference, this could lead to unexpected behavior. I generally prefer either the use of a component handle where a handle is converted to a pointer at the time of access or maintain copies of the data; generally of which the later is usually more cache friendly and gives a slightly higher performance depending on your data structures.
Assuming that your game doesn't support a concept such as teleport, generally the physics component's position & orientation will be seeded from the transform during the inspection phase. This is what makes sure the physics simulation starts out synchronized with the entity's transform data. If the entity has no transform, then you cannot initialize the physics component, and thus it remains "pending" or "inactive".
The next step is to activate your entity, at which point all systems are informed and the components which were initialized & synchronized successfully are moved into an active state and thus the system's update process will begin to manage the state for that component & entity. Either here or in the prior inspection step is where you could allocate whatever subsystem specific data objects that are needed. For example, a RigidBody for physics, a Collider for the Collision system, your SceneNode and various other renderable aspects in the render system, etc.
The point is once activation has completed, the entity's component state should be ready to be manipulated by any outside source.
When you begin to apply movement to your entity, the force/direction get applied to some movement/velocity component. When the physics system begins to step it's simulation, it takes all entities with a physics component and have a force/velocity and applies those values to the rigid bodies in the simulation and then steps the physics world simulation. If collisions are detected, then an event can be fired and any system interested in collisions can react. If no collisions took place and position/orientation were modified, the physics system can emit a position/orientation update message. The transform system can receive it and update the entity's position/orientation.
Here you have two options:
A) have the systems which manage your scene render objects also listen for physics events and update the scene's transform/orientation as well
B) have the transform system emit a second message after having changed the transform.
Now if your game had a teleport system, your transform system, physics system and all those render object systems might register to be notified upon a TeleportationEvent, then they simply update their position/orientation based on the transport system's knowledge of where you left and where to spawn your character perhaps on a new map or in another zone or area of the current map.
One thing I will also caution you on is try to avoid leaking system specific data into your components. I find often that people will create say a Light component, place all the data regarding how to construct a light in the render system and then have the component hold a pointer or some reference to the render system's Light object implementation. Instead, I prefer the idea of creating some internal data structure storage where the system holds the Light object's implementation pointer and can relate that back to a component of a specific entity. In some cases it's been more efficient to marry parts of the component's data with the specific systems implementation pointers and store all that in a specific structure and simply iterate those each frame and use a series of events to replicate changes from the components or other system changes to the internal structure the system maintains at set intervals.
As far as to your last question regarding the rendering library, there is really no set way. I generally code against a set of interfaces and so my engine's framework is much like that of CryEngine where an IRenderer interface is exposed that gives you access to the 3D rendering library. This class initializes the library, allows me to attach it to a specific window handle to begin rendering, exposes a render method, has support to restart the 3D library, exposes the scene graph, etc. I simply have the engine framework construct the Renderer class during startup. I leave the application class responsible for being a thin wrapper around the framework and exposing a series of listener methods and such which can be overwritten based on application needs such as OnActionEvent(), OnKeyEvent(), OnMouseEvent(), OnPreUpdate(), OnUpdateFixed(), OnUpdate(), and OnPreRender(), etc.
Feel free to ask any questions, hopefully it gives you a clearer idea. Just remember that the entity system is an abstraction layer that sits way above the underlying systems in the engine. It's basically the system or systems which designers in AAA titles interact with in the editors to create these elaborate games. What happens at the physics, rendering, and other various low-level systems are well below the entity framework but are influenced by "inputs" given to the components.
One thing I forgot to mention above is that once an entity has been activated and you add/remove components from the entity, those changes are once again considered "pending". This means that another inspection/activation process must be performed on the entity to allow various systems/components to determine whether or not the entity's state continues to satisfy the requirements of some systems and if not cleanup the existing data if it exists and treat the component as though it was just created but couldn't be initialized due to missing dependencies.
Edited by crancran, 15 January 2014 - 12:00 AM.