입문서의 이 부분은 "모범 사례" 형식으로 구성되어 있습니다. 여기에서는 품질 파라메트릭 워크플로우에 가장 도움이 되는 경험과 연구를 통해, 학습한 몇 가지 전략에 대해 설명합니다. 디자이너 및 프로그래머 입장에서 품질 메트릭은 주로 유지보수 용이성, 신뢰성, 유용성, 도구 효율성 등과 관련이 있습니다. 이러한 모범 사례에는 시각적 또는 텍스트 기반 스크립팅에 대한 구체적인 예가 포함되어 있지만, 기본 원칙은 모든 프로그래밍 환경에 적용될 수 있으며 많은 계산 방식 워크플로우의 기초를 이룰 수 있습니다.
시각적 프로그래밍 프로세스 내에서 작업하는 것은 유용한 크리에이티브 활동일 수 있지만, 작업공간의 복잡성 및/또는 배치 때문에 프로그램 흐름과 핵심 사용자 입력이 빠르게 가려질 수 있습니다. 프로그램 관리를 위한 몇 가지 모범 사례를 살펴보겠습니다.
작업공간에 여러 개의 노드를 추가했으면 명확성을 위해 노드의 배치를 재구성하려고 할 수 있습니다. 둘 이상의 노드를 선택하고 작업공간을 마우스 오른쪽 버튼으로 클릭하면 팝업 창에는 X 및 Y에 맞춤 및 분배 옵션이 있는 선택 항목 정렬 메뉴가 표시됩니다.
둘 이상의 노드를 선택합니다.
작업공간을 마우스 오른쪽 버튼으로 클릭합니다.
선택 항목 정렬 옵션을 사용합니다.
일부 환경에서는 노드 이름을 검토하고 프로그램 흐름에 따라 시각적 프로그램을 "읽을 수" 있습니다. 다양한 경험을 갖춘 사용자들을 위해 일반 언어 레이블과 설명을 추가하는 것도 좋은 방법입니다. Dynamo에는 이 작업을 위해 편집할 수 있는 텍스트 필드가 있는 Notes 노드가 제공됩니다. 다음 두 가지 방법으로 작업공간에 참고 사항을 추가할 수 있습니다.
편집 > 참고 만들기 메뉴로 이동합니다.
키보드 바로 가기 Ctrl+W를 사용합니다.
참고 사항이 작업공간에 추가되면 텍스트 필드가 팝업되어 참고 사항의 텍스트를 편집할 수 있습니다. 작성한 후에는 Note 노드를 두 번 클릭하거나 마우스 오른쪽 버튼으로 클릭하여 참고 사항을 편집할 수 있습니다.
시각적 프로그램의 규모가 커지면 실행될 더 큰 단계를 정해 두는 것이 도움이 됩니다. 더 큰 노드 모음을 그룹으로 강조 표시하고 배경 및 제목에 색상 직사각형을 사용하여 레이블을 지정할 수 있습니다. 다음 세 가지 방법으로 둘 이상의 노드를 선택하여 그룹을 만들 수 있습니다.
편집 > 그룹 만들기 메뉴로 이동합니다.
키보드 바로 가기 Ctrl+C를 사용합니다.
작업공간을 마우스 오른쪽 버튼으로 클릭하고 "그룹 작성"을 선택합니다.
그룹이 작성되면 제목, 색상 등의 설정을 편집할 수 있습니다.
팁: 파일에 주석을 달고 가독성을 높이기 위해서는 참고와 그룹을 둘 다 사용하는 것이 효과적입니다.
다음은 참고와 그룹이 추가된 프로그램의 예입니다.
참고: "그리드 매개변수"
참고: "그리드 점"
그룹: "점 그리드 작성"
그룹: "어트랙터 점 작성"
참고: "거리 값 보정"
참고: "원의 가변 그리드"
시각적 스크립팅 환경 내의 텍스트 기반 스크립팅을 활용하면 DesignScript, Python, ZeroTouch(C#)를 사용하여 강력한 시각적 관계를 사용할 수 있습니다. 사용자는 입력 슬라이더와 같은 요소를 노출시키고, 대규모 작업을 DesignScript로 압축하며, 동일한 작업공간 내에서 Python 또는 C#을 통해 강력한 도구 및 라이브러리에 액세스할 수 있습니다. 효과적으로 관리할 경우 이러한 전략을 결합하면 전체 프로그램에 대해 사용자화 사용 가능성, 명확성 및 효율성을 많이 향상할 수 있습니다. 아래에는 텍스트 스크립트를 사용하여 시각적 스크립트를 보강하는 데 도움이 되는 일련의 지침이 나와 있습니다.
텍스트 스크립팅의 경우 시각적 프로그래밍보다 더 복잡한 관계를 설정할 수 있지만 그와 겹치는 기능도 많습니다. 노드가 효과적으로 사전에 패키지된 코드이고, 전체 Dynamo 프로그램을 DesignScript 또는 Python으로 작성할 수 있기 때문에 그렇습니다. 그러나 노드와 와이어의 인터페이스에서 그래픽 정보의 직관적인 흐름을 작성하므로 우리는 시각적 스크립팅을 사용합니다. 텍스트 스크립팅의 기능이 시각적 스크립팅보다 유용한 지점을 알면 노드와 와이어의 직관적인 특성을 포기하지 않고 이 기능을 사용해야 하는 경우에 대한 중요한 단서를 얻게 될 것입니다. 아래에는 스크립팅해야 하는 경우와 사용해야 하는 언어에 대한 지침이 나와 있습니다.
텍스트 스크립팅의 목적:
루핑
재귀
외부 라이브러리에 액세스
언어 선택:
각 Dynamo 라이브러리에서 액세스 가능한 리스트를 보려면 스크립팅 참조를 참조하십시오.
필연적으로 파라메트릭 환경인 Dynamo에서 스크립팅할 경우 코드가 상주할 노드 및 와이어의 프레임워크를 기준으로 코드를 구성하는 것이 좋습니다. 텍스트 스크립트가 포함된 노드는 소수의 특정 입력, 함수 및 예상 출력이 있는 프로그램의 다른 노드처럼 생각하십시오. 그러면 즉시 해당 노드 내의 코드에 작은 변수 세트가 포함되어 작동하게 되며, 이것이 깔끔한 파라메트릭 시스템의 열쇠입니다. 아래에는 코드를 시각적 프로그램에 보다 효율적으로 통합하기 위한 몇 가지 지침이 나와 있습니다.
외부 변수 식별하기:
해당 데이터를 직접 작성하는 모델을 구성할 수 있도록 설계 문제에서 지정된 매개변수를 확인해 보십시오.
코드를 작성하기 전에 다음 변수를 식별하십시오.
최소한의 입력 세트
의도한 출력
상수
몇 가지 변수는 코드를 작성하기 전에 설정되어 있습니다.
강우를 시뮬레이션할 표면
기본 빗방울 수(에이전트)
기본 빗방울 이동 거리
가장 가파른 경로를 내려가는 경우와 표면을 횡단하는 경우 간의 전환
Python 노드(각 입력 수 포함)
반환된 곡선을 파란색으로 만드는 Code Block
내부 관계 설계하기:
매개변수화를 사용하면 방정식 또는 시스템의 최종 결과를 조작하거나 변경하기 위해 특정 매개변수 또는 변수를 편집할 수 있습니다.
스크립트의 엔터티가 논리적으로 관련된 경우 항상 서로의 함수로 정의하십시오. 이렇게 하면 하나가 수정되는 경우 나머지 요소가 비례적으로 업데이트될 수 있습니다.
다음과 같이 키 매개변수를 노출하는 방식으로만 입력 수를 최소화합니다.
매개변수 세트를 더 많은 상위 매개변수에서 파생할 수 있는 경우 상위 매개변수만 스크립트 입력으로 노출합니다. 그러면 인터페이스의 복잡성이 줄어들어 스크립트의 가용성이 높아집니다.
Python 노드 내 예시의 코드 "모듈"은 다음과 같습니다.
입력
스크립트 내부의 변수
이러한 입력 및 변수를 사용하여 해당 함수를 수행하는 루프
팁: 솔루션에서처럼 과정에 최대한 중점을 두십시오.
스크립트에서 동일한 항목을 표현할 방법이 여러 가지 있는 경우 어느 시점에 중복 표현이 동기화되지 않아 유지보수 문제, 공통 분할 불량, 내부 모순이 초래될 수 있습니다.
DRY 원칙에 따르면 "모든 지식은 시스템 내에서 단일하고, 명백하며, 권위 있게 표현되어야 합니다."
이 원칙이 제대로 적용되면 스크립트의 모든 관련 요소가 예측 가능한 방식으로 균일하게 변경되고, 모든 관련 없는 요소가 서로 간에 논리적인 결과를 일으키지 않습니다.
팁: 스크립트에서 엔터티(위 예에서는 상수)를 복제하기 전에 소스에 링크할 수 있는지에 대해 자문해 보십시오.
코드가 점점 길어지고 복잡해짐에 따라 “중요한 아이디어”나 매우 중요한 알고리즘은 점점 더 읽기 어려워집니다. 또한 어떤 특정 상황이 어디에서 발생하는지 추적하거나, 문제가 발생하는 경우 버그를 찾거나, 다른 코드를 통합하거나, 개발 작업을 지정하기가 더욱 어려워집니다. 이러한 문제를 방지하기 위해 실행하는 작업에 따라 코드를 분할하는 구성 전략으로, 모듈에서 코드를 작성하는 것이 좋습니다. 다음은 모듈화 방식으로 스크립트를 보다 쉽게 관리할 수 있는 몇 가지 팁입니다.
모듈에 코드 작성하기:
"모듈"은 작업공간의 Dynamo 노드와 유사하게 특정 작업을 수행하는 코드 그룹입니다.
인접 코드(함수, 클래스, 입력 그룹 또는 가져오고 있는 라이브러리)와 시각적으로 분리해야 하는 무엇이든 모듈이 될 수 있습니다.
모듈에서 코드를 개발하면 시각적이고 직관적인 품질의 노드뿐만 아니라 텍스트 스크립팅에서만 가능한 복잡한 관계도 활용할 수 있습니다.
이러한 루프에서는 우리가 연습에서 개발할 "agent"라는 클래스를 호출합니다.
각 에이전트의 시작점을 정의하는 코드 모듈
에이전트를 업데이트하는 코드 모듈
에이전트 경로에 대한 트레일을 그리는 코드 모듈
코드 재사용 발견하기:
코드가 두 곳 이상에서 같은(또는 매우 유사한) 작업을 수행하는 것을 발견한 경우 호출할 수 있는 함수로 클러스터링할 방법을 찾으십시오.
“관리자” 함수는 프로그램 흐름을 제어하며, 주로 구조 간 데이터 이동과 같은 낮은 레벨의 세부 정보를 처리하는 “작업자” 함수에 대한 호출을 포함합니다.
이 예시에서는 중심점의 Z 값을 기준으로 반지름과 색상을 사용하여 구를 작성합니다.
"작업자" 상위 함수 두 개: 반지름이 있는 구를 작성하고 중심점의 Z 값을 기준으로 색상을 표시하는 함수.
두 작업자 함수를 결합하는 "관리자" 상위 함수. 이를 호출하면 내부의 두 함수가 모두 호출됩니다.
확인해야 할 사항만 표시하기:
모듈 인터페이스에는 모듈에서 제공하거나 요구하는 요소가 나타납니다.
단위 간의 인터페이스가 정의되면 각 단위의 세부 설계를 별도로 진행할 수 있습니다.
분리 가능성/대치 가능성:
모듈에서는 서로에 대해 잘 모르거나 상관하지 않습니다.
모듈화의 일반적인 형태:
코드 그룹화:
함수:
클래스:
Dynamo에서 텍스트 스크립트를 개발하는 동안 실제로 작성되는 것이 기대하는 바와 일치하는지 지속적으로 확인하는 것이 좋습니다. 그러면 예기치 못한 이벤트(구문 오류, 논리 불일치, 부정확한 값, 이상 출력 등)를 신속하게 검색해 마지막에 한 번에 처리하는 대신 나타날 때 즉시 처리합니다. 텍스트 스크립트는 캔버스의 노드 내에 있으므로 시각적 프로그램의 데이터 흐름에 이미 통합되어 있습니다. 따라서 출력할 데이터를 지정하고, 프로그램을 실행하고, Watch 노드를 사용하여 스크립트에서 흐름 상태를 평가하는 것처럼 간단하게 연속적 스크립트 모니터링을 수행할 수 있습니다. 다음은 스크립트를 구성할 때 지속적으로 검사할 수 있는 몇 가지 팁입니다.
진행하면서 테스트하기:
기능 클러스터를 완료할 때마다 다음을 수행합니다.
이전 단계로 이동하여 코드를 검사합니다.
엄격하게 확인합니다. 공동작업자가 이 작업이 무엇인지 이해할 수 있는가? 이 작업을 수행할 필요가 있는가? 이 기능을 보다 효율적으로 수행할 수 있는가? 불필요한 중복이나 의존성을 작성하고 있는가?
빠르게 테스트하여 "타당한" 데이터가 반환되는지 확인합니다.
다음과 같이 스크립트가 업데이트되면 노드에서 항상 관련 데이터를 출력하도록 스크립트에서 작업 중인 최신 데이터를 출력으로 지정합니다.
솔리드의 모든 모서리가 곡선으로 돌아가 경계 상자를 작성하는지 확인합니다.
개수 입력이 범위로 변환되는지 확인합니다.
이 루프에서 좌표계가 제대로 변환되고 회전되었는지 확인합니다.
"극단적인 경우" 예상하기:
스크립팅하는 동안 할당된 도메인의 최솟값 및 최댓값에 입력 매개변수를 크랭크하여 프로그램이 극단적인 조건에서도 계속 작동하는지 확인합니다.
프로그램이 극단적인 조건에서 작동하더라도 의도하지 않은 null/공백/0 값을 반환하는지 확인합니다.
어떤 경우에는 몇몇 스크립트 관련 기본 문제를 나타내는 버그와 오류가 이러한 극단적인 경우에만 드러납니다.
오류의 원인을 파악한 다음 문제를 방지하려면 내부적으로 수정해야 할지 아니면 매개변수 도메인을 다시 정의해야 할지를 결정합니다.
팁: 항상 사용자가 자신에게 표시된 모든 입력 값의 모든 조합을 사용한다고 가정하십시오. 그러면 원치 않는 갑작스러운 상황이 발생하지 않습니다.
디버깅은 스크립트에서 "버그"를 제거하는 프로세스입니다. 버그는 오류, 비효율성, 부정확성 또는 예상치 못한 결과일 수 있습니다. 버그는 스크립트를 사용하여 철자가 잘못된 변수 이름을 보다 널리 퍼진 구조적 문제로 수정하는 것처럼 간단하게 해결할 수 있습니다. 스크립트를 만들면서 조정하면 버그가 완전히 없어진다는 보장은 없지만 이러한 잠재적 문제를 조기에 포착할 수 있습니다. 아래에는 버그를 체계적으로 해결하는 데 도움이 되는 몇 가지 모범 사례를 검토한 내용이 나와 있습니다.
Watch 풍선 사용하기:
프로그램 조정이라는 개념과 유사하게 OUT 변수에 데이터를 지정하여 코드의 여러 위치에서 반환되는 데이터를 확인합니다.
의미 있는 주석 작성하기:
의도한 결과를 명확하게 설명하면 코드 모듈을 디버깅하기가 훨씬 쉽습니다.
이 경우 일반적으로 주석과 빈 줄이 과도하게 많아지지만, 디버깅할 때 주석 내용을 관리 가능한 여러 부분으로 나누면 유용할 수 있습니다.
코드의 모듈성 활용하기:
문제의 소스는 특정 모듈로 격리할 수 있습니다.
잘못된 모듈을 식별하고 나면 문제를 훨씬 더 간단하게 해결할 수 있습니다.
프로그램을 수정해야 하는 경우 모듈에서 개발된 코드는 다음과 같이 훨씬 더 쉽게 변경할 수 있습니다.
새 모듈 또는 디버깅된 모듈을 기존 프로그램에 삽입할 수 있으며, 삽입하더라도 프로그램의 나머지 부분은 변경되지 않습니다.
Python 노드에서의 예시 파일 디버깅은 다음과 같습니다.
입력 형상에서 형상 자체보다 큰 경계 상자를 반환합니다. 이는 xDist 및 yDist를 OUT에 지정하면 볼 수 있습니다.
입력 형상의 모서리 곡선에서 xDist 및 yDist에 대해 올바른 거리로 적절한 경계 상자를 반환합니다.
xDist 및 yDist 값 문제를 해결하기 위해 삽입한 코드 "모듈"입니다.
아래 링크를 클릭하여 예제 파일을 다운로드하십시오.
전체 예시 파일 리스트는 부록에서 확인할 수 있습니다.
텍스트 스크립팅의 모범 사례를 고려하여 비 시뮬레이션 스크립트를 작성해 보겠습니다. 그래프 전략에서 체계적이지 않은 시각적 프로그램에 모범 사례를 적용할 수 있었지만 그렇게 하는 것은 텍스트 스크립팅을 사용하는 것보다 훨씬 더 어렵습니다. 텍스트 스크립팅에서 설정한 논리적 관계는 가시성이 낮아 복잡한 코드에서는 풀기가 거의 불가능할 수 있습니다. 텍스트 스크립팅의 기능을 사용하면 조직의 책임이 더 커집니다. 각 단계를 살펴보고 그 과정에서 모범 사례를 적용해 보겠습니다.
우리의 스크립트는 어트랙터가 변형된 표면에 적용됩니다.
가장 먼저 해야 할 작업은 필요한 Dynamo 라이브러리를 가져오는 것입니다. 먼저 이렇게 하면 Python에서 Dynamo 기능에 전역적으로 액세스할 수 있게 됩니다.
사용하려는 모든 라이브러리를 여기로 가져와야 합니다.
다음으로, 스크립트의 입력과 출력을 정의해야 합니다. 이는 노드에서 입력 포트로 표시됩니다. 이러한 외부 입력이 스크립트의 토대가 되고 파라메트릭 환경을 설정하는 열쇠가 됩니다.
Python 스크립트에서 변수에 해당하는 입력을 정의하고 원하는 출력을 결정해야 합니다.
우리가 걸어갈 표면
우리가 걷게 할 에이전트의 수
에이전트가 걸을 수 있는 최대 걸음 수
표면 아래로 최단 경로를 택하거나 횡단할 수 있는 옵션
스크립트의 입력(IN[0], IN[1])에 해당하는 입력 식별자가 있는 Python 노드
다른 색상으로 표시할 수 있는 출력 곡선
이제 모듈성 실습을 이용하여 스크립트 본문을 작성해 보겠습니다. 여러 시작점에 대해 표면 아래의 최단 경로를 시뮬레이션하는 것은 여러 함수가 필요한 중대한 작업입니다. 스크립트 전체에서 다른 함수를 호출하는 대신 이를 단일 클래스인 당사의 에이전트로 수집하여 코드를 모듈화할 수 있습니다. 이 클래스 또는 "모듈"의 여러 함수는 다른 변수를 사용하여 호출하거나 다른 스크립트에서 재사용할 수도 있습니다.
한 걸음씩 걸을 때마다 가능한 가장 가파른 방향으로 이동하도록 선택하여 표면을 걷게 하려는 에이전트에 대해 다음과 같은 클래스 또는 청사진을 정의해야 합니다.
이름
모든 에이전트가 공유하는 전역 속성
각 에이전트마다 고유한 인스턴스 속성
걷게 하는 함수
각 걸음의 위치를 트레일 리스트로 카탈로그화하는 함수
시작 위치를 정의하여 에이전트를 초기화하겠습니다. 이는 스크립트를 조정하고 에이전트 클래스가 제대로 작동하는지 확인할 수 있는 좋은 기회입니다.
표면을 걷는 것을 관찰하고 해당 초기 속성을 정의하려는 모든 에이전트를 인스턴스화해야 합니다.
비어 있는 새 트레일 리스트
표면에서 여정을 시작할 위치
여기서 스크립트가 반환하는 결과를 확인하기 위해 에이전트 리스트를 출력으로 지정했습니다. 올바른 수의 에이전트가 반환되지만, 반환되는 형상을 확인하려면 나중에 스크립트를 다시 조정해야 합니다.
각 단계에서 각 에이전트를 업데이트합니다. 그런 다음 내포된 루프를 입력해야 합니다. 여기서 각 에이전트와 각 걸음에 대해 해당 위치를 업데이트하고 해당 트레일 리스트에 기록합니다. 또한 걸음마다 에이전트가 표면에서 한 걸음 더 내디뎌서 내려갈 수 없는 지점에 도달하지 않았는지 확인합니다. 그러한 조건이 충족되면 해당 에이전트의 여정이 종료됩니다.
에이전트가 완전히 업데이트되었으므로 이들을 나타내는 형상을 반환해 보겠습니다. 모든 에이전트가 하강 제한 또는 최대 걸음 수에 도달한 후, 해당 트레일 리스트의 지점을 통해 polycurve를 작성하고 polycurve 트레일을 출력합니다.
가장 가파른 경로를 찾는 스크립트입니다.
기본 표면의 강우를 시뮬레이션하는 사전 설정입니다.
가장 가파른 경로를 찾는 대신 기본 표면을 횡단하도록 에이전트를 전환할 수 있습니다.
전체 Python 텍스트 스크립트입니다.
이 참조 페이지에서는 코드 라이브러리, 레이블 지정 및 스타일 지정에 대한 보다 자세한 내용을 통해 스크립팅 전략에서 다루는 모범 사례를 확장합니다. 아래에서는 Python을 사용하여 개념을 설명할 텐데, 동일한 원칙이 Python 및 C#(Zerotouch)에도 적용되지만 이때 구문은 다릅니다.
표준 라이브러리는 Dynamo 외부에 있으며 프로그래밍 언어 Python 및 C#(Zerotouch)에 있습니다. Dynamo에는 노드 계층에 바로 해당되는 고유한 라이브러리 세트도 있으므로, 사용자는 노드 및 와이어로 만들 수 있는 모든 요소를 코드에서 만들 수 있습니다. 아래에는 각 Dynamo 라이브러리를 통해 액세스할 수 있는 항목과 표준 라이브러리를 사용해야 하는 경우에 대한 지침이 나와 있습니다.
표준 라이브러리 및 Dynamo 라이브러리
Python 및 C#의 표준 라이브러리를 사용하여 Dynamo 환경에서 고급 데이터 및 흐름 구조를 만들 수 있습니다.
Dynamo 라이브러리는 형상 및 기타 Dynamo 객체를 작성하기 위한 노드 계층 구조에 바로 해당됩니다.
Dynamo 라이브러리
ProtoGeometry*
기능: 호, 경계 상자, 원, 원추, 좌표계, 직육면체, 곡선, 원통, 모서리, 타원, 타원 호, 면, 형상, 나선, 색인 그룹, 선, 메쉬, NURBS 곡선, NURBS 표면, 평면, 점, 다각형, 직사각형, 솔리드, 구, 표면, 위상, TSpline, UV, 벡터, 정점
가져오는 방법: import Autodesk.DesignScript.Geometry
``
DSCoreNodes
기능: 색상, 색상 범위 2D, 날짜 시간, 시간 간격, IO, 수식, 논리, 리스트, 수학, 쿼드 트리, 문자열, 스레드
가져오는 방법: import DSCore
테셀레이션
기능: 볼록 헐, Delaunay, Voronoi.
가져오는 방법: import Tessellation
DSOffice
기능: Excel
가져오는 방법: import DSOffice
*주: Python 또는 C#을 통해 ProtoGeometry를 사용할 때 비관리형 객체를 작성하는 경우에는 해당 메모리를 수동으로 관리해야 합니다. 자세한 내용은 아래의 비관리형 객체 섹션을 참고하십시오.
스크립팅하는 동안 우리는 변수, 유형, 함수, 기타 도면요소 등을 나타내기 위해 끊임없이 식별자를 사용합니다. 이러한 기호 표기 체계를 통해 알고리즘을 만들면 일반적으로 일련의 문자로 구성되어 있는 레이블을 통해 정보를 편리하게 참조할 수 있습니다. 명명 작업은 나중에 자신 및 다른 사람이 쉽게 읽고 이해할 수 있는 코드를 작성하는 데 매우 중요한 역할을 합니다. 다음은 스크립트에서 항목을 명명할 때 기억해야 할 몇 가지 팁입니다.
약어를 사용해도 좋지만 해설에 약어에 대한 설명을 포함합니다.
중복된 레이블을 지정하지 않도록 합니다.
변수 이름에는 부정 논리 대신 긍정 논리를 사용합니다.
기본적으로 "역방향 표기"를 사용합니다.
이 방식이 구조적 측면에서 좀 더 적합합니다.
별칭을 사용하여 지나치게 길고 자주 반복되는 체인을 줄입니다.
별칭을 지정하면 곧 매우 혼란스러운 비표준 프로그램이 작성될 수 있습니다.
필요한 단어만 사용합니다.
“모든 것은 가능한 한 간단하게 만들어야 하지만, 너무 간단해서는 안 된다.” - 알버트 아인슈타인
일반적으로, 프로그래밍 방법에는 몇 가지가 있습니다. 따라서 "개인적인 스크립팅 스타일"이란 자신이 도중에 수없이 많은 작은 결정을 선택하거나 선택하지 않은 결과입니다. 즉, 코드의 가독성과 유지 관리성은 내부 일관성과 일반적인 스타일 규칙 준수에 따른 직접적인 결과입니다. 경험상, 두 위치에서 동일하게 보이는 코드는 동일하게 작동합니다. 다음은 명확하고 일관된 코드를 작성하기 위한 몇 가지 팁입니다.
명명 규칙: 코드의 각 엔티티 유형에 대해 아래의 규칙 중 하나를 선택하고 선택한 규칙을 준수하십시오.
변수, 함수, 메서드, 패키지, 모듈:
lower_case_with_underscores
클래스 및 예외:
CapWords
보호된 메서드 및 내부 함수:
_single_leading_underscore(self, ...)
전용 메서드:
__double_leading_underscore(self, ...)
상수:
ALL_CAPS_WITH_UNDERSCORES
팁: 단일 문자 변수(예: l, O, I)는 바로 앞의 컨텍스트에서 의미가 명확하게 드러나는 아주 짧은 블록을 제외하고는 사용하지 마십시오.
빈 줄 사용:
최상위 함수와 클래스 정의를 두 개의 빈 줄로 묶습니다.
클래스 내부의 메서드 정의는 1개의 빈 줄로 묶습니다.
드문 경우지만 빈 줄을 추가로 사용하여 관련 함수의 그룹을 구분할 수 있습니다.
불필요한 공백 방지:
괄호, 대괄호 또는 중괄호의 안:
쉼표, 세미콜론 또는 콜론의 바로 앞:
함수 호출의 인수 리스트가 시작되는 여는 괄호의 바로 앞:
색인화 또는 분할이 시작되는 여는 괄호의 바로 앞:
항상 이러한 바이너리 연산자 한쪽에 1개의 공백을 둡니다.
줄 길이 감시:
79자만 넘지 않으면 됩니다.
필요한 편집기 창의 폭을 제한하면 여러 파일을 나란히 열어 둘 수 있으며, 이 방법은 인접한 열에 두 버전이 있는 코드 검토 도구를 사용할 때 유용합니다.
긴 줄의 경우 표현식을 괄호로 묶어 여러 줄로 나눌 수 있습니다.
명백한 내용으로 중복되는 해설 방지:
해설이 적어야 코드를 읽기 쉬운 경우도 있습니다. 특히 의미 있는 기호 이름을 대신 사용해야 하는 경우 더욱 그렇습니다.
좋은 코딩 습관을 들이면 해설에 대한 의존도가 줄어듭니다.
팁: 해설에서는 이유를 알려주고 코드에서는 방법을 알려줍니다.
오픈 소스 코드 확인:
오픈 소스 프로젝트는 많은 개발자가 함께 만드는 것입니다. 이러한 프로젝트는 팀이 가능한 한 효율적으로 함께 작업할 수 있도록 높은 수준의 코드 가독성을 유지해야 합니다. 따라서 해당 프로젝트의 소스 코드를 살펴보면서 이러한 개발자들이 어떤 작업을 하고 있는지 관찰하는 것이 좋습니다.
규칙 개선:
각 규칙이 현재의 필요에 맞게 작동하고 있는지를 질문합니다.
기능/효율성이 저하되고 있습니까?
Zerotouch용 C#을 작성하고 Dynamo에 기여하기 위한 지침을 보려면 다음과 같은 Wiki 페이지를 확인하십시오.
비관리형 객체:
그래프로 반환하지 않거나 참조를 저장하지 않는 비관리형 리소스만 제거하면 됩니다. 이 섹션의 나머지 부분에서는 이러한 객체를 중간 형상 이라고 부르겠습니다. 아래의 코드 예시에서는 이 객체 클래스의 예를 확인할 수 있습니다. 이 zero touch C# 함수 singleCube는 단일 정육면체를 반환하지만 실행 중에 10,000개의 추가 정육면체를 작성합니다. 이러한 다른 형상이 중간 구성 형상으로 사용된 것처럼 가장할 수 있습니다.
이 zero touch 함수는 Dynamo와 충돌할 가능성이 높습니다. 10,000개의 솔리드를 작성했지만 그중 하나만 저장하고 반환했습니다. 대신, 반환하는 항목을 제외한 모든 중간 정육면체를 제거해야 합니다. 반환하는 항목은 그래프로 전파되어 다른 노드에서 사용되므로 제거하지 않을 것입니다.
수정된 코드는 다음과 같습니다.
일반적으로 Surfaces
, Curves
및 Solids
과 같은 형상만 제거하면 됩니다. 그러나 안전을 위해 모든 형상 유형(Vectors
, Points
, CoordinateSystems
)을 제거할 수 있습니다.
이 장의 앞부분에서는 Primer를 통해 Dynamo의 강력한 시각적 스크립팅 기능을 구현하는 방법에 대해 다루었습니다. 이러한 기능에 대한 충분한 이해는 견고한 시각적 프로그램을 구축하는 단단한 기초이자 첫 번째 단계입니다. 현장에서 시각적 프로그램을 사용하거나, 동료들과 공유하거나, 오류 문제를 해결하거나, 제한을 테스트할 때는 처리할 추가적인 문제가 있습니다. 다른 사람이 프로그램을 사용할 예정이거나 지금부터 6개월 후 공개할 예정이면 즉각적인 그래픽과 논리적 명확성이 있어야 합니다. Dynamo에는 프로그램의 복잡성을 관리하는 많은 도구가 있으며, 이 장에서는 그러한 도구를 사용할 시기에 대한 지침을 제공합니다.
Dynamo 그래프를 개발하고 아이디어를 테스트함에 따라 규모와 복잡성이 빠르게 증가할 수 있습니다. 기능적인 프로그램을 만드는 것이 중요한 한편, 최대한 간단하게 만드는 것도 그만큼 중요합니다. 그래프를 더 빠르고 예측 가능한 방식으로 실행하게 될 뿐만 아니라 나중에 다른 사용자와 함께 그 논리를 이해하게 됩니다. 아래에는 그래프의 논리를 명확히 표시하는 여러 가지 방법이 나와 있습니다.
그룹을 사용하면 프로그램을 구축할 때 기능적으로 고유한 부분을 작성할 수 있습니다.
그룹을 사용하면 모듈성과 정렬을 유지하면서 프로그램의 큰 부분을 이동할 수 있습니다.
그룹에서 수행하는 작업(입력 대 함수)을 구분할 수 있도록 그룹의 색상을 변경할 수 있습니다.
그룹을 사용하면 그래프를 구성하여 사용자 노드 작성을 간소화할 수 있습니다.
이 프로그램의 색상으로 각 그룹의 용도가 식별됩니다. 이 전략을 사용하여 개발하는 그래픽 표준이나 템플릿에서 계층을 작성할 수 있습니다.
함수 그룹(파란색)
입력 그룹(주황색)
스크립트 그룹(초록색)
경우에 따라 Code Block을 사용하여 검색보다 빠르게 숫자 또는 노드 메서드를 입력할 수 있습니다(Point.ByCoordinates, Number, String, Formula).
Code Block은 DesignScript에서 사용자 함수를 정의하여 그래프의 노드 수를 줄이려는 경우에 유용합니다.
1과 2는 모두 동일한 기능을 수행합니다. 각 노드를 개별적으로 검색하고 추가하는 것보다 코드 몇 줄을 작성하는 것이 훨씬 더 빨랐습니다. code block은 훨씬 간결하기도 합니다.
Code Block에 작성된 설계 스크립트
노드 내 동등한 프로그램
간단한 노드 모음을 가져와 단일 Code Block에 해당 DesignScript를 쓰는 Node to Code를 사용하여 그래프의 복잡성을 줄일 수 있습니다.
Node to Code를** 사용하면 프로그램의 명확성을 유지하면서 코드를 압축할 수 있습니다.**
Node to Code를 사용할 경우의 장점은 다음과 같습니다.
계속 편집 가능한 하나의 구성요소로 쉽게 코드 압축
그래프의 대부분을 단순화할 수 있음
'미니 프로그램'을 자주 편집하지 않는 경우에 유용
함수와 같은 기타 code block 기능을 통합하는 데 유용
Node to Code를 사용할 경우의 단점은 다음과 같습니다.
일반 이름을 지정할 경우 읽기가 어려워짐
다른 사용자가 이해하기가 더 어려움
시각적 프로그래밍 버전으로 쉽게 돌아갈 수 있는 방법 없음
기존 프로그램
Node to Code로 작성한 Code Block
List@Level을 사용하면 상당한 크기의 캔버스 공간을 차지할 수 있는 List.Map 및 List.Combine 노드를 대체하여 그래프의 복잡성을 줄일 수 있습니다.
List@Level에서는 노드의 입력 포트에서 바로 리스트의 임의 레벨에 있는 데이터에 액세스할 수 있게 해주어** List.Map/List.Combine보다 더 빨리 노드 논리를 구성하는 방법**을 제공합니다.
우리는 CountTrue의 "list" 입력에 대해 List@Level을 활성화하여 BoundingBox.Contains에서 반환하는 True 값이 어떤 리스트에 몇 개인지 확인할 수 있습니다. 사용자는 List@Level을 통해 입력으로 데이터를 가져올 레벨을 결정할 수 있습니다. List@Level을 사용하면 유연하고 효율적이므로 List.Map 및 List.Combine과 관련된 다른 방법에 비해 적극 권장됩니다.
리스트 레벨 2에서 true 값 계산
리스트 레벨 3에서 true 값 계산
그래프를 최대한 간단하고 효율적으로 만들 뿐만 아니라 그래픽 명확성을 위해 노력하십시오. 논리적 그룹화를 사용하여 그래프를 직관적으로 만들기 위한 최선의 노력에도 불구하고 관계가 명확하게 표시되지 않을 수 있습니다. 그룹 내부에 간단한 메모를 기록하거나 슬라이더 이름을 바꾸면 사용자 자신이나 다른 사용자가 불필요한 혼란을 겪거나 그래프를 훑어보지 않아도 됩니다. 아래에는 그래프 내에, 그리고 그래프 전체에 그래픽 일관성을 적용하는 데 유용한 몇 가지 방법이 나와 있습니다.
그래프 작성을 마친 후 작업을 줄이려면 작업하면서 자주 노드를 정렬하여 노드 배치를 읽을 수 있도록 해야 합니다.
다른 사용자가 사용자의 그래프를 사용해 작업하려는 경우 보내기 전에 노드-와이어 배치가 쉽게 유동되는지 확인해야 합니다.
정렬에 활용하려면 "노드 배치 정리" 기능을 사용하여 그래프를 자동으로 정렬합니다. 그러나 이렇게 하는 것이 직접 정렬하는 것보다 정확하지는 않습니다.
구성되지 않은 그래프
정렬된 그래프
입력의 이름을 바꾸면 다른 사람들이 그래프를 쉽게 이해할 수 있습니다. 특히 플러깅 대상이 화면에서 벗어날 경우에 유용합니다.
입력 이외에 다른 노드의 이름을 바꿀 때는 주의하십시오. 이에 대한 대안은 노드 클러스터에서 사용자 노드를 작성하고 그 이름을 바꾸는 것입니다. 여기에 다른 것이 포함되어도 이해될 것입니다.
표면 조작을 위한 입력
건축 매개변수를 위한 입력
배수 시뮬레이션 스크립트를 위한 입력
노드의 이름을 바꾸려면 해당 이름을 마우스 오른쪽 버튼으로 클릭하고 "노드 이름 바꾸기..."를 선택합니다.
그래프의 일부에 노드로 표현할 수 없는 일반 언어 설명이 필요하다면 메모를 추가해야 합니다.
노드 또는 그룹 모음이 너무 크거나 복잡해서 즉시 쉽게 이해할 수 없는 경우 메모를 추가해야 합니다.
원시 변환 거리를 반환하는 프로그램 부분을 설명하는 메모
해당 값을 사인파에 매핑하는 코드를 설명하는 메모
프로그램을 구축할 때 Watch 또는 미리보기 풍선을 사용하여** 키 출력에서 예상한 결과를 반환하는지 확인합니다.**
Watch 노드는 다음을 비교하는 데 사용됩니다.
원시 변환 거리
사인 방정식을 통해 전달되는 값
사용자가 독립적으로 작업하는 경우에도 다른 사람이 언젠가 프로그램을 열 가능성이 높습니다. 다른 사람이 프로그램에 필요한 항목을 신속하게 파악하고 이 프로그램의 입력과 출력을 통해 생성할 수 있어야 합니다. 이는 특히 Dynamo 커뮤니티와 공유하고 다른 사람의 프로그램에서 사용할 사용자 노드를 개발할 때 중요합니다. 이러한 방법을 통해 강력하고 재사용 가능한 프로그램과 노드가 작성됩니다.
판독성 및 확장성을 보장하려면 최대한 많은 입력 및 출력을 시도하고 최소화해야 합니다.
캔버스에 단일 노드를 추가하기도 전에 먼저 논리가 어떻게 작동할 수 있는지 대략적인 윤곽을 작성하여 논리를 작성하는 방법에 대한 전략을 짜보아야 합니다. 대략적인 윤곽을 개발할 때는 스크립트에 적용할 입력 및 출력을 추적해야 합니다.
그래프에 포함할 특정 옵션 또는 조건이 있는 경우 사전 설정을 사용하여 신속하게 액세스해야 합니다.
사전 설정을 사용하면 실행 시간이 긴 그래프에서 특정 슬라이더 값을 캐싱하여 복잡성을 줄일 수도 있습니다.
프로그램을 단일 컨테이너에 수집할 수 있는 경우 사용자 노드를 사용해야 합니다.
다른 프로그램에서 그래프의 일부를 자주 재사용할 경우 사용자 노드를 사용해야 합니다.
Dynamo 커뮤니티와 기능을 공유하려면 사용자 노드를 사용해야 합니다.
점 변환 프로그램을 사용자 노드에 수집하면 강력하면서도 고유한 프로그램을 이동식으로 만들고 훨씬 쉽게 이해할 수 있습니다. 이름이 올바르게 지정된 입력 포트를 사용하면 다른 사용자가 노드 사용 방법을 쉽게 이해할 수 있습니다. 각 입력에 대한 설명과 필수 데이터 유형을 추가해야 합니다.
기존 어트랙터 프로그램
이 프로그램(PointGrid)을 수집하는 사용자 노드
템플릿을 작성하여 공동작업자가 그래프를 이해하는 표준화된 방법을 갖도록 시각적 그래프 전체에 그래픽 표준을 설정할 수 있습니다.
템플릿을 작성할 때 그룹 색상 및 글꼴 크기를 표준화하여 워크플로우 또는 데이터 작업의 유형을 분류할 수 있습니다.
템플릿을 작성할 때 그래프에서 프런트엔드 워크플로우와 백엔드 워크플로우 간의 차이를 레이블, 색상 또는 스타일로 지정하는 방법을 표준화할 수도 있습니다.
프로그램의 UI 또는 프런트엔드에는 프로젝트 이름, 입력 슬라이더 및 형상 가져오기 등이 있습니다.
프로그램의 백엔드
그룹 색상 카테고리(일반 설계, 입력, Python 스크립팅, 가져온 형상)
아래 링크를 클릭하여 예제 파일을 다운로드하십시오.
전체 예시 파일 리스트는 부록에서 확인할 수 있습니다.
몇 가지 모범 사례를 설정했으므로 종합된 프로그램에 빨리 적용해 보겠습니다. 프로그램에서 지붕이 생성되지만 그래프의 상태가 작성자의 "마인드맵"과 같습니다. 이 상태로는 구성 또는 용도에 대한 설명이 부족합니다. 다른 사용자가 사용 방법을 이해할 수 있도록 프로그램을 구성하고, 설명하고, 분석하는 모범 사례를 진행해 보겠습니다.
프로그램이 작동하지만 그래프가 체계적이지 않습니다.
프로그램에서 반환된 데이터 및 형상을 결정하는 것부터 시작하겠습니다.
데이터에 중요한 변경 사항이 발생하는 경우를 이해하는 것은 논리적 분할 또는 모듈성을 설정하는 데 중요합니다. Watch 노드가 있는 프로그램의 나머지 부분을 조사하여 다음 단계로 이동하기 전에 그룹을 결정할 수 있는지 여부를 확인합니다.
수학 방정식이 포함된 이 Code Block은 프로그램의 중요한 부분처럼 보입니다. Watch 노드가 표시되어 변환 거리 리스트가 반환됩니다.
이 영역의 용도가 명확하지 않습니다. BoundingBox.Contains의 리스트 레벨 L2에 True 값이 정렬되며, List.FilterByBoolMask가 있으면 점 그리드의 일부를 샘플링하고 있음을 의미합니다.
프로그램의 요소 부분을 이해하고 나면 그룹에 배치해 보겠습니다.
그룹을 사용하면 사용자가 프로그램의 부분을 시각적으로 구분할 수 있습니다.
3D 대지 모델 가져오기
사인 방정식을 기반으로 점 그리드 변환
점 그리드의 샘플 부분
건축 지붕 표면 작성
유리 커튼월 작성
그룹이 설정된 상태에서 노드를 정렬하여 그래프 전체에 걸친 시각적 연속성을 작성합니다.
시각적 연속성을 통해 사용자는 노드 간의 암시적 관계 및 프로그램 흐름을 확인할 수 있습니다.
그래픽 개선 사항을 한층 더 추가하여 프로그램에 더 쉽게 액세스할 수 있도록 합니다. 메모를 추가하여 프로그램의 특정 영역이 작동하는 방식을 설명하고, 입력에 사용자 이름을 지정하고, 서로 다른 유형의 그룹에 색상을 지정합니다.
이러한 그래픽 개선 사항을 통해 사용자는 프로그램에서 수행하는 작업에 대해 자세히 알 수 있습니다. 서로 다른 그룹 색상을 사용하면 입력을 함수와 구분할 수 있습니다.
주
알아보기 쉬운 이름의 입력
프로그램을 압축하기 전에 Python 스크립트 배수 시뮬레이터를 소개할 전략적 위치를 찾아보겠습니다. 첫 번째로 축척된 지붕 표면의 출력을 각각의 스크립팅 입력에 플러깅합니다.
이 프로그램에서 이 지점의 스크립팅을 통합하기로 선택했으므로 배수 시뮬레이션을 원래의 단일 지붕 표면에서 실행할 수 있습니다. 해당 특정 표면은 미리 볼 수 없지만, 모따기된 Polysurface의 상단 표면을 선택할 필요가 없습니다.
스크립트 입력에 대한 소스 형상
Python 노드
입력 슬라이더
켜기/끄기 "스위치"
모든 것이 제자리에 배치되었으므로 그래프를 단순화하겠습니다.
Node to Code와 사용자 노드로 프로그램을 압축하니 그래프의 크기가 크게 줄었습니다. 지붕 표면 및 벽을 작성하는 그룹은 이 프로그램에만 해당하는 것이기 때문에 코드로 변환되었습니다. 점 변환 그룹은 다른 프로그램에서 사용될 수 있으므로 사용자 노드에 포함되었습니다. 예시 파일에서는 점 변환 그룹에서 자체 사용자 노드를 작성합니다.
"점 그리드 변환" 그룹을 포함할 사용자 노드
"건축 지붕 표면 및 커튼월 작성" 그룹을 압축할 Node to Code
마지막 단계로, 본보기 지붕 양식에 대한 사전 설정을 작성합니다.
이러한 입력은 지붕 양식의 주요 동인이며 사용자가 프로그램의 잠재력을 확인하는 데 도움이 됩니다.
두 가지 사전 설정 뷰가 포함된 프로그램입니다.
지붕 배수 패턴은 사용자에게 각 사전 설정의 해석 뷰를 제공합니다.
다음 Wiki에서는 코드 문서화 및 테스트를 위한 몇 가지 일반적인 코딩 표준에 대해 설명합니다.
다음 Wiki에서는 특히 라이브러리, 카테고리, 노드 이름, 포트 이름 및 약어에 대한 명명 표준을 다룹니다.
사용자가 작성한 Python 또는 C# 형상 객체의 Dynamo 형상 라이브러리 (ProtoGeometry) 를 사용하는 과정을 가상 컴퓨터에서 관리하지 않고 이러한 여러 객체의 메모리를 수동으로 정리해야 하는 경우를 나타냅니다. 기본 또는 비관리형 객체를 정리하려면 Dispose 메서드 또는 using 키워드를 사용하면 됩니다. 개요를 보려면 다음 Wiki 항목을 참고하십시오.
그룹을 사용하는 방법은 를 참조하십시오.
Code Block을 사용하는 방법은 을 참조하십시오.
Node to Code를 사용하는 방법에 대한 자세한 내용은 을 참조하십시오.
List@Level을 사용하는 방법은 를 참조하십시오.
노드 정렬을 사용하는 방법은 를 참조하십시오.
메모를 추가하는 방법은 를 참조하십시오.
시각적 스크립트를 작성하는 동안 반환되는 결과가 예상되는 결과와 같은지 확인하는 것이 중요합니다. 모든 오류나 문제가 프로그램의 즉각적인 실패를 초래하는 것은 아닙니다. 특히, 먼 다운스트림에 영향을 줄 수 있는 null 또는 0 값이 그렇습니다. 이 전략은 의 텍스트 스크립팅 컨텍스트에서도 설명합니다. 다음 방법은 예상한 결과를 얻을 수 있도록 도와줍니다.
Watch를 사용하는 방법에 대해서는 를 참조하십시오.
사전 설정을 사용하는 방법에 대해서는 를 참조하십시오.
사용자 노드를 사용하는 방법에 대해서는 를 참조하십시오.
루핑
재귀
노드 압축
외부 라이브러리
축약형
DesignScript
예
예
예
아니오
예
Python
예
예
부분적
예
아니요
ZeroTouch (C#)
아니요
아니오
아니오
예
아니요