7월 21일
주간보고
이번 한 주간 또다른 무수한 고비들이 지나갔었습니다.
몇가지 해결된 사항과, 새로운 문제점, 장기적인 문제점 들이 나타났으며, 이를 하나 하나 이야기 해 보도록 하겠습니다.
VR 포팅
vr 포팅은 성공적으로 마무리 되었습니다. 일주일간 vr환경을 구현하는 방식을 리서치, 적용 시키면서 대부분의 일주일을 보냈는데, 아직까지 만족스러운 환경은 아닙니다.
예를 들어 이동에 관한 문제입니다.
팀장의 의견은 순간이동 방식의 캐릭터 이동에 매우 거부감을 가지고 있습니다.
컨트롤러를 의존해서 캐릭터 이동의 주장을 고수하고 있으며, 월드 좌표를 이용해 이동에 구현이 되었습니다.
하지만 월드 좌표의 기준이기 때문에, 캐릭터가 월드 좌표와 다른 방향으로 이동할때 생기는 문제가 나타나고 있습니다.
캐릭터 ver 1.3
캐릭터의 커스터마이징이 남은 한달간의 필수 과제입니다.
기초적인 적용방법 구현은 이미 성공했었습니다. 하지만 정확하고 빠른 계산방법은 다음 문제입니다.
캐릭터의 신체사이즈 조절은 본에 스키닝 된 부위의 scale 을 조절하는 방식입니다.
예를들어 목의 사이즈를 변경을 시도할시, 캐릭터의 목이라는 뼈에 인식되어있는 메쉬들의 사이즈를 변경하는 방식이지요.
여기서 하나의 문제점이 나옵니다.
스키닝 작업에서는 weight 추가작업이 들어갑니다. 특정 부위의 메쉬에 특정 뼈가 얼마나 커다란 영향력을 행사 할 수 있느냐 정도의 의미입니다.
이 말은 하나의 메쉬에 여러개의 뼈들이 조절을 담당 할 수 있다는 의미입니다.
목뼈를 조절하거나, 팔뼈, 심지어 발가락 뼈를 바꿀때도 메쉬는 그weight에 따라 얼마나 큰 영향을 받을 수 있는가를 결정 할 수있죠.
그 영향력은 0% ~ 100%까지 정할 수 있습니다.
이렇게 weight영향력을 얻은 메쉬들은 scale 값 ( 기본 1.0 배수) 을 가지고, 그 배수에 따라 알맞는 값들이 나오게 됩니다.
그럼 실제 메쉬의 사이즈(치수)는 어떻게 재는가? 인데, 이는 아쉽게도 재공하는 방법이 없다고 결론짓고 있습니다.
그렇다면 어떻게 치수를 재냐 인데요, 우선은 MarvelousDesigner 를 이용한 둘래를 얻는 방법을 이용했습니다.
마블러스에서는 캐릭터의 둘레 따위를 쉽게 잴 수 있습니다.
설명된 위의 방법들을 동원하여, 지금까지 치수화를 했었습니다.
완벽히 일치하지 않는 저급한 방법이었습니다.
그리고 이제 다시 막혔습니다. 스케일에 따라 변화되는 치수들을 재어, 정확한 신체치수의 변경이 되는지, 혹은 방안을 찾기 위해 시도 해 보았습니다. (1.0 스케일과 0.7 0.8 0.9 1.2 스케일일때의 둘레를 얻어, 값들의 증감폭을 구해보는 방식으로) 결과는 참담했습니다. 어떤 값에서는 무려 10센치나 넘는 오차가 발생했습니다.
이 부분을 해결하지 못하면, 커다란 문제를 갖게 되는것 입니다.
또다른 산이 코앞에 있습니다.
2017년 7월 23일 일요일
2017년 7월 16일 일요일
7월 14일
7월 14일
주간보고
아기다리고기다리던 주간보고의 시간입니다.
이번주에는 많은일들이 있었습니다.
일정에 맞게 계획을 바꿨으며, VR구매와 템플릿,캐릭터 신체 사이즈 조절 등 흥미로운 이야깃 거리들이 잔뜩 있습니다.
일정과 계획
마침내, 팀원들은 처음 목적과는 달리 약간의 계획변경은 불가피 하다는 결론을 냈습니다.
캐릭터의 신체에 맞는 자유로운 옷의 사이즈 조절은 남은 한달이라는 기간동안에는 너무나도 빠싹한 일정이며, 한달동안 완성 할 수 있을지 장담할 수도 없는 사항이기 때문입니다.
이러한 결정이 나고 곧바로, 팀장의 활약으로 프로토타입 캐릭터 옷입히기 기술을 적용했습니다.
VR 구매
드디어 Vive 를 구매했습니다.
대실도 완료했으나, 설정의 문제와 보안떄문에 설치가 완벽한 수준은 아닙니다.
이번주 중으로 룸을 구현할 생각입니다.
템플릿
당장 보여주기 위해 필요한 몇가지 에셋들을 구매할 예정입니다.
컨버팅 작업 의뢰를 했으나, 작업속도다 더딘듯 합니다. 이번주 초 까지 통보를 못받는다면 다시 컨택을 해봐야 할 듯 합니다.
캐릭터 업데이트 #1
프로토타입으로 만들었던 mimi chan 의 기본적인 형태는 변함이 없지만, 약간의 뼈 추가, 혹은 스키닝 작업을 위해 지속적으로 디자이나와 의뢰를 주고받으면서 시간을 보내고 있습니다. 캐릭터가 완변해야만, 작업이 올바르게 작동됩니다. 이는 매우 중요한 사항입니다.
옷 추가를 위한 초석, Marvelous Desinger
이미 디자이너는 Marvelous Desinger 를 배우고 있었습니다만, 이제서야 여러종류의 옷을 만들어 볼 시간적 여유가 생겼습니다. 그러기 이전에, 우리 캐랙터인 mimi chan 에 맞게 만들기 위해 Marvelous 에 맞는 mimi 아바타를 생성해야할 이유가 생겼었습니다.
타입은 여러가지를 만들 수 있었지만, 지금 당장은 기초 아바타면 충분 할 것 입니다.
(아바타 작업을 완성한mimi chan 입니다)
신체사이즈
size matter! 현제 제가 맡고있는 주 파트입니다.
캐릭터의 신체 세분화 작업이 완료되었고, 부위별 조절기능을 한번더 숙지했으며, 자료구조와, 약간의 사이즈 조절 알고리즘을 만들었습니다. 이 알고리즘은 다행스럽게도 여러 타입의 신체구조 혹은 부위를 그나마 손쉽게 추가 수정 할 수 있을것이라고 평가 중 입니다.
(끔찍한 수준의 방대한 노드들, 최적화는 필수일 것 입니다)
이 작업들을 통해 알아낸 몇가지 사실은
unreal에서 Map 을 지원하지만, 수정이 불가능 합니다.
unreal에서는 다차원 자료구조를 사용할 수 없습니다.
unreal에서는 기본 1uu=1cm 이며, 스케일링은 배율로 계산합니다.
우리팀 역시 cm단위를 기본으로 하며, 이에 맞게 반응되도록 식을 BP로 만들었습니다, 이에 따른 계산 속도는 느릴것으로 예상되며, 작업 안정화가 되었을 때에, 코드화 구현이 필수적인 파트가 될것 입니다.
다차원 자료구조가 먹히지 않는다는 사실이 가장 큰 충격이었으며, 이로인해 굉장히 비효율적인계산구조를지니고 있습니다. 이부분 역시 배포 전 수정해야할 부분입니다.
마치며
이제 팀은
프로토타입 캐릭터의 완성
프로토타입 애니메이션 생성
옷 추가
템플릿 구매/ 생성
텍스쳐와 머티리얼 작업
사이즈 작업 마무리
VR 환경 준비
등의 작업이 진행될 것 입니다.
다음 한 주는 끔찍히 바쁜 주말이 될 것 으로 보입니다.
하지만 드디어, 조금씩 성과가 보이기 시작하기 때문에 팀원의 사기는 더욱 증진한거 같습니다.
이제 한달 채 남지 않았습니다.
멈출 여유또한 없습니다.
2017년 7월 13일 목요일
7월 13일
7월 13일
어느정도 순조로운 진행
마블러스 디자이너에서 캐릭터 에셋 생성의 기초는 끝이났습니다.
어느정도수준의 이해는 되었기에 심화 작업을 요청받아도 금새 끝낼 수 있을것 입니다.
e
디자이너에게 스키닝 작업의 중요성을 이해시켰습니다. 동영상의 캐릭터의 전면부는 현제 애니메이션 행동시 가슴팍에 끼이는 문제가 발생합니다.
이를 해결하기 위한 현제 최고의 솔루션은 스키닝의 완벽한 작업입니다.
디자이너가 비명을 지르더군요.
수치를 위한 계산식이 필요합니다.
우선 첫번째 캐릭터의 기본 신체부위 둘레를 얻었습니다.
이를 이용해 디테일한 신체변화를 하는 방법을 찾아야 합니다.
어느정도 순조로운 진행
마블러스 디자이너에서 캐릭터 에셋 생성의 기초는 끝이났습니다.
어느정도수준의 이해는 되었기에 심화 작업을 요청받아도 금새 끝낼 수 있을것 입니다.
e
디자이너에게 스키닝 작업의 중요성을 이해시켰습니다. 동영상의 캐릭터의 전면부는 현제 애니메이션 행동시 가슴팍에 끼이는 문제가 발생합니다.
이를 해결하기 위한 현제 최고의 솔루션은 스키닝의 완벽한 작업입니다.
디자이너가 비명을 지르더군요.
수치를 위한 계산식이 필요합니다.
우선 첫번째 캐릭터의 기본 신체부위 둘레를 얻었습니다.
이를 이용해 디테일한 신체변화를 하는 방법을 찾아야 합니다.
2017년 7월 11일 화요일
7월 11일
7월 11일
도움을 받다.
어젯밤 Player Unknown Battleground 의개발팀원중 한명과 잠깐의 대화를 통할 수 있었습니다.
우리의 목표를 설명했을때 납득을 하는것으로 보아 역시 이 작업이 불가능한 수준은 아니라는 판단이 들었습니다.
힌트를 몇개 얻어서, 자신감이 생겼습니다.
또한 팀장의 성과가 보이기 시작하기 때문에,시도해볼 것들이 다시 더 생겼습니다.
오후에 강사님의 힌트를 얻어서 몇가지 해결하지 못했던 인터페이스 구현 방법의 실마리를얻었습니다.
야간시간에, 팀회의를 거쳐 우선사항의 변경을 결정했습니다.
1. 옷에 대한 현실적인 물리시스템은 현제상태에서 pasuse 를 한다. 계속 진행하기에는 시간 낭비가 심각하다.
2. vr ready 를 준비한다.
3. 수치 조절 알고리즘에 대해 작업을 시작한다.
4. 머티리얼과 옷 메쉬 제작을 시작한다.
로 내일부터 방향 전환을 시작합니다.
지금 하던것들은 분명 작업중에 새로운 힌트나 아읻어를 받을 수 있을 것 입니다.
너무 오래 지체했습니다.
죽이든 밥이든 나아갈 시간 입니다.
도움을 받다.
어젯밤 Player Unknown Battleground 의개발팀원중 한명과 잠깐의 대화를 통할 수 있었습니다.
우리의 목표를 설명했을때 납득을 하는것으로 보아 역시 이 작업이 불가능한 수준은 아니라는 판단이 들었습니다.
힌트를 몇개 얻어서, 자신감이 생겼습니다.
또한 팀장의 성과가 보이기 시작하기 때문에,시도해볼 것들이 다시 더 생겼습니다.
오후에 강사님의 힌트를 얻어서 몇가지 해결하지 못했던 인터페이스 구현 방법의 실마리를얻었습니다.
야간시간에, 팀회의를 거쳐 우선사항의 변경을 결정했습니다.
1. 옷에 대한 현실적인 물리시스템은 현제상태에서 pasuse 를 한다. 계속 진행하기에는 시간 낭비가 심각하다.
2. vr ready 를 준비한다.
3. 수치 조절 알고리즘에 대해 작업을 시작한다.
4. 머티리얼과 옷 메쉬 제작을 시작한다.
로 내일부터 방향 전환을 시작합니다.
지금 하던것들은 분명 작업중에 새로운 힌트나 아읻어를 받을 수 있을 것 입니다.
너무 오래 지체했습니다.
죽이든 밥이든 나아갈 시간 입니다.
2017년 7월 9일 일요일
7월 7일
7월 7일
여전히 옷입히기 기능에서 문제를 겪고있습니다. 지난주와 같은 상황에 있습니다. 옷이 줄어들지는 않지만, 콜리전또한 바뀌지 못하고 있습니다.
디자이너의우선작업 가능한 파트가 끝이났습니다.
약간 상의끝에 엔진파트에 같이 붙기로 정했습니다.
만 하루끝에 디자이너와 저의 갭을 해소했으며, 새로운 방식들을 생각 해 낼 수 있었습니다만, 아직까지도 얻은것은 없었습니다.
디자이너와 이야기를 거친후,
저는 디자이너에게 추가적인 조사를 부탁하고 코드로 넘어가야한다는 개인적인 판단을 내렸습니다.
우선 블루프린트 네이티브화 라는 기술을 알아봤습니다.
블루프린트에서 작업된 코드를 c++로 변환시켜 이중 작업을 용의하게 만드는 기술인것 같습니다만, 아직까지 c++에서 블루프린트로 바꾸는 기술에 대해서 얻은 정보가 없으며, c++코드로 변환시 일어나는 문자열 정렬 문제도 있기때문에 우선사항에서 밀려났습니다.
블루프린트 네이티브화
에디터를수정하면 어떨까 하는 방안을 떠올렸고, clothing 시스템의 위치를 파악했지만, 간단히 코드 교체로는 변화가 있지 않았습니다.
제조사 및, c 코드 공부를 다시 시작해야겠습니다.
주간 보고
일주간 일어난 성과나 문제점을 다시 정리해 봅니다.여전히 옷입히기
여전히 옷입히기 기능에서 문제를 겪고있습니다. 지난주와 같은 상황에 있습니다. 옷이 줄어들지는 않지만, 콜리전또한 바뀌지 못하고 있습니다.
디자인 파트의 일시중단, 협업
디자이너의우선작업 가능한 파트가 끝이났습니다.
약간 상의끝에 엔진파트에 같이 붙기로 정했습니다.
만 하루끝에 디자이너와 저의 갭을 해소했으며, 새로운 방식들을 생각 해 낼 수 있었습니다만, 아직까지도 얻은것은 없었습니다.
다시 코드로
디자이너와 이야기를 거친후,
저는 디자이너에게 추가적인 조사를 부탁하고 코드로 넘어가야한다는 개인적인 판단을 내렸습니다.
우선 블루프린트 네이티브화 라는 기술을 알아봤습니다.
블루프린트에서 작업된 코드를 c++로 변환시켜 이중 작업을 용의하게 만드는 기술인것 같습니다만, 아직까지 c++에서 블루프린트로 바꾸는 기술에 대해서 얻은 정보가 없으며, c++코드로 변환시 일어나는 문자열 정렬 문제도 있기때문에 우선사항에서 밀려났습니다.
블루프린트 네이티브화
에디터를수정하면 어떨까 하는 방안을 떠올렸고, clothing 시스템의 위치를 파악했지만, 간단히 코드 교체로는 변화가 있지 않았습니다.
제조사 및, c 코드 공부를 다시 시작해야겠습니다.
2017년 7월 6일 목요일
2017년 7월 3일 월요일
7월 3일
7월 3일
진행상황
physicsAsset 을 공유하는 방법을 찾았다고 판단했으며 실제적으로 입혔으나 아직까지, 이게 진짜 적용이 된건지 애매한 상황입니다.
디버깅으로 플레이시, 렉돌의 사이즈가 일정 수치 이상 혹은 이하가 되면 더이상 스케일링이 되지 않고, 겹치거나 붕 떠버리는 현상이 있습니다.
추가적으로 알아낸 사실 이 몇가지 더 있는데
1. 14년까지만 해도 에픽사에서는 본 스케일링을 권장하지 않았으며, 지금도 권장하는 편은 아닌듯 하며.
2. 실제로 본 스케일링이 적용된 사례를 보았을때, 피직스 판정범위는 올바르지만 동적으로 40마리 정도의 적이 움직이는 게임에서 상당한 퍼포먼스 하락을 봤습니다. 문제가 있다는것은 명확해졌습니다.
3. 현제 상태에서는 옷이 올바르게 적용되어 보이지는 않습니다.
4. 옷이꽉 조이는 효과는 보이기 힘듭니다. 왜냐하면 메쉬의 찢어짐 효과는 현제 게임에서구현하기가 곤란하다고 판단됩니다. 물론 APEX Distruction 같은 기술은 있으나, 우선사항은 아닌거 같습니다.
ㅎ
진행상황
physicsAsset 을 공유하는 방법을 찾았다고 판단했으며 실제적으로 입혔으나 아직까지, 이게 진짜 적용이 된건지 애매한 상황입니다.
디버깅으로 플레이시, 렉돌의 사이즈가 일정 수치 이상 혹은 이하가 되면 더이상 스케일링이 되지 않고, 겹치거나 붕 떠버리는 현상이 있습니다.
추가적으로 알아낸 사실 이 몇가지 더 있는데
1. 14년까지만 해도 에픽사에서는 본 스케일링을 권장하지 않았으며, 지금도 권장하는 편은 아닌듯 하며.
2. 실제로 본 스케일링이 적용된 사례를 보았을때, 피직스 판정범위는 올바르지만 동적으로 40마리 정도의 적이 움직이는 게임에서 상당한 퍼포먼스 하락을 봤습니다. 문제가 있다는것은 명확해졌습니다.
3. 현제 상태에서는 옷이 올바르게 적용되어 보이지는 않습니다.
4. 옷이꽉 조이는 효과는 보이기 힘듭니다. 왜냐하면 메쉬의 찢어짐 효과는 현제 게임에서구현하기가 곤란하다고 판단됩니다. 물론 APEX Distruction 같은 기술은 있으나, 우선사항은 아닌거 같습니다.
ㅎ
2017년 7월 2일 일요일
6월 30일
6.30
주간보고
지난 이주간 팀원들의 작업현황을 보고합니다.
우선 모델링 파트에서는 커다란 성과를 보였습니다.
올바른 rigging 과 skinning 그리고 간단한 animation 제작방법을 터득한 디자이너는, 목요일날 배포가능한 캐릭터의 리깅과 스키닝을 끝냈습니다.
이 말은 이제 본격적으로 보여 줄 만한 캐릭터를 이용해 작업을 진행 할 수 있다는 의미입니다.
올바른 rigging을 왜 준비하는데 오래걸리냐 는 질문이 있을 수 있습니다.
다른 사이트 등에서 쉽사리 기본제공해주는 뼈들이 잔뜩 있으며, auto rigging tool 역시 흔하게 존재하는데 말이죠.
저희는 일반적인 게임이 아닌 시뮬레이션 이기 때문에, 기존에 사용하는 뼈의 개수만으로는 상당히 부자연스러울 수 있다는 결론을 얻었기 때문에, 힘들지만 처음부터 maya 공부를 진행하게 되었습니다.
이 말은 곧 애니메이션 또한 처음부터 작업을 해야한다는 말 이기도 하죠.
분명 힘들지만 커다란 성과인 것은 확실하다고 판단중입니다. 디자이너의 이주간의 노고의 결과는 조금더 미래에 나오겠지요.
다음으로는 엔진 파트입니다.
언리얼 엔진의 기본적인 작동 메커니즘과 코드의 사용방법 등을 공부하며, 동시에 필요한 물리에셋의 복사방법을 찾기 위해 아직도 작업중인 단계입니다.
개발속도가 너무 늦기 때문에, pause를 해야하나 걱정을 했지만, 어느정도 성과가 나오고 있기 때문인지, 윗선의 압박이 조금 줄었습니다.
동시에 처음에는 문제없다고 판단했던 본 스케일링 파트는 추가적인 고민거리가 생겼습니다.
본 스케일링시 자식 본 마저 같이 스케일링 된다는 사실입니다.
과연 이 행위가 우리에게 더 이로울지, 아니면 독이 될지 판단을 하고, 해결방안도 미리 구해 놔야 할 것 같습니다.
이 부분을 해결한다면, 다음으로 걱정해야 할 파트는 알고리즘입니다.
캐릭터의 신체사이즈와 옷의 사이즈간의 상관관계와 그에따른 올바른 옷을 꺼내는 작업에 대해 고민을 시작해야할 때 인 것 같습니다.
현제 APEX cloth 기술에서는 옷의 질감에 대한 상세설정은 없다는 추측을 가지고 있기 때문에, 미세 값에 따른 올바른 옷 추천이 무엇보다 중요해진게 아닐까 추측하고 있습니다.
신축성의 유무에따라 추천하는 옷의 범위도 바뀔것이 분명하기 때문에, 고려해 주어야할 변수들이 상당할 것 이며, 이에따른 sort 처리속도 또한 늘어날 것입니다.
옷에 집어넣는 올바른 physics Asset은 조금더 연구가 필요하지만 성과가 없는 것은 아닙니다.
하지만 그렇다고 이곳에 현제 상태를 적자고 하기에도 애매한 상황이군요. 검증이 필요한 단계입니다.
월요일이나 화요일에 검증의 결과를 얻어야 할 것입니다.
더 정확히 할 수 있을거 같습니다.
전체적으로 느리지만 전진이 없지는 않았던 한달입니다.
종합적으로 보면 늦고있습니다. 조금더 박차가 가해졌으면 합니다.
주간보고
지난 이주간 팀원들의 작업현황을 보고합니다.
우선 모델링 파트에서는 커다란 성과를 보였습니다.
올바른 rigging 과 skinning 그리고 간단한 animation 제작방법을 터득한 디자이너는, 목요일날 배포가능한 캐릭터의 리깅과 스키닝을 끝냈습니다.
이 말은 이제 본격적으로 보여 줄 만한 캐릭터를 이용해 작업을 진행 할 수 있다는 의미입니다.
올바른 rigging을 왜 준비하는데 오래걸리냐 는 질문이 있을 수 있습니다.
다른 사이트 등에서 쉽사리 기본제공해주는 뼈들이 잔뜩 있으며, auto rigging tool 역시 흔하게 존재하는데 말이죠.
저희는 일반적인 게임이 아닌 시뮬레이션 이기 때문에, 기존에 사용하는 뼈의 개수만으로는 상당히 부자연스러울 수 있다는 결론을 얻었기 때문에, 힘들지만 처음부터 maya 공부를 진행하게 되었습니다.
이 말은 곧 애니메이션 또한 처음부터 작업을 해야한다는 말 이기도 하죠.
분명 힘들지만 커다란 성과인 것은 확실하다고 판단중입니다. 디자이너의 이주간의 노고의 결과는 조금더 미래에 나오겠지요.
다음으로는 엔진 파트입니다.
언리얼 엔진의 기본적인 작동 메커니즘과 코드의 사용방법 등을 공부하며, 동시에 필요한 물리에셋의 복사방법을 찾기 위해 아직도 작업중인 단계입니다.
개발속도가 너무 늦기 때문에, pause를 해야하나 걱정을 했지만, 어느정도 성과가 나오고 있기 때문인지, 윗선의 압박이 조금 줄었습니다.
동시에 처음에는 문제없다고 판단했던 본 스케일링 파트는 추가적인 고민거리가 생겼습니다.
본 스케일링시 자식 본 마저 같이 스케일링 된다는 사실입니다.
과연 이 행위가 우리에게 더 이로울지, 아니면 독이 될지 판단을 하고, 해결방안도 미리 구해 놔야 할 것 같습니다.
이 부분을 해결한다면, 다음으로 걱정해야 할 파트는 알고리즘입니다.
캐릭터의 신체사이즈와 옷의 사이즈간의 상관관계와 그에따른 올바른 옷을 꺼내는 작업에 대해 고민을 시작해야할 때 인 것 같습니다.
현제 APEX cloth 기술에서는 옷의 질감에 대한 상세설정은 없다는 추측을 가지고 있기 때문에, 미세 값에 따른 올바른 옷 추천이 무엇보다 중요해진게 아닐까 추측하고 있습니다.
신축성의 유무에따라 추천하는 옷의 범위도 바뀔것이 분명하기 때문에, 고려해 주어야할 변수들이 상당할 것 이며, 이에따른 sort 처리속도 또한 늘어날 것입니다.
옷에 집어넣는 올바른 physics Asset은 조금더 연구가 필요하지만 성과가 없는 것은 아닙니다.
하지만 그렇다고 이곳에 현제 상태를 적자고 하기에도 애매한 상황이군요. 검증이 필요한 단계입니다.
월요일이나 화요일에 검증의 결과를 얻어야 할 것입니다.
더 정확히 할 수 있을거 같습니다.
전체적으로 느리지만 전진이 없지는 않았던 한달입니다.
종합적으로 보면 늦고있습니다. 조금더 박차가 가해졌으면 합니다.
6월 28일
6월 28일
code it
마침내 코드의 리버스 엔지니어링을 통한 분석을 손을 댈 수 있을정도로 되었기 때문에, 추측에 따라 첫 번째 피직스 에셋 복사 작업을 시도했습니다.
우선은 블루프린트 노드를 생성했으며, 두 개의 스캘래탈 메쉬의 피직스 에셋값을 받아오며, 받아온 값들은 함수를 통해 복사하는 작업을 시도했습니다.
코드들의 작동은 성공적이었으며, 오류또한 없었지만, 실제로 사이즈의 변형은 일어나지 않았습니다.
이로써 추측할 수 있는 것은 두가지 인데,
1 . 포인터 사용에 실수가 있었다.
2 . 피직스 에셋을 가져오는곳이 틀렸거나, 전혀 엉뚱한 부분의 에셋을 골랐다.
정도로 평가 할 수 있을 거 같습니다.
실패했지만 그럼에도 약간 자신감도 돟아올 수 있었습니다. 실제로 코드를 삽입했고 컴파일까진 됬으니깐..
code it
마침내 코드의 리버스 엔지니어링을 통한 분석을 손을 댈 수 있을정도로 되었기 때문에, 추측에 따라 첫 번째 피직스 에셋 복사 작업을 시도했습니다.
우선은 블루프린트 노드를 생성했으며, 두 개의 스캘래탈 메쉬의 피직스 에셋값을 받아오며, 받아온 값들은 함수를 통해 복사하는 작업을 시도했습니다.
코드들의 작동은 성공적이었으며, 오류또한 없었지만, 실제로 사이즈의 변형은 일어나지 않았습니다.
이로써 추측할 수 있는 것은 두가지 인데,
1 . 포인터 사용에 실수가 있었다.
2 . 피직스 에셋을 가져오는곳이 틀렸거나, 전혀 엉뚱한 부분의 에셋을 골랐다.
정도로 평가 할 수 있을 거 같습니다.
실패했지만 그럼에도 약간 자신감도 돟아올 수 있었습니다. 실제로 코드를 삽입했고 컴파일까진 됬으니깐..
6월 27일
6.27
ongoing c++
막다른길 에 도달한게 아닐까 싶어지는 순간이 찾아왔습니다.
맨땅에 삽질도 정도껏인데, 끝이없다는 생각이 자꾸 든다는 기분이 드네요.
살찍 팁을 얻을 수 있지 않을까 싶어 방향은 조금 다르지만, 그래도 프로그래밍 쪽에서 지인 실무자에게 문의를 구했고, 돌아온 답변은 내가 하고있는 방식이 슬프지만 유일한 방법이라는 위안같지않은 위안을 얻었습니다.
오늘 종일 확신을 가지고 파고있던 소스파일은 결국 다른 작업물의 파일이라는 사실을 알았지만, 동시에 어떤 작업에 필요한 소스파일인지 알아내는 방법을 얻었기 때문에, 완전히 의미 없는 성과는 아니게 되었습니다.
하지만 이야기가 되었듯이, 이제 시간이 그렇게 많지 않습니다. 고 스톱, 어느쪽이든 이제 정해야 할 시기가 다가옵니다. 시간을 더 달라고 하고싶지만...
ongoing c++
막다른길 에 도달한게 아닐까 싶어지는 순간이 찾아왔습니다.
맨땅에 삽질도 정도껏인데, 끝이없다는 생각이 자꾸 든다는 기분이 드네요.
살찍 팁을 얻을 수 있지 않을까 싶어 방향은 조금 다르지만, 그래도 프로그래밍 쪽에서 지인 실무자에게 문의를 구했고, 돌아온 답변은 내가 하고있는 방식이 슬프지만 유일한 방법이라는 위안같지않은 위안을 얻었습니다.
오늘 종일 확신을 가지고 파고있던 소스파일은 결국 다른 작업물의 파일이라는 사실을 알았지만, 동시에 어떤 작업에 필요한 소스파일인지 알아내는 방법을 얻었기 때문에, 완전히 의미 없는 성과는 아니게 되었습니다.
하지만 이야기가 되었듯이, 이제 시간이 그렇게 많지 않습니다. 고 스톱, 어느쪽이든 이제 정해야 할 시기가 다가옵니다. 시간을 더 달라고 하고싶지만...
6월 26일
6.26
여전히 c++
여전히 답변은커녕 강의조차 찾지 못하고있기 때문에 불안감은 최고조에 달하고있습니다.
불안감을 어떻게든 해결하기 위해 되든 안되든 강의를 따라하고있으며, 어느정도 이해는 되기 때문에(강의의 절반은 구버전이기에 따라할수 없는 수준이지만) 그나마 위안을 삼고있는 수준.
수많은 SkeletalMesh들
c++ 코드속에서 드디어 원하는 Skeletalmesh를 찾은 듯 했으나, 이는 곧 9시즘 수많은 Skeletalmesh중 하나일 뿐이라는 사실을 알았습니다. 이중에 내가 원하는게 있는지 조차 문제지만..이 수많은것들ㅇ르 하나 하나 테스트하는것도 일인거 같습니다.
quick note:
Engine – UE – plugins – Runtime – ImmediatePhysics – public – BomeControllers
수상한 부분, 이건 4.16버전의 새로운 물리 기술, 당장 그다지 중요한 부분은 아니네요
여전히 c++
여전히 답변은커녕 강의조차 찾지 못하고있기 때문에 불안감은 최고조에 달하고있습니다.
불안감을 어떻게든 해결하기 위해 되든 안되든 강의를 따라하고있으며, 어느정도 이해는 되기 때문에(강의의 절반은 구버전이기에 따라할수 없는 수준이지만) 그나마 위안을 삼고있는 수준.
수많은 SkeletalMesh들
c++ 코드속에서 드디어 원하는 Skeletalmesh를 찾은 듯 했으나, 이는 곧 9시즘 수많은 Skeletalmesh중 하나일 뿐이라는 사실을 알았습니다. 이중에 내가 원하는게 있는지 조차 문제지만..이 수많은것들ㅇ르 하나 하나 테스트하는것도 일인거 같습니다.
quick note:
Engine – UE – plugins – Runtime – ImmediatePhysics – public – BomeControllers
수상한 부분, 이건 4.16버전의 새로운 물리 기술, 당장 그다지 중요한 부분은 아니네요
6월 22일
6월 22일
에디터를 에디트하기 위한 에디터
언리얼엔진에서 제공하는 full source로 처음에는 어디서부터 어떤기능을 재공하는지 몰랐지만, 이제 필요한 시기라고 판단하여 설치를 했습니다.
그리고 드디어 알아낸 사실은 이러했는데 : “언리얼엔진을 수정할 수 있는 소스코드들“
이었습니다.
설치부터 하나의 난관이었기 때문에, 재법 시간을 소모했었고, 이제 기초부터 빠르게 해치워 나가야할 시간인 것 같습니다.
비트수업 에서는 가볍게(혹은 내가 안들었거나) 지나갔던 헤더파일과 cpp파일의 차이를 명확하게 해야했습니다.
헤더파일은 마치 자바의 인터페이스같은게 아닌가 싶더군요. 사용할 함수를 미리 형식을 다 정해놓고 적어둔 뒤, 사용할 함수들을 소트시켜 같은 종류끼릴 묶어둔 놈을 헤더라 보면 될거 같았습니다.
물론 헤더에 함수내용을 입력해도 되지만, cpp파일에서 include 된 헤더가 나올때마다 해당 헤더를 읽게되는데, 이때 내용물에 함수내용이 들어가 있다면, 그것들을 모조리 읽어내기 때문에 컴파일 시간이 길어지는 문제점이 일어 날 수 있기 때문에 그러지 않는 것이 옳은 방법이라 합니다.
quick note:
U : low API수준의 언리얼 언어
A: 객체들을 의미. 매쉬나 파티클 음향효과...etc
S : slate, UI관련
F : 구조체 structure
6월 21일
6월 21일
skinning
명백히 당장은 쓸모없는 기능이라고 생각되지만, 언젠가는 해야할 공부를 어제 시작했었습니다. 진도도 더 이상 안가가고 자신감도 많이 떨어져 있었기 때문에 비교적 즐겁게 배웠으나, 이로써 역시 3d max 로 스키닝 작업은 미친짓이라는 결론을 얻었습니다.
스키닝의 기초 개념과 사용법, 그리고 어느정도 수준의 APEX로 질감구현의 방법을 터득하기도 했기에, 완전히 무의미한 시간은 아니었습니다.
어제 알아낸 기술인 nCloth는 우리 프로젝트에서는 크게 쓸모가 없다는 결론을 얻었습니다.
nCloth 는 Maya에서 고유적인 스크립트로 작동하는 애니메이션 부가기능인데, 이것을 추출 할 수 는 있으나, 단지 미리 baked 된 애니메이션만을 가져올 수 있다는 제한이 있었습니다.
그 말은 모든 애니메이션, 옷, 캐릭터에 따른 nCloth를 미리 구워서 들고와야 한다는 의미이며, 시간과 자원을 터무니없이 많이 쓸 것 이라는 이유입니다.
본 컨트롤러 구현
운 좋게도 올바른 캐스팅 방법을 찾아내어 본 컨트롤러의 구현을 성공했습니다.
이로써 캐릭터 커스터마이징은 전부 구현가능으로 결론지었습니다.
이로써 한가지 더 확정된 사실은, 본과 피직스 에셋을 공유를 해도, 본 혹은 피직스 에셋이 바뀐다 한들 다른 메쉬에서는 영향이 없다는 사실입니다. 당연한 이야기였지만 단계별로 알아가기 위한 수준이라고 생각합니다.
이로써 c++코드 사용이 더더욱이 필요하다는 생각에 힘이 들어갑니다.
또 동시에 방향도 조금 더 구체화가 된 것이, 스켈레탈 메쉬를 생성할때에 참조 혹은 동적 메모리로 생성할 본과 피직스 에셋을, 공유하는 방식으로 전환하는 방법을 찾아야 한다입니다.
가능여부는 물론, 실제 구현시 일어날 다른 문제점들도 분명히 있겠지만, 적어도 지금 당장 시도 해 볼 방향은 이것인 것 같습니다..
skinning
명백히 당장은 쓸모없는 기능이라고 생각되지만, 언젠가는 해야할 공부를 어제 시작했었습니다. 진도도 더 이상 안가가고 자신감도 많이 떨어져 있었기 때문에 비교적 즐겁게 배웠으나, 이로써 역시 3d max 로 스키닝 작업은 미친짓이라는 결론을 얻었습니다.
스키닝의 기초 개념과 사용법, 그리고 어느정도 수준의 APEX로 질감구현의 방법을 터득하기도 했기에, 완전히 무의미한 시간은 아니었습니다.
어제 알아낸 기술인 nCloth는 우리 프로젝트에서는 크게 쓸모가 없다는 결론을 얻었습니다.
nCloth 는 Maya에서 고유적인 스크립트로 작동하는 애니메이션 부가기능인데, 이것을 추출 할 수 는 있으나, 단지 미리 baked 된 애니메이션만을 가져올 수 있다는 제한이 있었습니다.
그 말은 모든 애니메이션, 옷, 캐릭터에 따른 nCloth를 미리 구워서 들고와야 한다는 의미이며, 시간과 자원을 터무니없이 많이 쓸 것 이라는 이유입니다.
본 컨트롤러 구현
운 좋게도 올바른 캐스팅 방법을 찾아내어 본 컨트롤러의 구현을 성공했습니다.
이로써 캐릭터 커스터마이징은 전부 구현가능으로 결론지었습니다.
이로써 한가지 더 확정된 사실은, 본과 피직스 에셋을 공유를 해도, 본 혹은 피직스 에셋이 바뀐다 한들 다른 메쉬에서는 영향이 없다는 사실입니다. 당연한 이야기였지만 단계별로 알아가기 위한 수준이라고 생각합니다.
이로써 c++코드 사용이 더더욱이 필요하다는 생각에 힘이 들어갑니다.
또 동시에 방향도 조금 더 구체화가 된 것이, 스켈레탈 메쉬를 생성할때에 참조 혹은 동적 메모리로 생성할 본과 피직스 에셋을, 공유하는 방식으로 전환하는 방법을 찾아야 한다입니다.
가능여부는 물론, 실제 구현시 일어날 다른 문제점들도 분명히 있겠지만, 적어도 지금 당장 시도 해 볼 방향은 이것인 것 같습니다..
6월 20일
6월 20일
nCloth 와 옷 모델링 등장
지난 회의로 시아를 환기시켰으며, 덕분에 조금 더 절망스러워졌으나, 다행히도 모델링 파트에서 커다란 전진을 보였으며, 또 새로운 실마리 또한 던져줬기 때문에, 시도해 볼 것들이 다양하게 늘어났습니다.
1. 남성용 상의 옷 모델링 두벌 셈플을 받음.
2. nCloth 기술을 들었음
이로써 시도해볼 방향은
1. physX Asset의 동적인 변화가 Apex Cloth 에 적용이 되는가?
- 블루프린트 작업으로 우선 시도해 볼 것.
- C++ 코드로 asset 부분을 포인트 하는 방식은 어떨까?
2. Maya nCloth 기술을 시도 해 볼 것.
- 시범적용
- 실현가능성 따지기.
가 생겨났으며, 하나씩 막힐때마다 바꿔가며 알아보고 있는 중입니다.
당장 nCloth에 대해 리서치 했을 때 나온점들은..
1. APEX를 unreal 에서는 지원하고 있다.
2. nCloth를 위한 Geometry Cache 역시 지원하기 떄문에, nCloth에 대한 배려가 없지는 않다.
3. nCloth 는 physiX Asset의 regdoll 이 필요없다?(조금더 알아봐야 할 것)
4. nCloth는 pre rander가 필요한 애니메이션일 뿐이다?
5. geometry cache 방식을 사용하지 못한다면 Morph target을 이용해야한다.
6. 부드러운 천을 APEX보다 월등히 잘 표현 해냈다.
정도 인듯합니다. 리서치가 더 필요한 부분입니다.
nCloth 와 옷 모델링 등장
지난 회의로 시아를 환기시켰으며, 덕분에 조금 더 절망스러워졌으나, 다행히도 모델링 파트에서 커다란 전진을 보였으며, 또 새로운 실마리 또한 던져줬기 때문에, 시도해 볼 것들이 다양하게 늘어났습니다.
1. 남성용 상의 옷 모델링 두벌 셈플을 받음.
2. nCloth 기술을 들었음
이로써 시도해볼 방향은
1. physX Asset의 동적인 변화가 Apex Cloth 에 적용이 되는가?
- 블루프린트 작업으로 우선 시도해 볼 것.
- C++ 코드로 asset 부분을 포인트 하는 방식은 어떨까?
2. Maya nCloth 기술을 시도 해 볼 것.
- 시범적용
- 실현가능성 따지기.
가 생겨났으며, 하나씩 막힐때마다 바꿔가며 알아보고 있는 중입니다.
당장 nCloth에 대해 리서치 했을 때 나온점들은..
1. APEX를 unreal 에서는 지원하고 있다.
2. nCloth를 위한 Geometry Cache 역시 지원하기 떄문에, nCloth에 대한 배려가 없지는 않다.
3. nCloth 는 physiX Asset의 regdoll 이 필요없다?(조금더 알아봐야 할 것)
4. nCloth는 pre rander가 필요한 애니메이션일 뿐이다?
5. geometry cache 방식을 사용하지 못한다면 Morph target을 이용해야한다.
6. 부드러운 천을 APEX보다 월등히 잘 표현 해냈다.
정도 인듯합니다. 리서치가 더 필요한 부분입니다.
6월 19일
6월 19일
돌아가는 시간
피직스를 건드릴 계획은 잠깐 미뤄두기로 했습니다. 현제 목표를 잠깐 바꾸어 본 트렌스폼에 우선적으로 생각을 해보기로 결정했습니다.
우선 지난주에 알아낸 새로운 실마리는 본 컨트롤을 할 경우 피직스 랙돌 범위또한 늘어난다는 정보를 얻었으나,
하지만 옷을 늘릴 수 있다 한들, 옷의 치수가 바뀌면 안되기 때문에 옷에 본 컨트롤을 입힐 이유가 하등 없다고 개인적으로 판단중입니다.
APEX를 적용시킬 때 덮어씌울 피직스 에셋은 별도로 지정이 가능했었기 때문에, 만일 사람의 피직스 에셋을 지정한뒤, 사람의 신체사이즈를 조정한뒤 반응은 어떠할까 라는 의문을 가지게 되었습니다.
이를 실험해 보기 위해 이론뿐이었던 캐릭터 본 스케일링을 실제로 구현해야 할 시기라고 판단 되었고,
이후 오후에서 추가적으로 회의를 거쳤으며, 아직까지는 판단이 명확하게 서지는 못했으나, 무엇이든지 밀어봐야 할 시기가 되었습니다.
돌아가는 시간
피직스를 건드릴 계획은 잠깐 미뤄두기로 했습니다. 현제 목표를 잠깐 바꾸어 본 트렌스폼에 우선적으로 생각을 해보기로 결정했습니다.
우선 지난주에 알아낸 새로운 실마리는 본 컨트롤을 할 경우 피직스 랙돌 범위또한 늘어난다는 정보를 얻었으나,
하지만 옷을 늘릴 수 있다 한들, 옷의 치수가 바뀌면 안되기 때문에 옷에 본 컨트롤을 입힐 이유가 하등 없다고 개인적으로 판단중입니다.
APEX를 적용시킬 때 덮어씌울 피직스 에셋은 별도로 지정이 가능했었기 때문에, 만일 사람의 피직스 에셋을 지정한뒤, 사람의 신체사이즈를 조정한뒤 반응은 어떠할까 라는 의문을 가지게 되었습니다.
이를 실험해 보기 위해 이론뿐이었던 캐릭터 본 스케일링을 실제로 구현해야 할 시기라고 판단 되었고,
이후 오후에서 추가적으로 회의를 거쳤으며, 아직까지는 판단이 명확하게 서지는 못했으나, 무엇이든지 밀어봐야 할 시기가 되었습니다.
6월 16일
6월 16일
APEX Cloth 와 Unreal Engine4
Unreal의 최신버전인 4.16 의 쇼케이스에서 새롭게 선보인 기능들이 몇 개있는데, 그중에서 Unreal 자체 엔진에서 APEX Cloth 기능을 내장시켜벼렸습니다.
특히 clipping 문제등이 골칫거리였으며, maya 혹은 max에서 작업한 결과물이 Unreal 에서는 올바르게 나타나지 않는 문제들이 있었는데, 이를 해결하기 위함이라고 합니다.
4.16에서 experimental 기능에 “Clothing tool“를 활성화 시키면, 메쉬 수정단계에서 작업을 진행 할 수 있는데, 이미 사용하는 엔진이며, 기능도 단순하기 떄문에, max에서 작업환경때 보다 수월하고, 더 빠르게 결과물을 볼 수 있는 장점이 있었습니다.
또 이로써, 언리얼에서 제공하는 phAT 의 physX를 ragdoll로 인식시켜 physX에셋툴을 재사용의 편의성이라는 매우 큰 장점을 얻어냈습니다.
이로써 생각 해볼 부분들이 약간 변환되었습니다.
1. 랙돌의 사용방법과 cloth적용방법이 간편화 되었기 때문에, 이제 랙돌의 동적인 변화방법을 구현시키면 될 것.
2. socket이나 mesh 겹치기 방식은 완벽한 솔루션이 아니기 때문에, 더 좋은 방법이 있는지 찾아볼 것.
3. 옷에 대한 올바른 물리효과 기대치를 찾아낼 것
정도로 지금은 나눌 수 있을 것 같습니다.
APEX Cloth 와 Unreal Engine4
Unreal의 최신버전인 4.16 의 쇼케이스에서 새롭게 선보인 기능들이 몇 개있는데, 그중에서 Unreal 자체 엔진에서 APEX Cloth 기능을 내장시켜벼렸습니다.
특히 clipping 문제등이 골칫거리였으며, maya 혹은 max에서 작업한 결과물이 Unreal 에서는 올바르게 나타나지 않는 문제들이 있었는데, 이를 해결하기 위함이라고 합니다.
4.16에서 experimental 기능에 “Clothing tool“를 활성화 시키면, 메쉬 수정단계에서 작업을 진행 할 수 있는데, 이미 사용하는 엔진이며, 기능도 단순하기 떄문에, max에서 작업환경때 보다 수월하고, 더 빠르게 결과물을 볼 수 있는 장점이 있었습니다.
또 이로써, 언리얼에서 제공하는 phAT 의 physX를 ragdoll로 인식시켜 physX에셋툴을 재사용의 편의성이라는 매우 큰 장점을 얻어냈습니다.
이로써 생각 해볼 부분들이 약간 변환되었습니다.
1. 랙돌의 사용방법과 cloth적용방법이 간편화 되었기 때문에, 이제 랙돌의 동적인 변화방법을 구현시키면 될 것.
2. socket이나 mesh 겹치기 방식은 완벽한 솔루션이 아니기 때문에, 더 좋은 방법이 있는지 찾아볼 것.
3. 옷에 대한 올바른 물리효과 기대치를 찾아낼 것
정도로 지금은 나눌 수 있을 것 같습니다.
6월 15일
6월 15일
현제까지 밝혀진 문제점/공부할 점
현제 내부에서 핵심 기능으로 평가중인 옷 과 신체사이즈 간의 관계, 사실적인 물리효과
에 대한 정보를 업데이트 합니다.
크게 핵심기능과 문제점을 짚어보며, 2주차 발표 이후 우리가 넘어가야 할 첫 번째 산이 어느 파트인지 설명 해 보겠습니다.
핵심기능과 문제점
1. 첫 번째로 신체사이즈는 Morph targer 과 Animation bone controller를 사용하여 키와 살의 변형이 가능하다는 결론을 얻었고, 이미 Morph target은 실제 적용에 성공하였습니다. 애니메이션 파트를 맡기에는 아직까지 시간과 정보가 부족하며, 우선순위도 비교적 낮기 때문에 2주차 발표에서는 구현 단계를 미루기로 결정했습니다.
(Morph target을 이용한 캐릭터의 세부적인 표현)
2. 두 번째로 옷에 대한 사실적인 물리효과에 대한 것입니다.
지금까지 AMD 와 NVIDIA, 혹은 HAVOK 사 등에서 내놓은 여러 가지 물리 엔진이 있으나, 얘나 지금이나 모델링 Clipping 문제가 있습니다.
(위쪽의 AMD hairworks 아래쪽의 NVIDIA사의 Gameworks)
현제 코드빼고 무료로 공개되어있고, 다른 엔진에 비하여 양호한 편으로 Clipping문제를 해결중 이며, 좋게 평가 받고있는 Nvidia 사의 APEX Cloth 시스템을 사용하기로 결정했습니다.
(APEX Cloth)
기초적인 Cloth 시스템의 구현 역시 성공적으로 되었습니다만. 아직 남아있는 문제가 있습니다. 옷에 대해서는 ragdoll 시스템을 주입시켜야 합니다.
(ragdoll과 애니메이션의 병합 예시, ragdoll 수치를 높게 잡아 애니메이션에 따라 휘두른 주먹의 힘의 양이 메쉬의 몸무개를 뛰어넘어버려 메쉬는 넘어지게 된 장면입니다.)
ragdoll의 초기 구현 목적은 애니메이션과 별개로 스스로 “물리”적으로 동작하는 메쉬를 위해서 만들어 졌습니다.
이후 오랫동안 발전 끝에, 이 기술은 애니메이션 시스템과 병합되거나, 독립적으로 높은 퍼포먼스를 유지하며 훌륭하게 동작하는 단계에 이르렀습니다만, 독자적인 시스템들이 들어간 아종 ragdoll 들이 많이 생겨, 기준이 애매한 상태인 것 같습니다.
APEX Cloth 시스템에서는 ragdoll을 사용한다고 명시하였으며,
언리얼 엔진에서는 phAT라며, 물리에셋툴 이라는 이름의 툴을 이용해서 ragdoll과 비슷한 물리를 사용중인 것 같습니다.
14일 오전 테스트로 APEX Cloth 에서는 phAT 의 ragdoll은 먹히지 않았습니다.
같은날 오후 테스트로 APEX Cloth에서 사용하라고 하는 ragdoll을 구현했을 때, 정상적으로 언리얼엔진에서도 인식이 되는 것을 확인했습니다.
이로써 해결해야 하는 문제는 아래와 같습니다:
1. APEX의 ragdoll 시스템과 Unreal에서 제공하는 ragdoll 시스템은 동일한가?
2. 동일하다면 unreal에서 제공하는 ragdoll 로 APEX의 옷에 기능을 적용 할 수 있는가?
3. 동일하지 않다면 동일하게 바꿀 수 있는가?
4. 체형의 변화에 따라 옷에도 적용해야할 ragdoll 범위또한 변해야 한다. 이를 해결하기 위한 솔루션이 있는가? 혹은 C++ 코드로 우리가 수정 할 수 있는가?
의 문제가 남아있습니다.
3. 세 번째의 문제인 옷과 신체사이즈 간의 관계입니다.
신체사이즈의 조절과 기획에 맞는 옷의 사이즈를 생각하여 낸 결론은 문제없다 압니다.
우선 이 작업을 시작하기 앞서, 우리는
1. 수정을 할 신체부위의 최소, 최대치 기준 정립.
2. 옷과 신체부위와의 비교가 필요한 부위를 결정.
3. 옷과 신체부위의 메쉬와 언리얼 엔진에서의 치수 통일 ex) 1uu=1cm
4. 옷의 사이즈, 재질, 부위별로 세분화, 그에따른 신체에 적용가능한 허용 수치 결정.
를 회의를 통해 최종 정립합니다.
이후 신체사이즈에 따른 올바른 옷들을 sort 시켜줄 수 있는 알고리즘을 구현합니다.
가장 우선적인 작업
이 작업들을 행하기 위해 가장 중요한 부분은 통일되고, 필요기능이 충족되고, 재사용이 용이한 뼈대인 스켈레탈 메쉬를 구현하는 것입니다.
스켈레탈 메쉬가 있어야만 올바르게 아바타 생성, 옷과 아바타사이의 현실적인 적용, APEX 적용이 가능하게 되기때문에 가장 우선적으로 작업되어야 할 부분이 될 것입니다.
이미 이 부분을 맡을 Maya 공부는 시작되었습니다.
현제까지 밝혀진 문제점/공부할 점
현제 내부에서 핵심 기능으로 평가중인 옷 과 신체사이즈 간의 관계, 사실적인 물리효과
에 대한 정보를 업데이트 합니다.
크게 핵심기능과 문제점을 짚어보며, 2주차 발표 이후 우리가 넘어가야 할 첫 번째 산이 어느 파트인지 설명 해 보겠습니다.
핵심기능과 문제점
1. 첫 번째로 신체사이즈는 Morph targer 과 Animation bone controller를 사용하여 키와 살의 변형이 가능하다는 결론을 얻었고, 이미 Morph target은 실제 적용에 성공하였습니다. 애니메이션 파트를 맡기에는 아직까지 시간과 정보가 부족하며, 우선순위도 비교적 낮기 때문에 2주차 발표에서는 구현 단계를 미루기로 결정했습니다.
(Morph target을 이용한 캐릭터의 세부적인 표현)
2. 두 번째로 옷에 대한 사실적인 물리효과에 대한 것입니다.
지금까지 AMD 와 NVIDIA, 혹은 HAVOK 사 등에서 내놓은 여러 가지 물리 엔진이 있으나, 얘나 지금이나 모델링 Clipping 문제가 있습니다.
(위쪽의 AMD hairworks 아래쪽의 NVIDIA사의 Gameworks)
현제 코드빼고 무료로 공개되어있고, 다른 엔진에 비하여 양호한 편으로 Clipping문제를 해결중 이며, 좋게 평가 받고있는 Nvidia 사의 APEX Cloth 시스템을 사용하기로 결정했습니다.
(APEX Cloth)
기초적인 Cloth 시스템의 구현 역시 성공적으로 되었습니다만. 아직 남아있는 문제가 있습니다. 옷에 대해서는 ragdoll 시스템을 주입시켜야 합니다.
(ragdoll과 애니메이션의 병합 예시, ragdoll 수치를 높게 잡아 애니메이션에 따라 휘두른 주먹의 힘의 양이 메쉬의 몸무개를 뛰어넘어버려 메쉬는 넘어지게 된 장면입니다.)
ragdoll의 초기 구현 목적은 애니메이션과 별개로 스스로 “물리”적으로 동작하는 메쉬를 위해서 만들어 졌습니다.
이후 오랫동안 발전 끝에, 이 기술은 애니메이션 시스템과 병합되거나, 독립적으로 높은 퍼포먼스를 유지하며 훌륭하게 동작하는 단계에 이르렀습니다만, 독자적인 시스템들이 들어간 아종 ragdoll 들이 많이 생겨, 기준이 애매한 상태인 것 같습니다.
APEX Cloth 시스템에서는 ragdoll을 사용한다고 명시하였으며,
언리얼 엔진에서는 phAT라며, 물리에셋툴 이라는 이름의 툴을 이용해서 ragdoll과 비슷한 물리를 사용중인 것 같습니다.
14일 오전 테스트로 APEX Cloth 에서는 phAT 의 ragdoll은 먹히지 않았습니다.
같은날 오후 테스트로 APEX Cloth에서 사용하라고 하는 ragdoll을 구현했을 때, 정상적으로 언리얼엔진에서도 인식이 되는 것을 확인했습니다.
이로써 해결해야 하는 문제는 아래와 같습니다:
1. APEX의 ragdoll 시스템과 Unreal에서 제공하는 ragdoll 시스템은 동일한가?
2. 동일하다면 unreal에서 제공하는 ragdoll 로 APEX의 옷에 기능을 적용 할 수 있는가?
3. 동일하지 않다면 동일하게 바꿀 수 있는가?
4. 체형의 변화에 따라 옷에도 적용해야할 ragdoll 범위또한 변해야 한다. 이를 해결하기 위한 솔루션이 있는가? 혹은 C++ 코드로 우리가 수정 할 수 있는가?
의 문제가 남아있습니다.
3. 세 번째의 문제인 옷과 신체사이즈 간의 관계입니다.
신체사이즈의 조절과 기획에 맞는 옷의 사이즈를 생각하여 낸 결론은 문제없다 압니다.
우선 이 작업을 시작하기 앞서, 우리는
1. 수정을 할 신체부위의 최소, 최대치 기준 정립.
2. 옷과 신체부위와의 비교가 필요한 부위를 결정.
3. 옷과 신체부위의 메쉬와 언리얼 엔진에서의 치수 통일 ex) 1uu=1cm
4. 옷의 사이즈, 재질, 부위별로 세분화, 그에따른 신체에 적용가능한 허용 수치 결정.
를 회의를 통해 최종 정립합니다.
이후 신체사이즈에 따른 올바른 옷들을 sort 시켜줄 수 있는 알고리즘을 구현합니다.
가장 우선적인 작업
이 작업들을 행하기 위해 가장 중요한 부분은 통일되고, 필요기능이 충족되고, 재사용이 용이한 뼈대인 스켈레탈 메쉬를 구현하는 것입니다.
스켈레탈 메쉬가 있어야만 올바르게 아바타 생성, 옷과 아바타사이의 현실적인 적용, APEX 적용이 가능하게 되기때문에 가장 우선적으로 작업되어야 할 부분이 될 것입니다.
이미 이 부분을 맡을 Maya 공부는 시작되었습니다.
6월6일~6월 14일
6월 6일
캐릭터 세부설정 구현(머리, 가슴, 배, 팔 두께)
Unreal엔진에서 구현가능한 기술인 Morph target 방식을 3d MAX로 구현 성공,
언리얼 엔진에서 구동 성공
6월 7일 ~ 6월 8일
Unreal 의 Socket 시스템으로 간단하게 모자 씌우기 목표
Socket 시스템을 이용해 불러온 마내킹에 옷을 입히는 방식 으로 모자 구현
하지만 애니메이션 재생시 일어나는 문제가 발생하였고, 해결을 위해 작업 일시 중지후
검색
6월 10일
현제 기술의 문제점 파악
현제 이용하고 있는 morph target 시스템은 메쉬의 변형만을 관리하기 때문에, 뼈의 사이즈를 조절 할 방법이 없다고 판단. 대안이나, 추가적인 기술 이용이 필요하기에 리서치/포럼에 질문 남기기 등을 시도.
어렴풋이 Maya를 이용해야한다는 판단
6월 11
뼈 사이즈 에 대한 대안
한가지 솔루션을 발견했는데, Bone animation을 사용하면 뼈의 스케일을 조절이 가능하다는 힌트를 얻었으나. 몇가지 문제점이 있다는 판단이 섰는데,
1. 애니메이션은 항상 동작되어야 한다.
2. 캐릭터의 달라지는 키(본 사이즈로 인해) 에 우리가 어떻게 알고, 알맞은 옷을 입힐 수 있는가?
3. 키가 달라지면 ragdoll 또한 변하게 될것인데, ragdoll 또한 같이 변형이 될것인가?
6월 12일
APEX 첫 시도
빠듯한 일정에 부득이하게 옷부터 구현하자는 마음에 APEX cloth 기술을 시도 해 보았고,
옷이 허공에 치솟다가 산산조각 나서 바닥에 널부러지는등의 악몽이 발생.
6월 13일
APEX 두 번째 시도
옷에 올바른 물리엔진을 구현하는대에 성공했으나, 옷이 3갈래로 찢어지며, 언리얼 엔진에서 구동 실패.
6월 14일
APEX 세 번째 시도
언리얼 엔진에 물리엔진을 입히는데 성공했으나, 다음 문제점이 나타났음.
옷에 콜리전(ragdoll)을 적용해야하는데, 콜리전의 세팅은 in-game에서 캐릭터의 체형 변화에 실시간으로 따라 갈 수 있을 것 이라는 판단이 들지 않음.
unreal에서 제공하는 ragdoll을 입혀보았지만 인식하지 못한 듯 하기 떄문에, APEX에서 사용하는 ragdoll만을 인식한다는 판단을 가지고 있음.
남은 기간동안 옷에대한 ragdoll의 자유로운 세팅을 구현하는 것이 주요 과제중 하나가 될 것.
피드 구독하기:
글 (Atom)