BIM 시장이 커지면서 BIM 관련 소프트웨어도 다양해지고, 작성 툴 또한 기능이 많아지고 있습니다. 자연스럽게 클라이언트들의 요구가 많아지면서 BIM에서 표현해야할 내용들도 더 많아졌습니다. 그만큼 작업량도 늘어나면서 3D CAD 프로그램이나 BIM 작성 툴에서 작업시간을 단축시키기 위한 수단을 제공하는 경우도 많아졌습니다.
Rhino - Grasshopper
Revit - Dynamo
Unity - Visual Scripting (출처 : Unity Learn)
위와 같은 Visual Programming 이외에도 직접 사용자가 기능을 만들 수 있도록 API를 제공하는 등의 방식으로 작업의 시간을 단축시킬 수 있는 수단들이 있습니다.
다만 제가 직접 Grasshopper, Dynamo를 사용하면서 한계를 느낀 부분들이 있었고, 이로인해 직접 애드인을 만들 수 있는 단계로 나아갔습니다.
1. 제한적인 UX
- 변수의 지정 (3D 오브젝트, 불러온 파일 등)을 미리 설정한 후 한번에 실행하는 방식으로 인해, 사용자가 의도하지 않은 방식으로 사용하는 것을 제한하기 힘들었습니다.
2. 조건문, 반복문 사용에서의 제약
- if문 등에 대한 기본 컴포넌트를 제공을 하지만, 데이터 구조 (1차원, 2차원 배열 등)를 비교대상끼리 일치시켜 주는 등 자료구조적 문제를 직관적으로 해결할 수 있도록 되어있지는 않았습니다.
- 반복문은 기본으로 제공하는 컴포넌트 중 Python 스크립트를 이용하는 방식으로 할 수는 있지만, 해당 스크립트 컴포넌트 창을 열어서 확인하기 전까지는 내부구조를 바로 볼 수 없었습니다.
3. 테스트 및 유지보수시 편의성
- 물론 코드가 익숙하지 않은 사람들은 Visual Scripting이 더 편할 수 있지만, 코드를 직접 짜는것에 익숙해진 지금은 Git을 이용하여 애드인의 변경사항을 관리하거나, 애드인 실행 로그를 따로 저장해 두는 등의 방식으로 관리하는 것이 더 편하게 느껴집니다.
4. 성능
- 같은 기능을 Visual Scripting 방식, API를 활용한 프로그래밍 방식 둘다로 했을 때 API로 실행한 것이 결과물을 훨씬 빨리 반환하였습니다.
물론 기본제공 컴포넌트나 Python, C#등의 스크립트를 이용하여 Windows Forms 를 호출하는 등의 행위나 객체지향 기법을 적용하는 것이 가능할 수는 있지만, 이미 그정도로 활용할 수 있는 사람이라면 직접 API를 활용하여 애드인을 만드는게 더 빠를 수도 있다고 생각합니다. 또한 최근의 개발도구는 코드만 짜도 미리 오류가 나는부분을 많이 잡아주고, 디버깅을 통해 구체적으로 어느부분에서 코드의 예외가 발생하는지 찾을 수 있도록 되어있는 등 개발의 편의를 위한 기능이 많이 제공됩니다.
지금까지 제가 API를 활용하는 단계로 나아간 이유를 설명드렸습니다. 평소 API에 관심이 많아 직접 애드인을 만들어보고는 싶지만 C#을 배우는 것에 엄두가 나지 않았던 분들, 그리고 자료를 쉽게 찾을 수 없어 포기하셨던 분들을 위해서 Revit API에 대한 강의를 시작하고자 합니다.
강의는 크게 5개의 챕터로 구성될 예정입니다.
- 개발환경 설정 및 C# 기초 문법, Windows Forms 기초
- API를 보는 방법과 기본 기능 활용하기
- Windows Forms를 활용하여 GUI 구성하기
- 프로젝트 예제
- 심화편 (Google Firebase, 타 프로그램과 연동하기, DBMS 사용하기 등)
타 프로그램과의 연동 중 "Excel 데이터를 불러오기"와 같은 자주쓰는 프로그램과의 연동은 심화편 이전에 2~4에서도 다룰 예정입니다.
