물 캐시 재생과 메시 업로드

재생 방식

DCB의 급류는 오프라인으로 계산한 액체·포말·비말 데이터를 캐시에 저장해 재생한다. 게임 중 전체 유체 시뮬레이션을 다시 계산하지 않는다.

런타임에서는 캐시 읽기, CPU 버퍼 관리와 메시 업로드 비용이 발생한다. 캐시 파일의 저장 공간도 필요하다.

캐시에는 위치, 법선, 포말 색과 인덱스를 저장한다. 세 프레임 슬롯과 스트림을 재사용하며 다음 프레임을 선행 읽기한다. 파일 읽기는 작업 스레드에서, Unity 메시 변경은 메인 스레드에서 처리한다.

flowchart LR
    A[오프라인 유체 데이터] --> B[캐시 파일]
    B --> C[작업 스레드에서 읽기]
    C --> D[프레임 버퍼]
    D --> E[메인 스레드에서 메시 업로드]
    E --> F[렌더링]

최대 버퍼 용량과 현재 프레임의 활성 정점·인덱스 수를 구분한다. submesh와 bounds도 현재 데이터에 맞게 갱신한다. 다음 프레임의 읽기가 끝나지 않았을 때는 대기하거나 이전 업로드를 유지하는 경로를 사용한다.

정점·인덱스 버퍼 하나의 메모리는 대략 다음과 같이 계산할 수 있다.

$M_{buffer} \approx N_{vertex} B_{vertex} + N_{index} B_{index}$

전체 메모리를 계산할 때는 프레임 슬롯 수, CPU·GPU 버퍼, 파일 캐시와 입자 데이터를 추가로 고려해야 한다.

CPU 평가 시간, 업로드 시간, GPU 시간과 전체 FPS는 측정 범위가 다르다. 특정 CPU 구간이 줄어든 수치를 전체 게임의 성능 개선율로 사용하지 않는다.

프레임 탐색과 루프 전환 후에도 같은 프레임 데이터가 읽히는지 확인한다. 일시정지, 정지, 재활성화와 객체 파괴 시의 선행 읽기 작업과 파일 핸들 관리도 확인할 항목이다.

화면 확인 항목은 수면과 지형의 접점, 포말·비말, 캐시 시작·끝의 연결이다.

2026년 10월 16일 관련 검사를 골라 실행했고, 19개 중 17개가 통과했다. 실패한 두 검사는 표시 영역과 컬링 비율을 고정된 값으로 가정했는데, 실제 캐시의 입자 분포가 이 가정과 맞지 않았다. 원본 레코드 집계로 결과를 대조했다.

실패한 두 검사는 아직 수정하지 않았다. 실제 캐시에 의존하지 않는 테스트 데이터를 별도로 만들고, 실제 캐시를 사용하는 검사와 나눠 정비할 필요가 있다.