ECharts-GL의 Bar3D 소스 읽기
2025년 4월 3D 차트를 조사하면서 ECharts-GL의 Bar3D와 좌표계 코드를 읽었습니다. 이번에는 workspace의 주석 사본을 배포된 2.0.9 소스와 대조해 데이터가 막대로 바뀌는 경로를 다시 정리했습니다.
이 조사는 Three.js로 전환하기 전 ECharts-GL의 활용 가능성을 검토한 과정에 있었습니다. 전환 전의 소스 분석과 이후 직접 구현한 선택 UI의 범위는 Wafermap 3D에 나눠 정리했습니다.
이 글은 라이브러리 소스 분석입니다. 아래 엔진과 geometry를 직접 구현했다는 경력 사례는 아닙니다. 로컬 사본에는 설명 주석과 변경이 있어 배포 원본과 동일한 파일로 취급하지 않았습니다.
파일 이름보다 데이터가 바뀌는 지점을 찾았습니다
Bar3D는 옵션 하나가 곧바로 정점 배열이 되는 구조가 아니었습니다. 시리즈 모델, 좌표계에 따른 layout, View와 geometry가 각기 다른 형태의 데이터를 다룹니다.
flowchart LR
Option["series 옵션과 데이터"] --> Series["Bar3DSeries: 데이터 모델"]
Series --> Layout["cartesian3DLayout: start, dir, size"]
Layout --> View["Bar3DView: 막대와 색을 순회"]
View --> Geometry["Bars3DGeometry: 정점과 인덱스"]
Geometry --> Mesh["mesh와 렌더링"]2.0.9의 Bar3DSeries는 series.bar3D 타입을 정의하고 getInitialData에서 목록을 만듭니다. 기본 좌표계는 cartesian3D입니다. 데이터 모델 파일에서 모든 렌더링 동작을 찾으려 하면 이후 경로를 놓치기 쉬웠습니다. Bar3DSeries 원본
layout에서 값이 공간의 길이로 바뀝니다
직교 좌표계의 layout은 x, y, z에 해당하는 데이터 차원을 찾고 막대의 기준점과 끝점을 계산합니다. dataToPoint로 변환한 두 점 사이의 거리와 방향이 막대의 높이와 방향이 됩니다. 누적 여부와 z축 범위에 따라 기준값도 달라집니다. 원시 z값을 그대로 화면의 픽셀 높이라고 읽으면 이 단계를 놓칩니다. cartesian3DLayout 원본
각 항목의 layout에는 시작점 start, 방향 dir과 크기 size가 저장됩니다. 좌표 변환을 마친 값이 View로 넘어간다는 경계가 보였습니다.
| 확인하려는 증상 | 먼저 읽을 부분 |
|---|---|
| 값의 차원과 축이 잘못 연결됨 | 시리즈 데이터의 차원과 좌표계 설정 |
| 막대의 위치나 높이가 예상과 다름 | layout의 기준값과 dataToPoint |
| 색, 선택과 항목 연결이 다름 | View의 데이터 순회와 항목 인덱스 |
| 모서리나 면의 구성이 다름 | geometry의 bevel, normal과 인덱스 생성 |
이 표는 소스를 따라가며 세운 조사 순서입니다. 증상마다 원인이 반드시 그 파일에만 있다는 뜻은 아닙니다.
View와 geometry를 구분합니다
Bar3DView는 데이터 항목의 layout과 색을 읽어 geometry의 addBar에 전달하고 버퍼 변경과 bounding box를 갱신합니다. 렌더링용 정점과 삼각형 인덱스의 구성은 Bars3DGeometry에서 확인할 수 있습니다. Bar3DView 원본, Bars3DGeometry 원본
원문에는 막대가 8개 정점과 12개 삼각형으로 만들어진다고 요약한 부분이 있었습니다. 하지만 정점 수는 조건부였습니다. bevel이 없는 경우에도 normal 사용 여부에 따라 24개 또는 8개를 반환하고 bevel을 켜면 별도 계산을 사용했습니다. 단순한 육면체의 꼭짓점 수와 렌더링 버퍼의 정점 수를 같은 것으로 설명하면 안 됐습니다.
항목과 정점의 관계를 보관하는 인덱스도 있었습니다. 색이나 선택 반응을 이해하려면 모양만 볼 것이 아니라 어떤 막대가 어떤 데이터 항목에 대응하는지도 따라가야 했습니다.
주석 사본을 원본과 대조한 이유
workspace의 사본에는 이해를 돕는 주석이 많았지만 일부 파일은 배포본과 바이트가 달랐습니다. 사본에 적힌 설명을 다시 인용하는 대신 버전을 고정한 배포 소스에서 함수와 분기를 확인했습니다. 소스 읽기 메모가 시간이 지나 라이브러리의 공식 동작처럼 굳는 것을 피하려는 목적이었습니다.
남긴 것은 옵션에서 데이터 모델, layout, View와 geometry로 이어지는 읽기 경로입니다. 실제 제품에서 성능이나 시각적 오류를 조사한다면 데이터 크기, 좌표계와 렌더링 설정을 고정한 재현을 더해야 합니다. 이번 분석을 실제 제품의 성능 개선이나 엔진 개발 성과로 확장하지 않았습니다.