surkim 님의 블로그

https://github.com/Very-Real-Engine/ALEngine GitHub - Very-Real-Engine/ALEngine: This is an GAME ENGINE made by 42 Very-Real-Engine Team.This is an GAME ENGINE made by 42 Very-Real-Engine Team. - Very-Real-Engine/ALEnginegithub.comhttps://www.youtube.com/watch?v=cwIg2w3mOJ0https://www.youtube.com/watch?v=ya1hKmkO8JY https://www.youtube.com/watch?v=oJnp3A-QEsEhttps://www.youtube.com/watch?v=M6dmD..

장렬하게 전사했다..이젠 정말 시간이 없어서 애초에 오브젝트 1000개의 프레임 방어가 주 과제였던지라오브젝트 material별 인스턴싱을 안해도 프레임 드랍이 없어타협을 하고 평가준비를 하기로 했다. 너무너무너무 아쉬운데일단 실패 원인과 과정을 조금 적어보자면..우선 인스터싱을 고려하지 않고 설계한게 문제이다.지금 생각해보면 게임 엔진인데인스터싱을 처음부터 고려하지 않은 내 무지함이 만든 스노우볼이다.오브젝트가 수천개 떠다닐텐데 그거마다 descriptorset을 만든다는게 말이 안된다.초창기에는 vulkan 배우기도 바빠 최적화를 전혀 고려하지 않았다는게 이런식의 실패를 만들줄 몰랐다.  현재 우리엔진의 draw콜 구조는 블로그에 적은 적이 없어 잠깐 적어보자면draw콜이 불릴 때 가장 윗단이Mesh..

shadowmap 그리는 descriptorset은 줄였다.이제 오브젝트가 몇개가 있든 상관없이 descriptorset은 16개다.-> 작업할 프레임 2 * (shadowmap 4 + shadowcubemap 4) 이제 진짜 그리는 main renderpass의 descriptorset을 줄여야하는데여기서 고민이 많다.아니 고민은 끝났고 사실 잘 구현하기만 남았다. descriptorset을 통합하려면shader에 입력되는 값의 공통부분을 uniform buffer로달라지는 부분을 storage buffer로 나누면 된다. 이제 그 공통부분을 어떻게 나눌지를 고민해봤는데아무리 생각해도 material별로 나눠야겠다는게 내 답이다. 우선 기존 geopass의 shader의 입력만을 살펴보면#version..

아오.. 처음부터 고려하면서 했어야했다.이제와서 고치니깐 고칠 것이 많아서 약간 애먹었다.사실 아직 다 못고쳤는데 이 정도까지는 픽스일 거같아 먼저 블로그에 올린다. 현재 문제는 RenderingComponent마다 descriptorset이 생겨 많은 오브젝트에 비례해서 descriptorset이 생기는 문제였다. 일단은 shadow를 그리기위한 descriptorset을 통합시켰다.어떻게 해결했고 어떤 고민을 했는지 써놔야겠다. 일단 결과물여기서 이렇게 개선됐다.역시 1000개가지고 프레임 드랍되면 말이 안되지 아직 다 완성 못했지만 바로 정상화된게 보여 뿌듯하다..ㅎ 우선 descirptorset을 줄이기 위한 방법은 많았고 거기서 선택을 했다.3가지를 고민했었는데 뭐가 더 좋은 방법인지는 모르겠다..

드디어 최적화까지 왔다!이 부분만 해결하면 사실상 과제에서 요구하는 기능들은 전부 구현한 것이고추가하고싶은 기능은 너무 많은데 내 욕심이고 기다리고 있는 동료들에게 예의가 아니라다른 프로젝트에서 하든 평가를 받고 추가하든 해야겠다.   우선 문제점은 씬에 오브젝트를 1000개 만들때 있다.오브젝트를 1000개 배치하고 프레임이 생각보다 너무 떨어져서 확인했을때우리엔진 파이프라인 구성상 큰 오버헤드가 발생할 구석이 없어서 cpu 병목인가 하고 살펴봤는데 cpu에서는 더더욱 병목이 일어날 일이 없었고gpu병목이면 draw호출을 없애보자하고씬을 그리지 않고 텍스쳐만 그리게 draw호출을 바꿔봤는데도 프레임드랍이 일어나서원인을 못찾아서 아.. 큰일났다 이건 정말 큰일이다.. 했는데다행히 동료의 컴퓨터로 debu..

코드를 보니깐 바보같이 shader 작성한 부분이 있어 급히 수정하고이걸 좋다고 블로그에 올렸어서 어디가 잘못 되었고 어떤 부분을 수정했는지 블로그에 올린다. PCF를 적용하는 부분에서 shadow cubemap에서 주변 벡터를 샘플링하는 과정에서 생긴 문제인데기존 코드vec3 rotatedVectors[8];vec3 getRotationAxis(vec3 direction) { vec3 worldUp = vec3(0.0, 1.0, 0.0); if (abs(dot(direction, worldUp)) > 0.99) { return normalize(vec3(1.0, 0.0, 0.0)); } return normalize(cross(direction, worldUp)..

역시 바쁠 때 가장 먼저 놓게 되는게 블로그인거같다.. 지금까지 한 일은 메모리 누수와 여러 잡다한 에러의 처리와skybox 개선, collider를 그리는 렌더패스를 추가했다. 우선 skybox개선전전 블로그의 그 이슈이다.예상했던 문제가 맞았고 hdr이미지를 본래 이미지 받아오는 것처럼 VK_FORMAT_R8G8B8A8_UNORM 형식이 아닌VK_FORMAT_R32G32B32A32_SFLOAT로 32비트로 받아와서 저장을 하니깐 말끔하게 해결되었다.받아오는 코드bool ImageBuffer::initHDRImageBuffer(std::string path){ auto &context = VulkanContext::getContext(); m_device = context.getDevice(); m_p..

그림자 퀄리티 개선은 사실 opengl 공부할 때 배웠던 방식 그대로 적용했다. 자세~~~~히 보면 우둘투둘하게 계단식으로 그림자가 보이는데 이게 모델이 커지면 커질수록 더 심해진다.그림자 개선을 위한 PCF라는 방법이 있는데그냥 간단히 말해 shadow map에서 그림자를 따올 때 주면 픽셀까지 같이 샘플링해서 평균치 내는 것이다. 적용 후 사진은별차이 없는거 같아 보이지만 약간 스무스~ 해졌다. 어려운건 없었고 신기한거와 신경 쓸게 하나씩 있었는데신기한거는float PCFShadow(sampler2DShadow shadowMap, vec3 shadowCoord, float currentDepth) { float shadow = 0.0; vec2 texelSize = 1.0 / texture..

이미 생성한 이미지를 다른 Renderpass에서 가져다 쓰는 것은 이제 익숙해서skybox 적용은 나름 쉽게 할줄 알았는데꽤나 어려웠고 사실 아직 고쳐야할 부분도 많다. 우선 적용 하는 방법은 쉬웠다.hdr파일을 우선 cubemap형태로 초기 변환을 해주고렌더링 중에 배경을 따로 렌더링하는 renderpass를 만들어서 나중에 model이 안그려지는 부분에 추가하면 끝!사실 따로 renderpass를 안만들고 바로 적용시킬 수도 있었을 거 같은데좀 더 직관적이고 쉬운 방법을 사용했다.적용하는 방법은 쉬웠지만 디테일에서 조금 문제가 생겼는데.. 문제가 생긴 부분은 hdr 파일 때문이다.가장 처음 의심되었던 부분은셰이더에서 톤매핑 기법을 안해서 그런가보다 해서reinhard 톤매핑 기법으로 매핑을 해줬더니..

글 쓴지 2주가 지났는데 그동안 많은 일이 있었다..급히 얼추 보여주기 형식이더라도 여태 해온 것을 보여줄 수 있는 정도로만들어야하는 상황이 와서 날밤새며 어찌저찌 만들었다.역시 사람이 긴박해지면 초인적인 힘이 나는 거 같다.. 일단 결과물부터!! 크으 에셋 많이 넣고 열심히 씬을 만들었더니 좀 있어보인다.일단 씬을 진짜 런타임 중에 만들고 저장할 수 있어서빨리빨리 만들 수 있어 다행이었다.예전 같았으면 코드로 에셋 추가 -> 컴파일 -> 확인 -> 코드 -> 컴파일 -> 확인 -> 무한반복... 어휴UI 작업자가 정말 고생을 많이 했고 없었으면 씬 만들지도 못했다.이제야 진짜 엔진처럼 씬을 만들게 될 수 있다! 업로드된 동영상은 rendering 소개할 파트의 동영상이고물리엔진도 동영상을 찍었는데 나에..