프로그래머 서식지

디버거 한번, 롤백 한번 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로 돌려야하는데 꽤 귀찮은 작업니다.

7월에 시도한 CSM 이 성공했다면, LiSPSM 을 시도할 일이없었을 것이고 모두 행복했을 것 같다. LiSPSM은 과거 기술로 그냥 지나가는 길에 해볼려고 했는 건데 안되서 오기로 진행하였다 현재 와서는 LiSPSM + CSM 이런식으로 붙여쓴다. MMD 의 LiSPM+CSM shader는 shadow mapping 만으로 아래와 같은 결과를 내준다 캐릭도 다르고 빛의 방향도 다른 Excellent shadow의 결과는 아래와 같다 이걸 왜 해야하냐면, MMD 의 shader 중 일부가 normal 값은 specular 판단하는데만 쓰고 음영을 shadow 에서 가져오는 넘이있기 때문이다 저게 죄다 shadow 그냥 shadow mapping을 돌리면

하도 안되서 NVIDIA 소스를 실행가능하게 만들어서 비교했다. miniEngine 의 수학 소스중 plane extraction 및 몇 부분이 틀려서 고쳤다. 이 넘의 소스는 실행안하는 수학코드에 함정이 왜케 많은지 그런데 특정 각도에서 그림자가 사라진다. cos 값이 1이 나온것도 아니고 이유를 알수가 없다. 결국 포기하고 저자의 reference 코드로 바꿔보았다. nvidia는 Light space clipping 을 안하고 대신 aabb box 의 z near/ z far 만 가져와서 unit cube (scaleTranslateToFit) 으로 화면을 한정시키는데 반해 저자의 코드는 장면 AABB와 camera frustum 을 cliiping 후 light volume 영역을 추가로 더한다 ..

우선, left hand 로 바꾸고 light matrix 만 구해서 orthographic 을 사용하는 버전을 테스트 해보자 그냥 임의의 min/max box DirectX::XMMatrixOrthographicOffCenterLH float2 TransTexCoord = ShadowPos.xy; if (!any( saturate( TransTexCoord ) != TransTexCoord )) { ShadowPos = saturate( ShadowPos ); float3 shadowPosDX = ddx_fine( ShadowPos ); float3 shadowPosDY = ddy_fine( ShadowPos ); saturate 없으면 ground 에서 깊이가 1.0 초과하는 값이 나와서 항상 실패하..