[Frontend] 3D 로고 페이드인 최적화

목차 (OPEN)

• 📑 들어가며
• 🟥 초기 페이드인 코드
• 🟧 수정 과정
• 🟨 결과 화면

 

 

 

 

📑 들어가며

나는 지금 스크롤을 내리면서 내 소개와 프로젝트 등을 볼 수 있는
개인 포트폴리오 사이트를 만드는 중이다.

 

그중에서도 가장 첫 번째 섹션인 히어로 섹션에서는
이전에 블렌더로 3D 모델링했던 내 이름 로고를 렌더링해서 보여주고 싶었다 🤧

 

그리고 이때, 단순히 3D 모델을 올리고 끝나는 것이 아니라,

기본적으로는 자동으로 살짝살짝 회전을 하고 있되,

사용자가 마우스로 드래그하면, 그 회전을 사용자 입력에 따라 반영하고,

마우스를 놓는 순간, 그 상태를 기준으로 다시 자동 회전이 이어지는 것을 원했다.

 

또한, 처음엔 사이트를 들어오는 순간 로고가 바로 등장하게 했더니 너무 부자연스러워서

자연스러움을 위해 부드럽게 페이드인 되면서 등장할 수 있게 만들고 싶었다.

 

 

그래서 이번 포스팅에서는 일단 페이드인을 어떻게 구현했고,

어떻게 최적화했는지를 정리해보려고 한다.

 

 

---

🟥 초기 페이드인 코드

처음 페이드인을 구현했을 땐 정말 ,, 직관적으로 코드를 짰다.

 

부끄럽지만 ,, 아래 코드에서 볼 수 있듯이

처음에는 재질의 opacity를 0으로 만들어서 안 보이게 했다가

매 프레임마다 opacity를 조금씩 증가시켜서 1에 가까워지도록 만들었다 ,, 😅

useEffect(() => {
  scene.traverse((obj) => {
    if (obj instanceof Mesh && obj.material instanceof MeshStandardMaterial) {
      obj.material.transparent = true;
      obj.material.opacity = 0;
    }
  });
}, [scene]);

useFrame(() => {
  scene.traverse((obj) => {
    if (obj instanceof Mesh && obj.material instanceof MeshStandardMaterial) {
      if (obj.material.opacity < 1) {
        obj.material.opacity += 0.01;
      }
    }
  });
});

 

솔직히 이때까지만 해도 '오 ! 내가 원한대로 잘 나타나는군 !! 생각보다 쉽네 !? 😏' 했다.

 

하지만 나중에 R3F와 Three.js 관련 글들을 좀 더 찾아보니

이 코드에는 두 가지의 큰 문제가 있다는 사실을 깨닫게 되었다.

 

 

문제점 1) 매 프레임마다 scene.traverse를 호출하고 있음

첫 번째 문제는 성능 부분이었다.

useFrame(() => {
  scene.traverse((obj) => {
    ...
  });
});

 

기존 코드에 있던 이 부분을 다시 보면, 매 프레임마다 실행되는 것을 알 수 있다.

일반적으로 초당 60프레임 정도로 돌고 있다고 치면, 1초에 60번 scene.traverse를 호출하고 있는 것이다..

 

뭐 scene.traverse가 단순한 함수이면 모를까

이 함수는 scene 안에 있는 모든 obeject를 재귀적으로 훑는 함수라는게 문제였다.

 

예를 들어 GLTF 모델 안에 Mesh가 10개이면 10개를 매 프레임마다 탐색하는 거고,

100개면 100개를 매 프레임마다 탐색하는 것이다.

 

따라서 opacity를 약간 올려주고 싶다는 이유만으로 매 프레임 전체 구조를 훑고 있다는 게 너무 비효율적인 것 같아서

이 부분에 대해서 개선을 할 필요가 있다고 생각했다.

 

👉🏻 그래서 내가 생각한 이 문제의 해결법은 'mount될 때 한 번만 traverse 하도록 하자'였다.

 

 

문제점 2) 프레임 의존적인 애니메이션

두 번째 문제는 애니메이션의 속도였다.

if (obj.material.opacity < 1) {
  obj.material.opacity += 0.01;
}

 

이 방식은 결국 한 프레임에 opacity를 0.01씩 증가하는 것인데, 프레임 수는 환경마다 다르다는 것이 문제였다.

 

어떤 기기에서는 60fps일 수도 있지만, 어떤 환경에서는 30fps 이하일 수도 있고,

브라우저 탭이 백그라운드로 가며 프레임 레이트가 떨어질 수도 있기 때문에

60fps에서는 더 빨리 페이드인 되고, 30fps에서는 두 배 느리게 페이드인 되는 등

기기 성능에 따라 애니메이션의 길이가 달라지는 현상이 생길 수 있다.

 

👉🏻 따라서 해결책으로 이 구조를 프레임 수가 아닌 시간을 기준으로 움직이도록 수정하고자 했다.

 

 

---

🟧 수정 과정

위에서 잡은 수정 목표를 정리해보면 아래와 같다.

• scene.traverse는 딱 한 번만 한다.
• 애니메이션은 프레임 수가 아니라 시간을 기준으로 움직이게 한다.

 

그리고, 이를 위해 가장 먼저 한 작업이 재질을 한 번만 모아두게 하는 것이었다.

왜냐면 매번 traverse를 도는 이유가 결국 어떤 mesh의 어떤 material에 opacity를 적용해야 하는지를 찾기 위함이기 때문이다.

 

그렇기에 한 번만 찾아서 저장해두고, 그 이후에는 그 목록만 돌면 이 문제를 해결할 수 있을 거라 생각했고,

따라서 아래와 같이 페이드인 대상이 되는 재질들을 모아두기 위한 ref를 추가해주었다.

const materialsRef = useRef<MeshStandardMaterial[]>([]);

 

 

그리고, useEffect에서 마운트 시 딱 한 번만 scene.traverse를 돌도록 수정해주었다.

useEffect(() => {
  const collected: MeshStandardMaterial[] = [];

  scene.traverse((obj) => {
    if (obj instanceof Mesh) {
      obj.castShadow = true;
      obj.receiveShadow = false;
    }

    if (isMeshWithStandardMaterial(obj)) {
      const material = obj.material;
      material.transparent = true;
      material.opacity = 0;
      material.needsUpdate = true;
      collected.push(material);
    }
  });

  materialsRef.current = collected;
}, [scene]);

 

여기서 하는 일은 크게 두 가지이다.

• 그림자 설정
  • obj.castShadoe = true;
  • obj.receiveShadow = false;
• 페이드인 대상 재질 수집
  • MeshStandardMaterial 타입의 재질만 골라서
  • transparent = true, opacity = 0으로 초기화하고
  • materialsRef.current 배열에 모아둔다.

이렇게 해줌으로써 이 작업은 마운트 타이밍에 딱 한 번만 일어나게 된다.

 

이후 useFrame에서는 더이상 scene.traverse를 호출할 필요가 없고,

그 대신 materialsRef.current 배열을 돌면서 opacity 값만 업데이트하면 된다.

 

 

이렇게 수정함으로써 GLTF가 아무리 복잡해져도,

매 프레임 비용은 재질의 개수 만큼만 늘어나게 제한할 수 있도록 최적화가 된 것이다 !

 

 

---

 

 

다음으로 고친 부분은 opacity 증가 로직이다.

 

기존에는 아래와 같이 프레임마다 0.01씩 증가시키고 있었다면,

opacity += 0.01;

 

이제는 수정 목표에 따라 '몇 초 동안 0에서 1까지 바꿀 것인지'를 기준으로 제어할 수 있도록 고치고 싶었다.

 

그래서 떠올린 아이디어가 '페이드인이 시작되는 시각을 기억해두고,

매 프레임마다 `현재 시각 - 시작 시각`을 해주면, 그게 곧 경과 시간임을 이용하자' 였다.

 

따라서 이를 위해 페이드인의 시작 시점의 시간을 저장할 아래의 ref를 하나 더 추가해주었다.

const startTimeRef = useRef<number | null>(null);

 

그리고 useFrame에서는 R3F가 제공하는 clock을 이용해서 아래와 같이 만들어주었다.

useFrame(({ clock }) => {
  if (materialsRef.current.length === 0) return;

  if (startTimeRef.current === null) {
    startTimeRef.current = clock.getElapsedTime();
  }

  const elapsed = clock.getElapsedTime() - startTimeRef.current;
  const rawT = Math.min(1, elapsed / fadeDuration); // 0~1
  const t = rawT * rawT * (3 - 2 * rawT); // 부드러운 이징

 

여기에서 clock.getElapsedTime()은 씬이 시작된 후 흐른 시간(초 단위)이고,

startTimeRef.current에는 페이드인 시작 시점의 시간을 저장해주었다.

그리고 elapsed에는 시작 후 얼마나 지났는지를 저장했으며,

elapsed / fadeDuration을 통해 0 ~ 1 사이의 비율로 정규화해주었다.

(예를 들어서 fadeDuration = 2.5라 가정하면, 0초일 땐 0, 1.25초일 땐 0.5, 2.5초 이상일 땐 1이 되는 느낌)

 

또한, 아래의 식을 적용해서 0에서 1로 갈 때 처음과 끝이 좀 더 부드러운 S-곡선을 만들어주도록 하였다.

(일종의 smoothstep 형태라고 보면 된다.)

const t = rawT * rawT * (3 - 2 * rawT);

 

그리고 이렇게 계산해낸 t를 opacity에 그대로 반영해주었다.

materialsRef.current.forEach((mat) => {
  mat.opacity = t;
  mat.needsUpdate = true;
});

 

이렇게 해줌으로써 이제는 프레임 수에 상관 없이 항상 같은 시간 동안 페이드인이 진행되고,

값도 0 ~ 1 사이를 S-곡선 형태로 부드럽게 채워지도록 되었다.

 

 

---

 

 

또한 마지막으로는, 어차피 opacity가 1이 된 이후에는 더이상 계속 useFrame에서 처리할 필요가 없다고 생각해서

페이드인이 끝났음을 나타내는 플래그를 하나 두고, 그 이후에는 useFrame에서 콜백으로 바로 return 해버리도록 만들었다.

(위에 까지만 수정했을 때의 구조에서는 rawT가 1에 도달한 이후에도 계속 같은 값을 다시 opacity에 넣고 있었다.)

const doneRef = useRef(false);

if (rawT >= 1) {
  doneRef.current = true;
}

if (doneRef.current) return;

 

이렇게 수정함으로써 rawT가 1에 도달하는 순간 doneRef.current = true로 변경하고,

그 이후 프레임부터는 if (doneRef.current) return; 에 걸려서 early return된다.

 

즉, 페이드인 애니메이션이 끝난 시점부터는 사실상 이 컴포넌트는 useFrame에서 아무것도 하지 않는 상태가 된다.

 

따라서 장기적으로 보면,

이 페이지를 계속 켜두고 작업하거나 탭이 오랫동안 열려 있는 상황에서도 불필요한 연산을 최소화한 구조가 된다.

 

 

---

🟨 결과 화면