얼마 전에 '000[1/4]'라는 제목의 파일을 구글 드라이브에 올렸는데 자꾸 이름이 '000[1:4]'로 슬래시가 콜론으로 대체되는 문제가 있었다.처음엔 그저 귀찮다는 생각만 하며 이름을 하나씩 수정했는데, 오늘 또 대체되길래 수정을 하다가 문뜩 이유가 궁금했다. MacOS를 사용하고 있어서 '인코딩 문제일까?' 하는 의심이 있어서 지피티에게 물어봤다. 결론은 애초에 파일명에 슬래시가 들어갈 수 없기 때문에 비슷한 형태의 특수 문자가 들어갔을 것이고, 구글 드라이브에 업로드할 때 이를 비슷한 다른 특수 문자로 수정했을 가능성이 높다고 한다. 여기에서 파일명에 슬래시가 들어갈 수 없다는 점에서 의문을 가졌는데, 생각해 보니 디렉터리를 표현할 때 슬래시로 구분을 하니까 파일명에 슬래시가 들어가면 이게 폴더..
분류 전체보기
기존에 땅을 파는 로직을 추가했다. 처음엔 땅을 파는 판정을 할 구의 반지름 내에 들어온 버텍스의 스칼라 값을 가까울수록 값을 많이 변화시키는 방식으로 작성했는데, 그냥 일정한 값만큼 값을 변경하도록 수정했다. 이렇게 하니까 한번 땅을 파거나 메울때마다 얼마나 팔 것인지 값을 조절할 수 있게 되었다. 나중에 장비를 업그레이드 하면 땅을 더 많이 팔 수 있도록 해야할 때 유용해보인다. 마우스를 꾹 누르면 일정 시간마다 땅을 파고 메우는 기능도 추가했다. 이렇게 하니까 제법 아스트로니어와 비슷해보였다. 구 형태로 지형을 편집하도록 구현해보니 왜 아스트로니어가 구 형태가 아닌 원 형태를 채택했는데 알겠다. 구 형태로는 땅을 원하는대로 고르게 파기가 어려웠고 메워도 내가 원하는 형태가 아니다보니 메우고 파기..
프로파일러로 체크해본 결과 평상시에 CPU가 한 프레임을 처리하는데 드는 시간이 5ms가 나오다가 메시를 렌더링 할때마다 16ms가 나오게 되었다. 특히 MeshCollider로 런타임에 충돌체를 생성하는것이 오래 걸리고 있었다.MeshCollider를 모두 꺼버리자 6ms가 줄어들어 10ms가 되었다. 하지만 여전히 Marching Cubes를 연산하느라 5ms정도를 먹고있다.코드를 확인하니 보여줄 필요가 없는 메시는 GameObject를 꺼버리고, 사용하게 되면 켜도록 처리했는데 여기에서 시간을 꽤 먹고있었다. 애초에 Marching Cubes는 스칼라 필드가 모두 1인경우 메시가 없으므로, 이 경우엔 액티브를 끄지 않고, mesh를 클리어 하는 방향으로 수정해보았다.게임 오브젝트를 켜고 끄는 처리만..
메시를 만들고 나서 Normal 값을 생성하도록 후처리 과정을 추가했다. normal값도 미리 룩업테이블에 두고 사용할 수 있을지 기대해봤지만, 기울기가 일정하지 않기 때문에 실시간으로 처리하는게 자연스러워서 실시간 처리로 수정했다. Cube에 MeshCollider를 추가했다. 그 외에도 테스트용으로 렌더러와 콜라이더를 끌 수 있는 기능을 추가했다. 이는 #if UNITY_EDITOR로 감쌌기 때문에 혹시나 빌드를 했을 때 코드가 노출되지 않도록 처리했다.Cube는 생성될 때 부모 transform을 null로 해둬서 최상위 부모로 올라가기 때문에 부모를 설정할 수 있도록 코드를 수정했다.그 외에도 마칭큐브 연산할 때 매번 생성되는 리스트를 캐싱하는 등 짜잘하게 최적화를 했다. 테스트 할때마다 중복되는..
기존에는 큐브에 버텍스 값과 인덱스를 넣을 때 배열을 넣어줘야 해서 ToArray 함수로 배열을 따로 만들었었는데, SetVertices, SetTriangles 함수로 넣으면 List를 넣을 수 있어서 넣어줬다.SetTriangles를 넣을 때 SubMesh라는 파라미터를 넣어야 했는데, 이는 큰 메시 하나가 여러개의 머터리얼로 사용할 때, 어떤 머터리얼을 사용할 것인지를 의미했다. 즉 사용할 머터리얼의 인덱스를 넣어줘야 했는데, 지금은 하나의 머터리얼만 사용해서 0을 넣어줬다. 큐브에 직접 접근해서 값을 수정하는게 좋지 않아 보여서 Generator 스크립트를 추가했다. 이제 무조건 이 Generator를 통해서만 큐브를 생성할 수 있도록 처리했다.Generator의 경우 컴포넌트일 필요가 없어서 M..
내가 구현한 Marching Cubes 알고리즘에서 몇가지 구멍이 있었다. 일단 스칼라 값이 인근 버텍스에도 영향을 줘야 한다는 것을 알고 있었으면서 정작 y축은 그렇지 않게 만들었다. 그리고 버텍스가 없으면 렌더링이 되면 안되는데, 예외처리를 잘못해서 버텍스가 없어도 렌더링이 되고있었다(Unity의 GameObject가 꺼지지 않고 있었다).그래서 밑에 잔상같은게 남는 문제가 있었는데 렌더링을 막아서 해결했고, 파도 모양이 이상하게 나오는것도 수정했다.이제 렌더링이 되니까 노이즈로 지형생성을 해보자. 수정 전 수정 후
아스트로니어를 플레이하는데 실시간으로 지형에 변화를 주는게 너무 신기하고 재미있어 보였다. 그래서 전통적인 복셀 그래픽은 아니지만, Marching Cubes 알고리즘으로 복셀 그래픽을 구현해보려고 한다.현재로써는 Marching Cubes 알고리즘을 이해했고, 만들어내는데까지 성공했다. 내 목표는 런타임중에 지형을 파거나 쌓아 올려보는것과 동굴이나 절벽같은 지형을 의도한 대로 생성하는 것까지 구현하는 것이다. 현재는 Marcing Cubes 알고리즘을 이해해서 실제로 구현까지 했는데, 지금까지 가볍게 기록한 내용을 공개하는게 좋겠다 싶어서 그간 짧게 기록해둔 내용과 앞으로 개발하는 과정을 글로 적어볼 예정이다.
연속 메모리 할당프로세스 A는 A의 크기만큼 메모리 주소를 할당받아 연속적으로 배치되고, 프로세스 B는 프로세스 A이후에 B의 크기만큼 연속적인 메모리 주소를 할당받아 배치되는 방식을 연속 메모리 할당이라고 한다. 이 방식을 구현할 때 무엇을 고려해야 하고, 어떤 잠재적인 문제가 있는지 알아본다.스와핑메모리에 적재된 프로세스들 중에선 현재 실행되지 않는 프로세스가 있을 수 있다. 대기중인 프로세스나 오랫동안 사용되지 않은 프로세스가 그렇다. 스와핑은 이러한 프로세스들을 임시로 보조기억장치 일부 영역으로 쫓아내고, 그렇게 해서 생긴 메모리상의 빈 공간에 또 다른 프로세스를 적재하여 실행하는 방식이다.스왑 영역 : 프로세스들이 쫓겨나는 보조기억장치의 일부 영역스왑 아웃 : 현재 실행되지 않는 프로세스가 메모..
교착 상태란도로에 차가 꽉 막혀 꼼짝달싹 못하는 상황을 본 적이 있을 것이다. 프로세스 실행 과정에서도 비슷한 문제가 있다. 두 개 이상의 프로세스가 각자 가지고 있는 자원을 무작정 기다린다면 그 어떤 프로세스도 진행할 수 없는 교착 상태가 된다. 교착상태가 정확히 무엇이고, 언제 어떻게 발생하는지 알아보자.식사하는 철학자 문제식사하는 철학자 문제(dining philosophers problem)는 교착 상태를 설명하기 위한 고전적인 시나리오이다.동그란 원탁에 다섯 명의 철학자가 앉아있다. 철학자들의 앞엔 식사가 있고, 철할자들 사이에는 식사에 필요한 포크가 있다. 철학자들 앞에 있는 식사는 두 개의 포크로 먹을 수 있는 음식이라 가정해보자.그리고 철학자들은 다음과 같은 순서로 식사를 한다.계속 생각을..
동기화란병렬적으로 실행되는 프로세스들은 공동의 목적을 올바르게 수행하기 위해 협력해야한다. 이때 실행 순서와 자원의 일관성을 보장해야 하기 때문에 동기화되어야 한다.동기화의 의미프로세스의 동기화란 국어 사전에 따르면 ‘정보·통신 분야에서의 동기화란 작업들 사이의 수행 시기를 맞추는 것’이라는 의미를 갖는다. 정리히자면, 프로세스 동기화란 프로세스들 사이의 수행 시기를 맞추는 것을 의미한다.프로세스뿐 아니라 스레드 같은 실행 흐름을 갖는 모든 것은 동기화의 대상이다. 다만 여기에서는 대부분의 전공서 표현에 따라 ‘프로세스 동기화’라고 칭한다.프로세스들 사이의 수행 시기를 맞추는 것이 의미하는 것은 다음과 같다.실행 순서 제어 : 프로세스를 올바른 순서대로 실행하기Reader와 Writer가 있을 때 Wri..
