렌더링 문답.

On Thursday 28th October 2010, @hika00 said:

#as3t 3D플래시 어플리케이션을 만들며 문답.....................김:
음 제가 이번에 이 3D 작업 해보면서.. 어떻게 만들긴 했는데
상당히 cpu를 먹더라구요 '';

맹:
암튼 3D는 cpu를 많이 먹어 그건 사실이잖아

김:
네 이거 어쩔 수 없는건가요??
음 지금 cpu 모니터링 해보니까 대략 평균이 30% 정도..
그 cpu를 많이 먹게 되니까 페이지에 있는 다른 swf 들에도 영향을 되게 많이 끼치더라구요???

맹:
그럼 어떻게 적게 먹게 만드냐인데 정답은 최대한 render를 덜 호출하는거지

김:
전에 블로그에서 본 것 같아요

맹:
render를 얼만큼 적게 호출하냐에 대한 답은 가능하면 많이 돌린다가 답이잖아
그리고 화면을 잘보고 3D객체여야하는것만 넣고 최대한빼
그리고 무엇보다 비트맵..매핑소스가 되는 비트맵사이즈를 될수있는대로 많이 줄여
원본 비트맵이 크면 uv를 계산하기 위해 부하가 많이 걸려

김:
아

맹:
정점이 똑같아도 컬러재질과 비트맵재질은 차이가 심해 비트맵 사이즈를 될수있는대로 줄여야하는거지

김:
비트맵 사이즈는 현재 크진 않고 음

맹:
렌더를 될 수 있는한 호출하기라는건
실제 현재의 프레임레이트를 알아야한다는거야
그건

function enter( $e:Event){
count++
}

이렇게 해보자.
그럼 엔터프레임이 올때마다 카운트를 하니까 이걸 일정시간마다 체크할 수 있지

checkTime = getTime() + 1000;

이라고 하면 현재시간으로부터 1초후니까

if( getTimer() > checkTime ){

이 조건을 통해 1초후를 인식할 수 있지 그럼 지금까지 말한걸 종합해보자

checkTime = getTime() + 1000;
function enter( $e:Event){
count++
if( getTimer() > checkTime ){
fps = count;
count = 0;
checkTime = getTime() + 1000;
}
}
}

1초에 몇번 엔터에 들어왔나니까 이렇게 하면 리얼타임의 fps를 얻을 수 있지

김:
네

맹:
그럼 반대로 실행할때 저 단위 이하로 호출해봐야 부하만 걸릴뿐 작동도 안한다는 얘기지
만약 fps가 30으로 측정되었다면 1초동안 30회 호출하는 비율 이상 호출해봐야
큐에 쌓일뿐 무의미하다는거지

김:
아아 소용이 없는거죠

맹:
따라서 이 개념을 그대로 rate로 바꾸면

fps = count;
rate = 1000/fps;

이렇게 rate를 구할 수 있지 만약 fps가 30이라면 1초에 30번만 실행할 수 있다는 뜻이니까
rate로는 33 ms마다 실행하는게 적당하다는 결론에 이르지

김:
아하

맹:
그럼 rate를 이용해서 render를 호출하면

if( getTimer() > rateCheck ){
render();
rateCheck = getTimer() + rate;
}

이렇게 되지. enter안이 전체적으로는 이렇게 되겠지

checkTime = getTime() + 1000;
rate = 10;
function enter( $e:Event){
count++
if( getTimer() > checkTime ){
fps = count;
rate = 1000/fps;
count = 0;
checkTime = getTime() + 1000;
}
}
if( getTimer() > rateCheck ){
render();
rateCheck = getTimer() + rate;
}
}

김:
오오

맹:

따라서
count는 fps를
fps는 rate를
render는 rate에 따라서 호출되니까
cpu부하가 심한 컴에선 render가 덜호출되고
cpu가 좋으면 부드러운 애니메이션을 만들어낼 만큼 render가 호출된다
중요한건 어떤 경우에도 cpu가 무리하지 않는다는거지!
왜냐면 cpu가 무리할만큼 자주 호출하지 않기 때문이지
이러한 cpu부하는 심지어 조정도 되는데

fps = count;
rate = 1000/fps;

이게 cpu를 한계로 쓰는거라면

fps = count;
rate = 1000/(fps+10);

이러면 더 여유있게 cpu를 쓰지 반대로

fps = count;
rate = 1000/(fps-5);

이러면 더 cpu를 빡빡히 쓰지
내가 실험해본바로는 아무것도 안하면 저 로직이 보통 cpu 70~80을 써
약간 위로도 여유가 ㅇㅆ어

김:
네

맹:
그외에 애니메이션같은건 전부 트위닝을 하고 있을테니 시간베이스라 render가 덜호출되도 상태는 갱신되어있을거야
이 로직을 쓰려면 모든게 프레임베이스의 누적연산같은걸 하면 안되고 시간베이스로 연산하도록 되어있어야해

x+=10

이런거 있으면 안되는거지

김:
음 현재 그런건 카메라 위치 조절하는 것만 있네요.. 음.

맹:
x = start + (getTimer()-startTime)*5
}
머 이런식으로 시간베이스로 되어있어야해
머신차이는 부드러운 정도로 반영되고

김:
네 부드러운 차이요
근데 여기 개발팀이 그 부드러운 차이 때문에 또 꽁시랑 거릴 것 같은 느낌이 드네요 ㅋㅋ;

맹:
pv3d기반인가?

김:
아뇨 어웨이요

맹:
너무 성능이 안나오면 얼터너티바써 완전무료로 선언해서 상용으로도 전혀 문제없어졌당
얼터너티바가 단순 오브젝트 표시에는 유리한데 이미지가 좀 거칠게 나오지

김:
네 일단 좀 다른 최적화와 같이 render 호출이랑 진행해보고 해봐야겠네오ㅛ ;;

맹:
오직 모델하나만 덜렁있는건가? 배경이랑 기타여러가지도 있는건가 암튼 어웨이에서 최대한 꺼내버리라는

김:
3D는 모델만 있어요

맹:
그리고 정점수좀 심하게 줄이라고 해 디테일한 표현이 필요하면 매핑으로 해결하거나 부족하면 노말맵달라고해

김:
아 현재 약 1500개 정도 되요

맹:
음..무리다. 그넘이 골격애니를 쓸거잖아

김:
네

맹:
1000개까지 줄이는게 좋은데..참.
모델링데이터는 베이킹했지? as로

김:
모델링데이터요 ?

맹:
응

맹:
dae로딩해써?

김:
네

맹:
AS3Exporter 를 파라!

김:
헉?!

맹:
var export:AS3Exporter;
export = new AS3Exporter;
export.addEventListener( ExporterEvent.COMPLETE, function( $e:ExporterEvent ):void{
$e.target.removeEventListener( $e.type, arguments.callee );
trace( $e.data );
} );
export.export( 객체, $className, $pakageName );

이렇게 되면말야 trace에 as파일을 만들 수 있는 내용이 나와

김:
네

맹:
그럼 그걸 저장해서 as로 만들고 import해서
model = new model
이렇게하면 만들어진단말이지
이렇게 만들어지는 객체가 훨씬 더 고속이고 로딩부하도 없어지고

김:
그렇겠네요! 확실히 근데 현재 제가 사용하는 캐릭터가
hair / face / eye / up / down

맹:
다 받아 다 구워

김:
오

맹:
재질만 후기바인딩해 무슨얘기냐면 재질을 dae에 기술할때
아무렇게나 경로를 지정하고 실제로 그 경로에 이미지를 두지마 모델 로딩이 완전히 끝난뒤어

for( key in material ){
$e.result.materialLibrary.getMaterial( key ).material = getMaterial( material[key] );
}

이런식으로 후기바인딩해버려

김:
모델 로딩 후 - > 맵핑 인거네요 ?

맹:
그치 이미 uv맵정보와 uv맵별 이름은 다 dae에 기술되어있잖아
그 이름대로 그냥 넣는거야

김:
네 애니메이션도

맹:
dae애니메이션이 사실은 용량은 적은데 부하는 심해
애니메이터들이 말야 정점이 뼈 두개이상으로부터 영향을 받도록 잡으면
더욱 심각해져 왠만하면 정점하나가 뼈하나에만 대응하게 만들어달라고 하는게 좋아
맥스랑 뒹굴어..

김:
그게 참 3D에 관해서 뭐 하기가 어려운게 제가 만지는 것도 아니고
저쪽에서 해주는건데 한계가 있어요 ㅠㅠ
그것만 가지고도 거의 1주 2주 동안 저기랑 싸웠어요

맹:
짜피 모델러들이 하는건 한계가 있어 그게 다시 말하지만 맥스랑 뒹굴기전엔 해결이 안된다는

김:
그렇군요 거의 원론적인 collada문제 까지 가는거네요

맹:
원래 공사를 했으면 계획은 걍 max만 주세요 였어

김:
아아

김:
저도 처음에 max 받고 max 설치까지 하긴 했는데 ㅋㅋㅋㅋ 아 화나서
뭐 플러그인이랑 뭐 설치 했는지 어떻게 해야 되는지도 안 알려주고 해서
알려달라해도 저기 가보세요 여기 가보세요 막 이러고

맹:
맥스가 내몸처럼 편해야해

김:
네 그렇군요
아무래도 맥스를 다시 만져보는게 옳겠네요

맹:
그게...애들 놀때나 프리머티브지
상용세계에서 조그만 조각하나라도 직접 모델링을 만드는 경우가 있겠냐
그건 마치 플래시에 setPixel과 드로윙api로 화면을 그리겠다는거나 마찬가지 발상이잖아
당연히 실무세계는 맥스나 마야로 넘어오는거지

김:
그렇죠

맹:
그럼 우리가 디자이너에게 psd를 받고 이상하다고 psd를 다시 달라고 하거나 모든 조각을 전부 png로 달라고 하느니
포샵을 열어서 자유롭게 쓰는게 더 편한것처럼
맥스도 그래야해 마야나 맥스 둘중 하나면 족해