突然想到另外一個擺扭解構的2D應用。如果把扭動軸選擇跟螢幕垂直，那就可以用3D物件的旋轉牽動2D要素的旋轉或者其他資料，因為解構得到的扭轉部分就是3D物件旋轉投影到螢幕上的結果。

但是就效能而言，不如把物件的一個軸投影到螢幕上，然後找該投影和一個固定2D軸的角度。但擺扭解構又不像投影法一樣，有物件軸與螢幕垂直的時候會數值炸掉的缺點。

1. 應該是在lighting pass的時候可以一次處理四盞燈，減少draw call。
   
2. 我的理解是，45盞燈是用deferred rendering方式在light pre-pass產生light map，forward rendering pass只是對light map做look-up。

對indie dev很友善的策略啊，不過對使用in-house engine的工作室來說沒有差就是了，使用in-house engine的好處是效能和特化性能夠比現成商業引擎好

當然是in-house engine啊

對了，另外是否有刪文功能? 感謝!

交替切換不同矩形，某種程度而言可以算是time-slicing，雖然說time-slicing技巧的本意是要把吃效能的邏輯分散到多個frame，我在工作上常常用這招來分散AI運算資源消耗