후디니 캐시 형식별 용량 실측: bgeo.sc·VDB·Alembic

후디니에서 시뮬레이션을 저장할 때 File Cache의 기본값인 .bgeo.sc를 그대로 사용해도 되는지, VDB나 Alembic으로 바꾸면 용량이 더 줄어드는지 고민하게 됩니다. 특히 파티클과 Pyro, 메시 애니메이션은 데이터 구조가 다르기 때문에 같은 기준으로 비교하기 어렵습니다.

Houdini 내부에서 속성과 그룹을 포함한 전체 geometry를 보존하려면 .bgeo.sc를 기준으로 삼으세요. 다른 프로그램으로 볼륨을 전달한다면 VDB, 메시나 포인트 애니메이션을 전달한다면 Alembic을 검토하는 편이 적합합니다. 다만 가장 작은 파일이나 가장 빠른 형식은 데이터에 따라 달라집니다.

Houdini 19.5.435에서 파티클 10만·100만 점, 저해상도 Pyro 한 프레임, 메시 애니메이션 10프레임을 실제 파일로 저장하고 비교했습니다. 100만 점 파티클에서는 .bgeo.sc가 19.69 MiB, Alembic Ogawa가 41.96 MiB였습니다. 반면 Pyro에서는 VDB가 .bgeo.sc보다 컸습니다.

이 결과는 한 대의 PC에서 측정한 참고치입니다. 특히 Pyro는 frame 2의 16³ 볼륨 필드 6개만 저장한 작은 실험입니다. 상용 시뮬레이션 전체의 용량 순위나 저장 속도를 뜻하지 않습니다.

1. File Cache에서 bgeo.sc·VDB·Alembic은 저장 목적부터 다릅니다

캐시 형식은 단순히 파일 크기만 보고 고르면 안 됩니다. 다시 열었을 때 어떤 데이터가 남아 있어야 하는지, 그리고 어느 프로그램에서 읽을 것인지부터 구분해야 합니다.

.bgeo와 .bgeo.sc: Houdini geometry 보존

.bgeo는 Houdini의 네이티브 바이너리 geometry 형식입니다. 점, 정점, 프리미티브, 디테일의 속성과 그룹을 포함한 geometry detail을 저장할 수 있습니다. .bgeo.sc는 이 계열에 압축을 적용한 캐시 형식입니다.

SideFX의 geometry 형식 표와 .bgeo 형식 설명에서 저장 형식과 geometry 정보 범위를 확인할 수 있습니다.

파티클 위치와 속도, 커스텀 속성, 그룹, 메시와 볼륨이 함께 들어 있는 SOP 결과를 Houdini에서 다시 사용한다면 우선 검토할 형식입니다. 프레임마다 토폴로지가 달라지는 geometry detail도 각 프레임의 파일로 저장할 수 있습니다.

Houdini 19.5의 File Cache SOP는 기본 캐시 확장자로 .bgeo.sc를 사용합니다. 최신 SideFX 공식 문서는 노드를 File Cache 2.0으로 설명하지만 기본 확장자는 동일합니다. 버전별 인터페이스는 구분하되 기본 파일 형식이 바뀐 것으로 이해할 필요는 없습니다.

설정은 SideFX Houdini 19.5 File Cache SOP 사용 문서와 최신 File Cache 2.0 문서에서 각각 확인할 수 있습니다.

VDB: 볼륨 그리드를 다른 프로그램으로 전달

OpenVDB는 희소 볼륨을 효율적으로 표현하기 위한 자료구조와 파일 형식입니다. 연기나 밀도 필드처럼 공간에 분포한 데이터를 다루는 데 사용합니다. OpenVDB의 공식 소개에서도 희소하고 시간에 따라 변화하는 볼륨 데이터와 저장 구조를 설명합니다.

하지만 .vdb가 .bgeo.sc의 모든 기능을 대신하지는 않습니다. VDB는 그리드 중심의 형식이며, Houdini의 polygon mesh·point geometry·그룹과 모든 속성을 통째로 보존하는 네이티브 geometry 파일과는 목적이 다릅니다.

Houdini에서 표준 Volume primitive를 사용 중이라면 VDB로 변환하는 단계가 필요합니다. 변환 시 primitive attribute는 grid metadata로, detail attribute는 file metadata로 옮겨질 수 있습니다. 따라서 필드 이름뿐 아니라 전달해야 할 metadata도 확인해야 합니다.

입력 geometry의 모든 primitive가 VDB volume이라면 File Cache에서 직접 .vdb 저장 형식을 선택할 수 있습니다. 표준 Volume과 다른 geometry가 섞여 있다면 먼저 데이터 구성을 확인하세요. SideFX의 표준 Volume과 VDB 구분 문서가 변환 경로를 이해하는 데 도움이 됩니다.

Alembic: 메시와 포인트 애니메이션 교환

.abc는 서로 다른 3D 프로그램 사이에서 geometry와 애니메이션을 전달하는 데 사용합니다. Houdini는 Alembic으로 hierarchy, polygon mesh, curve, point set 등을 저장하거나 읽을 수 있습니다.

Houdini에서 저장할 때는 Alembic ROP의 Format에서 HDF5 또는 Ogawa를 선택할 수 있습니다. 이번 측정은 Ogawa를 명시적으로 설정했습니다. 따라서 아래 수치를 HDF5까지 포함하는 모든 Alembic 결과로 해석하면 안 됩니다.

커스텀 속성을 전달하려면 Save Attributes와 point·vertex·primitive·detail attribute pattern을 확인해야 합니다. primitive group을 face set으로 전달하는 설정도 있습니다. 그러나 저장 기능이 있다는 사실만으로 수신 프로그램에서 모든 속성과 그룹을 동일하게 해석한다는 뜻은 아닙니다.

SideFX의 Alembic 데이터 교환 설명과 Alembic ROP의 Format·속성 설정 문서를 참고하세요.

형식	주요 저장 대상	우선 검토할 상황
.bgeo / .bgeo.sc	Houdini geometry detail, 속성, 그룹, 볼륨	Houdini 내부 재사용과 시뮬레이션 캐시
.vdb	OpenVDB volume grid	볼륨을 다른 VDB 지원 앱으로 전달
.abc	Mesh, curve, point set, animation, hierarchy	서로 다른 3D 앱 사이의 geometry 교환

세 형식의 차이는 압축률보다 데이터 표현 방식에서 시작합니다. 파일 크기를 비교하기 전, 전달할 데이터가 점인지 볼륨인지 메시인지 먼저 정하세요.

2. 실측 환경과 비교 방법

측정에는 Windows 환경의 Houdini 19.5.435 hython.exe를 사용했습니다. .bgeo, .bgeo.sc, .vdb는 같은 Houdini geometry detail을 saveToFile()로 저장하고 loadFromFile()로 다시 읽는 호출 시간을 측정했습니다. Alembic은 Ogawa ROP로 내보낸 뒤 Houdini Alembic SOP로 읽었습니다. 이 시간에는 Pyro 시뮬레이션 cook이나 전체 네트워크 처리 시간이 포함되지 않습니다. 파일 크기는 실제 저장 바이트 수를 확인하고, 표에는 1 MiB = 1,048,576 bytes 기준으로 환산했습니다.

쓰기와 읽기 시간은 hython 단일 실행에서 해당 호출이 걸린 벽시계 시간입니다. 디스크와 운영체제의 파일 캐시를 항상 차가운 상태로 고정하지 않았습니다. 따라서 시간 수치는 이 PC에서의 관찰이며, 다른 SSD·NAS·CPU·운영체제에서의 속도를 예측하는 공식은 아닙니다.

파티클은 10만 점과 100만 점을 만들고 P, v, Cd, id 속성을 넣었습니다. 같은 geometry를 세 형식으로 저장한 다음 다시 읽었습니다. Alembic은 한 프레임의 정적 point set으로 저장했고, Houdini Alembic SOP의 geometry 모드에서 점 수와 네 속성이 유지되는지 확인했습니다.

Pyro는 Sphere SOP에서 시작해 Pyro Source, Point Wrangle, Volume Rasterize Attributes, Pyro Solver를 연결했습니다. Pyro Source는 Volume Scatter와 Particle Separation 0.25, Volume Rasterize Attributes는 voxel size 0.2, Pyro Solver는 Div Size 0.25로 설정했습니다.

소스 점은 253개였고 Point Wrangle에서 density=1, temperature=1, v=(0,1,0)을 설정했습니다. 실제 Pyro Solver를 frame 2까지 cook한 뒤 나온 16³ 크기의 표준 볼륨 6개를 사용했습니다. 필드는 density, temperature, flame, vel.x, vel.y, vel.z입니다.

메시 실험은 100×100 quad grid, 10,201점과 10,000면을 사용했습니다. 토폴로지를 고정한 채 10프레임 동안 점 위치를 변형했습니다. .bgeo와 .bgeo.sc는 프레임별 10개 파일, Alembic은 Ogawa 형식의 한 파일로 저장했습니다.

3. 파티클 10만·100만 점의 캐시 용량과 속도

파티클에서는 압축된 .bgeo.sc가 세 형식 중 가장 작은 파일을 만들었습니다. 100만 점에서는 약 19.69 MiB로, 압축하지 않은 .bgeo의 약 38.15 MiB보다 작았습니다. Alembic Ogawa는 약 41.96 MiB였습니다.

점 수	형식	크기 (MiB)	쓰기 (초)	읽기 (초)
100,000	.bgeo	3.82	0.0026	0.0071
100,000	.bgeo.sc	2.01	0.0068	0.0088
100,000	.abc Ogawa	4.20	0.0238	0.0210
1,000,000	.bgeo	38.15	0.0196	0.0266
1,000,000	.bgeo.sc	19.69	0.0586	0.0431
1,000,000	.abc Ogawa	41.96	0.1107	0.1708

같은 점과 속성을 저장했지만 크기는 달랐습니다. 100만 점 기준 원시 파일 크기는 .bgeo 40,001,417 bytes, .bgeo.sc 20,651,640 bytes, Alembic Ogawa 44,002,101 bytes였습니다. 표의 반올림 값이 아니라 이 실제 바이트 수를 뒤의 계산기 기준으로 사용합니다.

쓰기 시간은 예상과 다르게 보일 수 있습니다. 이 실험에서는 100만 점 .bgeo의 쓰기가 0.0196초였고, .bgeo.sc는 0.0586초였습니다. 압축으로 파일이 작아졌지만 저장 호출 시간까지 짧아지지는 않았습니다.

읽기에서도 .bgeo는 0.0266초, .bgeo.sc는 0.0431초였습니다. 이는 압축 해제 비용과 저장 환경의 영향을 함께 포함한 한 번의 관찰입니다. 작은 파일이 언제나 빠르게 읽힌다고 판단하지 마세요.

세 형식 모두 이번 Houdini 재읽기 검사에서는 점 수와 네 속성을 확인했습니다. 하지만 Alembic을 Maya나 Blender 등으로 넘길 때까지 같은 결과가 보장되는 것은 아닙니다. 수신 애플리케이션에서도 id와 Cd, v처럼 실제 필요한 속성을 확인해야 합니다.

4. Pyro에서는 VDB가 더 작지 않았습니다

VDB는 희소 볼륨을 다루는 형식이지만 모든 Pyro 데이터를 가장 작은 파일로 만든다는 뜻은 아닙니다. 이번에는 같은 Pyro frame 2의 16³ 필드 6개를 표준 Houdini volume과 VDB로 저장해 비교했습니다.

저장 방식	bytes	MiB	쓰기 (초)	읽기 (초)
.bgeo 표준 volume	89,633	0.086	0.0008	0.0053
.bgeo.sc 표준 volume	51,163	0.049	0.0008	0.0043
.vdb 32-bit	108,110	0.103	0.0034	0.0056
.bgeo.sc 16bit float	29,609	0.028	0.0183	0.0053
.vdb half float	86,629	0.083	0.0024	0.0063

Float16을 적용하기 전에는 .bgeo.sc가 51,163 bytes, .vdb가 108,110 bytes였습니다. 이 샘플에서는 .bgeo.sc가 VDB보다 약 52.7% 작았습니다. VDB 변환 후에는 여섯 grid 이름이 유지되는 것도 확인했습니다.

여기서 중요한 것은 크기 순위를 일반화하지 않는 것입니다. 16³처럼 작은 필드에서는 파일 구조와 metadata 등의 상대적인 비중이 다른 조건과 같지 않을 수 있습니다. 이번 테스트만으로 수백 프레임의 고해상도 Pyro에서도 같은 비율이 유지된다고 말할 수 없습니다.

OpenVDB가 제공하는 희소 볼륨 구조의 장점과 이번 한 프레임의 파일 크기는 서로 다른 문제입니다. 다른 프로그램에 볼륨을 전달해야 한다면 VDB의 호환성이 선택 이유가 될 수 있습니다. 반대로 Houdini에서 표준 volume을 그대로 재사용한다면 .bgeo.sc를 먼저 측정할 이유가 충분합니다.

실제 프로젝트에서는 볼륨의 해상도, 비어 있는 영역, 활성 voxel 분포, 필드 수와 값의 특성이 달라집니다. 그 조건들을 이번 실험에서 별도로 변화시켜 측정하지 않았으므로 VDB의 절감률을 특정 숫자로 예상해서는 안 됩니다.

5. 메시 애니메이션 10프레임은 어떨까요?

고정 토폴로지 메시도 같은 형식으로 비교했습니다. 10,201점과 10,000개의 quad로 이루어진 grid를 10프레임 동안 변형한 데이터입니다. 이때 .bgeo와 .bgeo.sc는 각각 10개 파일의 합계이고, Alembic은 한 파일의 전체 크기입니다.

형식	전체 bytes	MiB	쓰기 (초)	읽기 (초)
.bgeo 10개	2,833,060	2.70	0.0332	0.0140
.bgeo.sc 10개	992,718	0.95	0.0267	0.0100
.abc Ogawa 1개	1,427,114	1.36	0.1915	0.0140

이번 메시에서도 .bgeo.sc의 총용량이 가장 작았습니다. Alembic Ogawa는 약 1.36 MiB로 .bgeo.sc보다는 컸지만, 압축하지 않은 .bgeo 시퀀스보다 작았습니다.

하지만 Alembic의 목적은 단지 저장 공간을 줄이는 데 있지 않습니다. 여러 프로그램으로 애니메이션을 전달하면서 hierarchy와 geometry sample을 처리하는 교환 형식이라는 점이 중요합니다.

테스트한 Alembic을 Houdini에서 1~10프레임 읽었을 때 매 프레임 점 위치가 변하는 것을 확인했습니다. 파일에서는 하나의 mesh shape로 로드됐습니다. 이 관찰은 이번에 저장한 단일 shape 구성에 해당하며, 여러 오브젝트를 가진 모든 Alembic 파일이 같은 구조라는 뜻은 아닙니다.

토폴로지가 변하는 메시도 별도 확인이 필요합니다. Alembic은 변화하는 geometry를 표현할 수 있고, Blender의 Mesh Sequence Cache 공식 문서에서도 변화하는 토폴로지의 메시를 다루는 기능을 설명합니다.

다만 이번에는 고정 토폴로지만 측정했습니다. 변화하는 토폴로지의 파일 크기나 처리 속도는 확인하지 않았습니다. Alembic을 받는 프로그램의 importer와 후속 modifier, 렌더링 작업에서 해당 변화가 정상 처리되는지 직접 시험하세요.

6. Float16과 Attribute Delete는 얼마나 용량을 줄일까요?

Float16은 용량과 수치 오차를 함께 봐야 합니다

Pyro 저장 크기를 줄이는 방법 가운데 하나는 볼륨 값의 저장 정밀도를 낮추는 것입니다. 표준 Houdini volume에서는 Volume Compress SOP의 Update Compression Settings와 Use 16bit Float 옵션을 사용했습니다.

그 결과 .bgeo.sc가 51,163 bytes에서 29,609 bytes로 줄었습니다. 같은 샘플에서 약 42.13% 감소한 결과입니다. 저장 후 확인한 최대 절대 오차는 0.0038328171, 평균 절대 오차는 0.000088897861이었습니다.

VDB에서는 별도 경로를 사용했습니다. 각 VDB primitive의 vdb_is_saved_as_half_float=1을 설정해 저장했을 때 108,110 bytes에서 86,629 bytes로 줄었습니다. 감소율은 약 19.87%였습니다.

VDB half float의 최대 절대 오차는 0.0038328171, 평균 절대 오차는 0.00014874413이었습니다. 최대 오차는 같았지만 평균 오차와 저장 크기는 달랐습니다. 두 저장 경로의 수치 결과를 동일한 것으로 간주해서는 안 됩니다.

SideFX Volume Compress 공식 문서에 따르면 Use 16bit Float는 볼륨 저장 시 float 정밀도를 낮추는 옵션입니다. 또한 이 SOP는 표준 Houdini volume용이며 VDB에는 작동하지 않습니다. 따라서 VDB에 같은 노드를 연결하는 방식으로 적용하려 하지 마세요.

Float16을 선택할 때는 파일 크기뿐 아니라 density, temperature, velocity 등의 값이 저장 후 얼마나 달라졌는지 확인해야 합니다. 이번 오차는 작은 테스트 볼륨에서 측정한 값으로, 다른 시뮬레이션에서 시각적 차이가 없다는 근거는 아닙니다.

이미지 저장에서도 비슷하게 압축률과 수치 보존 여부를 구분해야 합니다. EXR 파일에서는 DWAA·B44와 PIZ·ZIP의 압축 및 값 보존 차이를 비교한 EXR 글을 참고할 수 있습니다. 다만 EXR의 압축 방식과 Houdini volume의 Float16 저장은 서로 다른 기술입니다.

Attribute Delete는 속성값에 따라 효과가 다릅니다

파티클에서는 필요 없는 속성을 삭제한 효과도 측정했습니다. 기준은 100만 점에 P, v, Cd, id가 있는 geometry입니다. 여기에 pseudo-random 값의 debugWeight float와 stagingCode int 속성 두 개를 추가하고, Attribute Delete SOP로 삭제한 뒤 비교했습니다.

형식	속성 삭제 전	속성 삭제 후	감소율
.bgeo	48,001,715 bytes	40,001,417 bytes	16.67%
.bgeo.sc	28,191,696 bytes	20,651,640 bytes	26.75%

이 데이터에서는 사용하지 않는 속성 두 개만 제거해도 .bgeo.sc의 크기가 26.75% 줄었습니다. 데이터가 100만 점에 반복 저장되기 때문에 점마다 붙어 있는 속성의 크기가 전체 캐시에 영향을 줍니다.

그러나 속성 개수가 같아도 절감률은 달라집니다. 대조 실험에서 같은 종류의 속성값이 짧은 주기로 반복되도록 만들었을 때 .bgeo.sc는 20,688,411 bytes에서 20,651,640 bytes로 줄어드는 데 그쳤습니다. 감소율은 약 0.18%입니다.

즉, 압축된 파일의 용량은 속성 개수만으로 결정되지 않습니다. 값이 얼마나 반복되는지와 압축하기 어려운 값이 얼마나 포함되어 있는지도 중요합니다. 이번 측정에서는 pseudo-random 속성의 제거 효과가 반복값 속성보다 훨씬 컸습니다.

File Cache 앞에서 Geometry Spreadsheet를 열고 실제로 필요한 속성을 확인하세요. 디버그용 값이나 전달 대상이 사용하지 않는 임시 속성이 있다면 Attribute Delete SOP로 정리한 복사본을 저장해 비교할 수 있습니다. 원본 시뮬레이션에 필요한 속성까지 무조건 삭제해서는 안 됩니다.

7. 실제 작업에서는 어떤 형식을 선택해야 할까요?

처음의 질문으로 돌아가면, 세 형식 가운데 어느 하나가 항상 가장 작고 빠른 것은 아닙니다. Houdini 내부 전체 geometry 보존은 .bgeo.sc, 다른 앱과의 볼륨 교환은 VDB, 메시·포인트 애니메이션 교환은 Alembic을 기준으로 선택하되 실제 데이터로 다시 측정하는 것이 핵심입니다.

1. Houdini에서 다시 시뮬레이션 결과를 불러올 때: File Cache의 .bgeo.sc를 먼저 사용하세요. 점·프리미티브·속성·그룹·볼륨 등 전체 geometry detail이 필요한 경우에 적합합니다. 일반 .bgeo도 비교할 수 있지만 이번 측정에서는 더 큰 파일이 만들어졌습니다.
2. 연기나 다른 볼륨 필드를 외부 앱으로 전달할 때: 수신 앱이 OpenVDB를 읽는다면 .vdb를 검토하세요. 표준 Houdini volume이면 먼저 VDB 변환을 확인하고, grid class·필드 이름·metadata가 전달되는지 검사하세요.
3. 메시 또는 포인트 애니메이션을 전달할 때: Alembic Ogawa를 검토하세요. ROP의 Format=Ogawa, 프레임 범위, SOP Path, Save Attributes와 attribute pattern을 확인하세요. 전송 후에는 수신 프로그램에서 모든 필요한 프레임과 속성을 검사하세요.
4. 프레임마다 topology가 변할 때: Houdini 내부 작업이라면 프레임별 .bgeo.sc 캐시를 우선 비교하세요. Alembic으로 전달할 때는 수신 앱이 변화 토폴로지를 정상적으로 처리하는지 짧은 구간을 먼저 시험하세요.
5. 디스크 용량이 부족할 때: 포맷부터 바꾸기보다 불필요한 속성과 필드가 있는지 확인하세요. Float16이 가능한 볼륨이라면 원래 값과 저장 후 값의 차이도 함께 검사하세요.

Houdini File Cache는 시뮬레이션을 매번 다시 계산하지 않고 저장 결과를 읽게 해 줍니다. 따라서 캐시가 재사용될 위치와 전달 대상을 먼저 정한 뒤 저장 형식을 선택해야 합니다.

실제 작업에서는 전체 샷을 한 번에 저장하기 전에 대표 프레임을 골라 세 가지를 확인하는 편이 좋습니다. 첫째, 다시 읽은 데이터의 구조와 속성이 맞는지. 둘째, 저장 파일의 크기가 적절한지. 셋째, 사용하는 저장장치에서 읽기·쓰기 시간이 작업 흐름에 맞는지입니다.

파일을 Houdini 외부로 전달한다면 여기에 수신 앱의 실제 import 결과도 추가하세요. 확장자를 읽을 수 있다는 사실과 필요한 데이터가 모두 보존된다는 사실은 다릅니다.

8. 파티클 캐시 용량 계산기

아래 계산기는 이번 파티클 실측을 바탕으로 점 수, 추가 속성 수, 프레임 수에 따른 예상 용량을 보여 줍니다. 대상은 .bgeo, .bgeo.sc, .abc Ogawa입니다. 실제 저장 결과를 대체하지 않는 대략적인 추정 도구입니다.

기준 geometry에는 P(위치), v(벡터), Cd(색), id(정수)가 이미 포함되어 있습니다. 추가 속성 수는 이 네 가지에 더하는 단일 float 또는 int scalar 속성의 개수입니다. 예를 들어 새로운 float3 벡터 속성 하나는 세 성분이므로 추가 scalar 속성 3개로 입력하세요.

용량 추정에는 10만 점과 100만 점의 실제 기본 파일 크기를 사용합니다. 두 측정점 사이에서는 점당 파일 크기 비율을 로그 간격으로 보간하고, 범위를 벗어나면 가까운 끝점의 비율을 사용합니다. 추가 속성의 증가량은 100만 점의 pseudo-random float·int 두 속성 실측을 기준으로 계산합니다.

계산 결과를 읽는 방법

기본 입력값은 100만 점, 추가 속성 0개, 10프레임입니다. 이 경우 .bgeo는 약 381.48 MiB, .bgeo.sc는 약 196.95 MiB, Alembic Ogawa는 약 419.64 MiB로 표시됩니다.

이 숫자는 측정된 100만 점의 단일 프레임 파일 크기를 10배 한 결과입니다. 실제 10프레임의 파티클 애니메이션을 세 형식으로 다시 측정한 결과가 아닙니다.

추가 속성 수를 바꾸면 .bgeo는 실측된 두 속성의 증가량 8,000,298 bytes, .bgeo.sc는 7,540,056 bytes를 기준으로 추정합니다. 이를 각각 100만 점과 두 속성으로 나누어 단일 scalar 속성의 점당 증가량을 구했습니다.

그러나 이 값은 pseudo-random 속성에서 얻은 결과입니다. 앞서 본 반복값 속성처럼 압축이 잘되는 데이터는 증가량이 훨씬 작을 수 있습니다. 속성의 자료형, 값의 분포, 압축 방식이 달라지면 실제 파일 크기도 달라집니다.

Alembic은 특히 구분해야 합니다. 제공된 근거표에는 10만·100만 점의 기본 용량과 Houdini에서 재읽은 결과가 있지만, 추가 속성을 붙인 Alembic의 정확한 저장 바이트 수는 제시되어 있지 않습니다. 따라서 계산기는 .bgeo의 추가 scalar 증가량을 임시로 빌려 씁니다. Alembic의 속성 증가량이 실제로 동일하다고 확인한 것은 아닙니다.

또한 프레임 수에 단순히 비례시키는 방식은 각 프레임이 전체 point sample을 저장한다고 가정합니다. Alembic에서 반복 데이터나 시간 샘플을 최적화하면 실제 크기는 달라질 수 있습니다. 특히 위의 고정 토폴로지 메시 애니메이션 측정값을 이 파티클 계산식으로 대신해서는 안 됩니다.

VDB는 계산기에서 제외했습니다. 점 수와 단일 scalar 속성 수를 입력하는 방식은 볼륨 grid의 크기를 추정하기에 맞지 않습니다. 볼륨의 저장 용량은 앞서 제시한 Pyro 실측표를 참고하고, 실제 작업의 grid 수와 voxel 구성으로 다시 측정하세요.

9. 최종 저장 전에 확인할 것

이번 실험에서 .bgeo.sc는 파티클, 작은 Pyro, 고정 토폴로지 메시 모두에서 비교 대상 가운데 작은 용량을 보였습니다. 그러나 이는 테스트한 데이터의 결과입니다. 특히 Pyro는 frame 2의 16³ 필드만 비교했으므로 대규모 연기 시뮬레이션의 평균적인 용량 비율을 보여 주지 않습니다.

읽기·쓰기 시간 역시 같은 PC에서 hython 단일 실행으로 측정했습니다. OS 파일 캐시 상태가 통제되지 않았고, 다른 Houdini 빌드나 저장장치에서 재측정하지 않았습니다. 따라서 숫자의 미세한 차이를 근거로 형식별 절대적인 속도 순위를 정할 수 없습니다.

실무에서는 File Cache의 기본 .bgeo.sc로 대표 구간을 저장한 다음, 외부 프로그램과의 교환이 필요한 경우에만 VDB 또는 Alembic 출력을 추가해 비교하는 방법이 명확합니다. 파일 크기와 저장 시간뿐 아니라 읽은 뒤의 속성, 필드 이름, 프레임 변화, 토폴로지를 함께 확인하세요.

캐시 형식의 정답은 가장 작은 확장자가 아니라 필요한 데이터를 올바르게 보존하고 전달하는 형식입니다. Houdini 내부 작업에는 .bgeo.sc를 출발점으로 사용하고, 볼륨 교환에는 VDB, geometry 애니메이션 교환에는 Alembic을 검토하세요. 마지막 판단은 자신의 시뮬레이션에서 직접 저장하고 다시 읽은 결과로 내리는 것이 좋습니다.