我們目前的場景類Scene中不僅包含對場景節點的管理，還包含對場景中節點的繪制操作，也就是說當我們調用Scene::Update方法時：

scene->Update(time);

場景首先會遍歷場景中的所有節點，更新場景中節點的位置信息，然後會找到場景中所有需要繪制的對象並執行渲染操作，偽代碼如下：

void Scene::Update(float dt) {
    UpdateTransform(dt);
    RenderAll(dt);                     
}

void Scene::RenderAll(float dt) {
    PreRender(dt);
    vector
 
<ModelPtr> models = GetModels();
    for (int i = 0; i < models.size(); i++) {
        ModelPtr model = models.at(i);
        MeshPtr mesh = model->GetMesh();
        VertexBufferPtr vertex_buffer = mesh->GetVertexBuffer();
        IndexBufferPtr index_buffer = mesh->GetIndexBuffer();
        MaterialPtr material
 
->model->GetMaterial();
        // Render model
        // ......
    } 
    PostRender(dt);
}

然而事實上，渲染作為渲染引擎中一個非常復雜的操作，將來由很大的變動空間。將管理場景和渲染場景這兩項任務都寫在一個類Scene類中，不符合單一職責原則。場景管理，包括節點位置信息以及相關狀態的管理和更新和場景渲染是兩個相對獨立的功能。場景管理相對易於實現，功能也比較固定，場景渲染往往需要用到很多圖形學技術，隨著時間的推移，技術的進步，必然要不斷的更新渲染模塊。而當每次更新渲染模塊式都需要修改並重新編譯場景管理模塊，無形中增加了維護和重構的困難。因此這裏我們決定將場景管理和場景渲染模塊解耦。這裏簡單介紹一下重構計劃。

Component類表示節點的數據和行為。其中Model組件僅僅只是一個渲染數據的集合，只負責管理網格，材質等信息，不負責繪制，即移除Model::Render()方法，將渲染相關代碼移動到Renderer中，讓Renderer負責一切和渲染有關的操作，Component只負責維護數據。

Node類基本不變，Node::Update()只負責更新節點的位置信息等狀態，不負責調用渲染函數。

Scene只負責場景管理，不負責場景渲染，Scene只是先場景的邏輯功能，渲染功能全部由Renderer實現。

新建Graphics類，將當前Renderer類的功能全部移動到Graphics中，Graphics類負責封裝底層的圖形API。Renderer類使用Graphics，負責實現場景的渲染邏輯。

Renderer類的實現參考Urho3d引擎的方法，在這裏我們讓Renderer包含一組Viewport，每個Viewport包含一個Scene對象，一個Camera對象，表示要繪制的場景和觀察場景的攝像機，以及常見的(x, y, w, h)屬性，用來表示窗口中的繪制區域。每次叠代將調用一次Renderer::Render()方法，該方法遍歷所有的Viewport，讀取Viewport中的Scene，Camera，查找Scene中的所有可渲染對象和燈光，並依次執行繪制。

這是就是本次重構計劃。本次重構計劃至少一周內完成。

Bubble引擎重構計劃