프로그래머 서식지

색감때문에 tone mapping을 꺼놨는데 화면 밖에 카메라가 나가면 밝아진건 좋은데 색이 영 깨진다 SKYBOX 추가하면 되는 문제긴 한데 Tone mapping 을 넣으면 색깨지는건 없어지나 rim 쪽의 쉐이더 효과가 약해지고 색도 변한다

Camera가 모션 중간에 엄청 밝아지는 현상 발견 문제는 2개가 섞였는데 tone mapping operator 를 꺼놔서 auto exposer의 값이 감당 안되는 것이고 distance 가 음수일 경우 SetEyeAtUp( cameraPos, m_Position, up ); 여기서 direction을 구할때 음수가 나와서 그렇다. 이 후에 윤곽선이 진하게 나오는 현상이 발견 거리 자체는 멀지만 projection matrix의 scaling으로 화면과 가깝게 표현해서 그렇다. float4 posVS = mul(toView, float4(pos, 1)); float fovFactor = length(float2(projection[0][0], projection[1][1])); float scale ..

http://mmdguide.tistory.com/789?category=329175 중력을 역전 시켜보려하니 문제가 2개가 있다. noise란 부분은 존재하지 않고, SDEF 대신 DQ 로 blending 한 부분이 수학쪽 디버깅은 힘들다 믿을만한 라이브러리를 레퍼런스로 삼아 Test하는 수 밖에 틀린 것, vector3 가 XMVECTOR로 converting 되어 잘못된 값이 들어감 Dual = Quaternion( form.GetTranslation() * 0.5f ) * Real; 내가 이해를 잘못했나 EDUCATINO 쪽 자료 중에 DQ 초기화를 Cross 써서하고 Transform 공식을 이쁘장하게 몇줄로 하는게 있었는데 아예 GLM과 다르게 나온다. 다시 수정함 SDEF vs DQBS LB..

디버거 한번, 롤백 한번 Debugger가 날 엿먹여도 이번엔 빠르게 잡은 듯 spTex 에서 흰색 영역을 과도하게 가져온다. sphere 라고 제질 광택 분포를 나타낸 값이라 값이 없다면 가운데 검정색 부분을 가져와야한다 (specularlight 값을 저장해둔거라 보면된다) if ( mat.sphereOperation != kSphereNone ) { float2 normalVS = mul( (float3x3)view, normalWS ).xy; output.spTex = normalVS * float2(0.5, -0.5) + float2(0.5, 0.5); } normalVS 가 0 이 나왔는데 output.spTex가 계속 0 이 나온다. normalWS 를 강제로 0으로 주니 (0.5, 0.5)..

보통은 모핑이 거의 없거나 귀찮아서 안만든다. 모핑 전용 본이 따로 배포되는 정도? 근대 이건 너무 크다 https://youtu.be/fRYp_T1PAfQ 흠 MMD 에서도 그런거 보니 값을 변경해야 할듯 붙여두고 기타등등

결론은 항상 정해져 있다. 망할 Reference 모델의 경우 잘 정돈되어있다. 예외도 없고 그에 반해 유저 모델의 경우 항상 생각했던 범위를 뛰어넘는다 그 때문에 적당히 테스트를 해야한다 현재 발견된 문제는 3개다. 모델의 가슴이 뚤리는 현상. 물리 값이 발산하는 현상. 뼈 값이 음수가 나오는 현상. Debug 모드시엔 nad 값이 나오면서 assert 가 걸린다. 그럼 이 값이 왜 나오는지 봐야하는데, m_linearVelocity = {mVec128={m128_f32=0x000001eb7f39d0c0 {-6.81898034e+36, -8.55016639e+36, 7.02308856e+36, 0.000000000} ...} ...} 또 저 값이 어디서 결정되는지 바야하는데 저 값은 m_tmpSolve..

한때 Dual Quaternion으로 통일하던 시절이 있었다. 하지만 LBS를 DQBS으로 convert 한부분 중에 팔꿈치가 꽈배기로 나오는 부분이 있어서 결국 제거하였다. 최근, Skinning 을 분리하여서 MikuViewer/Shaders/MikuModelVS.hlsli MikuViewer/Shaders/MikuModel_Skin_VS.hlsl 이거나 PmxModelVS.hlsl PmdModelVS.hlsl 와 같은, 분기문에서 벗어났기에 MMD의 4종류 skinning을 vertex shader에서 분기문으로 처리해보기로 하였다. 애초에 QDEF 가 Dual Quaternion 으로 보이는데 이것만 되었으면 이런 작업이 필요없지만 MMD에 넣으면 뻗기 때문에 LBS로 때우다가 안되는 부분에 SQ..

발단은 여러 이유가 있지만, MMD의 model type은 PMD/PMX가 존재한다. 또한 x 파일도 컨버팅해서 들어간다 문제는 이 2개의 skinning 방식이 서로 다른데도 동일한 shader를 탄다는 것이다 Effect라 불리는 쉐이더를 까보면 skinning 을 하지 않고 vertex/normal 이 그냥 들어온다 Direct 9 기반이므로 software skinning을 썻을 거라 추측한다 아니면 이래저래 우회를 했거나; MMDAI의 경우 PPL 을 타거나, OpenCL 을 태우는 거 같다 MMD는 4가지 skinning type이 있으므로 속도만 괜찮으면 해당 분기도 태울 수 있을 것 같았다. CPU 프로그래밍은 간단하다 TaskManager::parallel_for(0, position.s..

Software skinning을 5분만에 짜고 그 느림을 감당하지 못하여 Stream Out 한 걸 돌려 쓰도록 바꾸었다 아예 너무 틀리면 debugger 가 작동을 중지하기 대략 눈으로 버그 잡고 드디어 결과가 놔왔는데 저 vertex와 edge는 왜 저런건지 debugger를 이용하니 float3 pos = BoneSkinning( input.position, input.boneWeight, input.boneID ); float3 normal = BoneSkinning( input.position, input.boneWeight, input.boneID ); 위와 같은 오타는 쉽게 잡을 수 있었다 문제는 튀어나온 vertex 15분 동안 씨름한 끝에 문제의 vertex의 id는 알 수 있었다. f..

모든 Matrix에 통달한 사람은 해당하지 않지만, 왜 이런 고통을 자처하느냐가 의문이고 장점이라곤 소스 코드 복붙 방지에 크나큰 도움이 된다 정도? 이상한 matrix 하드코딩해서 reverse z 해서 두면 주석 없이는 되돌리기가 너무 힘들다. 이 miniEngine 저자는 openGL 와 방향성을 같게 하기 위해 이랬는지 몰라도 크나큰 해악을 소스코드에 풀어놨다 결국 이런 어중간한 코드는 OpenGL과 DirectX의 모든 튜토리얼의 코드를 엿먹인다. 모든 튜토리얼의 matrix를 right hand - reverse z로 돌려야하는데 꽤 귀찮은 작업니다.