2026년 9월 19일 토요일

[TA #2] Houdini MCP 연결 — Houdini 19.5를 Claude Code에 붙이기

■ 목표

Houdini를 Claude Code에서 직접 조작하게 만든다. 노드 만들고, 파라미터 바꾸고, VEX 랭글 쓰고, 지오메트리를 조회하는 걸 채팅으로 시키는 구조다. 쓴 서버는 capoomgit/houdini-mcp. 로컬 Houdini는 19.5.368이라 최신 버전 기준으로 만들어진 코드가 여기서 도는지가 관건이었다.

Goal — Drive Houdini from Claude Code: create nodes, set parameters, write VEX wrangles, inspect geometry, all from chat. The server is capoomgit/houdini-mcp. My local Houdini is 19.5.368, so the real question was whether code written against newer builds runs here.

■ 환경

OSWindows 11
Houdini19.5.368 (내장 Python 3.9.10, PySide2 5.15.2)
시스템 Python3.12.10
Claude Code2.1.220
houdini-mcpcommit de4fd93 (2026-06-11)
uv0.12.17 (이번에 설치)

Environment — Windows 11, Houdini 19.5.368 (bundled Python 3.9.10 / PySide2 5.15.2), system Python 3.12.10, Claude Code 2.1.220, houdini-mcp at commit de4fd93, uv 0.12.17 installed for this.

■ 구조 — 프로세스가 둘이다

설치 전에 이걸 먼저 이해해야 뒤의 이슈가 전부 설명된다.

Claude Code ──stdio──> houdini_mcp_server.py (시스템 Python 3.12, FastMCP)
                              │ TCP 127.0.0.1:9876
                              ▼
                     Houdini GUI 프로세스
                     └ houdinimcp/server.py (Houdini 내장 Python 3.9, QTimer 폴링)
                       └ hou API
  • 브릿지(houdini_mcp_server.py)는 Claude Code가 띄우는 별도 프로세스. Python 3.12 이상이 필요하고 mcp 패키지를 쓴다.
  • 플러그인(server.py)은 Houdini 안에서 돈다. Houdini 내장 Python 3.9로 실행되고, mcp 패키지가 필요 없다. 소켓만 연다.
  • 둘은 Python도 패키지도 공유하지 않는다. 그래서 hython에 mcp를 설치할 필요가 없고, 설치하면 오히려 꼬인다(뒤의 이슈 참고).

Architecture — Two processes. The bridge (houdini_mcp_server.py) is spawned by Claude Code, needs Python ≥3.12 and the mcp package. The plugin (server.py) runs inside Houdini on its bundled Python 3.9 and only opens a socket — it never needs mcp. They share neither interpreter nor packages, which explains most of the issues below.

■ 설치 방법

경로 약속: REPO = 저장소 clone 위치, PREF = C:\Users\<이름>\Documents\houdini19.5.

1. 저장소 clone

git clone https://github.com/capoomgit/houdini-mcp REPO

2. uv 설치 (README 표준 경로. pip venv로도 되지만 lock 재현이 편해서 uv를 택했다)

powershell -c "irm https://astral.sh/uv/install.ps1 | iex"
# 설치 위치: C:\Users\<이름>\.local\bin\uv.exe  (PATH에 자동 등록되지 않음)

3. 브릿지 의존성 설치 — uv.lock에 mcp 1.4.1이 고정돼 있다. 이 버전이어야 한다(이슈 1).

cd REPO
uv sync --python 3.12
uv run python -c "import mcp.server.fastmcp; from importlib.metadata import version; print(version('mcp'))"
# → 1.4.1

4. Houdini 쪽 배치 — README는 PREF\scripts\python\houdinimcp에 넣으라고 하는데, 19.5에서 그 경로는 기본 sys.path에 없다(이슈 2). Houdini 표준 경로인 python3.9libs에 junction으로 연결했다. 복사 대신 링크라서 git pull이 그대로 반영된다.

mkdir "PREF\python3.9libs"
cmd /c mklink /J "PREF\python3.9libs\houdinimcp" "REPO"
"C:\Program Files\Side Effects Software\Houdini 19.5.368\bin\hython.exe" -c "import houdinimcp; print(houdinimcp.__file__)"
# → PREF\python3.9libs\houdinimcp\__init__.py 이면 성공

5. 셸프 파일 — GUI에서 버튼을 손으로 만드는 대신 PREF\toolbar\houdinimcp.shelf를 파일로 넣었다. Start MCP / Stop MCP 두 개. 스크립트 본문은 저장소의 shelf_tool_start_mcp.py / shelf_tool_stop_mcp.py에 import hou 한 줄만 붙인 것이다.

<?xml version="1.0" encoding="UTF-8"?>
<shelfDocument>
  <tool name="houdinimcp_start" label="Start MCP" icon="MISC_python">
    <script scriptType="python"><![CDATA[
import hou
import houdinimcp
if houdinimcp.is_server_running():
    print("already running")
else:
    houdinimcp.start_server()
]]></script>
  </tool>
  <tool name="houdinimcp_stop" label="Stop MCP" icon="MISC_python">
    <script scriptType="python"><![CDATA[
import hou
import houdinimcp
houdinimcp.stop_server()
]]></script>
  </tool>
  <toolshelf name="houdinimcp" label="Houdini MCP">
    <memberTool name="houdinimcp_start"/>
    <memberTool name="houdinimcp_stop"/>
  </toolshelf>
</shelfDocument>

Houdini를 열고 셸프 탭 줄 오른쪽 끝 + → Shelves → Houdini MCP 체크하면 탭이 생긴다.

6. Claude Code 등록 — project 스코프로 넣으면 작업 폴더의 .mcp.json에 기록된다. uv가 PATH에 없으므로 절대 경로.

claude mcp add -s project houdini -- C:\Users\<이름>\.local\bin\uv.exe run --directory REPO python REPO\houdini_mcp_server.py

생성된 .mcp.json:

{
  "mcpServers": {
    "houdini": {
      "type": "stdio",
      "command": "C:\\Users\\<이름>\\.local\\bin\\uv.exe",
      "args": ["run", "--directory", "REPO", "python", "REPO\\houdini_mcp_server.py"],
      "env": {}
    }
  }
}

시스템에 손댄 곳은 이 셋뿐이다: uv 설치, PREF 아래 junction·셸프 파일, .mcp.json. 각각 지우면 원복된다.

Install — (1) clone the repo, (2) install uv, (3) uv sync so the lock pins mcp 1.4.1, (4) junction the repo into PREF\python3.9libs\houdinimcp (the README's scripts\python path is not on 19.5's default sys.path), (5) drop a .shelf file with Start/Stop tools into PREF\toolbar, (6) claude mcp add -s project with the absolute path to uv.exe. Only three things touch the system: uv, the junction + shelf file, and .mcp.json.

■ 테스트 진행 순서

"Houdini 켜고 눌러본다"를 맨 마지막에 뒀다. 그 전에 사람 손 없이 검증할 수 있는 층을 아래서부터 쌓았다.

0층. 문법·임포트 — Houdini를 켜지 않고

플러그인이 Houdini 내장 Python 3.9에서 돌아야 한다. 최신 버전 기준으로 짠 코드에 3.10 이상 문법(match, X | Y)이 섞여 있으면 여기서 죽는다.

"C:\...\Houdini 19.5.368\python39\python.exe" -m py_compile REPO\server.py   # 통과
hython -c "from PySide2 import QtCore; import numpy, requests"                # 통과

1층. 브릿지 단독 — Houdini 꺼진 상태

등록한 명령 그대로 MCP 클라이언트로 띄워서 핸드셰이크·툴 목록을 확인했다. Houdini가 없으니 툴 호출은 실패해야 하고, 그 실패 메시지가 사람이 읽을 만한지를 봤다.

server: HoudiniMCP 1.4.1
tools: 25 ['get_scene_info', 'create_node', 'execute_houdini_code', ...]
get_scene_info: Could not connect to Houdini on 127.0.0.1:9876. Is the plugin running?

2층. 헤드리스 통합 테스트 — GUI 없이 진짜 hou

저장소에 tests/headless_host.py가 있다. hython으로 server.py를 띄우되 QTimer 대신 루프로 소켓을 폴링한다. 그 위에 tests/test_tools.py를 돌리면 노드 생성·파라미터·VEX 컴파일·지오메트리 조회·연결 교체까지 실제 hou API로 검증된다.

hython REPO\tests\headless_host.py 19878        # 터미널 1
uv run python REPO\tests\test_tools.py 19878    # 터미널 2
# → ALL 15 TEST GROUPS PASSED

19.5.368에서 15개 그룹 전부 통과. 여기까지 왔으면 GUI에서 안 될 이유는 셸프 로딩 정도만 남는다.

3층. 실제 GUI

  1. Houdini 실행 → 셸프 Start MCP → 상태바 HoudiniMCP server started on 127.0.0.1:9876
  2. netstat -ano | findstr :9876 → LISTENING
  3. 브릿지 경유로 /obj/mcp_test(geo) → box1 생성 → get_geometry_info가 점 8·프림 6·바운딩박스 1×1×1 응답
  4. 네트워크 뷰와 뷰포트에서 눈으로 확인 → delete_node로 정리 → /obj 비어 있음 확인
  5. Stop MCP → 포트 닫힘 → 툴 호출 시 1층과 같은 연결 오류 메시지

[스크린샷 ① — Start MCP 클릭 후 상태바. 이 줄을 지우고 Blogger 이미지 버튼으로 업로드]

[스크린샷 ② — 네트워크 뷰의 mcp_test / box1. 이 줄을 지우고 업로드]

Test order — Bottom-up, with the GUI last. (0) py_compile the plugin with Houdini's own Python 3.9 and import PySide2/numpy/requests in hython. (1) Launch the bridge alone as an MCP client: handshake, 25 tools, and a readable "Is the plugin running?" error with Houdini off. (2) The repo's tests/headless_host.py hosts server.py in hython without Qt; tests/test_tools.py against it passed all 15 groups on 19.5.368. (3) Real GUI: Start MCP → port listening → create geo+box through the bridge → eyeball it → delete → Stop MCP → clean connection error.

■ 이슈와 해결

1. mcp 2.x에서 브릿지가 안 뜬다 — 가장 큰 함정

브릿지는 from mcp.server.fastmcp import FastMCP를 쓴다. PyPI 최신 mcp(2.0, 2026-08~)는 이 모듈을 제거했고, 임포트하면 마이그레이션 가이드 에러가 난다. 저장소 uv.lock은 1.4.1을 고정하고 있어서 uv sync를 쓰면 안전하다. pip로 깔 거면 "mcp[cli]<2"로 고정해야 한다. README에는 이 얘기가 없다.

2. README의 scripts/python 경로가 19.5 기본 sys.path에 없다

hython에서 sys.path를 찍어보면 PREF\scripts\python은 없고 python3.9libs가 표준이다. SideFX Labs처럼 패키지 JSON으로 HOUDINI_PATH에 폴더를 추가한 경우에만 그 아래 scripts/python이 잡힌다. 그래서 python3.9libs\houdinimcp로 갔다.

덤으로 하나 더. Git Bash에서 hython을 돌리면 HOME이 C:\Users\<이름>으로 잡혀서 프리퍼런스 경로가 C:\Users\<이름>\houdini19.5로 바뀐다. 실제 GUI가 쓰는 Documents\houdini19.5와 다르다. 경로 검증은 PowerShell에서 해야 맞는 답이 나온다.

3. README §1.3 "패키지 JSON으로 자동 로드"는 동작하지 않는다 (이슈 #13)

Houdini 패키지 JSON은 경로를 추가할 뿐 Python 모듈을 임포트하지 않는다. 자동 시작을 원하면 PREF\scripts\456.py에 import houdinimcp; houdinimcp.start_server()를 넣는 게 맞는 방법이다. 이번엔 셸프 수동 시작으로 두고 자동 시작은 보류했다.

4. 서버가 단일 클라이언트다 (이슈 #14)

첫 클라이언트가 붙어 있으면 두 번째는 accept되지 않고 무한 대기한다. Claude Desktop과 Claude Code에 둘 다 등록하면 한쪽이 먹통이 된다. Claude Code 하나만 등록했다. (같은 이유로 blender-mcp도 9876을 쓰므로 동시 실행 금지.)

5. hython으로 브릿지를 돌리려 하면 안 된다 (이슈 #9)

이슈에 "hython에 mcp를 pip install하고 hython으로 브릿지를 실행하라"는 답이 달려 있는데, 이건 오답이다. hython은 site-packages-forced가 앞에 끼어들어 일반 패키지 임포트를 깨뜨린다. 브릿지는 시스템 Python 3.12로, 플러그인은 Houdini 안에서 — 구조 그림대로 분리하면 hython엔 아무것도 설치할 게 없다.

6. 작은 것들

  • uv 설치 후 PATH에 자동 등록되지 않는다. .mcp.json에는 uv.exe 절대 경로를 넣었다. Windows에서 spawn uvx ENOENT가 나오는 흔한 원인.
  • project 스코프 .mcp.json은 다음 세션 시작 때 승인 프롬프트가 한 번 뜬다. 이미 열려 있는 세션에는 반영되지 않는다.
  • langchain, langchain-classic 의존성은 OPUS(유료 에셋 API) 전용이다. 없어도 경고만 내고 뜬다. uv sync는 lock대로 다 깔지만 실제로 안 쓴다.

Issues — (1) mcp 2.x removed mcp.server.fastmcp; the lock pins 1.4.1, pin <2 if you use pip. (2) The README's scripts\python isn't on 19.5's default sys.path — use python3.9libs. Also, hython under Git Bash reports the wrong pref dir because HOME is overridden; verify from PowerShell. (3) README §1.3's package JSON doesn't auto-import (issue #13); use a 456.py hook if you want autostart. (4) Single-client server (issue #14): register only one MCP client. (5) Don't run the bridge under hython (issue #9); site-packages-forced breaks imports. (6) uv isn't added to PATH — use the absolute path; a project-scope .mcp.json needs approval in a fresh session; the langchain deps are OPUS-only.

■ 배운 것 / 막힌 것

  • 프로세스가 둘이라는 그림 하나로 이슈 대부분이 설명된다. hython에 뭘 깔아야 하나 헤맨 사람들(이슈 #9)은 그 그림이 없었다.
  • GUI는 마지막에. py_compile → 브릿지 단독 → 헤드리스 통합 테스트 순서로 쌓으니 GUI에서 사람이 할 일이 버튼 두 번 누르는 걸로 줄었다. 저장소에 headless_host.py가 있다는 걸 먼저 발견한 게 컸다.
  • lock 파일은 읽어야 한다. pyproject.toml의 mcp[cli]>=1.4.1만 보면 최신을 깔게 되고, 그러면 죽는다. lock이 1.4.1을 잡고 있는 건 우연이 아니었다.
  • 미검증: 렌더 툴 3종(render_single_view 등)은 헤드리스 테스트 범위 밖이라 19.5 뷰포트 API에서 도는지 아직 모른다.
  • execute_houdini_code는 Houdini 프로세스 안에서 임의 Python을 실행한다. 파일 삭제도 된다. 이 툴 호출은 사람이 확인하고 넘기는 규칙을 그대로 적용하기로 했다.

Learned / Stuck — One diagram (two processes) explains nearly every issue. Keep the GUI for last: compile → bridge alone → headless integration tests left only two button clicks for a human. Read the lock file, not just pyproject.toml. Unverified: the three render tools. execute_houdini_code runs arbitrary Python inside Houdini, so it stays behind a human-confirmation rule.


Sources

2026년 7월 29일 수요일

[TA #1] AI 릴레이 v1 — 교차 검수를 손에서 떼어내기 / AI Relay v1 — Taking Cross-Review Off My Hands

■ 목표

AI 두 개를 오가며 손으로 하던 교차 검수를 자동화한다. 지금까지는 한쪽에 보고서를 시키고, 그 결과를 복사해 다른 쪽에 "검수해줘"로 넘기고, 나온 지적을 다시 원래 쪽에 회신하는 걸 3라운드쯤 반복했다. 결과물은 좋았지만 그 왕복을 매번 내가 날랐다.

Goal — Automate the cross-review I used to run by hand, shuttling between two AIs. Until now I'd have one write a report, copy the result over to the other with "review this," then relay the feedback back to the first — about three rounds of that. The output was good, but I carried every round trip myself.

■ 오늘 한 것

Python으로 릴레이 스크립트를 만들었다. 과제를 md 파일에 써두면 네 단계가 자동으로 돈다 — Claude가 초안을 쓰고, Gemini가 검수하고, Claude가 수정하고, Gemini가 재검수한다.

역할 배치는 접근 권한 기준으로 정했다. Claude는 CLI로 실행돼서 로컬 파일을 직접 읽을 수 있으니 초안·수정을 맡기고, 로컬을 못 보는 Gemini는 문서만으로 판단하는 외부 검수자로 뒀다.

핵심은 검수자에게 판정 형식을 강제한 것이다. 그냥 "검수해줘"라고 하면 "전반적으로 좋으나 일부 아쉽습니다" 같은 답이 온다. 뭘 고쳐야 하는지도, 끝난 건지도 알 수 없다. 그래서 지시문에 형식을 못박았다.

REVIEW_INSTRUCTION = (
    "지적은 반드시 [치명]/[개선]/[취향]으로 분류하고 각각 근거를 붙여라. "
    "[치명]=사실 오류·잘못된 결론, [개선]=보완하면 좋음, [취향]=안 고쳐도 됨. "
    "마지막 줄에는 '판정: 통과' 또는 '판정: 재작업'만 써라."
)

형식을 강제해야 하는 진짜 이유는 그다음 줄에 있다. 코드는 글을 이해하지 못하고 문자열이 있는지만 본다.

if "판정: 통과" in review2:
    (run_dir / "final.md").write_text(revision, encoding="utf-8")

검수자가 정해진 문구로 답해야 기계가 읽고 판정할 수 있다. 나이아가라 유저파라미터를 스크립트에서 읽으려면 이름과 타입이 규약대로여야 하는 것과 같다. 형식 규약이 있어야 자동화가 성립한다.

What I Did — I built a relay script in Python. Write the task into an md file and four stages run on their own: Claude drafts, Gemini reviews, Claude revises, Gemini reviews again.

Roles were assigned by access rights. Claude runs as a CLI and can read local files directly, so it drafts and revises; Gemini, which can't see my machine, sits outside and judges from the document alone.

The key was forcing the reviewer into a fixed verdict format (first snippet above). Just asking "review this" gets you "solid overall, but a few things fall short" — which tells you neither what to fix nor whether you're done. So I nailed the format down in the instruction itself: every point classified as [critical] / [improvement] / [preference], and a final line reading either "판정: 통과" (pass) or "판정: 재작업" (rework).

The real reason for forcing that format is in the second snippet. Code doesn't understand prose — it only checks whether a string is present. The reviewer has to answer in a fixed phrase for a machine to read it and decide. It's the same as Niagara user parameters: a script can only read them when names and types follow the convention. Automation only holds up when there's a format convention.


■ 배운 것 / 막힌 것

1. 버전은 하드코딩하지 않는다

첫 실행은 404로 죽었다. 모델명을 이렇게 박아놨는데, 그 버전이 신규 사용자에게 막혀 있었다.

model="gemini-2.5-flash"   # 404 NOT_FOUND

이름을 바꿔가며 찍어보는 대신 API에 목록을 직접 물었다.

for m in client.models.list():
    print(m.name)

지금은 특정 버전 대신 별칭을 쓴다. 나중에 버전이 또 바뀌어도 코드를 안 고쳐도 된다.

model="gemini-flash-latest"

2. 트레이스백은 아래에서 위로 읽는다

에러가 스무 줄 넘게 쏟아져서 처음엔 어디를 봐야 할지 몰랐다. 위쪽은 에러가 지나온 경로일 뿐이고 맨 아래 한 줄이 원인이다.

3. 파이프라인이 죽으면 부품부터 단독으로 돌린다

Claude 호출이 안 될 때 스크립트 전체를 붙잡지 않고 명령어 한 줄로 먼저 테스트했다.

"OK라고만 답해" | claude -p

인증 만료라는 답이 3분 만에 나왔다. 스크립트로 확인했다면 "1단계 결과가 비어 있다"는 모호한 증상에서 시작했을 것이다.

4. 덮어쓰기는 실행별 폴더로 막는다

처음엔 결과 파일명이 고정이라 다시 돌릴 때마다 이전 결과가 사라졌다. 실행할 때마다 시각으로 폴더를 만들고, 과제 파일도 그 안에 함께 복사해둔다.

run_dir = WORK_DIR / datetime.now().strftime("%Y-%m-%d_%H%M%S")
run_dir.mkdir(parents=True, exist_ok=True)
(run_dir / "00_task.md").write_text(task, encoding="utf-8")   # 과제 스냅샷

결과만 남기면 나중에 "이 결론이 어떤 질문에서 나왔는지"를 알 수 없다.

5. 검수는 돌릴 때마다 새 [개선]을 찾아낸다

그래서 종료 조건을 "지적 없음"이 아니라 "[치명] 0"으로 잡은 게 맞았다. 개선까지 쫓으면 끝나지 않는다.

6. 왕복이 닫히기 전까지는 릴레이가 아니다

한 방향만 연결했을 때는 서로 소통해서 정제되는 게 눈에 보이지 않았다. 첫 검수 파일이 나오고 나서야 이게 릴레이구나 싶었다.

What I Learned, Where I Got Stuck

1. Don't hardcode versions. The first run died with a 404 — I'd pinned the model name, and that version turned out to be closed to new users. Instead of guessing names one at a time, I asked the API for the list directly (client.models.list()). Now I use the -latest alias, so the next version change won't touch the code.

2. Read tracebacks bottom-up. Twenty-odd lines poured out and at first I had no idea where to look. The upper lines are just the path the error traveled; the bottom line is the cause.

3. When a pipeline dies, test the parts alone first. When the Claude call failed, I tested one command line instead of wrestling with the whole script. The answer — expired authentication — came back in three minutes. Debugging through the script would have started from a vague symptom: "stage one came back empty."

4. Stop overwrites with a folder per run. At first the output filename was fixed, so every rerun erased the previous result. Now each run creates a timestamped folder, with the task file copied in alongside. Keep only the output and you lose track of which question produced which conclusion.

5. Reviewers find new [improvements] on every pass. That's why setting the stop condition at "zero [critical]" rather than "no comments" was the right call. Chase improvements too and it never ends.

6. It isn't a relay until the loop closes. With only one direction wired up, I couldn't see anything being refined between them. It only felt like a relay once the first review file appeared.

■ 다음 할 일

1차 검수에서 이미 통과가 나오면 나머지 단계를 건너뛰도록 조기 종료 조건을 넣는다. 지금은 통과든 아니든 무조건 4단계를 다 돈다.

Next — Add an early-exit condition so a pass on the first review skips the remaining stages. Right now it runs all four stages regardless.

Sources: Gemini API — Python quickstart, Claude Code CLI reference

2022년 5월 9일 월요일

(Niagara) 나이아가라 Overview

나이아가라를 활용하여 이펙트를 제작할시에는 Niagara Emitter/Niagara System을 가장 많이 활용한다.


나이아가라는 어떻게 구성되어 있는가?

나이아가라 시스템에 나이아가라 이미터 여러개로 구성된 형태로 이펙트를 제작한다.


나이아가라 이미터에 대한 이해

나이아가라 이미터는 크게 7가지로 분류할 수 있다. 
* 오렌지는 이미터와 관련된 설정이며 초록색은 파티클 자체의 설정

  1. 이미터 설정 : Local/World로 설정 여부, CPU/GPU
  2. 이미터 스폰 : 이미터 스폰은 처음 한번만 출력되는 설정
  3. 이미터 업데이트 : 프레임마다 업데이트되며 파티클이 출력되는 방식을 설정할 수 있다. 
  4. 파티클 스폰★ : 생성된 모든 파티클의 초기 설정
  5. 파티클 업데이트★ : 생성된 모든 파티클의 프레임별 설정
  6. 이벤트 핸드 추가
  7. 랜더 : 실제 화면상에 매치는 머티리얼 설정
fig01. Niagara Emitter


2022년 3월 22일 화요일

기본 노드의 기능 정리 - MathOperation

 *노드의 기능들을 공식처럼 바로 말 할 수 있도록 숙지가 필요함으로 다음과 같이 정리하도록 한다.

참고링크 : http://wiki.amplify.pt/index.php?title=Unity_Products:Amplify_Shader_Editor/Nodes


(다항연산)Saturate : 입력값을 범위를 0과 1사이로 제한한다. 0보다 작은 값은 0으로, 1보다 큰 값은 1로 출력한다. *Saturate 노드를 활용하여 0~1 범위 바깥의 의도치 않은 값들을 제거하여 라이트, 색상 연산 등에서 매우 자주 사용된다.

(백터연산) Dot 프로덕션 : Dot 프로덕션은 카메라가 물체를 바라보는 각도, 물체가 카메라를 바라보는 각도를 계산하여 0과 1의 값을 보낸다. ( 가운데 1, 외각 0 )


fig01. Dot Production Formula


Abs : 입력 값으이 절댓값을 출력하며 양수는 그대로 양수, 음수는 양수로 바꾸어 출력한다.

Add : 연결된 노드들의 값을 더한다. ( 색상은 더하면 밝아진다는 점을 유의하면서 사용한다. )

Ceil : 입력 값을 올림한 값을 출력한다. 예를 1.1은 2로 5는 5, -2.3은 -2이 된다.

Clamp : 값의 최솟값과 최대값 범위를 제한한다. ( Saturation과 Clamp(0,1)은 같은 기능을 구현한다.

DDX : 







2021년 10월 31일 일요일

ArtRayClass(5Week) : Depthfade, Dot Production, Vertex Normal, Noise Texture

*쉐이더를 제작할 시 어떤 기능이 필요한지 생각하고 해야 한다.

4주차에 제작된 쉐이더의 심화 과정

  • 기능을 조절하고 싶은때 제작한 노드 뒤편에 Power, Multiply 노드를 추가 시키면 된다.
  • Switch 기능은 제곱을 통한 연산을 하기에 3개 이상 쓰지 않도록 한다. 그럼으로 왠만하면 Switch와 비슷한 기능을 구현하는 Lerp 노드를 활용하길 권한다.
  • 시퀸스와 디졸브 쉐이더를 병합하여 사용하길 권한다.
  • 노드의 선을 더블 클릭하면 선의 형태를 변형할 수 있어 선 정리시 활용하면 좋다.
  • Vertex Normal은 버택스가 바라보는 방향, Tangent Normal은 Face가 바라보는 방향이다.
  • 바탕색이 빨간색인 노드는 Input Data로 Particle Emmitter에서 데이터를 가져오는 기능이다.

01. Depth Fade 추가 ( Alpha )

  • Depth Face는 1이 기본 값이다, 기본 값으로 Saturate은 Off로 설정되어 있는데 이로 인해 너무 밝게 나타나는데 그래서 반드시 On으로 설정 해줘야한다.
  • 만약 씬 뷰에서 Depth Fade가 적용이 됬으나 게임뷰 적용되지 않았다면 반드시 Project Setting에서 DepthFade 기능을 켜(fig02, fig03) 줘야 한다.
  • DepthFade 기능이 맞닿는 부분에서 출력이 되도록 설정을 하고 싶다면 OneMinus 노드를 Depthfade 노드 뒤에 추가 시켜주면 된다.
  • DepthFade는 무거운 기능임으로 기능 사용 여부를 선택할 수 있는 Static Switch를 연결주길 권한다.
fig01. Depth Fade Node

fig02. Depth Fade Setting 01

fig03. Depth Fade Setting 02


02. 외각 색상 노드 Fresnel ( Alpha )

  • Frenel 노드는 Dot Production의 기능을 노드화 시킨 노드로 이해하면 좋다.
  • Dot Production은 링크를 통해 간단한 기능 구현에 대한 설명을 보면 된다.

fig04. Fresnel Node

03. World Position Offset Node

  • Vertex Offset은 Add로 좌표값의 위치를 수정한다고 생각하면 된다. ( 기본 값은 0이다. )
  • Vertex Normal을 통해 다이다믹한 형태를 표현하고 싶다면 다음과 같은 노드들을 추가시켜준다. (LERP 노드)

fig05. World Position Offset Node


04. Grandient Color Node ( Color )

그라데이션 색을 주기 위해 다음과 같은 노드(Fresnel, UV/Component Mask)를 Color 값에 연결해준다.

fig06. Color Gradient Node

05. Master Node Final Result

fig07. Master Node Final Result


※ 노이즈 텍스쳐 그리는 방법론 ※

  • 2021 버전 부터 패턴 미리보기 기능이 있어 노이즈/타일 텍스쳐를 그릴때 활용하면 좋다.
  • 노이즈를 그릴때 흰색과 검정색의 비율이 중요하다. ( 흰색 비율이 많을 수록 바람/연기 계열, 횐색 비율이 적을수록 오로라 계열의 노이즈 텍스쳐 )
  • 노이즈 텍스쳐는 UV 스크롤을 활용하기에 어느 방향으로 흐를지 생각하고 그리길 권한다.

  1. 노이즈의 형태를 그려준다.
    fig08. Noise Shape

  2. 손가락 툴을 활용하여 움직일 방향성에 맞춰 형태감을 수정해 준다.
    fig09. Noise Smudge

    • *북미풍은 Blur한 텍스쳐를 선호하고 일본풍은 칼 같이 깔끔한 형태감을 선호한다.
  3. Motion Blur 효과를 넣어준다.
    fig10. Noise Motion Blur

  4. Glow 효과를 넣어준다.
    fig11. Noise Glow



2021년 10월 10일 일요일

ArtRayClass(2Week) : 라인 & 그라운드 스모크

라인 텍스쳐 제작 방법론

1개의 텍스쳐 사이즈 :  512/256 

  1. 라인 텍스쳐를 그린다 ( 다이아몬드 형태 )
    • 라인 텍스쳐를 그릴 경우에는 앞 머리를 기준으로 작업을 진행한다.(핵심)
  2. 라인의 위/아래의 넓이만 줄인다.
    • 타임 라인 줄이는 단축키 설정법
      • KeyBoardShotCut ( Edit )
      • Appilcation -> Pannel Menu
      • TimeVideo -> Trim End at Playhead ( Move and Trim ) - Cntrl E로 단축키
  3. 라인의 위/아래 넓이를 줄이고 라인의 꼬리부분의 길이를 줄여줍니다. ( 2 덩어리로 분할 )
  4. 위/아래의 넓이를 조금 더 줄이고 각 부분을 조금식 더 지운다. ( 3 덩어리 )
  5. 위/아래의 넓이를 조금 더 줄이고 4번에 제작한 2덩어리의 위치를 앞으로 살짝 움직인다. 
  6. 위/아래의 넓이를 조금 더 줄이고 5번에 제작한 2덩어리의 위치를 앞으로 살짝 움직인다.
  7. 6 프레임의 덩어리를 좀 지우고 2덩어리였던 부분을 1덩어리만 남기고 지운다.
  8. 7 프레임의 덩어리를 좀 지우고 뒷 덩어리 앞으로 조금 이동 시킨다.

fig01. LineTexture Final Result

※ 텍스쳐 시트 제작 방법론 ※

  1. 배경에 색 Layer를 깔아준다. 그러는 이유는 각 텍스쳐의 위치를 잡아줄 시 사이즈 맞게 이동 시키기 위함에 있다.
  2. 만든 시퀸스들과 배경색 레이어를 한번에 잡고 그룹으로 묶어준다.
  3. 필요한 크기의 새로운 캔버스를 생성해준다.
  4. 2번에서 만든 그룹을 복사해서 넣어준다.
  5. 배경 색 Layer를 기준으로 이미지들을 이동해준다.

※ 후반 Glow/그라데이션 작업 ※

  1. 레이어들을 묶은 그룹레이어에 OuterGlow이펙트를 넣어준다.
    • 마지막 결과물을 위한 세심한 Glow 효과를 내기 위해서는 전체적으로 Glow를 주기보다는 각각의 이미지에 맞는 Glow를 줘야한다.
  2. 각 텍스쳐에 그라데이션의 효과를 넣기 위해 그라데이션 레이어를 생성하여 기존에 Glow를 줬던 그룹에 Clipping Mask 해준다.


※ 텍스쳐가 정사각형이야 되는 이유 ※

유니티는 자체적으로 이미지를 압축하는 방식이 있는데 그 방식은 다음과 같다. 가장 긴 길이를 기준으로 정사각형의 이미지로 변경해서 엔진에 넣는다. 예를 들어 1024X512 이미지가 있다는 가정하에 유니티에 넣었을 때 유니티에서 이미지를 1024X1024로 임의 변경하여 엔진에 넣는다. 그렇다보니 Unity가 자동으로 정사각형으로 수정하는 과정에서 이미지가 손상되기 때문에 이미지를 제작할 시 정사각형의 형태를 유지하면서 이미지를 제작해줘야 한다.


그라운드 스모크 제작 방법론 ( 1024 /171 )

* 그라운드 스모크 그리는 방식에는 형태를 스케치해서 그리는 방식과 면을 채우면서 그리는 방식이 있다.
* 그라운드 스모크를 그릴 시 뒤로 밀린다는 느낌을 내는 것이 중요하다.


※ 주의 사항 ※

  • 가장 큰 방향성을 가지는 웨이브 간에는 어느 정도의 평행을 유지 해줘야 한다.
  • 가장 밑의(1~4)의 라인을 어느 정도는 유지해줘야 한다. 왜 그런가 하면 밑의 라인을 유지함으로써 옆으로 쓸리는 느낌을 내기 위함에 있다.
  • 형태를 겁 먹지 말고 앞으로 길게 뺀다는 느낌으로 작업을 한다.
  • 큰 형태들을 생각하면서 작업을 진행한다.
  • 하나, 둘, 셋 느낌으로 바람 형태를 잡는 것이 좋으며 반복 숙달하는 것이 중요하다.
  • 만약 형태가 잘 안 잡히면 작업 중인 이미지를 수정하기보다는 이미지를 Hide 시키고 다시 그리는 걸 권장한다.
  • 가운데를 가장 크게 그려주면 좋다. 왜 그런가 하면 사람들이 가장 눈이 많이 가는 부분이 중앙 부분이라 중앙을 잘 표현하면 효과가 좋다.
  • 하단 부분을 최대한 간단하게 그리면 좋다.
  • 너무 높은 각도를 가지는 웨이브는 지양한다. ( 적당한 각도 30~70 )
  • 1번 이미지의 형태는 볼륨감(부피) 있게 그려줘야 한다.


  1. 기초가 되는 스모크 텍스쳐를 그린다.
  2. 앞을 기준으로 반을 잘라서 중앙이 넘어갈 정도로 오른쪽으로 당겨줍니다. 그리고 다시 그린다는 생각으로 뒤의 부분과 연결을 시켜준다.
  3. 앞과 중간을 각각 뒤로 조금 밀어줍니다. 이때 오른쪽으로 이미지를 당기는 것 뿐만 아니라 Rotation 값도 조금 줍니다. 또한 가장 뒷부분을 분할해 줍니다. 
    • * 3번이 가장 높이가 높은 단계임을 생각하면서 작업한다.
  4. 맨 앞 부분을 짤라서 뒤로 조금 밀어주고 여러 부분으로 끊어주면서 형태감을 잡아준다. (HARD)
  5. 앞 부분은 조금 옆으로 밀어주고 볼륨을 지워주면서 형태감를 만들어준다.
  6. 큰 덩어리는 조금 더 뒤로 밀어주고 볼륨을 지워주면서 형태감을 만들어준다.
fig02. Ground Smoke Final

※ 텍스쳐 시트에 필요한 이미지 수 ※

대체적으로 필요한 이미지의 수 일뿐 반드시 동일한 이미지의 수일 필요는 없다.

  • 그라운드 스모크 : 4 - 6
  • 불 : 12/16
  • 번개 : 12
  • 링 : 4 6 9


※ 추후 작업 ※

실린더 제작 

  • 윗면과 아랫면을 지운 다음에 아래 라인을 잡아줘서 스케일을 줄인다. 최종적인 형태는 깔때기 모양으로 제작해준다.


Tip. RandomSeed - 동일한 형태의 랜덤 값

Tip. 연기를 제작 할 시 앞면과 뒷면을 표현하기 위해 파티클 이미터를 복사해줍니다. - 안에 면에는 밝게, 밖에 면은 어두운 계열의 색상으로 표현. {CullMode - Front(쉐이더에서는 Back으로 설정)}

Tip. RenderCue의 숫자가 높을 수록 상단으로 랜더가 된다.


2주차 과제

  • 오늘 작업한 바람 쉐이프, 라인 텍스쳐 추가
  • 3초 유지되는 기 모으는 이펙트 제작

2021년 10월 4일 월요일

ArtRayClass(1Week) : 이펙트에 대한 이론& Circle 이펙트 제작

이펙트에 대한 이론

이펙트에 대한 피드백을 줄 때 정확하게 피드백을 주질 못하는 경우가 많다. 그래서 다음과 같은 단계로 이펙트를 나눠줌으로써 피드백에 대한 이해도를 높이기 위한 가이드로 사용하면 좋을 것이다.


총 5단계로 이펙트를 구성 - 다만 모든 이펙트가 다음의 단계는 아니라는 점을 유의

  • 1 단계 - 차지
  • 2 단계 - 발동
  • 3 단계 - 유지
  • 4 단계 - 폭발, 피격, Hit
  • 5 단계 - 여운


시퀸스(Flipbook) : 연속으로 재생되는 이미지 

  • 캐주얼 게임 기준에서 시퀸스는 4,9,10,12,16장으로 구성 / 다만 실사 이펙트는 예외의 경우가 있다.
  • 16장 이상 쓰는 시퀸스의 경우 너무 부드럽게 재생이 되어 오히려 게임보다는 애니메이션 스러운 분위기를 만든다.


시퀸스의 종류

루프형  SQ

  • 첫 프레임과 끝 프레임이 동일하다 
  • ex) 환경 이펙트-모닥불, 스모크, 번개 

소멸형 SQ

  • 가장 화려한 프레임(발현형 프레임으로 보면 중간 프레임)부터 시작하며 서서히 사라진다 
  • ex) 히트 이펙트, 맞는 순간 터져야되기 때문에 히트 이펙트에서 자주 활용된다. - 가장 메인이 되는 이펙트 

발현형 SQ

  • 기승전결이 있는 시퀸스

연출형 SQ

  • 카메라에 붙는 이펙트
  • ex) 안에서 밖으로 또는 밖에서 안으로 들어오는 이펙트, 초 근접 이펙트, 라이트 이펙트, 화면을 가르는 이펙트


유니티랑 언리얼의 가장 큰 차이점?

: 때깔의 차이가 있다

왜 그런가하면은 언리얼은 RGBA는 HDR컬러는 진작부터 사용을 할 수 있었다. - 하지만 현재의 유니티에서는 HDR을 활용할 수 있다.


유니티 프로젝트 종류

  • 3D - 예전 게임
  • HDRP - 고사양 랜더 파이프 라인
  • URP - 유니버셜 랜더 파이프 라인

Tip. 포토샵의 교집합 기능 - 마법진을 제작할 때 사용된다


01. 링 이펙트 제작 방법론

  1. 링을 하나를 생성한다.
    fig01. Create Ring

  2. Circle이펙트의 형태를 잡을 때 가이드가 될 링 레이어를 하나 복사한다.
    fig02. Guide Layer

  3. Window - timeline (Create video Timeline)을 만들어 준다.
    fig03. Video Timeline

    Tip. 하단의 산 마크는 타임라인 확대 기능
    Tip. Timeline을 활용할때는 Onion Skin 기능을 켜준다. ( Onion Skin setting -> Normal )
  4. 브러쉬를 활용하여 기존의 Circle을 수정하여 Circle 이펙트를 그려준다. ( 사라지는 이펙트를 만들때 가장 외각에 있는 선들은 왠만해서는 건들지 않고 기준으로 잡아준다. )
    fig04. Circle SQ

Tip. 손의 방향에 맞게 Rotation을 돌리면서 작업을 진행한다.


※중요

  • 4장 짜리를 그릴때는 프레임간의 변화를 과감하게 진행해야 한다.
  • 4장 짜리를 그릴 때는 복잡한 쉐이프를 그리면 안된다.
  • 가장 첫번째 프레임은 반드시 이쁘게 그린다.
  • 이펙트 시퀸스를 그릴때는 찌꺼기가 남지 않도록 깔끔하게 그림을 그려야한다.
  • 쉐이프는 확실하게 끊어줘야한다. ( Opacity를 남겨주면 안된다. 반드시 덩어리로 진행해야된다. )
  • 시퀸스는 반드시 한번에 쭉쭉 그려/지워야 한다.


1주차 과제

  • 링을 3세트 제작(엣지, 굵기)
  • 엔진상에서 차지 이펙트 제작 (Glow에 오늘 배운 링을 섞어서) / 단. 본인 좀 더 초과해와도 된다. (Glow+링)