꽃미남 프로그래머 김포프가 창립한 탑 프로그래머 양성 교육 기관 POCU 아카데미 오픈!
절찬리에 수강생 모집 중!
프로그래밍 언어 입문서가 아닌 프로그래밍 기초 개념 입문서
문과생, 비전공자를 위한 프로그래밍 입문책입니다.
jobGuid 꽃미남 프로그래머 "Pope Kim"님의 이론이나 수학에 치우치지 않고 실무에 곧바로 쓸 수 있는 실용적인 셰이더 프로그래밍 입문서 #겁나친절 jobGuid "1판의내용"에 "새로바뀐북미게임업계분위기"와 "비자관련정보", "1판을 기반으로 북미취업에 성공하신 분들의 생생한 경험담"을 담았습니다.
Posted by 친절한티스

구조체의 멤버 변수를 정렬하는 것만으로도 구조체의 크기가 달라진다는 거 아시나요? 아래와 같이 구조체에 여러 타입들을 섞어서 썼을 경우 구조체 사이즈를 알아보겠습니다.

struct StructNonSorted
{
	bool bool1;
	int int1;
	int int2;
	bool bool2;
	char char1;
	int int3;
	char char2;
	int int4;
	char char3;
	int int5;
	bool bool3;
	int int6;
	bool bool4;
};



다음은 타입별로 멤버 변수를 정렬시켰을때의 구조체 크기를 살펴 보겠습니다.


struct StructSorted
{
	bool bool1;
	bool bool2;
	bool bool3;
	bool bool4;
	char char1;
	char char2;
	char char3;
	int int1;
	int int2;
	int int3;
	int int4;
	int int5;
	int int6;
};



무려 16이나 차이가 납니다. 왜이런 차이가 생길까요? VisualStudio C++의 경우 컴파일러 기본 옵션에 구조체 멤버 정렬 옵션(/Zp)이 8바이트로 정렬됩니다. 그래서 맨 처음 보여드린 구조체와 같이 정렬 되지 않은 상태인 경우 아래와 같이 중간에 패딩이 들어가게 됩니다. 그러면 그만큼 공간 낭비가 되고, 구조체의 크기가 커지게 되는 것이죠.



반대로 구조체를 크기 별로 정렬을 하면, 아래와 같이 8바이트 공간 안에 알차게 데이터가 들어가게 됩니다. 공간 낭비가 줄어들고, 그 만큼 구조체의 크기는 작아지게 되는 것이죠. 구조체의 크기가 작아지고 변수들이 정렬 되어있으면 메모리 친화적이게 되고, 캐싱 적중률도 높아지게 됩니다.


반응형
,
Posted by 대마왕J

비밀..이라지만 그렇게 거창하진 않습니다 허허허

그냥 뭐 조금 정리할 필요가 있어서 쓴 것 뿐이지요.

 

일단 유니티에는 여러 가지 텍스쳐 포맷이 있고, 그것들은 대부분 자동으로 선택이 되곤 합니다.

 

 

물론 Advanced로 하게 되면 이렇게 세부적으로 설정이 가능하지만, 이렇게까지 하실 분들은 별로 없겠죠.

게다가 이걸 하나 하나 다 설명하고, 유니티에서 사용되는 자동포맷이랑 연결해서 설명하려면 책으로 한 20페이지는 넘을겁니다 (...)

 

그러므로 여기서는 요약해서!

안드로이드!

에서만!

자동으로!!

 

사용하는 포맷에 한정해서 얘기하죠.

아참! ETC2는 빼겠습니다. 자동으로 설정되지도 않고, 아직 범용으로 사용되는 포맷도 아니라서요.

 

일단 기본적인 것. 다 아시겠지만 ...

유니티 엔진에는 어떤 텍스쳐라도 넣을 수 있습니다.

TGA를 넣어도 되고, jpg를 넣어도 되고, 심지어는 PSD를 넣어도 됩니다!!

전에 어떤 커뮤니티에서, 유니티에는 PNG를 넣는게 가장 가벼우니까 그렇게 넣자라는 글을 본 적도 있는데... -_-

 

결론부터 얘기하면, 그런건 하등 상관이 없습니다! 무조건 가장 품질 좋은 녀석을 넣으세요! 용량이 커도 됩니다!!

사이즈부터 포맷까지 모두 유니티 내부에서 다시 관리하기 때문에, 밖에서 만든 파일 포맷은 아무 상관이 없습니다. 오히려 밖에서 특정 포맷으로 압축해서 들어온 파일은 유니티 내부에서 '다시' 압축하기 때문에 이론적으로 더 깨질 가능성이 큽니다. [각주:1]

유니티건 언리얼이건 게임에서 쓰이는 파일 포맷은 거의 다 '손실압축' 파일 포맷이기 때문이지요[각주:2]

 

자 각설하고, 그럼 안드로이드에서 사용할 수 있는 파일 포맷에 대해 알아 보겠습니다.

 

 

=====================================================================

 

따란 - 3 가지 경우의 수가 있습니다.

이 경우의 수로 작성하면, 모든 기기에서 잘 돌아가는 파일 포맷이 됩니다. (물론 프로젝트가 안드로이드 상태여야 합니다)

고급 기능으로 바꾸면 다른 경우의 수도 많이 있지만, 그렇게 기계에 안맞는 포맷을 사용하면 안돌아가는 기기가 생기게 됩니다!

아니, 표현이 틀렸군요. 안돌아가는게 아니라요....

 

http://smilejsu.tistory.com/m/post/732

 

요거 참고하시면...

 

사용자 앱이 지원되지 않는 텍스쳐 압축(compression)을 사용하면 그 텍스쳐는 RGBA32로 무압축(uncompressed)되며 압축된 것들과 함께 메모리에 저장이 됩니다. 그래서 이 경우 텍스쳐의 압축을 푸는데 시간을 잃게되며 두번의 저장으로 인해 메모리 손실을 봅니다. 이것은 또한 렌더링 성능에도 아주 부정적인 영향을 줄 수 있습니다.

.... RGBA32 비트 무압축이라는 엄청난 결과가 나옵니다!!!! 히이이익

더 무서운 문제는, 이게 눈으로 구별할 수가 없다는 겁니다!!! 차라리 지원을 안해서 깨지면 몰라도, 아예 보이지도 않고 메모리만 처묵처묵하는 무서운 일이 일어난다는 것입니다.

그래서 우리는! 지원하는 파일 포맷을 매우 주의해서 써야 합니다!!!

 

 

그러므로 저 위 3가지 한도내에서 쓰는것이 가장 안전합니다. 다른 파일 포맷을 쓰고 싶으시더라도... 참아주셔야 합니다 ㅠㅠㅠㅠ 잘못하면 난리가 나요...

 

 

 

그럼 저 3가지 파일 포맷을 보면...

일단 저 3가지 자동 포맷도 2가지 경우로 다시 나눠집니다. 바로 '알파가 있느냐 없느냐!'

라는 걸로 말이죠

 

 

 

자 그럼 일단 이런 텍스쳐가 있습니다.

 

 

 

소개드립니다!!! 알파있슈알파없슈 형제입니다.

지금 보시면 알겠지만, 알파 있는 쪽이 0.3M 더 큽니다. 뭐 당연하지요. 알파가 있는 쪽이 좀 더 큰게 뭐 이상하지도 않죠.

 

그럼 이걸 압축(compressed) 로 해 보겠습니다.

 

1. 압축 (compressed) 알파없슈 

 

 

 

압축되고 알파 없는 이미지입니다. 512*512이므로 꽤 큰 이미지이지만, 글씨나 공의 외각에 아티펙트 (찌꺼기) 가 보이도록 압축되었습니다.

 

압축은 대충 이 정도의 느낌. 4*4 씩 압축하는 전형적인 게임 Texture 압축방법을 보여주고 있습니다.

 

크기는 170.7 KB

원본 이미지가 1M였으니 약 16.6% 의 크기가 되었습니다. 약 84%가 줄었으니  상당히 압축이 크게 되었지요!!!

 

이 방식은 안드로이드 기본 압축인 ETC1 입니다. 알파가 없을때의 기본 압축이죠.

일명 ETC1 4bit... 이 방식은 색상을 떨어뜨릴 뿐만 아니라, 색상끼리의 관계를 다시 손실 압축하여 용량을 줄입니다!

Compressed RGB texture. This is the default texture format for Android projects. ETC1 is part of OpenGL ES 2.0 and is supported by all OpenGL ES 2.0 GPUs. It does not support alpha. 4 bits per pixel (32 KB for a 256x256 texture)

 

 

 

 

2. 압축 (compressed) 알파있슈 

 

똑같은 compressed 옵션인데, 알파가 있는 녀석을 선택하면 용량이 거의 줄지 않으면서, 퀄리티도 개판이 됩니다!!

원래 1.3 M 였던게 0.7M가 되면 말 다했죠. 별로 이득이 없습니다. 절반밖에 되지 않으니까요. ETC1이 84%의 용량을 보이는 것과 비교해 보시면 차이가 확 느껴질 겁니다.

 

이 방식은 RGBA16 이라는 파일 포맷으로, 색상을 떨어뜨리지만 압축은 하지 않습니다. 사실상 압축이 아니예요!!! 

즉 원래 RGBA32 비트의 원본 포맷은 8:8:8:8 파일 포맷인데,

RGBA16 비트는 이를 그대로 색상 퀄리티만 떨어뜨려 4:4:4:4로 만들어 버리고 끝인 겁니다. 그래서 용량이 거의 절반인거죠.

바꾸면서 디더링이라도 좀 해주지.. 라는 생각도 있습니다만 하여간 해주지 않네요. 그래서 저렇게 줄무늬가 선명하게 남습니다.

 

 

 

뭐 비교할 필요도 없...

 

 

 

 

3. 16bit 알파없슈

이제 두 번째 옵션인 16비트를 보겠습니다.

일단 알파없는 녀석부터 보죠

 

 

 

 

 미세하게 줄무늬가 보입니다.

 

 

그래도 상당히 깨끗합니다!

이렇게 깨끗한 이유는.. 에또...

이것 역시 압축을 하지 않기 때문입니다.

색상만 떨어뜨려 버리지요.

 

용량을 보시면 알겠지만...

0.7MB 입니다. RGBA32bit 일때의 절반 정도죠.

알파가 없는데 왜? 라고 생각하실 수도 있겠지만, RGB 만 있을때 16bit로 바꾸면 이렇게 연산이 됩니다.

 

5:6:5

 

비트수는 확실히 RGBA16인 4:4:4:4 일때보다 각 채널당 할당 비트가 높아졌습니다만, 어쨌거나 8:8:8인 원본보다는 떨어집니다.

그리고 압축도 하지 않고요.

그래서 퀄리티는 높아졌지만 용량은 같은 상태인 겁니다.

정밀하진 않지만, 약간 퀄리티를 포기하는 한이 있어도 이녀석은 마스킹으로 사용 가능한 녀석입니다.

 

 

 

4. 16bit 알파있슈

이건.... compressed때랑 똑같습니다!!!!

어차피 compressed로 해도 알파가 있으면 RGBA16으로 바꾸기 때문에, 지금 알파 있는 녀석을 16bit로 바꿔도 똑같아집니다!!!

 

 

즉 이 녀석은 굳이 나서서 쓸 녀석은 아닙니다.

 

 

5. TrueColor 알파없슈

 

이 녀석은 TGA와 똑같은 용량에 무압축입니다! 즉 알파가 없으니 24bit이고 , 용량도 그 만큼인거지요.

최고의 퀄리티가 필요하면서 메모리를 낭비하고 싶을때 사용하는 파일 포맷입니다!!

 

퀄리티는 최강이지만 메모리 사용량은... ㅠㅠㅠ

 고품질의 UI를 사용하고 싶을 때 사용하는 포맷입니다.

 

 

 

6. TrueColor 알파있슈

 

역시 TGA와 똑같은 용량에 무압축입니다! 알파가 있고 32bit인 초 고품질 파일 포맷입니다.

 

 

 

 

 

 

정리하기

 

정리하자면, 안드로이드에서 사용할만한 파일 포맷은 다음과 같습니다.

 

1. 알파 없을때 (원본 1MB)

 

compressed : 압축 효과 가성비 최고, 170.7kb 가급적 이거 사용하길 원합니다.

 

16bit : 압축하지 않습니다. 약간 색상이 깎일 분입니다. 0.7MB . 용량이 너무 커서 되도록 사용 안했으면 좋겠지만 용량을 봐 가며 사이즈를 줄이는 방식으로 응용이 가능해 보입니다. 마스킹 같은 것을 사용할 때는 이 파일 포맷으로, 사이즈를 좀 줄여서 사용하는 것을  추천드립니다. 그리고 이것 쓸 때 말씀해 주세요. 특별하게 관리해야 하거든요.  최소한 TA가 알고 있기는 해야...  

 

truecolor : 최고의 품질을 보여야 할 때 사용합니다. 1.0M. 당연히 용량이 너무 큽니다. 이걸 쓸 때는 TA의 허락 (...) 을 감히 부탁드리겠습니다. 관리를 아주 잘 해야 하거든요

 

 

 

2. 알파 있을 때 (원본 1.3MB)

 

compressed : 사실상 16bit RGBA와 동일합니다. 0.7MB . 용량도 많이 주는 것도 아니면서, 심각하게 깨집니다... 기본 설정이 이 포맷이긴 하지만, 요새 업계에서도 이 포맷은 사용하지 않습니다. 차라리 알파 없는 텍스쳐 한 장을 더 쓰죠 . 사실상 사용 금지 포맷에 가깝습니다.

 

16bit : 아무 의미 없는 파일 포맷입니다!!! compressed와 동일합니다!!!

 

truecolor : 최고의 품질을 보여야 할 때 사용합니다. 1.3MB. 알파가 있으면서 최고의 품질을 보여야 할 때? 바로 UI 입니다!

기본적으로 NPOT (4의 배수가 아닌) 텍스쳐를 많이 사용해야 하는  UI의 특성상, 16bit나 truecolor를 사용해야 하는데 , 알파가 포함되어야 한다면 거의 선택할 수 있는 여지가 이것밖에 없습니다. (알파를 분리하는 대 작업을 한다면 모르겠지만...)

역시 이 파일 포맷은 UI 외엔 다른데서 사용하려면 반드시 허락이 필요한, 중요 관리 포맷입니다.

 

 

 

 

  1. 그런데 밖에서 DDS로 편집한 녀석은 그대로 들어오더라고요. PC 게임 만드실 분들은 참고하셔도 좋을 듯 합니다. 스마일 게이트 그래픽 팀 분들이 테스트 해주셨습니다. 감사 ! [본문으로]
  2. 압축 안하는 파일포맷을 쓸 때도 있습니다. 대표적인 경우가 UI [본문으로]
반응형

'아트' 카테고리의 다른 글

new GUI (ugui) 최적화 팁  (4) 2015.03.28
Unity5 Sky  (0) 2015.03.06
tex2Dlod와 tex2Dbias의 비교연구  (1) 2015.02.14
유니티(Unity) 의 뷰 프러스텀 (View frustom)컬링  (1) 2015.02.14
Unity3D와 LOD, 그리고 SImplygon  (2) 2015.01.14
,
Posted by ozlael

Draw call을 줄이는 것은 최적화 시 가장 중요한 요소중 하나입니다. Unity의 새로운 UI는 이러한 Draw call을 줄이는 것이 매우 용이하게 되어있습니다. 이 글에서는 new GUI의 Draw call에 대해 다루고자합니다.


new UI는 Button, Image 등 UI 컴포넌트를 추가 시 자동으로 Canvas하위로 배치되게 되어있습니다. 

유니티 UI의 Draw call은 이 Canvas 단위로 이루어집니다. Canvas 하위의 UI 컴포넌트들에 쓰이는 이미지가 SPrite packing되어 있다면 모두 하나의 Draw call로 처리가 가능합니다. 그러므로 유니티의 UI시스템을 이용하면 Draw call을 절약할 수 있어서 성능 향상에 매우 도움이 됩니다. 하지만 유니티의 UI를 이용한다고 해서 무조건 Draw call이 하나만 발생하는 것은 아닙니다. 성능 향상을 위해서 숙지하고 있어야 할 사항을 몇 가지 이야기하고자 합니다.



Draw call

그래픽 최적화를 위해서는 Draw call을 줄이는 것이 중요합니다. 이는 UI 역시 마찬가지입니다. 유니티의 UI에서는 Canvas마다 각자의 Vertex buffer를 가지고 있기때문에 Canvas가 두개면 최소 두번의 Draw call이 일어납니다. 이는 Canvas하위에 Canvas가 존재하는 경우에도 마찬가지입니다. 만일 Canvas안에 Canvas를 추가하는 경우에도, 씬 바로 하위의 Canvas는 하나 뿐이지만, 최소 두 개의 Draw call이 발생합니다.

위에도 언급했지만 하나의 Draw call이 되기 위해서는 사용되는 이미지들이 atlas 처리가 되어있어야합니다. 즉, Sprite packing되어있는 sprite들을 사용해야합니다. 다만, atlas 페이지가 두 개 이상으로 나뉘어져있으면 경우에 따라서 두 개 이상의 Draw call이 일어날 수도 있습니다. 따라서 Packing Tag를 잘 나누는 것이 중요합니다.

다만, Canvas 별로 Draw call이 일어난다고해서 무조건 모든 UI요소들을 하나의 Canvas에 몰아넣는 것이 꼭 좋은 솔루션인것만은 아닙니다. 동적으로 반응하는 버튼이나 Fill Image등을 처리하기위해서는 매 번 갱신 비용이 발생하기 때문입니다. Runtime시에 변경되지 않는 이미지와 실시간으로 변경되는 이미지가 같은 Canvas에 존재하면 변경되는 이미지 하나를 처리하기 위해서 Canvas의 Vertex buffer를 갱신하기때문에 쓸데없는 갱신 비용이 발생합니다. 따라서, Draw call을 하나 희생하더라도 정적인 이미지들은 별도의 canvas로 빼두는 것이 효율적일 수도 있습니다. 



Text

Text는 별도의 Texture를 사용하기때문에 별도의 Draw call로 발생합니다. 이 텍스쳐는 font별로 만들어지므로 font의 종류를 줄이는 것이 Draw call을 줄이는 방법이기도 합니다.

따라서 아래의 씬에서는 UI가 차지하는 Draw call이 3입니다. 아이콘 이미지들은 패킹되어있는 상태라서 모두 합쳐서 1개의 Draw call을 차지합니다. 텍스트는 3개가 존재하지만 사용된 폰트는 2개라서 2개의 Draw call을 차지합니다. 따라서 총 3개의 Draw call이 발생합니다.



More More ...

유니티의 새로운 UI를 효율적으로 쓰기 위한 더 많은 팁이나 퍼포먼스를 향상시키기 위한 더 많은 노하우들은 유나이트 서울 2015에서 얻어실 수 있습니다. 오셔서 더 많은 정보와 도움을 얻어가시길 바랍니다 :)

할인 공동구매 : http://cafe.naver.com/unityhub/18250

공식 페이지 link : http://unity3dkorea.com/uniteseoul2015/


반응형
,
Posted by 월하

안녕하세요. 달땡(월하) 입니다.


우와..... 진짜 오랜만이네요. 반성 하겠습니다. ㅋ


아~주 오래전


실무에서 쓰이는 엑셀 함수. 실전 사용법 - 엑셀 입문자용


이라는 포스팅을 한 적이 있는데

당시 결론이 "다들 vba 배우세요. vba가 짱이에요." 였죠.

그래서 VBA를 가져 왔습니다.


[죄송합니다. 이 짤방 한 번 써보고 싶었어요]




Sub test()

Dim i As Integer

i = 0

Do While i < 30

    i = i + 1
    
    If i Mod 15 = 0 Then
        Cells(i, 1).value = "반반 무마니"
        
    ElseIf i Mod 5 = 0 Then
        Cells(i, 1).value = "양념"
        
    ElseIf i Mod 3 = 0 Then
        Cells(i, 1).value = "후라이드"
        
    Else
        Cells(i, 1).value = i
        
    End If

Loop


End Sub

이게 뭐냐 하면 

  • 1부터 30까지의 숫자를 순서대로 출력 한다.
  • 단, 해당 숫자가 3의 배수일 경우 "후라이드"를 출력 한다.
  • 단, 해당 숫자가 5의 배수일 경우 "양념"을 출력 한다.
  • 단, 해당 숫자가 15의 배수일 경우 "반반 무마니"를 출력 한다.


즉, 아래와 같은걸 출력 하는거죠




근데 이걸 왜 하느냐?? 


특정 값까지의 결과를 출력하되, 조건에 따른 값의 변화를 줄 수 있다는게 중요 합니다.


간단하게 예를 들어



 

 플레이어 A

 플레이어 B

 체력

 1000 

 1000 

 공격력

 2

 10 


일때 둘이 싸우면 누가 이기는....




어.... 음.... 당연히.... B가 이기겠죠.


그렇다면 다시...



 

 플레이어 A

 플레이어 B 

 체력

 1000 

 1000 

 공격력

 2 

 10 

 치명타 확률

 10 % 

 5 % 

 치명타 배율

 200 % 

 10 % 

 체력 회복

 초당 1

 없음

 회피 확률

 10% 

  5%


이럴 경우 누가 이길지 계산을 엑셀로 하면.... 좀..... 많이.... 갑갑... 하죠.

일단 이건 나중에 알아보고 위에 vba 코드 부터 뜯어 보겠습니다.

그 전에 한번 실행이나 시켜 볼까요?

  1. 엑셀을 실행 시키고
  2. Alt + F11 을 누른 후
  3. 모듈 추가


그럼 텅 빈창이 나오는데 위의 코드를 복사하여 붙여 넣고 


F5 를 눌러 봅시다.


예쁘게 잘 나오죠? 안나오면 안되는데 ㄷㄷㄷ


그럼 잘 나온다고 치고 코드를 뜯어 보겠습니다




Sub test()

End Sub


vba 는 위와 같이 Sub ~~()로 시작 해서 End Sub로 종료 됩니다.



Dim i As Integer

i = 0


저기서 i 는 변수(변하는 수?!) 라고 하는데 vba에서 사용 하기 위해서 선언을 해줘야 합니다.


이 변수가 어떤 녀석인지, 정수인지 실수인지 알아야 하는거죠.


DIm 변수 As 정수(혹은 실수)


이렇게 쓰면 되는데 


정수 = Integer

실수 = double


로 쓰면 됩니다.


그리고 i = 0 이라는게 있는데 이건 i 의 초기 값을 설정 해 주는 부분 입니다.

말 그대로 i 의 값은 정수 중 0으로 설정 한다는 말이죠.




Do While i < 30

Loop



옙. 저게 VBA의 핵심 중 하나인 반복문 입니다.


Do While 조건 ~ Loop


이면 조건을 만족 하는 동안 아래의 내용을 계속 반복해라! 가 되는 겁니다. 아래 내용은 어디까지?  Loop 앞까지!


즉, 위 예제에서는

    i = i + 1
    
    If i Mod 15 = 0 Then
        Cells(i, 1).value = "반반 무마니"
        
    ElseIf i Mod 5 = 0 Then
        Cells(i, 1).value = "양념"
        
    ElseIf i Mod 3 = 0 Then
        Cells(i, 1).value = "후라이드"
        
    Else
        Cells(i, 1).value = i
        
    End If



요걸 계속 반복 하는 겁니다.


여기서 가장 중요한 부분은 


i = i + 1


요 부분 입니다.


제일 처음에  i = 0 으로 설정 했었죠.


그게 저 반복문 안에 들어가면 i = i + 1 의 수식을 계속 반복 하는겁니다.


언제까지? i 값이 30이 될 때 까지.


왜?  Do while i < 30 으로 반복문을 돌렸으니깐요.


다시 반복문을 살펴 봅시다.


i = i + 1 이 되었으니 i 의 값은 1이 되었습니다.


그리고 



If "조건 1" Then
    "값 1"
ElseIf "조건 2" Then
    "값 2"
Else
    "값 3"
End If



가 나왔는데 기존 엑셀의 if 함수를 반복 하는것과 같습니다.


즉, "조건 1"을 만족하면 "값 1"을,

"조건 2"를 만족하면 "값 2"를

그것도 아니면 "값 3"을 사용 하는 겁니다.


그럼 여기서 조건이 무엇이냐?


i Mod 15 = 0
i Mod 5 = 0
i Mod 3 = 0


요 세가지인데 각기 다음과 같습니다.


i / 15 한 값의 나머지가 0

i / 5 한 값의 나머지가 0

i / 3 한 값의 나머지가 0


즉, i / 15 의 나머지가 0이면 "반반 무마니"를

i / 5 의 나머지가 0이면 "양념"을

i / 3 의 나머지가 0이면 "후라이드"를 출력 하라는거죠.


어디에?


Cells(i, 1).value


즉, i 행 1열에 찍어 주라는 이야기죠.


여기서 value는 말 그대로 값을 의미합니다.


그러니 


 Cells(i, 1).value = "반반 무마니"
의 경우 i행, 1열의 값(value) = "반반 무마니" 가 되는 거죠.



이렇게 해서 최종적으로


i는 1 ~ 30까지 적되 

3의 배수는 "후라이드"

5의 배수는 "양념"

15의 배수는 "반반 무마니"가 되고 각 내용은

i행 1열에 출력이 되는 형태


가 완성이 됩니다!!

다음에 계속. 아마도.....

반응형

'기획' 카테고리의 다른 글

밸런싱, 숫자의 함정  (18) 2013.01.25
1 depth, 1 play, 1 rank  (2) 2012.12.11
게임개발에서의 스토리와 내러티브  (1) 2012.07.23
게임 UX 기획 - 04. prototyping 下  (4) 2012.06.15
게임 스토리와 연출  (8) 2012.06.10
,

Unity5 Sky

아트 2015. 3. 6. 00:35
Posted by 대마왕J

 



 


일단 스카이는 유니티 5 베타때 써봤던 그대로입니다.


프로시져로 생성된 하늘이 있고, 예전에는 없던 디렉셔널 라이트 하나가 들어가 있습니다.


그리고 그 라이트 각도에 맞춰서 태양이 있습니다.


디렉셔널 라이트 각도를 돌리면 태양이 맞춰 움직이며, 태양의 각도에 따라 (시간대에 따라) 하늘의 색이 변합니다.


이것은 마치 맨탈레이 sky  같은 느낌인데, PBS를 위해서는 반사해야할 객체가 있어야 하니 당연한 듯 합니다.


 


 



 


물론 저 라이트를 지운다고 이상해지진 않습니다.


애매한 시간대의 하늘이 되고, 태양이 없어진다는 것 뿐 ㅎ


 


다시 디렉셔널 라이트를 만들면 태양과 시간이 연동됩니다.


 


 



 


스카이박스에 대한 것은 윈도우 / 라이팅 창을 열면 볼 수 있습니다.


기본적으로 스카이박스 메터리얼이 적용되어 있지만, 수정할 수는 없게 되어 있습니다.


생성된 메터리얼을 붙여 넣은게 아니라 자동으로 들어가 있는 '내장형 메터리얼' 이기 때문이지요.


태양도 뭔가 따로 넣을 수 있는 것으로 보입니다.


 


 



 


 


하늘을 커스텀하게 만들기는 쉽습니다.


일단 프로젝트에 메터리얼을 하나 만들고, 그 메터리얼을 스카이박스 슬롯에 적용합니다.


 


그 후에 그 메터리얼의 쉐이더를 Skybox / Procedural로 적용시켜주면 기본으로 들어있던 스카이 박스와 동일한 설정이 나옵니다.


그렇지만 이번에는 메터리얼을 직접 만든 것이기 때문에 여러 설정을 바꿀 수 있게 되어 있죠.


간단히 봐서도 태양의 크기나 노출, 대기 두께 (물리적으로 대기 두께가 커지면 파장이 짧은 파란색의 빛이 산란해서 사라지기 때문에 파장이 긴 붉은 빛이 오래동안 살아 남아 전체적으로 하늘이 붉어집니다. ) 스카이와 바닥의 색 도 바꿀 수 있습니다.


 


PBS 시스템을 위해서는 필수적인 하늘 기능이지요.


 


그리고 이외에도 큐브맵을 넣을 수 있는 것으로 보입니다. 큐브맵은 6장의 이미지를 직접 넣는 방법과 HDR 큐브맵을 이용하는 방법이 있는 것 같은데요. HDR 큐브맵은 어떻게 넣어야 인식할지 모르겠네요. HDR 이미지를 Spherical 큐브맵으로 만들어서 집어 넣는 것인지? 모바일에서는 어떻게 지원되는지??? 나중에 테스트가 필요하겠습니다.


 



 


 


 


 



 


Sun 옵션은 뭔가 했더니 어떤 라이트를 태양으로 처리할 것인가에 대한 내용입니다. 아마도 Area 라이트를 제외한 모든 라이트가 되는 것이 아닐까 합니다.


뭔가 도움말이 상당히 부족하군요. 제가 못찾는 것인지..


 


 


 


반응형
,
Posted by 알 수 없는 사용자

오랜만에 글을 남겨보렵니다... 

요즘 모바일게임의 경쟁이 치열한 관계로 살아남기 위해서 과하게 일하다가 이렇게 살다가는 재미없어서 죽을 것 같아서, 올 해부터는 조금씩 개인적으로나마 엔진 쪽 작업을 하기 시작했습니다. 개발하기 앞서 준비 작업을 하다가 정리한 내용 중에 상식적으로 알면 좋을 것 같은 내용을 적어보려고 합니다. (아마 다들 아실 내용 같은데.. 음...). 최근에는 다들 유니티 엔진이나 언리얼 엔진을 사용하고 계실 것이기 때문에, 특별히 엔진 코어한 내용에 대해서는 이야기 하지 않겠습니다. ㅎㅎㅎ

엔진에서 멀티플랫폼을 지원해야 한다는 것은 이제는 너무 당연한 이야기입니다. 사실 유니티, 언리얼도 국내에서는 모바일에만 주로 사용하지만, PC, 모바일, 콘솔 거의 모든 플랫폼을 지원하니까요. 이런 플랫폼에서 기반이 되는 Graphics API가 존재합니다. DirectX, OpenGL 뭐 이런 것들입니다. 현재는 아마 모바일에서 OpenGL ES을 가장 많이 사용하겠죠...

저도 이전 엔진 개발하면서 이 부분을 좀 무식하게 처리한 부분이 있어서 깔끔하게 하고 싶어서, 이런 저런 준비를 하면서 과연 어떤 그래픽 API들을 지원해야 하나? 라는 고민을 하기 시작했습니다. 지금 세대에서 많이 사용하는 그래픽 API를 정리해보면 이런 것들이에요.

  • DirectX9, DirectX11 - Windows
  • OpenGL 3.x ~ OpenGL 4.x - Windows, Linux, Android 상위 기종, Console
  • OpenGL ES 1.1, 2.0, 3.x - Android, iOS

그런데, 재미있는 일이 벌어지고 있습니다. 이런 API 벤더들이 차세대 API를 만들고 있다는 것이에요. 

  • DirectX12 - Windows
  • glNext - Windows, Android, Linux, .... 
  • Metal - iOS
  • Mantle - AMD

여러가지 큰 변화들이 있겠지만, 방향성은 좀 더 직접적으로 그래픽 드라이버를 컨트롤 해보겠다는 것으로 알고 있습니다. 그래서, 렌더 상태 변화에 따른 OVERHEAD도 없어지구요. 뭐 이런 겁니다. 예를 들어서 iOS 계열에서만 사용할 수 있는 Metal API의 경우에도 이런 이유로 10배나 빨라질 수 있다고 (뻥?!)홍보를 하구요.

이 중에 가장 핫(?)한 이슈가 해외 개발자 포럼에서 있었는데, "과연 APPLE이 OpenGL ES의 차기 버전을 계속 지원할 것인가?"라는 거에요. 갑론을박이 있었는데, 이건 지켜봐야 알 것 같네요. 애플에서 앱스토어에만 게임을 출시하게 만드려고, Metal을 사용하게 하려고 하지 않을까? 라는 이야기도 있고, 그럴리가 없다는 의견도 있고 그렇습니다.

암튼 이런 이유로 이전에 모바일 초창기에 플랫폼 파편화 같은 이야기가 있었는데, 이제는 그래픽 API 파편화("API Fragmentation") 현상이 심합니다. 지금 당장 1년 안에 게임을 만들어서 출시한다면 아마 현세대 API 중에 하나를 사용하면 될 것 같아요. 하지만, 좀 장기적으로 퍼포먼스를 극대화해서 퀄리티를 죽여주겠다면 아마 차세대 API를 생각해보는 것도 좋을 것 같아요. 물론 아직은 더 기다려보는 것이 좋겠지요?!

저는 일단 DirectX11과 OpenGL ES 2.0 ~ 3.x를 선택해서 출발을 했습니다. 앞으로 어떤 API가 어떤게 엔진에 추가될 수 있을지 모르기 때문에, 최대한 새로운 API를 추가하기 쉽도록 엔진 구조를 잡아가는 중입니다. 

앞으로 아마 점점 엔진을 구매해서 사용해야 하는 이유가 점점 많이지는군요. ㅎㅎㅎ. 엔진을 구매하더라도 엔진에서 그래픽 API를 선택할 수 있을텐데, 어떤 것들이 있고, 어떤 특성이 있는지 한번 확인하고 사용해보시면 좋을 것 같습니다.
(나중에 기회가 되면 차세대 그래픽 API 특징에 대해서 한번 정리해보도록 할게욤... 아직 저도 깊게 보지는 않아서 몰라요. 그리고 GDC15에서 DirectX12, glNext 발표가 내정된 것으로 알고 있으니, 기대해보셔도 좋을 듯 합니다.)

그럼 늦었지만 새해 복 많이 받으세요.

반응형
,