1.script先由ResourceGroupMgr在prepare函數里根據不同的后綴名選擇不同的ScriptLoader的派生類來加載，這里我們就以ScriptCompilerMgr為例。（今天開始細看材質加載部分的代碼才發現ogre的材質解析原來還有兩套，以前的一套是MaterialSerializer，1.6之后默認使用的是ScriptCompilerMgr.）
2.調用ScriptCompilerMgr內部ScriptCompiler對象的compile函數，這里其實也沒有進行實際分析，只是創建并調用了分析和編譯的對象：ScriptLexer，ScriptParser，ScriptCompiler。
3.先由ScriptLexer對文本進行分析，創建一個包含了所有token信息節點的列表，注意這一步僅僅是將所有材質里的詞匯單元提取出來而已，還沒有生成CST，乃至AST（當然這里的CST和AST都是簡化的），這里的實現比較易讀在ScriptLexer::tokenize中對文本的每個字符進行遍歷，查找token（在ogre里也就是譬如{ } // \ : newline等，當然普通的字符肯定也算的），最后生成一個tokenlist。
4. 接下來將tokenList傳入ScriptParser的parse函數中，這些token節點將被根據標記符的關系，而生成一個簡單有父子關系的分析樹，也就是CST了。到這里你就發現之前動輒就100個的nodelist已經變成了ConcreteNodeList,當然這里的node每個都是一個樹了.以最外面的{}為根.當然沒有{}的部分就變成一個節點(知道找到{或者別的標記符)
5.接著，在ScriptCompiler里將之前生成的CST轉化為AST（這里的具體轉化的代碼我還沒細看。。）
6.呼，終于要到最后了，根據每個AST的類型調用不同的ScriptTranslator，例如材質的話就取得MaterialTranslator來解釋成最終的material，然后對其中的每個AST子節點再調用對應的ScriptTranslator，（例如pass就調用PassTranslator等）把所有的值都設置好，這樣所有解釋的工作終于完成了。
呼，的確是個很漫長的過程。。個人感覺如果把scriptLexer換成已有的什么文本解釋庫讀取的速度會不會得到很多提升呢？譬如如今比較流行的rapidXml什么的，畢竟個人覺得這些專門優化文本庫的性能還是很高的（雖然我得說尖括號啥的的確不是那么易讀～）。當然我覺得ogre這么寫的架勢很可能有想將原來普通的腳本配置文件提升成ogre專用的腳本語言的趨勢？（最早只是寫了一堆Serializer而已）