포토리얼 애셋은(는) 무엇을 하나요?

브리프를 연구하고, 단일 빌드를 실행하며, 사진과 비교하고 결과를 보고합니다. 설치된 Blender와 호스트의 사용 가능한 에이전트 도구를 사용합니다. 특정 에이전트 제공자, 모델, Blender 설치 경로 또는 프로젝트 위치가 필요하지 않습니다.

설정

{SKILL}을 이 파일이 포함된 디렉터리로, {SCRIPTS}를 그 scripts/ 디렉터리로 확인합니다. {PROJECT}를 사용자가 선택한 프로젝트 디렉터리로 확인합니다. 명령어에서 경로를 따옴표로 묶습니다. 예제는 Windows, macOS 및 Linux에서 Python이 허용하는 슬래시를 사용합니다.
Python 3과 numpy 및 Pillow를 사용합니다 (python -m pip install -r "{SKILL}/requirements.txt"). SciPy는 선택 사항이며 UV 검사를 가속화합니다. Blender는 bpy 스크립트에 번들 Python을 사용합니다.
blender를 PATH에서 찾거나, PHOTOREAL_BLENDER를 실행 파일의 전체 경로로 설정합니다. (값 주변에 따옴표를 포함하지 마십시오). 빌드 스크립트와 하네스에 동일한 실행 파일을 사용합니다. 버전을 확인하고 지원되는 bpy API에 맞게 빌드 코드를 조정합니다. 고정 버전을 가정하지 마십시오.
Cycles는 사용 가능한 GPU 백엔드를 선택하고 CPU로 폴백합니다. PHOTOREAL_CYCLES_DEVICE를 CPU, OPTIX, CUDA, HIP, METAL 또는 ONEAPI로 설정하여 자동 선택을 재정의합니다. 렌더를 순차적으로 실행합니다. 선택적 외부 gpu_slot.py 대기열을 PHOTOREAL_GPU_TOOLS를 통해 제공할 수 있습니다. 번들되거나 필수는 아닙니다.
asset.json의 경로는 해당 파일을 기준으로 합니다. 빈 hdri는 절차적 주광 하늘을 사용합니다. 그렇지 않으면 기존 HDRI를 가리킵니다. 빌드가 시작되면 조명과 카메라는 고정합니다.
기본 전달은 이미지와 리뷰 렌더가 패킹된 편집 가능한 .blend입니다. 요청 시에만 게임 내보내기를 추가하며, templates/GAME_READY.md를 따릅니다.

프로젝트 레이아웃

<project>/
  asset.json          카메라, 조명, 컬렉션 접두사 및 크리틱 참조
  BRIEF.md            연구 브리프와 채워진 RULES.md 템플릿
  ref/SOURCES.md      사진 출처 정보; 참조 이미지는 배송되지 않음
  research/           layout.py, blockout.py, blockout.blend, NOTES.md
  rounds/r01-build/   TASK.md, build.py, NOTES.md, tex/, renders/, final/, DONE.txt
  <Title>.md          라운드 테이블 및 프로젝트 로그

사용자가 제공하는 경우 기존 애셋 라이브러리를 사용합니다. 외부 이미지 및 텍스처의 소스 URL과 라이선스를 기록합니다. 알 수 없는 라이선스는 알 수 없음으로 표시합니다. 저작권을 추측하거나 참조 사진을 전달 가능한 결과물에 재배포하지 마십시오.

1. 연구

templates/asset.json을 프로젝트에 복사하고 주제, collection_prefix, 하늘 및 지면을 조정합니다. 주제, 측면/정면, 상단 3/4 및 가장 어려운 부분의 근접 뷰를 구성합니다. 크리틱을 위해 render_as, photo_kind 및 scope_note를 설정합니다.
templates/TASK_research.md를 채웁니다: {ASSET}, {PROJECT}, {PREFIX}, {SUBJECT_PLURAL}, {SKILL} 및 {SCRIPTS}. research/TASK.md로 저장합니다. 호스트의 에이전트 도구를 통해 한 명의 연구자를 실행하거나 직접 연구를 수행합니다.
출처 정보가 있는 참조 사진, BRIEF.md, 부품당 하나의 영역과 소유자 컬렉션이 있는 research/layout.py, 블로킷, 그리고 asset.json의 owner_refs / overall_refs를 전달합니다.
호스트의 이미지 뷰어로 블로킷 렌더를 검사합니다. 각 카메라가 주제를 프레이밍할 때까지 조정한 후 잠급니다.

제공된 디자인 시트의 경우, 변경 없이 ref/에 복사하고, 제공된 출처 정보를 기록합니다 (지정되지 않은 경우 알 수 없음). 세부 크롭을 만듭니다. 평가된 카메라에 해당 뷰를 사용합니다. 사진으로 통과하는 대신 양식화된 디자인을 일치시키는 것이 목표인 경우 critic_goal을 설정합니다. 작업 표현과 추가 전달 사항을 그에 따라 조정합니다.

2. 빌드

templates/TASK_build.md에서 rounds/r01-build/TASK.md를 만듭니다. {ROUND}, {ASSET}, {PROJECT}, {ROUND_DIR}, {FILE} 및 {SCRIPTS}를 채웁니다.
Blender 전용 애셋의 경우 {GAME_READY}를 비워 둡니다. 그렇지 않으면 채워진 templates/GAME_READY.md를 삽입하고 Godot, Unreal Engine 또는 둘 다를 선택합니다.
작업을 한 명의 빌더에게 제공합니다. 사용자가 다른 모델을 요청하지 않는 한 현재 모델을 사용합니다. 호스트가 세션 식별자를 노출하는 경우 유지합니다. 한 명의 빌더가 지오메트리를 소유합니다. 독립적인 크리틱은 리뷰만 수행합니다.

3. 모든 라운드 리뷰

최종 장면을 렌더링합니다:

python "{SCRIPTS}/run.py" --asset "{PROJECT}/asset.json" --parts "{ROUND_DIR}/final/{FILE}.blend" --out "{ROUND_DIR}/final/renders"

NOTES.md와 마지막 critique.md를 읽습니다. 어려운 부분의 전체 해상도 크롭을 사진 옆에서 검사합니다. 필요한 경우 밝게 한 크롭도 포함합니다. 심각도 카운트는 신뢰할 수 없습니다. 실제 시각적 차이로 진행 상황을 판단합니다.

이전 라운드가 있는 경우 비교합니다:

python "{SCRIPTS}/compare_rounds.py" --asset "{PROJECT}/asset.json" --rounds <이전-라운드> <현재-라운드> --focus <영역-id> --refs "<사진>:x0,y0,x1,y1" --out "{PROJECT}/compare_rounds"

결과 _all.jpg 및 _focus.jpg 시트를 검사합니다. compare_rounds.py --help에서 예상되는 라운드 경로를 사용합니다.

게임 내보내기의 경우, GAME_READY.md에서 대상별 검증을 실행합니다. Godot GLB 검사기로 검증된 Unreal 가져오기를 설명하지 마십시오.
지원되는 트랜스크립트를 사용할 수 있는 경우, 선택적으로 다음을 실행합니다:
```
python "{SCRIPTS}/audit_round.py" "{ROUND_DIR}" --root "{PROJECT}"
```
이 감사는 Antigravity 및 Claude Code 로그를 이해하며, 모든 호스트를 이해하는 것은 아닙니다. Antigravity 대화의 경우 --session을, 추가 허용 도구 디렉터리의 경우 --allow를 전달합니다. 파일 경로 스캔은 Windows 드라이브 경로를 인식합니다. 다른 경로 스타일은 별도로 검토합니다. 로그 루트는 PHOTOREAL_ANTIGRAVITY_LOGS 및 PHOTOREAL_CLAUDE_LOGS로 재정의할 수 있습니다.
라운드와 보고서 이미지, 개선 사항, 회귀, 검증 결과 및 하나의 권장 사항을 기록합니다. 비용은 측정된 경우에만 보고합니다. 요청된 라운드 후에 중지합니다. 사용자가 요청할 때만 다른 리파인먼트를 시작합니다. 해당 대상 및 작업이 요청된 경우에만 외부 라이브러리에 복사하거나 수집합니다.

4. 요청 시 리파인먼트

명명된 부품의 더 나은 사진을 관련 뷰(앉은 상태, 빈 상태, 측면 및 평가 카메라 각도)에서 얻습니다. ref/SOURCES.md에 출처 정보를 기록합니다.
소유자의 owner_refs 목록에 가장 강력한 참조를 먼저 배치합니다. 각 그룹은 최대 6개를 가집니다.
이전 빌드 스크립트, tex/ 및 final/{FILE}.blend를 새 rounds/rNN-<초점>/ 폴더에 복사합니다. 노트를 NOTES_<이전>.md로, 마지막 검사를 renders/<이전>_check/로, 최종 렌더를 renders/<이전>_final/로 보존합니다.
templates/TASK_refine.md를 부품, 영역 ID 및 새 참조를 포함하여 채웁니다. 해당 부품에 대한 변경을 제한합니다. 단, 다른 곳의 심각도 3 결함은 제외합니다. 갈등하는 위치와 각도(연결된 부품 포함)보다 사진이 우선한다는 규칙을 유지합니다.
한 명의 빌더를 실행하고 위와 같이 리뷰한 후, 이전 및 현재 결과를 사진 옆에 표시합니다.

에이전트 핸드오프 및 독립적 크리틱

도구 이름이나 모델 별칭을 가정하지 않고 호스트의 네이티브 에이전트 인터페이스를 사용합니다. 연구자나 빌더에게 작업 디렉터리와 전체 작업 파일을 제공합니다. 할당된 프로젝트 또는 라운드 디렉터리 내에서만 쓰기를 유지합니다. 작업은 DONE.txt를 작성하여 종료됩니다. 빌더 위임이 불가능한 경우, 동일한 작업 경계를 유지하면서 직접 빌드합니다.

규칙 11의 크리틱은 빌더와 독립적이어야 합니다. photo_check.py는 프롬프트와 critic_jobs.json 매니페스트를 준비합니다. 각 프롬프트를 이미지/파일 읽기만 가능한 새로운 리뷰어(네트워크 또는 편집 도구 없음)에게 보내고, JSON 응답을 매니페스트의 response_file에 저장하고 병합합니다. 호스트가 지원하는 경우에만 크리틱을 동시에 실행하며, critic.parallel을 존중합니다. 프롬프트가 이미지/파일 읽기를 참조하는 곳마다 호스트의 이미지 뷰어를 사용합니다.

독립적인 하위 에이전트를 사용할 수 없는 경우, --runner claude는 설치되고 인증된 Claude Code CLI를 사용할 수 있습니다. 그렇지 않으면 렌더와 준비된 리뷰 작업을 전달하고, 독립적 크리틱이 불완전하다고 보고합니다. 빌더 자신의 리뷰를 대체하여 독립적이라고 부르지 마십시오.

검사

스크립트	목적
`run.py` / `render.py`	잠긴 Cycles 장면에서 접두사 일치 컬렉션 렌더링; 카메라 PNG 및 `sheet.jpg` 작성.
`photo_check.py`	레이아웃 영역 크롭, 독립적 크리틱 작업 준비 및 JSON 응답을 `critique.md`로 병합. `--from`은 렌더를 재사용하고, `--groups`는 소유자를 선택합니다.
`game_check.py` / `game_check_bl.py`	Godot LOD 메시, UV, 볼록 충돌 및 임베디드 GLB 텍스처 검증; LOD 턴테이블 생성. Unreal 검증은 `GAME_READY.md` 참조.
`compare_rounds.py`	라운드 및 초점 크롭을 참조 행과 비교.
`audit_round.py`	선택적으로 지원되는 트랜스크립트에서 파일 액세스, 형제 라운드, 웹 호출 및 측정된 토큰 사용량 검사.

리뷰 원칙

약한 부분의 더 나은 사진이 일반적으로 브리프에 규칙을 추가하는 것보다 더 도움이 됩니다.
각 리파인먼트를 이전 라운드와 비교하십시오: 수정이 이전 개선 사항을 지울 수 있습니다.
비례 불만은 지오메트리를 변경하기 전에 크기 일치 오버레이로 확인하십시오.
어두운 캐비티에는 눈에 띄는 립 하이라이트, 벽 두께 및 내부 페이드오프가 필요합니다. 밝게 하는 것은 검사용으로만 사용하십시오. 평가된 조명은 고정합니다. 하이키 이미지를 클리핑할 때는 밝게 하는 것을 건너뜁니다.
크리틱을 라운드 간 수치 점수가 아닌 라운드 내 수리 목록으로 사용하십시오.

포토리얼 애셋