OrcaSlicer 딥다이브
— 3D 모델이 프린터의 이동 경로가 되기까지

1프로젝트 한줄 요약

OrcaSlicer는 3D 모델과 출력 설정을 프린터용 이동·압출 명령으로 바꾸는 슬라이서입니다. 화면에 예쁜 입체 모형을 보여주는 것만으로는 물체를 만들 수 없습니다. 노즐이 어느 높이에서 어떤 선을 따라 움직이고, 그동안 재료를 얼마나 밀어낼지 정해야 합니다.

이 저장소에서 배울 핵심은 복잡한 계산을 여러 단계로 나누고, 그 결과를 사람이 조작할 수 있는 제품으로 연결하는 방법입니다. 웹 서비스 경험이 있다면 화면과 서버를 떠올려도 좋지만, 여기서는 계산 엔진과 화면이 대체로 같은 데스크톱 프로세스 안에 있습니다.

1-1. 입력과 출력 사이에 있는 다섯 가지 일

위 표에서 파일명만 적은 계산 파일은 src/libslic3r/ 아래에 있습니다. 실제 파이프라인에는 브림, 퍼지 타워, 경로 단순화, 재료 전환 등 더 많은 단계가 있습니다. 다섯 단계는 처음 읽기 위한 큰 지도입니다.

1-2. G-code는 어떤 모습인가

; 문법 이해용 예시. 특정 프린터용 출력 파일이 아닙니다.
G90                    ; 좌표를 절대 위치로 해석
M82                    ; 압출 위치도 절대값으로 해석
G1 Z0.20 F600          ; 높이 이동
G1 X20 Y20 F3000       ; XY 위치 이동
G1 X40 Y20 E0.75 F1200 ; 이동하며 재료 압출

이 예시에는 가열·원점 복귀·압출 초기화 등이 없습니다. 문법을 읽는 연습에만 사용합니다. 같은 형상이라도 펌웨어와 압출 모드가 다르면 필요한 명령이 달라집니다.

2왜 주목받는가

2026-10-23 GitHub Trending C++ Weekly에서 7위로 선정된 프로젝트입니다. 다만 순위만으로 유입 원인을 확정할 수는 없습니다. 아래의 주목 요인은 README의 기능 설명과 소스 구성을 바탕으로 한 해석이며, 특정 소식 때문에 순위가 올랐다는 인과관계는 확인되지 않았습니다.

2-1. 한 제조사의 장비를 넘어서는 설정과 연결

README는 Bambu Lab·Prusa·Creality·Voron 등을 지원 대상으로 소개합니다. 소스에는 제조사별 resources/profiles/가 있고, PrintHost::get_print_host()는 htOctoPrint, htPrusaLink, htMoonraker 등에 따라 구현 객체를 선택합니다. “호환된다”는 홍보 문구 뒤에 데이터와 연결 코드라는 두 종류의 확장 지점이 있는 셈입니다.

JSON 파일이 있다고 모든 장비 조합을 검증했다는 뜻은 아닙니다. 그럼에도 여러 장비의 차이를 하나의 계산 엔진으로 흡수하는 방식은 프린터 사용자와 개발자 모두에게 관심을 끌 만한 지점입니다.

2-2. 출력 품질을 조절하는 도구가 한곳에 있습니다

README가 강조하는 기능은 온도·유량·리트랙션 교정, 벽 정밀도와 이음매 제어, 지지대 최적화입니다. 관련 코드는 src/libslic3r/calib.hpp, src/libslic3r/PerimeterGenerator.cpp, src/libslic3r/Support/ 등으로 이어집니다. 출력 실패를 줄이고 표면을 다듬는 문제는 사용자가 결과를 직접 확인하기 쉬운 문제입니다.

2-3. 경쟁 제품을 볼 때는 출발점과 학습 초점을 비교합니다

README의 계보 설명에 따르면 Slic3r에서 PrusaSlicer로, 다시 Bambu Studio로 발전한 흐름 위에서 OrcaSlicer가 시작됐습니다. SuperSlicer와 Cura에서 영향을 받은 아이디어도 언급합니다. 따라서 비슷한 화면이나 클래스 이름은 공유한 역사와 연결해 읽는 편이 정확합니다.

이 표는 다른 제품에 해당 기능이 없다는 주장이나 성능 순위가 아닙니다. 동일 모델·설정·하드웨어로 비교한 측정 자료가 없으므로 “가장 빠르다”는 결론도 내리지 않습니다.

2-4. 개발 브랜치는 슬라이서 주변으로 범위를 넓힙니다

커밋 022769c8에는 src/libslic3r/CAD/와 src/slic3r/GUI/CAD/, Python 플러그인 구현이 존재합니다. 루트 CMakeLists.txt의 SLIC3R_CAD 기본값도 켜져 있습니다. 이는 현재 개발 소스의 사실이며, 안정 릴리스 v2.4.2에 모두 들어 있다는 뜻은 아닙니다.

OrcaSlicer의 학습 가치는 새 알고리즘 하나보다, 오래된 엔진에 새 기능을 붙이면서 설정·호환성·화면 반응성을 함께 지키는 데 있습니다.

3기술 스택 전체 지도

3-1. 백엔드에 해당하는 부분: 로컬 C++ 계산 엔진

웹 서비스의 백엔드에 가까운 역할은 src/libslic3r/가 맡습니다. 모델·설정·단면·경로를 다루는 라이브러리이며, 외부 HTTP 서버를 띄워야 슬라이싱할 수 있는 구조는 아닙니다. 루트와 src/CMakeLists.txt 모두 기본 C++ 표준을 17로 설정합니다.

여기서 버전은 해당 커밋의 의존성 빌드 정의 또는 포함된 소스 버전입니다. 운영체제 패키지를 이용하는 빌드나 배포본의 실제 링크 결과까지 같은 버전이라고 단정할 수는 없습니다.

3-2. 프론트엔드: wxWidgets와 OpenGL, 일부 내장 웹 화면

주 UI는 src/slic3r/GUI/의 네이티브 C++ 코드입니다. deps/wxWidgets/wxWidgets.cmake는 Orca용 wxWidgets 저장소의 v3.3.2를 고정하고, src/CMakeLists.txt는 wxWidgets 3.3을 요구합니다. 창·버튼·이벤트는 wxWidgets가, 3D 장면과 경로 표시는 OpenGL 관련 코드가 담당합니다.

예를 들어 resources/web/dialog/ExportPresetDialog/index.js의 RequestProfile()은 request_export_preset_profile을 보내고, HandleStudio()는 응답 명령을 확인합니다. resources/web/include/globalapi.js에는 SendWXMessage()가 있습니다. 웹 화면이 있어도 제품 전체를 웹 앱으로 분류하면 실제 구조를 놓칩니다.

저장소에는 package.json, Cargo.toml, pyproject.toml, go.mod가 없습니다. 이 프로젝트의 빌드 출발점은 CMake입니다. JavaScript 파일이 존재한다는 이유만으로 Node.js 기반 프론트엔드 빌드를 가정하면 안 됩니다.

3-3. 인프라·빌드: 의존성을 먼저 만들고 앱에 연결합니다

deps/는 외부 의존성을 준비하는 빌드 정의이고, deps_src/는 저장소에 포함된 외부 소스입니다. 거대한 C++ 제품에서는 코드 컴파일만큼 버전·패치·운영체제별 라이브러리 배치를 맞추는 일이 중요합니다.

# CMakeLists.txt의 설정 중 일부를 발췌
cmake_minimum_required(VERSION 3.13)
option(SLIC3R_GUI "Compile OrcaSlicer with GUI components (OpenGL, wxWidgets)" 1)
option(SLIC3R_CAD "Compile OrcaSlicer with the parametric Design/CAD tab (needs OCCT ModelingAlgorithms)" 1)
option(BUILD_TESTS "Build unit tests" OFF)
set(CMAKE_CXX_STANDARD 17)

CMAKE_BUILD_TYPE이 비어 있고 다중 구성 생성기도 아니면 기본값은 Release입니다. scripts/Dockerfile은 ubuntu:24.04를 기반으로 의존성·앱·AppImage를 만드는 단계를 나눕니다. 이 Dockerfile은 개발·패키징 환경을 설명하며 웹 서버 배포의 증거가 아닙니다.

.github/workflows/build_all.yml은 Linux x86_64·aarch64, Windows x64·arm64, macOS의 아키텍처별 빌드와 Universal 패키지 결합을 구성합니다. unit_tests.yml은 빌드된 테스트 산출물을 내려받아 실행하고 JUnit 결과를 올립니다.

.github/workflows/clang_tidy.yml은 PR의 변경된 C++ 줄을 검사합니다. 미리 컴파일한 헤더를 끈 컴파일 데이터베이스를 사용해, 우연히 다른 헤더를 통해 공급된 선언에 의존하는 코드도 드러내려 합니다. 테스트 프레임워크는 tests/catch2/CMakeLists.txt 기준 Catch2 3.11.0입니다.

앱에 포함하는 패키지 도구 uv도 루트 CMake에서 0.11.21로 고정하고 플랫폼별 SHA-256을 검사합니다. 이처럼 빌드 파일은 프로그램을 만드는 명령 목록이면서, 제품에 어떤 부품을 넣을지 기록한 명세서이기도 합니다.

4아키텍처 심화 분석

4-1. 전체 시스템 지도

src/OrcaSlicer.cpp의 일반 플랫폼 진입점 main()은 CLI().run(argc, argv)를 호출합니다. CLI::run()은 실행할 작업이 없고 하위 호환성 검사(downward_check)가 꺼져 있으면 GUI 시작 경로를 선택하고, GUI를 포함한 빌드에서는 GUI_Run()으로 들어갑니다. CLI와 GUI가 서로 다른 슬라이싱 엔진을 따로 갖는다고 이해할 필요는 없습니다.

위 그림은 주요 책임을 묶은 개념도입니다. 모든 화살표가 인접한 함수의 직접 호출을 뜻하지는 않습니다. 특히 실제 출력은 경로 생성 외에 프린터 설정 검증과 별도의 전달·시작 동작을 거칩니다.

4-2. 데이터 모델부터 구분하기

Model과 Print를 구분해야 “모델은 그대로인데 설정 때문에 경로만 다시 계산한다”는 상황이 이해됩니다. src/libslic3r/PrintApply.cpp의 Print::apply()가 그 사이를 잇습니다. 출력 작업을 다루는 Print.cpp에 모든 구현이 모여 있지는 않다는 점도 기억하세요.

4-3. 설계 ① 파이프라인과 단계별 무효화

Print::process()는 PrintObject::slice(), make_perimeters(), prepare_infill(), infill() 등을 단계적으로 호출합니다. 하지만 호출됐다는 사실과 실제 계산이 다시 수행됐다는 사실은 다릅니다.

src/libslic3r/PrintBase.hpp의 PrintState::set_started()는 뮤텍스를 잡고 취소 여부를 확인한 뒤, 단계가 이미 DONE이면 false를 반환합니다. 이를 이용해 선행 단계를 다시 호출하더라도 유효한 결과는 재사용합니다.

// PrintObject.cpp의 infill()을 핵심 흐름만 남겨 재구성
void PrintObject::infill()
{
    this->prepare_infill();
    if (this->set_started(posInfill)) {
        // 실제 구현은 TBB로 레이어별 make_fills() 수행
        // 중간과 완료 직전에 취소 요청 확인
        this->set_done(posInfill);
    }
}

그렇다면 언제 DONE을 버릴까요? Print::apply()에서 설정 차이를 반영하고, PrintObject::invalidate_state_by_config_options()가 변경된 키를 재계산할 단계로 연결합니다.

이 표는 전체 무효화 목록이 아닌 대표 분기입니다. 무효화는 뒤 단계에도 전파되므로 “출발 단계 하나만 다시 계산한다”는 뜻은 아닙니다. 특히 채움 밀도는 숫자만 바뀌는 설정처럼 보이지만, 비어 있음·일반 채움·완전 채움의 경계에서 더 많은 계산에 영향을 줍니다.

빠르게 만드는 핵심은 계산을 무조건 병렬화하는 것뿐 아니라, 바뀌지 않은 계산을 다시 하지 않는 데 있습니다.

4-4. 설계 ② 팩터리와 전략: 패턴을 교체하는 방법

src/libslic3r/Fill/FillBase.cpp의 Fill::new_from_type()는 패턴 열거값을 구현 객체로 바꿉니다. FillBase.hpp의 Fill은 가상 함수를 제공하고, 구체적인 채움 구현은 그 인터페이스를 따릅니다. 객체 선택은 팩터리로, 바꿔 끼우는 계산 방식은 전략으로 읽을 수 있습니다.

// FillBase.cpp의 switch 중 대표 분기 발췌
case ipGyroid:      return new FillGyroid();
case ipRectilinear: return new FillRectilinear();
case ipGrid:        return new FillGrid();

// Fill.cpp의 소유권 처리 방식
std::unique_ptr<Fill> f =
    std::unique_ptr<Fill>(Fill::new_from_type(surface_fill.params.pattern));

공장 역할의 함수가 원시 포인터를 반환해도 호출부는 std::unique_ptr로 소유권을 받습니다. 소유 객체가 범위를 벗어날 때 정리되는 RAII의 실제 사용입니다. 새 패턴을 추가할 때는 구현 클래스뿐 아니라 열거값·설정 선택지·팩터리 연결·테스트까지 찾아야 합니다.

장비 연결에도 비슷한 선택 구조가 있습니다. src/slic3r/Utils/PrintHost.cpp의 PrintHost::get_print_host()는 host_type을 보고 연결 구현을 만듭니다. 학습할 때는 서로 다른 파일에서 반복되는 “설정값 → 구체 구현”의 모양을 찾아보세요.

4-5. 설계 ③ 이벤트와 작업 스레드의 책임 분리

오래 걸리는 계산을 화면 이벤트 처리 중에 모두 수행하면 창이 멈춘 것처럼 보입니다. src/slic3r/GUI/BackgroundSlicingProcess.cpp는 작업 스레드와 상태를 관리하고, 계산 완료 등은 wxQueueEvent()로 GUI 쪽에 전달합니다.

BackgroundSlicingProcess::start(), stop()과 작업 루프를 함께 읽으면 STATE_IDLE, STATE_STARTED, STATE_RUNNING, STATE_FINISHED의 역할이 보입니다. 루프는 조건변수로 시작·종료 요청을 기다리며, 완료 통지에는 예외 정보와 취소 상태도 반영합니다.

여기에 TBB 병렬 계산이 한 겹 더 있습니다. PrintObject::infill()은 tbb::blocked_range<size_t>로 레이어 범위를 나누고 make_fills()를 호출합니다. “GUI와 계산을 분리하는 동시성”과 “계산 내부를 나누는 병렬성”은 목적이 다릅니다.

4-6. 설계 ④ 데이터 중심 설정과 검증 가능한 캐시

PrintConfig.cpp는 옵션의 타입·범위·설명·기본값을 정의하고, PresetBundle.cpp는 제조사와 프리셋 데이터를 읽어 조합합니다. PresetBundle::load_vendor_configs_from_json()은 이름과 달리 현재 소스에서 read_vendor()와 install_vendor_read()를 거치며 캐시 경로도 처리합니다.

read_vendor()는 조건에 따라 VendorCacheFile::load()를 시도하고, 채택되지 않으면 parse_vendor_json()으로 진행합니다. 검증 모드에서는 캐시를 사용하지 않고 JSON을 읽습니다. 다만 JSON이 제거된 배포 형태라면 캐시 손상을 JSON 재해석만으로 복구할 수는 없습니다.

상세 설계 문서 docs/HLSD/preset-cache.md는 상속 결과를 모두 굳혀 저장하기보다, 원래 설정의 차이와 부모 이름을 보관하고 로딩 때 상속을 해결한다고 설명합니다. 선언 순서 번호만 저장하면 설정 하나를 끼워 넣었을 때 뒤 번호가 밀릴 수 있기 때문에, 이름으로 해석하는 사전이 의미를 갖습니다.

커밋 제목은 프리셋 캐시를 배포할 때 제조사 데이터 파일을 보존하는 수정입니다. 실제 scripts/build_preset_cache.sh의 listed_presets()는 제조사 목록의 sub_path를 모으고, 패키징 대상에서는 캐시가 생성된 제조사의 목록 JSON과 그 목록에 나열된 프리셋 파일을 제거합니다. 옆에 있는 색상표·별도 설정·이미지까지 지우지 않도록 구분하는 규칙이 코드에 보입니다.

5디렉토리 구조 해부

5-1. 목적에 따라 들어갈 문을 고릅니다

5-2. 줄 수로 본 크기: 직접 센 물리적 줄 수

아래는 커밋 022769c8의 파일을 확장자별로 읽어 센 결과입니다. 빈 줄·주석·헤더·포함된 외부 코드를 포함하고 .git은 제외했습니다. 마지막 줄에 개행이 없어도 한 줄로 계산했습니다. 중복 코드나 실제 실행 코드만 가려낸 수치는 아닙니다.

C/C++·헤더는 .c .cc .cpp .cxx .h .hh .hpp .hxx .ipp .inl을 묶었습니다. 셸은 .sh .bash, CMake는 .cmake와 CMakeLists.txt입니다. HTML에는 .html과 .htm을 함께 집계했습니다. Objective-C 계열, JSON·번역·문서 등은 이 표에 포함하지 않았으므로 표의 합이 저장소 전체 줄 수는 아닙니다.

C/C++ 묶음 안에서도 앱의 src/는 894,137줄, deps_src/는 462,355줄, deps/는 79,422줄, tests/는 152,429줄, sandboxes/는 1,250줄입니다. 테스트 폴더에는 Catch2 소스도 들어 있으므로 이 숫자로 자체 테스트 비중을 계산하면 왜곡됩니다.

resources/profiles/ 아래 JSON은 14,408개입니다. 이 수는 장비 대수가 아니라 제조사 목록·기본 설정·파생 프리셋·보조 데이터 등을 포함한 파일 수입니다. 프리셋 캐시가 왜 별도 하위 시스템으로 발전했는지 이해할 단서가 됩니다.

6학습 포인트 (기술별)

6-1. C++: 누가 객체를 소유하는지 따라가기

Fill::new_from_type()과 호출부의 std::unique_ptr<Fill>를 함께 읽으세요. 생성·사용·파괴를 한 함수 안에서만 찾으면 객체의 수명이 보이지 않습니다. 기반 클래스의 가상 소멸자와 호출부의 소유권을 연결해야 구체 구현이 올바르게 정리되는 이유를 이해할 수 있습니다.

PrintState의 std::scoped_lock<std::mutex>도 같은 관점입니다. 자원을 메모리에 한정하지 않고 잠금까지 확장해 보면 RAII가 제품 코드 전반에 쓰이는 방식이 보입니다.

6-2. 계산기하: 형상과 경로의 차이 이해하기

메시는 입체 표면을 삼각형으로 표현합니다. 단면은 평면의 다각형이며, 출력 경로는 노즐 중심이 움직일 선입니다. 바깥 윤곽 그대로 노즐을 움직이면 선의 폭 때문에 원하는 치수와 달라질 수 있습니다. 윤곽을 안팎으로 이동하는 오프셋 연산이 필요한 이유입니다.

src/libslic3r/ClipperUtils.hpp와 ClipperUtils.cpp는 내부 다각형 타입과 Clipper2 사이의 접점을 제공합니다. 합집합·교집합·차집합·오프셋이 벽과 채움 영역 계산의 공통 도구가 됩니다.

tests/libslic3r/test_clipper_utils.cpp의 첫 시나리오는 사각형 안에 구멍을 둔 뒤 오프셋 결과를 확인합니다. 보조 함수 start_at_min()으로 다각형 시작 꼭짓점을 정규화하는 점도 좋습니다. 같은 테두리라도 어느 꼭짓점부터 나열했느냐는 달라질 수 있기 때문입니다.

작은 실습으로 종이에 사각형과 구멍을 그리고 각각 1칸씩 오프셋해 보세요. 두 다각형의 정점 배열이 다르다는 이유만으로 형상이 다르다고 판단하면 안 되는 사례를 직접 만들 수 있습니다.

6-3. 수치 표현: 단위와 정밀도는 따로 생각하기

src/libslic3r/libslic3r.h의 활성 분기에서 coord_t는 int64_t입니다. SCALING_FACTOR_INTERNAL은 0.000001, 큰 프린터용 상수는 0.00001입니다. libslic3r.cpp에서 전역 배율은 기본 상수로 초기화됩니다.

# 기본 배율에서 단위를 이해하기 위한 계산
내부 좌표 = mm 좌표 / 0.000001
1 mm      = 내부 좌표 1,000,000
20 mm     = 내부 좌표 20,000,000

# 저장 단위가 작다고 실제 출력 정밀도가 그만큼 높아지지는 않습니다.

정수 격자는 좌표 표현을 일정하게 만들지만, 모든 기하 연산이 무한히 정확해지는 것은 아닙니다. docs/HLSD/polygon-clipping.md는 Clipper2의 일부 교점·기울기 계산에 부동소수점이 쓰인다는 점과 좌표 범위를 설명합니다. 실습에서는 mm와 내부 단위를 섞었을 때 100만 배 오류가 어디서 생기는지 적어 보세요.

6-4. 설정 시스템: 스키마의 기본값과 사용자 값 구분하기

PrintConfig.cpp에서 sparse_infill_density는 coPercent, 범위 0~100, 기본값 20입니다. wall_loops는 coInt, 범위 0~1000, 기본값 2입니다. 하지만 이는 옵션 정의의 기본값이지, 모든 프리셋을 선택했을 때 화면에 나타나는 값은 아닙니다.

// resources/profiles/Vzbot/process/0.20mm Standard @Vzbot.json
{
  "type": "process",
  "name": "0.20mm Standard @Vzbot",
  "inherits": "fdm_process_Vzbot_common",
  "from": "system",
  "setting_id": "aufrk8Rt9qtJksVX",
  "instantiation": "true",
  "layer_height": "0.2",
  "bottom_shell_layers": "3",
  "top_shell_layers": "4"
}

이 프리셋의 부모 resources/profiles/Vzbot/process/fdm_process_Vzbot_common.json은 wall_loops를 "3", sparse_infill_density를 "15%"로 지정합니다. 부모의 top_shell_layers는 3이지만 자식은 4로 덮어씁니다. 또한 JSON에서는 많은 값이 문자열로 저장되므로 파일 표기와 엔진 내부 타입을 구분해야 합니다.

설정을 이해하려면 이름과 기본값만 읽지 말고, 누가 덮어쓰고 어느 계산을 다시 시작시키는지까지 따라가야 합니다.

6-5. 병렬 처리: 쓰는 데이터와 읽는 데이터를 구분하기

PrintObject::infill()의 람다는 this를 캡처하고 여러 레이어를 처리합니다. 범위가 나뉜다는 사실만으로 모든 공유 데이터가 안전해지는 것은 아닙니다. 각 작업이 쓰는 레이어와 함께 참조하는 자료구조를 구분해야 합니다.

실습으로 함수 안의 값을 “레이어별 결과”, “공유해서 읽는 입력”, “취소·진행 상태”로 나눠 보세요. throw_if_canceled()가 반복 안과 완료 전에도 호출되는 이유를 설명하면, 빠른 완료 외에 취소 반응성이라는 목표가 있음을 이해하게 됩니다.

6-6. 테스트·저장 형식: 미래의 변경을 견디는 방법

tests/fff_print/test_print.cpp는 G-code 생성 등 출력 관련 동작을, tests/libslic3r/test_vendor_cache.cpp는 제조사 캐시를 다룹니다. 캐시 테스트의 TempDir은 생성자에서 임시 디렉토리를 만들고 소멸자에서 정리합니다. 테스트도 C++ 자원 수명 관리의 학습 자료입니다.

docs/HLSD/design-tab.md는 CAD 레시피의 과거 버전 표본을 이용한 호환성 검사를 설명합니다. 같은 버전에서 저장하고 다시 읽는 왕복 검사만으로는, 저장·읽기 구현이 함께 잘못 바뀐 문제를 놓칠 수 있습니다. 과거 프로그램이 만든 고정 표본을 읽는 검사가 필요한 이유입니다.

7하드웨어 / 시스템 요구사항

소스와 README에 명시된 조건은 아래와 같습니다. 아래의 RAM·디스크 수치는 빌드 전 검사값이므로 앱 실행 최소 사양과 구분해야 합니다.

7-1. 오류 문구 하나만 믿으면 생기는 오해

src/slic3r/GUI/OpenGLManager.cpp의 해당 초기화 분기는 is_version_greater_or_equal_to(2, 0)으로 검사합니다. 그런데 실패 시 표시할 문장은 OpenGL 3.2보다 낮다고 안내합니다. 검사식과 사용자 문구가 서로 다릅니다.

따라서 이 분기 하나만 보고 앱 전체가 모든 OpenGL 2.0 장치에서 정상 동작한다고 보장해서도, 안내 문장만 보고 그 검사가 정확히 3.2를 요구한다고 설명해서도 안 됩니다. 실제 배포본과 드라이버의 조합은 따로 확인해야 합니다.

7-2. 공부를 시작할 때의 현실적인 선택

코드 탐색은 일반 개발용 PC와 편집기로 시작할 수 있습니다. 직접 빌드를 계획한다면 여유 있는 멀티코어 CPU, SSD, 32GB급 RAM을 학습용 권장 환경으로 고려할 만합니다. 이 수치는 공식 최소 사양이나 측정 결과가 아니라, 의존성과 병렬 컴파일의 여유를 위한 제안입니다.

우선 작은 단일 모델로 학습하고, 레이어 높이·삼각형 수·오브젝트 수를 한 번에 하나씩 늘려 관찰하세요. 대략 20mm 높이를 0.2mm 층으로 나누면 100층, 0.1mm면 200층입니다. 실제 층 수는 첫 층 설정과 형상 등에 따라 달라지고 실행 시간도 단순히 두 배가 되는 것은 아닙니다.

요구사항을 읽을 때는 사용자 실행 조건, 빌드 도구의 검사값, 학습용 권장 환경을 서로 구분해야 합니다.

8직접 해볼 수 있는 실습 과제

다음 과제는 프린터 없이 시작할 수 있습니다. 소스 검색 명령은 저장소 루트에서 읽기만 수행하는 예입니다. 구현·빌드가 필요한 확장은 별도 연습용 사본에서 진행하고, 처음에는 분석 결과물부터 완성해 보세요.

# 저장소 루트에서 실행하는 읽기 전용 검색
rg -n 'wall_loops|sparse_infill_density|top_shell_layers' \
  src/libslic3r/PrintConfig.cpp resources/profiles/Vzbot/process

# 이름에 공백이 있으므로 경로 전체를 따옴표로 감쌉니다.
cat 'resources/profiles/Vzbot/process/0.20mm Standard @Vzbot.json'

rg -n 'ipGyroid|FillGyroid|new_from_type' src/libslic3r/Fill
rg -n 'gyroid' src/libslic3r/PrintConfig.cpp

실습의 완료 기준은 파일을 많이 읽는 것이 아니라, 입력 하나가 결과와 재계산 범위에 미치는 영향을 설명하는 것입니다.

9관련 기술 심화 학습 로드맵

다음은 C++ 기초 문법을 조금 아는 독자를 위한 학습 제안입니다. 처음부터 전체 빌드를 성공시키는 일을 목표로 삼기보다, 작은 설정 하나와 단순한 형상을 반복해서 사용하세요. 각 주의 결과물을 다음 주에 연결하면 지식이 따로 흩어지지 않습니다.

9-1. 기초가 부족하면 앞에 한 단계를 더 둡니다

C++가 처음이라면 참조와 포인터, const, 컨테이너, 생성자·소멸자, 예외를 먼저 익히세요. 수학은 2D 좌표·벡터·선분·넓이부터 시작하면 됩니다. 자이로이드의 수식이나 복잡한 지지대 알고리즘을 첫 관문으로 삼을 필요는 없습니다.

처음에는 “이 함수가 무슨 일을 하나”를 적고, 익숙해지면 “이 함수가 어떤 전제에 기대나”를 적으세요. 예를 들어 레이어 수가 0일 때, 취소가 들어왔을 때, 설정 타입이 바뀌었을 때의 행동을 묻는 식입니다.

9-2. 이후에는 관심 분야를 하나 선택합니다

• 알고리즘: TriangleMeshSlicer.cpp에서 단면 선분이 폐곡선으로 연결되는 흐름을 추적합니다.
• 데스크톱 UI: Plater.cpp와 GLCanvas3D.cpp에서 사용자 조작과 장면 갱신을 연결합니다.
• 플러그인: PythonInterpreter::initialize(), PluginManager::initialize()와 C++·Python 경계를 읽습니다.
• CAD: CadDocument::checkpoint()와 recompute()를 읽고 작업 이력과 파생 형상을 구분합니다.
• 배포: 의존성의 버전·해시·패치가 운영체제별 산출물에 반영되는 경로를 따라갑니다.

한 기능을 입력·설정·계산·저장·검증까지 연결해 읽는 경험이, 디렉토리 전체를 훑는 것보다 오래 남습니다.

10핵심 키워드 사전

11참고 링크

11-1. 공식 저장소와 사용자 문서

• OrcaSlicer 공식 저장소 — README, 이슈와 프로젝트 전체.
• 공식 웹사이트 — README가 안내하는 공식 도메인.
• 공식 위키 — 설정 설명과 사용자 안내.
• 교정 안내 — 온도·유량 등 출력 조건 학습.
• 빌드 안내 — 운영체제별 최신 절차.
• v2.4.2 릴리스 — 안정 릴리스의 변경 내용과 배포 파일.

11-2. 코드 설명의 기준점

• Print.cpp — Print::process()와 G-code 내보내기.
• PrintApply.cpp — 모델·설정 반영과 변경 감지.
• PrintObject.cpp — 오브젝트별 단계와 설정 무효화.
• PrintConfig.cpp — 설정 타입·범위·기본값.
• FillBase.cpp — 채움 패턴 객체를 만드는 팩터리.
• BackgroundSlicingProcess.cpp — 작업 스레드와 GUI 이벤트.
• 프리셋 캐시 설계 문서 — 파일 형식과 상속·캐시의 경계.
• 다각형 클리핑 설계 문서 — 오프셋과 좌표 범위.
• 제조사 캐시 테스트 — 정상·실패 입력을 다루는 예.

11-3. 관련 기술의 공식 학습 자료

• wxWidgets 문서 — 창과 이벤트 모델.
• Khronos OpenGL 위키 — 그래픽 API의 개념.
• oneTBB 문서 — 범위 분할과 병렬 알고리즘.
• Clipper2 문서 — 다각형 연산.
• CGAL 문서 — 계산기하 자료구조와 알고리즘.
• CMake 문서 — 타깃·옵션·외부 프로젝트.
• Catch2 문서 — C++ 테스트 작성과 매처.
• pybind11 문서 — C++와 Python 연결.
• 저장소 라이선스 원문 · GNU AGPLv3 원문.

기술 문서의 최신판은 여기서 인용한 의존성 버전과 다를 수 있습니다. API를 실제로 적용할 때는 저장소가 고정한 버전과 포함된 패치도 함께 확인하세요.

현재 상태 (2026-10-23 기준)