數位建築?

上次David老師的課程上談digital architecture..
很有意思..看到了許多不同的想法
看到有人堅持建築就是建築..不需要去探討blending或fusion
也看到有人對數位建築的熱情..遠超乎現在流行的以形為主的所謂數位建築

我很想提一個概念加上一個問題..
可惜感冒了喉嚨痛..沒辦法搶話
剛好老師又得趕車子..沒有足夠的討論時間..

真希望能有更多時間討論這個部份..
雖然我不認為David老師所說的革命會發生..
但在一個以數位建築自居的所上..總是一個重要而廣大的議題空間..

我自己的看法是認為所謂的數位建築其實早就發生了..
數位(digital)跟類比(analog)從科學的角度來看都是人類處理訊息的方式..
所謂訊息包括視覺..聽覺等五感..或是在體內傳遞的神經訊號等等
也就是人類接受刺激後產生反應的過程中所採取的處理形式..
或者說其實只是一種概念而已..本來就不是新東西..
例如太極八卦就是一種標準的數位系統..
而中國人老早就把這樣的數位系統概念運用在庭院設計上了..
所以我認為所謂的數位建築其實早就存在了..

那現在討論的熱熱鬧鬧的數位又是什麼?
其實是因為以數位概念所創造的電腦出現後..對人類的影響太大了
數位這個詞才突然被切割出來..
所以電路設計上有數位電路跟類比電路..數學上有線性數學與離散數學

但是非數位無以成事?當然不是..
像現在流行的手機是一種標準的數位系統..
但在GSM出現之前..就已經有了090的黑金剛..而黑金剛是類比系統的
同樣地在顯示器上也是..現在有數位電視..那以前的電視也不見得非數位不可
不過提到這個..就很容易引起數位類比孰優孰劣的紛爭..
所以沒必要去比較..
我想我只是要強調..數位或類比..其實都是人類處理訊息的方式..
就像電腦..除了現在的數位電腦..也會有類比電腦
甚至可能還會有量子電腦..光電腦等等..
這些都只是一種概念..實在沒必要特意去強調或是神話..

所以真正比較值得注意的..是純數位的建築..以及受到數位媒材影響的建築

純數位的建築..才是我認為會造成David老師所說的革命會形成的部分
但是在純粹虛擬的空間裡..現有建築形式存在的必要性是我所質疑的..
我認為建築將以別的形式存在..可能是bits..可能是information..可能是data
而這些都脫乎現在所能感知的建築..對很多建築設計者而言是很難接受的事
所以純粹虛擬的建築是否還能稱得上建築?那議題就會回到建築的"抽象"本質是什麼
很多人在談到建築究竟是什麼的時候總會秀出那張有屋頂的棚子的圖..
但那真的是建築的本質嗎?認為是的人..自然就會認為建築將在虛擬空間中消失..
因為那樣子的建築的型的必要性..或是像David老師所說的重量..甚至是機能都已不存在
那建築的依據是什麼呢?這本來就挑戰了對建築的認知與反思
然而如果不是呢?如果如我所認為其實建築設計的本質是在對空間性質的掌握與推演..
那我想建築就會以新的形式存在或展現在虛擬空間中..這是很容易理解的
甚至將會存在所有能被認知為空間的空間中..
就像CS講的architecture..跟Architecture講的architecture似乎不太一樣
但在我的觀點中..其實就其抽象的本質而言..是一樣的
CS講的architecture..同樣在掌握所有能使用的資源..找boundary..
甚至在推展空間的過程..CS同樣講programming....
我不認為是因為誰抄襲誰的用詞..或許剛好只是個巧合..
卻那麼巧地講中了..
我想Aleppo也有看到這點..但是站在他的觀點..我想他不能接受不像建築的建築
所以他辦了FEIDAD來peep這個部份的發展..但是又不敢導入課程中
因為這部份還是一團亂..不但挑戰設計的本質..也侵入了人類思考的本質..
或許..會成為一個更大的革命..促使人類去思考自己的思考
雖然我覺得其實他可以不用這麼怕..但是這樣的東西的creativity太難評斷
因為在這個領域下的發展大概什麼都是新的..問題就在..那什麼是好的?
問題就是這麼多的新東西是否能通過他在設計思考中講的social domain的evaluation....
我認為太難..所以他就只能用類似實驗的方式..透過FEIDAD去窺視
不過FEIDAD裡..被reviewer的主觀刪過後..80%以上都還是比較像建築的建築..
真的能看到多少..我很懷疑..
但是有沒有更好的方法來看這部份的發展..這應該留給他去傷腦筋就好

這部份我只在思考一個問題..
如果在未來人口爆炸..Matrix裡頭描述的人類容器或許不是不可能的事
那麼..所謂的建築..是那個容器?還是matrix世界?
人類對真實空間需求的縮小化..是持續在發生的..
現在的家裡..開始不再需要電話的空間..電視扁平化..甚至很多人都是電腦兼職..
朋友的聚會..開始減少空間中的移動..而是透過網路等形式
書櫃也減少了..大量的電子文本減少了人類閱讀行為的空間需求
再加上ubiquitous的推波助瀾..人類的生活空間需求已經相當大程度轉移進虛擬空間中了
那麼我想再問一次..所謂的建築..是那個容器?還是matrix世界?
當以往像建築的建築所能提供的事件或生活行為被虛擬化了以後..
我認為的答案是..both

David老師在掙扎地argue說
要不是真實空間中有萬神殿怎麼可能在虛擬空間中創造出萬神殿讓觀者感動?
然而要是虛擬環境進化到人類能夠直接在虛擬空間中做設計
誰說不可能以這樣的形式做出經典的設計來?
這樣來看的話..建築存在的前後順序本來就沒有關聯性的
我不認為他這個論點站得住腳

至於受數位媒材影響的建築..我想現在也越來越明顯將會是短時間內的主流吧
也是Aleppo真正想辦的東西..因為這樣的東西才會在最後回歸到實體建築..
這部份也不用去探討啦..常常聽他講聽到都會背了吧我想..
從Gehry到freeform..blob..makoto..

啊..其實還有很多想講..以後再寫吧
只是有的還沒整理清楚..有的怕講了會被建築的temple knight殺了
所以還是得自己偷偷跟自己的blog講..哈哈哈哈

總覺得很奇怪..曾經我說某人是建築本位者..
結果對方認為我是數位本位者所以不容易溝通..滿妙的..
因為很顯然對方並不了解我對數位的態度..所以我也懶得回應了
對一個橫跨物理與資訊的人而言..在類比系統跟數位系統都學過後
在玩過各式各樣的邏輯閘..拉過各種電阻電容..走過相位差..示波器後..
我從來不認為自己是什麼數位本位者..反倒我把數位看的非常非常輕..
我自己一直都覺得自己其實是個介面本位者..以後創個詞來形容好了^_^

半個靈魂

我的靈魂大概有一半在妳那裡....

妳昨天中午就怪怪的了....還害我被取笑....
只是想到妳狀況那麼不好..還硬撐著把大家的報告講完後
才倒下去....真是對不起妳啊

妳壞了..我也就跟著重感冒....好難受
明明昨天中午身體還好好的....
看來是真的心理影響生理啊....

唉..最近真不順啊....

回憶 - 與台鐵的恩怨

台鐵的網頁實在有夠難用..
我們常用的車站不過就那幾個站..每次都要選來選去很煩
而且不能離線查詢..也不能跨線查詢..
空有資料庫..卻一點也沒為使用者著想..介面超級不友善
所以才有那支查詢程式的誕生..也獲得了相當多的迴響..
寫那支程式的期間..是真正讓我感覺到.."啊..寫程式真是幸福啊.."的時期
圖片
剛剛興起找了一下以前寫的各個版本的readme..真是美好的回憶
也看到了當年跟台鐵的對決..還有跟使用者的互動過程

---

台鐵班車查詢系統 V0.9.4.15 說明
　　因為太多人建議列印功能了，所以花了一晚上的時間搞定這部分，當初因為覺得只是幾行資料，好像沒什麼列印價值所以並
沒這打算，想不到有這麼多人建議。列印建議使用A4大小列印，紙張太小可能會有資料被截掉看不到。而且目前限定只能列印一
張大小，超過一張的資料會被截掉，暫時沒有修改的打算。列印的最後打了點廣告，不知道會不會被罵得很慘^^;

　　還有網友建議做其他線，所以把連線連到台鐵的跨線查詢網頁去抓資料，不過還沒做轉車的設定，所以目前的跨線只能查詢
到直達車的資料。

　　另外在做跨日查詢時，會發現時間的表示多了一個＠號，那是為了給表格排序需要，沒什麼意義，應該不會造成太大困擾。

　　有什麼問題歡迎直接反映給我，有時間我會回信的，應該有不少使用者都知道我滿勤回信的:)

---

台鐵班車查詢系統 V0.9.5.18 說明
　　苦惱了很久，決定先放個小改版，算是督促一下自己不要再懶了，這次除了修正一些小問題，主要多了我的最愛還有增加系
統紀錄的實作，我想這是一個比較大的進步了，算是勉強交代得過去。

　　最近應該會再多個小改版是修改介面的部分，不過那算是個大工程，有空再說吧。資料庫應該是不會做了吧，因為那實在太
過於違背我的原則了。

　　還有這陣子台鐵常常出事情，搭火車的人大概少了很多吧，幸好我不靠這東西吃飯，越少人搭火車就越少人會想用這個小程
式了吧。

　　有問題可以直接到我的網頁留言給我，比方說需要什麼程式但是沒有相類似的軟體可以用或是軟體不好用的可以告訴我，要
是很多人有類似需求而我有興趣的話就會嘗試看看，或許又可以多造福一些朋友。

　　台鐵網頁修改了格式，造成上個小版本(0.9.5.17)系統出問題，我是很希望能夠直接進入台鐵的資料庫取資料，這樣的話可
以更加快速與方便整合資料呈現的方式，甚至可以做出更多不同的交叉查詢，不會像現在從台鐵的網頁作parsing，都得要擔心
哪天台鐵改個呈現格式就會造成查詢系統必須改版，不過直接進入資料庫這個希望應該是不可能實現了，畢竟沒有什麼背景或是
條件怎麼可能要台鐵開放讓一個沒沒無聞的小人物進去查詢重要的資料庫呢，所以還是只能想想而已啦:Q

---

台鐵班車查詢系統 V0.9.8.21 說明
　　呼～這次來了一次大翻修，整個系統都變了，希望有變得更加好用，多了加班車查詢，所以查詢的速度會稍微變慢，因為多
了兩次的下載網頁，除此以外，在速度上應該沒有掉太多才是。而且因為用了資料庫，離線查詢速度大概快了有60%以上。
　　
　　這次的改版我寫得相當快樂，快樂到想用"爽"來形容了，因為實在改得太多了，而且玩了很多實驗用的功能，像是壓縮的，
資料庫的，雖然有些最後都沒有放進來。但這些經驗讓我對系統的規劃更有心得，收穫實在不小。

　　新增的資料庫系統大概是最大的改變吧，因為不需要每次都做parsing html，查詢速度快了不少，而且也允許局部更新時刻
表，然而因為系統是屬於被動式的資料庫，用局部更新的話在資料的正確性上會有漏洞。所以也提供清除資料庫的功能，以確保
每次查詢到的資料都是最正確的。附上的資料庫是完整版，但是可能比較舊了，不過至少什麼車都查得到，這個資料庫可是整整
跑了三天才跑出來的。而因為這麼做會造成台鐵網站相當大的負擔，所以我把更新完整資料庫的功能鎖起來了，要用密技才可以
開啟XD。

　　至於剛剛提的的漏洞是什麼，就是當台鐵刪除火車資料的時候。為什麼？因為我們的資料是被動的，被動的意思也就是說新
增容易刪除難，也就是說本地端的資料有可能比台鐵的多，這樣就會造成班車資訊錯誤(明明就已沒有這班車但是卻查得到)，這
在加班車上最常見，而要知道哪些班車被拿掉只能做資料比對才會知道，但資料比對一做等於整個資料庫重建，那資料庫對於我
們只能被動而且部分地取得資料的情況下無用武之地。或許是我太笨，想不到更好的方法可以在這種情況下正確地更新資料庫。
知道怎麼做或是有什麼建議的朋友歡迎給我指教。

　　接下來除了一些大bug會修之外，這個系統應該不會再有太大的改版了吧，我想多花點心寫自己的遊戲了，希望這個系統能
繼續廣為流通，帶給更多人方便。當然我最希望的是台鐵能夠想辦法改善一下他的資料呈現方式，真的是太爛了:(

　　至於PDA版本，我想現在可以輸出成文字檔案或是CSV應該也有相關的軟體可以用來轉換或是傳到PDA上了吧。我上次試著把
查詢結果用文字檔傳到PDA，結果看起來還是有用，所以就暫時擱著囉。

　　大家有什麼意見還是可以到討論區跟我聊聊，我期待下次能介紹我的新遊戲。

---

台鐵班車查詢系統 V0.9.9.23 說明
　　哈哈，大家新年快樂，原本這個版本應該要在去年底放出來的不過台鐵網頁居然在元旦又做了修改，再加上我希望能讓使用者不
需要去選路線，所以多花了點時間弄。

　　說真的，台鐵實在很糟糕，新版的網頁唯一的一個優點是資料變整齊了。除此以外，查詢的速度變慢了，還有網頁不完整，不知
道大家會不會覺得很奇怪，我的版本裡居然有西部跨南迴的查詢，其實是台鐵本身資料庫有這些資料﹔好笑的是，他們的網頁居然沒
有做，只有西部跨東部的查詢，真是莫名其妙，台鐵我真是搞不懂你呀！

　　還有，其實要判斷兩個站是哪些路線並不難，大概只有台東要選從台北或是從高雄吧，我真的不了解為什麼不做，硬要讓使用者
在一堆的選項裡按來按去。既然我的資料來自台鐵，像我這樣的整合方式不是會讓使用者有比較大的方便嗎？比起資料庫來，這部分
的程式又不難寫，為什麼到現在還是一樣難用，甚至更難用，我真的搞不懂。

　　因為更新不少，沒辦法所有的站都測過，有問題就回報給我，希望大家使用愉快:)

---

台鐵班車查詢系統 V0.9.10.25 說明
　　這次的一點小改版，放上了票價查詢的部分，因為太多人反應了，因為更新不少，沒辦法所有的站都測過，有問題就回報給我，
希望大家使用愉快:)

懷念的change log

剛剛找時間翻了一下以前的東西..
看到了懷念的change log history檔....

想到以前跟台鐵的恩怨..促使了一支程式的誕生
也想到那時候有一群好可愛的使用者跟我的互動..
真的很懷念啊..

什麼時候還能有這樣的感動呢?

---

[版本修改0.9.9.23 -> 0.9.10.25]
F1. 票價顯示的問題
F2. 避免查詢台鐵的錯誤資料
A1. 票價的資料庫支援

[版本修改 0.9.8.21 -> 0.9.9.23]
F1. 修正:適應新版台鐵網頁
A1. 新增自動判斷路線
A2. 把票價放回來了
A3. 查詢 西部到南迴線的班車資料 (台鐵網頁居然沒有:D)

[版本修改 0.9.6.19 -> 0.9.8.21]
F1. 修正:文字大小導致的排版問題
F2. 站名部份, 台東新應該為台東, 台東和馬蘭兩站應刪除(已廢站)
F3. 修正:計算時間的錯誤
A1. 顯示各站編號
A2. 增加"時數"顯示, 即(到達時間-開車時間)
A3. 防火牆設定
A4. 支線(集集,平溪,內灣)查詢
A5. 全時段查詢(0~24)
A6. 外掛功能
A7. 不存檔功能
A8. 紀錄連線設定
A9. 加班車查詢
AX. 資料庫
D1. 拿掉票價表

[版本修改 0.9.5.18 -> 0.9.6.19]
F1. 嘗試修正:文字大小導致的排版問題
A1. 可調整的主視窗版面

[版本修改 0.9.5.17 -> 0.9.5.18]
F1. 修正:台鐵網頁修改格式造成查詢資料錯誤

[版本修改 0.9.4.15 -> 0.9.5.17]
F1. 修正:清單的字體在移動時會忽大忽小
F2. 修正:小修演算法讓處理速度快一點點
A1. 我的最愛
A2. 系統紀錄

[版本修改 0.9.3.14 -> 0.9.4.15]
F1. 修正:快車的最後一班查不到
F2. 修正:變更車站後標題列沒有跟著變
A1. 列印功能
A2. 跨線查詢
A3. 修改跨日查詢時時間排序方式
D1. 拿掉train.ini避免每次更版都會覆蓋到舊設定

[版本修改 0.9.2.10 -> 0.9.3.14]
D1. 拿掉自動撥號的功能讓相容性更大
[版本修改 0.9.1.9 -> 0.9.2.10]
A1. 可以做跨日查詢，ex: 23:00 ~ 02:00 (謝謝lusien網友的建議)

2004-12-04 與自己meeting後記

paper趕完了..proposal也還算順利..
完整版的Crit-Space當作是碩士論文的成品就夠了
是該想下一個階段的東西了....腳步可不能停下來啊

前幾天一直都在玩以前買的engine....才發現原來自己並沒有好好地弄個明白..差點白花錢了
這兩天開始持續在思考這樣的東西應用在VR上的可能性
當然也不是不可能..而且也是不難..
但是光只是把這樣的東西移植上去..有點無趣..也太容易了
CMU就做過把Unreal Engine 2弄成Urban Combat(都會戰鬥?)系統了..
所以別做這種事..那麼可能的方案就是
1. 不能光只是移植..完整的package才是對designer最有意義也最有用的
研究方向: An alternative process applied on digital media design
不過這樣的主題有點沒有吸引力..再看看..
2. 搭配不同的硬體..engine只做最後的visualization..
研究方向: interaction with virtual environment
這..有點遜ㄟ..並沒有比現階段更進一步..只是背後自己寫的部分用engine replace掉了..
有點走回頭路的感覺
3. 如果是focus在performance of visualization上..可能還ok吧..
研究方向: qualitive realtime-visualization
畢竟以現在看過的關於建築設計上視覺呈現的paper或是project....
realtime visualization算是還在很初期的階段..幾乎都是low poly
啊不過搞這個的話....勢必得犧牲人機互動上的努力了..再想想再想想....
對我的未來好處不多..對別人的好處比較多..哈哈

看來這個引擎在學術上的應用還有很大的空間..雖然看起來實在很炫
實在很想馬上用她來寫遊戲啊..T-T
先牛刀小試一下..找機會用他來秀Ando的房子好了..記得要跟@hno要貼圖....

---

原來想很久的視覺化程式設計軟體那麼早就開始有人在發展相關的研究了啊....
以前只看過labView實在太孤陋寡聞了..
不過很奇怪的是..他們多半比較注重algorithm的視覺化..
為什麼呢?
是因為演算法這部分是最抽象的關係吧..所以視覺化能有助於了解
那也好..反正我打算做的是logical thinking的visual development environment
以後還可以拿來當教材用..哈哈哈..
不過要拿什麼做呢?....
opengl? 以後可以嘗試3d的設計思考喔..
flash? 好做而且容易移到網頁上..但是就沒辦法compile啦
engine? 考慮中....不過不熟的話寫起來還挺累的
c? 有點醜..
java? 一樣的問題..沒辦法compile
啊..結合c跟flash好了..雖然是老梗不過畢竟是自己最拿手的把戲啊..哈哈哈哈

---

scope新增
Natural Programming
Haman-Centered Computing
Interactive Audience Participation

順便把proposal的review弄得更加完美..
給我95分我還不夠滿意..哼..因為上上次的大失敗..沒拿99分(他一定不會給100的..哈哈)實在不甘心..

---

DMK....ㄟ..每次都只有寫論文賽到很煩的時候才會想到他..
這個東西角色還真是尷尬..寫了有幫助..要寫卻很痛苦....
更尷尬的是..老師幫我放話說要寫了....
哈哈..還是寫吧

來排個下兩週priority吧.....
1. engine
2. VDE
3. DMK
4. proposal..要是被知道這個排最後老師下次大概會釘死我吧....f-_-

唉..加上其他跟別人有關的雜事..還是閒不下來啊
CG&A, A&B, NCHC, HCII

--會議完畢

DMK的進展

進行DMK(Digital Media Knowledge-base)已經有一段時間了..
雖然現在已經寫了一個小程式在做bibliography的排版..
不過離我理想的full automation還有一段距離啊

主要就是出現了一些option..讓我不知不覺猶豫起來
1.
偶然發現原來Acrobat本身就有撰寫review的能力..也可以對文件的內容直接highlight
而且透過線上分享就可以synchronize每個人寫的review
實在是一個相當完整的作筆記功能
正在思考要不要乾脆利用這點..直接把一些心得寫進pdf檔裡?
然後用分享的方式共享..而不需要另外建資料庫....
這還得看PHP對pdf的處理能力有沒有到這麼detail的地步
就現在所知道..php處理pdf裡頭table跟image的功能似乎還有缺陷..
這是值得懷疑的

2.
困擾很久的問題....究竟要寫成web application....還是寫成distributed application?
distributed application有好處..可以直接使用Acrobat SDK..功能當然最強
缺點就是使用者必須有裝acrobat....
web application好處是直接上網就可以執行..很方便
缺點當然就是相對的要看php的支援能力..印象中是比較差了....

3.
最麻煩的就是..讀檔以及分析
各種不同的manuscript差異還真大....
即使來自同一個source..不同作者寫起來也不一樣...這還真是ooxx....
像是CG&A的abstract就常常找不到寫在哪裡..這要怎麼parse?
要做到full automation當然是讓使用者直接上傳pdf檔..然後分析產生資料庫檔案..快速方便
不過這部分的執行顯然會是個大麻煩
比較壞的打算就是大家自己key資料..不過這麼一來就會有多一次的人為疏失....
key錯怎麼辦..一點小小的打字錯誤就可能出現duplicate資料....
要分析paper就會有問題..尤其是要找key paper這件事情上....

遇到了三個選擇....要進行下去只能先暫定三個答案
1. 用PHP....翻過了Acrobat SDK的文件....看起來用起來並不怎麼甜....
2. 傾向web application....
3. automation還是要做....不過要做的話勢必會卡很久

另外就是要先把 php跟帳號整合的那部分先試看看....
老師有說用.access就可以..應該先試著玩看看

解脫?

終於送走了....雖然還不知道會不會因為慢了幾個小時而被reject....

但總是送走了....

我也終於可以從連續熬夜的無間地獄中解脫了....

而在這值得紀念的一刻..我只想說幾句話....

Acrobat妳可以再爛一點....
要不是為了妳轉檔老是轉失敗..
我就不用為了重新畫圖忙到翻了....

把我沒睡到覺的夜晚跟傷亡慘重的頭髮還來啊～～