프로그래머 서식지

이까지 오는데 너무 많이 걸렸는데, 여기서 또 Pixel Query를 하네 Deferred context랑 안맞기도 한데 그냥 context로 해도 stall 이 있는듯. https://www.3dgep.com/forward-plus/ 에서는 이전 프레임 (또는 이전 2 프레임)의 쿼리 결과가 시간적 일관성 이론 [15] 에 의존하는 현재 프레임의 쿼리 결과 대신 사용되는 경우 실속을 피할 수 있습니다 . 이렇게하면 여러 광원에 대해 여러 쿼리 개체를 만들어야하기 때문에 쿼리 개체를 여러 프레임에 걸쳐 유지해야하는 경우 다시 쿼리 개체를 사용할 수 없기 때문에 이러한 쿼리 개체를 다시 사용할 수 없습니다. 또, 다시 Query pool 을 만들어야하나. 만들어도 저 시간적 일관성이 어떻게 얻어지는거지; ..

http://zerogram.info/?p=1613 에 기반하여 실험을 진행하고 있다.

http://zerogram.info/?p=1613 에 기반하여 실험을 진행하고 있다.

쓰면 적게쓰고, 안쓰는게 정신 건강에 좋다 좋은 튜토리얼 https://medium.com/@alinakipoglu/parsing-with-spirit-qi-fcaeaf4357b3 하지만, 쓰다보면 boost tutorial 다 읽고 부족해서 구글 검색하면서 왜 안되는가 고민하는 시간이 늘어간다. https://github.com/newpolaris/Parser/blob/master/Boost.Sprit/Boost.Sprit/mqo.cpp spirit 으로 억지로 해봤는데, lexer 붙이는 순간 컴파일 에러 너무 많이 나기 시작해서 지지치고 위와 같은 형태로 갔다. string iterator 를 끊어서 재 사용가능한건 좋은데, 컴파일 타임이 분단위임. 이게, 한줄 잘못하면 알지도 못하는 에러를 몇페이..

샘플의 bunny를 보고 적용하려고 하면 스트레스 받을 부분이 많다. 파라메터에 영향을 많이 받는다. 우선 kVC를 0으로 둔다면, 떨어지고 분리는 된다. 안떨어지게 하려면 어떻게 해야하는가? http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?t=7070 // psb->m_cfg.kVC = 0.000; // psb->m_cfg.kDF = 0.5; // psb->m_cfg.kMT = 0.1; psb->m_cfg.kVC = 0.001; // psb->m_cfg.kDF = 0.5; // psb->m_cfg.kMT = 0.1; psb->m_cfg.kMT = 0.1; psb->setPose( false, true ); 아래 링크에서 약간 설명은 되어있다. http://..

reduction 이라고도 불리고, decimation 이라고도 불린다. 우선 이게 필요한 이유는, PMD 기본 vertex가 3만개 가량인데 bullet 으로는 soft body를 돌릴 수가 없다. 예전에는 crash가 났다고 하는데 지금 버전에서는 너무느리다. 결국 줄인 것으로 시뮬레이션 해서 그걸 원래 mesh 에 반영해야한다. 반영을 위해 skinning 과 비슷하게 가상이든 진짜든 bone 을 도입하여 weight를 준다고 한다. 그때문에 decimation 방법을 조사해봤는데 이걸로 LOD 도 구현하고 그림자 전용 mesh도 만들고 한다고 한다. 이걸 실시간을 하면 귀찮으니까 전처리 단계에서 최적화도 하고 에러도 수정하는 단계를 밟는다. 소스 공개 된 soft 중에 Skeleton mesh 즉..

천쪼가리 2개 휘날리는데 3 ms 걸린다. Ground 와는 무조건 collapse 된다고 판정되어, island 분리도 불가능하고 현재 버전은 그 때문인지 multithread 지원도 안된다. Ground 를 제거하고 MT 버전 대충 때려박아봤는데도 안된다. 좀더 파보니까, batch island 가 128 이라서 merge 되 버린다. for 문제 static 만 추가하도록 되어있던데 아예 따로 만들 계획이었나? island manager를? 골치아픈거 생각하느니 나쁘진 않은듯. collision 은 딴데서 처리하였지? 아마; 몇개 수정하다 보면 solveSoftConstraint 만 하면 될거 같은데, 거기서는 디펜던시가 있는지 버그 난다. 망할, 우선 개발 버전 받아서 삽질 좀 해야할 것 같다. ..

OpenCL 버전은 개발 및 유지보수할 사람이 없단다. 그래서 Roadmap 이고 머고 없다고. 600 개 정도의 테스트를 하면 병렬화 코드 9 ms => 6.5 ms 로 줄어드는데, task size 를 조정하고 thread 수를 조작해도 +-1ms 정도 밖에 차이가 안난다. 아래 싸이트의 shader와 shape mesh를 사용하였다. http://zerogram.info/?p=2188 개체를 1만개 까지 늘리면 확연한 차이가 나는데 그 경우는 이미 16 ms 를 넘어버린다

으아아아 auto shadow = T * m_SplitProjections[i] * m_SunShadow.GetViewMatrix(); vsConstants.shadow[i] = m_SplitProjections[i]; shadow 를 넣어야하는데 실수했다. 근대 몇시간 걸린거지 좀 바꿀게 많고 어떻게든 돌아가면 그때 고치느라고 미루다보니 실수했다. 바로 디버깅 때려서 값 확인해야했는데 단계를 나눠 밟더라도 천천히 계속 성공하면서 가야 기분이 나는데 실천하긴 쉽지 않다

역시 Frustum visualize 해야 먼가 보인다. Cascaded 를 붙이고 있다. http://dev.theomader.com/cascaded-shadow-mapping-1/ 위의 글을 따라하고 있었는데 잘못한듯 우선 Orthographic Light Projection matrix 를 나눠본건데 저런 식으론 depth 의 정밀도는 높아진다. 하지만, 별로 도움이 안된다. Z 높이가 100 일때, Z 높이가 20 일때, 대신 x, y 를 줄여서 꽉 쪼이게 만들면?