|
:: 게시판
:: 이전 게시판
|
- 모두가 건전하게 즐길 수 있는 유머글을 올려주세요.
- 유게에서는 정치/종교 관련 등 논란성 글 및 개인 비방은 금지되어 있습니다.
통합규정 1.3 이용안내 인용"Pgr은 '명문화된 삭제규정'이 반드시 필요하지 않은 분을 환영합니다.법 없이도 사는 사람, 남에게 상처를 주지 않으면서 같이 이야기 나눌 수 있는 분이면 좋겠습니다."
14/10/23 20:02
그냥 로우폴리곤 오브젝트라면 별 문제 없겠지만 백만 폴리곤 짜리를 넣어놓으니.....
최적화 때문에 폴리곤 하나라도 더 줄일려고 기를 쓰는데 백만짜리를.....
14/10/23 19:47
저건 장난이었을 수도 있는데, 실제로도 가끔 어떤 프로젝트에서는 벌어지는 일입니다. 디자이너는 디자인한 것 하나하나가 자신의 포트폴리오가 되기 때문에 막 게임과 상관 없는 꽃병같은걸 더 정밀하고 미려하게 만들어 넣고 싶어하고, 그걸 실제로 최적화해야 하는 프로그래머는 난감해 하고 이런 식의 일이 많죠.
14/10/23 19:54
근데 디자이너 잘못이라기보단 프로그램에 문제가 있긴 있네요. 그 집이 투명한 유리집이 아닌 이상 랜더링 대상에서 제외되었어야 할텐데..
14/10/23 19:59
욕조와 백만폴리곤짜리 오리 오브젝트가 있다는 생각자체를 못한거죠. 프로그래머는 집 하나만 있겠거니 했는데
디자이너가 넘기기전에 장난으로 프로그래머 모르게 그 오브젝트들을 넣어놓은 상황이니....
14/10/23 20:21
상용 엔진들은 그런 처리를 자동으로 하기 때문에 프로그래머가 몰랐어도 됐어야 한다는 얘기입니당
커다란 유리문이라도 있어서 집 내부가 보이는 설계라면 얘기가 좀 달라지겠지만
14/10/23 20:33
근데 이게 욕조 안에 물이 차 있고 그 위를 떠다니는 거라면 아마도 다른 오브젝트일 것으로 생각이 되거든요...
집에 투명한 창문이라도 있었던가 했나 봅니다
14/10/23 20:37
렌더 방식에 따라 다르다고 할수있겠죠.
카메라뷰에 보이는 폴리곤 Face 만 쉐이더/텍스쳐를 적용해서 렌더 걸수도 있습니다. 만약에 눈에 보이는 오브젝트 전부를 연산에 집어넣어야 한다면 대규모 터레인(지형)같은건 노답이 되겠죠...
14/10/23 20:02
단순 프로그램 문제라고 하기에는..
대형 프로젝트는 모듈화 되어있기 때문에 각 담당자는 자기가 맡은 부분 밖에 모릅니다. 그리고 보이지 않는다고 안그리는게 아닙니다. 보이지 않는곳에 폴리곤 덩어리를 디자인해놓은 디자인팀과 아무 생각없이 반영한 담당자가 문제죠. 게임엔진는 그 집 안이 보일지 안보일지 모르기 때문에 일단 존재하는 모든 폴리곤을 그릴 수 밖에 없습니다.
14/10/23 20:08
불투명한 오브젝트가 있고 시점이 그 오브젝트 밖에 있으면 그 안에 존재하는 오브젝트는 로딩도 하지 않는 것이 보통일 것 같은데, 오브젝트를 R-Tree같은 걸로 저장하지 않았나 봅니다.
아무튼 모든 폴리곤을 다 그려야만 하는 건 아닙니다. 막 시야 밖에 있는 오브젝트까지 전부 그려는 놔야 한다는 말인데 그러면 그 어떤 게임도 도저히 프레임이 안 나올 걸요...
14/10/23 20:09
눈에 보이지도 않는데 연산하는건 명백한 오류라고 봐야할것 같습니다.
집이 화면에 등장할때가 아니라 집 안에 들어가서 욕조 안에 있는 오리를 볼때 느려져야죠
14/10/23 20:12
게임개발은 아니지만,
제가 하는 업무 특성상 보이지 않는다고 그리지 않는다는건 상상할 수도 없네요.. 유저인터페이스 개념으로는 유저가 언제 화면 전환을 할지 모르기 때문에, 유저 눈에 보여줄 수 있는 모든 화면을 일단 다 그려놓습니다. (그래서 성능문제가 항상 발목 잡죠) 문득 떠오르는 실예가 있네요. 디아2 하드코어 유저들의 적이었던 2막보스 두리엘 두리엘 방 진입하는 시점부터 로딩을 함 -> 두리엘이 퍽퍽퍽 으악 -> 화면이 돌아오는 동시에 으앙 주금
14/10/23 20:18
게임에서는 기본중의 기본입니다.
90년도 초에 만들어진 둠이나 울펜슈타인 3d 같은 게임에서조차 기본으로 그렇게 연산합니다. 어떤 업무를 하시는지는 모르겠는데 분야와 인터페이스를 막론하고 눈에 안보이는 부분을 렌더하는건 대부분 낭비입니다. 그건 비효율적으로 코드를 짰다고밖에 안보이네요.
14/10/23 20:25
코드 문제라고 하기에는...
해당 담당자는 리소스가 있으니 그냥 로딩하게 한 것뿐일겁니다. 그 리소스가 작은 집한채였는지 그 안에 100만폴리곤 오리가 있었는지 디자이너가 알려주지 않았다면, 일일히 리로스 크기 확인하지 않고서는 알 수가 없습니다. 그냥 배경으로 나무그리는 것처럼 집을 로딩한것입니다. 그 집 로딩하는데 엄청난 연산이 필요한지 아닌지 개발자 입장에서는.. 모릅니다. 코드입장에서는 더더욱 모르구요.
14/10/23 20:27
카메라-오브젝트-렌더 시스템에 대해서 생각하고 계신 것이 완전히 다른 것 같네요.
월드 안에 1억폴리곤이 존재한다고 해도 눈에 안보이면 안그리면 그만입니다.
14/10/23 20:44
시야 회전이 가능한 3D도 그렇게 처리할까요?
기본적으론 보이지 않지만 회전하면 보이는 영역에 욕조와 오리가 있었다고 한다면, 화면에 페인팅을 하지는 않지만 렌더링은 되고 있었다고 생각해도 무리가 없는 것 같아서요.
14/10/23 20:54
시야가 회전해서 오브젝트가 화면 안에 들어올 때 연산하면 됩니다.
바로 그때 무려 백만폴리곤 오리따위가 시야에 들어오면 비로소 느려지게 되는 것이지요. (일단 용어에 혼선이 없어야 하는데 렌더링이라는 개념 자체가 2D 이미지를 만드는 일이므로 말씀하신 페인팅이 곧 렌더링이라고 해야 할 것 같습니다.) 물론 화면에 렌더링은 하지 않았지만 백만폴리곤짜리 오리가 욕조 위에 떠다니는 유체시뮬레이션을 별도로 하고 있더라 하면 느려질 가능성도 있습니다. 하지만 그런 무리한 가정 없이 오브젝트로만 존재한다 하면 기본적으로 눈에 보이면 안그리고, 눈에 보이면 그려야 하니까 되도록이면 가벼운 폴리곤을 쓰는 대원칙을 지키면 됩니다.
14/10/23 21:00
저는 분야가 웹이다 보니 웹 브라우저의 동작방식을 빗대어 이해를 하게 되는 면이 있는데요.
웹브라우저는 화면에 그리는 작업을 위해 연산하는 렌더링 동작과 화면에 칠하는 페인팅 동작을 합니다. 여기서의 렌더링은 그리지 않지만, 그릴 내용을 준비해놓는 연산이지요. 화면에 노출되지 않아도 하는 연산입니다. 페인팅은 실제로 노출 될 때의 작업이구요. 실제로 웹페이지 화면을 그릴 때의 병목은 페인팅 부분이 되는 경우가 많습니다만, 렌더링 부분에서의 최적화도 필요합니다. 저는 위의 기사를 보았을 때 웹브라우저의 렌더링과 같이, 눈에 보이지는 않지만 미리 연산해놓는 부분이 있었던 것이라고 생각했구요. 당시의 상황이 그러했다고 기사에서 말하고 있으니 '최적화가 제대로 안되었나보네'라는 것보다는 '뭔가 연산이 필요했던 상황이었나보네'라고 보는 쪽이 더 자연스럽다고 생각되어 그렇게 이해합니다.
14/10/23 21:14
그렇군요. 웹분야에서 렌더링이라는 용어를 그렇게 사용하고 있는줄은 몰랐습니다. 3D 분야에서는 렌더링이라 하면 3D 오브젝트들과 카메라 위치를 기반하여 2D 이미지를 생성해서 보여주는 과정을 의미하기에 용어사용에 차이가 있었던 것 같습니다.
말씀하신 것처럼 '눈에 보이지 않지만 미리 연산해두는' 이 3D 분야라고 해서 전무한 것은 아닙니다. 일례로 영화나 애니메이션에 쓰이는 CG의 경우 포톤(포톤캐논...?) 같은 것을 눈에 보이지 않는 곳이라고 하더라도 3D 공간상에 마구 뿌려서 여기저기 맞고 튀어나오고 산란되는 정보를 가지고 렌더를 거는 기법이 있는데 훨씬 사실적인 이미지를 만들어낼 수 있습니다. 그런데 이런 기법들은 이미지 한장 만드는데 수십시간이 걸리기도 하죠. 하지만 1초에 최소한 30프레임, 못해도 60프레임 이상, 즉 1초에 수십장의 이미지를 만들어 내야만 하는 게임에서는 실시간 연산은 생명입니다. 특히나 3D 게임의 경우 화면에 보이는 각각의 폴리곤 오브젝트를 연산해서 2D 이미지로 1초에 수십장씩 렌더링하는 것도 녹록치 않은 일이라, 최대한 절약하고 절약시키는 것이 게임 렌더 엔진에게는 숙명과도 같은 일입니다. 눈에 보이지 않는 부분까지 미리 그려놓을 여력이 없다고 봐야 할 것 같습니다. 뭐 저도 게임이 주 전공분야는 아니어서;; 좀더 구체적이고 전문적인 설명이 되지 못함은 양해 부탁드릴게요;
14/10/23 20:18
GTA 같은 게임을 생각해 보세요. 월드 내 오브젝트 숫자가 많으면 수십억개를 넘는데 모든 화면을 그려놓는다는게 말이 됩니까... 최신예 그래픽카드는 개인용 PC에서도 1초마다 수십 테라플롭스를 연산합니다만 그런 괴물같은 연산능력으로도 1080P 60fps 보장이 안 되는 게 요즘 게임인데..
그리고 일반 유저 어플리케이션에서도 그런 식으로 프로그래밍을 하지는 않습니다. 더블버퍼링 트리플버퍼링을 통해 현재 화면을 미리 준비하는 건 있어도, 요청이 들어오기 전에 다른 화면을 미리 그려놓는다는 건 낭비죠. 그런 건 불러오는 데 시간이 오래 걸려서 사람이 인지할 수 있는 시간인 20밀리세컨드 내에 완료할 수 없는 경우에나 사용하는 기법이죠.
14/10/23 20:21
리소스 프리로딩와 컬링은 전혀 다른 개념입니다.
예를 드신 듀리엘은 리소스를 미리 읽어두지 않았기 때문이고, 컬링은 매 프레임 가시성 테스트를 하기 때문에 "언제 화면 전환을 할지 모른다"는 개념이 존재하지 않습니다.
14/10/23 20:16
뭐 구체적인 상황을 알 수는 없지만 창문 너머로 살짝 보여야 될 수도 있고, 그때문에 집에 가까이 가면 오리를 프리(pre)렌더링을 해놔야 할 수도 있고 가능성은 많죠. 그리고 아마도 저 정도 프로젝트라면 이미 검증된 게임엔진을 쓰기 때문에 그런 정도의 초보적인 바보짓은 아닐거라고 생각합니다.
|
||||||||||||
