후디니 Pyro Voxel Size를 반으로 줄이면 메모리는 8배

Pyro 해상도를 높이려고 Voxel Size를 반으로 낮추면 어떤 비용이 생길까요? 같은 컨테이너에서 각 축의 복셀 수는 두 배가 되지만, 실제 Houdini Pyro의 피크 메모리와 시간까지 그 숫자대로 고정되지는 않습니다. 아래 계산기로 밀집 격자 기준값을 먼저 확인하고, sparse 영역과 서브스텝이 무엇을 바꾸는지 살펴보겠습니다.

Pyro 계산기는 컨테이너와 필드 수로 밀집 격자값을 계산합니다

컨테이너 X·Y·Z와 Voxel Size를 입력하면 각 축의 복셀 수를 올림해 계산합니다. Scalar field는 채널 1개, vector field는 채널 3개로 보고 float32는 값마다 4 bytes, float16은 2 bytes를 곱합니다.

계산식은 ceil(X/Voxel Size) × ceil(Y/Voxel Size) × ceil(Z/Voxel Size) × (scalar field 수 + 3 × vector field 수) × bytes per value입니다. 프레임 수를 곱한 값은 압축 전 field payload를 단순 합산한 캐시 참고치입니다.

예를 들어 10×10×10 컨테이너, Voxel Size 0.1, Scalar field 3개, Vector field 1개라면 100×100×100, 1,000,000 voxel입니다. 채널은 3 + 3 = 6개이므로 float32 기준 22.9 MiB/frame, 100 frames의 원시 payload는 2.24 GiB입니다.

Voxel Size	축별 복셀 수	전체 복셀	float32 필드 배열 / 프레임	100 frames 원시 payload
0.1	100 × 100 × 100	1,000,000	22.9 MiB	2.24 GiB
0.05	200 × 200 × 200	8,000,000	183.1 MiB	17.9 GiB

Voxel Size를 절반으로 낮추면 복셀 수는 이론상 8배가 됩니다

컨테이너 크기를 그대로 두고 복셀 한 변만 절반으로 만들면, 연속적인 격자 기준으로 X·Y·Z 각 축의 복셀 수가 두 배가 됩니다. 그래서 2×2×2, 총 8배의 복셀을 계산해야 합니다. 다만 계산기는 각 축의 수를 올림하므로, 컨테이너 크기가 Voxel Size의 정수배가 아니면 실제 복셀 수 비율은 8배와 달라질 수 있습니다. SideFX 공식 Pyro Solver SOP 문서도 Voxel Size를 반으로 줄이면 memory와 time이 여덟 배 필요하다고 안내합니다.

이 비율은 해상도 판단의 출발점입니다. 같은 field 구성과 정밀도라면 밀집 배열의 바이트 수도 복셀 수와 함께 8배가 됩니다. 현재 컨테이너에서 한 프레임의 기준 용량을 확인한 뒤, 샷에 필요한 프레임 수를 곱해 저장 공간을 가늠하세요.

Houdini Pyro의 sparse 격자는 컨테이너 전체를 항상 계산하지 않습니다

하지만 Houdini Pyro는 실제로 연기가 없는 컨테이너 공간까지 모두 밀집 격자로 계산하지 않을 수 있습니다. SideFX 문서에서 기본 Pyro Solver는 sparse mode로 동작하며, 활성 영역 안에서 필요한 계산을 수행한다고 설명합니다. 활성 영역은 16×16×16 복셀 타일 단위로 관리됩니다.

따라서 연기나 불꽃이 컨테이너의 일부만 차지한다면, 계산기 결과보다 실제 필드 저장량이 작아질 수 있습니다. 반대로 피크 메모리를 이 숫자보다 반드시 작다고 단정할 수도 없습니다. Sparse solver는 advection을 batch로 처리하며, SideFX는 이 방식이 피크 메모리 사용을 높일 수 있다고 설명합니다.

연기가 컨테이너에 닿아 잘리는 문제를 해결하려는 중이라면 Voxel Size부터 줄이지 마세요. 먼저 컨테이너 크기와 padding을 확인하는 순서는 후디니 Pyro 연기가 네모나게 잘릴 때 확인할 글에서 이어서 볼 수 있습니다.

CFL 서브스텝은 시뮬레이션 시간의 추가 변수입니다

속도가 빠른 연기는 한 프레임 안에서 더 많은 서브스텝이 필요할 수 있습니다. Houdini의 CFL Condition은 한 스텝에서 이동하는 거리를 복셀 수와 연결하고, Max Substeps는 사용할 수 있는 서브스텝의 상한을 둡니다. Voxel Size가 작아지면 같은 월드 이동도 더 많은 복셀을 지나므로, CFL 설정에 따라 계산량이 더 늘 수 있습니다.

서브스텝 수는 속도와 설정에 따라 달라집니다. 그래서 복셀 수가 8배라는 사실만으로 모든 샷의 실제 시뮬레이션 시간이 정확히 8배라고 예측할 수는 없습니다. 또한 sparse advection의 batch 크기와 solver 내부 임시 필드도 피크 메모리에 영향을 줍니다.

Blender 5.0 Mantaflow 참고 실측은 Houdini Pyro와 별개입니다

Houdini에서 같은 장면을 돌린 실측치는 이번에 만들지 않았습니다. 대신 Blender 5.0.0의 Quick Smoke가 만든 Gas domain에서 Resolution Divisions를 바꾸고 1~6프레임을 Bake All해, 다른 솔버의 참고 사례를 확인했습니다. 이 수치는 Houdini의 예상치가 아닙니다.

Resolution Divisions	프레임	config와 VDB 캐시 합계	Bake All 시간
16	1~6	327,024 bytes	0.20초
32	1~6	459,176 bytes	0.25초
64	1~6	1,030,632 bytes	0.60초

이 테스트는 작은 Quick Smoke 장면 하나이며 Blender의 domain 크기, 활성 영역, OpenVDB 정밀도와 압축 설정에 따라 결과가 달라집니다. Blender 공식 문서는 Resolution Divisions가 가장 긴 domain 축을 기준으로 정해지고, cache format과 OpenVDB precision 및 compression도 선택할 수 있다고 안내합니다. 이 표를 Houdini와 비교하거나 다른 씬의 예상 시간으로 사용하지 마세요.

8배는 밀집 격자 기준이며, 실제 피크와 시간은 달라집니다

Voxel Size를 반으로 줄이면 같은 박스의 복셀과 필드 배열은 8배가 되지만, 실제 Houdini 피크 메모리와 시간은 sparse 영역·내부 작업 버퍼·CFL 서브스텝에 따라 달라집니다.

계산기는 복셀마다 저장되는 필드 값의 바이트만 셉니다. 솔버의 임시 작업 공간, active mask, 메모리 allocator, 캐시 포맷과 압축은 계산하지 않습니다. 따라서 결과를 실제 피크 메모리의 상한이나 디스크에 저장될 파일 크기로 읽지 마세요.

float16은 float32보다 값 하나의 저장 폭이 절반이지만, 이것만으로 시뮬레이션 시간이나 Houdini live field의 메모리까지 절반이라고 볼 수는 없습니다. SideFX의 16bit 옵션은 볼륨 처리 설정에 따른 메모리 절감과 속도 저하 가능성을 안내합니다. 실제 적용 전에는 현재 Houdini 버전과 선택한 필드 출력 방식을 확인하세요.

실제 샷에서는 이 순서로 Voxel Size를 정하세요

• 컨테이너 크기와 기준 Voxel Size로 밀집 복셀 수를 계산하세요.
• Density, Temperature, Flame, Velocity처럼 실제로 필요한 필드만 세고 scalar와 vector를 구분하세요.
• Voxel Size를 절반으로 바꾼 기준 용량과 캐시 추정을 비교한 뒤, 현재 RAM과 여유 디스크에 맞춰 테스트 단계를 정하세요.
• 빠른 움직임에서 CFL과 서브스텝이 늘어나는지 확인하고, 짧은 프레임 구간을 먼저 캐시하세요.
• Houdini에서 실제 active 영역, peak memory, 프레임당 시간을 기록해 밀집 추정과 비교하세요.

한 줄 정리

Pyro Voxel Size를 절반으로 낮추면 복셀 수는 8배가 되지만, 실제 메모리와 시간은 sparse 영역과 CFL 설정을 함께 확인해야 합니다.

공식 자료