대충 살아가는 게임개발자

테스트 3번

Tue, 05 May 2026 13:45:31 +0900

테스트 3번

테스트 2

Mon, 04 May 2026 22:05:00 +0900

테스트 글 올리기
이것저것 테스트

배경씬 제작 과제 _ 300팀

Tue, 24 Jun 2014 03:15:59 +0000

제 수업인 배경씬 제작 수업에서 그래픽 학생들이 제출한 과제입니다.

주제는 “이야기가 있을 것 같은 배경 만들기” 입니다

아직 shader를 못가르쳤더니 라이팅이나 셰이딩, 이펙트 등이 조금 아쉽지만, 그래도 프로그램 지원 전혀 없이 그래픽 3명이서 짧은 일정에 좋은 결과물을 만들었네요 :)

300팀 작품입니다. 셜록 홈즈 소설에 나올 것 같은 살인사건 현장을 만들었습니다.

(PC에서만 볼 수 있습니다 )

http://jpcorp.cafe24.com/300

Flow shader 신버전 제작

Fri, 16 May 2014 12:05:41 +0000

이전 shader에 기능을 추가해서 더 불이 리얼하게 구겨질 수 있도록 수정.

실시간으로 보면 제법 그럴듯 하다.

당연하게도 불에만 쓸 수 있는것은 아니며, 상당히 가볍게 만들어짐.

예제파일

Thu, 24 Apr 2014 18:25:24 +0000

N드라이브가 안돼서 당황중 ;;

Texture.zip

유니티 물 쉐이더 강의용 예제

Thu, 10 Apr 2014 02:08:08 +0000

흘러가는게 더 이쁘긴 하지만..

굴절은 프레그먼트 쉐이더를 짜야 하는 관계로 패스.

사수가 하나도 없는 상황이 되었어요 ㅠ 어째야 하지요?

Tue, 08 Apr 2014 21:10:17 +0000

Q. 안녕하세요.작은 모바일 게임 회사에 그래픽 신입으로 입사했는데 얼마 후 사수가 모두 떠나신 상황이 되었습니다. 그런데 그래픽 인원이 저 혼자만 남게 되었어요. ㅠㅠ 그런데 회사에서는 더이상의 충원이 없고 모든 그래픽 데이터를 저 혼자 공부해서 다 만들라고 하는 상황입니다. 이런 상황에서 저는 어떻게 해야 할까요??

지금 처하신 상황은 제가 이전에 말했던 내용인데요.

‘실력이 부족해, 기반이 없는 회사로 들어가게 되었을때 가장 최악의 상황은 사수가 없는 회사에 들어가게 되는 것이다’

라는 말씀이었습니다. 그래서 실력을 키워야 한다고 호통을 쳤던 거구요.

신입이 좋은 회사를 가는 것은 현실적으로 녹록치 않습니다. 그렇지만 최소한 현업에서 있을때는 존경심이 생기고 이끌어주는 사수는 하나 있어야 발전하기 좋습니다.

그렇지만 어쩌겠습니까. 이미 제가 걱정하던 이런 상황에 처하게 되었으니 말이죠.

일단 지금 상황은 기회의 위기 , 2가지의 상황이라고 할 수 있겠습니다.

사수가 없는 상황에 혼자서 다 해야 한다는 상황은 일단 위기 측면에서 봤을 때

자신이 잘못하고 있다는 것을 지적해줄 사람이 없다
문제가 생겼을때 해결해줄 수 있는 사람이 없다.
결정해야 할 상황이 생겼을 때 결정해줄 사람이 없다

라는 것입니다. 사실 치명적인 위기입니다. 자칫 잘못하다가는 잘못된 습관이 몸에 배게 될 수도 있고,

더 최악의 경우는 프로젝트나 회사가 아예 접혀 버리는 일이 일어날 가능성이 큽니다.

일단 미숙한 신입에게 일을 전부 맡겨 버린다는 것은, 회사 차원에서도 프로젝트를 접고 튈 준비를 하고 있다고 볼 수도 있겠습니다.

프로젝트의 퀄리티는 ‘포기’ 한다는 말이니까요. 그런 일이 일어난다면 님은 아무런 경력도 남지 않고, 갑자기 하루아침에 실직자가 될 수도 있습니다.

(월급은 제대로 나오고 있습니까? 또한 4대보험은 제대로 지불되고 있는지 공단측에 알아볼 필요가 있겠습니다. 지금은 위기상황입니다!)

자 그럼 반대로,

만약 정말로 이 회사를 본인이 최고로 신뢰하고 있고, 본인이 스스로 이 수라장을 헤쳐나갈 각오가 되어 있다면 이것은 기회가 될 수 있습니다.

이 회사의 상황은 정말 일시적인 상태이고, 회사의 재정상태나 프로젝트의 의지가 확실하며 신용이 가서 이 회사에서 뼈를 묻어도 되겠다고 생각한다면 모험을 걸어볼 수도 있는 단계입니다.

(사실 제 3자 입장에서 상황을 들어서는 별로 그런것 같지 않습니다만)

이것은 본인의 판단에 전적으로 맡길 수 밖에 없으며, 그 책임도 본인의 몫임을 잊지 마십시오. 이제 본인은 자신에게 책임을 지어야 하는 사회에 뛰어들었으니까요!

만약 어쨌건 이 회사가 믿음직하다면, 반대로 이것은 기회가 될 수도 있습니다.

요즘같은 때에 프로젝트의 모든 작업을 혼자서 해 볼수 있는 기회를 얻는다는 것은 엄청난 기회로 생각할 수도 있습니다.

단, 그만큼 고생은 각오해야 합니다.

작업에 대한 리스트업과 일정을 모두 본인이 잡아야 합니다.
컨셉 디자인을 잡기 위해서 기획자와 계속 회의하고 고민해야 합니다.
프로그래머와 계속 데이터의 효율에 대해 토론하고, 빠른 방법을 찾아야 합니다.
가장 효율적인 작업 프로세스를 찾아 고민하고 본인이 혼자 결정해 내야 합니다.
저녁엔 쉬거나 놀 시간이 없습니다. 계속 책을 보고, 인터넷 강의와 지인을 동원해서 미리 익히지 못했던 지식을 빨리 채워서 따라 잡아야만 합니다. 프로젝트의 프로세스에 대한 고민은 자면서 하세요.

회사는 공부시켜주는 곳이 아니니 당연합니다. 회사는 일을 하고 돈을 받는 곳이지, 기술을 전부받는 학원이 아니란 말이죠. 배우게 되는 것이 있더라도 회사 프로젝트가 진행되면서 부가적으로 배우는 곳입니다. (사실 회사에서 이런 지시를 내린게 이해가 안가지만 말입니다)

그렇지만 그렇게 고생하면서 ‘만약’ 이 프로젝트를 혼자서 제대로 완료한다면, 본인의 기술과 경험은 순식간에 엄청난 수준으로 올라가게 됩니다. 몇 년 치의 공부를 한 번에 해버리는 결과가 되니까요. 물론 하루에 잠은 거의 1-2시간씩, 거의 혹사당하듯이 진행해야겠지만 말이죠.

또한 이렇게 고생해서 무언가를 해 놓으면 그에 따른 보상이 약속되어 있어야 합니다. 이것 또한 본인이 판단해야 할 문제입니다

혹시나 회사에서 학원비까지 대 주겠다고 하면서까지 본인을 믿는다고 한다면, 본인의 판단에 따라 걸어볼 수도 있겠습니다. 어떤 상황인지는 본인이 가장 잘 알지 제3자가 알지는 못할 것입니다.

어쨌거나 여기서 가장 중요한 요소는 ‘본인이 이 회사를 얼마나 믿고 있느냐’ 라는 것입니다.

그리고 그 결정에 따른 책임은 온전히 본인의 몫이 될 것입니다.

자, 당신의 판단은 무엇입니까?

그리고, 제가 제대로 실력을 쌓고 회사를 알아보라고 험한 얘기 했던 이유를 아시겠지요?

어느 정도 이상의 실력을 쌓고 가면 이런 회사에 들어가게 될 확률은 대단히 줄어들고, 상황에 처하더라도 더욱 유연하게 대할 수 있을 것입니다. 지금 실력에 새로 회사를 알아보기도 힘들겠지 않습니까?

어쨌건 이미 화살은 시위를 떠났고 시간은 돌이킬 수 없습니다. 할 수 없습니다. 남보다 뒤쳐져서 안좋은 상황에 처한 것을 가지고 누구에게 불평하겠습니까.

아무쪼록 현명하고 후회없는 선택을 하시기 빕니다. 좋은 결과 나오면 좋겠네요.

CCRC 좋다

Mon, 07 Apr 2014 22:36:10 +0000

학교에서 지원해주는, 재학중인 학생들을 위한 팀 작업용 사무실. 24시간 개방.

각 파티션 마다 한 팀이라고 생각하면 된다.

사실 학교에서 이정도 시설을 지원해 주는데가 몇이나 있을까.

성공한 사람의 인생은 성공한 후에 포장되어 평범한 사람을 망친다.

Mon, 07 Apr 2014 08:50:24 +0000

출처를 표기하고 싶은데 워낙 그냥 막 돌아다니는 사진이라 ;;; 출처 아시면 알려주세요

유니티 툰 쉐이더 강의용 예제들

Fri, 04 Apr 2014 02:25:58 +0000

만들다보니 재미들려서 … :)

캐릭터그림자 제어

Thu, 27 Mar 2014 17:29:27 +0000

캐릭터의 Transform을 받아서, 캐릭터의 좌우 위치를 따라서 움직이고 캐릭터가 높이 뛰면 크기가 커지면서 연하게 되는 기능 제작. 연하게 되는건 쉐이더를 하나 만들어 프로퍼티에 접근하도록 만들었다.

using UnityEngine;using System.Collections;

public class ShadowControl : MonoBehaviour {

// Use this for initialization void Start () { trans = this.renderer.material.GetFloat ("_Transparent"); } private float trans; public Transform mainchar;

// Update is called once per frame void Update () {

float scalefactor = 1.0f + mainchar.position.y; gameObject.transform.position = new Vector3( mainchar.position.x,gameObject.transform.position.y,mainchar.position.z) ; gameObject.transform.localScale = new Vector3(scalefactor, scalefactor, 1); trans = 1.0f - (mainchar.position.y * 0.5f); this.renderer.material.SetFloat ("_Transparent", trans); }}

고전 액정 게임을 해보자

Sun, 23 Mar 2014 17:59:14 +0000

http://www.pica-pic.com/고전 액정 게임을 해볼 수 있는 사이트. 사이트 디자인도 매우 감각적으로 되어 있다.

타블렛으로 3D max 모델링 작업시에, 회전이 뚝뚝 끊어지는 문제 해결법

Tue, 18 Mar 2014 22:38:34 +0000

저는 예전부터 3D Max를 타블렛을 이용해서 조작해 왔습니다.

마우스를 오래 사용하다가 터널 증후군인가 뭔가 같은게 와서 말이죠…

타블렛 셋팅은 이렇게 합니다.

사이드 버튼의 아래 - 중간버튼

사이드 버튼의 위 - 오른쪽 클릭

이렇게 하면 꽤 쾌적하게 맥스를 타블렛으로 작업할 수 있습니다.

아, 줌 인/아웃은 컨트롤+알트+ 마우스 중간 클릭 드래그로 컨트롤 할 수 있으니까요.

그런데 여러 타블렛과 여러 맥스 버전을 사용하다가, 가끔 이런 문제가 발생하더군요.

분명 타블렛과 맥스나 그래픽 카드는 아무런 문제가 없는데, 몇몇 조합의 경우 맥스의 뷰포트 회전 (Orbit) 이 뚝뚝 끊기는 겁니다. 그것도 조작하기 매우 짜증날 정도로 말이죠.

드라이버도 새로 깔아보고, 듀얼 모니터도 모니터 하나로 바꿔보고, 맥스의 뷰포트 드라이버를 바꿔봤는데도 소용 무. 그래서 꽤 오랫동안 포기하고 살았습니다. 맥스하다가 짜증나니까 맥스가 손이 잘 안갈 지경이 되더군요.

그러다가 어쩌다 보니 … 검색하다가 해결책을 찾았습니다!

혹시나 동일한 증상인 분들에게 도움될까 + 내가 잊어버리면 다시 보려고

여기다 백업해 봅니다.

이 증상은 아마도 윈도우 7 의 타블렛 관리 부분이랑 충돌나는 것이 아닐까 합니다.

기본적으로 제어판에서 타블렛 기능은 다 죽여놓고 쓰시죠? 길게 누르면 마우스 오른쪽 클릭으로 인식하게 한다던가.. 그거야 뭐 다 그렇게 하시지만, 다른 방법을 사용해야 합니다.

출처는 http://forums.cgsociety.org/archive/index.php/t-854385.html

이고, 여기서 steve1701 의 글이 도움이 되었습니다.

The information in the last post on the polycount forums fixed it for me. I was getting the jerky orbit with the pen, and the center of right click menu was being obscured by the animated circle thingy. Windows 7 Pro 64 bit, Max 2010. Bamboo Fun Pen and Touch (which rocks!)What I did (following instructions from the original forum post referenced above):Open the Control Panel and type Group Policy in the Search box. Clicked on Edit group policy and up popped another window labeled Local Group Policy Editor. Drill down to User Configuration - Administrative Templates - Windows Components - Tablet PC - Cursors. Either click on Turn off pen feedback and then Edit Policy Setting or right click Turn off pen feedback and choose Edit. Another window opens, click on Enabled and click on Ok. No reboot, fix was immediate.Hope this helps.

우선 제어판에서 검색창에 “그룹 정책 편집” 을 검색합니다.

관리도구의 그룹 정책 편집이 뜰겁니다. 그걸 클릭합니다.

새 창이 뜰겁니다. 여기서 사용자 구성 / 관리 템플릿 / 윈도우 구성 요소를 누릅니다.

잔뜩 나오는 구성 요소에서 Tablet PC를 두 번 클릭합니다.

거기서 커서를 선택합니다. 펜 피드백 사용 안함이 나왔습니다.

펜 피드백 사용 안함을 오른쪽 클릭해서 ‘편집’ 을 선택합니다.

다시 새로 나오는 창에서 ‘사용’ 을 선택해 줍니다.

그리고 확인을 눌러서 창을 닫아 줍니다. 맥스를 사용해 봅니다.

저는 이렇게 잘 고쳤습니다!!!! Thx steve1701 !!!

게임 중독법 반대 서명 운동

Fri, 08 Nov 2013 00:26:50 +0000

http://www.k-idea.or.kr/signature/signature.asp

완전히 잠수중인 블로그이지만, 이거 한 번 안올리면 아무래도 평생 후회할것 같단 말이죠.
일단 제 입장은 게임쪽에 어떠한 안전장치가 있기는 해야 한다고 보지만,
밑도끝도없이 싸잡아서 마약취급하는 작금의 사태는 분노를 금치 못하겠군요.

제 의견은 게임이란 누텔라처럼 엄청나게 맛있는 초코렛이라는 겁니다.
당연히 먹으면 행복해지고, 또 먹고 싶어지고, 너무 많이 먹으면 건강에 위험할 수도 있는 겁니다.
아이들을 위해서라고요? 아이들이 뭘 먹는지는 그렇게 잘 알면서 왜 아이들이 뭐하고 노는지는 관심이 없는거죠?

먹는 것도 비만세 얘기도 있지만, 오히려 비만세는 지방함량이 높은 항목에 제한되어 있고 그나마도 논란이 많은 항목이죠.
그런데 게임은 어떤 기준도 없이 게임이라는 것 만으로 일단 잡아 매려 하네요.
마치 초코렛 먹고 이빨썩으니까 모든 음식은 이빨에 안좋은 것이라는 느낌.

기본적으로 바다이야기 같은 도박이랑 구분이나 하고 가던가,
인터넷 중독과 게임중독도 구분못하는 멍청이들이
겨우 자리잡고 있는 문화산업 죽이려 노력하고 있네요.

오늘의 C# 공부 :server / client

Mon, 15 Apr 2013 07:21:25 +0000

/////////// server

using System;
using System.Diagnostics;
using System.Net;
using System.Net.Sockets;
using System.Text;

namespace EchoServer
{
    class MainApp
    {
        static void Main(string[] args)
        {
            if (args.Length < 1)
            {
                Console.WriteLine(“사용법 :{0} ”, Process.GetCurrentProcess().ProcessName);
                return;
            }

            string bindIp = args[0];
            const int bindfort = 5425;
            TcpListener server = null;

            try
            {
                IPEndPoint localAddress =
                    new IPEndPoint(IPAddress.Parse(bindIp), bindfort);

server = new TcpListener(localAddress);

server.Start();

Console.WriteLine(“메아리 서버 시작…”);

                while (true)
                {
                    TcpClient client = server.AcceptTcpClient();
                    Console.WriteLine(“클라이언트 접속 :{0}”, ((IPEndPoint)client.Client.RemoteEndPoint).ToString());

NetworkStream stream = client.GetStream();

                    int length;
                    string data = null;
                    byte[] bytes = new byte[256];

                        while ((length = stream.Read(bytes,0,bytes.Length)) != 0)
                        {
                            data = Encoding.Default.GetString(bytes, 0, length);
                            Console.WriteLine (String.Format(“수신{0}",data)) ;
                            byte[] msg = Encoding.Default.GetBytes(data);
                            stream.Write(msg, 0, msg.Length);

Console.WriteLine(String.Format(“송신: {0}”, data));
}

                        stream.Close();
                        client.Close();
                }

}

            catch (SocketException e)
            {
                Console.WriteLine(e);
            }

            finally
            {
                server.Stop();
            }

Console.WriteLine(“서버를 종료합니다”);

}
}
}

//////Client

using System;
using System.Diagnostics;
using System.Net;
using System.Net.Sockets;
using System.Text;

namespace jpClient
{
    class MainApp
    {
        static void Main(string[] args)
        {
             Console.WriteLine(“args={0}",args.Length);
            if (args.Length < 4)
            {
                Console.WriteLine(
                    “사용법 : {0} ”, Process.GetCurrentProcess().ProcessName);
                return;
            }

            string bindIP = args[0];
            int bindPort = Convert.ToInt32(args[1]);
            string serverIP = args[2];
            const int serverPort = 5425;
            string message = args[3];

            try
            {
                IPEndPoint clientAddress =
                    new IPEndPoint(IPAddress.Parse(bindIP), bindPort);
                IPEndPoint serverAddress =
                    new IPEndPoint(IPAddress.Parse(serverIP), serverPort);

Console.WriteLine(“클라이언트 : {0} , 서버 : {1}”, clientAddress.ToString(), serverAddress.ToString());

TcpClient client = new TcpClient(clientAddress);

client.Connect(serverAddress);

byte[] data = System.Text.Encoding.Default.GetBytes(message);

NetworkStream stream = client.GetStream();

stream.Write(data, 0, data.Length);

Console.WriteLine(“송신 :{0}”, message);

data = new byte[256];

string responseData = “”;

int bytes = stream.Read(data, 0, data.Length);

responseData = Encoding.Default.GetString(data, 0, bytes);

Console.WriteLine(“수신 :{0}”, responseData);

                stream.Close();
                client.Close();
            }

            catch (SocketException e)
            {
                Console.WriteLine(e);
            }

Console.WriteLine(“클라이언트를 종료합니다”);

}
}
}

오늘의 C# 공부 : winform

Fri, 12 Apr 2013 07:01:46 +0000

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;

namespace WindowsFormsApplication1
{
public partial class Mainform : Form
{

Random random = new Random(37);

        public Mainform()
        {
            InitializeComponent();

            lvDummy.Columns.Add(“Name”);
            lvDummy.Columns.Add(“Depth”);
        }

        private void Mainform_Load(object sender, EventArgs e)
        {
            var Fonts = FontFamily.Families;
            foreach (FontFamily font in Fonts)
                cboFont.Items.Add(font.Name);
        }

        void ChangeFont()
        {
            if (cboFont.SelectedIndex < 0)
                return;

FontStyle style = FontStyle.Regular;

if (chkBold.Checked)
style |= FontStyle.Bold;

if (chkItalic.Checked)
style |= FontStyle.Italic;

txtSampleText.Font = new Font((string)cboFont.SelectedItem, 10, style);
}

        private void cboFont_SelectedIndexChanged(object sender, EventArgs e)
        {
            ChangeFont();
        }

        private void chkBold_CheckedChanged(object sender, EventArgs e)
        {
            ChangeFont();
        }

        private void chkItalic_CheckedChanged(object sender, EventArgs e)
        {
            ChangeFont();
        }

        private void tbDummy_Scroll(object sender, EventArgs e)
        {
            pgDummy.Value = tbDummy.Value;
        }

        private void btnModal_Click(object sender, EventArgs e)
        {
            Form frm = new Form();
            frm.Text = “Modal Form”;
            frm.Width = 300;
            frm.Height = 100;
            frm.BackColor = Color.Red;
            frm.ShowDialog();
        }

        private void btnModaless_Click(object sender, EventArgs e)
        {
            Form frm = new Form();
            frm.Text = “Modaless Form”;
            frm.Width = 300;
            frm.Height = 300;
            frm.BackColor = Color.Green;
            frm.Show();
        }

        private void btnMsgBox_Click(object sender, EventArgs e)
        {
            MessageBox.Show(txtSampleText.Text, “MessageBox Test”, MessageBoxButtons.OK, MessageBoxIcon.Exclamation);
        }

        void TreeToList()
        {
            lvDummy.Items.Clear();
            foreach (TreeNode node in tvDummy.Nodes)
                TreeToList(node);
        }

        void TreeToList(TreeNode Node)
        {
            lvDummy.Items.Add(
                new ListViewItem(
                    new string[] { Node.Text, Node.FullPath.Count(f => f == ‘\’).ToString() }));

            foreach (TreeNode node in Node.Nodes)
            {
                TreeToList(node);
            }
        }

        private void btnAddRoot_Click(object sender, EventArgs e)
        {
            tvDummy.Nodes.Add(random.Next().ToString());
            TreeToList();
        }

        private void btnAddChild_Click(object sender, EventArgs e)
        {
            if (tvDummy.SelectedNode == null)
            {
                MessageBox.Show(“선택된 노드가 없습니다”, “TreeView Test”, MessageBoxButtons.OK, MessageBoxIcon.Error);
                return;
            }

            tvDummy.SelectedNode.Nodes.Add(random.Next().ToString());
            tvDummy.SelectedNode.Expand();
            TreeToList();
        }

}
}

오늘의 C# 공부 : WinForm

Mon, 08 Apr 2013 07:36:48 +0000

////simpleWindow

//using System;

//namespace SimpleWindow
//{
//    class MainApp : System.Windows.Forms.Form
//    {
//        static void Main(string[] args)
//        {
//            System.Windows.Forms.Application.Run(new MainApp());
//        }
//    }
//}

////SimpleWindowClose
//using System;
//using System.Windows.Forms;

//namespace UsingApplication
//{
//    class MainApp : Form
//    {
//        static void Main(string[] args)
//        {
//            MainApp form = new MainApp();

//            form.Click += new EventHandler((sender, eventargs) =>
//            {
//                Console.WriteLine(“closing Window,,,”);
//                Application.Exit();
//            });

// Console.WriteLine(“Starting Window Application…”);
// Application.Run(form);

// Console.WriteLine(“Exiting Window Application….”);

// }

// }
//}

////메시지 필터
//using System;
//using System.Windows.Forms;

//namespace MessageFilter
//{
//    class MessageFilter : IMessageFilter
//    {
//        public bool PreFilterMessage(ref Message m)
//        {
//            if (m.Msg == 0x0F || m.Msg == 0x200 || m.Msg == 0x113)
//                return false;

// Console.WriteLine("{0} : {1} “, m.ToString(), m.Msg);

// if (m.Msg == 0x201)
// Application.Exit();

//            return true;
//        }
//    }

//    class MainApp : Form
//    {
//        static void Main(string[] args)
//        {
//            Application.AddMessageFilter(new MessageFilter());
//            Application.Run(new MainApp());
//        }
//    }
//}

////form Event

//using System;
//using System.Windows.Forms;

//namespace Formevent
//{

//    class MainApp : Form
//    {
//        public void MyMouseHandler(object sender, MouseEventArgs e)
//        {
//            Console.WriteLine(“Sender : {0} “, ((Form)sender).Text);
//            Console.WriteLine(“X:{0} , Y:{1}”, e.X, e.Y);
//            Console.WriteLine(“Button : {0} , Click : {1}”, e.Button, e.Clicks);
//            Console.WriteLine();
//        }

//        public MainApp(string title)
//        {
//            this.Text = title;
//            this.MouseDown +=new MouseEventHandler(MyMouseHandler);
//        }

//        static void Main(string[] args)
//        {
//            Application.Run(new MainApp(“Mouse Event Test”));
//        }
//    }

//}

////Form Size

//using System;
//using System.Windows.Forms;

//namespace FormSize
//{
//    class MainApp : Form
//    {
//        static void Main(string[] args)
//        {
//            MainApp form = new MainApp();
//            form.Width = 300;
//            form.Height = 200;

// form.MouseDown += new MouseEventHandler(form_MouseDown);

// Application.Run(form);
// }

//        static void form_MouseDown(object sender, MouseEventArgs e)
//        {
//            Form form = (Form)sender;
//            int oldWidth = form.Width;
//            int oldHeigth = form.Height;

//            if (e.Button == MouseButtons.Left)
//            {
//                if (oldWidth < oldHeigth)
//                {
//                    form.Width = oldHeigth;
//                    form.Height = oldWidth;
//                }
//            }

//            else if (e.Button == MouseButtons.Right)
//            {
//                if (oldHeigth < oldWidth)
//                {
//                    form.Width = oldHeigth;
//                    form.Height = oldWidth;

//                }
//            }

//            Console.WriteLine(“윈도우의 크기가 변경되었습니다”);
//            Console.WriteLine(“Width : {0} , Height {1} “, form.Width, form.Height);
//        }
//    }
//}

////백그라운드 이미지조절하기

//using System;
//using System.Drawing;
//using System.Windows.Forms;

//namespace FormBackground
//{
//    class MainApp : Form
//    {
//        Random rand;
//        public MainApp()
//        {
//            rand = new Random();

//            this.MouseWheel += new MouseEventHandler(MainApp_MouseWheel);
//            this.MouseDown += new MouseEventHandler(MainApp_MouseDown);
//        }

//        void MainApp_MouseDown(object sender, MouseEventArgs e)
//        {
//            if (e.Button == MouseButtons.Left)
//            {
//                Color oldcolor = this.BackColor;
//                //this.BackColor = Color.FromArgb(rand.Next(0, 255), rand.Next(0, 255), rand.Next(0, 255));
//                this.BackColor = Color.FromArgb(255, 255, 0, 0);

//            }

//            else if (e.Button == MouseButtons.Right)
//            {
//                if (this.BackgroundImage != null)
//                {
//                    this.BackgroundImage = null;
//                    return;
//                }

// string file = “sample.jpg”;

//                if (System.IO.File.Exists(file) == false)
//                    MessageBox.Show(“파일이 없ㅋ엉ㅋ”);
//                else
//                    this.BackgroundImage = Image.FromFile(file);
//            }
//        }

//        void MainApp_MouseWheel(object sender, MouseEventArgs e)
//        {
//            this.Opacity = this.Opacity + (e.Delta > 0 ? 0.1 : -0.1);
//            Console.WriteLine(“Opacity : {0}”, this.Opacity);
//        }

//        static void Main(string[] args)
//        {
//            Application.Run(new MainApp());
//        }
//    }
//}

////폼 스타일
//using System;
//using System.Windows.Forms;

//namespace FormStyle
//{
//    class MainApp : Form
//    {
//        static void Main(string[] args)
//        {
//            MainApp form = new MainApp();

// form.Width = 400;
// form.MouseDown += new MouseEventHandler(form_MouseDown);

// Application.Run(form);
// }

//        static void form_MouseDown(object sender, MouseEventArgs e)
//        {
//            Form form = (Form)sender;

//            if (e.Button == MouseButtons.Left)
//            {
//                form.MaximizeBox = true;
//                form.MinimizeBox = true;
//                form.Text = “최소 최대 오케이”;
//            }

//            else if (e.Button == MouseButtons.Right)
//            {
//                form.MaximizeBox = false;
//                form.MinimizeBox = false;
//                form.Text = “최소 최대 끔”;
//            }
//        }
//    }
//}

//폼과 컨트롤
using System;
using System.Windows.Forms;

namespace FormAndControl
{
    class MainApp : Form
    {
        static void Main(string[] args)
        {
            Button button = new Button();

            button.Text = “Click Me!”;
            button.Left = 100;
            button.Top = 50;

            button.Click += (object sender, EventArgs e) =>
                {
                    MessageBox.Show(“딸깍”);
                };

            MainApp form = new MainApp();
            form.Text = “Form & Control”;
            form.Height = 150;

form.Controls.Add(button);

            Application.Run(form);
        }
    }
}

오늘의 C# 공부 : 인터럽트 , 싱크로 나이즈

Fri, 05 Apr 2013 06:38:43 +0000

////인터럽트

//using System;
//using System.Security.Permissions;
//using System.Threading;

//namespace InterrruptingThread
//{
//    class SideTask
//    {
//        int count;

//        public SideTask(int count)
//        {
//            this.count = count;
//        }

//        public void KeepAlive()
//        {
//            try
//            {
//                Console.WriteLine(“Running thread isn’t gonna by interruped”);

// Thread.SpinWait(1000000000);

//                while (count > 0)
//                {
//                    Console.WriteLine("{0} left", count–);

//                    Console.WriteLine(“Entering into WaitJoinSleep State…”);
//                    Thread.Sleep(10);
//                }
//                Console.WriteLine(“Count ; 0”);
//            }

//            catch (ThreadInterruptedException e)
//            {
//                Console.WriteLine(e);
//            }

//            finally
//            {
//                Console.WriteLine(“Clearing resource…”);
//            }
//        }

//        class MainApp
//        {
//            static void Main(string[] args)
//            {
//                SideTask task = new SideTask(100);
//                Thread t1 = new Thread(new ThreadStart(task.KeepAlive));
//                t1.IsBackground = false;

// Console.WriteLine(“Starting Thread….”);
// t1.Start();

// Thread.Sleep(100);

// Console.WriteLine(“Interrupting thread…”);
// t1.Interrupt();

// Console.WriteLine(“Wating untile thread stops…”);
// t1.Join();

//                Console.WriteLine(“Finished”);
//            }
//        }
//    }
//}

////synchronize/

//using System;
//using System.Threading;

//namespace Synchronize
//{
//    class Counter
//    {
//        const int LOOP_COUNT = 1000;

// readonly object thisLock;

//        private int count;
//        public int Count
//        {
//            get { return count; }
//        }

//        public Counter()
//        {
//            thisLock = new Object();
//            count = 0;
//        }

//        public void Increse()
//        {
//            int loopCount = LOOP_COUNT;
//            while (loopCount– > 0)
//            {
//                lock (thisLock)
//                {
//                    count++;
//                }
//                Thread.Sleep(1);
//            }
//        }

//        public void Decrease()
//        {
//            int loopCount = LOOP_COUNT;
//            while (loopCount– > 0)
//            {
//                lock (thisLock)
//                {
//                    count–;
//                }
//                Thread.Sleep(1);
//            }
//        }
//    }

//    class MainApp
//    {
//        static void Main(string[] args)
//        {
//            Counter counter = new Counter();

// Thread incThread = new Thread(new ThreadStart(counter.Increse));
// Thread decThread = new Thread(new ThreadStart(counter.Decrease));

// incThread.Start();
// decThread.Start();

// incThread.Join();
// decThread.Join();

//            Console.WriteLine(counter.Count);
//        }
//    }
//}

////모니터 클래스로 동기화하기

//using System;
//using System.Threading;

//namespace UsingMoniter
//{
//    class Counter
//    {
//        const int LOOP_COUNT = 1000;

// readonly object thisLock;

//        private int count;
//        public int Count
//        {
//            get { return count; }
//        }

//        public Counter()
//        {
//            thisLock = new object();
//            count = 0;
//        }

//        public void Increase()
//        {
//            int loopCount = LOOP_COUNT;

//            while(loopCount– >0)
//            {
//                Monitor.Enter(thisLock);
//                try
//                {
//                    count++;
//                }
//                finally
//                {
//                    Monitor.Exit(thisLock);
//                }
//                Thread.Sleep(1);
//            }
//        }

//        public void Decrease()
//        {
//            int loopCount = LOOP_COUNT;
//            while (loopCount– > 0)
//            {
//                Monitor.Enter(thisLock);
//                try
//                {
//                    count–;
//                }

//                finally
//                {
//                    Monitor.Exit(thisLock);
//                }
//                Thread.Sleep(1);
//            }
//        }
//    }

//    class MainApp
//    {
//        static void Main(string[] args)
//        {
//            Counter counter = new Counter();

// Thread incThread = new Thread(new ThreadStart(counter.Increase));
// Thread decThread = new Thread(new ThreadStart(counter.Decrease));

// incThread.Start();
// decThread.Start();

// incThread.Join();
// decThread.Join();

//            Console.WriteLine(counter.Count);
//        }
//    }
//}

//// 저수준 동기화

//using System;
//using System.Threading;

//namespace WaitPalse
//{
//    class Counter
//    {
//        const int LOOP_COUNT = 1000;
//        readonly object thisLock;

// bool lockedCount = false;

//        private int count;
//        public int Count
//        {
//            get { return count; }
//        }

//        public Counter()
//        {
//            thisLock = new object();
//            count = 0;
//        }

//        public void Increase()
//        {
//            int loopCount = LOOP_COUNT;

//            while (loopCount– > 0)
//            {
//                lock (thisLock)
//                {
//                    while (count > 0 || lockedCount == true)
//                        Monitor.Wait(thisLock);

//                    lockedCount = true;
//                    count++;
//                    lockedCount = false;
//                    //Console.WriteLine(count);
//                    Monitor.Pulse(thisLock);
//                }
//            }
//        }

//        public void Decrese()
//        {
//            int loopCount = LOOP_COUNT;

//                    lockedCount = true;
//                    count–;
//                    lockedCount = false;
//                    //Console.WriteLine(count);
//                    Monitor.Pulse(thisLock);
//                }
//            }
//        }

//        class MainApp
//        {
//            static void Main(string[] args)
//            {
//                Counter counter = new Counter();

// Thread incThread = new Thread(new ThreadStart(counter.Increase));
// Thread DecThread = new Thread(new ThreadStart(counter.Decrese));

// incThread.Start();
// DecThread.Start();

// incThread.Join();
// DecThread.Join();

// Console.WriteLine(counter.Count);

//            }
//        }
//    }
//}

// task
using System;
using System.IO;
using System.Threading;
using System.Threading.Tasks;

namespace UsingTask
{
    class MainApp
    {
        static void Main(string[] args)
        {
            string srcFile = args[0];

            Action FileCopyAction = (object state) =>
                {
                    String[] paths = (String[])state;
                    File.Copy(paths[0], paths[1]);

Console.WriteLine(“TaskID:{0} , TaskID:{1} ,{2} was copied to {3}”, Task.CurrentId, Thread.CurrentThread.ManagedThreadId, paths[0], paths[1]);
};

Task t1 = new Task(
FileCopyAction, new string[] {srcFile, srcFile+".copy1"});

Task t2 = Task.Factory.StartNew(FileCopyAction, new string[] {srcFile, srcFile+ “.copy2”});

t1.Start();

            Task t3 = new Task(
                FileCopyAction, new string[] { srcFile, srcFile + “.copy3” }
                );

t3.RunSynchronously();

            t1.Wait();
            t2.Wait();
            t3.Wait();

}
}
}

오늘의 C#공부 : 직렬화, 스레드/ 테스크

Mon, 01 Apr 2013 07:56:53 +0000

////직렬화

//using System;
//using System.IO;
//using System.Runtime.Serialization.Formatters.Binary;

//namespace Serialization
//{
//    [Serializable]
//    class NameCard
//    {
//        public string Name;
//        public string Phone;
//        public int Age;
//    }

//    class MainApp
//    {
//        static void Main(string[] args)
//        {
//            Stream ws = new FileStream(“a.dat”, FileMode.Create);
//            BinaryFormatter serializer = new BinaryFormatter();

//            NameCard nc = new NameCard();
//            nc.Name = “박상현”;
//            nc.Phone = “010-123-4567”;
//            nc.Age = 33;

// serializer.Serialize(ws, nc);
// ws.Close();

// Stream rs = new FileStream(“a.dat”, FileMode.Open);
// BinaryFormatter deserializer = new BinaryFormatter();

//            NameCard nc2;
//            nc2 = (NameCard)deserializer.Deserialize(rs);
//            rs.Close();

//            Console.WriteLine(“Name: {0}”, nc2.Name);
//            Console.WriteLine(“Phone: {0}”, nc2.Phone);
//            Console.WriteLine(“Age:   {0}”, nc2.Age);

// }
// }
//}

////List를 직렬화하고역직렬화하기

//using System;
//using System.Collections.Generic;
//using System.IO;
//using System.Runtime.Serialization.Formatters.Binary;

//namespace SerializingCollection
//{
// [Serializable]

//    class NameCard
//    {
//        public string Name;
//        public string Phone;
//        public int Age;

//        public NameCard(string Name, string Phone, int Age)
//        {
//            this.Name = Name;
//            this.Phone = Phone;
//            this.Age = Age;
//        }
//    }

//            List list = new List();
//            list.Add(new NameCard(“박상현”, “010-123-4567”, 33));
//            list.Add(new NameCard(“김연아”, “010-323-1111”, 22));
//            list.Add(new NameCard(“장미란”, “010-555-5555”, 26));

// serializer.Serialize(ws, list);
// ws.Close();

// Stream rs = new FileStream(“a.dat”, FileMode.Open);
// BinaryFormatter deserializer = new BinaryFormatter();

//            List list2;
//            list2 = (List)deserializer.Deserialize(rs);
//            rs.Close();

//            foreach (NameCard nc in list2)
//            {
//                Console.WriteLine(
//                    “Name : {0}, Phone : {1} , Age {2}”
//                    , nc.Name, nc.Phone, nc.Age);
//            }
//        }
//    }

//}

////스레드와 테스크

//using System;
//using System.Threading;

//namespace BasicThread
//{
//    class MainApp
//    {
//        static void DoSomething()
//        {
//            for (int i = 0; i < 5; i++)
//            {
//                Console.WriteLine(“DoSomeThing : {0}” , i);
//                    Thread.Sleep(10);
//            }
//        }

//        static void Main(string[] args)
//        {
//            Thread t1 = new Thread(new ThreadStart(DoSomething));

// Console.WriteLine(“Starting Thread…”);
// t1.Start();

//            for (int i = 0; i < 5; i++)
//            {
//                Console.WriteLine (“Main : {0}”, i);
//                Thread.Sleep(10);
//            }

// Console.WriteLine(“Wating until thread stops…”);
// t1.Join();

//            Console.WriteLine(“Fineshed”);
//        }
//    }
//}

////스레드 임의로 종료시키기

//using System;
//using System.Threading;

//namespace AbortingThread
//{
//    class SideTesk
//    {
//        int count;

//        public SideTesk(int count)
//        {
//            this.count = count;
//        }

//        public void KeepAlive()
//        {
//            try
//            {
//                while (count > 0)
//                {
//                    Console.WriteLine("{0} left", count–);
//                    Thread.Sleep(10);
//                }
//                Console.WriteLine(“Count : 0”);
//            }

//            catch (ThreadAbortException e)
//            {
//                Console.WriteLine(e);
//                Thread.ResetAbort();
//            }

//            finally
//            {
//                Console.WriteLine(“Clearing resource…”);
//            }
//        }

//        class MainApp
//        {
//            static void Main(string[] args)
//            {
//                SideTesk task = new SideTesk(100);
//                Thread t1 = new Thread(new ThreadStart(task.KeepAlive));
//                t1.IsBackground = false;

// Console.WriteLine(“Starting thread…”);
// t1.Start();

// Thread.Sleep(100);//느리게 하고..

// Console.WriteLine(“Aborting thread….”);
// t1.Abort();

// Console.WriteLine(“Wating until thread stops….”);
// t1.Join();

//                Console.WriteLine(“Finished”);
//            }
//        }

//    }
//}

////Thread State

//using System;
//using System.Threading;

//namespace UsingThreadState
//{
//    class MainApp
//    {
//        private static void PrintThreadState(ThreadState state)
//        {
//            Console.WriteLine("{0,-16} : {1}", state, (int)state);
//        }

//        static void Main(string[] args)
//        {
//            PrintThreadState(ThreadState.Running);

// PrintThreadState(ThreadState.StopRequested);

// PrintThreadState(ThreadState.SuspendRequested);

// PrintThreadState(ThreadState.Background);

// PrintThreadState(ThreadState.Unstarted);

// PrintThreadState(ThreadState.Stopped);

// PrintThreadState(ThreadState.WaitSleepJoin);

// PrintThreadState(ThreadState.Suspended);

// PrintThreadState(ThreadState.AbortRequested);

// PrintThreadState(ThreadState.Aborted);

//            PrintThreadState(ThreadState.Aborted | ThreadState.Stopped);
//        }
//    }
//}

오늘의 C# 공부 : 파일 다루기, 스트림.

Wed, 27 Mar 2013 07:49:21 +0000

//////////////////////////////////////////////////
/////파일 다루기 /////////////////////////////////
/////////////////////////////////////////////////

//// 디렉토리 / 파일 정보 조회하기

//using System;
//using System.Linq;
//using System.IO;

//namespace Dir
//{
//    class MainApp
//    {
//        static void Main(string[] args)
//        {
//            string directory;
//            if (args.Length < 1)
//                directory = “.”;
//            else
//                directory = args[0];

// Console.WriteLine("{0} directory Info", directory);
// Console.WriteLine("-Directories : “);

//            var directories = (from dir in Directory.GetDirectories(directory)
//                               let info = new DirectoryInfo(dir) //let이 뭐더라
//                               select new
//                               {
//                                   Name = info.Name,
//                                   Attributes = info.Attributes
//                               }).ToList();//이 부분에 대한 설명 필요

// foreach (var d in directories)
// Console.WriteLine ( “{0}:{1}”, d.Name, d.Attributes);

//            Console.WriteLine("-Files :”);
//            var files = (from file in Directory.GetFiles(directory)
//                         let info = new FileInfo(file)
//                         select new
//                         {
//                             Name = info.Name,
//                             FileSize = info.Length,
//                             Attributes = info.Attributes
//                         }).ToList();

//            foreach ( var f in files)
//                Console.WriteLine ( “{0} : {1},{2}",f.Name, f.FileSize, f.Attributes);

//        }
//    }
//}

////디렉토리 / 파일 생성하기
//using System;
//using System.IO;

//namespace Touch
//{
//    class MainApp
//    {
//        static void OnWrongPathType(string path)
//        {
//            Console.WriteLine(“Type{0} is Wrong Type”);
//            //Console.WriteLine(“Type{0} is Wrong Type”,path);
//            return;
//        }

// static void Main(string[] args)
// {

//            if (args.Length == 0)
//            {
//                Console.WriteLine(
//                    “Usage : Touch.exe [Type : File / Directory]”);
//                return;
//            }

// string path = args[0];

//            string type = “File”;
//            if (args.Length > 1)
//                type = args[1];

//            if (File.Exists(path) || Directory.Exists(path))
//            {
//                if (type == “File”)
//                    File.SetLastWriteTime(path, DateTime.Now);
//                else if (type == “Directory”)
//                    Directory.SetLastWriteTime(path, DateTime.Now);
//                else
//                {
//                    OnWrongPathType(path);
//                    return;
//                }

// Console.WriteLine(“Updated {0} {1}”, path, type);

// return;
// }

//            if (type == “File”)
//                File.Create(path).Close();
//            else if (type == “Directory”)
//                Directory.CreateDirectory(path);
//            else
//            {
//                OnWrongPathType(path);
//                return;
//            }

//            Console.WriteLine(“Create {0} {1}”, path, type);
//        }
//    }
//}

////파일스트림으로 데이터 쓰고 읽기
//using System;
//using System.IO;

//namespace BasicIO
//{
//    class MainApp
//    {
//        static void Main(string[] args)
//        {
//            long someValue = 0x123456789ABCDEF0;
//            Console.WriteLine ("{0,-13} : 0x{1:X16}”,“Original Data”, someValue);

// Stream outStream = new FileStream(“a.dat”, FileMode.Create);
// byte[] wBytes = BitConverter.GetBytes(someValue);

// Console.Write("{0,-13} : “, “Byte array”);

//            foreach (byte b in wBytes)
//                Console.Write("{0:X2} “, b);
//            Console.WriteLine();

// outStream.Write(wBytes, 0, wBytes.Length);
// outStream.Close();

// Stream inStream = new FileStream(“a.dat”,FileMode.Open);
// byte[] rbytes = new Byte[8];

//            int i = 0;
//            while (inStream.Position < inStream.Length)
//                rbytes[i++] = (byte)inStream.ReadByte();

// long readValue = BitConverter.ToInt64(rbytes, 0);

// Console.WriteLine("{0,-13} : 0X{1:X16} “, “Read Data”, readValue);

// inStream.Close();

// }

// }
//}

////파일스트림에서 임의접근하는 예제 프로그램
//using System;
//using System.IO;

//namespace SeqNRand
//{
//    class MainApp
//    {
//        static void Main(string[] args)
//        {
//            Stream outStream = new FileStream(“a.dat”, FileMode.Create);

// Console.WriteLine(“Position : {0} “, outStream.Position);

// outStream.WriteByte(0x01);

// Console.WriteLine(“Position : {0} “, outStream.Position);

// outStream.WriteByte(0x02);

// Console.WriteLine(“Position : {0} “, outStream.Position);

// outStream.WriteByte(0x03);

// Console.WriteLine(“Position : {0} “, outStream.Position);

// outStream.Seek(5, SeekOrigin.Current);
// Console.WriteLine(“Position : {0} “, outStream.Position);

// outStream.WriteByte(0x04);
// Console.WriteLine(“Position : {0} “, outStream.Position);

//            outStream.Close();
//        }
//    }
//}

////바이너리 리더

//using System;
//using System.IO;

//namespace BinaryFile
//{
//    class MainApp
//    {
//        static void Main(string[] args)
//        {
//            BinaryWriter bw = new BinaryWriter(new FileStream(“a.dat”, FileMode.Create));

//            bw.Write(int.MaxValue);
//            bw.Write(“Good Morning”);
//            bw.Write(uint.MaxValue);
//            bw.Write(“안녕하세요”);
//            bw.Write(double.MaxValue);

// bw.Close();

// BinaryReader br = new BinaryReader(new FileStream(“a.dat”,FileMode.Open));

//            Console.WriteLine(“File size : {0} bytes” , br.BaseStream.Length);
//            Console.WriteLine("{0}”, br.ReadInt32());
//            Console.WriteLine("{0}”, br.ReadString());
//            Console.WriteLine("{0}”, br.ReadUInt32());
//            Console.WriteLine("{0}”, br.ReadString());
//            Console.WriteLine("{0}”, br.ReadDouble());

//            br.Close();
//        }
//    }
//}

////텍스트 처리를 위한 스트림 리더
//using System;
//using System.IO;

//namespace TextFile
//{
//    class MainApp
//    {
//        static void Main(string[] args)
//        {
//            StreamWriter sw = new StreamWriter(new FileStream(“a.txt”, FileMode.Create));

//            sw.WriteLine(int.MaxValue);
//            sw.WriteLine(“Good Morning”);
//            sw.WriteLine(uint.MaxValue);
//            sw.WriteLine(“안녕하세요”);
//            sw.WriteLine(double.MaxValue);

// sw.Close();

// StreamReader sr = new StreamReader(new FileStream(“a.txt”, FileMode.Open));

// Console.WriteLine(“FileSize : {0}”, sr.BaseStream.Length);

//            while (sr.EndOfStream == false)
//            {
//                Console.WriteLine(sr.ReadLine());
//            }

//            sr.Close();
//        }
//    }
//}

오늘의 C# 공부 : 애트리뷰트, 다이나믹.

Fri, 22 Mar 2013 07:31:55 +0000

//———————————————————————-
//—————–애트리뷰트———————————
//———————————————————————-

//using System;

//namespace BasicAttribute
//{
//    class MyClass
//    {
//        [Obsolete(“OldMethod 는 폐기되었습니다. NewMethod() 를 이용하세요 “)]
//        public void OldMethod()
//        {
//            Console.WriteLine(“낡은거”);
//        }

//        public void NewMethod()
//        {
//            Console.WriteLine(“새거”);
//        }
//    }

//    class MainApp
//    {
//        static void Main(string[] args)
//        {
//            MyClass obj = new MyClass();

//            obj.OldMethod();
//            obj.NewMethod();
//        }
//    }
//}

////custom attribute

//using System;

//namespace HistoryAttribute
//{
// [System.AttributeUsage(System.AttributeTargets.Class, AllowMultiple = true)]

//    class History : System.Attribute
//    {
//        private string programmer;
//        public double version;
//        public string changes;

//        public History(string programmer)
//        {
//            this.programmer = programmer;
//            version = 1.0;
//            changes = " First relese”;
//        }

//        public string GetProgrammer()
//        {
//            return programmer;
//        }
//    }

// [History ( “Sean”, version = 0.1, changes = “2010-11-01 Created class stub”)]
// [History ( “bob” , version = 0.2 , changes = " 2010-12-03 Added Func() Method”)]

//    class MyClass
//    {
//        public void Func()
//        {
//            Console.WriteLine(“Func()”);
//        }
//    }

//    class MainApp
//    {
//        static void Main (string[] args)
//        {
//            Type type = typeof(MyClass);
//            Attribute[] attribues = Attribute.GetCustomAttributes(type);
//            Console.WriteLine(“MyClass change history….”);

//            foreach (Attribute a in attribues)
//            {
//                History h = a as History;
//                if (h !=null)
//                    Console.WriteLine(“Ver:{0}, Programmer : {1}, Change: {2}",h.version,h.GetProgrammer(), h.changes);
//            }
//        }
//    }
//}

////////////////////////////////////////
//Dynamic 형식//////////////////////////
////////////////////////////////////////

using System;

namespace DuckTyping
{
    class Duck
    {
        public void Walk()
        {Console.WriteLine(this.GetType() + “.Walk”);}

public void Swim()
{ Console.WriteLine(this.GetType() + “.Swim”); }

        public void Quack()
        { Console.WriteLine(this.GetType() + “.Quack”); }
    }

class Mallard : Duck
{ }

    class Robot
    {
        public void Walk()
        { Console.WriteLine(“Robot.Walk”); }

public void Swim()
{ Console.WriteLine(“Robot.Swim”); }

        public void Quack()
        { Console.WriteLine(“Robot.Quack”); }
    }

    class MainApp
    {
        static void Main(string[] args)
        {
            dynamic[] arr = new dynamic[] {new Duck(), new Mallard(), new Robot()};

            foreach (dynamic duck in arr)
            {
                Console.WriteLine(duck.GetType());
                duck.Walk();
                duck.Swim();
                duck.Quack();

                Console.WriteLine();
            }
        }
    }
}

오늘의 C# 공부 : LinQ

Wed, 20 Mar 2013 07:37:46 +0000

////LinQ
////링크

//using System;
//using System.Linq;

//namespace From
//{
//    class MainApp
//    {
//        static void Main(string[] args)
//        {
//            int[] numbers = { 9, 2, 6, 4, 8, 3, 7, 8, 1, 10 };

//            var result = from n in numbers
//                         where n % 2 == 0
//                         orderby n
//                         select n;

//            foreach (int n in result)
//            //for(int n=0;n<result.;n++)
//                Console.WriteLine(“짝수 : {0}”, n);
//        }
//    }
//}

//using System;
//using System.Linq;

//namespace SimpleLinq
//{
//    class Profile
//    {
//        public string Name { get; set; }
//        public int Height { get; set; }
//    }

//    class MainApp
//    {
//        static void Main(string[] args)
//        {
//            Profile[] arrProfile =
//            {
//                new Profile(){Name = “정우성”, Height = 186},
//                new Profile(){Name = “김태희”, Height = 158},
//                new Profile(){Name = “고현정”, Height = 178},
//                new Profile(){Name = “이문세”, Height = 178},
//                new Profile(){Name = “하하”, Height = 171}
//            };

//            var profiles = from profile in arrProfile
//                           where profile.Height > 175
//                           orderby profile.Height
//                           select new
//                           {
//                               Name = profile.Name,
//                               InchHeight = profile.Height * 0.393
//                           };

//            foreach (var profile in profiles)
//                Console.WriteLine("{0},{1}", profile.Name, profile.InchHeight);
//        }
//    }
//}

////여러 개의 테이터 원본에 질의하기
//using System;
//using System.Linq;

//namespace FormFrom
//{
//    class Class
//    {
//        public string Name { get; set; }
//        public int[] Score { get; set; }
//    }

//    class MainApp
//    {
//        static void Main(string[] args)
//        {
//            Class[] arrClass =
//            {
//                new Class() { Name = “연두반” , Score = new int[] {99,80,70,24}},
//                new Class() { Name = “분홍반” , Score = new int[] {60,45,87,72}},
//                new Class() { Name = “파랑반” , Score = new int[] {92,30,85,94}},
//                new Class() { Name = “노랑반” , Score = new int[] {90,88,0,17}}
//            };

//            var classes = from c in arrClass
//                            from s in c.Score
//                            where s < 60
//                            orderby s
//                          select new { c.Name, Lowest = s };

//            foreach (var c in classes)
//                Console.WriteLine(“낙제 : {0} {1}",c.Name ,c.Lowest);
//        }
//    }
//}

////group by로 데이터 분류하기

//using System;
//using System.Linq;

//namespace GroupBy
//{
//    class Profile
//    {
//        public string Name { get; set; }
//        public int Height { get; set; }
//    }

//    class MainApp
//    {
//        static void Main(string[] args)
//        {
//            Profile[] arrProfile =
//            {
//                new Profile(){Name = “정우성” , Height = 186},
//                new Profile(){Name = “김태희” , Height = 158},
//                new Profile(){Name = “고현정” , Height = 172},
//                new Profile(){Name = “이문세” , Height = 178},
//                new Profile(){Name = “하하” , Height = 171}
//            };

//            var listProfile = from profile in arrProfile
//                              orderby profile.Height
//                              group profile by profile.Height < 175 into g
//                              select new { GroupKey = g.Key, profiles = g };

//            foreach (var Group in listProfile)
//            {
//                Console.WriteLine ( “-175cm 미만? : {0}",Group.GroupKey);

//                foreach (var profile in Group.profiles)
//                {
//                    Console.WriteLine(”     {0},{1}”, profile.Name, profile.Height);
//                }
//            }
//        }
//    }
//}

////join
//using System;
//using System.Linq;

//namespace Join
//{
//    class Profile
//    {
//        public string Name { get; set; }
//        public int Height { get; set; }
//    }

//    class Product
//    {
//        public string Title { get; set; }
//        public string Star { get; set; }
//    }

//    class MainApp
//    {
//        static void Main(string[] args)
//        {
//            Profile[] arrProfile =
//            {
//                new Profile() { Name = “정우성” , Height = 186},
//                new Profile() { Name = “김태희” , Height = 158},
//                new Profile() { Name = “고현정” , Height = 172},
//                new Profile() { Name = “이문세” , Height = 178},
//                new Profile() { Name = “하하” , Height = 171}
//            };

//            Product[] arrProduct =
//            {
//                new Product() { Title = “비트” , Star = “정우성”},
//                new Product() { Title = “CF 다수” , Star = “김태희”},
//                new Product() { Title = “아이리스” , Star = “김태희”},
//                new Product() { Title = “모래시계”, Star = “고현정”},
//                new Product() { Title = “솔로예찬”, Star = “이문세”}
//            };

//            var listProfile =
//                from profile in arrProfile
//                join product in arrProduct on profile.Name equals product.Star
//                select new
//                {
//                    Name = profile.Name,
//                    Work = product.Title,
//                    Height = profile.Height
//                };

//            Console.WriteLine("—–내부 조인 결과 ———-");
//            foreach (var profile in listProfile)
//            {
//                Console.WriteLine(“이름: {0} , 작품:{1} , 키: {2}”, profile.Name, profile.Work, profile.Height);
//            }

//            listProfile =
//                from profile in arrProfile
//                join product in arrProduct on profile.Name equals product.Star into ps //두 개를 조인해서 ps에 집어 넣는다.
//                from product in ps.DefaultIfEmpty(new Product() { Title = “그런거 없음” })
//                select new
//                {
//                    Name = profile.Name,
//                    Work = product.Title,
//                    Height = profile.Height
//                };

// Console.WriteLine();

//            Console.WriteLine("————-외부 조인 결과——————–");
//            foreach (var profile in listProfile)
//            {
//                Console.WriteLine(“이름:{0},작품{1},키{2}cm”, profile.Name, profile.Work, profile.Height);
//            }

// }
// }
//}

////심플Linq

//using System;
//using System.Linq;

//namespace SimpleLinq2
//{
//    class Profile
//    {
//        public string Name { get; set; }
//        public int Height { get; set; }
//    }

//    class MainApp
//    {
//        static void Main(string[] args)
//        {
//            Profile[] arrProfile =
//            {
//                new Profile() { Name = “정우성”, Height = 186},
//                new Profile() { Name = “김태희”, Height = 158},
//                new Profile() { Name = “고현정”, Height = 172},
//                new Profile() { Name = “이문세”, Height = 178},
//                new Profile() { Name = “하하” , Height = 171}
//            };

//            var profiles = arrProfile.
//                Where(profile => profile.Height < 175).
//                OrderBy(profile => profile.Height).
//                Select(profile =>
//                    new
//                    {
//                        Name = profile.Name,
//                        InchHeight = profile.Height * 0.393
//                    });

//            foreach (var profile in profiles)
//                Console.WriteLine("{0},{1}", profile.Name, profile.InchHeight);
//        }
//    }
//}

using System;
using System.Linq;

namespace MinMaxAvg
{
    class Profile
    {
        public string Name { get; set; }
        public int Height { get; set; }
    }

    class MainApp
    {
        static void Main(string[] args)
        {
            Profile[] arrProfile =
           {
               new Profile() {Name = “정우성” , Height = 186},
               new Profile() {Name = “김태희” , Height = 158},
               new Profile() { Name = “고현정” , Height = 172},
               new Profile() { Name = “이문세”, Height = 178},
               new Profile() { Name = “하하”, Height = 171}
           };

            var heightStat = from profile in arrProfile
                             group profile by profile.Height < 175 into g
                             select new
                             {
                                 Group = g.Key == true? “175미만”:“175이상”,
                                 Count = g.Count(),
                                 Max   = g.Max(profile => profile.Height),
                                 Min   = g.Min(profile => profile.Height),
                                 Average = g.Average(profile =>profile.Height)
                             };

            foreach (var stat in heightStat)
            {
                Console.Write("{0} - Count :{1}, Max: {2}, “,
                    stat.Group, stat.Count, stat.Max);
                Console.WriteLine(“Min : {0} , Average : {1}”, stat.Min, stat.Average);
            }
        }
    }
}

오늘의 C# 공부 : 이벤트 /람다식

Fri, 15 Mar 2013 07:24:36 +0000

////이벤트

//using System;

//namespace EventTest
//{
// delegate void EventHandler(string message);

//    class MyNotifier
//    {
//        public event EventHandler SomethingHappened;
//        public void DoSomething(int number)
//        {
//            int temp = number % 10;
//            if (temp != 0 && temp % 3 == 0)
//            {
//                SomethingHappened(String.Format("{0}:짝", number));
//            }
//        }
//    }

//    class MainApp
//    {
//        static public void MyHandler(string message)
//        {
//            Console.WriteLine(message);
//        }

//        static void Main(string[] args)
//        {
//            MyNotifier notifier = new MyNotifier();
//            notifier.SomethingHappened += new EventHandler(MyHandler);

//            for (int i = 1; i < 30; i++)
//            {
//                notifier.DoSomething(i);
//            }

//        }
//    }
//}

////람다식

//using System;

//namespace SimpleLamda
//{
//    class MainApp
//    {
//        delegate int Calculate(int a , int b);

//        static void Main(string[] args)
//        {
//            Calculate Calc = (a,b) =>a+b;

//            Console.WriteLine("{0}+{1}={2}" , 3,4,Calc(3,4));
//        }
//    }
//}

////문 형식의 람다식
//using System;

//namespace StatementLamda
//{
//    class MainApp
//    {
//        delegate string Concatenate(string[] args);

//        static void Main(string[] args)
//        {
//            Concatenate concat = (arr) =>
//            {
//                string result = “”;
//                foreach (string s in arr)
//                    result += s;

// return result;
// };

//            Console.WriteLine ( concat(args));
//        }
//    }
//}

////Func 델리게이트

//using System;

//namespace FuncTest
//{
//    class MainApp
//    {
//        static void Main(string[] args)
//        {
//            Func func1 = () => 10;
//            Console.WriteLine(“func1() : {0}”, func1());

// Func<int, int> func2 = (x) => x * 2;
// Console.WriteLine(“func2(4): {0}”, func2(4));

// Func<double, double, double> func3 = (x, y) => x / y;
// Console.WriteLine(“func3(22/7) : {0}”, func3(22, 7));

// }
// }
//}

////Action 델리게이트

//using System;

//namespace ActionTest
//{
//    class MainApp
//    {
//        static void Main(string[] args)
//        {
//            Action act1 = () => Console.WriteLine(“Action()”);
//            act1();

//            int result = 0;
//            Action act2 = (x) => result = x * x;
//            act2(3);
//            Console.WriteLine(“result : {0}”, result);

//            Action<double, double> act3 = (x, y) =>
//                {
//                    double pi = x/y;
//                    Console.WriteLine(“Action<T1,T2>({0},{1}) : {2}”, x, y, pi);
//                };

// act3(22.0, 7.0);

// }
// }
//}

////식 트리
//using System;
//using System.Linq.Expressions;

//namespace UsingExpressionTree
//{
//    class MainApp
//    {
//        static void Main(string[] args)
//        {
//            //1 *2+(x-y)
//            Expression const1 = Expression.Constant(1);
//            Expression const2 = Expression.Constant(2);

// Expression leftExp = Expression.Multiply(const1, const2);

// Expression param1 = Expression.Parameter(typeof(int)); //x를 위한 변수
// Expression param2 = Expression.Parameter(typeof(int));//y를 위한 변수

// Expression rightExp = Expression.Subtract(param1, param2);

// Expression exp = Expression.Add(leftExp, rightExp);

// Expression<Func<int, int, int» expression = Expression<Func<int, int, int».Lambda<Func<int, int, int»
// (exp, new ParameterExpression[] { (ParameterExpression)param1, (ParameterExpression)param2 });

// Func<int, int, int> func = expression.Compile();

// Console.WriteLine(“1*2+({0}-{1}) = {2}”, 7, 8, func(7, 8));

// }
// }
//}

////람다식을 이용한 식 트리
//using System;
//using System.Linq.Expressions;

//namespace ExpressionTreeViaLamda
//{
//    class MainApp
//    {
//        static void Main(string[] args)
//        {
//            Expression<Func<int, int, int» expression = (a, b) => 1 * 2 + (a - b);
//            Func<int, int, int> func = expression.Compile();

//            Console.WriteLine(“1*2+({0}-{1})-{2}”, 7, 8, func(7, 8));
//        }
//    }
//}

오늘의 C# 공부 : 델리게이트

Wed, 13 Mar 2013 06:43:18 +0000

///////////////////////////////////////////////////////////////////////////////////////////////////////////
//////델리게이트
////////////////////////////////////////////////////////////////////////////////////////////////////////////

//using System;

//namespace Delegate
//{
// delegate int MyDelegate ( int a, int b);

//    class Calcurator
//    {
//        public int Plus(int a, int b)
//        {
//            return (a + b);
//        }

//        public static int Minus(int a, int b)
//        {
//            return (a - b);
//        }
//    }

//    class jpcorp
//    {
//        static void Main(string[] args)
//        {
//            Calcurator Calc = new Calcurator();
//            MyDelegate Callback;

// Callback = new MyDelegate(Calc.Plus);
// Console.WriteLine(Callback(3, 4));

//            Callback = new MyDelegate(Calcurator.Minus);
//            Console.WriteLine(Callback(7, 5));
//        }
//    }
//}

//// 델리게이트를 이용한 정렬 프로그램

//using System;

//namespace UsingCallback
//{
// delegate int Compare(int a, int b);

//    class jpcorp
//    {
//        static int AscendCompare(int a, int b)
//        {
//            if (a > b)
//                return 1;
//            else if (a == b)
//                return 0;
//            else
//                return -1;
//        }

//        static int DescendCompare(int a, int b)
//        {
//            if (a < b)
//                return 1;
//            else if (a == b)
//                return 0;
//            else
//                return -1;
//        }

//        static void BubbleSort(int[] DataSet, Compare Comparer)
//        {
//            int i = 0;
//            int j = 0;
//            int temp = 0;

//            for (i = 0; i < DataSet.Length - 1; i++)
//            {
//                for (j = 0; j < DataSet.Length - (i + 1); j++)
//                {
//                    if (Comparer (DataSet[j],DataSet[j+1]) >0)
//                    {
//                        temp = DataSet[j + 1];
//                        DataSet[j + 1] = DataSet[j];
//                        DataSet[j] = temp;
//                    }
//                }
//            }
//        }

//        static void Main(string[] args)
//        {
//            int[] array = { 3, 7, 4, 2, 10 };

// Console.WriteLine(“소팅 오름차순….”);
// BubbleSort(array, new Compare(AscendCompare));

// for (int i = 0; i < array.Length; i++)
// Console.Write("{0} “, array[i]);

// int[] array2 = { 7, 2, 8, 10, 11 };

// Console.WriteLine("\n소팅 내림차순”);
// BubbleSort(array2, new Compare(DescendCompare));

// for (int i = 0; i < array2.Length; i++)
// Console.Write("{0} “, array2[i]);

// Console.WriteLine();

// }
// }
//}

////일반화 델리게이트

//using System;

//namespace GenericDelegate
//{
// delegate int Compare(T a, T b);

//    class jpcorp
//    {
//        static int AscendCompare(T a, T b) where T : IComparable
//        {
//            return a.CompareTo(b);
//        }

//        static int DescendCompare(T a, T b) where T : IComparable
//        {
//            return a.CompareTo(b) * -1;
//        }

//        static void BubbleSort(T[] DataSet, Compare Comparer)
//        {
//            int i = 0;
//            int j = 0;
//            T temp;

//            for (i = 0; i < DataSet.Length - 1; i++)
//            {
//                for (j = 0; j < DataSet.Length - (i + 1); j++)
//                {
//                    if (Comparer(DataSet[j], DataSet[j + 1]) > 0)
//                    {
//                        temp = DataSet[j + 1];
//                        DataSet[j + 1] = DataSet[j];
//                        DataSet[j] = temp;
//                    }
//                }
//            }
//        }

//        static void Main(string[] args)
//        {
//            int[] array = { 3, 7, 4, 2, 10 };
//            Console.WriteLine(“오름차순 정리…”);
//            BubbleSort(array, new Compare(AscendCompare));

// for (int i = 0; i < array.Length; i++)
// Console.Write("{0} “, array[i]);

// string[] array2 = { “abd”, “def”, “ghi”, “jkl”, “mno” };

// Console.WriteLine("\n내림차순….”);

// BubbleSort(array2, new Compare(DescendCompare));

// for ( int i =0; i<array2.Length; i++)
// Console.Write("{0} “,array2[i]);

// Console.WriteLine();

// }
// }
//}

////델리게이트 체인
//using System;

//namespace DelegateChains
//{
// delegate void Notify ( string meassage);

//    class Notifier
//    {
//        public Notify EventOccured;
//    }

//    class EventListener
//    {
//        private string name;
//        public EventListener(string name)
//        {
//            this.name = name;
//        }

//        public void SomethingHappend(string message)
//        {
//            Console.WriteLine("{0}.SomethingHappened : {1}”, name, message);
//        }
//    }

//    class jpcorp
//    {
//        static void Main(string[] args)
//        {
//            Notifier notifier = new Notifier();
//            EventListener listener1 = new EventListener(“Listener1”);
//            EventListener listener2 = new EventListener(“Listener2”);
//            EventListener listener3 = new EventListener(“Listener3”);

//            notifier.EventOccured += listener1.SomethingHappend;
//            notifier.EventOccured += listener2.SomethingHappend;
//            notifier.EventOccured += listener3.SomethingHappend;

// notifier.EventOccured(“You’ve got mail”);
// Console.WriteLine();

// notifier.EventOccured -= listener2.SomethingHappend;
// notifier.EventOccured(“Download complete.”);

// Console.WriteLine();

// notifier.EventOccured = new Notify(listener2.SomethingHappend) + new Notify(listener3.SomethingHappend);
// notifier.EventOccured(“Nuclear launch derected”);

// Console.WriteLine();

// Notify notify1 = new Notify(listener1.SomethingHappend);
// Notify notify2 = new Notify(listener2.SomethingHappend);

// notifier.EventOccured = (Notify)Delegate.Combine(notify1, notify2);
// notifier.EventOccured(“Fire!”);

// Console.WriteLine();

// notifier.EventOccured = (Notify)Delegate.Remove(notifier.EventOccured, notify2);
// notifier.EventOccured(“RPG”);

// }
// }
//}

////익명 메소드
//using System;
//namespace AnonymousMethod
//{
// delegate int Compare ( int a, int b);

//    class jpcorp
//    {
//        static void BubbleSort(int[] DataSet, Compare Comparer)
//        {
//            int i = 0;
//            int j = 0;
//            int temp = 0;

//            for ( i =0; i < DataSet.Length-1 ; i ++)
//            {
//                for (j = 0; j<DataSet.Length - (i+1);j++)
//                {
//                    if (Comparer(DataSet[j] , DataSet[j+1] ) >0)
//                    {
//                        temp = DataSet[j+1];
//                        DataSet[j+1] = DataSet[j];
//                        DataSet[j] = temp;
//                    }
//                }
//            }
//        }

//        static void Main(string[] args)
//        {
//            int[] array = { 3, 7, 4, 2, 10 };
//            Console.WriteLine(“오름차순 소팅…”);
//            BubbleSort(array, delegate(int a, int b)
//                {
//                    if (a > b)
//                        return 1;
//                    else if (a == b)
//                        return 0;
//                    else
//                        return -1;
//                 });

// for ( int i = 0 ; i <array.Length ; i++)
// Console.Write("{0} “,array[1]);

//            int[] array2 = {7,2,8,10,11};
//            Console.WriteLine ("\n 내림차순 소팅…..”);
//            BubbleSort(array2, delegate( int a, int b)
//                {
//                    if (a > b)
//                        return 1;
//                    else if (a == b)
//                        return 0;
//                    else
//                        return -1;

// });

// for ( int i= 0; i <array2.Length; i++)
// Console.Write("{0} “,array2[i]);

//            Console.WriteLine();
//        }
//    }
//}

오늘의 C# 공부 : 예외처리 (try ~ catch, finally)

Fri, 08 Mar 2013 07:35:50 +0000

////예외처리 실습
//using System;

//namespace TryCatch
//{
//    class jpcorp
//    {
//        static void Main(string[] args)
//        {
//            int[] arr = { 1, 2, 3 };

//            try
//            {
//                for (int i = 0; i < 5; i++)
//                {
//                    Console.WriteLine(arr[i]);
//                }
//            }

//            catch (IndexOutOfRangeException e)
//            {
//                Console.WriteLine(“예외가 발생했지롱 : {0}”, e.Message);
//            }

//            Console.WriteLine(“종료”);
//        }
//    }
//}

////예외 던지기
//using System;

//namespace Throw
//{
//    class jpcorp
//    {
//        static void DoSomething(int arg)
//        {
//            if (arg < 10)
//                Console.WriteLine(“arg : {0}”, arg);
//            else
//                throw new Exception(“arg가 10보다 큽니다”);
//        }

//        static void Main(string[] args)
//        {
//            try
//            {
//                DoSomething(1);
//                DoSomething(2);
//                DoSomething(3);
//                DoSomething(4);
//                DoSomething(5);
//                DoSomething(11);
//                DoSomething(31);//예외가 발생해서 실행되지 않음.

// }

//            catch (Exception e)
//            {
//                Console.WriteLine(e.Message);
//            }
//        }
//    }
//}

////try ~ catch와 finally

//using System;

//namespace Finally
//{
//    class jpcorp
//    {
//        static int Divide(int divisor, int divided)
//        {
//            try
//            {
//                Console.WriteLine(“Divide() 시작”);
//                return divisor / divided;
//            }

//            catch (DivideByZeroException e)
//            {
//                Console.WriteLine(“Divide() 예외발생 : 0으로 나눴네 “);
//                //throw e; //throw를 이용하는 경우가 뭔가? : 메소드 밖으로 에러 메세지 객체인 e 를 빼기 위해서다.
//                 //즉 0으로 나눴다는 객체를 뺀다.

//                //Console.WriteLine(“Divide() 예외발생 : 0으로 나눴네 : {0}”, e.Message);
//                return 0;
//            }

//            finally
//            {
//                Console.WriteLine(“Divide() 끝”);
//            }
//        }

//        static void Main(string[] args)
//        {
//            //try
//            //{
//            Console.Write(“제수를 입력하세요 “);
//            String temp = Console.ReadLine();
//            int divisor = Convert.ToInt32(temp);

//            Console.Write(“피제수를 입력하세요”);
//            temp = Console.ReadLine();
//            int divided = Convert.ToInt32(temp);

// Console.WriteLine(” {0}/{1} = {2}”, divisor, divided, Divide(divisor, divided));
// //}

//            //catch (FormatException e)
//            //{
//            //    Console.WriteLine(“에러 : “, e.Message);
//            //}

//            //catch (DivideByZeroException e)
//            //{
//            //    Console.WriteLine(“에러 : “, e.Message);
//            //}

//            //finally
//            //{
//            //    Console.WriteLine(“프로그램을 종료합니다”);
//            //}
//        }
//    }
//}

////사용자 정의 예외 클래스 만들기

//using System;
//namespace MyException
//{
//    class InvalidArguementException : Exception //이 부분을 어떻게 쓰는지 체크하자.
//    {
//        public InvalidArguementException()
//        {
//        }

//        public InvalidArguementException(string message)
//            : base(message)
//        {
//        }

//        public object Argument
//        {
//            get;
//            set;
//        }
//        public string Range
//        {
//            get;
//            set;
//        }
//    }

//    class MainApp
//    {
//        static uint MergeARGB(uint alpha, uint red, uint green, uint blue)
//        {
//            uint[] args = new uint[] { alpha, red, green, blue };

//            foreach (uint arg in args)
//            {
//                if (arg > 255)
//                    throw new InvalidArguementException()
//                    {
//                        Argument = arg,
//                        Range = “0~255”//왜 쉼표를 쓰는가?
//                    };
//            }

//            return (alpha « 24 & 0xFF000000) |
//                     (red « 16 & 0x00FF0000) |
//                    (green « 8 & 0x0000FF00) |
//                    (blue & 0x000000FF); //이부분 다시 체크하자.
//        }

//        static void Main(string[] args)
//        {
//            try
//            {
//                Console.WriteLine(“0x{0:X}”, MergeARGB(255, 111, 111, 111));
//                Console.WriteLine(“0x{0:X}”, MergeARGB(1, 65, 192, 128));
//                Console.WriteLine(“0x{0:X}”, MergeARGB(0, 255, 255, 300));
//            }

//            catch (InvalidArguementException e)
//            {
//                Console.WriteLine(e.Message);
//                Console.WriteLine(“Argument : {0}, Range:{1}”, e.Argument, e.Range);
//            }
//        }
//    }
//}

//예외 처리 다시 생각해 보기

//using System;
//namespace MainApp
//{
//    class jpcorp
//    {
//        static void Main(string[] args)
//        {
//            try
//            {
//                int a = 1;
//                Console.WriteLine(3 / –a); //여기서 예외 처리가 발생한다
//            }

//            catch (DivideByZeroException e)
//            {
//                Console.WriteLine(e.StackTrace);//stacktrace를 하면 어디서 문제가 발생했는지 찾아준다.
//            }
//        }
//    }
//}

오늘의 C# 공부 : stack, 일반화, 예외처리들

Wed, 06 Mar 2013 07:37:59 +0000

////Stack

//using System;
//using System.Collections.Generic;

//namespace UsingGenericstack
//{
//    class MainApp
//    {
//        static void Main(string[] args)
//        {
//            Stack stack = new Stack();

//            stack.Push(1);
//            stack.Push(2);
//            stack.Push(3);
//            stack.Push(4);
//            stack.Push(5);

//            while (stack.Count > 0)
//                Console.WriteLine(stack.Pop());
//        }
//    }
//}

////Dictionary <Tkey, TValue>

//using System;
//using System.Collections.Generic;

//namespace UsingDictionary
//{
//    class MainApp
//    {
//        static void Main(string[] args)
//        {
//            Dictionary<string, string> dic = new Dictionary<string, string>();
//            dic[“하나”] = “one”;
//            dic[“두울”] = “two”;
//            dic[“세엣”] = “three”;
//            dic[“네엣”] = “four”;
//            dic[“다섯”] = “five”;

//            Console.WriteLine(dic[“하나”]);
//            Console.WriteLine(dic[“두울”]);
//            Console.WriteLine(dic[“세엣”]);
//            Console.WriteLine(dic[“네엣”]);
//            Console.WriteLine(dic[“다섯”]);
//        }
//    }
//}

////foreach를 사용할 수 있는 일반화 클래스
//using System;
//using System.Collections;
//using System.Collections.Generic;

//namespace EnumerableGeneric
//{
//    class MyList : IEnumerable, IEnumerator
//    {
//        private T[] array;
//        int position = -1;

//        public MyList()
//        {
//            array = new T[3];
//        }

//        public T this[int index]
//        {
//            get
//            {
//                return array[index];
//            }

//            set
//            {
//                if (index >= array.Length)
//                {
//                    Array.Resize(ref array,index + 1);
//                    Console.WriteLine(“Array Resized :{0}",array.Length);
//                }

//                array[index] = value;
//            }
//        }

//        public int Length
//        {
//            get { return array.Length; }
//        }

//        public IEnumerator GetEnumerator()
//        {
//            for (int i = 0; i < array.Length; i++)
//            {
//                yield return (array[i]);
//            }
//        }

//        IEnumerator IEnumerable.GetEnumerator()
//        {
//            for (int i = 0; i < array.Length; i++)
//            {
//                yield return (array[i]);
//            }
//        }

//        public T current
//        {
//            get { return array[position]; }
//        }

//        object IEnumerator.Current
//        {
//            get { return array[position]; }
//        }

//        public bool MoveNext()
//        {
//            if (position == array.Length - 1)
//            {
//                Reset();
//                return false;
//            }

//            position++;
//            return (position < array.Length);
//        }

//        public void Reset()
//        {
//            position = -1;
//        }

//        public void Dispose()
//        {
//        }
//    }

//    class jpcorp
//    {
//        static void Main(string[] args)
//        {
//            MyList str_list = new MyList();
//            str_list[0] = “abc”;
//            str_list[1] = “def”;
//            str_list[2] = “ghi”;
//            str_list[3] = “jkl”;
//            str_list[4] = “mno”;

// foreach (string str in str_list)
// Console.WriteLine(str);

// }
// }
//}

////예외처리

//using System;
//namespace KillingProgram
//{
//    class jpcorp
//    {
//        static void Main(string[] args)
//        {
//            int[] arr = { 1, 2, 3 };

//            for (int i = 0; i < 5; i++)
//            {
//                Console.WriteLine(arr[i]);
//            }

//            Console.WriteLine(“종료”);
//        }
//    }
//}

////예외처리 실습
//using System;

//namespace TryCatch
//{
//    class jpcorp
//    {
//        static void Main(string[] args)
//        {
//            int[] arr = { 1, 2, 3 };

//            try
//            {
//                for (int i = 0; i < 5; i++)
//                {
//                    Console.WriteLine(arr[i]);
//                }
//            }

//            catch (IndexOutOfRangeException e)
//            {
//                Console.WriteLine(“예외가 발생했지롱 : {0}”, e.Message);
//            }

//            Console.WriteLine(“종료”);
//        }
//    }
//}

////예외 던지기
//using System;

// }

//            catch (Exception e)
//            {
//                Console.WriteLine(e.Message);
//            }
//        }
//    }
//}

////try ~ catch와 finally

//using System;

//            catch (DivideByZeroException e)
//            {
//                Console.WriteLine(“Divide() 예외발생 : 0으로 나눴네 “);
//                throw e;
//            }

//            finally
//            {
//                Console.WriteLine(“Divide() 끝”);
//            }
//        }

//        static void Main(string[] args)
//        {
//            try
//            {
//                Console.Write(“제수를 입력하세요 “);
//                String temp = Console.ReadLine();
//                int divisor = Convert.ToInt32(temp);

//                Console.Write(“피제수를 입력하세요”);
//                temp = Console.ReadLine();
//                int divided = Convert.ToInt32(temp);

// Console.WriteLine(” {0}/{1} = {2}”, divisor, divided, Divide(divisor, divided));
// }

//            catch (FormatException e)
//            {
//                Console.WriteLine(“에러 : “, e.Message);
//            }

//            catch (DivideByZeroException e)
//            {
//                Console.WriteLine(“에러 : “, e.Message);
//            }

//            finally
//            {
//                Console.WriteLine(“프로그램을 종료합니다”);
//            }
//        }
//    }
//}

using System;
namespace MyException

{
    class InvalidArguementException : Exception
    {
        public InvalidArguementException()
        {
        }

        public InvalidArguementException(string message) : base(message)
        {
        }

        public object Argument
        {
            get;
            set;
        }
        public string Range
        {
            get;
            set;
        }
    }

    class MainApp
    {
        static uint MergeARGB ( uint alpha, uint red, uint green, uint blue)
        {
            uint[] args = new uint[] {alpha,red,green, blue};

            foreach ( uint arg in args)
            {
                if (arg >255)
                    throw new InvalidArguementException()
                    {
                        Argument = arg, Range = “0~255”
                    };
            }

            return (alpha « 24 & 0xFF000000) |
                     (red « 16 & 0x00FF0000) |
                    (green « 8 & 0x0000FF00) |
                    (blue &0x000000FF);
        }

        static void Main(string[] args)
        {
            try
            {
                Console.WriteLine(“0x{0:X}”, MergeARGB(255, 111, 111, 111));
                Console.WriteLine(“0x{0:X}”, MergeARGB(1, 65, 192, 128));
                Console.WriteLine(“0x{0:X}”, MergeARGB(0, 255, 255, 300));
            }

            catch (InvalidArguementException e)
            {
                Console.WriteLine(e.Message);
                Console.WriteLine(“Argument : {0}, Range:{1}”, e.Argument,e.Range);
            }
        }
    }
}

오늘의 C# 공부 : Indexer, Generic

Wed, 27 Feb 2013 07:32:28 +0000

////인덱서

//using System;
//using System.Collections;

//namespace Indexer
//{
//    class MyList
//    {
//        private int[] array;

//        public MyList()
//        {
//            array = new int[3];
//        }

//        public int this[int index]
//        {
//            get
//            {
//                return array[index];
//            }

//            set
//            {
//                if (index >= array.Length)
//                {
//                    Array.Resize(ref array, index + 1);
//                    Console.WriteLine (“Array Resized : {0}",array.Length);
//                }

//                array[index] = value;
//            }
//        }

//        public int Length
//        {
//            get
//            {
//                return array.Length;
//            }
//        }
//    }

//    class jpcorp
//    {
//        static void Main(string[] args)
//        {
//            MyList list = new MyList();

//            for (int i = 0; i < 5; i++)
//            {
//                list[i] = i;
//            }

//            for (int i = 0; i < list.Length; i++)
//            {
//                Console.WriteLine(list[i]);
//            }
//        }
//    }
//}

////foreach가 가능한 객체를 만들어 보자

//using System;
//using System.Collections;

//namespace Enumerable
//{
//    class MyList : IEnumerable, IEnumerator
//    {
//        private int[] array;
//        int position = -1;

//        public MyList()
//        {
//            array = new int[3];
//        }

//        public int this[int index]
//        {
//            get
//            {
//                return array[index];
//            }

//            set
//            {
//                if (index >= array.Length)
//                {
//                    Array.Resize(ref array, index + 1);
//                    Console.WriteLine(“Array Resized : {0}”, array.Length);
//                }

//                array[index] = value;
//            }
//        }

//        public object Current
//        {
//            get
//            {
//                return array[position];
//            }
//        }

//        public bool MoveNext()
//        {
//            if (position == array.Length -1)
//            {
//                Reset();
//                return false;
//            }

//            position++;
//            return (position < array.Length);
//        }

//        public void Reset()
//        {
//            position = -1;
//        }

//        public IEnumerator GetEnumerator()
//        {
//            for (int i = 0; i < array.Length; i++)
//            {
//                yield return (array[i]);
//            }
//        }

//        class jpcorp
//        {
//            static void Main(string[] args)
//            {
//                MyList list = new MyList();

// for (int i = 0 ; i<5 ; i++)
// list[i] = i;

// foreach ( int e in list)
// Console.WriteLine(e);

// }
// }

// }
//}

////일반화 프로그래밍

//using System;
//namespace CopyingArray
//{
//    class jpcorp
//    {
//        static void CopyArray(T[] source, T[] target)
//        {
//            for (int i = 0; i < source.Length; i++)
//            {
//                target[i] = source[i];
//            }
//        }

//        static void Main(string[] args)
//        {
//            int[] source = { 1, 2, 3, 4, 5 };
//            int[] target = new int[source.Length];

// CopyArray(source, target);

// foreach (int element in target)
// Console.WriteLine(element);

// string[] source2 = { “하나”, “둘”, “셋”, “넷”, “다섯” };
// string[] target2 = new string[source2.Length];

// CopyArray(source2, target2);

//            foreach (string element in target2)
//                Console.WriteLine(element);
//        }

// }
//}

////일반화 클래스
//using System;

//namespace Generic
//{
//    class MyList
//    {
//        private T[] array;

//        public MyList()
//        {
//            array = new T[3];
//        }

//        public T this[int index]
//        {
//            get
//            {
//                return array[index];
//            }

//                array[index] = value;
//            }
//        }

//        public int Length
//        {
//            get { return array.Length; }
//        }
//    }

//    class jpcorp
//    {
//        static void Main(string[] args)
//        {
//            MyList str_list = new MyList();

//            str_list[0] = “abc”;
//            str_list[1] = “def”;
//            str_list[2] = “ghi”;
//            str_list[3] = “jkl”;
//            str_list[4] = “mno”;

// for (int i = 0; i < str_list.Length; i++)
// Console.WriteLine(str_list[i]);

// Console.WriteLine();

// MyList int_list = new MyList();

//            int_list[0] = 0;
//            int_list[1] = 1;
//            int_list[2] = 2;
//            int_list[3] = 3;
//            int_list[4] = 4;
//            int_list[5] = 5;

//            for (int i = 0; i < int_list.Length; i++)
//                Console.WriteLine(int_list[i]);
//        }

// }
//}

//// 형식 매개 변수 예약하기

//using System;
//namespace ConstraintsOnTypeParameters
//{
//    class StructArray where T : struct
//    {
//        public T[] Array{get;set;}
//        public StructArray(int size)
//        {
//            Array = new T[size];
//        }
//    }

//    class RefArray where T : class
//    {
//        public T[] Array { get; set; }
//        public RefArray(int size)
//        {
//            Array = new T[size];
//        }
//    }

//    class Base { }
//    class Derived : Base { }
//    class BaseArray where U : Base
//    {
//        public U[] Array { get; set; }
//        public BaseArray(int size)
//        {
//            Array = new U[size];
//        }

//        public void CopyArray ( T[] Source) where T : U
//        {
//            Source.CopyTo(Array, 0);
//        }

//    }

//    class MainApp
//    {
//        public static T CreateInstance() where T : new()
//        {
//            return new T();
//        }

//        static void Main(string[] args)
//        {
//            StructArray a = new StructArray(3);
//            a.Array[0] = 0;
//            a.Array[1] = 1;
//            a.Array[2] = 2;

//            RefArray<StructArray> b = new RefArray<StructArray>(3);
//            b.Array[0] = new StructArray(5);
//            b.Array[1] = new StructArray(10);
//            b.Array[2] = new StructArray(1005);

//            BaseArray c = new BaseArray(3);
//            c.Array[0] = new Base();
//            c.Array[1] = new Derived();
//            c.Array[2] = CreateInstance();

//            BaseArray d = new BaseArray(3);
//            d.Array[0] = new Derived();
//            d.Array[1] = CreateInstance();
//            d.Array[2] = CreateInstance();

//            BaseArray e = new BaseArray(3);
//            e.CopyArray(d.Array);
//        }
//    }
//}

////일반화 컬렉션
////List

//using System;
//using System.Collections.Generic;

//namespace UsingGenericList
//{
//    class MainApp
//    {
//        static void Main(string[] args)
//        {
//            List list = new List();
//            for (int i = 0; i < 5; i++)
//                list.Add(i);

//            foreach (int element in list)
//                Console.Write("{0} “, element);
//            Console.WriteLine();

// list.RemoveAt(2);

//            foreach (int element in list)
//                Console.Write("{0} “, element);
//            Console.WriteLine();

// list.Insert(2, 2);

//            foreach (int element in list)
//                Console.Write("{0} “, element);
//            Console.WriteLine();
//        }
//    }
//}

////Queue

//using System;
//using System.Collections.Generic;

//namespace UsingGenericQueue
//{
//    class MainApp
//    {
//        static void Main(string[] args)
//        {
//            Queue queue = new Queue();

//            queue.Enqueue(1);
//            queue.Enqueue(2);
//            queue.Enqueue(3);
//            queue.Enqueue(4);
//            queue.Enqueue(5);

//            while (queue.Count > 0)
//                Console.WriteLine("{0}”, queue.Dequeue());
//        }
//    }
//}

c# 오늘의 공부 : 배열, 어레이.

Fri, 22 Feb 2013 07:25:05 +0000

////2차원 배열

//using System;

//namespace _2DArray
//{
//    class MainApp
//    {
//        static void Main(string[] args)
//        {
//            int[,] arr = new int[2, 3] { { 1, 2, 3 }, { 4, 5, 6 } };

//            for (int i = 0; i < arr.GetLength(0); i++)
//            {
//                for (int j = 0; j < arr.GetLength(1); j++)
//                {
//                    Console.Write("[{0},{1}] : {2}", i, j, arr[i, j]);
//                                    }
//                Console.WriteLine();
//            }
//            Console.WriteLine();

// int[,] arr2 = new int[,] { { 1, 2, 3 }, { 4, 5, 6 } };

//            for (int i = 0; i < arr2.GetLength(0); i++)
//            {
//                for (int j = 0; j < arr2.GetLength(1); j++)
//                {
//                    Console.Write("[{0},{1}] : {2}" , i,j,arr2[i,j]);
//                }
//                Console.WriteLine();
//            }
//            Console.WriteLine();

//            int[,] arr3 = new int[,] { { 1, 2, 3 }, { 4, 5, 6 } };
//            for (int i = 0; i < arr3.GetLength(0); i++)
//            {
//                for (int j = 0; j < arr3.GetLength(1); j++)
//                {
//                    Console.Write("[{0},{1}] : {2}", i, j, arr3[i, j]);
//                }
//                Console.WriteLine();
//            }
//            Console.WriteLine();
//        }
//    }
//}

////다차원 배열

//using System;

//namespace _3DArray
//{
//    class jpcorp
//    {
//        static void Main(string[] args)
//        {
//            int[,,] array = new int[4,3,2]
//            {
//                {{1,2},{3,4},{5,6}},
//                {{1,4},{2,5},{3,6}},
//                {{6,5},{4,3},{2,1}},
//                {{6,3},{5,2},{4,1}},
//            };

//            for (int i = 0; i < array.GetLength(0); i++)
//            {
//                for (int j = 0; j < array.GetLength(1); j++)
//                {
//                    Console.Write("{");
//                    for (int k = 0; k < array.GetLength(2); k++)
//                    {
//                        Console.Write("{0}", array[i, j, k]);
//                    }
//                    Console.Write("} “);

//                }
//                Console.WriteLine();
//            }

// }
// }
//}

//// 가변 배열
//using System;

//namespace JaggedArray
//{
//    class jpcorp
//    {
//        static void Main(string[] args)
//        {
//            int[][] jagged = new int[3][];
//            jagged[0] = new int[5] { 1, 2, 3, 4, 5 };
//            jagged[1] = new int[] { 10, 20, 30 };
//            jagged[2] = new int[] { 100, 200 };

//            foreach (int[] arr in jagged)
//            {
//                Console.Write(“Length:{0}, “, arr.Length);
//                foreach (int e in arr)
//                {
//                    Console.Write("{0} “, e);
//                }
//                Console.WriteLine(””);
//            }
//            Console.WriteLine(””);

//            int[][] jagged2 = new int[2][]
//            {
//                new int []{1000,2000,},
//                new int [4]{6,7,8,9},
//            };

//            foreach (int[] arr in jagged2)
//            {
//                Console.Write(“Length:{0}, “,arr.Length);
//                foreach( int e in arr)
//                {
//                    Console.Write("{0} “,e);
//                }
//                Console.WriteLine();
//            }
//        }
//    }
//}

////컬렉션
////Arraylist

//using System;
//using System.Collections;

//namespace UsingList
//{
//    class jpcorp
//    {
//        static void Main(string[] args)
//        {
//            ArrayList list = new ArrayList();
//            for (int i = 0; i < 5; i++)
//                list.Add(i);

//            foreach (object obj in list)
//                Console.Write("{0} “, obj);
//            Console.WriteLine();

// list.Remove(2);

//            foreach (object obj in list)
//                Console.Write("{0} “, obj);
//            Console.WriteLine();

// list.Insert(2, 2);

//            foreach (object obj in list)
//                Console.Write("{0} “, obj);
//            Console.WriteLine();

// list.Add(“abc”);
// list.Add(“def”);

//            for (int i = 0; i < list.Count; i++)
//                Console.Write("{0} “, list[i] );
//            Console.WriteLine();

// }
// }
//}

////Queue
//using System;
//using System.Collections;

//namespace UsingQueue
//{
//    class jpcorp
//    {
//        static void Main(string[] args)
//        {
//            Queue que = new Queue();
//            que.Enqueue(1);
//            que.Enqueue(2);
//            que.Enqueue(3);
//            que.Enqueue(4);
//            que.Enqueue(5);

//            while (que.Count > 0)
//                Console.WriteLine(que.Dequeue());
//        }
//    }
//}

////stack 컬렉션

//using System;
//using System.Collections;

//namespace UsingStack
//{
//    class jpcorp
//    {
//        static void Main(string[] args)
//        {
//            Stack stack = new Stack();
//            stack.Push(1);
//            stack.Push(2);
//            stack.Push(3);
//            stack.Push(4);
//            stack.Push(5);

//            while (stack.Count > 0)
//                Console.WriteLine(stack.Pop());
//        }
//    }
//}

////hashtable
//using System;
//using System.Collections;

//namespace UsingHashtable
//{
//    class jpcorp
//    {
//        static void Main(string[] args)
//        {
//            Hashtable ht = new Hashtable();
//            ht[“하나”] = “one”;
//            ht[“둘”] = “two”;
//            ht[“셋”] = “three”;
//            ht[“넷”] = “four”;
//            ht[“다섯”] = “five”;

//            Console.WriteLine(ht[“하나”]);
//            Console.WriteLine(ht[“둘”]);
//            Console.WriteLine(ht[“셋”]);
//            Console.WriteLine(ht[“넷”]);
//            Console.WriteLine(ht[“다섯”]);
//        }
//    }
//}

오늘의 C# 공부 :

Wed, 20 Feb 2013 07:03:47 +0000

////무명 형식
//using System;

//namespace AnonymousType
//{
//    class jpcorp
//    {
//        static void Main(string[] args)
//        {
//            var a = new { Name = “박상현”, Age = 123 };
//            Console.WriteLine(“Name : {0}, Age : {1}”, a.Name, a.Age);

//            var b = new { Subject = “수학”, Scores = new int[] { 90, 80, 70, 60 } };
//            Console.Write(" Subject : {0} , Scores : “, b.Subject);
//            foreach (var scores in b.Scores)
//                Console.Write("{0} “, scores);

//            Console.WriteLine();
//        }
//    }
//}

////인터페이스의 프로퍼티
//using System;

//namespace PropertiesInInterface
//{
//    interface INameValue
//    {
//        string Name
//        {
//            get;
//            set;
//        }

//        string Value
//        {
//            get;
//            set;
//        }
//    }

//    class NameValue : INameValue
//    {
//        public string Name
//        {
//            get;
//            set;
//        }

//        public string Value
//        {
//            get;
//            set;
//        }
//    }

//    class jpcorp
//    {
//        static void Main(string[] args)
//        {
//            NameValue name = new NameValue()
//            { Name = “이름”, Value = “박상현” };

// NameValue height = new NameValue()
// { Name = “키”, Value = “177”};

// NameValue weight = new NameValue()
// { Name = “몸무게”, Value = “90kg”};

//           Console.WriteLine("{0} : {1}” , name.Name , name.Value);
//            Console.WriteLine("{0} : {1}” , height.Name, height.Value);
//            Console.WriteLine("{0} : {1}" , weight.Name , weight.Value);

// }
// }
//}

////추상 클래스와 프로퍼티

//using System;
//namespace PropertiesInAbstractClass
//{
//    abstract class Product
//    {
//        private static int serial = 0;
//        public string SerialID
//        {
//            get { return String.Format("{0:d5}", serial++); }
//        }

//        abstract public DateTime ProductDate
//        {
//            get;
//            set;
//        }
//    }

//    class MyProduct : Product
//    {
//        public override DateTime ProductDate
//        {
//            get;
//            set;
//        }
//    }

//    class jpcorp
//    {
//        static void Main(string[] args)
//        {
//            Product product_1 = new MyProduct() { ProductDate = new DateTime(2010, 1, 10) };

//            Console.WriteLine(“Product : {0} , Product Date : {1}”,
//                product_1.SerialID,
//                product_1.ProductDate);

// Product product_2 = new MyProduct() { ProductDate = new DateTime(2010, 2, 3) };

//            Console.WriteLine(“Product : {0} , product Date : {1}”,
//                product_2.SerialID,
//            product_2.ProductDate);

// }
// }
//}

////배열과 컬렉션, 그리고 인덱서
//using System;

//namespace ArarrySample
//{
//    class jpcorp
//    {
//        static void Main(string[] args)
//        {
//            int[] scores = new int[5];

//            scores[0] = 80;
//            scores[1] = 74;
//            scores[2] = 81;
//            scores[3] = 64;
//            scores[4] = 55;

//            foreach (int score in scores)
//            {
//                Console.WriteLine(score);
//            }

//            int sum = 0;
//            foreach (int score in scores)
//                sum += score;

// int average = sum / scores.Length;

//            Console.WriteLine(“Average Score ; {0} “, average);
//        }
//    }
//}

////배열을 초기화하는 세 가지
//using System;

//namespace InitializingArray
//{
//    class jpcorp
//    {
//        static void Main(string[] args)
//        {
//            string[] array1 = new string[3] { “안녕”, “Hello”, “Halo” };

//            Console.WriteLine(“array1…”);
//            foreach ( string greeting in array1)
//                Console.WriteLine("{0}",greeting);


//            string[] array2 = new string[] { “안녕”, “Hello”, “Halo” };

//            Console.WriteLine(“array2….”);
//            foreach (string greeting in array2)
//                Console.WriteLine("{0}”, greeting);

// string[] array3 = { “안녕”, “Hello”, “Halo” };

//            Console.WriteLine(“array3…”);
//            foreach ( string greeting in array3)
//                Console.WriteLine ("{0}”, greeting);
//        }
//    }
//}

////system.array

//using System;

//namespace DerivedFromArray
//{
//    class jpcorp
//    {
//        static void Main(string[] args)
//        {
//            int[] array = new int[] { 10, 30, 20, 7, 1 };
//            Console.WriteLine(“Type Of Array : {0}”, array.GetType());

//            Console.WriteLine(“Base type Of Array : {0} “, array.GetType().BaseType);
//        }
//    }
//}

//정적 메소드와 인스턴스 메소드
using System;

namespace MoreInArray
{
    class jpcorp
    {
        private bool CheckPassed(int score)// 인스턴스 메소드
        {
            if (score >= 60)
                return true;
            else
                return false;
        }

        private static void Print(int value) // 정적 메소드
        {
            Console.Write("{0} “, value);
        }

        static void Main(string[] args)
        {
            jpcorp jp = new jpcorp();// 인스턴스 메소드 사용하는 방법
            int[] scores = new int[] { 80, 74, 81, 90, 34 };

            foreach (int score in scores)
                Console.Write("{0} “, score);
            Console.WriteLine();

            Array.Sort(scores);
            Array.ForEach(scores, new Action(Print));
            Console.WriteLine();

Console.WriteLine(“Number of dimensions : {0}”, scores.Rank);

Console.WriteLine(“Binary Search : 81 is at {0} " , Array.BinarySearch (scores, 81));

Console.WriteLine(“Linear Search : 90 is at {0} “, Array.IndexOf(scores, 90));

Console.WriteLine(“Everyone passed? : {0}”, Array.TrueForAll(scores, jp.CheckPassed));

            int index = Array.FindIndex(scores, delegate(int score)
            {
                if (score < 60)
                    return true;
                else
                    return false;
            });

scores[index] = 61;

Console.WriteLine(“Everyone passed? : {0}”,
Array.TrueForAll(scores, jp.CheckPassed));

Console.WriteLine(“Old length of scores : {0} “, scores.GetLength(0));

Array.Resize(ref scores, 10);

Console.WriteLine(“New length of scores : {0} “, scores.Length);

Array.ForEach(scores, new Action(Print));
Console.WriteLine();

Array.Clear(scores, 3, 7);

Array.ForEach(scores, new Action(Print));
Console.WriteLine();

}
}
}

오늘의 C# 공부 : 구조체, 인터페이스, 추상 클래스, 프로퍼티

Fri, 15 Feb 2013 07:54:29 +0000

//// 구조체 실습

//using System;
//using System.Collections.Generic;
//using System.Linq;
//using System.Text;

//namespace Structure
//{
//    struct Point3D
//    {
//        public int X;
//        public int Y;
//        public int Z;

//        public Point3D(int X, int Y, int Z)
//        {
//            this.X = X;
//            this.Y = Y;
//            this.Z = Z;
//        }

//        public override string ToString()
//        {
//            return string.Format("{0},{1},{2}", X, Y, Z);
//        }
//    }

//    class jpcorp
//    {
//        static void Main(string[] args)
//        {
//            Point3D p3d1;
//            p3d1.X = 10;
//            p3d1.Y = 20;
//            p3d1.Z = 30;

// Console.WriteLine(p3d1.ToString());

//            Point3D p3d2 = new Point3D(100, 200, 300);
//            Point3D p3d3 = p3d2;
//            p3d3.Z = 400;

//            Console.WriteLine(p3d2.ToString());
//            Console.WriteLine(p3d3.ToString());
//        }
//    }
//}

////인터페이스
//// 변하지 못하는 선언만하는 부모클래스 같은 것이다. 상속 전용으로 사용할 수 있다.

//using System;
//using System.IO;

//namespace ILogger
//{
//    interface ILogger
//    {
//        void WriteLog(string message);
//    }

//    class ConsoleLogger : ILogger
//    {
//         public void WriteLog(string message)
//        {
//            Console.WriteLine("{0},{1}", DateTime.Now.ToLocalTime(), message);
//        }
//    }

//    class FileLogger : ILogger
//    {
//        private StreamWriter writer;

//        public FileLogger(string path)
//        {
//            writer = File.CreateText(path);
//            writer.AutoFlush = true;
//        }

//        public void WriteLog(string message)
//        {
//            writer.WriteLine("{0},{1}", DateTime.Now.ToShortTimeString(), message);
//        }
//    }

//    class ClimateMonitor
//    {
//        private ILogger logger;
//        public ClimateMonitor(ILogger logger)
//        {
//            this.logger = logger;
//        }

//        public void start()
//        {
//            while (true)
//            {
//                Console.Write(“온도를 입력해 주세요 : “);
//                string temperature = Console.ReadLine();
//                if (temperature == “”)
//                    break;

//                logger.WriteLog(“현재 온도: " + temperature);
//            }
//        }
//    }
//    class jpcorp
//    {
//        static void Main(string[] args)
//        {
//            ClimateMonitor monitor = new ClimateMonitor(new FileLogger(“MyLog.txt”));

//            monitor.start();
//        }
//    }

//}

////인터페이스를 상속하는 인터페이스
//using System;

//namespace DerivedInterface
//{
//    interface ILogger
//    {
//        void WriteLog(string message);
//    }

//    interface IFormattableLoger : ILogger //인터페이스가 인터페이스를 상속한다.
//    {
//        void WriteLog(string format, params Object[] args);
//    }

//    class ConsoleLogger2 : IFormattableLoger
//    {
//        public void WriteLog(string message)
//        {
//            Console.WriteLine("{0},{1}”, DateTime.Now.ToLocalTime(), message);
//        }

//        public void WriteLog(string format, params Object[] args)
//        {
//            string message = String.Format(format, args);
//            Console.WriteLine("{0},{1}”, DateTime.Now.ToLocalTime(), message);
//        }
//    }

//    class jpcorp
//    {
//        static void Main(string[] args)
//        {
//            IFormattableLoger logger = new ConsoleLogger2();
//            logger.WriteLog(“The World is not Flat”);
//            logger.WriteLog("{0}+ {1}={2}” , 1,1,2);
//        }
//    }
//}

//// 인터페이스 다중 상속
//using System;

//namespace MultiInterfaceInheritance
//{
//    interface IRunnable
//    {
//        void Run();
//    }

//    interface IFlyable
//    {
//        void Fly();
//    }

//    class FlyingCar : IRunnable, IFlyable
//    {
//        public void Run()
//        {
//            Console.WriteLine(“Run, Run!!”);
//        }

//        public void Fly()
//        {
//            Console.WriteLine(“Fly, Fly!!”);
//        }
//    }

//    class jpcorp
//    {
//        static void Main(string[] args)
//        {
//            FlyingCar car = new FlyingCar();
//            car.Run();
//            car.Fly();

// IRunnable runnable = car as IRunnable;
// runnable.Run();

//            IFlyable flyable = car as IFlyable;
//            flyable.Fly();
//        }
//    }
//}

//// 추상 클래스
//using System;

//namespace AbstractClass
//{
//    abstract class AbstractBase
//    {
//        protected void PrivateMethodA()
//        {
//            Console.WriteLine(“AbstractBase.PrivateMethodA()”);
//        }
//        public void PublicMerthodA()
//        {
//            Console.WriteLine(“AbstractBase.PublicMerhodA()”);
//        }
//        public abstract void AbstracMethodA();
//    }

//    class Derived : AbstractBase
//    {
//        public override void AbstracMethodA()
//        {
//            Console.WriteLine(“Derived.AbstracrMethodA()”);
//            PrivateMethodA();
//        }
//    }

//    class jpcorp
//    {
//        static void Main(string[] args)
//        {
//            AbstractBase obj = new Derived();
//            obj.AbstracMethodA();
//            obj.PublicMerthodA();
//        }
//    }
//}

////프로퍼티
//using System;

//namespace Property
//{
//    class BirthDatInfo
//    {
//        private string name;
//        private DateTime birthday;

//        public string Name
//        {
//            get
//            {
//                return name;
//            }
//            set
//            {
//                name = value;
//            }
//        }

//        public DateTime BirthDay
//        {
//            get
//            {
//                return birthday;
//            }

//            set
//            {
//                birthday = value;
//            }
//        }

//        public int Age
//        {
//            get
//            {
//                return new DateTime(DateTime.Now.Subtract(birthday).Ticks).Year;
//            }
//        }
//    }

//    class jpcorp
//    {
//        static void Main(string[] args)
//        {
//            BirthDatInfo birth = new BirthDatInfo();
//            birth.Name = “서현”;
//            birth.BirthDay = new DateTime(1991, 6, 28);

//            Console.WriteLine(“Name :{0}”, birth.Name);
//            Console.WriteLine(“Birthday :{0}”, birth.BirthDay.ToShortDateString());
//            Console.WriteLine(“Age :{0}”, birth.Age);
//        }
//    }

//}

////자동 구현 프로퍼티

//using System;

//namespace AutoImplementedProperty
//{
//    class BirthdayInfo
//    {
//        public string Name
//        {
//            get;
//            set;
//        }

//        public DateTime Birthday
//        {
//            get;
//            set;
//        }

//        public int Age
//        {
//            get
//            {
//                return new DateTime(DateTime.Now.Subtract(Birthday).Ticks).Year;
//            }
//        }
//    }

//    class jpcorp
//    {
//        static void Main(string[] args)
//        {
//            BirthdayInfo birth = new BirthdayInfo();
//            birth.Name = " 서현";
//            birth.Birthday = new DateTime(1991,6,28);

//            Console.WriteLine(“Name : {0} “, birth.Name);
//            Console.WriteLine(“Birthday : {0} " , birth.Birthday.ToShortDateString());
//            Console.WriteLine(“Age : {0}",birth.Age);
//        }
//    }
//}

오늘의 C# 공부 : 계속 클래스 공부

Fri, 08 Feb 2013 07:49:43 +0000

////메소드 숨기기

//using System;

//namespace MethodHiding
//{
//    class Base
//    {
//        public void MyMethod()
//        {
//            Console.WriteLine(“Base.MyMethod()”);
//        }
//    }

//    class Derived : Base
//    {
//        public new void MyMethod() //MyMethod를 재정의하는 느낌이다. 그렇지만 오버라이딩처럼 완전히 바꾸진 않는다. new로 만든다.
//        {
//            Console.WriteLine(“Derived.MyMethod()”);
//        }
//    }

//    class MainApp
//    {
//        static void Main(string[] args)
//        {
//            Base baseobj = new Base();
//            baseobj.MyMethod();

// Derived derivedObj = new Derived(); //derived 를 만들면
// derivedObj.MyMethod(); // 같은 mymethod를 불러도 결과는 다시 정의된 녀석으로 나온다. 즉 ‘숨겨진’ 것이다.

//            Base baseOrDerived = new Derived();// 그치만 derived를 만든다 하더라도 그걸 base 클래스에 집어 넣으면
//            baseOrDerived.MyMethod(); // 숨겨졌던 base 클래스의 값이 나온다.
//        }
//    }
//}

////오버라이딩 봉인하기
//// 파생된 클래스에서 더 이상의 오버라이딩을 막기 위한 방법

//using System;

//class Base
//{
//    public virtual void SealMe()
//    {
//    }
//}

//class Derived : Base
//{
//    public sealed override void SealMe()
//    {
//    }
//}

//class WantToOverride : Derived
//{
// public override void SealMe();
//}

//class MainApp
//{
// static void Main(string[] args)
// { } //에러가 납니다 : 오류 2 ‘WantToOverride.SealMe()’: 상속된 ‘Derived.SealMe()’ 멤버가 sealed이므로 재정의할 수 없습니다. C:\jpcorp\ConsoleApplication1\ConsoleApplication1\HelloWorld.cs 64 26 ConsoleApplication1

//}

////중첩 클래스
//using System;
//using System.Collections.Generic;

//namespace NestedClass
//{
//    class Configuration
//    {
//        List listConfig = new List();

//        public void SetConfig(string item, string value)
//        {
//            ItemValue iv = new ItemValue();
//            iv.SetValue(this, item, value);
//        }

//        public string GetConfig(string item)
//        {
//            foreach (ItemValue iv in listConfig)
//            {
//                if (iv.GetItem() == item)
//                    return iv.GetValue();
//            }

// return “”;
// }

//        private class ItemValue
//        {
//            private string item;
//            private string value;

//            public void SetValue(Configuration config, string item, string value)
//            {
//                this.item = item;
//                this.value = value;
//                bool found = false;
//                for (int i = 0; i < config.listConfig.Count; i++)
//                {
//                    if (config.listConfig[i].item == item)
//                    {
//                        config.listConfig[i] = this;
//                        break;
//                    }
//                }

//                if (found == false)
//                {
//                    config.listConfig.Add(this);
//                }
//            }

//            public string GetItem()
//            { return item; }
//            public string GetValue()
//            { return value; }
//        }
//    }

//    class HelloWorld
//    {
//        static void Main(string[] args)
//        {
//            Configuration config = new Configuration();
//            config.SetConfig(“Version”, “V 4.0”);
//            config.SetConfig(“Size”, “655,324 KB”);

// Console.WriteLine(config.GetConfig(“Version”));
// Console.WriteLine(config.GetConfig(“Size”));

//            config.SetConfig(“Version”, “V 4.0.1”);
//            Console.WriteLine(config.GetConfig(“Version”));
//        }
//    }
//}

////분할 클래스
//using System;

//namespace PartialClass
//{
//    partial class MyClass
//    {
//        public void Method1 ()
//        {
//            Console.WriteLine (“Method1”);
//        }

//        public void Method2()
//        {
//            Console.WriteLine(“Method2”);
//        }
//    }

//    partial class MyClass
//    {
//        public void Method3()
//        {
//            Console.WriteLine(“Method3”);
//        }

//        public void Method4()
//        {
//            Console.WriteLine(“Method4”);
//        }
//    }

//    class MainApp
//    {
//        static void Main(string[] args)
//        {
//            MyClass obj = new MyClass();
//            obj.Method1();
//            obj.Method2();
//            obj.Method3();
//            obj.Method4();
//        }
//    }
//}

////구조체

//using System;

//namespace Structure
//{
//    struct Point3D
//    {
//        public int X;
//        public int Y;
//        public int Z;

//        public Point3D(int X, int Y, int Z)
//        {
//            this.X = X;
//            this.Y = Y;
//            this.Z = Z;
//        }

//        public override string ToString()
//        {
//            return string.Format("{0},{1},{2}", X, Y, Z);
//        }
//    }

//    class MainApp
//    {
//        static void Main(string[] args)
//        {
//            Point3D p3d1;
//            p3d1.X = 10;
//            p3d1.Y = 20;
//            p3d1.Z = 30;

// Console.WriteLine(p3d1.ToString());

//            Point3D p3d2 = new Point3D(100, 200, 300);
//            Point3D p3d3 = p3d2;
//            p3d3.Z = 400;

//            Console.WriteLine(p3d2.ToString());
//            Console.WriteLine(p3d3.ToString());
//        }
//    }
//}

오늘의 C# 공부

Thu, 07 Feb 2013 07:32:18 +0000

으미 어렵다 슬슬

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

//////this 키워드
//////자기 자신의 필드나 메소드에 접근할 때 this 키워드를 사용한다.

////using System;

////namespace This
////{
////    class Employee
////    {
////        private string Name;
////        private string Position;

////        public void SetName(string Name)
////        {
////            this.Name = Name;
////        }

////        public string GetName()
////        {
////            return Name;
////        }

////        public void SetPositon(string Position)
////        {
////            this.Position = Position;
////        }

////        public string GetPosition()
////        {
////            return this.Position;
////        }
////    }

////    class HelloWorld
////    {
////        static void Main(string[] args)
////        {
////            Employee pooh = new Employee();
////            pooh.SetName(“pooh”);
////            pooh.SetPositon(“waiter”);
////            Console.WriteLine("{0} {1}", pooh.GetName(), pooh.GetPosition());

////            Employee tigger = new Employee();
////            tigger.SetName(“tigger”);
////            tigger.SetPositon(“Cleaner”);
////            Console.WriteLine("{0} {1}", tigger.GetName(), tigger.GetPosition());
////        }
////    }
////}

////this 생성자

//using System;

//namespace ThisConstructor
//{
//    class Myclass
//    {
//        int a, b, c; // 맴버변수는 굳이 초기화 하지 않아도 기본값이 0 이 들어가고, 쓰레기값이 들어가지 않는다.

//        public Myclass()
//        {
//            this.a = 5425;
//            Console.WriteLine(“Myclass()”);
//        }

//        public Myclass(int b) : this()
//        {
//            this.b = b;
//            Console.WriteLine(“MyClass({0})”, a);
//        }

//        public Myclass(int b, int c)
//            : this(b)
//        {
//            this.c = c;
//            Console.WriteLine(“Myclass({0} . {1})",b,c);
//        }

//        public void PrintFriends()
//        {
//            Console.WriteLine(“a:{0}, b:{1}, c:{2}”, a, b, c);
//        }
//    }

//    class HelloWorld
//    {
//        static void Main(string[] args)
//        {
//            Myclass a = new Myclass();
//            a.PrintFriends();
//            Console.WriteLine();

//            Myclass b = new Myclass(1);
//            b.PrintFriends();
//            Console.WriteLine();

//            Myclass c = new Myclass(10, 20);
//            c.PrintFriends();
//            Console.WriteLine();
//        }
//    }
//}

////접근 한정자로 공개 수준 결정하기

//using System;

//namespace AccessModifier
//{
//    class WaterHeater
//    {
//        protected int temperature;

//        public void SetTemperature(int temperature)
//        {
//            if (temperature < -5 || temperature > 42)
//            {
//                throw new Exception(” 온도 범위를 벗어났습니다 “);
//            }

// this.temperature = temperature;
// }

//        internal void TurnOnWater()
//        {
//            Console.WriteLine ( “Turn on Water : {0} " , temperature);
//        }
//    }

//    class HelloWorld
//    {
//        static void Main (string[] args)
//        {
//            try
//            {
//                WaterHeater heater = new WaterHeater();
//                heater.SetTemperature(20);
//                heater.TurnOnWater();

// heater.SetTemperature(-2);
// heater.TurnOnWater();

// heater.SetTemperature(50);
// heater.TurnOnWater();

//            }
//            catch (Exception e)
//            {
//                Console.WriteLine(e.Message);
//            }
//        }
//    }
//}

////상속받기 연습

//using System;

//namespace Inheritance
//{
//    class Base
//    {
//        protected string Name;
//        public Base(string name) // 생성자
//        {
//            this.Name = name;
//            Console.WriteLine("{0}.Base()”, this.Name); //생성자에 넣은 명령이니 초기에 바로 실행되어 버릴 거다.
//        }

//        ~Base()
//        {
//            Console.WriteLine("{0}.~Base()”, this.Name);
//        }

//        public void BaseMethod()
//        {
//            Console.WriteLine("{0}.BaseMethod()", Name);
//        }
//    }

//    class Derived : Base
//    {
//        public Derived(string Name) : base(Name) //Base 의 초기값에 접근하기 위해 base 명령을 썼네요.
//        {
//            Console.WriteLine("{0}.Derived()", this.Name); // 역시 생성자임. 초기값을 넣어주고 있네요
//        }

//        ~Derived()
//        {
//            Console.WriteLine("{0}.~Derived()", this.Name);
//        }

//        public void DerivedMethod()
//        {
//            Console.WriteLine("{0}.DerivedMethod()", this.Name);
//        }

// }

//    class HelloWorid
//    {
//        static void Main(string[] args)
//        {
//            Base a = new Base(“a”); // 처음에 생성자가 실행되면서 자동으로 씌여지는게 있음.
//            a.BaseMethod();

//            Derived b = new Derived(“b”);
//            b.BaseMethod();
//            b.DerivedMethod();

//        }
//    }
//}

////기반 클래스와 파생 클래스 사이의 형식 변환. 그리고 is와 as

//using System;

//namespace TypeCasting
//{
//    class Mammal
//    {
//        public void Nurse()
//        {
//            Console.WriteLine(“Nurse()”);
//        }
//    }

//    class Dog : Mammal
//    {
//        public void Bark()
//        {
//            Console.WriteLine(“Bark()”);
//        }
//    }

//    class Cat : Mammal
//    {
//        public void Meow()
//        {
//            Console.WriteLine(“Meow()”);
//        }
//    }

//    class HelloWorlds
//    {
//        static void Main(string[] args)
//        {
//            Mammal mammal = new Dog(); //새로운 dog 클래스를 선언하고 이것에 소속된 mamamal 클래스만 사용하겠다고 하면서 집어 넣는다.
//            Dog dog;

//            if (mammal is Dog) //mammal은 dog 인가
//            {
//                dog = (Dog)mammal;
//                dog.Bark();
//            }

// Mammal mamma12 = new Cat();

//            Cat cat = mamma12 as Cat; //as 는 형식 변환 연산자와 같은 일을 하지만 예외가 발생하거나 제대로 되어 있지 않으면 null을 리턴한다.
//            if (cat != null)
//                cat.Meow();

//            Cat cat2 = mammal as Cat; //mammal은 Dog 클래스 입니다.
//            if (cat2 != null)
//                cat2.Meow();
//            else
//                Console.WriteLine(“cat2 is not a Cat : cat2는 Cat 클래스가 아닙니다”);
//            }
//    }
//}

////오버라이딩과 다형성

//using System;

//namespace Overriding
//{
//    class ArmorSuite
//    {
//        public virtual void Initialize()
//        {
//            Console.WriteLine(“Armored”);
//        }
//    }

//    class IronMan : ArmorSuite
//    {
//        public override void Initialize()
//        {
//            base.Initialize();
//            Console.WriteLine(“Repulsor Rays Armed”);
//        }
//    }

//    class WarMachine : ArmorSuite
//    {
//        public override void Initialize()
//        {
//            base.Initialize();
//            Console.WriteLine(“Double-Barrel Cannon Armd”);
//            Console.WriteLine(“Micro-Rocket Launcher Armd”);
//        }
//    }

//    class HelloWorld
//    {
//        static void Main(string[] args)
//        {
//            Console.WriteLine(“Creating Armorsuite…..”);
//            ArmorSuite armosuite = new ArmorSuite();
//            armosuite.Initialize();

//            Console.WriteLine("\nCreating Atmorsuite…..");
//            ArmorSuite ironman = new IronMan();
//            ironman.Initialize();

//            Console.WriteLine("\nCreating Atmorsuite…..");
//            ArmorSuite warmachine = new WarMachine();
//            warmachine.Initialize();
//        }
//    }
//}

오늘의 C# 공부. 테스트 문제 , 클래스

Wed, 06 Feb 2013 06:37:16 +0000

눈폭탄에 워크샵에 두 번 빠졌더니 못따라가겠…

////Test 문제

//using System;

//namespace EX6_2
//{
//    class HelloWorld
//    {
//        public static void Main()
//        {
//            double mean = 0;

// Mean(1, 2, 3, 4, 5, ref mean);

// Console.WriteLine(“평균: {0}", mean);
// }

//        public static void Mean(double a, double b, double c, double d, double e, ref double mean)
//        {
//            mean = (a + b + c + d + e) / 5;
//        }
//    }
//}

//////Test 문제
////using System;

////namespace EX6_1
////{
////    class HelloWorld
////    {
////        static double Square(double arg)
////        {
////            arg *= arg;
////            return arg;
////        }

////        static void Main(string[] args)
////        {
////            Console.Write(“수를 입력하세요: “);
////            string input = Console.ReadLine();
////            double arg = Convert.ToDouble(input);

////            Console.WriteLine(“결과:{0}”, Square(arg));
////        }
////    }
////}

////테스트 3번
//using System;

//namespace EX6_3
//{
//    class HelloWorid
//    {
//        public static void Main()
//        {
//            int a = 3;
//            int b = 4;
//            int resultA = 0;

// Plus(a, b, out resultA);

// Console.WriteLine("{0} + {1} = {2}”, a, b, resultA);

//            double x = 2.4;
//            double y = 3.1;
//            double resultB = 0;

// Plus(x, y, out resultB);

// Console.WriteLine("{0} + {1} = {2}”, x, y, resultB);
// }

//        public static void Plus(int a, int b, out int c)
//        {
//            c = a + b;
//        }

//        public static void Plus(double a, double b, out double c)
//        {
//            c = a + b;
//        }

// }
//}

////클래스를 선언하고 객체를 생성하는 예제 프로그램
//using System;

//namespace BasicClass
//{
//    class Cat
//    {
//        public string Name;
//        public string Color;

//        public void Meow()
//        {
//            Console.WriteLine("{0}:야옹”,Name);
//        }
//    }

//    class MainApp
//    {
//        static void Main(string[] args)
//        {
//            Cat kitty = new Cat();
//            kitty.Color = “하얀색”;
//            kitty.Name = “키티”;
//            kitty.Meow();
//            Console.WriteLine("{0} : {1}", kitty.Name, kitty.Color);

//            Cat nero = new Cat();
//            nero.Color = “검은색”;
//            nero.Name = “네로”;
//            nero.Meow();
//            Console.WriteLine("{0} : {1}", nero.Name, nero.Color);
//        }
//    }

//}

////생성자와 소멸자

//using System;

//namespace Constructor
//{
// class Cat
// {

//// 생성자는 클래스 이름과 같은 메소드를 만들어 주면 되는 것이다.

//        ~Cat()
//        {
//            Console.WriteLine("{0}:잘가", Name);
//        } //소멸자는안쓴다. 그치만 알아두기만 하자. 소멸자는 생성자 있는 곳에 선언해 두기만 하면,
//        // 자동으로 프로그램이 끝난 후에 생성된 객체를 날려버린다.
//        // 그치만 GC가 있는데 굳이 수동으로 이걸 호출하는게 더 바보짓이다.

//        public Cat()
//        {
//            Name= “”;
//            Color = “”;
//        } //아무것도 안쓰면 아무것도 없는 값으로 들어가게 된다.

//        public Cat(string _Name, string _Color)
//        {
//            Name = _Name;
//            Color = _Color;
//        }// 이름을 굳이 쓰면 이름이 들어가도록 오버로딩이 되어 있다.

//        public string Name;
//        public string Color;

//        public void Meow()
//        {
//            Console.WriteLine("{0} : 야옹",Name);
//        }
//    }

//    class HelloWorld
//    {
//        static void Main()
//        {
//            Cat kitty = new Cat(“키티”, “하얀색”);
//            kitty.Meow();
//            Console.WriteLine("{0},{1}", kitty.Name, kitty.Color);

//            Cat nero = new Cat(“네로”, “검은색”);
//            nero.Meow();
//            Console.WriteLine("{0},{1}", nero.Name, nero.Color);
//        }
//    }

//}

////딥카피
//// 딥카피는 수동으로 만들어 줘야 한다
//using System;

//namespace DeepCopy
//{
//    class MyClass
//    {
//        public int MyField1;
//        public int MyField2;

//        public MyClass DeepCopy()
//        {
//            MyClass newCopy = new MyClass(); // 클래스를 new 시키고 초기화한다.
//            newCopy.MyField1 = this.MyField1; // 새로 만든 class 에 ‘지금 현재 있는 값’ 을 집어 넣는다.
//            newCopy.MyField2 = this.MyField2;
//            return newCopy; //그리고 그걸 리턴한다.
//        }
//    }

//    class HelloWorld
//    {
//        static void Main()
//        {
//            Console.WriteLine(“얕은 카피 : Shallow Copy”);
//            {
//                MyClass source = new MyClass();
//                source.MyField1 = 10;
//                source.MyField2 = 20;

// MyClass target = source;
// target.MyField2 = 30;

//                Console.WriteLine ("{0} {1}", source.MyField1, source.MyField2);
//                Console.WriteLine ("{0} {1}", target.MyField1, target.MyField2);
//            }

//            Console.WriteLine(“딥카피 : Deep Copy”);
//            {
//                MyClass source = new MyClass();
//                source.MyField1 = 10;
//                source.MyField2 = 20;

//                MyClass target = source.DeepCopy();
//                target.MyField2 = 30;

//                Console.WriteLine("{0} {1}",source.MyField1,source.MyField2);
//                Console.WriteLine("{0} {1}",target.MyField1, target.MyField2);
//            }
//        }
//    }
//}

////this 키워드
////자기 자신의 필드나 메소드에 접근할 때 this 키워드를 사용한다.

//using System;

//namespace This
//{
//    class Employee
//    {
//        private string Name;
//        private string Position;

//        public void SetName(string Name)
//        {
//            this.Name = Name;
//        }

//        public string GetName()
//        {
//            return Name;
//        }

//        public void SetPositon(string Position)
//        {
//            this.Position = Position;
//        }

//        public string GetPosition()
//        {
//            return this.Position;
//        }
//    }

//    class HelloWorld
//    {
//        static void Main(string[] args)
//        {
//            Employee pooh = new Employee();
//            pooh.SetName(“pooh”);
//            pooh.SetPositon(“waiter”);
//            Console.WriteLine("{0} {1}", pooh.GetName(), pooh.GetPosition());

//            Employee tigger = new Employee();
//            tigger.SetName(“tigger”);
//            tigger.SetPositon(“Cleaner”);
//            Console.WriteLine("{0} {1}", tigger.GetName(), tigger.GetPosition());
//        }
//    }
//}

오늘의 C# 공부 : 매개변수

Mon, 28 Jan 2013 07:40:26 +0000

////출력 전용 매개 변수
//// out을 입력하면 값을 메소드에서 값을 반드시 넣어야 한다.
//// out을 입력하면 메소드에서 값을 읽을 수 없고 출력만 할 수 있다.
//using System;

//namespace UsingOut
//{
//    class MainApp
//    {
//        static void Divide(int a, int b, out int quotient, out int remainder)
//        {
//            quotient = a/b;
//            remainder = a%b;
//        }

//        static void Main(string[] args)
//        {
//            int a = 20;
//            int b = 3;
//            int c;
//            int d;

// Divide(a,b,out c, out d);

//            Console.WriteLine(“a:{0},b:{1}, a/b:{2}, a%b{3}",a,b,c,d);
//        }
//    }
//}

////메소드 오버로딩
//// 같은 이름의 메소드로 여러 개의 연산을 만들 수 있다.
//using System;

//namespace HelloWorld
//{
//    class MainApp
//    {
//        static int Plus (int a,int b)
//        {
//            Console.WriteLine(“Calling int Plus(int,int)…”);
//            return a + b;
//        }

//        static int Plus(int a, int b, int c)
//        {
//            Console.WriteLine(“Calling int Plus (int, int,int)…”);
//            return a + b + c;
//        }

//        static double Plus(double a, double b)
//        {
//            Console.WriteLine(“Calling double Plus (double, double)….”);
//            return a + b;
//        }

//        static double Plus(int a, double b)
//        {
//            Console.WriteLine(“Calling douvle Plus(int,double)….”);
//            return a + b;
//        }

//        static void Main(string[] args)
//        {
//            Console.WriteLine(Plus(1, 2));
//            Console.WriteLine(Plus(1, 2, 3));
//            Console.WriteLine(Plus(1.0, 2.4));
//            Console.WriteLine(Plus(1, 2.4));
//        }
//    }
//}

//////가변길이 매개 변수

////using System;

////namespace UsingParams
////{
////    class MainApp
////    {
////        static int Sum(params int[] args)
////        {
////            Console.Write(“Summing….”);
////            int sum = 0;

////            for (int i = 0; i < args.Length; i++)
////            {
////                if (i > 0)
////                    Console.Write(”, “);

////                Console.Write(args[i]);
////                sum += args[i];
////            }

////            Console.WriteLine();
////            return sum;
////        }

////        static void Main(string[] args)
////        {
////            int sum = Sum(1,2,3,4,5,6,7,8,9,10);
////            Console.WriteLine(“Sum :{0}",sum);
////        }
////    }
////}

////명명된 매개 변수
//using System;

//namespace NameParameter
//{
//    class HelloWorld
//    {
//        static void PrintProfile(string name, string phone)
//        {
//            Console.WriteLine(“Name : {0}, phone : {1}”, name, phone);
//        }

//        static void Main()
//        {
//            PrintProfile(name: “박찬호”, phone: “010-123-4567”);
//            PrintProfile(phone: “010-000-0000”, name: “박지성”);
//            PrintProfile(“박세리”, “010-111-1111”);
//            PrintProfile(“대마왕”, phone: “010-852-9631”);
//        }
//    }
//}

////선택적 매개 변수
//using System;

//namespace OpionalParameter
//{
//    class HelloWorld
//    {
//        static void PrintProfile(string name, string phone = “”)
//        {
//            Console.WriteLine(“Name:{0},Phone:{1}”, name, phone);
//        }

//        static void Main(string[] args)
//        {
//            PrintProfile(“태연”);
//            PrintProfile(“윤아”, “010-123-4567”);
//            PrintProfile(name: “유리”);
//            PrintProfile(name: “서현”, phone: “010-456-7894”);
//        }
//    }
//}

오늘의 C# 공부

Fri, 25 Jan 2013 07:58:28 +0000

////메소드 예제
//using System;

//namespace Method
//{
//    class Calculator
//    {
//        public static int Plus(int a, int b)
//        {
//            return a + b;
//        }

//        public static int Minus(int a, int b)
//        {
//            return a - b;
//        }
//    }

//    class MainApp
//    {
//        public static void Main()
//        {
//            int result = Calculator.Plus(3, 4);
//            Console.WriteLine(result);

//            result = Calculator.Minus(5, 2);
//            Console.WriteLine(result);
//        }
//    }
//}

////재귀호출과 리턴 예제

//using System;

//namespace Return
//{
//    class Mainapp
//    {
//        static int Fibonacci(int n)
//        {
//            if (n < 2)
//                return n;
//            else
//                return Fibonacci(n - 1) + Fibonacci(n - 2);
//        }

//        static void PrintProfile(string name, string phone)
//        {
//            if (name == “”)
//            {
//                Console.WriteLine(“이름을 입력해 주세요”);
//                return;
//            }
//            Console.WriteLine(“Name:{0}, Phone:{1}”, name, phone);
//        }

//        static void Main(string[] args)
//        {
//            Console.WriteLine(“10번째 피보나치 수:{0}",Fibonacci(10));
//            PrintProfile(”", “123-4567”);
//            PrintProfile(“대마왕”, “456-1230”);
//        }
//    }
//}

////매개 변수 연습
////매소드에 들어간 값은 복사된 값이라서 본래의 값이 변하거나 하지 않는다.

//using System;

//namespace SwapByValue
//{
//    class MainApp
//    {
//        public static void Swap(int a, int b)
//        {
//            int temp = b;
//            b = a;
//            a = temp;
//        }

//        static void Main()
//        {
//            int x = 3;
//            int y = 4;

// Console.WriteLine(“x:{0},y:{1}”, x, y);

// Swap(x, y);

//            Console.WriteLine(“x:{0},y:{1}”, x, y);
//        }
//    }
//}

//참조에 의한 매개 변수 전달
using System;

namespace SwapByRef
{
    class MainApp
    {
        static void Swap(ref int a, ref int b)
        {
            int temp = b;
            b = a;
            a = temp;
            return;
        }

        static void Main(string[] args)
        {
            int x = 3;
            int y = 4;

            Console.WriteLine(“x:{0}, y:{1}”, x, y);
            Swap(ref x, ref y);
            Console.WriteLine(“x:{0}, y:{1}”, x, y);
        }
    }
}

Test 10번 문제

Fri, 25 Jan 2013 07:14:16 +0000

using System;

//Test 10번
namespace Test10
{
    class HelloWorld
    {
        static void Main()
        {
            char Alphabet = ‘A’;
            int number = 1;

            //앞에 2번 돌리기
            for (int i = 0; i < 2; i++)
            {

                for (int j = 0; j < i; j++)
                {
                    Console.Write(" “);
                }

Console.Write("{0} “, Alphabet);

                for (int k=3; k > (i*2); k–)
                {
                    Console.Write("{0} “,number);
                    number++;

                }
                Console.Write("{0} “, Alphabet);
                Alphabet++;

Console.WriteLine();
}

//C는 무식하게 쓰기

Console.WriteLine (” {0}",Alphabet);
Alphabet++;

            //뒤에 2번 돌리기
            for (int i = 2; i > 0; i–)
            {

                for (int j = 1; j < i; j++)
                {
                    Console.Write(” “);
                }

Console.Write("{0} “,Alphabet);

                for (int k = 4 ; k >= (i* 2); k–)
                {
                    Console.Write("{0} “,number);
                    number++;

                }
                Console.Write("{0} “,Alphabet);
                Alphabet++;

Console.WriteLine();
}

}
}
}

오늘의 C# 공부

Wed, 23 Jan 2013 07:53:13 +0000

using System;

////switch 문
//namespace Switch
//{
//    class HelloWorld
//    {
//        static void Main(string[] args)
//        {
//            Console.Write(“요일을 입력하세요. (일,월,화,수,목,금,토) : “);
//            string day = Console.ReadLine();

//            switch (day)
//            {
//                case “일” :
//                    Console.WriteLine (“Sunday”);
//                    break;

//                case “월”:
//                    Console.WriteLine(“Monday”);
//                    break;

//                case “화”:
//                    Console.WriteLine(“Tuesday”);
//                    break;

//                case “수”:
//                    Console.WriteLine(“Wednesday”);
//                    break;

//                case “목”:
//                    Console.WriteLine(“Thursday”);
//                    break;

//                case “금”:
//                    Console.WriteLine(“Friday”);
//                    break;

//                case “토”:
//                    Console.WriteLine(“Saturday”);
//                    break;

//                default:
//                    Console.WriteLine("{0}은 요일이 아닙니다”,day);
//                    break;

//            }
//        }
//    }
//}

////반복문 연습
//namespace While
//{
//    class HelloWorld
//    {
//        static void Main(string[] args)
//        {
//            int i = 10;

//            while (i > 0)
//            {
//                Console.WriteLine(“i : {0}”, i–);
//            }
//        }
//    }
//}

////do while문
//namespace DoWhile
//{
//    class HellowWorld
//    {
//        static void Main()
//        {
//            int i = 10;

//            do
//            {
//                Console.WriteLine(“a) i: {0}”, i–);
//            }
//            while (i > 0);

//            do
//            {
//                Console.WriteLine(“b) i : {0}”, i–);
//            }
//            while (i > 0);

// }
// }
//}

////for 문
//namespace For
//{
//    class HelloWorld
//    {
//        static void Main()
//        {
//            for (int i = 0; i < 5; i++)
//            {
//                Console.WriteLine("{0}",i);
//            }
//        }
//    }
//}

////중첩 for 문
//namespace ForFor
//{
//    class HelloWorld
//    {
//        static void Main()
//        {
//            for (int i = 0; i < 5; i++)
//            {
//                for (int j = 0; j <= i; j++)
//                {
//                    Console.Write(”*");
//                }
//                Console.WriteLine();
//            }
//        }
//    }
//}

//for문을 이용한 무한루프
//namespace InfiniteFor
//{
//    class HelloWorld
//    {
//        static void Main()
//        {
//            int i = 0;
//            for (; ; )
//            {
//                Console.WriteLine(i++);
//            }
//        }
//    }
//}

////break 점프문
//namespace Break
//{
//class HelloWorld
//{
//static void Main(string[] args)
//{
//    while (true)
//    {
//        Console.Write(“계속할까요?(예/아니오) :”);
//        string answer = Console.ReadLine();

//        if (answer == “아니오”)
//            break;
//    }
//}
//}
//}

//// 테스트 1번
//namespace Test1
//{
//    class HelloWorld
//    {
//        static void Main()
//        {

//            for (int i = 5; i >= 1; i–)
//            {
//                for (int j = 1; j <= i; j++)
//                {
//                    Console.Write(“A”);
//                }
//                Console.WriteLine();
//            }
//        }
//    }
//}

////테스트 2번
//namespace Test2
//{
//    class HelloWorld
//    {
//        static void Main()
//        {
//            int k = 1;

//            for (int i = 4; i >= 0; i–)
//            {
//                for (int j = 0; j < i; j++)
//                {
//                    Console.Write(" “);
//                }

//                for (int j = 0; j < k; j++)
//                {
//                    Console.Write(”*");
//                }
//                 k += 2;

//                Console.WriteLine();
//            }
//        }
//    }
//}

////테스트 3번
//namespace Test3
//{
//class HelloWorld
//{
//    static void Main()
//    {

//        for (int i = 0; i <= 3; i++)
//        {
//            for (int j = 3; j > i; j–)
//            {
//                Console.Write(" “);
//            }

//            for (float k = 0; k <= i; k += 0.5f)
//            {
//                Console.Write(”*");
//            }
//            Console.WriteLine();
//        }

//        for (int i = 1; i <=3 ; i++)
//        {
//            for (int j = 1; j <= i; j++)
//            {
//                Console.Write(" “);
//            }

//            for (float k = 3; k >=i ; k-= 0.5f)
//            {
//                Console.Write(”*");
//            }

//            Console.WriteLine();
//        }
//    }
//}
//}

//// 테스트 4번
//namespace Test4
//{
//    class HelloWorld
//    {
//        static void Main()
//        {
//            char alphabet = ‘A’;

//            //Console.WriteLine(–alphabet);

//            for (int i = 0; i < 5; i++)
//            {
//                for (int j = 0; j <= i; j++)
//                {
//                    Console.Write(alphabet++);
//                }

// Console.WriteLine();
// }

// }
// }
//}

////테스트 5번
//namespace Test5
//{
//    class HelloWorld
//    {
//        static void Main()
//        {
//            for (int i = 0; i < 5; i++)
//            {
//                for (int j = 0; j < i; j++)
//                {
//                    Console.Write(" “);
//                }
//                Console.WriteLine(“A”);

//            }
//        }
//    }
//}

////테스트 6번
//namespace Test6
//{
//    class HelloWorld
//    {
//        static void Main()
//        {
//            for (int i = 4; i >= 0; i–)
//            {
//                for (int j = 0; j < i; j++)
//                {
//                    Console.Write(” “);
//                }
//                Console.WriteLine(“A”);
//            }
//        }
//    }
//}

//// 테스트 7번
//namespace Text7
//{
//    class HelloWorld
//    {
//        static void Main()
//        {
//            int n = 11;
//            for (int i = 0; i < 4; i++)
//            {
//                for (int j = 0; j <= i; j++)
//                {
//                    Console.Write(n % 10);
//                    n++;
//                }

//                Console.WriteLine();
//            }
//        }
//    }
//}

////테스트 8번
//namespace Test8
//{
//    class HelloWorld
//    {
//        static void Main()
//        {
//            char ch = ‘Z’;

//            for (int i = 5; i > 0; i–)
//            {
//                for (int j = 0; i > j; j++)
//                {
//                    Console.Write("{0} “,ch–);
//                }

//                Console.WriteLine();
//            }

//        }
//    }
//}

//테스트 9번
namespace Test9
{
    class HelloWorld
    {
        static void Main()
        {
            int n = 1;

            // 앞에 3줄
            for (int i = 0; i < 3; i++)
            {
                for (int j = 2; j > i; j–)
                {
                    Console.Write(”   “);
                }

                for (float k = 0; k <= i; k += 0.5f)
                {
                    if (n < 9)
                    {
                        Console.Write("{0} “, n);
                    }
                    else
                    {
                        Console.Write("{0} “, n);
                    }
                    n += 2;
                }
                Console.WriteLine();
            }

// 뒤에 2줄

            for (int i = 0; i < 2; i++)
            {
                for (int j = 0; j <= i; j++)
                {
                    Console.Write(” “);
                }

                for (float k = 1; k >= i; k -= 0.5f)
                {
                    Console.Write("{0} “, n);
                    n += 2;
                }

Console.WriteLine();

            }
        }
    }
}

제작중. 9번문제.

Tue, 22 Jan 2013 22:14:18 +0000

using System;
//using System.Collections.Generic;
//using System.Linq;
//using System.Text;
//using System.Threading.Tasks;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            int n = 2;
            int Resultnumber = 1;

            for (int i = 0; i < 5; i++)
            {

                for (int j = -3; Math.Abs(j) >= (Math.Abs(n)+1); j++)
                {
                    Console.Write(Resultnumber);

                }

n -= 1;//공백을 증가했다가 감소시킴

Console.WriteLine();
}

}
}
}

문제 7번

Tue, 22 Jan 2013 21:49:43 +0000

using System;
//using System.Collections.Generic;
//using System.Linq;
//using System.Text;
//using System.Threading.Tasks;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            int n = 11;
            for (int i = 0; i <= 3; i++)
            {

                for (int j = 0; j <= i; j++)
                {
                    Console.Write(n%10);
                    n += 1;
                }

Console.WriteLine("");
}

}
}
}

문제 5번 6번

Tue, 22 Jan 2013 21:41:15 +0000

using System;
//using System.Collections.Generic;
//using System.Linq;
//using System.Text;
//using System.Threading.Tasks;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {

            for (int i = 0; i <= 5; i++)
            {
                for (int j = 0; j < i; j++)
                {
                    Console.Write(" “);

                }

Console.WriteLine(“A”);
}

}
}
}

using System;
//using System.Collections.Generic;
//using System.Linq;
//using System.Text;
//using System.Threading.Tasks;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {

            for (int i = 0; i <= 5; i++)
            {
                for (int j = 5; j > i; j–)
                {
                    Console.Write(” “);

                }

Console.WriteLine(“A”);
}

}
}
}

문제 3번

Tue, 22 Jan 2013 20:43:21 +0000

// 학원 선생님이 내주신 과제

using System;
//using System.Collections.Generic;
//using System.Linq;
//using System.Text;
//using System.Threading.Tasks;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine(“Hello World!!”);

            for (int i = 0; i <= 3; i++)
            {
                for (int j = 3; j > i; j–)
                {
                    Console.Write(" “);
                }

                for (float k = 0; k <= i; k += 0.5f)
                {
                    Console.Write(”*");
                }
                Console.WriteLine();
            }

            for (int i = 1; i <=3 ; i++)
            {
                for (int j = 1; j <= i; j++)
                {
                    Console.Write(" “);
                }

                for (float k = 3; k >=i ; k-= 0.5f)
                {
                    Console.Write(”*");
                }

Console.WriteLine();
}

}
}
}

//3번 다시

using System;
//using System.Collections.Generic;
//using System.Linq;
//using System.Text;
//using System.Threading.Tasks;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine(“Hello World!!”);

// 2줄만 돌리기

            for (int i = 0; i <= 2; i++)
            {
                for (int j = 2; j > i; j–)
                {
                    Console.Write(" “);
                }

                for (float k = 0; k <= i; k += 0.5f)
                {
                    Console.Write(”*");
                }
                Console.WriteLine();
            }

            // 3줄 돌리기
            for (int i = 1; i <= 2; i++)
            {
                for (int j = 1; j <= i; j++)
                {
                    Console.Write(" “);
                }

                for (float k = 2; k >= i; k -= 0.5f)
                {
                    Console.Write(”*");
                }

Console.WriteLine();
}

}
}
}

게임업계의 장래가 너무 어두운 것 같아요. 취업해도 될까요?

Mon, 21 Jan 2013 23:51:12 +0000

Q: 곧 30이 되는 신입 아티스트 지망생입니다. 업계가 불안하다고 하는데 걱정되네요.
이 업계에 취업하는게 전망이 있을까요? 포트폴리오 첨부합니다. 독설 부탁드려요.

A :
고민이 많으시겠습니다. 나이도 나이고, 업계에 불안한 소식만 늘어가니까 말이죠.

한 가지 재미있는 예를 들어 볼께요.

옛날 애니메이션 업계에 촬영감독님이라고 있었습니다.

셀로 그린 에니메이션을 한 장 한장 촬영해서 필름으로 만드시는 분이었지요.

광선검이나 빛 효과같은 특수효과는 이 분들이 촬영할때 다중 노출 기법등을 동원하지 않으면 만들지 못했었습니다.

거대하고 비싼 촬영기기와 촬영감독님은 그야말로 애니메이션의 최고 기술자이자 최종 완성자였었습니다.

그런데 그 감독님들이 순식간에 모두 직업을 잃었습니다. 왜 그랬을까요?

바로 ‘포토샵’ 이 나오고 난 후 부터입니다. 애니메이션 작업을 더이상 셀에서 할 필요도 없어졌고,

각종 3D와 특수효과를 비싼 장비 필요 없이 간단하게 작업할 수 있게 바뀌었기 때문이지요.

그 다음 예를 들어 볼께요. 한 사람의 얘기입니다.

그 사람은 전문대학교 출신입니다. 게임과 전혀 상관 없는 과였죠.

그리고 잘 다니던 회사 를 내팽겨치고

그 때까지 취미로 게임만들던 팀에, 월급도 받지 못한 채 들어가서 일하기 시작했었습니다.

그 사람은 솔직히 앞으로도 계속 월급 받지 못할 줄 알았습니다.

그냥 이렇게 골방에서, 만화가들처럼 (지금이나 그때나 만화가들은 가난했었습니다 ) 그렇게 제대로 돈도 받지 못하고 가난하게 살 것이라고 생각했었습니다.

지금은? 좋은 회사에서 남부럽지 않게 살아가고 있습니다.

자. 이렇게 제가 본 것만 해도 이런 상황들이 벌어집니다.

누구도 앞날은 어떻게 될지 모릅니다. 알 수 있습니까? 알 수 있다면 로또나 사지 왜 열심히 공부하고 일하겠습니까?

게임업계가 말씀하신대로 전망이 밝지 않을 수도 있습니다.

좋습니다.

그럼 한가지 묻죠.

게임업계를 선택한 이유는 ‘전망이 밝아서’ 입니까?

‘본인이 이거 아니면 죽을 것 같아서’ 입니까?

‘전망이 밝아서’ 라면 빨리 포기하시고, 편안하게 사십시오.

이 일, 안편합니다. 화려해 보이십니까? 애초에 이 일을 왜 선택하신겁니까?

전망이 밝다는 ‘보장’ 이 없으면 안하실 생각이었단 말입니까?

본인은 아닐 수도 있지만, 실제로 그런 친구들이 있습니다. 아니 많습니다.

왜 게임회사에 오려고 하는 겁니까 도대체?

요새 실무의 사람들 생각을 말씀드릴까요? D모사의 유명한 TD님이 말씀하신 명언입니다.

“우리는 예전에 게임을 만들고 싶어서 회사에 들어왔지만,

요새 신입들은 취직을 하고 싶어서 게임을 만드는 척 한다"

신입들 면접볼때 가려내는게 바로 저거입니다.

특히 그래픽들. ‘그림을 그리고는 싶은데 그림은 배고픈 직업이라 가장 돈많이 준다는 게임회사에 가야지’

따위의 생각으로 들어오는 사람들이 진짜 있습니다.

그런데 더 웃긴건, 본인들이 그런 생각을 가지고 있는지도 모릅니다. 자신은 게임에 대한 열정이 누구보다 높다고 하죠.

저는 이런 질문을 던지죠.

‘게임과 그림, 둘 중에 하나를 선택하고 다른쪽을 일부 포기해야만 하는 상황이라면 뭘 선택하겠습니까?’

그럼 잠시 고민하다가 ‘그림’ 이라고 합니다. 이런 사람들은 게임을 만들러 온게 아닙니다. 그림을 그리러 온 사람이지요.

이런 사람도 실력만 좋다면 뽑을 수 있습니다. 그리고 몇 년 정도는 괜찮습니다 이런 사람들은, 중간에 생각이 바뀔 수도 있구요.
그렇지만 일단 시작은 평생직장으로 생각하고 오는 사람은 아닙니다. 그 정도로 실력이 좋으시다면야 할 말이 없습니다만.

본인에게 똑같은 질문을 던지죠.

‘게임과 안정된 생활, 둘 중에 하나를 선택하고 다른쪽을 일부 포기해야만 하는 상황이라면 뭘 선택하겠습니까?’

추가로 말씀드리지요. 문화업계는 그런사람들 많이 있습니다.

개그맨들이 모두 유재석만큼 돈을 많이 버나요?

개그맨들이 안정적인 생활을 하나요?

개그맨을 하려는 사람들이 전망을 따지면서 하는 걸까요?

만화가중에 부자가 있기나 합니까?

그럼 만화가들은 왜 그런 불안한 생활을 할까요?

안정된 생활을 원하신다면, 지금 빨리 그만두시기 바라겠습니다. 공무원 안정적이고 좋은 직업입니다. 그쪽 준비하세요.
성공 못할 것 같으니까 안전한 곳에서 적당히 구겨서 살아가자라는 그런 삶은 미안하지만 우리 업계에는 절대 맞지 않습니다.
미안하지만 여기는 싸워서 이기는 전쟁터입니다. “경력자 자질부족” 이라는 게임백서의 그래프가 무슨 의미인지 아직 이해 못하신 것 같네요.

거기다가 미안한 말씀입니다만, 본인의 지금 수준의 실력으로는 업계의 전망을 걱정할 수 있는 수준은 아닙니다.

마치 대학을 들어갈 성적이 안되는 학생이 대학 졸업후 취업률이 낮을 것 같다고 걱정하는 상황입니다.

업계가 어둡다고요 ㅎㅎㅎ

죄송하지만 아무리 업계가 어두워도, 상위 50%의 실력자는 걱정없이 살아갈겁니다.

그리고 상위 10%의 실력자는 대기업에 부럽지 않게 살아갈겁니다.

자신의 실력이 없음을 두려워 해야지, 업계를 두려워 하는것은 지구멸망을 걱정하며 살아가는 것과 크게 다를 바 없지요. 그건 왜 걱정 안하시냐고 묻고 싶을 정도네요.

그리고 이미 국내에서도 업계가 정말로 엉망이 되면, 중국에서 , 미국에서, 일본에서 데려가려고 호시탐탐 노리는 인재들이 득시글 거리고 있습니다.

국내 업계가 어둡다고요? ㅎㅎ 세계는 넓어요. 실력만 있으면 통역을 붙여서라도 데려가는게 이 업계인데 도대체 뭘 걱정하고 있는것인지 알 수가 없군요.

그래요. 실력이 지금 정도로 계속 가신다면, 업계의 거창한 생각 이전에 일단 취직부터 걱정하세요.

신입이어서 걱정된다고요? 경력직은 특별대우라도 있다고 생각하시나요?

실력 없는 사람은 경력이건 신입이건 , 업계가 발전해도 앞날이 캄캄할 겁니다.

그건 옛날부터 늘 그래 왔어요.

업계가 활황일때요. 실력 좋은 사람이 밀려들다보니까 실력 없는 사람은 제대로 대우를 받지 못했어요.

업계가 불황이라고요. 실력 좋은 사람만 남기고 실력 없는 사람은 짤릴 겁니다. 네. 확실히 말씀드릴께요.

현업에 있는 오래된 사람으로서, 대학교수로서도 잘 모르는 학생의 투정을 받아주는건 많이 해본 일이긴 합니다만

이번에는 살짝 삐직해서 제가 말투가 지나치긴 했습니다. 죄송합니다. ㅎㅎ

하긴… 학생들 대상으로도 상담할때 이렇게 얘기하긴 하는군요.

슬램덩크의 명대사죠 . “풋내기가 발전하기 위해서는 본인이 풋내기라는걸 아는 것 부터다”

정리하죠.

의지 : 일단 본인이 정말 게임회사에 들어가고 싶은건지 게임회사가 돈 많이 주고 안정적이니까 기웃대는건지 다시 생각해 보세요.
실력 : 일단 실력이 실무 사람들과 같이 일 할 정도의 수준이 된 다음에 업계의 미래를 고민하시던가 하세요.

ps. 화나지 않았어요. 단지 제가 사랑하는 업계에, 이 일을 사랑하는 사람만이 가득하기를 바랄뿐.

1대 1 독설 원하시면 언제건 찾아오세요.

(adsbygoogle = window.adsbygoogle || []).push({});

오늘의 C# 공부

Mon, 21 Jan 2013 07:59:41 +0000

using System;

//            switch (day)
//            {
//                case “일” :
//                    Console.WriteLine (“Sunday”);
//                    break;

//                case “월”:
//                    Console.WriteLine(“Monday”);
//                    break;

//                case “목”:
//                    Console.WriteLine(“Thursday”);
//                    break;

//                case “금”:
//                    Console.WriteLine(“Friday”);
//                    break;

//                case “토”:
//                    Console.WriteLine(“Saturday”);
//                    break;

//                default:
//                    Console.WriteLine("{0}은 요일이 아닙니다”,day);
//                    break;

//            }
//        }
//    }
//}

////반복문 연습
//namespace While
//{
//    class HelloWorld
//    {
//        static void Main(string[] args)
//        {
//            int i = 10;

//            while (i > 0)
//            {
//                Console.WriteLine(“i : {0}”, i–);
//            }
//        }
//    }
//}

////do while문
//namespace DoWhile
//{
//    class HellowWorld
//    {
//        static void Main()
//        {
//            int i = 10;

//            do
//            {
//                Console.WriteLine(“a) i: {0}”, i–);
//            }
//            while (i > 0);

//            do
//            {
//                Console.WriteLine(“b) i : {0}”, i–);
//            }
//            while (i > 0);

// }
// }
//}

//        if (answer == “아니오”)
//            break;
//    }
//}
//}
//}

//// 테스트 1번
//namespace Test1
//{
//    class HelloWorld
//    {
//        static void Main()
//        {

////테스트 2번
//namespace Test2
//{
//    class HelloWorld
//    {
//        static void Main()
//        {
//            int k = 1;

//            for (int i = 4; i >= 0; i–)
//            {
//                for (int j = 0; j < i; j++)
//                {
//                    Console.Write(" “);
//                }

//                for (int j = 0; j < k; j++)
//                {
//                    Console.Write(”*");
//                }
//                 k += 2;

//                Console.WriteLine();
//            }
//        }
//    }
//}

오늘의 C# 공부

Fri, 18 Jan 2013 07:52:06 +0000

using System;

////시프트 연산자
//namespace ShiftOperator
//{
//    class HelloWorld
//    {
//        static void Main()
//        {
//            Console.WriteLine(“Testing «….”);

//            int a = 1;
//            Console.WriteLine(“a     : {0:D5} (0x {0:X8})”, a); //D는 10진수5는 자릿수, X는 16진수 8은 자릿수
//            Console.WriteLine(“a « 1: {0:D5} (0x {0:X8})”, a « 1); // 2진수인 데이터를 1칸 좌측으로 이동시켰다.
//            Console.WriteLine(“a « 2: {0:D5} (0x {0:X4})”, a « 2);
//            Console.WriteLine(“a « 5: {0:D5} (0x {0:X8})”, a « 5);

// Console.WriteLine("\nTesting » … “);

//            int b = 255;
//            Console.WriteLine(“b     : {0:D5} (0x {0:X8})”, b);
//            Console.WriteLine(“b » 1: {0:D5} (0x {0:X8})”, b » 1);
//            Console.WriteLine(“b » 2: {0:D5} (0x {0:X8})”, b » 2);
//            Console.WriteLine(“b » 5: {0:D5} (0x {0:X8})”, b » 5);

// Console.WriteLine("\nTesting » 2… “);

//            int c = -255;
//            Console.WriteLine(“c     : {0:D5} (0x {0:X8})”, c);
//            Console.WriteLine(“c » 1: {0:D5} (0x {0:X8})”, c » 1);
//            Console.WriteLine(“c » 2: {0:D5} (0x {0:X8})”, c » 2);
//            Console.WriteLine(“c » 5: {0:D5} (0x {0:X8})”, c » 5);

// }
// }
//}

//// 비트 연산자 실습
//namespace BiteWiseOperator
//{
//    class HelloWorld
//    {
//        static void Main()
//        {
//            int a = 9;
//            int b = 10;

//            Console.WriteLine("{0}&{1}:{2}”, a, b, a & b);
//            Console.WriteLine("{0}|{1}:{2}”, a, b, a | b);
//            Console.WriteLine("{0}^{1}:{2}", a, b, a ^ b);

//            int c = 255;
//            Console.WriteLine(“0~{0}(0x{0:X8}) : {1}(0x{1:X8})”, c, ~c);
//        }
//    }
//}

////할당 연산자 실습
//namespace AssignmentOperator
//{
//    class HelloWorld
//    {
//        static void Main()
//        {
//            int a;
//            a = 100;
//            Console.WriteLine(“a = 100 :{0}”, a);

// a += 90;
// Console.WriteLine(“a +=90 : {0}”, a);

// a -= 80;
// Console.WriteLine(“a -=80 : {0}”, a);

// a *= 70;
// Console.WriteLine(“a *= 70 : {0}”, a);

// a /= 60;
// Console.WriteLine(“a /= 60 : {0}”, a);

// a %= 50;
// Console.WriteLine(“a %= 50 : {0}”, a);

// a &= 40;
// Console.WriteLine(“a &= 40 : {0}”, a);

// a |= 30;
// Console.WriteLine(“a |= 30 : {0}”, a);

// a ^= 20;
// Console.WriteLine(“a ^= 20 : {0}”, a);

// a «= 10;
// Console.WriteLine(“a «= 10 :{0}”, a);

//            a »= 1;
//            Console.WriteLine(“a »= 1 : {0}”, a);
//        }
//    }
//}

////분기문 연습
//namespace IFElse
//{
//    class HelloWorld
//    {
//        static void Main(string[] args)
//        {
//            Console.WriteLine(“숫자를 입력하세요 :”);

// string input = Console.ReadLine();//문자열 입력을 받습니다
// int number = Int32.Parse(input);//문자열 입력을 받아 숫자로 파싱했습니다

//            if (number < 0)
//                Console.WriteLine(“음수인데다가”);
//            else if (number > 0)
//                Console.WriteLine(“일단 양수로 보이고”);
//            else
//                Console.WriteLine(“음수도 아니고 양수도 아니고 0이고”);

//            if (number % 2 == 0)
//                Console.WriteLine(“짝수이기도 함”);
//            else
//                Console.WriteLine(“홀수임”);
//        }
//    }
//}

////if문 중첩해서 사용하기
//namespace IFIF
//{
//    class HelloWorld
//    {
//        static void Main(string[] args)
//        {
//            Console.Write(“숫자를 입력하세요”);

// string input = Console.ReadLine();
// int number = Convert.ToInt32(input);//

//            if (number > 0)
//            {
//                if (number % 2 == 0)
//                    Console.WriteLine(“0보다 큰 짝수”);
//                else
//                    Console.WriteLine(“0보다 크고 홀수”);
//            }
//            else
//            {
//                Console.WriteLine(“0보다 작거나 같은 수”);
//            }
//        }
//    }
//}

오늘의 C# 공부

Wed, 16 Jan 2013 07:51:40 +0000

using System;

//nallable 형식
//namespace Nullable
//{
//    class HelloWorld
//    {
//        static void Main()
//        {
//            int? a = null;

// Console.WriteLine(a.HasValue);//값을 가지고 있느냐?
// Console.WriteLine(a != null);// 값이 널이 아니냐?

// a = 3;

//            Console.WriteLine(a.HasValue);//값을 가지고 있느냐?
//            Console.WriteLine(a != null);//값이 널이 아니냐?
//            Console.WriteLine(a.Value); //a 의 값을 내놓아라
//        }
//    }
//}

//var 형식을 공부해 보자
//namespace UsingVar
//{
//    class HelloWorld
//    {
//        static void Main()
//        {
//            var a = 20;
//            Console.WriteLine(“Type : {0}, Value : {1}”, a.GetType(), a);

// var b = 3.1414213;
// Console.WriteLine(“Type : {0}, Value : {1}”, b.GetType(), b);

// var c = “Hello, World!”;
// Console.WriteLine(“Type : {0}, Value : {1}”, c.GetType(), c);

//            var d = new int[] { 10, 20, 30 };
//            Console.Write(“Type : {0}, Value :”, d.GetType());
//            foreach (var e in d)
//            {
//                Console.Write("{0}", e);
//            }
//            Console.WriteLine();

// }
// }
//}

//// 기본 연산자 공부
//namespace ArtimaticOperation
//{
//    class HelloWorld
//    {
//        static void Main()
//        {
//            int a = 111 + 222;
//            Console.WriteLine(“a :{0}”, a);

// int b = a - 100;
// Console.WriteLine(“b: {0}”, b);

// int c = b * 100;
// Console.WriteLine(“c:{0}”, c);

// double d = c / 6.3;
// Console.WriteLine(“d:{0}”, d);

// Console.WriteLine(“22/7 = {0}({1})”, 22 / 7, 22 % 7);

// }
// }
//}

////증가 연산자와 감소 연산자
//namespace InDecOperator
//{
//    class HelloWorld
//    {
//        static void Main(string[] args)
//        {
//            int a = 10;
//            Console.WriteLine(a++);
//            Console.WriteLine(++a);

//            Console.WriteLine(a–);
//            Console.WriteLine(–a);
//        }
//    }
//}

//// 문자열 결합 연산자
//namespace StringConcatenate
//{
//    class HelloWorld
//    {
//        static void Main()
//        {
//            string result = “123” + “456”;
//            Console.WriteLine(result);

//            result = “Hello” + " " + “World”;
//            Console.WriteLine(result);
//        }
//    }
//}

////관계 연산자

//namespace RelationOperator
//{
//    class HelloWorld
//    {
//        static void Main(string[] args)
//        {
//            Console.WriteLine(“3>4 : {0}”, 3 > 4);
//            Console.WriteLine(“3>=4 : {0}”, 3 >= 4);
//            Console.WriteLine(“3<4 : {0}”, 3 < 4);
//            Console.WriteLine(“3<=4 : {0}”, 3 <= 4);
//            Console.WriteLine(“3==4 : {0}”, 3 == 4);
//            Console.WriteLine(“3!=4 : {0}”, 3 != 4);
//        }
//    }
//}

////논리 연산자 연습
//namespace LogicalOperator
//{
//    class HelloWorld
//    {
//        static void Main()
//        {
//            Console.WriteLine(“Testing &&….”);
//            Console.WriteLine(“1>0 && 4<5 : {0}”, 1 > 0 && 4 < 5);
//            Console.WriteLine(“1>0 && 4>5 : {0}”, 1 > 0 && 4 > 5);
//            Console.WriteLine(“1==0 && 4>5 : {0}”, 1 == 0 && 4 > 5);
//            Console.WriteLine(“1==0 && 4<5 : {0}”, 1 == 0 && 4 < 5);

//            Console.WriteLine("\nTesting ||…");
//            Console.WriteLine(“1>0 || 4<5 : {0}”, 1 > 0 || 4 < 5);
//            Console.WriteLine(“1>0 || 4>5 : {0}”, 1 > 0 || 4 > 5);
//            Console.WriteLine(“1==0 || 4>5 : {0}”, 1 == 0 || 4 > 5);
//            Console.WriteLine(“1==0 || 4<5 : {0}”, 1 == 0 || 4 < 5);

//            Console.WriteLine("\nTesting ! …");
//            Console.WriteLine("!True :{0}", !true);
//            Console.WriteLine("!False:{0}", !false);
//        }
//    }
//}

////조건 연산자
//namespace ConditionalOperator
//{
//    class HelloWorld
//    {
//        static void Main()
//        {
//            string result = (10 % 2) == 0 ? “짝수” : “홀수”;
//            Console.WriteLine(result);
//        }
//    }
//}

오늘의 C# 공부하기

Mon, 14 Jan 2013 07:26:11 +0000

using System;

/-
//형식 변환 연습

namespace IntergralConversion
{
    class HelloWord
    {
        static void Main()
        {
            sbyte a = 127;
            Console.WriteLine(a);

int b = (int)a;
Console.WriteLine(b);

int x = 128;
Console.WriteLine(x);

            sbyte y = (sbyte)x;//int였던 x 를 더 작은 sbyte 인 y 에다가 집어 넣어라.
            Console.WriteLine(y);//그랬더니 오버플로우 나서 -128이 된다.
        }
    }
}
*-

//형식 변환 연습 2
//namespace FloatConversion
//{
//    class HelloWorld
//    {
//        static void Main()
//        {
//            float a = 69.6875f;
//            Console.WriteLine(“a : {{{0}}}”, a);

// double b = (double)a;
// Console.WriteLine(" b : {0}", b);

// Console.WriteLine(“69.6875 == b:{0}”, 69.6875 == b);

// float x = 0.1f;
// Console.WriteLine(“x : {0}”, x);

// double y = (double)x;
// Console.WriteLine(“y : {0}”, y);// 쓰레기값이 들어간다!!

//            Console.WriteLine(“0.1 == y : {0} “, 0.1 == y);
//        }
//    }
//}

//부호 있는 정수 형식과 없는 형식 변환
//namespace SignedUnsingnedConversion
//{
//    class HelloWorld
//    {
//        static void Main()
//        {
//            int a = 500;
//            Console.WriteLine(a);

// uint b = (uint)a; //양수를 부호 없는걸로 캐스팅 해 봐야 같지
// Console.WriteLine(b);

// int x = -30;
// Console.WriteLine(x);

//            uint y = (uint)x;//음수를 부호 없는 걸로 캐스팅하면 문제 생김
//            Console.WriteLine(y);
//        }
//    }
//}

//부동 소수점 형식과 정수 형식 사이의 변환
//namespace FloattoIntegral
//{
//    class Helloworld
//    {
//        static void Main()
//        {
//            float a = 0.9f;
//            int b = (int)a;//float 을 int로 만들면 반올림의 자비따위는 없다.
//            Console.WriteLine(b);

//            float c = 1.1f;
//            int d = (int)c;
//            Console.WriteLine(d);

// }
// }
//}

// 문자열을 숫자로, 숫자를 문자열로
//namespace StringNumberConversion
//{
//    class HelloWorld
//    {
//        static void Main()
//        {
//            int a = 123;
//            string b = a.ToString();
//            Console.WriteLine(b);

//            float c = 3.14f;
//            string d = c.ToString();
//            Console.WriteLine(c);

//            string e = “123456”;
//            int f = int.Parse(e);
//            Console.WriteLine(f);

//            string g = “1.23456”;
//            float h = float.Parse(g);
//            Console.WriteLine(h);
//        }
//    }
//}

// 상수를 만들어 봅시다.
//namespace Constant
//{
//    class HelloWorld
//    {
//        static void Main()
//        {
//            const int MAX_INT = 2147483647;
//            const int MIN_INT = -2147483648;

//            Console.WriteLine(MAX_INT);
//            Console.WriteLine(MIN_INT);
//        }
//    }
//}

//enum을 만들어 봅시다.

namespace Enum
{
    class HelloWorld
    {
        enum DialogResult { YES, NO, CANCLE, CONFIRM, OK }

        static void Main()
        {
            Console.WriteLine((int)DialogResult.YES);
            Console.WriteLine((int)DialogResult.NO);
            Console.WriteLine((int)DialogResult.CANCLE);
            Console.WriteLine((int)DialogResult.CONFIRM);
            Console.WriteLine((int)DialogResult.OK);
        }
    }
}

//nallable 형식
//namespace Nullable
//{
//    class HelloWorld
//    {
//        static void Main()
//        {
//            int? a = null;

// Console.WriteLine(a.HasValue);//값을 가지고 있느냐?
// Console.WriteLine(a != null);// 값이 널이 아니냐?

// a = 3;

//var 형식을 공부해 보자
namespace UsingVar
{
    class HelloWorld
    {
        static void Main()
        {
            var a = 20;
            Console.WriteLine(“Type : {0}, Value : {1}”, a.GetType(), a);

var b = 3.1414213;
Console.WriteLine(“Type : {0}, Value : {1}”, b.GetType(), b);

var c = “Hello, World!”;
Console.WriteLine(“Type : {0}, Value : {1}”, c.GetType(), c);

}
}
}

C# 공부하기

Fri, 11 Jan 2013 07:44:54 +0000

using System;

–
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ConsoleApplication1
{
    class HelloWorld
    {
        static void Main(string[] args)
        {
           Console.WriteLine(“Hello,World!”);
           Console.WriteLine(“Helle,{0}!”, args[0]);
        }
    }
}

–
namespace IntegralTypes
{
    class HelloWorld
    {
        static void Main(string[] args)
        {
            sbyte a = -10;
            byte b = 40;

Console.WriteLine(“a={0}, b={1}”, a, b);

short c = -3000;
short d = 6000;

Console.WriteLine(“c={{{0}}}, d={1}”, c, d);

int e = -10000000; // 0이 7개지롱
uint f = 300000000; // 부호가 빠져서 0이 8개가 됨

Console.WriteLine(“e={0}, f={1}”, e, f);

long g = -500000000000; // 0이 11개나!
ulong h = 2000000000000000000; //부호가 없으니 0이 18개나 된다.

            Console.WriteLine(“g={0}, h={1}”, g, h);
        }
    }
}

–

–
//오버플로우 테스트

namespace Overflow
{
    class HelloWorld
    {
        static void Main(string[] args)
        {
            uint a = uint.MaxValue; // 언사인드 인트의 맥스 값을 집어 넣는다.
            a += 1; //맥스값에 1을 더한다

            Console.WriteLine(a);//a 를 출력한다.
        }
    }
} // 오버플로우. 값은 0이 나오게 된다.

//부동 소수점의 정밀도

namespace FloatingPoint
{
    class MainApp
    {
        static void Main(string[] args)
        {
            float a = 3.14159265358979323846f;
            Console.WriteLine(a); // float은 소수점 6자리 초과는 짤리게 된다.

            double b = 3.14159265358979323846;
            Console.WriteLine(b); // double 은 전부 다 표시해 준다.
        }
    }
}

//데시멀의 정밀도

–
namespace Decimal
{
    class HelloWorld
    {
        static void Main(string[] args)
        {
            float a = 3.141592653589793238462643383279f;
            Console.WriteLine(a);
            double b = 3.141592653589793238462643383279;
            Console.WriteLine(b);
            decimal c = 3.141592653589793238462643383279m;
            Console.WriteLine(c);
        }
    }
} //decimal은 매우 큰 수도 표현할 수 있다.

–

–
//문자를 받아서 좌아악 연결합시다.
namespace Char
{
    class MainApp
    {
        static void Main(string[] args)
        {
            char a = ‘안’;
            char b = ‘녕’;
            char c = ‘하’;
            char d = ‘세’;
            char e = ‘요’;

            Console.Write(a);
            Console.Write(b);
            Console.Write(c);
            Console.Write(d);
            Console.Write(e);//문자 입력은 줄을 바꾸지 않습니다.
            Console.WriteLine();//문자열 입력은 줄을 바꿉니다.
        }
    }
}

–

–
namespace String
{
    class HelloWorld
    {
        static void Main()
        {
            string a = “안녕하세요”;
            string b = “대마왕입니다.”;

            Console.WriteLine(a);
            Console.WriteLine(b);
        }
    }
}

–
//Object는 다양한 형식을 맘대로 받습니다.
namespace Object
{
    class HelloWorld
    {
        static void Main()
        {
            object a = 123;
            object b = 3.141592653589793238462643383279m;
            object c = true;
            object d = “안녕하세요”;

            Console.WriteLine(a);
            Console.WriteLine(b);
            Console.WriteLine(c);
            Console.WriteLine(d);
        }
    }
}

오늘의 shader 공부

Sun, 06 Jan 2013 21:38:47 +0000

간만에 정리하면서 해보니까 재밌다…

그동안 기본을 많이 소홀히 했구낭.

ShaderFX를 이용한, 그래픽 디자이너를 위한 기초 쉐이더 강좌 10강

Sun, 06 Jan 2013 03:53:11 +0000

이 글은
http://chulin28ho.tistory.com/53
에서 보시는걸 추천합니다 .

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

10강입니다!!! 이번 10강은 진짜 우여곡절이 … ㅠㅠ

NDC 스피커파티까지 끝내고 나서 누적된 피로로 계속 몸이 안좋았는데, 주말에는 경조사가 겹치고 평일에는 회식과 외부 약속이 겹치더니 결국 저번주 목요일날 급체하는 바람에 만 하루동안 사경을 헤맷습니다. 급체와 함께 몸살이 겹쳐서 와서요.

결국 겨우 안정된 다음에 한약방 갔더니 너무 피로해 있다고 쉬라고 하는군요. 쉬라니 ㅠㅠ 20대 때의 1/4 정도, 30대때의 절반 정도 강도로 일하고 있는데 쉬라니요 ㅠㅠ (하긴 30대 때는 그러다가 디스크 걸려서 몇 년 고생했었지 … )
여하간 덕분에 이제야 정신과 몸을 챙기고 10강을 쓰게 되었습니다. 크흑.

불쌍합니다.

뭐 각설하고…

이게 전체 예상된 일정의 절반쯤 되는 것 같아요. (아마도)
일단 빠르게 나가 보지요. 이번 시간에는… 드디어 알파가 들어간 불(파이야) 를 만들어 보겠습니다.

아마 이번으로 1부는 끝이 날 것 같아요!!! 1부가 뭐냐고요? 그건 ‘텍스쳐 컨트롤’ 하는 쪽이예요 !

이후부터는 좀 어려운 얘기가 나옵니다. ‘알파 소팅’ 에 대한 얘기가 나오구요. ‘라이팅 연산’ 에 대한 얘기도 나올 거예요.

사실 이게 프로그래머들이 배우는 hlsl하고는 완전 반대되는 과정의 느낌이긴 합니다만… 말씀드렸듯 이 강의는 그래픽 디자이너를 위해 특화된 과정의 강의니까요. 다릅니다 달라요.

셰이더로 이펙트를 어떻게 만드나요?

이펙트라는 것이 보통 ‘추상적인 무언가가 어떤 에니메이션을 보여주는 것’ 이니까요. 그리고 주로 알파 블렌딩된 이미지들이고요. 이런 이펙트를 만드는 방법은 보통 아래 방법을 사용하지요.

가. 파티클을 이용한다

일반적인 방법이예요. 파티클을 이용하면 여러 효과를 리얼하게 낼 수 있지요.
그치만… 무거워요… 아주 많이…
가볍게 하려면 꽤 기술이 필요하고 말이죠. 엔진 특성에 따라 가볍고 무겁고도 다르고..
그래서 제한적으로 사용해야만 하지요.

나. 텍스쳐 시퀀스를 이용한다

실무에서도 많이 쓰는 방법이지요. 텍스쳐 한 장에 에니메이션 되는 이펙트 그림을 나열해 놓고 차례로 보여주는 방식이예요. 시퀀스를 지원하지 않는 구식 엔진에는 IFL 파일이라는 것을 이용하기도 하지요.
옛날 2D 게임 만들때 흔히 사용했던 스프라이트 방식. 그거예요.
그치만 역시 텍스쳐를 너무 많이 사용한다는게 문제예요. 편하긴 해도 매우 큰 약점이지요.

다. 오브젝트 에니메이션을 이용한다

오브젝트들 실제로 구기거나, 스케일링 하거나 등등 해서 이펙트를 에니메이션 시키는 방법이예요.
불이나 폭파 이미지에서 직접적으로 이것만 이용해서 뭔가를 만들긴 좀 그렇고, 알파 에니메이션 등을 같이 사용하곤 하죠. 단점은 효과가 그렇게 좋지 못하다는 것. 아까 말했지만 혼자서 사용하기에는 무리가 있고 말이죠.

라. 텍스쳐 에니메이션을 이용한다

UV를 움직이거나 해서 애니메이션 시키는 방법이지요. 어찌보면 가장 많이 쓰이는 방법이고, 가벼우면서도 효과가 좋은 방법이긴 하지만, 표현할 수 있는 것이 한계가 있다는게 좀 단점이지요. 각종 꼼수를 동원하면 대부분 가능하긴 합니다만…

마. Shader 기술로 만든다

오늘 배울 겁니다. 불이나 폭파 에니메이션을 셰이더로 제어하게 되면, 가벼우면서도 효과가 좋은 이펙트를 만들 수 있어요. 물론 실무에서는 이것과 함께 복합적으로 사용하는 경우가 많지만, 어쨌거나 이 방법을 이용하면 텍스쳐 에니메이션의 장점을 그대로 흡수하면서 더 복잡한 응용이 가능하게 됩니다.

그리고 재미있게도, 오늘 얘기할, 셰이더를 이용해서 불을 만들기 위한 기술은 ‘이미 다 배우신 기술’ 이라는 겁니다. 후후후후후후후후후후 (오늘을 위해서 미리 다 계획해 놓는 치밀함!!!)

첫번째 불 이미지를 만들어 봅시다.

불을 만드려면 일단 불이 있어야 겠군요.

네 뭐 이런 불 그림이 있다고 칩시다 어설프지만.

이 불 그림을 입혀서 불을 만들어 봅시다.

… 불 그림을 입혔는데 말도 안되게 어설프지요. 우와 진짜 구려. ㅋ 망했다 ㅋ

… 이건 뭐 당연하게도 알파도 없는 불 그림을 입혀 놓았기 때문이지요.

불 모양을 만들기 위해서 일단 알파채널이 있는 이미지로 만들어 놓겠습니다.
아래처럼 말이지요.[각주:1]
알파 채널에 보면, 불 모양의 외각이 있는걸 볼 수 있습니다. 이걸 32bit TGA 파일이나 DDS DXT5 같은 파일로 만들어 놓으면 사용할 수 있게 되지요.

이렇게 해서 알파 채널도 연결했습니다. 불이 제대로 나옵니다.

야호 불이 만들어졌다 이걸로 끝 !@

야호 끝났다

… 이젠 오래 써먹은 개그니 아무도 안 속으시겠죠. 쳇.

넹 끝났으면 좋겠습니다만, 전혀 안끝났습니다. 지금은 그냥 ‘불 모양 그림’ 일 뿐이지요. 아무리 긍정적으로 봐라봐도 불이라 보기엔 무리가 좀 있습니다. [각주:2]

두 번째 불 이미지를 만들어 봅시다.

넹 그럼 이번에는 두 번째 불 이미지입니다.
그리기 상당히 귀찮아서 (… 나 그래픽 디자이너 맞나…) 파티클 일루젼에서 소스를 만들어서 대충 닦았습니다.
이 이미지의 특징은, 세로로 타일링 되는 이미지라는 것입니다. 세로로 주욱 이어져요.

세로로 붙여보면.. 요렇게요. 이어지죠. 주우우우ㅇ우우우우우우웅우우ㅜ우ㅜㅇ욱.

만드는 법이요? 그래픽 디자이너라면 이정도는 다 해요.
프로그래머분들이 클래스 만드는 수준.

그렇다면 그런 줄 아세요.

자 이거 가지고, 아래처럼 만들어 봤습니다.
응? 어디서 많이 보던거 아니예요???

뭔지 모르시겠는 분은 7강 http://www.gamedevforever.com/120 을 복습하세요.
UV가 세로로 흐르는 거잖아요!!!

이렇게요!!!

다시 말씀드리지만
전 이미 다 알려드린 기술만 사용해요 후후후
왜냐면 쉬워야 하니까요. 쉽게 쓰기로 작정한 거니까요.
제가 여기에서 WVP(World View Projection) Matrix 라던가 dot / cross 공식따위를 증명하고 앉았으면 다들 도망가실 거잖아요 … (어차피 설명할 수 있을지도 잘 모르겠지만)

아마 이러시겠죠. 저도 그랬었었었어요.

아차! 이것도 알파를 안 만들었군요.
여기의 알파는 좀 특이한 모양으로 만들어 보았습니다. 물론 위 아래 타일링 되는 것은 동일.

이걸 연결하면 이렇게 되지요.
마치 용암이 구불구불하게 흘러가는 듯한 이미지가 되었습니다.

흠? 두 이미지를 가지고 뭘 하려는 걸까요? 후후후후후후후후

이제 다음 단원에서 그 비밀이 드러납니다.

후후후후후후후 기대돼라

간단하게 불을 합성해 봅시다.

두 이미지를 만들어 봤습니다. 이제 이걸 합성해 보도록 하지요.
지금 만든 두 셰이더를 동시에 나열하면 이런 모양이겠죠.

1번과 2번 텍스쳐가 있고, 2번 텍스쳐는 UV 조작을 통해 위로 흘러가고 있었습니다.[각주:3]

자.. 일단 1번 텍스쳐를 최종 출력에 연결을 해 보지요.

그럼 이렇게, 단원 2에서 봤던 것과 같은 이미지가 나옵니다.
다음은 어떻게 해야 할까요?

이제는 충분히 익숙해지셨을, Math/MathOperator 를 이용해서 두 이미지를 곱했더니, 좀 더 그럴듯한 불 이미지가 되었습니다.

얘네 둘을 곱하는것은, 포토샵에서 두 레이어를 Multiply 하는 것과 같으니까요.

포토샵에서 보면 이런 거겠죠. 레이어 두 개를 Multiply로 섞는다는…
두 이미지가 잘 섞였군요. 그럼 플레이하고 동영상을 볼까요.

동영상 압축 특성상 외각이 좀 지저분하게 나오는데요. 저정도까지는 아닙니다.

불 그림이 흘러가는데, 아래쪽은 첫 번째 텍스쳐의 노랑때문에 좀 밝아 보이고, 윗쪽은 좀 어두줘집니다. 이런 느낌은 그림만 좀 더 잘 만들면 괜찮습니다.

그래도 음.. .뭐 일단 좀 속도만 느려지면 불이 올라가는 것 처럼 보일 것 같긴 한데.. 뭔가 좀 이상합니다.
뭐가 이상할까요? 아니 이상하다 못해 너무 구립니다.

외각 말이죠 외각. 외각이 이상하잖아요
불이 … 그림만 올라가고 출렁출렁 움직이는 느낌이 없잖아요?!?

그래서 만든게 두 번째 텍스쳐의 알파 채널입니다.

이번엔, 이렇게 두 알파 채널도 같이 곱해 줘서 출력해 줘 봅시다.

포토샵에서는 ‘알파채널을 Multiply하기’ 같은 레이어 옵션이 없기 때문에 그냥 알파 채널을 이미지처럼 만들어서 설명해 봤습니다. 두 알파 채널이 이렇게 섞인다는 거지요.

두 알파 채널이 곱셈(Multiply) 로 섞이기 때문에,
검은색(0) 이 있는 부분은 흰색(1) 과 곱해지더라도 검은 색이 ( 0 * 1 = 0 ) 나오게 됩니다.[각주:4]

대충 짐작하시겠지요? 알파 채널도 어차피 RGB와 같은 채널 중 하나인 A 채널이기 때문에,
곱하면 그냥 같이 곱해집니다.

그럼 최종 결과물을 볼까요? [각주:5]

(역시 동영상의 압축에 의한 잔상때문에 외각이 지저분하게 나오네요… 제길)

* 주의 : 맥스 2009 버전에서는 플레이 버튼을 누르면, 외각의 알파가 저렇게 갱신되지 않고 계속 누적이 되어서 쌓이는 모습을 발견했습니다. 맥스 자체가 이런거 하려고 만들어 놓은게 아니라서 그런건 이해하겠습니다만… 맥스 2010 을 사용하시면 아무 문제없이 잘 됩니다.
맥스 2009에서는 플레이 버튼으로 보시지 마시고, 타임 컨트롤 바를 수동으로 조금씩 움직여서 보시는 것을 추천합니다.

네 좀 지저분하게 찍혔지만, 불이 이제 정형적인 모습을 가지지 않고 ‘일렁이듯이’ 움직인다는 것을
볼 수 있습니다.

이제 불의 소스가 하나 완성된거지요. 텍스쳐 UV 에니메이션으로는 하기 힘든 모양을, 이렇게 간단한 셰이더를 이용해서 만들 수 있습니다. 물론 이게 끝이 아니지요. 여기에 더 추가되는 작업을 해야 그럴듯한 불 이펙트가 나오게 될 겁니다.
예를 들면, 파티클을 살짝 써서 불똥을 표현해 준다던가, 굴절 셰이더를 쓰는 평면을 하나 더 만들어서 뒤 배경이 굴절되게 한다던가, 아주 밝은 부분 레이어와 위로 올라가는 연기 레이어를 추가로 제작해서 배열한다던가 하는 식으로 말이지요.

어쨌건, 가장 중요한 부분을 끝냈으니 나머지는 좀 더 쉬울 겁니다

자 …. 이렇게 해서 이미지 컨트롤 파트를 마치겠습니다!!! 다음 시간에는…

….

라이트를 할 것인가 알파 소팅을 할 것인가 고민좀 하고 돌아오겠습니다!!!

따라해 보실 분을 위한 이미지 소스는 여깄습니당

A.tga

B.tga

그래픽 하시는 분들은 다 아시는 얘기 : RGB 이미지는 알파 채널 이미지랑 다르게 전체가 불 이미지 스러운 칼라로 되어 있지요? 만약 위에 나온 예제처럼, 외각을 검은색으로 채웠다면 나오는 이미지에도 검은 색이 어느정도 묻어 버리기 때문에 저렇게 만듭니다. [본문으로]
못그려서 그런거라고 하지 마세요. [본문으로]
흐르는 속도를 바꾸시려면 Time에다가 일정 숫자를 곱해서 출력하시면 되겠지요 대략 경험상 여기에서는 0.25 정도를 곱하는게 좋겠더군요 [본문으로]
곱셈은 둘중 하나가 0이면 0이 되고, 덧셈은 둘 중하나가 1이면 1이 된다라고 생각하시면 편합니다. (덧셈은 좀 더 깊은 세계가 있지만 일단 여기까지..) [본문으로]
불이 흐르는 속도를 1/4 로 줄였습니다. 어떻게 하시는지 다 알지요? [본문으로]

아이노트 블루투스 헤드셋 BT-555 리뷰

Thu, 03 Jan 2013 19:59:28 +0000

PDB-MD 슬라이드 멀티독 리뷰

Mon, 26 Nov 2012 02:03:32 +0000

포은아트홀 '레미제라블' 보고 왔슴다.

Fri, 23 Nov 2012 12:29:22 +0000

세계 4대 뮤지컬이라는 거창한 수식어를 달고 있는 ‘레미제라블’ 보고 왔습니다.
회사에서 이벤트를 열어서, 참여한 사람들에게 ‘반드시 뮤지컬을 보는 조건’ 으로 자금을 지원해 줬거든요 :)
뭐 뮤지컬 매우 좋아하니까… 그치만 너무 비싸니까… 이런 이벤트 너무 좋아요.

일단 포은아트홀은 용인쪽에 있고 생긴지 얼마 안되는 곳입니다.
덕분에 매점같은건 커피집 하나와 편의점 하나 외엔 아무것도 없어유.

그 외의 시설은 나쁘지 않은 편입니다. 아참 주차장이 조금 작다는 것 정도?
특히 의자가 아유 그냥 … 허리를 탄탄하게 받쳐주는게 뮤지컬 극장 의자 중에서는 최고인 것 같습니다. 물론 뭐 극장 의자같은 편안함과는 거리가 있지만 말이죠. ㅋ

용인에서 프리뷰 공연은 25일인가? 에 끝나고 , 본공연은 내년 4월에나 서울에서 볼 수 있을 듯 합니다.

주연 정성화님. 다른 분들은 누군지 알던데 전 뭐 연예인은 아이유정도밖에는 모르니까 ㅡ,.ㅡ 남자연예인은 더 몰라유

어쨌거나 원캐스팅!!! 대사 전체가 노래로만 되어 있고 장발장은 사람도 들쳐 매고 막 그래야 하는데 이 가혹한 공연에서 원캐스팅!! 어마어마하더군요.

그래서 그런지 모든 출연진의 실력들이 ㅎㄷㄷㄷㄷ 소싯적에 음악 쬐끔 건드려 봤다고 까불던 입장에서 볼때 이 괴물들은 뭐야… 수준의 …

특히 이 아역들이 저는 아주 훌륭했어요. 그중에 저 가브로쉬 역 한 친구가 최고. 원캐스팅은 아닌 것 같은데 역시 실력이 어마어마… 어떤 예술이던지 이런 괴수분들 만나면 존경스러울 수 밖에 없어요.

정성화님의 장발장 연기도 부족함이 없었는데 자베르가 더 멋져 버린게 함정 ㄷㄷㄷ 아니 인간적으로 너무 만화 캐릭터처럼 나와 ㄷㄷㄷ 저게 사람이여 만화여 ㄷㄷㄷ

어쨌건 마눌님은 감동의 눈물을 흘릴 정도로 만족하셨으니 저도 만족.
지금까지 본 뮤지컬중 최고는 아직까지 지킬엔 하이드였는데 이건 다른 의미로의 최고로 기억될 듯 합니다.

미리 사전조사해 갔을 때에는 음향이 이상해서 대사가 하나도 안들린다고 하길래 걱정했는데,
뮤지컬 전문가인 이실장 말에 의하면 처음에는 외국인이 엔지니어링 하는 바람에 한국어에 대한 이해가 없어서 그랬다는 듯. 막상 들어보니 엄청나게 또렷하게는 아니지만 꽤 들을만 했습니다.

그래도 만약에 보신다면은 콘서트 버전을 보고 간다던가 해서 예습을 하고 가는 쪽을 추천해요.
아무래도 노래다 보니까 전달이 약간 잘 안되는 경우도 있고, 인터미션 포함 3시간 안에 이정도 규모의 스토리를 진행하려니 진행이 엄청 빠를 수 밖에 없게 될만 해요.

중간에 갑자기 10년씩 팍팍 건너뛰고 그러니까요. 아역이 갑자기 막 늙고 막 이래. 예습만 조금 해 가면 재밌게 볼 수 있을듯. (저는 이실장한테 빌려서 DVD를 한 4번쯤 보고 가니까 음악까지도 귀에 착착 붙고 짱 좋더군요 )

물론 준비 안해갔다고 하더라도 이해 못할 수준은 아닙니다. 디테일을 좀 놓칠 뿐. 그리고 대사에 집중하다보면 넓은걸 못불 수 있으니까… 예습 안해간 아이들도 끝까지 집중해서 눈을 떼지 못하고 보더라고요. (아차.. 장발장 얘기는 아는구나…)

특히 세트의 다이나믹함은 꽤 마음에 듭니다. 엄청나게 커다란 세트가 날렵하게 휙휙 바뀌는 것이 꽤 멋져요
저희는 앞열 3째줄에서 봤습니다. 포은아트홀은 특성상 가능한한 앞에서 보는게 좋겠더구만요.

샤롯데는 오케스트라가 무대 밑으로 들어가 있는 분위기였다면, 포은아트홀은 오케스트라가 그냥 무대 앞에 위치하고 있는 느낌입니다. 덕분이 3열에서 봤는데도 가깝다는 느낌은 전혀 없었어요. 오히려 1열에서 보고 싶었달까.

라이브 공연 DVD와 CD를 샀습니다 히힛.

어쨌건 후회없을만큼 멋진 뮤지컬인건 확실했습니다. 대 서사시를 본 느낌이랄까.

지난번 제주도 여행

Mon, 19 Nov 2012 10:09:14 +0000

가족사진 잘 안올리는데 이유가 있어서 특별히 ㅋㅋㅋ
그래도 ‘리뷰좀 찌그린거’ 에 캠핑카 여행기 같은걸 보면 군데군데 보여요.

인상 펴 이녀석들 ㅋㅋㅋ

렌트카. 저거 괜찮더군요

이마가 빛납니다.

별로 신나하지 않는 표정이지만 신난거

잇힝 제주도 좋아

이번 게시물은 딸사진 전용 게시물입니다.

다리 길당

유리박물관은 밤에가야 제맛

이놈의 강아지들 ㅋ

간혹 나오는 자연스러운 표정들

비오는 사려니 숲길

만장굴이던가..?

photoshop eclipse tour 2012

Wed, 07 Nov 2012 21:57:01 +0000

갔다왔습니다. 아도브 이클립스 투어.

포토샵을 쓰면서 먹고 산지는 거진 십오년이 되어 가는 것 같은데,
생각해 보니 포토샵 관련 세미나는 한 번도 가본 적이 없었더군요.

게다가 최근에는 포토샵을 쓸 일이 매우 제한적이 되면서, 또한 너무 쓰던 기능만 편안히 쓰다 보니
최신의 포토샵에 어떤 기능이 더 들어갔는지, 최근과 앞으로의 포토샵의 발전 추세는 어떤지 궁금해서 바쁜 와중에도 꼭 가보고 싶어서 갔다왔습니다.

또한 ‘포토샵 세미나’ 라는 것은 도대체 어떻게 진행하는지도 보고 싶었구요.
이런 식의 특정 프로그램의 세미나는 자칫 잘못하면 단순한 광고가 되어 버릴 수도 있기 때문에 MS 등에서도 주로 무료강연으로 만들고 경품을 잔뜩 뿌린다던가 하는데, 이 강연은 그정도로 경품을 뿌리는 것도 아니면서 꽤 비싼 유료강연이었거든요. (정말 괜찮으면 회사에 추천한다던가)

꽤 비싼 유료강연임에도 불구하고 사람들이 득시글대더군요.
슬쩍 봤을 때에는 게임쪽보다는 출판이나 사진쪽, 혹은 개인 아티스트들의 비중이 높아보였습니다.

인사말과 함께 강연이 시작됩니다.

처음에는 KGC 처럼 포토샵에 대한 여러 전문가가 나와서 강연을 하는 방식인가 했더니, 강연장은 하나이고 기조강연과 초청강연을 제외한 나머지 세션은 전부 아도브 크리에이티브 디렉터와 에반젤리스트 두 명이 번갈아 나와서 신기능을 소개하고 요령을 가르쳐 주는 교육이더군요. ‘강연’ 이라기 보다는 ‘강의’ 에 가까운 것이라는걸 처음 알았습니다 .

그렇지만 실제로 강의를 들어보면, 그냥 강의와는 좀 다른 느낌입니다. 훨씬 더 떠들석하고, 시트콤스럽달까요
이게 뭘까 하다가 상품으로 받은 옷과 함께 받은 USB에 씌여 있는 말을 보니 확실히 알겠더군요.

“러셀 브라운 (주: 강연자)의 쇼”

네 그렇습니다. 이건 강의나 강연보다는 “쇼” 에 가까운 행사였습니다.

포토샵과 라이트룸의 신기술을 소개하고 응용법을 재미있게 알려주는 쇼 말이죠

상품은 트위터로 질문올리기 대회를 했는데 거기서 우수질문에 뽑혀서 받은 것이라는…

하여간 그래서 사실 강의 내용은 완전히 퍼펙트한 전문가보다는 ‘파워 유저’ 정도의 수준에 머뭅니다. 기대했던 것보다는 낮아서 조금 실망.. 그치만 이런 툴은 파워 유징도 사실 중요하니까요.

하루 종일 두 명의 강연자가 번갈아서 강연하는데, 매우 인기가 있어서 쉬는 시간마다 사인 행렬이 열립니다.

물론 재미있는 쇼 분위기를 빌린 강연이라는건 인정하지만, 그래도 아도브에서 이 정도를 유료강연으로 해야 할 이유가 있는가 … 라는 생각이 들긴 했습니다.

물론 유료강연으로 하면 수익을 얻을 수 있다는 장점과 함께, 관객의 수준을 제어할 수 있다는 장점이 있습니다. 중고등학생이 잔뜩 모여 들어서 자리만 차지하고 있는 것 같은 일을 방지할 수 있으니까요.

그래도 테이블도 없는 강연장 자기 자리에서 나눠준 도시락을 무릎 위에 불안하게 올리고 먹어야 하는 점심식사는 불만이었습니다.

정작 중요한 강연 내용을 이제 말해보자면, 포토샵 6에서 가장 강력하게 주장하고, 인상깊었던 부분은 아래와 같습니다.

강력한 파노라마, HDR 합성 / 보정 기능을 사용하세요.
스마트 오브젝트를 다양하게 이용하세요

그 외에도 새로운 보케와 작은 RAW 팁 , 포토샵에서의 동영상 편집 등 여러 가지 주제들을 마치 강연이 아닌 공연을 하는 방식으로 진행되었습니다. (강의 진행에서 배울 점이 있더군요)

파노라마 합성 기능은 다른 것 보다 광각으로 인해 미묘하게 휘어진 이미지들을 어떻게 세워줄 것이냐… 에 대한 접근으로써, 간단한 가이드라인을 세워주는 것 만으로 휘어진 이미지가 똑바로 서게 됩니다. HDR 합성은 기존의 툴보다 더욱 개량된 방식으로, 더욱 전문가스럽게 만드는 요령을 알려주었고 …

스마트 오브젝트라는 것이 무엇이고, 어떻게 사용해야 하는 것인지를 알려주었습니다.

스마트 오브젝트 (스마트 레이어) 란, 일종의 ‘원본을 저장하고 있는 레이어’ 의 개념으로, 수정작업을 하다가 중간에 복구 / 변형이 가능한 정보를 모두 품고 있는 보다 강력한 레이어 개체를 의미합니다.

이 show의 내용이 동영상으로 들어 있는 DVD를 받았습니다. 강의 내용이 거의 다 들어 있네요 .

안가고 이것만 봐도 똑같을듯

결론적으로 얘기하면, 포토샵의 신기능은 ‘사진 합성과 인쇄물 편집’ 에 중점을 두고 있는 것을 알 수 있습니다. 물론 게임이나 다른 매체를 위한 툴로도 여전히 강력하지만, 아도비가 중점을 두고 개발하고 있는 것은 역시 포토샵이란 이름에 걸맞는 ‘고급 사진 편집 툴’ 이란 것이지요.

덕분에 PC의 자원도 많이 사용하게 되고, 그 때문에 무거워져서 회사에서 CS3 버전을 선호하시는 분들도 많은 것으로 알고 있습니다. 강연 듣고 나서의 생각은, 과연 최신 버전의 포토샵은 우리에게 그다지 절실하지 않을 만 하구나… 라는 것 정도였습니다.

[KGC2012]Multi Platform Full 3D MMORPG 만들기- "삼국지를 품다"의 테크니컬 아트

Thu, 11 Oct 2012 22:22:39 +0000

multi plaform Full3D MMO 만들기 “삼국지를 품다"의 테크니컬 아트 from jpcorp

PT 자료입니다…만 아이프레임이 지원 안되는군요 흐음.

multi plaform Full3D MMO 만들기 “삼국지를 품다"의 테크니컬 아트 from jpcorp

NuRi’s Tools - iframe 변환기

NuRi님의 변환기로 변환했습니다. 짱 좋네요!!!!
감사합니다!!!

삼국지를 품다 출사표 영상

Thu, 11 Oct 2012 18:09:48 +0000

이제 곧 오픈이군요. 들인 시간만큼 잘 돼야 할텐데.
그나저나 이건 또 언제 만들었데.

게임에 대해서 한 가지 말할 수 있는건
진짜 딱 들인 시간을 이 게임 만드는데 썼다고 말할 수 있겠네요.
중간에 다 뒤엎고 첨부터 시작하고 … 이런거 없었다능.

인재 채용

Sat, 06 Oct 2012 16:00:20 +0000

누군가에게 ‘인재 채용하는 철학을 좀 말해봐라’ 라는 요청을 받아서 써봅니다.

인재 채용이라… 전 오히려 신입을 분위기 쇄신을 위해 뽑거나 하는 것을 별로 좋아하지 않습니다. 팀에 오래 된 사람이 많아서 매너리즘에 빠졌다면 그 원인을 찾아서 그렇지 않게 되도록 해야지, 임시 방편으로 반짝 신입 효과를 내 봤자 1년도 안되어서 그 신입도 같이 매너리즘에 빠지게 되거든요. -ml:namespace prefix = o ns = “urn:schemas-microsoft-com:office:office” /-ml:namespace prefix = o /-ml:namespace prefix = o /-ml:namespace prefix = o /-ml:namespace prefix = o /

오래 된 사람이 매너리즘에 빠지는 것은 지금 현재에 만족하기 때문입니다.

즉 발전하거나 도전할 이유가 없거나, 발전하거나 도전할 길이 막혀 있을 때 사람은 매너리즘에 빠지게 됩니다.

내부적인 프로젝트 팀끼리의 정치가 있는 것도 아니고, 회사가 망할 것 같지도 않고, 개인이 자신의 역량을 최대한 쥐어짜야 할 이유도 그렇게 많지 않을 경우에, 회사가 익숙해지면 말 그대로 그냥 ‘보통 수준의’ 일만 하면 되는 B급 인재로 살아가게 됩니다.

물론 B급 인재가 필요하긴 합니다. 모두 A 급 인재가 될 수는 없지요. 그렇지만 주의할 것은 B급 인재가 장악하는 팀의 분위기입니다. 팀 자체가 B급의 분위기로 흘러가게 된다면 거기에는 A급 인재가 들어올 수가 없습니다. 어디까지나 A급이 주도할 수 있도록 분위기를 만들어 주는 것이 팀장의 가장 큰 임무라고 생각되며, 그러기 위해서 팀장 자체가 A급 인재가 먼저 되어야 한다고 생각합니다.

B급 인재도 물론 필요합니다. 그렇지만 게임을 20년간 만들면서, 그 B급 인재들이 지금 어떻게 되어 있는지를 보면 매우 유감스럽기 그지없습니다.

약 10여전 전에 A급으로 치부되던 아티스트가 있었습니다. 그 아티스트는 현실에 만족하고 안주했지요. 그리고 다른 회사에서 계속 같은 수준의 일을 했습니다.

그런데 그 회사가 망했습니다. 졸지에 그 사람은 회사를 옮겨야 할 상황에 처했지요. 그리고 10년 전의 AD인 저한테 연락이 왔었습니다.

저는 그 사람의 포트폴리오를 봤지요. 10여년 전의 실력 그대로더군요. 이미 시장은 아주 빠르게 바뀌어서, 10여년 전의 생각과 실력을 가진 사람은 지금 신입만도 못한 수준입니다. 당연히 그 사람을 받을 수 없었지요. 지금은 나이도 많은 그 사람은 , 아주 안 좋은 회사에 들어가서 위태위태하게 일하더군요.

비록 이건 그 사람의 문제라고 할 수 있겠습니다만, 10여년 전의 팀장인 저에게 아무런 관련이 없다고 말할 수 있었을까요? 혹시나 제가 그 사람을 현실에 안주해도 되도록 교육시켰던 아니었을까요?

저는 당장의 팀의 분위기와 프로젝트를 위해서가 아닌, 그 사람의 미래를 위해서라도 A급 인재들이 주도하는 회사를 만들려고 합니다. B급의 사람들도 일할 수 있지만 그 사람들이 계속 A급을 보면서 자극을 받을 수 있고, 오래 된 사람들이 매너리즘의 대명사가 아닌, A급의 대명사로 불리는 팀을 만들고 싶습니다.

예전에는 A급의 팀원이라고 하는 것이 단순히 실력이 좋은 사람을 뜻한다고 생각했었습니다. 그렇지만 지금 보니 그런 사람들은 A급의 사람들이 아니더군요. 위에 설명했듯, 10년 후에도 A급이 될 수 있는 사람, 지금은 아직 원석이라고 하더라도 , 그런 사람을 뽑아야 합니다.

제가 보는 A급의 인원의 기준은 아래와 같습니다.

현재의 실력이 충분히 좋은가?

신입에게 최고를 바랄 순 없겠지만, 적어도 자기 분야의 일을 충실히 이끌어 나갈 수 있을 만한 실력은 가지고 있어야 합니다.

그렇지 않으면 말만 번지르르한 사람이지요. 그리고 여태까지 어떻게 살아왔는지에 대한 반증이기도 합니다.

지식의 공유정신이 강한가?

가끔 회사를 자신의 실력과 연봉을 높이기 위한 디딤돌 정도로 인지하는 사람들이 있습니다. 그런 사람들은 자신의 평가에 민감하고, 자신의 결과물을 공유하기 싫어하며, 모든 데이터를 자신 혼자서 독차지하려 합니다. 이런 사람들은 얼핏 보면 1번을 매우 강하게 충족해서 실력이 좋아 보일 수 있습니다만, 오히려 이런 사람이야말로 빨리 내보내야 할 직원입니다.

사실 지식은 공유되면서 발전합니다. 자신 혼자의 지식은 어차피 단체의 지식이 되지 못합니다. 그리고 지식을 공유해 보면, 자신이 얼마나 제대로 모르고 있는지를 알게 됩니다. 제가 NDC나 KGC 발표를 독려하는 이유도 이것입니다. 지식의 보안이요? 어차피 1-2년만 지나면 구식이 되어버릴 알량한 지식들입니다. 전세계를 대상으로 보면 아주 미미한 지식입니다. 그런 분위기가 A급의 직원이 좋아하는 분위기가 됩니다.

또한 이런 사람들의 특징은, 우리 회사 내에서 안주하지 않고 전세계적인 추세는 어떤가, 앞으로는 어떻게 변해야 하는가에 대한 관심도 충분합니다. 자신이 kgc에 발표하러 나가서, 전 세계 추세에 맞지도 않는 헛소리를 하면 어마어마하게 창피하겠지요. 늘 깨어 있는 사람이 필요합니다.

10년 후의 미래 계획이 있는가?

전형적인 B급 인재들은 ‘10년 후에도 지금 이 자리에서 그대로 똑같은 일을 하길’ 바랍니다. 하지만 조금만 생각해 보면, 우리가 10년 전에 하던 일과 지금 하던 일을 같은 수준에서 하려면 얼마나 공부를 하고 따라잡아야 하는지 알 수 있습니다. 그렇지만 B급 인재들은 ‘지금과 똑같은 수준으로 일하면서 10년 후에도 일하게 해줄 ’ 회사를 찾는 것입니다. 10년 후의 계획이 블리자드인 사람은 적어도 영어를 꾸준히 공부할 것이고, 10년 후의 계획이 대학교수인 사람은 밤새 논문 준비를 할 것입니다. 10년 후의 계획이 개발 이사인 사람은 어떻게든 개발이사가 되기 위한 준비를 할 것입니다. 10년 후를 구체적으로 계획하면서 늘 움직이는 사람이 A급 인재입니다. 이런 사람들은 여유 시간에 할 일 없이 뒹굴거리는 것을 증오합니다. 만약 이런 사람이 회사의 미래에 관심을 가지게 된다면 그 효과는 엄청날 것입니다.

이런 사람들이 고참인 팀이 있다면 어떨까요? 매너리즘에 빠진 팀에 신입이 들어오게 된다면 그 신입은 포기해서 적응하거나 실망하게 될 것이지만,

이런 활기찬 팀에 A급의 신입이 들어오게 된다면 신입은 하루하루가 존경스러운 사람들 속에 둘러쌓여서 일하는 행복한 기분이 될 것입니다.

활기찬 A급이 요직에 있지 않고 매너리즘에 빠진 집단을 우리는 ‘공무원’ 이라고 흔히 말합니다.
(이 말이 공무원 분들을 비하하는 의미가 있다라는 것을 알고 있습니다. 당연히 공무원분들 중에서도 미래와 나라를 생각하시면서 열심히 일하시는 분들도 많지요)

저는 적어도 10년 후에 저보다 잘되었거나,
10년 후에도 저랑 같이 일할 수 있는 수준의 사람을 뽑고 싶습니다.
저도 10년 후에는 완전 다른 수준의 사람이 되어 있을 거구요. (누가 40대에 개발자 생명 끝난댔어)

실제로 그런 사람들이 몇 명 있는데, 제가 다 자랑스럽고 기쁘더군요.

"TEXCOORD" has too big of a numeric index (8) 에러

Thu, 04 Oct 2012 17:31:51 +0000

http://forum.unity3d.com/threads/56180-Strumpy-Shader-Editor-4.0a-Massive-Improvements/page23

Originally Posted by duke

Getting this:
“Shader error in ‘ShaderEditor/EditorShaderCache’: Program ‘vert_surf’, output semantic attribute “TEXCOORD” has too big of a numeric index (8) at line 161”

In 3.0, not 3.1.

edit: Told the shader to be transparent - problem fixed.

Duke sent me a PM about this, I’ll post the reply here for anyone that runs into similar issues. The breakdown is that by using the world reflection node the vertex interpolator count was exceeded. Here is the explanation:

So in shader land you can have a certain number of varying outputs from the vertex shader into the pixel shader. In shader model 2 this is 8 (+2 color interpolators), SM3 it is 10, and SM4 it is 16 (which can be expanded to 32 via geometry shaders).

Now if we look at the structure that the vertex shader was generating for output into the pixel shader:

Code:

1. struct Input {

 - float4 screenPos;

 - float2 uv_Bump2;

 - float3 worldRefl;

 - float3 viewDir;

 - INTERNAL_DATA

 - };

Because you are using the world reflection node INTERNAL_DATA is required (which is a whole matrix worth of interpolators!). Unity (on internal shader compilation) will pad out this data structure out even more with things like shadow data, and lightmapping data depending on which shader permutation is being compiled.

Looking at the error message: ‘Shader error in ‘ShaderEditor/EditorShaderCache’: Program ‘frag_surf’, cannot locate suitable resource to bind parameter “_ShadowCoord” at line 152’ it seems like something has exceeded the allowed interpolator count.

The way to work around this issue is to reduce the number of interpolators you are using. Step one for me would be to remove the World Reflection node and replace it with a Vertex Reflection node. It is much simpler (you can’t modify it by the normal from the normal map ) but it will only use one interpolator register instead of the 4 I think you are using now.

This issue can also be run into if you have too many unity texture samples because the offset UV’s / tiling / scaling is calculated via the texture matrix in the vertex shader and passed through as an interpolator. There is a node that can help with this (Mesh UV), but it bypasses unity’s nice material stuff. If the texture coordinates were calculated in the pixel shader this would not be so much an issue, but this is out of the shader editors control.

If you are curious as to why this does not happen with transparent shaders it is because they don’t calculate the same permutations of shaders that an opaque object does. In other words you kind of got lucky that you didn’t go over the interpolator count before.

스승님의 테스트 코드 2

Thu, 20 Sep 2012 11:33:52 +0000

[오전 11:32:35] Dustin Lee: Shader “Custom/NewShader2” {
Properties {
_MainTex (“Base (RGB)”, 2D) = “white” {}
}
SubShader {
Tags { “RenderType”=“Opaque” }
LOD 200

CGPROGRAM
#pragma surface surf Lambert

sampler2D _MainTex;

struct Input {
float2 uv_MainTex;
};

void surf (Input IN, inout SurfaceOutput o) {
   half4 c = tex2D (_MainTex, IN.uv_MainTex);
   o.Albedo = c.rgb;
   o.Alpha = c.a;
}
ENDCG

        GrabPass {
            Name “PREPASS”
            Tags { “LightMode” = “PrePassFinal” }
        }

Pass {
            Name “PREPASS”
            Tags { “LightMode” = “PrePassFinal” }
   Blend One One
   SetTexture[_GrabTexture] { combine texture }
   SetTexture[_LightBuffer] { combine texture }

}
}
FallBack “Diffuse”
}

우와 공부할거 늘어만 간다

테스트 코드 / 스승님

Thu, 20 Sep 2012 11:16:15 +0000

[오전 11:15:06] Dustin Lee: Shader “Custom/NewShader2” {
Properties {
_MainTex (“Base (RGB)”, 2D) = “white” {}
}
SubShader {
Tags { “RenderType”=“Opaque” }
LOD 200

        GrabPass {
            Name “PREPASS”
            Tags { “LightMode” = “PrePassFinal” }
        }

CGPROGRAM
#pragma surface surf Lambert

sampler2D _MainTex;
sampler2D _GrabTexture;

struct Input {
float2 uv_MainTex;
};

void surf (Input IN, inout SurfaceOutput o) {
   half4 c = tex2D (_MainTex, IN.uv_MainTex);
   half4 d = tex2D (_GrabTexture, IN.uv_MainTex);
   //o.Albedo = c.rgb;
   o.Alpha = c.a;
   o.Albedo = d.rgb;
}
ENDCG
}
FallBack “Diffuse”
}

다음 할 일 .

일반 패스 {}
서피스 셰이더

이 구조가 가동되는지 테스트 해 보자. 스승님은 되는 걸로 알고 있다고 …

surface shader 컴파일 파라미터

Fri, 07 Sep 2012 14:24:33 +0000

alpha - Alpha blending mode. Use this for semitransparent shaders.* 알파 블렌딩 모드. 반투명 작동* alphatest:VariableName - Alpha testing mode. Use this for transparent-cutout shaders. Cutoff value is in float variable with VariableName.* 알파 테스팅 모드. 컷아웃 모드. 컷오프 값은 변수 이름에 따름* vertex:VertexFunction - Custom vertex modification function. See Tree Bark shader for example.* 커스텀 버텍스 쉐이더 모드. (버텍스 쉐이더 추가 모드)* finalcolor:ColorFunction - Custom final color modification function. See Surface Shader Examples.* 파이널 칼라 커스텀 모드* exclude_path:prepass or exclude_path:forward - Do not generate passes for given rendering path.* 디퍼드나 포워드 렌더링 둘 중 하나 패스를 제거해서 한쪽으로만 가게 할 수 있다.* addshadow - Add shadow caster & collector passes. Commonly used with custom vertex modification, so that shadow casting also gets any procedural vertex animation.* 쉐도우 캐스터나 콜렉터 패스를 추가한다. 보통 커스텀 버텍스 쉐이더 장착되었을때 사용된다.* dualforward - Use dual lightmaps in forward rendering path.* 듀얼 라이트맵이 가동되었을때 사용된다. 포워드에서.* fullforwardshadows - Support all shadow types in Forward rendering path.* 포워드 렌더링 패스에서 모든 쉐도우 타입을 지원한다.* decal:add - Additive decal shader (e.g. terrain AddPass).* 애디티브 데칼 쉐이더* decal:blend - Semitransparent decal shader.* 반투명 데칼 쉐이더* softvegetation - Makes the surface shader only be rendered when Soft Vegetation is on.* 소프트 베지테이션이 켜졌을때만 서페이스 쉐이더를 만든다* noambient - Do not apply any ambient lighting or spherical harmonics lights.* 엠비언트 라이트나 SH 라이트가 적용되지 않게 한다* novertexlights - Do not apply any spherical harmonics or per-vertex lights in Forward rendering.* SH 나 버텍스 라이트가 가동되지 않게 한다. 포워드 렌더링에서 .* nolightmap - Disables lightmap support in this shader (makes a shader smaller).* 라이트맵이 가동되지 않게 한다 (쉐이더를 작게 만든다)* nodirlightmap - Disables directional lightmaps support in this shader (makes a shader smaller).* 디렉셔널 라이트맵을 가동되지 않게 한다* noforwardadd - Disables Forward rendering additive pass. This makes the shader support one full directional light, with all other lights computed per-vertex/SH. Makes shaders smaller as well.* 포워드 렌더링 에디티브 패스를 가동되지 않게 한다. 이것은 쉐이더를 하나의 완전한 디렉셔널 라이트를 지원하게 한다. 다른 라이트는 무조건 버텍스나 SH 라이트로 작동하게 한다. 쉐이더를 가볍게 한다.* approxview - Computes normalized view direction per-vertex instead of per-pixel, for shaders that need it. This is faster, but view direction is not entirely correct when camera gets close to surface.* 노말라이즈된 뷰 디렉션을 퍼 픽셀 대신에 퍼 버텍스로 만든다. 이것을 필요로 하는 쉐이더에 한해서 말이다. 이것은 빠르지만 카메라가 근접하게 된다던가 할 때 정확하지 않은 결과를 만든다.* halfasview - Pass half-direction vector into the lighting function instead of view-direction. Half-direction will be computed and normalized per vertex. This is faster, but not entirely correct. * 하프-디렉션 벡터를 라이트 함수에 뷰 디렉션 벡터 대신에 넣는다. 하프 디렉션은 퍼 버텍스에서 연산될 것이다. 이것은 빠르지만 완전히 정확하지는 않다.

Additionally, you can write #pragma debug inside CGPROGRAM block, and then surface compiler will spit out a lot of comments of the generated code. You can view that using Open Compiled Shader in shader inspector

추가적으로 당신은 CGPROGRAM 블럭에 #pragma debug 를 넣을 수 있다. 그리고 그러면 서페이스 컴파일러는 생성된 코드에 많은 분기된 코멘트를 넣어줄 것이다. 그리고 이렇게 컴파일된 쉐이더를 쉐이더 인스펙터에서 볼 수 있다.

fragment shader Texture 추가

Thu, 06 Sep 2012 09:59:39 +0000

Shader “TestRedShader” {
Properties {
_MainTex (“Texture1”, 2D) = “white” {}
// _BumpMap (“Bumpmap”, 2D) = “bump” {}
// _Texture2 (“Texture2”, 2D) = “gray” {}
// _Amount (“Texture1->Texture2”, Range(0,1)) = 0.5
}

Category{

SubShader {
Tags{ “Queue”=“Geometry” “RenderType”=“Opaque” }

pass{

CGPROGRAM
#pragma vertex vert
#pragma fragment frag
#pragma ARB_precision_hint_fastest
// #pragma target 3.0
#include “UnityCG.cginc”

struct v2f
{
float4 vertex : POSITION;
};

float4 _MainTex_ST;

v2f vert (appdata_full v)
{
v2f o;
o.vertex = mul(UNITY_MATRIX_MVP, v.vertex);
o.texcoord = TRANSFORM_TEX (v.texcoord, _MainTex);
//o.texcoord = v.texcoord ; //해도 상관 없지만, shader option의 tiling 이나 offset 등을 적용하기 위해서는 위와 같이 해야 함
return o;
}

float4 frag(v2f i) : COLOR
{
float4 finalcolor = float4(1,0,0,1);
return finalcolor;
}
ENDCG

}//pass
}//subshader
}//Category

}

fragment shader 기본형

Wed, 05 Sep 2012 17:54:35 +0000

Shader “TestRedShader” {
    Properties {
//      _MainTex (“Texture1”, 2D) = “white” {}
//      _BumpMap (“Bumpmap”, 2D) = “bump” {}
//     _Texture2 (“Texture2”, 2D) = “gray” {}
//      _Amount (“Texture1->Texture2”, Range(0,1)) = 0.5
    }


Category{

SubShader {
  Tags{ “Queue”=“Geometry” “RenderType”=“Opaque” }

  pass{

   CGPROGRAM
   #pragma vertex vert
   #pragma fragment frag
   #pragma ARB_precision_hint_fastest
//   #pragma target 3.0
   #include “UnityCG.cginc”

   struct v2f
   {
   float4 vertex : POSITION;
   };

   v2f vert (appdata_full v)
   {
   v2f o;
   o.vertex = mul(UNITY_MATRIX_MVP, v.vertex);
   return o;
   }

   float4 frag(v2f i) : COLOR
   {
   float4 finalcolor = float4(1,0,0,1);
   return finalcolor;
   }
   ENDCG

  }//pass
}//subshader
}//Category


}

명일역 항아리 닭강정

Thu, 30 Aug 2012 09:33:16 +0000

명일역 4번출구 항아리 닭강정.
새로 생겼길래 어떤가 하고 가봤더니

생긴지 10년은 된 듯한 지저분함에 일단 놀람.
기름 튀기는 일이 원래 좀 지저분 할 수 있지만 꾸준히 닦아 주기만 하면 저정도까지는 안갈텐데 이건 신경을 안쓴 수준.
어지럽게 던져져있는 건자재들을 봐도 일단 정리라는걸 할 생각이 없는 것이 보인다. 위생은 일단 불합격.

손님이 와도 웃으며 뛰어오며 반기는 것도 아니고 구석에서 딴짓하고 있다가 어슬렁어슬렁.
질문에도 대충대충 대답. 졸리면 가서 문닫고 자라… 친절도 불합격.

조리가 금방 되는 걸로 봐서 미리 튀겨놓은 닭을 쌓아놓고 있다가 주문들어오면 다시 한 번 튀겨서 소스 발라주는 방식인듯.

근처 학생들에게 컵강정 정도 파는걸 목적으로 할 생각이었는지 포장박스도 전용이 아님…

맛은 그저 그런데 닭과 기름의 품질을 기가막히게 따지는 내 배의 지금 상태로 봤을때 품질도 불합격.
오래 가지는 못할 것 같군 여기.

덧 ) 그 이후에 다시 한 번 가 봤더니 이 글을 보셨는지 좀 깨끗해 지긴 했더군요. 지나가다 본 거라서 친절한지, 맛은 좋은지는 잘 모르겠지만. 조만간 한 번 먹어봐야겠습니다.

유니티 4.0이 발표되었습니다.

Fri, 24 Aug 2012 17:57:29 +0000

유니티 4.0이 이번주의 암스테르담에서 열린 Unite2012 에서 발표되었습니다.

유니티 4.0 의 큰 변화는 향상된 에니메이션 시스템입니다. (Mecanim이라고 부르는 듯?)

또한 추가적으로 다이렉트X 11 지원, 모바일에서의 실시간 그림자 지원, 발전된 조명 시스템, 리눅스와 플레쉬 익스포트 지원 등이 있습니다. 그지같은 어셋 서버나 고쳐주지

테크 데모 릴인 “나비효과” 를 공개합니다.

으흠. 캐릭터 피부에 다이렉트X 11 기술 적용했네요. 머리카락도 DX11의 퍼를 사용했고. 폭파장면도 DX11… 조명도 다르고..

처음에 나오는 건물은 LOD 겠고..

추가적인 소개 동영상과 튜터리얼은

http://video.unity3d.com/

여기서 볼 수 있습니다.

특히 새로 나온 에니메이션 시스템은 튜터리얼도 올라와 있네요 +_+ 반짝

http://video.unity3d.com/video/6717599/unity-4-preorder-mecanim-beta

게임테크 2012 강연료 기부 인증

Wed, 22 Aug 2012 09:30:18 +0000

http://chulin28ho.egloos.com/5646840

에서 마지막에 말했던 ‘강연료 기부’ 를 실행했는데 인증을 안했길래…
사진 뒤지다 보니 나오더라고요.

요약하자면,
“게임테크의 실망스러운 진행과 엉망인 스피커 대우에 분노해서 다시는 게임테크에 참가하지 않겠다” 라는 이유로,
나중에 나온 게임테크 강연료를 기부한 증거물 입니다.

사실 매년 엔진광고 - 엔진사 홈페이지만 들어가도 볼 수 있는 수준의 - 들으러 몇 만원씩 내고 가는 수준의 이런 강연이면 안가는 쪽이 훨씬 낫거든요. 차라리 NDC 나 KGC 를 가는게 백배 유익합니다.

이게 획기적으로 개선된다면 몰라도, 지금과 같은 수준의 강연이면 절대로 가지 않겠습니다.

ShaderFX를 이용한, 그래픽 디자이너를 위한 기초 쉐이더 강좌 9강

Sun, 19 Aug 2012 13:35:34 +0000

Phong 셰이더보다 싼 유사 Blinn-Phong 셰이딩 모델

Sat, 18 Aug 2012 13:03:26 +0000

물리기반 셰이더를 짤때 가장 먼저 고려되는게 Normalized Blinn-Phong 셰이더입니다.

아시다시피 게임에서 널리 쓰이는 Specular 모델인 Phong 셰이딩은 그다지 물리적으로 정확한 모델은 아닙니다. 실제 Specular는 방향성을 갖고 있지만 Phong 셰이딩은 항상 원형 형태로 Specular가 생기거든요.

이게 구같은 곡면에선 큰 문제가 없지만 편편한 곳에선 실제와 전혀 다른 Specular를 만듭니다. 아래 사진들을 보시죠.

그림에서도 보시면 아시겠지만 물리적으로 정확한 Specular는 Blinn-Phong 셰이딩입니다. 근데 Blinn-Phong 셰이딩은 두가지 문제를 갖고 있습니다.

Phong 셰이더보다 비쌉니다!
Normalmap이 깨져보이게 Specular가 생깁니다!

Blinn-Phong 셰이더는 Phong 셰이더와는 달리 Reflection 벡터를 사용하지 않고 Half 벡터를 사용합니다. 그래서 더 실제같은 결과물을 보여주는 대신 좀더 많은 처리를 요하지요. 하지만 요새 하드웨어 성능이 원체 좋아져서 이건 큰 문제가 안됩니다. 그러나!

실제 폴리곤 모델인 경우 생기지 않는 문제지만 Normalmap을 사용하게 되면 Specular가 깨져서 생기게 됩니다. 이게 무슨 소리냐면

그림에서 보시다시피 Flickering 현상이 나타납니다. 이건 Normalmap이 0~~1까지의 값만을 갖으면서 생기는 문제로, Blinn-Phong 셰이더에서 이걸 해결하려면 Normalmap을 한번 더해주고 그걸 다시 나눈다음에 노멀라이즈 해줘서 -1~~1의 값을 갖도록 만들어주면 됩니다.

그런데 가뜩이나 Phong 셰이더보다 무거운데 Normalmap까지 처리해주느라 더 무거워지는 일이 생기는데 이걸 해결한 유사 Blinn-Phon 셰이딩 모델이 있습니다. 심지어 Phong 셰이더보다도 가볍습니다!

a reformulation of the Blinn-Phong model by Richard F. Lyon 에서 나온 셰이딩 모델인데요, 1993년에 Apple에 기고된 연구 논문입니다. (Lyon씨는 광학 마우스까지 만든, 잡스옹의 말을 빌자면 아주 어썸!한 사람입니다.) 자세한 이론적 배경은 링크된 논문을 참고하시고, 구현식은 이렇습니다.

Code:

float Lyon(float3 normal, float3 view, float3 light){ 
    float3 halfVector = normalize(light + view); 
    float3 difference = halfVector - normal; 
    float xs = saturate(dot(difference, difference) * specPower / 2); 
    return pow(1 - xs, 3); 
} 
 
 
 
 
 
 
이제 Phong 보다도 싼 Lyon/Blinn-Phong 모델을 써서 물리적으로 좀더 정확한 셰이더를 만들어 보세요!

뷰 벡터 / 카메라 벡터 구하는 식

Sat, 18 Aug 2012 00:19:47 +0000

ViewDir = normalize(InvViewMatrix[3].xyz - Position.xyz);

카메라 디렉션 / 뷰 디렉션

이벤트 2부 : 이태원 여행

Thu, 16 Aug 2012 03:23:59 +0000

오전의 시네 드 셰프 마치고 오후 일정이 진짜.

사실 외국 여행을 가고 싶었어요. 하지만 일정도 일정이고, 금액도 금액이고 그건 불가능 ㅋ

그래서 그 대용으로, 이태원에서 1박 2일 세계 맛집 여행을 결정했어요 ㅎㅎ

1박 2일로는 뭐 별로 많이 돌아다닐 수도 없겠지만, 어쨌거나 마나님이 즐거워하시면 그걸로 오케.

예약한 IP 부티끄 이태원 호텔 ♥

IP가 뭐야? 했는데 나중에 알고보니 임페리얼 펠리스 ..ㅋㅋ

해밀톤 호텔이 조금 더 중심가와 가깝지만, 호텔이 너무 오래된 느낌이라 여기로 선택했습니다.

입구의 나무 태권브이가 반기네요 :)

날씨 죽인다 ㅋ

… 아니 농담아니고 진짜 사람을 죽이네…

올해 가장 더웠던 바로 그 때입니다. ㄷㄷㄷ

호텔은 꽤나 감각적인 디자인으로 가득 차 있습니다.

마치 현대 미술 갤러리에 와 있는 기분.

곳곳에 감각적인 디자인들이 보입니다.

여기가 하루 묵을 객실. 깔끔하네요. 넓지는 않지만, 여태까지 다녔던 호텔 중 상위에 들만큼 깨끗하고 시설도 좋습니다.

와이파이도 무료고 ㅋ

역시나 모던한 디자인은 여기저기서 볼 수 있습니다.

물 외에 건드리면 안되는 미니 바가 가득.

뭐.. 필요하면 꺼내 먹고 동일한 걸로 채워도 괜찮아 보입니다만.

칫솔 치약 같은건 요새 전세계적으로 안 주는 추세죠. 일회용품 아낀다고.

그치만 왠지 저기다 두니까 새로운 수익구조 창출로 보이는군요. ㅎ

화장실도 감각적으로 잘 되어 있습니다. 약간 반투명한 유리로 감싸 있지만 별로 민망할 것 까지는 없네요.

상하이에서는 통유리로 된 욕실이 있는 방에서 묵었는데 … (이상한 생각하면 안됨. 혼자 묵었어요 ㅋ)

아이폰 독 스피커가 있는게 특히 맘에 듭니다.

창밖의 전망도 괜찮아요. 제일기획 건물이 앞에 보입니다. 길교수님 저기 계실텐데 ㅋ

날씨는 지극히 좋고 덥습니다. 진짜 낮에는 각오하고 돌아야 할 것 같..

이쪽에는 이슬람 사원이 있네요. 한번 가 봐야 겠습니다.

자 짐을 정리하고, 전형적인 외국 여행객 복장을 갖춘 채 출발 ㅋ

일단 이슬람 사원쪽으로 가 봅니다. 날씨 장난 아니네요.

으힉 ㅋ
트랜스젠더 빠들이 많다는 말은 들었는데 정말 대놓고 많아 ㅋㅋㅋ

아아 굉장히 이국적인 느낌의 경고문

이태원에 온 것 같은 느낌이 팍 듭니다 .

이슬람 사원 도착.

왠지

들어가도 되나.. .? 라는 느낌이 들긴 합니다. 아무런 안내문이 없어서요.

멀리서 보면 이렇게 되어 있거든요.

‘소비자 수퍼’ … 인상깊네요. 마치 LA 한인타운에 온 것 같은 느낌.

거부감있는 첫인상과는 달리, 들어가면 의외로 친절합니다. 경비 아저씨도 친절하고… 사람도 꽤 많고…
대신 여자는 짧은 치마나 바지를 입으면 안되기 때문에 여기서 덧입는 긴치마를 빌려 입고 구경해야 한다는군요.

생각보다 꽤 이쁜데요.

오오 이것이 이슬람 사원.

저 기도실은 남성 전용 . 그리고 외부인은 들어갈 수 없어서 밖에서 구경만 할 수 있습니다.

문 열린 틈으로 봤는데

기도실이라면서 … 다들 낮잠자고 있어요 뒹굴대면서 ㅋㅋㅋㅋ 뭐야 오침실인 거였어?

생각보다는 크지 않고 볼 것도 적어서 조금 실망했습니다만 어쨌건 매우 이국적인 좋은 경험이었습니다.

이것이 이태원의 골목길. 뭔가 묘하게 이국적이면서도 익숙합니다.

국내 수입 안되는 음료수도 막 있고 막 이래. 몬스터도 봤음.

이번엔 이태원 엔틱 가구 거리와 로데오거리를 한바퀴 돌려고 출발했습니다.

이태원은 땅이 좁아서인지, 저렇게 신기한 공간들이 많더군요.

거의 벽에 붙어 있는 듯 만든 카페 야외석이 이채롭습니다.

제가 생각한 이태원의 인상이 이 사진 한 장으로 함축되어 있습니다.

가는 동안에 찍은 사진.

오오 저 총은 !!!! 바로 내가 고등학교때 교련 시간에 썼던 그 고무총 아닌가!!!

엔틱 가구 거리를 돌아다니면, 알프스소녀 하이디에나 나왔을 것 같은 잡동사니들이 저렇게 굴러다니더군요.

많은 가게가 여름휴가를 떠나서 제대로 보진 못했지만.

이렇게 엄청나고 신기한 잡동사니(?) 들을 모아놓고 파는 가게가 많습니다.

이쁜 카페를 열고 싶으면 여길 한바퀴 돌아서 챙겨오면 되겠더군요.

헥헥 힘들다. 날씨가 너무 더워서 더 돌다간 탈진할 것 같아요.

일단 기본적으로 돌 곳은 다 돌았으니까 맥도날드에서 잠깐 쉬었다가 호텔로 복귀하고, 저녁에 선선해지면 다시 돌기로 했습니다.

호텔로 컴백. 호텔에 그네가 있어 ㅋㅋ ㅋ

잠시 쉬고, 좀 씻고, 더위로 지친 몸을 달래고 난 후 본격적으로 식사여행을 떠날 준비 완료.

핫식스로 기력을 충전합니다. 요샌 노는데에도 약물이 필요해요.

여기가 이태원의 세계 음식문화의 거리!
오기는 몇 번 와 봤지만 마나님이랑 제대로 와본건 처음인듯.

오우 역시 불금의 이태원은 80% 정도가 아가씨들만 보입니다.

진짜 아무데나 찍어도 이렇게 나옴.

저녁식사로 고른 곳은 불가리아 레스토랑 ‘젤렌’

아무리 읽어도 제렌인데, 왜 사람들은 젤렌이라고 부르는 걸까요?

안에는 대충 이런 느낌입니다. 음 … 사람은 역시나 바글바글

가볍게 먹고 가능한한 다양한 곳을 가보고 싶었기 때문에 많이 시키지 않았습니다.

양도 작고 딱 좋네요.

이건 가지에다가 치즈랑 … 뭐 어쩌구 한 건데.

음… 가지 별로 안좋아하는데 이건 맛있네요.

근데 솔직히 불가리아랑 뭐가 상관있는지는 잘 모르겠음 ㅋ 치즈 저렇게 하니까 이탈리아 요리같애 ㅋ

두 번째 요리는 구운 닭가슴살과 감자와 크림소스인데, 느끼하지 않고 맛있습니다. 부드럽구요.

… 근데 그리스 요리랑 별로 다른걸 모르겠어 ㅋㅋㅋ

홍석천씨의 음식점이 많다고 하던데, 바로 옆이 거기더군요. 타이차이나.

이 근처 살면 가볼 요리집은 아주 넘치겠습니다.

아니나다를까 홍석천씨는 길가의 지나가는 팬분과 셀카를 찍어주시고 계심 ㅋ

음… 역시 1박 2일로는 먹거리 여행에서 별로 할 게 없어요.

왜냐면 저만큼 먹어도 벌써 배불렀으니까요 ㅋ

한 잔 하려 하는데 유명한데는 자리도 없고…

그래서 라디오 가든에서 간단히 마티니.

아 마티니 달다 ㅋ

커다란 강아지가 어슬렁거리는 가게에서 마티니 홀짝대면서 놀고 있었는데,

10년동안 못만났던 박감독이랑 갑자기 연락이 되어서 만나기로 했지요.

박감독 온다더니 많이 늦길래 다시 이태원 거리 방황중.

이후 박감독과 , 곧 결혼할 아름다운 Shanelle 양과 만나서 , 너무 즐겁게 수다떨고 노느라 사진이 한 장도 없습니다 ㅋ
http://jinwooshanelle.com/xe/
결혼식장이 우왕굿 ㅋ

정~~~말로 반가웠어요 진짜로.

제가 사람 만나는거 별로 안좋아 하지만 좋은 사람이랑 만나는건 정말 좋거든요.
이렇게 좋은 사람들과 즐거운 시간을 보낼 수 있다니 정말 행복했습니다.
이것만으로도 이태원 여행의 본전을 뽑은 느낌이었습니다.
할 수만 있다면 호텔방으로 초대해서 밤새 놀고 싶었습니다만 젊은 커플에게 방해가 되는 것 같아서 그렇게는 못했죠 ㅋ 아니 솔직히 체력의 한계도 있고. 다음날 아이들 데리러 가야 해서…

그렇게 새벽까지 놀다가, 내일 아침으로 캐밥을 사서 호텔로 리턴.

이 얼마나 오랜만인가.. 이 시간까지 논게..

참고로 저 캐밥은 아침에 먹어도 무척 맛있더군요.

담에는 사와서 집에서 먹어보고 싶었뜸.

아침이 밝았습니다. 캠프를 간 아이들 데리러 가야 하기 때문에 아침 일찍 체크아웃.

2박 3일로 놀지 못한걸 아쉬워하는 마눌.

그 얘기는 그만큼 재밌었다는 뜻이렸다.

기념으로 그동안 공개 안하던 마눌님 사진 투척.
저 뒤의 유모차는 우리게 아님 ㅋ

한 장 더 ㅋ

발렛파킹 해 놓은 차 기다리는 중입니다.

부릉부릉 ㅋ 앗따 1호기 맑은 낮에 보니 더 이쁘네.

잘잤냐 ㅋ

이렇게 1부에 이은 2부, 이태원 여행까지 종료했습니다.

이태원은 생각보다 무척 재미있는 곳이더군요! 다음에는 꼭 2박 3일로 와보고 싶었습니다. 다음에는 좀 더 더울때 ㅋㅋ
(아이들 겨울 캠핑이 언제더라…)

마눌님을 위한 이벤트 1부 : 시네 드 셰프

Wed, 08 Aug 2012 01:55:22 +0000

아이들이 4박 5일 캠프 가 있는 동안, 그동안 홈스쿨링에 수고한 마눌님을 위해 작은 이벤트를 준비해 봤습니다.
저도 하루 정도 휴가내고요.
그 1부는 압구정에 있는 시네 드 셰프. 일주일 전 부터 예약이 가능하네요.

로블카드에서 10만원 지원해 주는게 있어서 이번에 사용했는데,
2주일 전에 예약하니 1주일 전까지는 불가능 하다고 합니다.
자리가 없을까봐 그랬던 건데 자리가 없기는 커녕 오히려 반도 안차더군요. 하긴 그냥 보면 4만원 짜리라서 …

압구정 CGV에서 발렛파킹하고, 전용 엘리베이터를 타고 지하 5층 (!) 으로 내려가면
숨겨진 영화관이 나옵니다..

자리는 딸랑 이게 다.
관은 2개 관밖에 없어서, 다양한 영화는 물론 포기해야 합니다.

본 영화는 “도둑들” 과 “다크나이트” 가 있었는데, 닭나는 봐서 도둑들을 봤습니다. 영화는 대 만족.

자리는 이렇게 생겼습니다. 럭셔리 럭셔리.
특별한 날 연인과 기분내기에는 확실히 좋을듯.

음료와 간단한 과자는 줍니다. 그리고 메뉴판도 있네요.
영화를 보다가 룸서비스처럼 추가로 시킬 수도 있는 모양입니다.

일반적으로 듣기에는 영화보면서 저녁식사를 하는 것 처럼 소문이 난 모양입니다만,
그런게 아니라 영화는 영화, 식사는 식사입니다.

점심 타임에는 식사 후에 영화를 보는데, 저희는 아침 10시 타임이어서 영화 관람 후 식사를 했지요.

한컷 더. 한산 한산. 하긴 뭐 평일 (금요일) 오전에 사람이 많을리가 없죠.

영화 관람 후 밖으로 나오면 바로 옆에 식당이 있습니다.
지하 5층에 이런게 있다니 참 뭐랄까. 비밀기지에 들어온 느낌이네요.

주방은 이렇게.

약간 출출합니다. 영화를 재미있고 편안하게 본 지라 매우 만족스러웠어요.

총 3개의 코스 중 2개만 고르면 38000원, 3개를 고르면 46000원입니다. 당연히 부가세 포함 안된 금액이죠.
저희는 로블카드라서 1인분만 추가로 시키면 됩니다 :)

스타터로 시킨 시저 샐러드.

메인 요리는 스테이크와

농어구이.
농어구이는 뭐… 물고기 구운 맛 ㅋㅋ

스테이크는 채끝살이라 그런지 어쩐지 엄청나게 부드럽거나 하진 않았습니다. 힘줄 싫음.
그래도 나쁘진 않은 정도?

후식은 참 재미있네요.
복숭아에다가 뭔가를 뿌리고 구웠 (…) 는데, 술맛이 납니다.

옆에 있는 이상한 모자는 그냥 복숭아 넥타 (…)

너무 럭셔리해서 그런지 싸구려 입맛에게는 좀 무리인듯. ㅋ

파킹은 식사까지 하면 무려 6시간 (!) 이나 줍니다.
시간이 남아서 주변을 돌아다니고 싶었지만 너무 더워서 포기 …
그냥 차 뺍니다. 오후 일정이 있어요. ㅋ 2부가 진짜니까요.

발렛 파킹은 2천원 파킹비와 함께 주차권을 주고 커피숍에서 대기하면 저렇게 번호로 알려줍니다

시네 드 셰프. 다소 가격은 비싸지만, 한 번씩 이벤트로 마눌님 모시고 대접할때는 꽤 쓸만한 것 같습니다.
단 , 영화가 재밌는걸 하는 시즌을 잘 골라야 한다는 … ㅎㅎ

듀얼 라이트맵에 대한 연구

Wed, 01 Aug 2012 12:01:46 +0000

라이트맵이란? (Lightmap)

유니티에 라이트맵 기능은 이전부터 있어 왔습니다.

라이트맵이란, 렌더링에서 가장 무거운 요소인 조명과 그림자 연산을 실시간으로 하지 않기 위해서 미리 조명과 그림자 연산을 특정한 텍스쳐로 만들어 (굽는다고 표현합니다 : Bake) 입힘으로써, 조명 연산을 피하고자 하는 꼼수라고 할 수 있습니다.

참고로 유니티에는 가장 유명한 라이트맵 솔루션인 비스트 (Beast) 가 내장되어 있습니다.

이전에 있던 라이트맵은 싱글 라이트맵 (single lightmap) 이라 불리는 것으로, 보다 단순한 구조를 가지고 있습니다.
싱글 라이트맵은 누구나 흔히 짐작할 수 있는 기술로, 라이트맵을 구워서 오브젝트 / 배경등 static (고정된) 오브젝트에 입혀 버리는 기술입니다.

장점은 조명 계산을 하지 않아도 되므로 렌더링 부하가 줄어들고, 그래픽 카드나 각종 사양에 상대적으로 둔감하게 적용할 수 있다는 것입니다. 때문에 낮은 사양의 컴퓨터에서도 훌륭한 조명과 그림자 효과를 표현할 수 있습니다.

단점은 맵 제작시에 전체 맵을 전부 구워(Bake) 해 버리는 작업이 필요하므로 작업효율이 떨어지며, 추가의 UV가 필요한 버텍스 버퍼와 추가의 텍스쳐 이용으로 인한 메모리 소비 등이 있을 수 있겠습니다. 아참, 또하나로 노말맵이나 스페큘러 등의 효과가 전부 무시되어 버리는 단점이 있습니다. 열심히 작업한 배경의 노말맵이 모두 사라져 버리면 실망스럽겠지요.

(이래서 프로젝트에서 라이트맵을 사용하지 않았던 것입니다.)

동적 오브젝트의 리얼타임 그림자만 섞어서 제작하는 것이 이 방식이었습니다

듀얼 라이트맵이란? (Dual Lightmap)

듀얼 라이트맵이란. 이전에 가지고 있던 싱글 라이트맵의 단점을 개량해서 나온 새 기능으로,
유니티 3.4인가 3.5인가 잘 모르겠지만 (아마 3.5인듯?) 그때부터 나온 기능입니다.

이 기능을 간단하게 정의하자면, “리얼타임 라이트/셰도우와 구워진 라이트맵을 혼합해서 동시에 사용” 한다는 것이 기존의 라이트 맵과 다른 기능입니다.

즉 카메라의 Shadow distance (그림자 출현 거리) 옵션 값으로, 카메라와 가까운 영역은 리얼타임 그림자와 리얼타임 라이트가 계산됩니다. 즉 노말맵이나 스페큘러가 모두 적용된, 말그대로 ‘라이트맵을 사용하지 않는 실시간 상태’ 로 렌더링됩니다. (거기다가 기존의 라이트맵도 같이 섞여서 렌더링 됩니다)

그렇지만 카메라의 shadow dstance 를 넘어간, 카메라와 먼 영역이 되면 예전의 라이트맵 방식만 나타나게 됩니다.
즉 멀리 있는 동적 오브젝트 - 멀리있는 몬스터나 NPC- 등의 그림자는 안나오겠지만, 그 외에 고정된 오브젝트는 라이트맵이 충실하게 표현된다는 것입니다.

이렇게 리얼타임 라이트/그림자와 , 라이트맵을 혼용해서 사용하면 다음과 같은 장단점이 있을 것으로 예상됩니다.

듀얼 라이트맵의 장단점

듀얼 라이트맵의 장점

퀄리티가 올라갑니다. (호오? 퀄리티가 올라가는군요?)

라이트맵은 기본적으로 Indirect light (간접광) 을 계산해서 구현하는 것이기 때문에 분위기 잡기에는 좋습니다.
그렇지만 반대급부로 섬세한 노말맵 효과나 스페큘러를 표현할 수 없는 단점이 있는데, 가까운 거리에는 리얼타임 라이트/그림자와 혼합함으로써, 그림자의 해상도도 올라가게 되고 (가까운데만 고급으로 처리할 수 있으니까) 노말맵과 스페큘러도 쓸 수 있으므로 라이트맵의 장점과 실시간 라이팅/셰도잉의 장점을 동시에 살릴 수 있습니다.

저사양에서도 품질이 덜 떨어집니다.
지금 게임을 돌릴 때 가장 무거운 것이 실시간 그림자입니다. (조명연산도 무시 못하지만)
그래서 옵션을 조금이라도 낮추었을때 프레임 향상을 위해서 가장 먼저 없애는 것이 그림자이고, 그 이유로 중급 이하부터는 퀄리티가 팍 떨어져 보이게 됩니다. 이 방식을 쓰면 이것을 방지할 수 있게 됩니다.

사양이 낮아집니다.
최고 사양같은 경우에는 그림자 영역을 길게 잡을 수 밖에 없는데, 이 방법을 쓰면 최고 옵션에서도 그림자 거리를 낮게 잡을 수 있어서 사양이 내려가는 효과가 있습니다. 반대로 저사양은 살짝 올라갈 수도 있습니다만 (…)

간단한 수정이 쉬워져 보입니다.
테스트를 해 봐야 확실하겠지만, 이론적으로는 일단 조명 한두개 정도는 리얼타임으로 추가해도 라이트맵을 다시 굽지 않고도 사용가능해 보입니다. 리얼타임 라이트와 합성하는 거니까요.

<사진: 듀얼 라이트맵의 효과를 보여주고 있습니다. >

멀리 있는 부분은 라이트맵이고 가까이 있는 부분은 리얼타임 라이팅이지만, 경계선이 잘 블렌딩 되어서 어디가 시작인지 알아볼 수 없습니다.
멀리 있는 더미 병사에게는 그림자 (동적 그림자) 가 영향을 끼치지 못하고 있는 것을 알 수 있습니다.
화면의 맨 오른쪽 위 부분은 가까이 있는 부분이지만, 라이트맵에서 받은 부드러운 간접광 효과도 같이 나오고 있는걸 알 수 있습니다.

가까이 있는 맨홀 뚜껑에는 노말과 스페큘러가 나타나고 있습니다.
가까이 있는 드럼통은 폭발해야 할 동적 오브젝트입니다, 자연스럽게 동적 그림자를 드리우고 있습니다.
라이트맵은 보통 그림자의 해상도가 좋지 못합니다. 넓은 면을 한 장의 그림자로 해결해야 하기 때문이죠.
하지만 이 방식을 쓰면 가까운 부분의 그림자 해상도가 좋아집니다.

듀얼 라이트맵의 단점

제작이 귀찮습니다.
라이트맵을 굽는(Baking) 작업의 시간이 꽤 걸립니다. 품질이 높은 대신 이런 단점이 있죠. 빠른 수정에 대처하기 힘듭니다. 부분만 굽는 기능이 개발되어 있습니다만, 어쨌거나 그냥 만들던 이전의 리얼타임 방식과의 차이는 큽니다.

메모리를 더 차지합니다.
라이트맵의 사이즈에 따라서 메모리를 더 차지할 수 밖에 없습니다. 저사양에서는 조금 부담이 될 수도 있겠습니다.

디퍼드 렌더링 모드에서만 사용가능합니다.
포워드 렌더러도 사용이 가능하긴 합니다. 대신 셰이더에서 수동으로 dualforward 라는 키워드를 이용하여 작동하게 할 수 있습니다.

그럼 현실적인 사용 방법은?

프로젝트에서 사용할 것인가?

4.0 에서는 라이트맵에서도 스페큘러와 노말맵이 사용 가능하게 된다는 정보가 있습니다. 잘만 되면 라이트맵 만으로도 전부 표현할 수 있다는 말이 되겠지요.

이렇게 라이트맵의 발전이 예상되는 관계로 체크하지 않고 갈 수 없겠지요. 단점에 비해 장점이 많다면 당연히 채용합니다.

그런 의미에서 다른건 괜찮지만, 제작 시간이 오래 걸린다는 것이 가장 큰 문제라고 할 수 있습니다.
메모리 차지야 사실 큰 문제는 아니고, 렌더링 모드는 디퍼드 모드를 사용하면 되는 것이니까요. 아이폰 게임도 아니고.
그렇지만 작업이 오래 걸린다면 효율에 큰 영향을 줄 것입니다.
그러므로 제안하고자 하는 절충안은 이 정도 입니다.

일단은 실시간 조명/그림자만 적용해서 게임을 제작한다.
TA 가 음지에서 지속적으로 라이트맵 적용을 테스트 한다
게임 제작 후반이 되어서 작업이 안정되고 변수가 적어질 때 작업에 들어가도 늦지 않을 듯.

이상 듀얼 라이트맵(Dual lightmap) 에 대한 이론적 기초 연구를 마칩니다.
쓸 지 안쓸지 좋을지 안좋을지는 TA 들이 지속적으로 테스트 해주실 겁니다 :)

아치바 이동형 모니터 M9

Mon, 30 Jul 2012 01:49:44 +0000

현재 모바일 프로젝트의 텍스쳐 제작 요령

Wed, 18 Jul 2012 17:39:17 +0000

모바일 프로젝트의 텍스쳐에 샤픈을 주는 건 주의해야 한다.

텍스쳐가 작다고 샤픈을 주면 픽셀간 대비가 높아지면서 고주파 이미지가 되고,

텍스쳐의 바이리니어 필터링 시에 자글대는 앨리어싱 현상이 나타나기 쉽다.

선명하게 하고 싶으면 큰 텍스쳐를 사용해라.

모바일 프로젝트에서는 아직까지 트라이리니어 필터링을 사용하기 어렵기 때문에 그렇다.

언젠가는 anisotropic 필터링까지 사용될 날이 오겠지…

BMW 528i 2012 F10 4기통 터보

Fri, 13 Jul 2012 01:02:33 +0000

진짜 딱 4개월만에 받았습니다. 인디오더 하니까 몸에서 사리나오게 기다려야 하는군요.
그전 E60을 떠나보내고 2호기 좀 몰고 다니다가 다시 1호기 자리를 채우게 되었네요.

BMW 528i F10 4기통 터보입니다. 디젤은 싫어해서..
전 E60에 비해 너무 꿀렁댄다고 하더니… 몰아보니까 저같은 일반인한테는 “좋은데???” 였네요.
특유의 가죽냄새도 마음에 들고 각종 전자장비들도 추가된 것이 마음에 듭니다.

임페리얼 블루와 시나몬 브라운 시트.

임블은 생각한것보다 훨씬 네요. 정말 마음에 드는 색상입니다.

시나몬 브라운은 생각보다 좀 탁하지만 야간 조명과 잘 어울리고요.

엠비언트 라이트는 사제로 했는데 좀 너무 밝은 감이… 그치만 귀찮으니까 냅둘랍니다.

인디 오더를 하느라고 4개월을 기다렸지만 덕분에 대 만족.

특히 컴포트 시트가 우왕 굿 … 이거 하나만으로도 4개월 기다릴만한 이유가 되네요.

리얼룩 레온 컬러 액정 보호 필름

Thu, 12 Jul 2012 02:08:48 +0000

BM Font 툴

Tue, 10 Jul 2012 09:13:16 +0000

한글 한 장에 넣으려면

2002L_test1 체

22사이즈

padding 1
2048 2048

ZIO 무선공유기 TR300N

Sun, 08 Jul 2012 20:33:50 +0000

shader option changer 백업

Thu, 05 Jul 2012 12:46:15 +0000

비공개.
TsShaderOptionChanger.cs

TsShaderOptionChangerByFolder.cs

if( !System.IO.Path.HasExtension(obj.name) ) // 시스템에서 받은 오브젝트의 확장자 이름이 없으면. (그럼 폴더니까)
    {
     string fullPath = System.IO.Path.GetFullPath(Application.dataPath);
// 전체 경로를 받아둡니다. Asset 까지만 나옵니다. D:\AT2_WEB\Assets
     string projectPath = fullPath.Remove(fullPath.IndexOf(“Assets”));
// 프로젝트 경로 : 위에서 Assets 를 지웁니다. D:\AT2_WEB\
     string selectedPath = System.IO.Path.GetFullPath(AssetDatabase.GetAssetPath(obj));
// 선택한 오브젝트의 전체 경로를 받습니다. D:\AT2_WEB\Assets\Scripts\AutoTextureApply\Editor\TsShaderOptionChangerByFolder.cs
     string folderPath = System.IO.Path.Combine(projectPath, selectedPath);
// 두 경로를 합칩니다. D:\AT2_WEB\Assets\Scripts\AutoTextureApply\Editor\TsShaderOptionChangerByFolder.cs

ShaderFX를 이용한, 그래픽 디자이너를 위한 기초 쉐이더 강좌 9강

Thu, 05 Jul 2012 12:39:59 +0000

파란이 서비스를 닫는군요.

Mon, 02 Jul 2012 22:44:10 +0000

덕분에 하이텔 게제동도 사라지네요…

이렇게 오랜 역사와 전통을 자랑하는 추억의 게제동이 사라진다니 참 기분이 복잡다난합니다.

할 수 없이 백업이나 해 놓고 보내주는 수 밖에요.

처음으로 크레딧에 제 이름이 들어갔던 게임.

92년도부터 만들어서 93년도 초에 끝난 H.Q. team의 첫 프로젝트, Knight Master 입니다.

도스 게임이라 어떻게 돌려야 할지 잘 모르겠네요 :)

/md.egloos.com/img/eg/icon_file.gif") no-repeat left 50%; padding: 0px 0px 0px 15px; list-style-type: none;’ href=“http://pds23.egloos.com/pds/201207/02/03/KinghtMaster.zip" player=“0”>KinghtMaster.zip

포프님 책 추천사

Mon, 02 Jul 2012 01:38:12 +0000

Shader 란 참 이상한 기술입니다. 분명히 Programer들이 알아볼 수 있는 언어로 구성되어 있고, 그 안의 Process도 지극히 Hardcore한 공학적 내용입니다. 그렇지만 그런 수학적 Programing 결과물이 Art가 되어 나오는, 공학과 예술이 조합된 신기한세계라고 할 수 있습니다.
그 때문에 3D 게임을 제작할 때, Graphic Artist들이 Shader에 대해 민감하게 관심을 가지고 접근하고 싶어하는 것도 이상한 일이 아닐 것입니다. 자신들의 작품이 더욱 아름답고 예술적으로 보이고 싶어하는 것은 Artist들의 본능에 가까운 것이니까요.

물론 저 역시 Artist였기 때문에 그랬었고, 그 후에 제가 처음 Shader라는 것에 관심을 가지고 Programer들이 보는 책을 뒤적거렸을 때가 생각납니다.
지금은 물론 많이 바뀌었지만, 그 때에는 더더욱 Shader 라고 하는 것은 엄연한 Programing 의 분야였으며 (외국은 어땠을지 잘 모르겠지만) Graphic Artist들은 범접할 수 없는 미지의 세계였었지요.

물론 그 당시에 Graphic Artist들이 알아볼 수 있는 Shader에 관한 책은 전무했으며, Programer를 위한 기초 Shader 책도 제대로 된 책은 기껏해야 한 두 권 정도였습니다. 그리고 놀랍게도 그것은 지금도 그렇게 크게 변하지 않았습니다! 여전히 많은 책에서 기초 Shader는 3D Programing에 소속된 한 단원에 불가한 경우가 대부분이며, 그나마도 빈약하거나, Graphic Artist들은 전혀 배려하지 않은 철저하게 3D Programer들을 위해서 씌여진 책이었습니다.

그래서 저와 같이 Shader에 관심을 가지게 된 Graphic Artist들은 전혀 알아듣지도 못하는 C++ 와 DirectX Framework를 공부하며, 어떻게든 Shader에 근접해 가기 위해 발버둥을 치다가 많은 좌절을 겪곤 했었습니다. 그리고 그 때 정말 아쉬웠던 것이, Graphic Artist를 조금이라도 배려한 Shader책이 한 권쯤 있으면 좋겠다라는 것이었습니다.
Shader는 사실 Direct X의 Framework를 제외하고, 구현이나 Programing 수준은 무척 간단한 수준입니다. Graphic Artist들도 조금만 관심을 가지면, 적어도 어느 정도까지는 크게 어렵지 않게 접근할 수 있도록 만들어 놓은 언어입니다. 그렇지만 Artist들의 그 마음과 수준을 이해하고 고려하면서, 이런 전문적인 내용을 쉽게 설명할 수 있는 책을 쓸 수 있는 사람이 없었다는 것이 문제였습니다.

그리고 드디어, Programer와 Graphic Artist들을 모두 친절하게 고려한 Shader 책이 처음으로 세상에 나오게 되었습니다. 이 책을 집필한 Pope Kim님은 캐나다에서 일류 Graphic Programer로 오랜 기간 근무하시고, 대학에서 강의하시면서 준비하시고 정리한 지식들을 이 책에 정리해 놓았습니다. Programer와 Graphic Artist 모두를 고려한 내용을 말이지요!

다른 책에서는 한 번에 묶어서 설명하기 때문에 Graphic Artist 들도 어쩔 수 없이 같이 배워야 했던 DirectX Framework를, 이 책에서는 선택사항으로 단원마다 분리해서 그 부분이 필요없는 Graphic Artist 들은 그 부분을 건너뛸 수 있도록 배려되어 있습니다.
게다가 어려운 수학과 이론은 건너뛰고, 바로 실습해 볼 수 있도록 친절하게 준비되어 있는 모습이 마치 Graphic Artist 를 위해 씌여진 책으로 보일 정도라고 할 수 있습니다.

그렇다고 Programer들에게 부족한 책도 아닙니다. Shader를 처음 시작해 보는 프로그래머들이 Shader에 대한 기본 개념을 실습을 통해 쉽게 잡을 수 있도록 구성되어 있기 때문에, 이 책은 Graphic Artist나 Programer모두 만족할 수 있는 ‘실용적인’ 책이라고 말할 수 있을 것입니다.

부디 이 책이 많은 사람들에게 읽히고, 그들의 ‘즐거운 결과물’ 을 완성하는데에 밑거름이 되기를 바라는 바입니다.

Ndoors Tecnical Art Director 정종필

ShaderFX를 이용한, 그래픽 디자이너를 위한 기초 쉐이더 강좌 8강

Mon, 02 Jul 2012 00:51:34 +0000

어느덧 8강이 되었습니다. 벌써 UV도 깊게 다뤄 보시고!!! 색도 막 더해 보시고!!
UV가 흘러가게도 하셨습니다!!!

자 다시 정리해 볼까요.

일단 ShderFX를 다루기 위한 기초로, 기본 조작법을 익혔지요. 거기서 가장 중요한건, 여전히 0.0~1.0 사이로 끝나는 float 이라는 단위입니다. 여전히 중요하고, 앞으로도 중요할 겁니다.

그리고 노드를 연결하는 것과… 색을 숫자로 보는 법을 익혔지요.
지금도 색을 딱 보면 숫자가 딱! 하고 나와야 하는 거예요?!? 알겠지요?!? 딱~!

딱~!

그리고 드디어 UV 구조라는 걸 제대로 익혔구요, UV를 눈으로 보는 법도 배웠고 UV를 에니메이션 시키는 법도 익혔어요!!! 공부를 제대로 하셨다면, 1강때 설명한 것을 응용하여 지금까지 만든 쉐이더를 fx로 익스포트해서 친구에게 선물하실 수도 있겠지요!!

자 .. 그럼 이제, shader fx의 기본조작을 마치고, 중급조작 단계에 들어온거라고 할 수 있습니다.
중급조작에서는 이전 시간처럼 UV를 조작하고, 이미지를 다양하게 합성하게 되지요.
그리고 고급에서는…
고급에서는….
고급에서는….

알파 블렌딩과 라이트를 다룰 겁니다!!! 오메!! 어려워!!! 여기까지 과연 할 수 있을까!!!!

다 할 생각 해 보니까 아주 좋되는거야

자 .. 뭐 앞 일은 앞 일이고, 오늘은 그럼 오늘 일을 해 봐야죠.

오늘 할 일은 드디어 멀티 텍스쳐링입니다.텍스쳐를 섞는거죠.

우선 개념을 설명해 볼까요.

포토샵 정도는 쉽게 다루실 수 있으실 겁니다 다들. 이 강의는 일단 그래픽 디자이너를 위한 강의 이니까요.
포토샵에서 일단 이 이미지를 보실까요.

네.. 이전 시간에 줄기차게 썼던 또 그 이미지입니다.
강의를 쉽게 하기 위해서 익숙한 그림을 쓰는거지, 결코 다른 이미지 찾기가 귀찮거나 힘들어서 이러는거 아닙니다. [각주:1]

어쨌건 이 이미지를 포토샵에서 채널 창과 함께 보면, 이렇게 생겼죠.

이게 무슨 의미입니까? RGB 채널은 지난번에 말했으니까 그런가부다.. 하시고,
알파를 보세요! 이 풀 그림은 사실 풀 모양으로 이미 ‘따져’ 있고, 밖은 그냥 투명이라는 의미 아닙니까?

즉 이렇게 표현할 수도 있겠지요 .

네 … 이 그림은 풀 모양으로 추출되어서 플로팅 되어 있는 이미지입니다.
포토샵을 오래 쓰신 분들은, 저 체크무늬가 ‘아무것도 없는 허공’ 으로 보이신다는거 다들 알고 계실 겁니다.

특정 환자들에게만 투명하게 보이는 이미지.jpg

네, 알파 채널이 있는 이미지는 저런 느낌인 거지요.
다시 말해서, 저 이미지를 호랑이 이미지 위에 얹었을 때,[각주:2]

이런 느낌으로 얹어질 테니까,

결국 이렇게 얹어지게 될 거란 말씀입니다. 아시겠지요?

오늘 해 볼 것이 이거입니다. 일명 리니어 인터폴레이션 (Linear interpolation) 이라고 하지요.
두 이미지를 섞을 때 주로 사용하는 법이지요.

그러면 해 봅시다.

이번엔 plane 입니다. 하나 만듭시다. 주전자 만드는 것 만큼 쉽습니다.
모르시는 분은 주변에 물어보세요. 정말 별거 아닙니다.

거기다가 Tiger.bmp 를 맵핑으로 입혀 놓습니다.
이제 뭐 이거까지는 다 아시고 막 이러시잖아요.
진짜 이거 어떻게 하는거냐고 이 와중에 물어보시는 분 있으시면 때릴것임

때리러 오는 검은 삼연성

네 뭐 이 다음은 간단합니다.

여기다가 다른 이미지 한 장 겹치면 되는거지요.
그럼 일단 다른 텍스쳐 한 장 준비해 둡니다.
만만한 풀을 준비해 두지요.

엄청 만만한 풀 불러왔습니다.
저거 알파 채널 가지고 있는거, 다 아시지요? :)

자 이제 저 두 이미지를 “리니어 인터폴레이션” 해 봅시다.
그럼, 리니어 인터폴레이션 (일명 Lerp라고도 하죠) 노드를 불러 옵시다.

‘계산’ 계열일게 분명하니까 Math 아래에 있고,
MixLinearInterp 라고 씌여 있습니다. 다 쓰려면 다 쓰던가 ….. 뭐야 줄여쓰기는….

이걸 만들면 이렇게 생겼습니다.
제가 늘 칭찬하는게, 참 아이콘이 직관적으로 생겼어요 :)
뭔가 0 에서 1까지, 직선으로 그어져 있지요?

그리고 다시 잘 봅시다. 들어오는 값인 Input은 A와 B 두 개가 있습니다.
그리고 그 두 개를 ‘섞어주는’ 인자인 Blend Value가 있습니다.

그리고 그 둘이 섞여서 나오는 결과값이 Result 라고 있습니다.

척 생각해 봐도, 두 개를 섞는 거니까 Input A 와 Input B의 단위는 서로 같아야 할 것 같습니다. float2 건 float3건 말이죠. 그리고 섞는 값인 Blend Value는, 지금은 뭐 아무 값이나 받을 수 있게 되어 있습니다만… 사실 float 을 넣어줄 일 밖에 없습니다. 섞는거야 한자리면 충분하니까요.

이게 또 재밌는게, 오른쪽 메뉴에서 옵션만 바꾸면 리니어 인터폴레이션(Linear Interpolation) 이 스무스 인터폴레이션 (Smooth interpolation) 으로 바뀐단 말입니다. 이건 나중에 Smoothstep 이라고도 불리는데, 언젠가는 쓸 일이 있을 겁니다. (SSS 할때 쓸지도… 후후후) 그치만 지금은 안쓸거니까 신경쓰지 말고 리니어 인터폴레이션만 쓰기로 하지요.

자.. 그럼 여기의 A와 B를 각각 호랑이와 풀로 만들어 줍시다.

그럼 어떻게 보이나요?

검게 보입니다!!!! 무언가 잘못된 것일까요????

이런 표정 지으신분은 베란다에서 5분간 손들다 오세요.

이젠 슬슬 눈치 채실때가 되었지용

Blend Value에 아무 값도 넣지 않았잖아요.

shader FX 가 너무 자동으로 잘 해 주다보니까, 당연하다는 듯이 오류가 안생길거라고 생각하실 수도 있는데
이런 뻔한 오류는 일으켜 주는게 맞습니다.

자 그럼 당황하지 마시고, 저 Blend Value 에다가 숫자 1을 넣어 주시지요. [각주:3]

오오, 드디어 풀이 나왔습니다!!!
아니 그런데 호랑이는 어디 간건가요?

호랑이를 보고 싶으시면, 저 Blend Value에 0을 넣어 보세요.

오옷 , 0을 넣으니까 이번엔 호랑이가 나왔습니다!!!!
뭔가 짐작이 가능하시죠?
1을 넣으니까 Input B에 넣었던 풀이 나왔고,
0을 넣으니까 Input A에 넣었던 호랑이가 나왔습니다!

그럼 퀴즈입니다. 숫자 0.5를 넣으면 뭐가 나올까요?

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

정답 공개합니다.

딱 절반이 섞였습니다!!!!!

이제 명확해졌습니다!!! 리니어 인터폴레이션(Linear Interpolation)은, 0~~1 사이의 값으로 , 두 이미지를 섞어 주는 명령입니다!!!! 또 0~~1 사이야!!!! 도대체 0~1 로 못하는 것이 뭘까요???? [각주:4]

그런 스토립니다.

자자자자자자자
그렇다면 봐요봐요봐요봐요봐요봐요

저 풀은 알파 채널을 가지고 있어요 그렇죠?

알파 채널은 float 이예요 그쵸?

float이란 0~1 사이의 한 자리의 숫자란 의미예요 그쵸?

뭔가 또 생각나지 않아요?

전부 다 스토리가 연결되어 있던 거예요. 믿을 수 없게도…

이 풀의 알파 채널을 다시 봅시다.

이게 투명도를 나타내는 ‘숫자 덩어리’ 라고 말씀드렸잖아요. 아시겠지만 저는 친절하고 관대하므로 다시 한 번 자세히 설명드립니다.

관대합니다.

이 이미지를 확대해 보면 이렇게 되어 있죠.

이 한 픽셀 픽셀이 투명도를 나타내는 한 자리의 float 숫자라고 생각해 보세요.

흰색은 불투명도가 100% 이므로 1이고요
검은색은 완전히 투명하므로 0이고요
그 중간은 각각 그 % 에 맞는 색이겠지요.

즉 이 이미지들은 전부 한 픽셀 픽셀이 한 자리 소숫점 숫자란 말입니다.

여러 번 얘기했다는건 중요한 거예요 밑줄 좍 그으라고.

그러므로 이 숫자덩어리 알파 채널을 Blend Value 에 넣으면 어떻게 되겠습니까?

이렇게 된다고요

두 이미지가 블렌딩 된다고요

알파 채널의 픽셀이 흰색이면 1이니까 풀이 나오고, 알파 채널의 픽셀이 검은색이면 0이니까 호랑이가 나오고, 그 중간이면 그 중간이 나온다고요.

별 거 아니죠? :) 정말 쉽잖아요? 포토샵에서 레이어 올리는거 다 이렇게 동작하는 거예요. 똑같아요.

… 그치만 정말 별게 아닐까요?
여기서 부터 시작해서 응용되는게 장난이 아닌데???

정말 별게 아닐까요?

제가 요즘 게임테크 강연 준비하느라 좀 바쁩니다 (후후후)
강의를 더 길게 하고 싶은데 이번주는 좀 짧게 해야 겠어요.
http://www.zdnet.co.kr/news/news_view.asp?artice_id=20120308090801

그래서 오늘은 특별히! 숙제를 내 드리겠습니다.
어렵지 않아요. 위의 것의 응용입니다.
응용을 보여 드릴테니, ‘왜 이렇게 되는지’ 이해해 보세요.

그리고 실습해 보세요. 이게 숙제입니다.
이해도 못하고 그냥 따라만 하면 때릴 거예요!!!

숙제 다 했으면 댓글 써!!!!

숙제 다 한사람만!!!!

자 첫번째 이미지입니다.

풀이 멀티플라이 레이어처럼 어두워졌네요? 왜 그렇게 되었을까요?
그리고 또 이 어두운 정도를 조절할 수 있을까요?

풀이 이번엔 밝아졌네요? 무슨 일이 일어난 걸까요?
너무 밝은데 조금 어둡게 할 수는 없을까요? 이미지 수정 없이 말이죠.

엇 호랑이가 많아졌어요!!! 무슨 일이 일어 난 걸까요? 따라 하실 수 있으시겠어요????

오늘은 일단 여기서 끝냅니다.

게임테크 2012 강연 참가하고 나면, 이번엔 유니티 부트캠프에 또 강연 참가… OTL
그래서 바쁩니다.

그치만 이거… 쉬워 보이는데
이거에서 발전하면 별별거 다 만듭니다.

예를 들어

이렇게 얼룩이 알파 채널로 따져 있는 이미지와

깨끗하고 작은 벽돌 이미지 하나만 있으면

이렇게 얼룩진 벽도 간단히 만들 수 있구요.

더 응용해서 다다다음 시간쯤 되어서 더 실력이 올라가면 말이죠

맥스에서 실시간으로 동작하는 맵에디터를 만들 수도 있어요

다음 시간에는 버텍스 칼라를 이용한 Liniar Interpolation을 해볼까… 하고 생각하고 있습니다.
자 그럼 오늘은 바빠서 이만 총총.

뿅

믿어주세요 [본문으로]
일단 모든 이미지는 shaderFX를 깔았을때 , 3Dmax 설치 폴더 아래의 map폴더에 자동으로 같이 깔리는 이미지를 사용하였습니다. 이 호랑이는 tiger.bmp 입니다. 깔려 있어요. [본문으로]
숫자 넣는건 constant 라는거 잊지 않으셨죠? [본문으로]
프로그래머들은 이 용어를 잘 알고 있습니다. 사운드건 인공지능이건, 두 값을 적절한 조건에 의해 섞어줘야 할 때 “그거 그냥 리니어로 섞어줘!!!!” 라고 말하면 다 알아 듣습니다. :) [본문으로]

체력안배의 중요성

Sat, 30 Jun 2012 09:34:35 +0000

내 주위는 아직 젊어서들 그런지 이런 얘기가 덜 나오는데,
30대 넘는 개발자들한테 슬슬 제가 5-6년 전 했던 얘기가 나오기 시작했습니다. 그때는 아무도 들은척도 안하더니 ㅋㅋㅋ
아래 글을 읽고 좀 믿으란 말야. 당신들은 안늙을것 같아? ㅋㅋ

20대

한 2-3일 밤새는 것 까지 가능.
오버해도 하루만 푹자면 바로 회복
하루에 4시간 이하만 자고도 1달 정도 정신차리면서 버틸 수 있음.
육포와 콜라만으로도 연명 가능. 일주일에 한 번씩 갈비탕 정도 흡입해주면 회복.
HP로는 천천히 줄고 금방 차는 느낌이랄까.

30대

1일 밤새면 다음날 지장 옴
오버 페이스 해버리면 2-3일 후유증 옴
운동 꾸준히 하면서 체력 안배하면 새벽 2-3시까지 버틸 수 있음. 단 마지막 한 시간은 졸면서 버팀.
자꾸 먹어줘야 버틸 수 있음. 그래서 배가 나오기 시작.
HP는 평소에 계속 줄다가 하루 제대로 푹 자야 만땅충전되는 느낌.

40대

12시 넘어가면 정신이 혼미함
오버 페이스 해버리면 다음날 하루가 혼미함
운동 빼먹으면 그냥 하루가 혼미함
포션도 웬만한걸로 안됨. 양보다 질을 따지게 됨. 우리 아버지들이 왜 그리 몸에 좋은거 찾아 다녔는지 이해가 가기 시작함.
HP는 평소에도 적당한 빠르기로 줌. 심지어 쉬고 있는데도 줌. 하루 푹 잤는데도 만땅차지 않고, 깨어 나는 순간 줄기 시작함. 이미 출근하면 HP경고 ㅋㅋㅋ

아 걱정된다 50대 ㅋㅋㅋㅋ 운동하자..

부왘ㅋㅋ 다음메인에 떴구나.
블로그 폭발하는 줄 알았네 ㅋㅋㅋ

제주도 제주도

Thu, 28 Jun 2012 00:03:53 +0000

천제연 폭포 선임교 위에서 .

유리박물관

여행중에도 게임테스트 테스트.

비오는 사려니 숲길.

닐모리 동동

청강대 강연

Sat, 23 Jun 2012 23:10:50 +0000

청강은 정말 좋은 학고같아요.
산속에 폭 박혀 있는게
마치 군대온 느낌

아하하

하여간 아늑하고 정말 좋습니다.
나중에 여기서 강의 한 1년 해보고 싶다는.

버스커 버스커 - 첫사랑

Sat, 23 Jun 2012 20:43:53 +0000

FM7 G Em7   Am   FM7 G Em7 Am
                 FM7             G                   Em7                 Am
처음 널 봤을 때 왠지 다른 느낌 너와 함께 말하고 싶어 웃을 때마다
                     FM7               G                   Em7                  Am
이 마음을 알아가 이젠 널 볼 때마다 나의 맘이 너무나 커져 이젠 나의 시간은
         Dm7      Em7         FM7                   Gsus4                  G
항상 너와 웃으며 이 밤을 그리워하며 하루를 아쉬워하며 또 너를 기다리겠지
                FM7           G           Em7       Am
나는 어떡하죠 아직 서툰데 이 마음이 새어나가
         FM7        G        Em7       Am
커져버린 내 마음이 자꾸만 새어나가        FM7 G Em7   Am   FM7 G Em7 Am
              FM7            G                   Em7                 Am
네가 없을 때 왠지 아픈 느낌 이 마음을 전하고 싶어 눈을 감으면
                 FM7               G                   Em7                 Am
또 네가 떠올라 이젠 숨쉴 때마다 네 모습이 너무나 커져 이젠 나의 사랑은
           Dm7    Em7        FM7                    Gsus4                   G
항상 너와 웃으며 이 밤을 그리워하며 하루를 아쉬워하며 또 너를 기다리겠지
                FM7           G           Em7       Am
나는 어떡하죠 아직 서툰데 이 마음이 새어나가
          FM7       G       Em7       Am
커져버린 내 마음이 자꾸만 새어나가
F           G        Am         C       F         G          Am           C
아름다운 그대여 참아보려 했지만 어두워지는 밤과 외로움 알겠네 예
         FM7           G            Em7      Am
어떡하죠 아직 서툰데 이 마음이 새어나가
         FM7         G       Em7      Am
커져버린 내 마음이 자꾸만 새어나가
           FM7    G          Em7    Am
조금만 더 그대를 참아보려 했지만
         FM7        G           Em7        Am
커져버린 내 마음과 커져가는 니 마음이        FM7   G Em7 Am FM7 G Em7   Am

호주 여행기 4부 -태즈매니아

Wed, 06 Jun 2012 17:23:23 +0000

호바트 여행의 마지막 날이 밝았습니다.

오늘은 역시 또 ‘한눈에’ 여행이지요.

넵 호바트가 한눈에 보입니다.

저기로 똑바로 2박 3일 정도만 가면 남극대륙이라는 군요.
그래서 남극기지를 위한 베이스캠프를 호바트에 만들곤 한답니다.

반대쪽인 이쪽이 더 비싼 곳이랍니다. 이유는 북향이라서 말이죠.
호주는 남반구니까 북향이 더 해가 잘 들어오는 좋은 방향입니다 :)

해발 1280M 를 자랑하는 웰링턴 산이 보이는군요.

이제 저 산을 올라갑니다. 물론 차타고 올라가지요 :) 걸어서 아니예요

산 올라가는 중턱에 잠깐 서서 하이킹 맛보기.

태고의 자연을 자랑한다는 태즈매니아에 어울리는 나무, 옥토퍼스 트리입니다.

뿌리가 문어처럼 생겼거든요

이끼나 버섯에 대해 잘 모르고 관심도 없지만, 가이드인 토마스 리의 자랑이 대단합니다.

달인의 말씀을 듣고 보니 확실히 대단히 보이는 것 같기도…

웰링턴 산 정상에 왔습니다. 우와아아아 바람이 우와아아아아아아아아아아나란알낭라하나ㅓㅁㅇ라

저건 무슨 안테나라고 하네요

정상은 의외로 평평하고, 중간크기의 일정한 돌들이 굴러다니는 황무지 스타일입니다.

외계 행성이라고 치고 영화찍어도 어울리겠네요

구름보다 높기 때문에, 날씨가 조금만 구름이 많아도 산 아래가 아무것도 보이지 않습니다.

역시나 이번에도 비를 피해온 저희의 날씨 운은 대단히 좋네요

구름이 걷히고, 호바트 시의 전경이 다시 ‘한눈에’ 들어옵니다.

점점 더 걷히고 있습니다.

오오 드디어 호바트 시가 다 보입니다. 당연하게도 시야 끝까지 다 ‘한눈에’ 보이는 장관이 펼쳐집니다.

날씨 나쁠때 오면 정말 아무것도 보지 못하고 돌아가는게 되겠군요. 태즈매니아 여행은 날씨에 매우 민감하게 좌우될 것 같습니다.

다시 내려와서 점심으로 피쉬엔 칩스를 정말 잘하는 곳이 있다고 해서 간 곳.
좋습니다. 뭐 일단 할 건 다 하는 거네요 :)

여깁니다.

이건 그냥 생선요리이고

피쉬엔 칩스입니다.

사실 피쉬엔 칩스는 뭘 어떻게 만들어도 맛이 크게 다르지 않을 음식이긴 합니다만.. 네 꽤 맛있었습니다.
커다란 번데기 봉투에 담아주는 것도 인상적이었구요. 저걸 가지고 돌아다니면서 먹는다면..

그 이후에 호바트 근방의 유서깊은 마을들을 돌아보았습니다.

처음 생긴 성당이라던가..

1823년에 세운 다리라던가.. .

이것이 레알 ‘리치몬드’ 빵집.

아.. 배만 안불렀어도 저거 하나씩 다 사먹는건데..

이렇게 근방을 돌고 , 다시 공항으로 … 이제 돌아갈 때가 된거지요

호바트 공항에서 시드니 공항으로

시드니 도착 후 마지막 저녁식사를 합니다. 역시 스테이크.
서양에 왔으면 서양식을 먹어 줘야지요.

여기도 꽤 좋은 식당이라는데, 어디 호바트의 레스토랑과의 차이는 어떨지요.

일반 분위기는 먹어줍니다만 ㅎㅎ

스테이크가 나왔습니다. 츄릅.

스테이크의 퀄리티는… 태즈매니아에서 먹었던 것보다는 좀 못하군요.

그 대신!

캥거루 스테이크를 먹어봤습니다!!!!

오오 이것이 캥거루!!!

맛은 …………

뭐 소고기랑 비슷한데 약간 동물원 냄새가 살짝 나는군요 ㅎㅎ

좋은 테러사진이군요

마지막으로 내일 새벽에 일어나서 귀국해야 하기 때문에, 공항 바로 앞에 있는 호텔에서 마지막 숙박을 했습니다.

마지막 호텔이 가장 좋은 호텔이지만, 밤늦게 들어가서 새벽 일찍 나가니 별 의미가…

공항 앞이라서 워낙 새벽에 나가는 사람이 많다보니, 계산 편의를 위해 방 안의 냉장고에는 아무것도 들어 있지 않고 이렇게 복도에 바가 준비되어 있는 시스템입니다.

새벽 6시에 아침식사… 그 후 바로 아침 비행기를 타고 한국으로 귀국합니다. 집에 가면 밤 늦은 시간이 되는.. 말그대로 하루 종일 이동하는 거죠

돌아옵니다.

이 때 근방의 핸폰 사진들이 다 날라가서 이 이상의 사진이 없네요.

한국 와서 좋은 점은 … 역시 인터넷이 장난아니게 빨라!! 속이 다 시원하네요 :)

어쨌건 이렇게 잘 갔다 왔습니다.
좋은 점이라면 이 짧은 기간 안에 호주의 도시와 자연을 대표한다고 할 수 있는 시드니와 태즈매니아를 모두 갔다왔다는 것이겠지요. 중요한 곳은 모두 갔다 왔다는 느낌. 시드니는 포인트만 거쳐간 느낌이었고, 진짜 여행은 태즈매니아 같았습니다. 사람의 흔적이 전혀 닿지 않은 태고의 자연을 보고 싶으신 분들에게 추천합니다.

하지만 아쉬운 점이라면 역시 패키지의 특성상 좀 훑고 지나간다는 점이겠지요. 어쩔 수 없는 것 이해합니다. 짧은 일정이었으니까요. 그리고 덕분에 이동거리가 길어서 너무 피곤했다는 것 정도. 돌아와 보니까 입술이 퉁퉁 부르터 있더군요 :) 이 여행을 하시려면, 체력을 일단 만들어 두시는게 가장 중요할 것 같습니다.

http://blog.naver.com/prologue/PrologueList.nhn?blogId=ilovetas&skinType=&skinId=&from=menu&userSelectMenu=true

태즈매니아달인 토마스 리 블로그

호주 여행기 3부 -태즈매니아

Wed, 06 Jun 2012 17:21:51 +0000

태즈매니아 호바트의 아침이 밝았습니다.

확실히 좀 더 차가운 공기예요

여기에서 만난 가이드분은, 태즈메니아 전도사로 유명하신 토마스 리 이십니다 :)
당연히 가기전에는 몰랐는데, 가서 얘기 나눠보니 .. 알고보니 유명하신 분!

http://blog.naver.com/prologue/PrologueList.nhn?blogId=ilovetas&skinType=&skinId=&from=menu&userSelectMenu=true

여기가 블로그입니다.

이분입니다.

태즈매니아 가실때는 토마스리를 찾아주시길. 강추합니다.
이분이랑 얘기하면

… 이 분 만난 기분이 듭니다.

태즈매니아 와보셨어요? 안와보셨으면 말을 하지 마세요 (…) ㅋㅋㅋ

길가다가 갑자기 과일가게 가서 사과 사주시고 ㅋ 태즈매니아 홍보에 열심이십니다.
말씀하시는건 완전 고향 형님 만난 스타일 ㅋㅋㅋ

가이드가 자기 사진 안찍어준다고 삐치는거 첨봤 ….. ㅋㅋㅋㅋ

호주에는 은근히 한국차가 많습니다. 썬팅도 안한건 좀 이채롭네요.
일본 차보다는 적지만, 기아와 현대의 차들이 꽤 많이 보입니다. 한국에는 보기 힘든 i20도 있네요.

어딜 가는거야 …

수동적인 여행자는 자신이 어디로 가는지도 모르고 따라갑니다.
사실 뭐 차에서 설명해 주셨는데 맨 뒤에 앉은데다가 차 소리가 시끄러워서 들리지도 않았어요

응? 카페리에 차까지 싣고 어딘가 또 바다를 건너갑니다. 또 섬으로 가는거야???

나중에 알고 보니 여기 브루니 섬으로 또 가는 거였군요. 브루니 섬은 노스 브루니와 사우스 브루니로 나누어져 있는데, 저희는 사우스 브루니 맨 아래를 목표로 가고 있었습니다.

그렇게 10 몇 분 정도 페리를 타고 건너간다음. 다시 차를 타고 한참 갑니다.
오늘 일정이 이거 하나뿐인 이유가 있군요… 차를 한참 타고 가야 합니다.

차 타고 가다가 중간에 쉰 곳은 ‘굴 공장’

굴은 이렇게 먹으랍니다.

굴 판매하는 박스에는 낙서가 가득.

신선해 보입니다만

저는 굴을 못먹으니 그림의 떡 …

오늘의 여행은 크루즈 - 스피드 보트에 가깝지만 - 에 탑승하는 것입니다.

뭘까요 그게? 여기까지 내려와서?

한려수도 같은걸 니나노 ~ 하면서 보는 걸까요?

기다리는 동안 먹은 커피와 머핀.
머핀은 특히 맛있더군요. 블루베리가 톡톡 터지는 것이… 아 군침돌아.

탑승을 기다리면서 해변가를 봤습니다.
구름이 끝없이 보이니, 굉장히 낮아 보이네요 ..

이걸 타려고 몇 시간이나 걸려서 온 거로구만요. 저게 뭐길래 그럴까요 대체.

응? 타는 사람마다 저 빨간 옷을 줍니다. 두꺼운 방수포로, 추위와 물을 막을 수 있게 되어 있네요. 모자까지 달린 완전무장형 원피스입니다.

게다가.. 타는 사람 모두에게 멀미약을 줍니다 . 뭐야 몰라 무서워…

무슨 일이 일어나려고 그러는 걸까요…

출발합니다. 부우우우웅.

앞에서 두 번째 탔는데, 거의 앞이 들린채 달리는 군요. 옷을 든든하게 입기를 잘했다는 생각이 든 유일한 때입니다.

잠시 몇 억년이 되었다던 자연들을 감상해 보죠.

멋지긴 합니다만 어메이징 수준은 아닌데 아직… 흠..

총 3시간 코스이므로 시간은 아직 많이 남았지요

음… 좀 파도가 거칠어지기 시작합니다. 배도 많이 흔들리구요.

어라… 파도가 점점…

어라라랏 파도가 장난이 아닙니다.
마치 원양어선이라도 탄 듯 어두운 바다가 마구 요동치는 모습을 보니 무섭네요.

바다사자다 바다사자.

한시간 반 쯤 남쪽으로 더 내려가니 바다사자가 사는 곳이 나옵니다.

으아아아 바다사자가 득시글대

배 좀 타보신 분들에게는 아무것도 아닌 파도일지 모르겠지만,
육식동물초식동물로 평생 살아오던 저같은 사람에게는 충분히 자극적인 파도입니다.

낮은 강도의 바이킹을 3시간 타고 있는 느낌이랄까요. 멀미약의 효과는 굉장히 좋았습니다.

이 거친 바다에 , 이 태고의 자연에서 뒹굴고 있는 바다사자들… 뭔가 신기한 곳을 엿본 느낌이 나는군요

돌아오는 길에는 잘하면 돌고래와 고래도 볼 수 있다고 하던데, 애석하게 저 새 외에는 한 마리도 못봤습니다. 아쉽네요 진짜. 다시 언제 올 지도 모르는 곳인데…

돌아왔습니다. 아 위험했어요. 그다지 멀미 안하는 저지만 1시간 정도만 더 탔었다면 위험했을듯. :)

돌아와서 먹은 큼지막한 샌드위치

오이는 저의 원쑤. 오이를 죽입시다.

점심에 먹은 ‘데빌’ 그림이 그려져 있는 진저비어.

비어라고 해서 술인줄 알았는데 그냥 음료수예요. 그것도 생강 음료수!!! ㅎㅎㅎ 오오오 특이한 맛.

한 번 먹어볼 만은 해요. 먹고 나서 계속 먹을지는 취향에 좀 갈리겠습니다만.

돌아오는 길에 본 사우스 브루니와 노스 브루니를 잇는 도로 입니다. 전망대도 만들어 놔서 보기 참 좋네요.

여기 가운데에 있는 저 얇은 라인입니다.
한쪽은 만이어서 파도가 거의 없고, 한 쪽은 남태평양과 바로 이어져서 파도가 꽤 있지요.

역시 ‘한눈에’ 절경을 볼 수 있는 여행입니다. 한눈에 여행.

한 컷 더 크게 보지요.
거기서 잠시 원주민들의 삶에 대해서, 죄수들을 이주시켜서 만든 호주라는 나라에 대해서 설명을 듣고 해변가로 내려옵니다.

해변가 근처의 이 굴은 팽귄이 사는 굴이라는군요!!! 저녁에 돌아온다나요!! 팽귄이 굴에 산다는건 첨 알았네요!!!

해변가의 토마스 리 이십니다

해변가의 그림자샷.

정말 깨끗하고 사람의 흔적이 없는 자연을 실컷 본 느낌이랄까요

벌써 해가 지려고 하네요.
늦가을이어서, 저녁 5시만 되면 이미 캄캄한 밤이 됩니다. 4시 정도만 되면 노을이 지려고 해요.

오는길에 치즈를 좀 사러 들른 가게.

치즈들입니다. 치즈는 꽤 맛이 괜찮았었는데, 가져올 수가 없다는게 참 아쉬웠네요 .

저녁 식사는 저희 일행들의 요청으로 ‘호바트의 가장 맛있는 스테이크집’ 으로 결정했습니다.

스테이크 사진을 못찍었네요.

… 정말 맛있었거든요.

호주 여행한 동안에는 가장 맛있었고요. 제가 여태까지 먹어본 스테이크중에서도 3손가락 안에 들 정도의 맛이었습니다. 역시 토마스 리가 태즈매니아의 소고기를 칭찬할 만 하달까요. (제가 여태까지 먹어본 스테이크중 최고는 LA의 블랙 엥거스에서 먹은 엥거스 스테이크였습니다.. 츄릅… 한국 앵거스는 절대 그 수준이 아니예요 )

식당 주변을 살짝 산책하면서 하루의 일과를 끝마쳤습니다.

다시 호텔로 복귀. 이번 여행 유일하게 2일밤을 자는 호텔이라, 짐을 정리할 필요가 없어서 좀 편합니다.

간만에 조금 여유가 생긴 김에, 그 동안 해보고 싶었던 실험을 하나 했습니다.

바로 물 빼기 실험!!!!

제가 초등학교때인데요. 책에서 아주 인상깊은 구절을 읽었었지요.

" 북반구에서는 물이 빠질때 시계 반대방향으로 돌면서 빠지는데, 남반구에서는 반대로 돌면서 빠집니다. 즉 호주에서는 물이 시계방향으로 빠지지요"

어렸을적 이걸 보고 ‘진짜?’ 라고 생각했었지요. 눈으로 직접 보고 싶었다는 겁니다.
그리고 이 실험을 드디어 할 수 있게 되었다는 거지요 ! 정말 시계방향으로 물이 빠질까????

오오오! 정말 오른쪽으로 돌면서 빠집니다!!!
실험을 위해서 물과 호텔 샴푸를 좀 낭비했습니다만, 정말 알고 싶었거든요. 평생의 소원이 이루어진 느낌입니다.
전 원래 이런 작은 디테일을 즐기는 것을 좋아하는 스타일이라 말이죠 ㅎㅎ

이렇게 태즈매니아의 밤이 저물었습니다. 내일만 여행하면 드디어 끝이군요.

호주 여행기 2부 - 시드니

Wed, 06 Jun 2012 17:20:01 +0000

야경 코스는 하버 브리지 도보 횡단입니다.

저 걷는거 짱 좋아해요. 이런거 좋습니다 :)

약간의 매연만 참으면 괜찮습니다.

장노출로 찍어서 사람이 없는걸로 보이지만 사실은 사람 꽤 많다는.

오오 드디어 보입니다. 시드니 노래방

마침 비비드(Vivid) 라고 하는 조명 축제 기간이라, 조명이 자꾸 바뀝니다.

막 그림도 그려지고 막 그래요

도시들도 조명이 막 바뀌고 그럽니다.

그렇게 다리를 건너가자, 건너편에서 뭔가 축제를 하네요.

오오 저 이런거 좋아합니다 :)

특히 좋아하는게 길거리 음식.

이런거 좋아요 좋아 ㅋ 꼬치구이예요. 맛있네요 ㅎ
주문하고 사먹고 보니까 한국 유학생이 팔더군요.

오오오 딸기 초코렛 코팅

역시 안먹어 볼 수 없지요. 저녁까지 먹어서 배부르지만…
딸기와 초코렛이 아주 잘 어울려서 두 개나 사먹었습니다.

VIvid는 빛 축제라서 그런지 이런 퍼포먼스들도 많이 보였구요

책도 팔길래 기웃대 봤습니다.

어라 저 가운데 있는 책은 …

이 짤방의 그놈이군요.

하지만 무엇보다 가장 맛있었던건 이거였습니다.
단순해 보이는 옥수수 버터구이에 후추를 뿌린 것 뿐이지만, 그 맛이 엄청나게 잘 어울려요!!!

게다가 옥수수가 물이 많아서, 한입 무는 순간 과일처럼 물이 터집니다!!! 옥수수가 이렇게 부드러운 맛이었다니!!

배가 완전히 부른 상태만 아니었으면 몇 개 더 먹고 싶었을 정도의 맛이었습니다.

구운 옥수수에 후추가 이렇게 잘 어울릴줄 몰랐네요. ㅎ

다시 오페라 하우스 야경을 관람하러 갑니다.
이젠 무슨 움직이는 조명을 쏘는군요. 왠 여자와 남자가 굴러다닙니다.

축제 분위기 나고 좋군요 시끌벅적합니다.

오페라 하우스 아래에 있는 테라스에서 맥주 한잔.

맥주가 괜찮기는 한데, 술을 즐기는 편이 아니라 얼마나 좋은지까지는 잘 모르겠어요.
어쨌거나 운전하는게 아니니 맥주를 안심하고 먹을 수 있는건 정말 좋구만요.
배부른게 문제지…

막 이상한 그림도 쏘아집니다.

이렇게 건너편에서 레이저로 쏘는 거라고 하네요.

요새 레이저는 저렇게 할 수도 있나봐요

그렇게 NOVOTEL SYDNEY OLYMPIC PARK HOTEL 호텔로 들어오니 밤 12시 30분…

전날은 비행기에서 쪽잠자고 아침부터 지금까지 돌아다니니 녹초가 안될래야 안될 수가 없겠지요.
패키지 여행은 확실히 ‘아무 생각 없이’ 다닐 수 있어 좋긴 합니다만, 저같이 느린 여행을 좋아하는 취향의 사람한테는 좀 힘듭니다.

하루종일 쓴 전자제품을 충전 걸어놓고 잠이 듭니다. 그렇게 호주에서의 밤이 지나갑니다.

다음날 아침도 일정이 바쁘니 일찍 일어 납니다.

호텔의 아침식사는 뭐 다 그런그런 메뉴지만, 여긴 꽤 괜찮은 편이네요

특히나 빵의 품질이 좋아요.

두 번째 날이 시작되었습니다.
두 번째 날에는 패키지다운 코스인 쇼핑을 좀 하고 …

역시나 시드니 시내가 ‘한눈에’ 보이는 Mrs Macquaries Point 로 이동합니다 .

일명 ‘증명사진 찍는 곳’

여깁니다 여기.

여기서 사진을 찍으면

이런 사진을 찍을 수 있지요

사진찍는 곳에서는 이런 흔한 호주의 나무가 …

햇살은 뜨겁고, 건조하면서 바람은 찹니다. 정말로 산책이나 조깅하기에는 최고의 날씨.

고개를 조금 돌리면 시드니의 시내가 보입니다.

그야말로 시드니의 증명사진 찍는 곳이네요.

이번엔 밤에 갔던 오페라 하우스를 다시 낮에 가 봅니다.
왼쪽 아래가 어제 술먹었던 테라스네요

왠지 듄2 라는 게임이 생각나는 디자인이네요 …

현재 공사중이긴 했습니다만, 그런대로 볼 만큼 개방되어 있었습니다.

오페라하우스의 지붕은 이렇게 생긴 타일들로 만들어 진 것이구만요

오페라 하우스의 디자인 컨셉을 설명한 조각입니다. 공에서 떼어낸 걸 보니 수박 맛보기 컨셉 (…)

이렇게 관광을 끝내고 간 곳은 크루즈 배에서 먹는 점심식사입니다.

패키지 여행은 정말 편하고 요점만 찍어주는 참고서 같습니다. 편하고 빠르게 관광을 할 수 있긴 한데…
뭐랄까 과정이 생략된 정답만 보여주는 느낌이랄까요. 그래서 감상이 별로 없습니다. ㅎㅎ
과정을 생각하기 보다 결과만 생각하니 여행기도 단순히 ‘찍고 오는’ 기록중심이 될 수 밖에 없겠지요.
뭐 짧은 일정에 다 돌려니 어쩔 수 없습니다만…

배 안은 이런 식당이네요

종류가 다양한 편은 아니지만 품질이 좋습니다. 일단 외국 나오면 느끼는 것들이, 재료의 신선도가 다르달까.

특히 저 후식인 초코와 치즈케잌은 환상적이었어요 . 우왕…

그렇게 식사를 하면서 다시 시드니 하우스 근처를 돕니다.

하버 브리지를 낮에 보니 확실히 사람들이 보이는군요.
아치형 철교에 사람들 바글바글한거 보이세요?
저길 걸어서 통과하는 여행 코스가 있다는군요.

국기는 호주 국기와 원주민 국기가 걸려 있습니다.

아아 햇살은 정말 죽이네요…

수상 버스를 비롯하여 많은 배들이 왕래하고 있습니다.

엇… 그 유명한 멕쿼리군요… 호오… 나꼼수에 많이 나오던

성 마리아 성당에도 갔었구요.
… 실내가 정말 신앙돋게 생겼는데 사진촬영이 금지라는게 아쉬움..

오늘 일정은 더 빡빡합니다.

타즈매니아 라는 섬으로 가야 하기 때문에 6시 정도에 출발하는 국내선 비행기를 타야 합니다.
덕분에 4시에 저녁밥을 먹어야 하죠.

저녁은 한식. 뭐 저 혼자 가는 거였다면 외국에서 한식은 절대로 안먹겠습니다만 … ㅎㅎㅎ

식당 옆에 있는 성인 인터넷 게임방 간판이 이체롭습니다.

가이드 아저씨의 말씀 “저기 망했어요. 누가 가요 호주에서 저기를”

밥 먹고 공항으로 이동. 태즈매니아로 이동해야 할 시간이지요.

호주는 국내항공이 잘 발달되어 있다는군요. 그래서 그런지 거의 고속버스 터미널 같은 분위기입니다.

아 저거 사고 싶 …

약 한시간 반 정도의 비행 후에, 태즈매니아에 도착했습니다.

태즈매니아?

첨엔 거기가 어딘지도 몰랐어요 -_-

알고보니 여기더군요.

뭐야 작잖아.. 라고 생각했지만

저 섬이 거의 우리나라 만하다는게 함정 -_- ;;;

큰 섬이었습니다. 호주 최남단의 섬이요.

타즈매니아, 태즈매니아, 태즈메이니아, 타즈메이니아, 테즈마니아, 타즈마니아 등 다양한 이름으로 불리고 있어서 참 검색하기 곤란하더군요 ;;

더욱 더 시골 버스터미널 스러워진 공항. 더 추워진 기후 (남쪽이니까요) 더 맑은 공기, 더 맑은 하늘…

태즈매니아의 호바트에 도착하였습니다.

어느 정도로 맑냐면… 지금 저 상태에서 고개를 위로 들어 올리면 은하수가 보일 정도입니다. -_-;;; 세상에..

시드니 여행이 도시를 보는 거였다면, 태즈매니아 호바트는 자연을 보는 여행이더군요. 역시 ‘한눈에’

가이드분과 간단한 미팅을 하고, 애매한 저녁식사로 쌀국수집을 갔습니다.

베트남식 쌀국수인데, 맛이 독특하더군요. 좋은쪽으로 독특했습니다.

그리고 나서 호텔도착. 오늘도 지쳤어요…

호텔은 마치 영국에서 봤던 것 같은 , 고풍스러운 호텔입니다.

이걸보면 확실히 호주가 영국령이라는게 느껴져요

호텔방도 매우 좁고 깁니다. 고풍스럽고 낡은 가구와 창문들… 딱 영국 스러워요

왜 내 방이 Lee 냐고 직원한테 따졌는데 ㅋㅋㅋ 나는 Jung 인데!!!

알고보니 저게 227호를 쓴 걸 뒤집어 본 것 ㅋㅋㅋㅋㅋ 야이씨 저게 어떻게 227이야 ㅋㅋㅋㅋㅋ

역시 정리하고 충전준비 완료하고 쉽니다.
매일 호텔을 바꾸는건 힘들어유…

호주 여행기 1부 - 시드니

Wed, 06 Jun 2012 17:16:05 +0000

호주.

오스트레일리아.

오스트리아 아닙니다. 오스트리아와 오스트레일리아(호주) 는 다른 나라예요.ㅋ

그렇게 하도들 혼동해서, 오스트리아에 가면 이런 표지판이 있다고들 하지요. 확인해 본 적은 없습니다만.

네이버 검색만 해봐도 오스트리아가 호주라고 하는 글이 좌르륵…
‘호주 관광청 답변’ 이라는 개그글도 있구요 :)

http://clien.career.co.kr/cs2/bbs/board.php?bo_table=park&wr_id=11656981

네 어쨌건 호주에 가게 되었습니다. 가는데만 10시간이 걸리는 비행이라고요.
더군다나 이번에는 평소와 같은 자유여행이 아니라, 일정이 빡빡하게 짜 있는 패키지 여행입니다.
회사에서 8년차 이상인 사람들 대상으로 보내준 해외 여행이지요.

(3년, 5년차에 는 각각 동남아와 유럽을 가는데, 8년차 첫 여행을 맞아 남반구를 가보기로 했지요)

비행기는 저녁에 출발합니다. 비행기에서 밤을 지내는 거지요. 내리면 다음날 아침이라는 스토리.
미국을 몇 번 갔다왔다고 이제 장거리 여행에 기술이 좀 생겼습니다.
장거리 비행을 위한 기술과 장비는 나중에 공개하도록 하지요 호호홍.

일단 이건 기술이 아닙니다 절대.
근데 저는 개인적으로 공항에서 외국에 나갈 때에는 꼭 KFC를 들르는 이상한 버릇이 있…
비행기 안에서는 고생하게 되면서도 이상하게 꼭 가게 되더라고요.

출발했습니다. 간만에 가는 아샤나.

KFC를 들렀다고 기내식을 안먹는 것은 아닙니다.

한잠 자고나니 아침밥을 주시네요 .

또 하나 개인적으로 해외여행의 버릇은 두 가지 정도가 더 있는데
하나는 그 나라의 맥도날드를 가는 것이고
또 하나는 그 나라의 콜라를 먹어보는 것입니다.

이 콜라는 꽤나 마이너한 콜라인데, 바닐라 맛이 나는 바닐라 콜라입니다.
일반 콜라가 없는건 아니지만, 간만에 보니 반가운 기분에 집어들었지요.

주로 멀리 가는 여행은 유럽이나 아메리카 대륙이어서, 계절은 비슷하지만 시차가 다른 여행이었습니다.
그렇지만 호주는 시차가 1시간 밖에 안나네유 (여름엔 섬머타임으로 2시간)
시차는 거의 안나지만, 가는 동안 적도를 지나가니까 … 봄 -> 여름 -> 가을로 가는, 시차가 아닌 계절차가 나는 신기한 경험이었지요.

… 춥겠네요 그럼. 여기는 늦봄이니까 거기는 늦가을 … 우와 춥겠다…
덕분에 옷가방이 커질 수 밖에 없게 되었지요. 음음.. 그래서 겨울옷을 잔뜩 가져 갔는데… 꽉꽉 가져 갔는데…..

안춥네요

안추워요. 네. 아니 뭐 기온은 8도에서 18도를 오르락내리락 하는데, 추운가? 뭔가 묘한 느낌
묘한 느낌. 기온은 살짝 낮은게 맞고 바람도 센데, 바람이 차지 않고 시원한데다가
무엇보다 해가.. 햇살이… 우리나라에서 보던 햇살 *5 정도 되는 느낌이랄까.
그래서 안춥습니다. 그늘에 있으면 좀 춥다 느낄 정도고 , 열 있는 사람은 시원하다고 할 정도.

묘해요 이게. 춥다면 춥다고 할 수도 있고, 적응되면 괜찮다고 할 느낌이랄까?
때문에 점퍼를 입고 다니는 사람도 있는가 하면 민소매에 반바지를 입고 다니는 사람도 있더라고요.

호주는 영국령입니다. 그래서 유니언잭에, 호주의 6개 주를 상징하는 여섯 별이 그려진 국기를 사용하고 있지요.

호주의 동전. 특이하게도 작을수록 금액이 높고, 금색이 달라고 은색이 센트입니다.

날씨 운은 최고였습니다. 저희가 오기 전날까지 비가 왔었다는데… 저희가 있던 동안에는 쨍쨍했네요.
그리고 저희가 떠난 직후 비가 또 왔다죠 아마.
하늘에는 스카이박스가 없이 그라디에이션으로만 표현해 놨습니다. (직업병 발언이었습니다. 신경쓰지 마세요)

처음 간 곳은 대관령 양떼목장 TOBRUK SHEEP STATION

아니 뭐 진짜 목장은 아니라는 것 같네요. 일종의 ‘관광객용’ 목장이랄까.
저 멀리에서부터 양치는 개가 양 무리를 빙글빙글 돌면서 몰아옵니다.

양에게 먹이를 준다던가… 양털을 깎을 양을 분류하는 개의 시범을 본다던가 말이죠. 이런걸 하는 곳이예요.
양털들을 깎을만한 놈들을 거의 없었죠 사실.

이제 양 몰이 개의 순서는 끝나고, 양 분류 개의 활약이 펼쳐집니다…

양 분류 개의 활약은 너무 길어서 올리지 못하는게 한스럽군요.

이렇게 분류된 양은 다시 손님들 앞에서 털을 깎이게 됩니다.
솔직히 털 깎을 만한 양은 없는데요. 손님들 계시니까 할 수 없이 깎이는 거지요.
곧 겨울인데 불쌍하네요 (…)

여기가 털깎기 시연하는 곳입니다.

이 할아버지가 꽤 유명하신 분인가 봐요. 돌아올때 기내에서 비치되어 있던 잡지에도 나오시더라고요.

여러 가지 역사에 대해 설명해 주십니다만, 영국식 악센트는 잘 안들린다는게 문제

털을 깎으면 이렇게 등급에 따라 분류해서 전세계로 보내지게 됩니다.

사실 어그부츠의 유래도 여기서 시작되었던 것이지요. 어그부츠는 사실 실내화래요. 호오… 어그부츠가 호주꺼라는거 처음 알았네요. 아무런 사전지식 없이 여행온 여행자 티가 팍팍 나는군요.

이건 그냥 바리캉이라고 생각하시면 됩니다. 양 털 깎는 녀석이지요.

오늘의 희생양 (정말로 희생양이구만요) 이 질질 끌려 나옵니다!!

양 털을 깎을때에는 일정한 순서가 있고, 양을 잡는 방법이 있습니다.

순식간에 한 마리의 털이 밀리는군요

제대로 자란 털은 이렇게 된다는군요.

양털 깎기 쇼가 끝난 다음, 스테이크로 점심식사를 합니다.

양고기 아닙니다. 소고기예요. 양고기는 비싸다는군요. 살짝 기대했는데…

호주의 원경은 정말 어디를 봐도 훌륭합니다. 공기가 워낙 맑은데다가 건조해서, 정말 ‘시야 끝까지’ 보이거든요.

저 멀리 보이는 유달리 파란 산맥은 블루 마운틴이라고 부른다고 한답니다.
특별히 푸른빛을 띄는 유칼리투스 잎 때문이라네요.

점심식사후 채찍 시범.
채찍의 끝에 붙어 있는 부분이 땅에 닿을때 어마어마하게 큰 소리가 납니다. 거의 충격파만으로 따지면 총소리에 맞먹을 정도. 나중에 전부 실습해 봤는데… 생각보다 쉽게 잘 나더군요.

부메랑 시범.
원래 던지기에 재주없는 저는 부메랑을 직선으로 날려버리는 만행을 저지르게 됩니다 (…)

이렇게 첫 패키지 코스를 끝내고 이동.

참고로 호주는 영국령이라, 차도 오른쪽으로 다니고 여러 가지가 영국과 닮았습니다.
자연을 보면 미국처럼 살지만 나라의 속성은 영국같은 느낌이랄까.

두 번째로 간 곳은 코알라 파크. 그냥 동물원입니다.
가이드분이 사진에 출연하셨네요 :)

코알라!

만질 수 있어요! 만졌어요!!

길거리에 막 돌아다닌다던가 한다는 소문을 들은 것 같았는데, 도시만 돌아다니다 보니 그런건 못보고…
어쨌거나 코알라를 드디어 만났습니다.

이상한 칠면조 같은 녀석도 걍 돌아다니고 있고.

무엇보다 코알라 ㅋㅋㅋㅋㅋ 어쩔꺼야 ㅋㅋㅋㅋㅋ

엉덩이로 나무잡고 자는게 웃겨요 ㅋㅋㅋㅋㅋㅋ

그리고

냄새 쩔어요 … ㅋㅋㅋㅋ

에이씨 자는데 깨우고 있어

유칼리투스 나무랍니다. 자동차와 박으면 자동차만 부서질 정도로 단단하다는군요.
그래서 그런지 전봇대도 전부 저 나무고, 이곳저곳에 쓰이고 있습니다.

캥거루? 아닙니다. “왈라비”

캥거루 사촌이라는 듯.

왔어?

머리에 줄무늬가 있고, 크기가 작은게 특징이랍니다.
저 주먹 어쩔꺼야 ㅋㅋㅋㅋ 귀여워 ㅋㅋㅋㅋ 만화 주먹같아 ㅋㅋㅋㅋ

이게 캥거루 ㅋ

점프를 4미터나 할 수 있다는데요 (정말?)
여기가 편해서 걍 동물원에 산다고 가이드 아저씨가 말씀해 주셨어요.

에… 너 이름 잊어먹었다… 이상한 이름이던데…

동물원 관광을 끝마치고 … 더들리 페이지에 왔습니다.

여기는 시드니 시내가 ‘한눈에’ 보이는 포인트라고 합니다.

음… 이 여행 자체가 ‘한눈에 여행’ 이예요.
여행 일정표에 보니까 대부분 ‘한눈에 볼 수 있는’ ‘전경을 한눈에 볼 수 있는’ 이라고 씌여있는 일정이더라고요.

‘한눈에 여행’

그 다음으로 간 곳은 근처에 있는 갭 팍 (Gap Park)

위치는 대충 저 정도 되는 위치입니다. 시드니로 들어오는 바다가 시작되는 곳이죠. 경치는 훌륭합니다.

남태평양이 ‘한눈에’ 보이는 곳이지요.

그다음으로 간 곳은 본다이 비치.

본다이 비치는 모래가 아주 고운 해변입니다.

거기다가 특성상 매우 건조해서, 해변가 특유의 퀴퀴한 냄새도 나지 않고 산뜻하고 건조합니다.
일단 근해 어업이 없어서, 부산물 같은 것도 없어서 깨끗해요. 4면이 바다인데 육식을 주로 먹어 (…)

그래서 저 모래도 우리나라 모래처럼 달라붙지 않고, 그냥 툭 털면 깨끗하게 털어집니다.

갈매기 발자국. 우리나라 비둘기처럼 다녀요 ㅋ

안도망가 이쉐키

서서히 해가 지기 시작합니다.
하늘 색깔 한번 참 …

노을을 보면서 맥주 한잔 하기로 했지요.

그런데! 본다이비치에 노을이 지자 황금도시가 출현하더군요

멋지니까 한 장 더.

아아아 태양이 강렬한 나라는 역시 모든 자연의 색의 강렬합니다.
아름답군요.

이래놓고 귀국하면 우리나라는 전부 회색으로 보여요. 크흑.

대충 찍어도 이런 색이 나오니까요.
행여나 카메라에서 색상을 좀 세게 건드리면 완전 비상식적인 색깔까지 나오게 됩니다.

다음은 저녁식사.

호주에 있는 한국인이 경영하는 일본식당 (…) 에서 돈까스를 먹는 나.

이건 마치 우리 회사 2층에 있는 쌀국수집 호아센과 같은 구조

“한국에 있는 호주식 베트남 쌀국수집”

저녁은 선택코스인 하버 브리지 야경관람입니다. 이상 1부 끝

Unity Shader Tip

Thu, 17 May 2012 08:53:57 +0000

Alphatest 큐 -> 번호는 2450.
지오메트리의 큐 범위가 2500까지이므로, 지오메트리 영역에 속하지만 나중에 그린다.
즉 지오메트리 -> 알파테스트 -> 알파블렌딩 순서로 그린다고 보면 된다.

Multi_compile
최종 컴파일할때 다양한 에디터 환경에 따른 셰이더 코드들을 생성해 내는 옵션
예를 들어 Multi_compile_fwdbase는 포워드 패스일때 사용.
(라이팅 모드를 뭘로 해놨느냐에 따라서 결정되어야 할듯)
debug fragma를 이용하면 아마도 결과물을 비교해 볼 수 있을듯 하다.

결과물은, 경우별로 키워드들이 여러개 정의되어서 여러개의 코드가 생성된다.(… 뭘까)

나중에 함 해봐야지

NDC 2012 강연자료 "Unity3D로 만드는 Web Full 3D MMORPG"-삼국지를 품다의 테크니컬 아트 공개합니다.

Wed, 25 Apr 2012 23:53:16 +0000

Unity3D로 풀3D web mmorpg 만들기

View more presentations from jpcorp

강연이 무사히 잘 끝났습니다.
매년 발전하는 NDC를 보니, 솔직히 이제 조금만 글로벌해지면 GDC를 위협할 것으로 보일 정도로 전체적으로 진행이 매끄럽고 능숙해졌으며 , 강연 내용들도 훨씬 알차지고 많아졌습니다.

이 자리에 낀 것 만으로도 영광스러워졌달까…
내년에는 더 발전하겠지요. 내년에는 저도 더욱 개그넘치는 PT를 만들 수 있도록 열심히 노력해야겠습니다. (…)

유니티 부트캠프 2일차 참관 감상

Thu, 12 Apr 2012 08:57:17 +0000

존 구데일 : 유니티 아시아 담당 키노트

유니티는 게임을 민주화하고 있습니다 : 누구나 게임을 쉽게 만들 수 있다

크로스 컬쳐 게임을 만드는 방법 조언

유니티를 쓰세요 :)
게임 초창기부터 게임 플레이를 고려해 주세요
타겟층이 플레이 하고 있는 유사한 게임을 조사해 주세요
로컬라이제이션을 고려해 개발하세요 : 텍스트를 하드코딩 하지 마세요
파트너로부터 어드바이스를 받으세요
반복반복반복 테스트하세요
실패작이라고 실망하지 마세요

유니티는 문화를 초월해서 많이 사용되고 있어요
특히, 도시는 서울이 최고로 많이 사용되고 있지요!!

강조할 수 있는 게임 4개 소개해 드립니다.
엔도어즈의 삼품 (!) 컴투스의 매직트리, 쿠노의 콘솔게임 디펜스 테크니카. 중국의 스텐드 얼론 MMO 소울 오브 히어로스

요약

유니티를 쓰세요 :)

총평 : 일반적이지만 키노트다운 강연이었습니다. 총 유저의 25% 의 유저가 최근 3개월 안에 생길만큼 폭발적으로 인기가 높아져서, 지원이 늦어졌다는 얘기도 있었지요.

유니티로 콘솔 게임 만들기

유니티로 콘솔 게임 만드는 요령에 대해 소개가 되었습니다.
일반적으로는 쉽게 알 수 있는 내용이었습니다. 라이센스를 받아야 하고, 개발 하드웨어를 구매해야 하고, 플렛폼의 제약사항 들도 소개되었습니다. 그 외에 각 콘솔 머신별 주의해야 할 내용에 대해 소개되었습니다.
콘솔 게임을 개발해야 할 때 필요한 내용이 잘 정리되었습니다.

재미있는 것은, 콘솔게임의 유니티 라이센스는 타이틀 당이라는 것!

서피스 쉐이더 프로그램

쉐이더에 대한 전반적인 흐름을 매우 잘 정리한 강연이었습니다.
드디어 유니티에서 다이렉트X 11 기능을 개발하고 있군요!
그동안 유니티의 행보를 보면, 매우 빠른 기간안에 나올것이 확실하고 또한 매우 쉽게 나오겠지요. 기대가 됩니다. 다이렉트 X 11의 기능을 제대로 이용하면 다른 차원의 그래픽을 만들 수 있지요. 그것도 매우 쉽게

그 외에는 유니티의 3가지 쉐이더 제작 방법에 대한 소개가 있었습니다.
재미있는 것은, 서피스 쉐이더에서 #pragma debug 를 쓰면 서피스 쉐이더를 프레그먼트 쉐이더로 변환해서 볼 수 있다는 것!!!

… 그리고 QA 시간에 폭풍질문을 했습…

유니티 안드로이드 개발 : 안드로이드의 파편화 대응

안드로이드의 파편화에 대한 내용을 기대하고 들어갔습니다만, 강연 대부분이 2인으로 이루어진 인디 게임팀 소개라서 조금 실망했습니다. 또한 파편화에 대한 해결 내용도 작은 프로젝트의 경험에 기반된 내용이라, 큰 프로젝트와는 전혀 다른 상황이라 저희에게는 도움이 되지 못했습니다. 예를 들면 레퍼런스가 많다고 하시던 것도 , 작은 프로젝트의 레퍼런스야 물론 많지만 일정 규모 이상의 프로젝트는(MMO라던가 웹게임이라던가) 전혀 그렇지 않죠. 개인 인디 개발자를 지원하시는 지망생분들에게 유용한 강연이었을 듯 합니다.

ps. 무엇보다 가장 도움이 되었던 시간은, 강연 모두 끝나고 유니티 개발자들과 함께 가진 맥주파티였습니다. 쉐이더 담당 프로그래머를 만나서 요구사항을 푸시했다능… 하악하악 ㅎㅎㅎ

유니티 컨퍼런스도 무사히 종료

Tue, 10 Apr 2012 23:29:46 +0000

예전 샌프란의 유니티 컨퍼런스때에도 느꼈지만, 확실히 유니티에는 캐주얼한 프로젝트를 하시는 분들이 많고, 저희처럼 PC 온라인 게임과 동일한 규모의 게임을 만드시는 분들은 적다는 것을 이번에도 확실히 깨달았습니다.

stand alone으로 만들면 웬만한 PC 용 MMO도 뚝딱 만들 수 있을듯한 엔진인데 확실히 아직 그렇게 쓰시는 분은 없네요. 강연때 청중분들 표정만 봐도 이젠 다 알 것 같다는… 게임테크때와는 또 달라서 신선했어요.

어쨌건 강연 잘 끝냈습니다. 다들 지치셨는데도 불구하고 마지막까지 강연장 꽉꽉 채워서 들어주셔서 감사합니다

키노트에 나왔던 삼국지를 품다. 어째서 “삼품” 이 공식 용어가 된거야 ㅋㅋㅋ

끝내고 나서 애프터 파티에서 유니티 본사 개발팀들 만나서 짧은시간이었지만 즐거웠었네요 :)

아이폰/아이패드 Dock iAV-001 리뷰

Sat, 07 Apr 2012 22:59:03 +0000

이번엔 강연준비에 급해서 쓸말 다 못 쓴듯.

유니티 인터뷰

Mon, 02 Apr 2012 14:56:54 +0000

——— 원본 메일 ———

보낸사람: 유영곤 freelandx@gmail.com
받는사람 : jpcorp@hanmail.net
날짜: 2012년 4월 02일 월요일, 11시 40분 00초 +0900
제목: 안녕하세요. 아시아 부트캠프 인터뷰 메일입니다.

안녕하세요. 유니티 코리아 유영곤입니다.

먼저 저희 이번 아시아 부트캠프의 세션에 강연을 맡아주셔서 감사의 말씀 드립니다.

이번 행사에 강연하시는 분들의 스토리와 경험을 재미있는 기사로 만들어 예비 개발자 및 다른 개발자들이 공감하고 동기 부여를 받을 수 있도록 하고자 합니다.

가능하시다면 아래의 13개 인터뷰 질문에 답변을 달아 주시면 저희 쪽에서 세션 참여 부분 홍보에 많은 도움이 될 것 같습니다.

바쁘시겠지만 많은 참여 부탁드리며, 다음주 화요일까지 전달 주시면 감사하겠습니다.

감사합니다.

유영곤 드림

(010-3732-5234)

게임 업계에 언제부터 일하시게 되었는지 그 배경에 대해 듣고 싶습니다.

이제 대충 20년이 되었네요. 고등학교 때에는 그냥 친구들과 함께 만화를 즐겨 그리던 평범한 학생이었는데, 어느 날 고등학교 친구들이 게임을 만들기 위해 그래픽이 필요하다는 얘기를 듣고 팀에 합류하여, HQteam 이라는 팀을 만들어 게임에 들어갈 그래픽 데이터를 그리기 시작한 것이 어느새 직업이 되었습니다. 처음 시작할 때에는 게임 개발에 대한 제대로 된 책이나 교육기관 같은 것이 전무하다시피 했기 때문에 그냥 독학으로 진행할 수 밖에 없었고, 때문에 캐릭터부터 시작해서 배경, 이펙트 UI 등 게임의 모든 부분을 작업해 볼 기회를 얻게 되었습니다.2. 가장 최근 개발작과 어떤 동기로 만들게 되셨는지요?

최근 개발작은 물론 ‘삼국지를 품다’ 입니다. 혼자 만든게 아니니 어떤 동기로 만들었냐고 물어보신다면, 회사에서 만들게 되었으니까 참여하게 되었다고 말할 수 밖에 없겠네요. ‘삼국지를 품다’ 는 멀티 플렛폼을 목표로 하는 고품질 풀 3D MMORPG 입니다. 또한 삼국지의 배경만 빌려오던 게임과는 달리, 충실한 스토리 구성을 전달하는 것을 목표로 하고 있기 때문에, 1000여 개의 연출 드라마와 다양한 스토리텔링 도구들을 준비하고 있는 게임으로 , ‘게임으로 읽는 정통 삼국지’ 라고 생각하시면 되겠습니다.

개발자가 된 계기는 어떠한 것입니까?

위에서 말씀드긴 것과 같이, 그저 평범하게 그림그리기 좋아하는 학생이었습니다만, 친구들과 게임을 만든답시고 골방에 틀어박혀 몇 년동안 일하면서 정신차려보니 게임 개발자가 되어 있었습니다. 사실 지금도 어리둥절합니다. 20년이나 지났는데 말이죠. 이게 직업이 되다니!!!

유니티에 대해서 어떻게 알게 되셨는지요?

멀티 플렛폼 엔진을 찾다가 주위의 소문으로 알게 되었습니다. ‘참 신기한 게임엔진이 있다’ 라고 말이죠.자세한건 강연때 말씀드리겠습니다.

유니티 엔진으로 만든 게임 중 특별히 좋아하는 것이 있습니까?

물론 가장 좋아하는 유니티 게임은 삼국지를 품다입니다. 유니티로 가볍고 간단한 게임만 만드는 것이 아니라는 것을 보여줄 수 있었기 때문이지요. 게다가 유니티 엔진의 파워를 극한으로 끌어내고 있다는 점이 매력적입니다.

향후 유니티를 이용한 게임 개발 계획은 어떠한 것이 있습니까?

좀 더 높은 퀄리티의 게임 제작이 가능할 것으로 보입니다. 물론 여기에는 유니티 엔진 개발사의 전폭적인 지원이 필요하지만 말이죠. 큰 프로젝트에 대한 지원이 부족합니다! 인식이 부족해요! 저희는 유니티의 한계를 넘는 게임을 만드는 것이 목표입니다!7. 유니티에서 개선되거나 다른 엔진과 차별되는 점을 본 것이 있습니까?

사용 편의성은 세계 최강이라고 감히 말하고 싶습니다. 이 정도 기능과 이 정도 퀄리티에 이렇게 사용하기 쉽고, 빠른 피드백을 가질 수 있는 엔진은 별로 없습니다. 특히 어셋 스토어의 매력에 흠뻑 빠졌습니다. 기술을 연구하고 싶은 사람이 아닌, “게임을 만들고 싶은 사람” 을 위해 만들어진 엔진이라는 것을 강하게 느낄 수 있었습니다.

업계에서 다른 개발자들에게 어떤 충고를 해주고 싶습니까?
충고라니요. 다른 개발자 분들은 언제나 경이롭고 놀랍습니다. 오히려 제가 배우고 충고 들어야 할 것이 잔뜩인걸요. 잘 부탁 드리겠습니다.

다른 개발자들과 공유 할 수 있는 시행착오는 무엇입니까?

게임을 만들면서 , 설명하기도 힘들만큼 수 많은 시행착오를 거쳐 왔습니다. 간단히 설명할 수 있는 시행착오는 시행착오라고 부르기도 힘들지요. 하지만 모든 시행착오를 해쳐나가는 방법은 공유할 수 있습니다. 그것은 ‘사람을 믿는 것’ 이었습니다.
10. 다른 개발자들의 멘토가 되실 의향이 있습니까?

저라도 괜찮다면 물론입니다. 우리는 어차피 서로의 몸을 묶고 히말라야 산을 등정하는 동료와도 같으니까요. 서로가 서로의 의지가 되고 도움이 될 때 게임 업계는 발전하게 될 것입니다.
11. 당신의 롤 모델은 누구입니까?

특별히 롤 모델을 정하고 살아가는 사람은 아닙니다. 저는 ‘대충 살아가는 게임개발자’ 니까요. ㅎㅎ
굳이 존경스러운 분을 꼽는다면, 니시카와 젠지 씨라고 할 수 있겠습니다.
12. 5년 후 당신의 모습은 어떻게 그리십니까?
그래픽 팀장과 기획팀장을 거쳐 테크니컬 아티스트의 영역까지 왔습니다. 아마도 5년 후에는 클라이언트 프로그래밍을 하고 있을 것 같습니다. 특히 관심이 있는 분야는 UI 프로그래밍입니다. UI는 가장 감각적인 구현과 게임에 대한 이해 모두를 가지고 있어야 제대로 할 수 있는 일입니다. 멋진 캐릭터나 배경은 스쳐 지나가지만, 마우스 아이콘과 버튼을 비롯한 조작부는 게임 시작부터 끝까지 유저와 가장 붙어서 움직이기 때문에, 게임에서 가장 중요한 부분이라고 생각합니다. 굉장히 재미있고 보람찰 것 같아요.

현재 가장 좋아하는 온라인/ 모바일 게임은 무엇입니까?
저희 회사에는 우리가 서비스하는 온라인 게임을 계속 즐기면서 개선점을 찾아야 하기 때문에 다른 게임을 할 시간이 거의 없을 정도입니다. 때문에 우리 게임이 재미가 없으면 하기 싫어지므로 , 재미있도록 계속 의견을 내야만 하지요:) . 최근에는 삼국지를 품다의 장기컨텐츠인 약탈에 전 개발자들이 푹 빠져 살고 있습니다. 그러므로 다른 게임은 길게 즐기기보다는 짧게 즐길 수 밖에 없는데, 그 동안 즐겨봤던 짧은 게임중 최고는 아름다운 밸런스와 UX 가 감동적인 Plants vs Zombies 입니다. 언젠가는 이런 게임을 꼭 혼자 만들어 보고 싶습니다.

유니티에 한마디

몇 가지 중요한 개선만 한다면, 언리얼이나 크라이에 뒤지지 않는 성능을 자랑하는 아름다운 엔진입니다. 그리고 그걸 세상 사람들에게 보여 드리고 싶습니다. 한국 개발자들의 속도와 실력은 덴마크의 여러분들이 아시는 것보다 훨씬 빠르고 높습니다. 더 전폭적인 지원을 부탁드립니다! 사람들을 깜짝 놀라게 해주자고요!

deferred SSS 관련문서

Mon, 02 Apr 2012 11:15:13 +0000

오옷 >_< 스승님이 디퍼드 SSS 문서 찾아 주셨다. 감사합니다 스승님 >_< /
예제 코드도 구했으니 시간은 좀 걸리겠지만 차분히 봐야겠네요.
알아 들을 수 있을까 나…

@BlindRendererKR 김포프

디퍼드 SSS관련 자료들좀 따왔습니다.

http://http.developer.nvidia.com/GPUGems/gpugems_ch16.html
http://www.iryoku.com/sssss/
http://www.cs.umd.edu/~rob/Documents/sss.pdf
http://people.cs.nctu.edu.tw/~wclin/translucency/EG_paper.pdf
http://graphics.cs.ucf.edu/sss.pdf

Unity Shader Tip / custom shader에서 그림자가 안나올때.

Mon, 02 Apr 2012 10:35:43 +0000

FallBack 을 무시하지 말자 …

캐릭터 쉐이더를 짜다 보니 갑자기 그림자가 안나오는 사태가 발생…
이유가 뭔지 하루 종일 찾았는데도 못찾아서 포기하다가
다시 역추적 하다가 재미있는것 발견.

쉐이더를 렌더링 하다가 실패하면 나오게 되는 ‘긴급용 보조 쉐이더’ 인 FallBack 이 빠져 있어서 그랬던 것!!!
아마도 그림자를 렌더링 하는 부분에서, 캐릭터 쉐이더가 너무 복잡하면 접근을 못하는 것 같은데…
그래서 그림자를 렌더링 할 때에는 FallBack 쉐이더에 접근해서 그리는 것인 듯.

어쨌건 FallBack 쉐이더를 무시하지 말자. 늘 놔둬야 겠다. 위급용으로도 쓸만하고, 리얼타임 그림자를 위해서는 반드시 남겨놔야 할 듯.

게임테크 2012 강연을 잘 끝냈습니다 :)

Sun, 01 Apr 2012 20:43:14 +0000

강연이 잘 끝나서 일단 다행입니다. 꽤 넓은 강연장이었는데도 불구하고 뒤에 서서까지 들어주신 분들께 감사드립니다.
개인적으로 ‘강연은 공연이다!’ 라는 철학을 가지고 있는지라, 지루하지 않게 구성하려고 노력했는데 다행히도 준비한대로 잘 되어서 얼마나 기쁜지 모릅니다 :) 질문도 많이 해주시고 (감사합니다람쥐 라고 했는데 아무도 공황상태에 빠지지 않다니!!!)

(베토 오의덕 기자님이 찍어주신 사진. 저는 스포트 라이트도 없는 곳을 워낙 왔다갔다 돌아다니면서 강연하는지라 제 강연 사진이 거의 없는데, 이정도로 잘찍어주신 사진은 처음 보는 것 같습니다 ㅋㅋㅋ )

뭐 .. 그건 그렇고, 할 소리는 좀 하자면 올해도 게임테크는 좀 실망스러웠습니다.
키노트는 여전히 광고 수준이고, 강연 환경도 여전히 개선되지 않았네요. 대부분의 강연이 광고 강연이라는 점도 실망.

입장료도 적지 않은 수준인데도 불구하고, 광고 부스를 다 돌고 스티커를 받아 와야 하는 퀘스트를 끝내야 받을 수 있는 기념품이 겨우 천원도 안되는 키보드 솔이라는 것부터 일단 실소를 금할 수 없더군요. 게다가 선착순 350개라고 했던가 … 나중엔 사람들이 기념품을 보고 실망해서 안가져가자 아무나 막 나눠줬다는군요. (강연장 가서 받는 티셔츠 모으는 나의 낙이…!!!)

강연장도 이미 꽉 차서 더 이상 자리가 없을 수준인데 현장등록을 계속 받는건 아무리 봐도 좋아 보이지 않았습니다. ‘생각보다 많은 문들이 와주셔서’ 라고 하는데 생각보다 많은 사람을 받으면 안되는 것 아닙니까? -_-;;;

그리고 도시락은 꽤 좋은 편이었습니다만, 따로 식당이 마련된게 아니라 강연장으로 마련된 곳에서 그냥 먹어야 하는 것도 상당히 불편했지요. (제 옆 분의 도시락의 딸기가 곰팡이 핀 것은 그냥 실수라고 하지요)

저야 즐거운 강연을 할 수 있는 점 자체가 가장 큰 만족이긴 하겠지만, 그래도 강연자용 스피커 라운지 하나 마련되지 않았다는 점도 이해가 가지 않았던 점입니다. 프레스룸은 유지하면서, 강연자를 위한 쉼터는 없더군요. VIP 라운지라고 써있어서 기웃대 봤습니다만 아무도 안내하는 사람도 없고, 룸 자체도 창고에 가까운 분위기였구요.

강연료가 없는건 KGC도 그러니 그렇다 치지만, 그래도 KGC는 스피커 예우가 여기에 비하면 좋은 편이지요. 유일한 스피커 혜택은, 추가 무료 입장 쿠폰 4장이 전부.

가장 난감했던건, 스피커 명찰을 받으러 갔더니 정말로 딸랑 스피커 명찰만 주고 아무런 안내도 공지도 없더군요, 심지어 점심 도시락에 관한 안내도 없어서, 박일님과 실버님을 찾아서 관계자에게 물어물어 겨우 일반 참관객용 식권을 얻어서 점심을 해결할 수 있었습니다. 친한 강연자 분들 - 어차피 강연자 분들은 이미 다 알음알음 아는 분들이라 - 이랑 수다떨면서 식사하고 싶었는데, 이산가족이 될 수 밖에 없었죠 .

개인적으로 수십번의 강연이나 세미나에서 스피커로 참가해 봤고, 올해도 강연이 이미 3개가 더 잡혀 있긴 합니다만… 이렇게 대우가 나쁜 강연은 처음이었습니다. 높은 입장료와 함께 스폰서비도 받았을텐데, 강연은 광고가 대부분이고 서비스는 최악이고 말이죠. 내용보다는 수익을 가장 중요시하는 강연의 느낌이었습니다. ‘강연의 내용이 뭐냐’ 가 아니라 ‘유명한 누가 왔느냐’ 를 광고의 포인트로 삼는 것 부터 알 수 있지요

저는 내년부터는 이런 식이라면 게임테크에는 참가하지 않을 생각입니다. 여기 말고도 NDC나 KGC처럼 더 좋은 분위기에서 더 재미있는 강연을 할 수 있는 장소가 많이 있는데다가, 홈페이지 몇 번 뒤져보면 알 수 있는 엔진 개발사 광고를 라이브로 듣고 싶은 마음은 별로 없으니까요.

덧 ) 강연 끝나고 다음주가 되었는데 이제 이메일이 날라와서 강연료를 주신다고 하시는군요 (…) 처음에는 얘기도 없었는데. 이 포스팅을 보신 것인지? 어쨌거나 싸우자는 입장은 아니니 주신다는건 받겠지만, 내년부터는 외국 스피커 분들만 챙기지 말고 국내 스피커 분들의 대우에도 좀 신경써 주시면 좋겠습니다.
게임 쪽 기부할 수 있는 재단이 있나 찾아봐야겠군요.

겜브리오 4.0 세미나 참관기

Thu, 15 Mar 2012 19:10:52 +0000

겜브리오 4.0 ? 라이트스피드?

애증의 겜브리오 4.0 발표를 보고 왔습니다.
2010년에 회사가 접히고 그 회사를 한국 게임베이스가 사서 …
여태까지 아무 소식도 없어서 소리소문없이 사라진거 아니냐라는 괴소문이 돌았던 적도 있었지요.

그렇게 몇 년 동안 아무 소식도 안들리던 겜브리오가, 이번에 4.0 이라는 이름을 걸고!
첫 세미나를 열었습니다!
3.2던가 3.4 에서 갑자기 4.0으로 올렸다는 것은…
메이저 넘버를 올렸다는 것은 뭔가 대단한 변화가 있었다는 의미겠지요. 그렇지 않고서 이렇게 넘버를 올리진 않았을 테니까 말이죠.

겸해서 저는 아틀란티카의 유지보수를 위해서 뭔가 힌트라도 없을까 하는 마음으로 가 봤습니다.

강연장의 파이프 오르간이 굉장하네요

재미있는건 겜브리오가 두 개의 버전으로 나눠졌다는 겁니다.
겜브리오 4.0과, 겜브리오 라이트 스피드 2012 라는 두 개의 엔진으로 나눠져서 만들어 지고 있다는 거지요.
여기서 중요한건, 과거형이 아닙니다. ‘만들어지고 있다’ 라는 현재 진행형입니다.

겜브리오 4.0은 C++ 로 만들어 졌으며 , 좀 더 가벼운 엔진을 지향한다고 하고
라이트스피드 2012 는 C#으로 만들어졌으며, 좀 더 하드코어한 프로젝트의 엔진을 지향한다고 합니다.
하지만 둘의 결정적인 차이는 잘 모르겠더군요. “두 엔진 개발팀의 취향이 다르다” 정도밖에.

강연 내용도 둘이 서로 중첩되는게 대부분이고 말입니다.
겜브리오 4.0 같은 경우는 기초 프레임웍만 두고 나머지는 전부 뒤엎었다는 것으로 보아,
내부에서 무슨 이유에서인가 두 개의 개발팀으로 나눠서 개발되고 있는 느낌이었습니다.

예전 라이트 스피드가 초기에 나왔을 때, 너무 큰 변화와 함께 불안한 안정성으로 인해
기존의 겜브리오 사용자들한테 외면을 많이 당했던 것 때문에 그럴지도…

4.0과 라이트스피드 2012 이 동시에 발표되었습니다.
아참 출시는 3.0은 4월 경이고 라이트스피드2012는 올해 말이라는군요.

어쨌거나 여전히 툴은 조금 번잡하고, 섬세하지 못하며, 직관적이지도 않습니다.
아티스트들이 원하는 것이 뭔지 전혀 모르는 것 같은 느낌.
아티스트들은 물 수정을 하기 위해 ‘독립된, 탑뷰의 다른 인터페이스를 가진 ’ 툴을 띄우길 원하지 않습니다.
아티스트들은, 게임 화면 안에서 유저의 시선으로 물이 어떻게 보이는지 보고 싶을 뿐입니다. 그 자리에서 보면서 아주 익숙한 인터페이스로 작업하고 싶어 하지요.

외국에서 온 강연자들은 그저 빈 툴을 띄워놓고서는 “유연하다, 빠르다, 직관적이다” 라고만 말하고 있네요.
기존의 유저들을 좀 더 휙 하고 잡으려면 좀 더 강력한 모습을 보여주면 좋았을텐데 말이죠. 아쉬웠습니다.

메터리얼 에디터라고 하기엔 좀 썰렁…

예제도 좀 부족하고 고급 효과는 디퍼드 렌더러와 일부 포스트 프로세스 적용된 것 외에는 특이한게 없었습니다.
스카이박스는 이제 들어갔고… 킥스타트는 3.2 때부터이던가 자랑하던것이구요

OpenGL 지원여부도, 일주일전에 관련 개발자를 뽑았다고 하네요. 모바일 지원도 내년 말이나 가능하지 않을까 라는 예상을 하더군요. ㅠㅠ

곧 = 내년 말. (2년 후)

또한 “2.6을 사용하는 회사는 여전히 맥스 9만 익스포트 플러그인으로 지원하는데 그 이상을 지원해줄 계획은 없느냐”
에 대한 답변은 ,
2.6.03 을 사용하면 2010 까지는 지원하지만, 어쨌건 2.x 버전의 지원은 더이상 하지 않는다 라고 하네요. ㅠㅠ

이것은 실버치매님의 고군분투기 제작사례!!!!

정신을 차려보니

Mon, 12 Mar 2012 22:46:54 +0000

내 손 안에 왠 계약서 사본이 (…)

하지만 인디오더를 한 나는 4-5개월을 기다리게 되겠지.

삼국지 퀴즈

Mon, 12 Mar 2012 00:46:07 +0000

1. 병법 수상개화(樹上開花)에 대한 설명으로 맞는 것은?
가 . 선봉(先鋒)을 일반 부대의 선두에 세움으로써 왕성한 기백과 웅장한 위세를 과시하여 적을 제압
나. 상대의 갈등과 알력을 이용하거나 조장해서 목적한 바를 이룸
다. 호기가 올 때까지 기다렸다가 다시 적을 공격한다. 인위적인 가상으로 적을 기만한다. 건괘의 원리를 응용하여 장차 위험이 있을 것 같으면 잠시 떠나 있는다
라. 지리적으로 다른 방향에서 적을 미혹하여 적이 통제가 불가능한 상태에서 섬멸하도록 한다.

조조가 드디어 여포를 없앤 전투는?
가. 장판파(長坂坡) 전투
나. 양평관전투
다. 오장원(五丈原)전투
라. 하비성 전투
목우(目牛) 에 대한 설명으로 맞지 않은 것은?
    가. 제갈량이 발명했다
    나. 방향 전환을 할 수 없다.
    다. 꼬리에 장치가 있다.
    라. 군량이나 물자 수송을 하는 사륜거다
다음 중 가정(街亭)전투에 관련된 내용으로 맞는 것은?
    가. 오관참육장(五關斬六將)
    나 .읍참마속(泣斬馬謖)
    다. 난공불락(難攻不落)
    라. 순망치한(脣亡齒寒)
다음 삼국지 사자 성어의 내용 중 맞지 않는것은?
    가. 우도할계(牛刀割鷄) : 적게 먹고 일은 많이 한다는 의미
    나. 순망치한(脣亡齒寒) : 입술이 없으면 이가 시리다.
    다. 수어지교(水魚之交) : 아주 친밀하여 떨어질 수 없는 사이를 의미
    라. 비육지탄(脾肉之歎) : 자기의 뜻을 펴지 못하고 허송세월 하는 것을 한탄하다

1-4-3-2-1

http://www.subkorea.com/xe/?mid=samkukji&category=60442&sort_index=readed_count&order_type=asc&document_srl=61939

http://www.subkorea.com/xe/?mid=samkukji&category=60443&sort_index=readed_count&order_type=asc&document_srl=61698

http://www.subkorea.com/xe/?mid=samkukji&category=60444&sort_index=readed_count&order_type=asc&page=2&document_srl=61787

4,5
http://kin.naver.com/qna/detail.nhn?d1id=11&dirId=111002&docId=58547282&qb=7IK86rWt7KeAIOyCrOyekOyEseyWtA==&enc=utf8§ion=kin&rank=1&search_sort=0&spq=0&pid=g1zcu35Y7udssu9pZIhssc--450407&sid=T1xjp8g-XE8AAF75xYE

삼국지를 품다 OST 도화 (桃花) - Peach Blossom

Sun, 11 Mar 2012 20:29:30 +0000

달우팀장님 작품 >_< /
겜 만들면서 만난 사운드 크리에이터중 가장 음악 잘 만드는 아저씨 >_< /

삼품 음악 너무 좋아요

아 이 음악이 오케스트라로 연주되는거 보고 싶다…

ShaderFX를 이용한, 그래픽 디자이너를 위한 기초 쉐이더 강좌 7강

Fri, 09 Mar 2012 21:50:32 +0000

http://gamedevforever.com/

에서 보시면 주석을 좀 더 편하게 보실 수 있으십니다 :)
게다가 동영상이나 첨부파일도 저기에 가면 제대로 보시거나 받을 수 있습니다.
이 강좌는 저기가 메인이고 여기가 보조라서 말이죠…

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

안녕하십니까. 오늘도 어김없이 찾아온
치명적인 매력의 소유자 대마왕J입니다.

심지어 우리 게임에도 보스 몹으로 등장하는 위대하신 분이 바로 저입니다. Ndoors Co. 아틀란티카.

그럼 오늘도 즐거운 시간을 한 번 가져볼까요 호호홍

이번 시간으로 UV를 끝내봅시다.

다른 거 할까 잠깐 생각해 봤는데… 이거 UV를 조금만 더하면 마무리 짓는데다가,
여기서 추가로 배울 수 있는 재미있는 개념과 ShaderFX의 새 기능이 생각나서 말입니다.
그래서 추가로 좀 더 나가봅니다 :)

저번 시간에 UV에 덧셈과 곱셈을 해서 변화시키는 것을 배워봤습니다.
네 ,

이거 말입니다 이거.

귀여운 개불아저씨가 등장하는 이거.
사실 개불은 이렇게 생겼지만.

사랑을 돈으로 사는 개불과 티스.

이제 이번 시간에는 귀여운 개불캐릭터가 원하는대로, 똑바로 UV가 위아래로 혹은 옆으로 흐르도록 만들어 봅시다.

왜 그랬는지 한 번 더 생각해 봅시다.

지난 시간에 보면, UV가 대각선으로 흘렀지요?
생각해 보면 당연할 수 밖에 없는 결과였습니다.

이렇게 UV를 가지고 있는 Vertex가 있는데…

여기의 UV값인 float2(0.0 , 0.0)[각주:1] 에다가 +0.2를 해주면

어쩔 수 없이 float2(0.2, 0.2) = float2(0.0, 0.0) +0.2 [각주:2]
가 되어서 U, V 값이 동시에 변하기 때문입니다.
당연하지요. 2차원의 벡터에 한 자리의 숫자를 더하면 전부 영향을 끼쳐버리니까요.

그러므로 이걸 대각선이 아닌 똑바로 움직이게 하려면 , 어쩔 수 없이 두 자리가 같이 다니던 UV를, U와 V 로 일단 갈라서 따로따로 계산해 줘야 합니다 .

즉 ShaderFX에서 이걸 계산하려면,

float2( U , V )

였던 녀석을

float( U )
float( V )

이렇게 두 개로 따로따로 찢어준 다음에,(각각은 당연히 float)이겠지요

float( U )
float( V ) + 0.2

이런 식으로 U나 V 한테만 값을 적용해 주고,(여기서는 V에다가만 값을 줬네요)
다시 둘을 합쳐서

float2( U, V )

로 만들어 주면 된다는 것입니다.

근데,

생각해 보니 조낸 간단한걸 일부러
귀찮게 하는 것 같지 않아요?????

코딩으로 한 번 짜보기 시작하면 그래서 다시 노드로 못돌아 가겠뜸…

네 그렇습니다. 이게 노드식으로 이루어지는 비주얼 쉐이더 툴의 단점입니다.
hlsl 코드로 짜면, 그냥

UV = float2(U , V+0.2);

하고 한 줄이면 끝날 것을,
노드로 위에서 설명한것처럼 구구절절하게 표현해야 한다는 것입니다 .
일단 조금 짜도 쉽게 길어지기 때문에 열심히 일한 것 처럼 보이는 것은 장점.

묘한데서 안심하지 마세요

ShaderFX로 구현해 봅시다.

그럼, 일을 열심히 하는 것 처럼 보이기 위해서 간단하게 위에서 말한 방식으로 UV의 수직이동을
ShaderFX로 구현해 봅시다.

수직이니까… V에다가 + 해 주면 되겠군요. [각주:3]

뭐 일단 여기에서부터 시작합니다.
슥 보니 UV 밑에 U와 V가 떨어져 있는게 보이는군요.
파랑색 공 아이콘이 U와 V의 옆에 각각 보이니까 당연히 float 으로 출력되는 거겠고..
U와 V가 각각 떨어져 준비가 되어 있는걸 볼 수 있습니다. 하긴 저게 미리 없으면 방법이 없겠지..

그럼 떨어뜨리는 것은 할 필요 없이 저걸 합쳐주는 것만 준비하면 되겠군요.

그럼 좀 귀찮지만, 합쳐 주는 뭔가가 추가로 필요하다는 것을 알 수 있습니다.
빈 화면에서 오른클릭해서 ,Math를 찾아서 VectorConstruction 을 만듭시다.

VectorConstruction (벡터 건설) 이 나왔습니다.
아이콘이 참 직관적이어서 좋아요. 공사하고 있잖아 ㅋ

이놈은 뭐 별 건 아닙니다.
굳이 수식으로 표현하자면 이런거..?

float4( , , , )

즉, ‘준비된 빈자리의 float4 벡터’ 입니다.
근데 재미있는 것은, 4자리가 준비되어 있긴 하지만 이 VectorConstruction에 몇 개의 수를 넣는냐에 따라 float 숫자가 달라진다는 거지요.

즉 X한테만 숫자를 넣으면 float 을 출력하고,
X,Y 에다가 숫자를 넣으면 float2를 토해내고
X, Y, Z 에다가 넣으면 float3을 토해내고
X, Y, Z, W 에다가 넣으면 자동으로 float4를 토해내는 신통방통한 놈이란 말입니다.

그러므로 우리는 여기다가 U와 V 를 넣겠습니다. 두 개 넣었으니 float2가 출력되겠죠.
이전에도 말했지만, U와 V 는 X와 Y 랑 똑같은데 그냥 이름만 다른거라고 말씀드렸었지요

자, 기존에 연결되어 있던 UV 라인을 삭제하고,
U와 V 를 각각 X와 Y에 넣어서 합쳐줬습니다.
그리고 나온 Vector를 UV에 연결해 줬지요. [각주:4]

이렇게 하면 기존에 작업한 것과 똑같습니다. 그럼 성공한겁니다.
그렇지만, 전과 다른것은 이제 드디어 U와 V 값을 따로 접근할 수 있게 되었다는 것입니다.

이제 벌써 3달을 넘게 하셨으니, 너무 쉬운건 살짝 점프하고 싶은데요.
아니, 그 전에 한 번 스스로 생각해 보세요.

V 한테 0.5 값을 더하려면 이제 어떻게 해야 하지요?

……

설마 알겠지

.. 어서 안다고 말해…

설마 여기까지 배워놓고 모를까…

네, 정답공개합니다.

네에. 이렇게 하면 되겠죠?

멀쩡히 잘 가고 있던 V 값을 끊고, 그 사이에 MathOperator를 끼워 넣은 다음에, Constant(상수)를 0.5만 더해주면 되는 거지요.
그림을 보니 위아래로만 움직였습니다!!!!
-0.5 를 하면 반대로도 움직이겠지요!
다양한 숫자를 넣어보시고 테스트 해 보십시오.

자아 ….. 요걸 이용하면 뭘 할 수 있을까요?

바로

폭포나 흘러가는 강을 만들 수 있습니다
폭포나 강은 보통 물 텍스쳐가 일정 방향으로 흘러가는 방식으로 만들지요.
이럴때 사용할 수 있는게 이 쉐이더입니다.

UV를 어떻게 펴냐에 따라 , 곡선으로 흘러가게 할 수도 있다는 말씀. Ndoors Co. 삼국지를 품다.

쉐이더에서 V 값만 무한히 증가하게 애니메이션을 준다면, 폭포나 흘러가는 강을 자연스럽게 만들 수 있습니다.
요것도 알아서 흘러가게 할 수 있는데, 이건 좀 있다가 해 보도록 합시다. 아직 개념설명이 끝나지 않았어요.

UV를 눈으로 봅시다.

네, 위에서는 이제 Vector Construction을 통해, 조각조각 나눠져 있던 float를 합쳐서 float2 등으로 만드는 것을 알아봤습니다.

자… 여기서 … 뭔가 할 수 있을 것 같지 않나요…?

바로… UV를 눈으로 보는 것 말입니다!!!!
워워.. 긴장하지 마세요. 별 거 아닙니다.
그전에는 분명 뭐야 이게? 했던 것이겠지만, 이제 여러분들의 수준에서는 ‘아 .. 그거!’ 라고 알 수 있는 수준인 단원입니다.

게다가 UV를 눈으로 보게 되면, 그동안 개념으로만 알고 있었던 UV라는 것이
확실하게 이해되게 됩니다! 그래픽 디자이너는 눈으로 봐야만 이해하곤 하거든요.

자 , 이번에 필요한 것은 아까 배운 VectorConstuction 과 UV 뿐입니다. 다른 것은 지워버리셔도 좋습니다.

여기서 우리가 알고 있는 몇 가지 사실을 나열해 보겠습니다. 무엇이 상상되는지 한 번 생각해 보시죠.

UV 는 0과 1 사이의 값으로 표현된다.
칼라도 0과 1사이의 채널값의 모임으로 표현된다.
칼라는 0과 1사이의 채널이 R,G,B 세 군데에 들어가면 칼라가 된다.
VectorConstruction 은 한 채널 (float) 을 합쳐서 최대 4개의 채널 (float4) 을 가진 벡터로 만들어 준다.

자 상상이 끝나셨는지? 뭘 하려는지?
잘 모르시겠다고요?
그럼 아래 그림을 보세요

짠

어라… U 값을 X, Y, Z 에 넣어서 float3로 만들었습니다. 그리고 그걸 다시 AmbientColor로 만들었습니다 :)
그럼 그림은 어떻게 보일까요?

이렇게 보입니다 :) UV의 U 값이 흑백으로 보입니다!! 그도 그럴 것이, X,Y,Z 모두에 U 값을 넣었으므로, float3(0,0,0) 부터 float3(1,1,1) 까지의 색상이 되었지요? UV의 U가 눈으로 보입니다 >_<

물론 U가 아니라 V도 볼 수 있습니다.

우리 그래픽 디자이너들은, 눈으로 봐야 이해하기가 쉽잖아요!
어디가 V 값이 0인줄 알겠고 어디가 1인줄 알 것 같애!!!
프로그래머들은 자기네들만 이런거 보고!!! 우린 보여주지도 않고!!! 흐규흐규!!!!

“Vertex가 UV값을 가진다” 라고 설명하면, “그럼 그 Vertex 사이는 어떻게 되어 있는거야?” 라고 생각할 수 있겠지요. 이제 그림을 보면 명백해 지지요.
“두 개의 다른 Vertex 값의 사이는 두 값을 블랜딩 해 줍니다” [각주:5]

어때요? UV를 눈으로 보게 되니까 뭔가 기쁘지 않아요?
아직 끝나지 않았어요!

끝나지 않았어 끝나지 않았어

이번엔 UV를 동시에 보기로 하죠. U는 Red 채널에 넣고, V는 Green 채널에 넣는 거예요. B가 남으니까….B는 그냥 상수 0 을 넣어서 색을 없애 보기로 하죠!! 파랑색은 업ㅋ엉ㅋ

우왕 UV가 칼라로 한 번에 보여요!!! UV가 0,0 인 부분은 Z값도 0을 넣었으니까 (0,0,0)이 되어서 검은색이 나왔구요!

UV가 (1,1)인 부분은 RGB로 하면 (1,1,0) 이 되니까 노란색이 되었어요!!!

어때요, UV를 눈으로 볼 수 있지요?????!!!!??

이렇게 UV를 눈으로 보게 되었습니다. 그동안 ‘니시카와 젠지’ 씨의 글이나 기타 그래픽스 이론 글을 읽다가 저런 뭔가 무지개색의 그림이 나오면 저게 뭘까.. 라고 더이상 생각하지 않아도 좋습니다!! 이젠 저 색깔이 숫자로 보여야 해요!!!

이전에도 말씀드렸지만, 숫자를 색으로, 색을 숫자로 변환해 가면서 볼 수 있는 능력!
쉐이더를 공부할때는 꼭 필요한 능력입니다.

실습 : UV를 에니메이션 합시다.

원래 4까지 하고 끝내려 했는데, 진짜 이것만 하면 이제 더는 UV를 안건드려도 될 것 같네요.
요것까지만 해 보지요. 실습입니다.

자 이번엔 흘러가는 강을 만들 거예요. 폭포라고 해도 괜찮겠죠.

우선 준비할 것은 이것입니다.

텍스쳐는 일단 귀찮으니까 있는거 쓰도록 합시다.

DClouds_32bit.dds 가 괜찮아 보이네요. Texture를 생성해서 이 텍스쳐를 입혀 보세요 [각주:6]

세로로 길죽하게 입혀졌군요. 뭐 이대로도 좋다면 할 말 없지만… 저는 좀 조절하고 싶네요
조절이 가능하게 하기 위해서 , Vector Construntion 을 이용해서 UV를 나눠 놓읍시다.

이렇게요. 뭐, 당연하게도 변한건 없지요.

근데 이번엔 U 값 (X 축)이 좀 늘어난 것을 완화시켜 보도록 하겠습니다.
생각해보세요… 귀찮겠지만… 어떻게 하면 되나요?

U값(X축) 을 타일링 시키면 되겠지요? 세로 타일링 수치를 늘이면 늘어난게 좀 완화되지 않겠어요?
타일링을 만드는건? 곱하기죠?

그러니까 아래처럼 되는거죠.
이해 안되시면 차근차근 잘 보시면서 기억을 되짚어 보세요 :)

네, 이렇게 U 값에 타일링 (곱하기) 를 추가해 놨습니다. 상수 (Constant)의 숫자를 좀 올려보세요.

저는 2 정도로 하니까 그런대로 괜찮게 되었네요.

흑백인게 마음에 안 드시면, 마지막에 칼라값을 곱해주세요.
푸른 계열 색을 곱하면 괜찮겠지요 .

..촌스럽네요.
그냥 이게 무료강의의 폐해라고 생각하고 넘어가도록 합시다.

자 이젠 물이 흘러가게 해야죠.

물이 흘러가는건? UV의 이동입니다. 이동은 어느쪽으로? 역시 아까 했던 것처럼 위아래로 흘러가야 하니까.. 간단합니다. U 에다가 ‘덧셈’ 을 해주면 되겠군요.

자 , 잘 보세요. 여기입니다. 흐름을 눈으로 잘 느껴보세요.
노드로 하면 오히려 조금만 복잡해져도 흐름을 놓치는 경우가 많거든요. 오히려 코드가 보기가 쉽다는… 쿨럭.

요령은, 오른쪽 부터 보는겁니다. 흐름을 느껴보세요. 오른쪽 아래 UV부터 봅니다. 좌측으로 흘러갑니다…

UV의 U 값이 … [각주:7]
Input B 로 들어가서
상수(Constant) 랑 곱해졌습니다.
거기서 곱셈이 끝이죠.
그리고 그걸 Vector Construction의 X 에다 집어 넣는 것입니다.

그러므로, 완성된 U의 값은

요기를 통해 나와 흘러가고 있습니다.

요기를 과감히 끊고, 상수를 더해주도록 만들어 주면, 이제 이동을 시킬 수 있을겁니다.

이렇게요. 간단하지요? [각주:8]

자, 이제 이 덧셈의 상수를 움직여서, 물이 흘러가는지 봅시다.

오오! 상수를 올려주니 UV가 이동하면서, 물이 흘러가는 것 같은 화면이 됩니다!!! 정말로 바로 뛰어들고 싶을 정도로 맑고 투명한 물이로군요!!!

이런 식으로 U 값을 애니메이션 줄 수 있다면 매우 만족스러울 것 같습니다…..만…

문제는 물이 영원히 흘러간다는 말이죠. 이거 애니로 제어하기 쉽지 않습니다. 막 루핑 써야 하고.. 귀찮…

그래서 이번엔 Time 컨트롤러를 써 봅시다.

그전에 우리가 여태까지 만들어 놓은 노드구조를 잠깐 감상해 볼까요.

오 꽤 멋집니다.

사실 별 거 아니지만, 꽤 뭔가 한 것 처럼 보입니다. 놀지않고 일한것 처럼요.

조금 복잡해졌다고 막 헤매면 안돼요. 앞으로 이것보다 두 배 세배로 복잡하게 만들겁니다.

자 여기서 좀 더 일한 것 처럼 만들어 봅시다.

우리가 여기 U값 덧셈 부분의 상수를 손으로 조절했잖아요?
그랬더니 흘러갔었죠?

이 부분의 상수를 지우고,
Time 컨트롤러를 넣습니다.

Time 컨트롤러는 Inputs / Time에 있습니다. 꺼내봅시다.

뭔가 엄청나게 정직한 시계가 나왔군요 :)
이 Time 컨트롤러를 , 아까 상수를 지우고 거기다가 연결해 줍시다.

별 변화가 없네요?

변화가 없는게 정상이지요.

맥스로 가서 , 맥스 하단에 있는 플레이 버튼 (▶) 을 눌러줍시다.

우와와와와와와와와와와

빨라!!!!

빠릅니다. 빠르고요.

일단 이 타임컨트롤러는 초마다 0 1 2 3 4 5 6 7 8 9… 식으로 숫자를 늘여주는 노드로 보입니다.
그러므로 이렇게 휙휙 이동하는 거겠지요.

이걸 느리게 하려면 간단합니다.

Time을 그냥 덧셈에 넣지 말고, 0.1 같이 소숫점을 곱한 결과물을 넣어주면 되겠지요.
만약 0.1을 곱하면, 1은 0.1이 되고 2는 0.2가 되니까… 1/10로 느려지겠지요!?

한 번 보겠습니다.

오오오 좋은 속도로군요. 이정도라면 만족할 수 있겠습니다.

이제 이렇게 원하는 모양으로 구부린다던가 해서 쓸 수도 있습니다.
곡선으로 만들면 곡선에 따라 잘 흐르지요 :)

이번 시간에 우리가 만든 노드는 다음과 같습니다. 잘 안보이시면, 그림을 누르면 커집니다. :)

이렇게 해서 드디어! 처음으로 뭔가 좀 쓸만할 것 같은 쉐이더를 만들어 보았습니다!!!
SFX 파일도 첨부해 드리지요. 보시고 싶으시면 보셔도 좋겠습니다 :) [각주:9]

7강.SFX

이제 이것으로 UV에 대해서는 끝내도록 하겠습니다.
다음 시간에는 아마도… 리니어 인터폴레이션 정도..?
아니다 . 그거 하려면 그 전에 텍스쳐 블렌딩부터 해야겠구나… 웅…
잘 하면 둘 다 할 수 있겠네요 :) 여기서부터는 재밌지요.

UV 이론을 알면 말이죠!!!

이젠 정말 UV는 끝!!!! 앞으로는 그냥 얘기도 안해주고 막막 쓸테니까 복습하세요!!!!

다시 한 번 말합니다. float2 (0.0 , 0.0) 의 앞자리가 U 이고, 뒷자리가 V 입니다. 지금은 둘다 0.0 이네요. [본문으로]
float2(0.0, 0.0) +0.2 = float2(0.2, 0.2) 가 아니라 float2(0.2, 0.2) = float2(0.0, 0.0) +0.2 입니다. 프로그램에서는 우리가 수학시간에서 배웠던 것과 달리, 답이 왼쪽에 있습니다! [본문으로]
U,V 는 X,Y에 대응된다고 했잖아요? X가 가로니까 Y는 세로겠지요? [본문으로]
두 자리 넣었으니 float2를 뱉겠다고 Vector 의 공 아이콘이 보라색으로 변한 꼼꼼한 디테일 보세요. [본문으로]
블렌딩. 사실 블렌딩이라고 하면 맞지 않습니다. 그래픽 디자이너분들의 용어로는 “보까시” 해준다 라던가"그라디에이션" 해준다 정도가 통용되는 말이겠지요. 그렇지만 프로그래머의 용어로 이걸 말하려면 “인터폴레이션 해준다” 또는 “보간해준다” 라고 하는 것이 좋습니다. 구체적으로 말하면 리니어 인터폴레이션 (Liniar Interpolation) 이지요. 혹은 이걸 번역해서 ‘선형 보간’ 이라고도 합니다. 참 다르고도 신기한 그래픽 디자이너들과 프로그래머들의 용어의 세계입니다. :) [본문으로]
설마 이젠 이런 것 정도는 설명 안해도 아시겠죠??? 이 텍스쳐는 ShaderFX를 설치하면 기본으로 들어 있는 것이 또한 마음에 드는 점입니다. [본문으로]
뭐해요! 찾아봐요 어서!!! [본문으로]
MathOperator를 선택하고 오른쪽 메뉴에 보면 덧셈으로 바꿀 수 있지요..? [본문으로]
재미있는 것 하나 알려 드리지요. 이렇게 만들어 놓은 물 오브젝트를, 1. 맥스에 가서 메터리얼 에디터를 열고, 2. 슬롯을 하나 빈 것 선택한 다음에, 3. 메터리얼 에디터에 있는 스포이드 아이콘을 찍어서 지금 만든 물 오브젝트를 찍어보세요!!! 신기한 일이 벌어질겁니다!!! 뭔지는 안가르쳐 드려요!!! [본문으로]

PT 다 만들었다

Fri, 02 Mar 2012 02:46:23 +0000

PT 다 만들었다!!!! 이걸로 1년 우려먹어야지?!??! 벌써 잡혀있는 강연만 4개…. OTL

삼국지를 품다 영상

Tue, 28 Feb 2012 10:52:43 +0000

http://jx2comics.egloos.com/4678157

JJ네서 퍼온 삼국지를 품다 영상입니다!!! 짱 멋져요!!!

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

http://s.nx.com/s2/game/3p/cbt/swf/sp_player.swf?param_url=http://vod.nexon.co.kr/3p/3p_gameplay.flv

오늘부터 아기다리고기다리던 2차 서포터즈네요.
요것은 작년 11월에 지스타용으로 만들었던 동영상인데
완성이 하루늦어서 매체에 나가지 못했던 비운의 영상입니다.

중간에 게임 플레이 화면이 나오는데
현재 버전은 한단계업그레이드 되었으니 ….

기대바랍니다.^^

라는군요. 지스타때 만들었었구나 이거…

ShaderFX를 이용한, 그래픽 디자이너를 위한 기초 쉐이더 강좌 6강

Fri, 24 Feb 2012 01:27:49 +0000

안드로이드에서 최적화 방법

Sun, 19 Feb 2012 14:00:50 +0000

Lighting Performance

Per-pixel dynamic lighting will add significant cost to every affected pixel and can lead to rendering object in multiple passes. Avoid having more than one Pixel Light affecting any single object, prefer it to be a directional light. Note that Pixel Light is a light which has a Render Mode setting set to Important.
Per-vertex dynamic lighting can add significant cost to vertex transformations. Avoid multiple lights affecting single objects. Bake lighting for static objects.
퍼 픽셀 라이트는 픽셀마다 중대한 영향을 끼치고 여러 패스로 그리게 될 수도 있으니까 하나만 쓰라는 얘기. 그것도 디렉셔널 라이트로. 셋팅은 important 셋팅으로 (제대로 번역하기 귀찮…)
버텍스 라이트는 트렌스폼 코스트에 영향 끼친다… 당연하겠지. 어쨌건 결론적으로 라이트는 하나만 쓰라는 말씀.

Optimize Model Geometry

When optimizing the geometry of a model, there are two basic rules:

Don’t use excessive amount of faces if you don’t have to* 필요없는 면 쓰지 마* Keep the number of UV mapping seams and hard edges as low as possible
- UV 단순하게 짤러. 그리고 스무스 옵션으로 부드럽게 해. (주:노말과 UV 줄이라는 말임)

Note that the actual number of vertices that graphics hardware has to process is usually not the same as what is displayed in a 3D application. Modeling applications usually display the geometric vertex count, i.e. number of points that make up a model.
그래픽 툴에서 보이는 버텍스 숫자는 그래픽 하드웨어에서 인식하는 숫자랑 다르다는것 주의. 모델링 프로그램은 보이는 버텍스만 카운트 하걸랑.

For a graphics card however, some vertices have to be split into separate ones. If a vertex has multiple normals (it’s on a “hard edge”), or has multiple UV coordinates, or has multiple vertex colors, it has to be split. So the vertex count you see in Unity is almost always different from the one displayed in 3D application.
그래픽 카드에서는 버텍스를 똑같은 놈으로 잘라 (복사) 해 버리거든요. 버텍스 노말이 많으면 (꺾인면이 있으면) 또는 UV좌표가 많으면, 혹은 버텍스 칼라가 많으면 버텍스가 복사 되어요. 그래서 버텍스 카운트가 늘어나요. 그래서 그래픽 프로그램과는 데이터가 달라져요 (요건 글로 한번 써야겠다. 좋은 말인데?)

Texture Compression

All Android devices with support for OpenGL ES 2.0 also support the ETC1 compression format; it’s therefore encouraged to whenever possible use ETC1 as the prefered texture format. Using compressed textures is important not only to decrease the size of your textures (resulting in faster load times and smaller memory footprint), but can also increase your rendering performance dramatically! Compressed textures require only a fraction of memory bandwidth compared to full blown 32bit RGBA textures.

If targeting a specific graphics architecture, such as the Nvidia Tegra or Qualcomm Snapdragon, it may be worth considering using the proprietary compression formats available on those architectures. The Android Market also allows filtering based on supported texture compression format, meaning a distribution archive (.apk) with for example DXT compressed textures can be prevented for download on a device which doesn’t support it.

Enable Mip Maps

As a rule of thumb, always have Generate Mip Maps enabled. In the same way Texture Compression can help limit the amount of texture data transfered when the GPU is rendering, a mip mapped texture will enable the GPU to use a lower-resolution texture for smaller triangles. The only exception to this rule is when a texel (texture pixel) is known to map 1:1 to the rendered screen pixel, as with UI elements or in a pure 2D game.

Tips for writing well performing shaders

Although all Android OpenGL ES 2.0 GPUs fully support pixel and vertex shaders, do not expect to grab a desktop shader with complex per-pixel functionality and run it on Android device at 30 frames per second. Most often shaders will have to be hand optimized, calculations and texture reads kept to a minimum in order to achieve good frame rates.

Complex arithmetic operations

Arithmetic operations such as pow, exp, log, cos, sin, tan etc heavily tax GPU. Rule of thumb is to have not more than one such operation per fragment. Consider that sometimes lookup textures could be a better alternative.

Do NOT try to roll your own normalize, dot, inversesqrt operations however. Always use built-in ones – this was driver will generate much better code for you.

Keep in mind that discard operation will make your fragments slower.

Floating point operations

Always specify precision of the floating point variables while writing custom shaders. It is crucial to pick smallest possible format in order to achieve best performance.

If shader is written in GLSL ES, then precision is specified as following:

highp - full 32 bits floating point format, well suitable for vertex transformations, slowest* mediump - reduced 16 bits floating point format, well suitable for texture UV coordinates, roughly x2 faster than highp* lowp - 10 bits fixed point format, well suitable for colors, lighting calculation and other high performant operations, roughly x4 faster than highp

If shader is written in CG or it is a surface shader, then precision is specified as following:

float - analogous to highp in GLSL ES, slowest* half - analogous to mediump in GLSL ES, roughly x2 faster than float* fixed - analogous to lowp in GLSL ES, roughly x4 faster than float

For more details about general shader performance, please read the Shader Performance page. Quoted performance figures are based on the PowerVR graphics architecture, available in devices such as the Samsung Nexus S. Other hardware architectures may experience less (or more) benefit from using reduced register precision.

Bake Lighting into Lightmaps

Bake your scene static lighting into textures using Unity built-in Lightmapper. The process of generating a lightmapped environment takes only a little longer than just placing a light in the scene in Unity, but:

It is going to run a lot faster (2-3 times for eg. 2 pixel lights)* And look a lot better since you can bake global illumination and the lightmapper can smooth the results

If a number of objects being rendered by the same camera uses the same material, then Unity Android will be able to employ a large variety of internal optimizations such as:

Avoiding setting various render states to OpenGL ES.* Avoiding calculation of different parameters required to setup vertex and pixel processing* Batching small moving objects to reduce draw calls* Batching both big and small objects with enabled “static” property to reduce draw calls

All these optimizations will save you precious CPU cycles. Therefore, putting extra work to combine textures into single atlas and making number of objects to use the same material will always pay off. Do it!

Simple Checklist to make Your Game Faster

If you’re using built-in shaders, peek ones from Mobile category. Keep in mind that Mobile/VertexLit is currently the fastest shader.* Keep the number of different materials per scene low - share as many materials between different objects as possible.* Set Static property on a non-moving objects to allow internal optimizations.* Use ETC1 format for textures when possible, otherwise choose 16bit textures over 32bit for uncompressed texture data.* Use mipmaps.* Use combiners or pixel shaders to mix several textures per fragment instead of multi-pass approach.* If writing custom shaders, always use smallest possible floating point format: + fixed / lowp – perfect for color, lighting information and normals,+ half / mediump – for texture UV coordinates,+ float / highp – avoid in pixel shaders, fine to use in vertex shader for vertex position calculations.* Minimize use of complex mathematical operations such as pow, sin, cos etc in pixel shaders.* Do not use Pixel Lights when it is not necessary – choose to have only a single (preferably directional) pixel light affecting your geometry.* Do not use dynamic lights when it is not necessary – choose to bake lighting instead.* Choose to use less textures per fragment.* Avoid alpha-testing, choose alpha-blending instead.* Do not use fog when it is not necessary.* Learn benefits of Occlusion culling and use it to reduce amount of visible geometry and draw-calls in case of complex static scenes with lots of occlusion. Plan your levels to benefit from Occlusion culling.* Use skyboxes to “fake” distant geometry.

삼국지를 품다 SSAO 조절

Wed, 15 Feb 2012 15:49:39 +0000

삼국지를 품다는 포워드 렌더러로 돌고 있습니다. 유니티 엔진은 디퍼드 렌더링도 가능하지만, 디퍼드 렌더링 쓴다고 무조건 좋아지는거 아닙니다 -_-; 기본적으로는 포워드 렌더링이 가볍게 만들기 좋지요.

근데 문제가 여기서 SSAO를 사용하면 원거리에서 좀 문제가 생긴단 말이지요.
특히 포그 있는데서.

일단 잘보이게 좀 강하게 처리해 봤습니다.

저렇게 먼거리에서 검댕이가 생깁니다.

지금이야 좀 과장한 거라고 하지만, 과장 안해도 멀리 포그가 짙은 곳에서 검뎅이가 왔다갔다 하는건 좀 거시기 하지요잉. 눈에도 은근히 잘떠서 스트레스.

어쨌건 간단하게 말하면
SSAO 데이터를 뽑은것에다가

Z 버퍼값을 조금 모디파이한 녀석을 준비해요.

그리고 이 둘을 더하면
이렇게 되겠지요.

물론 거리는 조절가능. 기본은 0.5로 해놨는데 아마 충분할 겁니다.

그러면 먼 거리는 SSAO가 안먹어요잉.

수치조절은 맵마다 할 수 있어요.

근데 나 여기까지 건드리니까 레알 프로그래머 같애..

Unity 3.5 신기능 : HDR (High Dynamic Range)

Mon, 13 Feb 2012 10:07:23 +0000

HDR (High Dynamic Range) HDR 하이 다이나믹 레인지 : 고 계조영역

Overview 총론

Normally when rendering a scene pixel values are clamped with a maximum intensity of 1.0, HDR rendering removes this limitation and allows stored pixel values to have an intensity greater than 1.0. As monitors normally only display intensities in the range of 0.0 - 1.0 this range needs to be mapped back into a visible range. This is achieved via a process known as tone mapping.
보통 씬의 픽셀이 렌더링 될때 , 빛의 최대강도는 1.0에서 짤립니다. HDR 렌더링은 이러한 제한을 제거하고 픽셀에 조명 강도를 1.0 이상으로 저장할 수 있게 합니다. 모니터도 일반적으로 빛의 강도를 0.0~1.0으로만 표현할 수 있고, 이 영역은 보이는 영역으로 다시 리맵핑 되어야 합니다. 이것은 톤 매핑이라는 프로세스를 통해 달성됩니다. (주: 조명 강도가 1.0 이상으로 높게 저장된 조명 값은 톤매핑이라는 과정을 통해 모니터의 한계인 1.0 안으로 조정됩니다 )

Enabling HDR HDR활성화

HDR rendering is a per camera setting in Unity. It is exposed via a new property on the camera. By selecting this checkbox it is telling unity to internally use the HDR pipeline.
HDR 렌더링은 유니티의 각각의 카메라 셋팅에 있습니다. 이것은 카메라의 새로운 속성에 노출되어 있습니다. 이 체크박스를 선택하면 유니티에게 내부적으로 HDR 파이프라인을 사용하라고 얘기하는 것입니다.

Working with HDR HDR과 일하기

Once HDR is enabled the scene is rendered as it normally would be, but into an HDR buffer. When the rendering is completed the resultant image is passed to the Unity post processing effect pipeline, it is here that HDR bloom, tonemapping and other HDR image effects can be configured. At some stage the image should be mapped back into the LDR range for display via an image effect. ImageEffectTransformsToLDR is a new attribute can be added to an image effect to indicate that the target buffer should be in LDR instead of HDR.
HDR이 활성화되면 씬은 일단 보통으로 렌더링될 겁니다만, HDR 버퍼로 들어갑니다. 렌더링이 끝나면 결과 이미지는 유니티 후처리 이펙트 파이프라인으로 옮겨집니다. 여기에는 HDR 블룸, 톤매핑 그리고 다른 HDR 이미지 이펙트가 설정되어 있습니다. 어떤 스테이지에 오면 이미지가 이미지 이펙트에 의해 LDR (주: HDR의 반대) 로 다시 맵핑됩니다. ImageEffectTransformsToLDR 은 타겟 버퍼가 HDR 대신 LDR로 되게 하는 이미지 이펙트가 더해질 수 있게 해주는 기능입니다. (주: HDR이었던 이미지가 중간에 과정을 거쳐서 다시 LDR로 바뀌게 됩니다. HDR로는 출력할 수 없기 때문에 반드시 최종적으로는 LDR로 바꿔줘야 하거든요)

Tonemapping 톤매핑

Tonemapping is the process of mapping HDR values back into the LDR range. There are many different techniques, and what is good for one project may not be the best for another. A variety of tonemapping image effects have been included in Unity. To use them select Assets -> Import Package -> Image Effects (Pro Only) select the camera in the scene then select Component -> Image Effects ->ToneMapping a detailed description of the tonemapping types can be found in the image effects documentation.
톤매핑은 HDR 값을 LDR 영역 값으로 돌리도록 해주는 프로세스입니다. 이것은 많은 다른 테크닉이 있고, 어떤 프로젝트를 위한 좋은 설정이 다른 프로젝트에도 최적의 것은 아닙니다. 톤매핑 이미지 이펙트의 다양함은 유니티에 내장되어 있습니다. 이들을 사용하려면 Assets -> Import Package -> Image Effects (Pro Only) 을 불러옵니다. 카메라를 선택하고 Component -> Image Effects ->ToneMapping 을 선택합니다. 톤매핑 타입에 대한 세부적인 기술은 image effects documentation. 에서 찾을 수 있습니다.

An exceptionally bright seen rendered in HDR. Tonemapping is used to bring the bright intensities back into the displayable range.
비정상적으로 밝은 씬이 HDR 렌더링입니다. 톤매핑은 이런 밝기를 정상적으로 보이는 밝기로 돌려줍니다.
(주: 원래 위에 보이는 비정상적으로 밝은 씬이 실제 세계에서는 정상인 씬입니다. 그렇지만 저 상태가 모니터로는 표현할 수 없기 때문에 강제로 내려준게 아래입니다. 톤매핑이 이것입니다. )

HDR Bloom HDR 블룸

Using HDR allows for much more control in post processing. LDR bloom has an unfortunate side effect of blurring many areas of a scene even if their pixel intensity is less than 1.0. By using HDR it is possible to only bloom areas where the intensity is greater than one. This leads to a much more desiarable outcome with only super bright elements of a scene bleeding into neighboring pixels. The built in ‘Bloom and Lens Flares’ image effect now also supports HDR. To attach it to a camera select Assets -> Import Package -> Image Effects (Pro Only) select the camera in the scene then select Component -> Image Effects ->Bloom (Supports HDR and Lens Flare) a detailed description of the ‘Bloom and Lens Flares’ effect can be found in the image effects documentation.
HDR은 훨씬 많은 컨트롤을 후처리에서 할 수 있게 해 줍니다. LOD 블룸(주: 기존의 블룸) 은 운나쁘게도 밝기가 1.0 이하인 값에서도 부작용으로 블룸이 먹어 버리곤 했었습니다. HDR을 사용하면, 이제 확실하게 밝기가 1.0 이상인 부분만 블룸을 정확히 줄 수 가 있게 됩니다. 이것은 이제 더욱 더 확실하게 ‘굉장히 밝은 영역이 인접한 영역에 영향을 끼치는’ 정확한 결과물을 나타낼 수 있게 해 줍니다. (주: 블룸이 정확해져서, 쓸 데 없는 것이 타버리는 것을 방지할 수 있습니다)기본 내장된 ‘Bloom and Lens Flares’ 이미지 이펙트는 또한 HDR을 지원합니다. 이것을 카메라에 붙이려면 Assets -> Import Package -> Image Effects (Pro Only) 를 불러오고 카메라를 선택한 후 Component -> Image Effects ->Bloom (Supports HDR and Lens Flare) 를 적용하면 됩니다. 더 많은 세부 문서는 이미지 이펙트의 ‘Bloom and Lens Flares’항목에서 찾으시면 됩니다.

An exceptionally bright scene where bloom has been applied to intensities of > 1.0. The bloomed image has also been tonemapped back into a displayable range.
1.0 이상의 과도하게 밝은 이미지에 블룸이 적용되었습니다. 블룸 이미지는 보여지는 영역 안으로 다시 톤매핑 되게 됩니다. (주: 역시 너무 밝아 안보이거든요 HDR 상태에서는)

Advantages of HDR HDR의 장점

Colors not being lost in high intensity areas
아주 밝은 영역에서도 칼라값을 잃어버리지 않습니다.* Better bloom support
훨씬 좋은 블룸을 제공합니다. * Reduction of banding in low frequency lighting areas
적은 주파수의 라이트 영역에서의 밴딩을 줄입니다.

Disadvantages of HDR HDR의 단점

Uses Floating Point buffers, so is slower
부동 소수점 포인트의 버퍼를 사용합니다. 그래서 느립니다.* Not supported on all hardware
모든 하드웨어에서 사용되는것은 아닙니다.

Usage notes 사용 방법

Forward Rendering 포워드 렌더링

In forward rendering mode HDR is only supported if you have an image effect present. This is due to performance considerations. If you have no image effect present then no tone mapping will exist and intensity truncation will occur. In this situation the scene will be rendered directly to the backbuffer where HDR is not supported.
포워드 렌더링 모드에서 HDR은 당신이 이미지 이펙트를 제공할때에만 지원합니다. 이것은 퍼포먼스 고려에 기인합니다. 만일 당신이 이미지 이펙트를 적용하지 않으면 톤매핑은 없을 것이면 밝기는 짤려 버릴 겁니다 (주: 1.0 이상 밝기는 날라가 버릴 겁니다. 기존처럼 말이죠) 이 상황에서 씬은 백버퍼에 HDR을 고려하지 않은 채 바로 렌더링 될겁니다.

Deferred Rendering 디퍼드 렌더링 (지연 렌더링)

In HDR mode the light prepass buffer is also allocated as a floating point buffer. This reduces banding in the lighting buffer. HDR is supported in deferred rendering even if no image effects are present.
HDR 모드에서 라이트 프리패스 버퍼는 또한 부동소수점 버퍼로 할당됩니다 (주: 어차피 플로팅 포인트로 렌더링된다는 말씀) . 이것은 라이트 퍼버의 밴딩을 줄입니다 (주: 밴딩. 줄무늬. 계조가 부족해서 생기는 그라디에이션의 끊김을 말함) 디퍼드 렌더러에서는 이미지 이펙트가 설정되지 않더라도 HDR이 가동됩니다.

Page last updated: 2011-11-22

삼국지를 품다 2차 서포터즈 테스터 모집!!!

Fri, 10 Feb 2012 17:10:57 +0000

저번보다 확실히 많이 다듬었어요.

코피쏟으며 작업한 삼품팀 화이팅.

http://3p.nexon.com/event/Main2nd

요새 일과

Thu, 09 Feb 2012 09:33:53 +0000

6시 반 기상

주섬주섬 준비하고 출근준비
7시 반
헬스장 도착. 헬스하면서 영어강의 또는 팟캐스트 청취
8시 반
회사로 출근
오후 6시
근무 끝. 그치만 약간씩 +a 됨
오후 8시
집에 옴. 저녁먹음. 혹은 먹고 올때도 있음.
2시간쯤 쉼. 블로그도 돌고, 서핑도 좀 하고..
오후 10시
2시간쯤 공부. 유니티 스크립트 / 게임개발 포에버 글쓰기 / 강연준비
12시 반
낼 일찍 일어나려면 버틸 수가 없음. 자야 함. 만화 좀 보면서 잠들음.

… 도대체 드라마 본다는 사람들은 언제 시간이 나는 걸까.

자격증 _ 백업

Tue, 07 Feb 2012 10:12:19 +0000

절대비공개

ShaderFX를 이용한, 그래픽 디자이너를 위한 기초 쉐이더 강좌 5강

Fri, 03 Feb 2012 01:10:36 +0000

http://gamedevforever.com/

에서 연재합니당.

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

ShaderFX 메터리얼

자… 지금까지 배운 것들을 잠깐 정리해 보겠습니다.

a. 칼라 노드를 만들 수 있게
되었습니다.

원하는 칼라가 출력되는 노드를 만들 수 있게 되었습니다.

b. 텍스쳐 노드를 만들 수
있게 되었습니다.

사실 정식으로 쉐이더 코드를 짜려면, 텍스쳐 샘플러를 선언하고, UV 를 버텍스 쉐이더에서부터 받아서 픽셀 쉐이더로 넘겨오는 과정부터 거쳐야 하지만, 맨 첫 강의때 말했듯 이건 그래픽 디자이너를 위한 강의이므로 ‘일단 간지나게 만들고 공부는 나중에 한다’ 라는 구조로 진행합니다 후후후
그러므로 여러분은 텍스쳐 노드를 만들 수 있게 되었습니다.

c. 텍스쳐 노드의 채널을 따로 따로 다룰 수 있게 되었습니다.

RGBA로 이루어진 텍스쳐 채널 구조를 배우게 되었습니다. 각각은 float으로 이루어진 상수이고, 이것들이 모여서 칼라와 투명도를 정합니다. 그리고 따로 사용할 수도 있습니다.

d.상수를 만들 수 있게 되었습니다.

상수, 별 거 아닙니다. 그냥 숫자입니다. 1+1 같은 공식에서 1이 상수란 말입니다. 여기서는 float 이라고 해도 문제 없겠지요. 어차피 보통 소숫점을 쓰니까요.

e. 연산자를 만들 수 있게 되었습니다.

사칙연산이 가능하게 되었습니다. 이것도 별 거 아니죠. 1+1 에서 +를 만들 수 있게 되었다는 건데… 물론 곱하기나 빼기 등도 만들 수 있게 되었습니다. 거의 사용하지는 않지만 나누기 부호도 만들 수 있게 되었구요.

f. 이 출력물들을 연결할 수 있게
되었습니다 .

이 출력물 노드들을 이리 얽히고 저리 얽히게 만들어서 출력할 수 있게 되었습니다. 그리고 Ambient Color에 연결할 수 있게 되었습니다. (여태까지 Ambient Color에만 연결하신 분은 없으시겠지만)

생각보다 꽤 많은 것을 했네요!

지겨우셨을지도 모르지만, 사실 위 내용은 ShaderFX를 다루기 위한 기본 조작 같은 것입니다. 이제 여기에 함수가 추가되면 재미있는 기능이 발현되게 되지요. 그 때부터는 본격적 실습입니다 실습 !

그러기 위해서 오늘은 … 배운것을 총 정리하는 겸 해서
ShaderFX 메터리얼을 배워보도록 합시다!
별 거 아닙니다. 이 왼쪽에 있는 진짜 루트 노드 말예요 이거.

여기에 연결하는거 배워보도록 하자는 거지요.
겸해서 라이팅에 대한 기본적인 지식을 쬐끔 배워보는 시간을 가지도록 하겠습니다.

제대로 배우시고 싶다고요? 제대로 배우려면 하나당 한 번의 강의로 해야 해요.
그러니 그건 나중에 , 라이팅을 직접 만들 때가 옵니다. 그 때 알려 드릴께요 .
그전에 실버치매님이 알려주시겠지

오늘 강의를 따라하면 드디어 이런 이미지를 만들 수 있게 됩니다.
그런대로 볼만하지요?

Diffuse Color 연결하기

Diffuse Color는, 확산광 (擴散光) 이라고도 불리며[각주:1] , 복잡하게 설명하면 어려워지지만, 간단하게 이렇게 생각하면 일단 편합니다.

“빛 때문에 밝고 어두워지는 색깔”

나중에 자세히 말하겠지만, Diffuse Color에서 가장 밝은 부분은 1이고, 가장 어두운 부분은 0입니다. 당연하게도 중간쯤 밝은 부분은 0.5겠지요.[각주:2]
그리고 이 값이 텍스쳐에 곱셈 연산이 됩니다. 즉 가장 밝은 부분은 텍스쳐의 고유한 색상이 되고, 가장 어두운 부분은 검은색이 되는 거지요.

그러므로, 아래 그림처럼 텍스쳐 노드를 만들고, RGB 채널을 Diffuse Color에 연결해 주면 그것으로 끝입니다.
빛의 밝고 어두움에 따라 음영이 지는 주전자를 볼 수 있습니다.
D_cobblestone.dds 를 적용하였습니다. [각주:3]

Ambient Color 만들어 연결하기

지금 당장 책상 아래를 보세요. 빛이 전혀 닿지 않는 곳임에도 불구하고 새카맣지 않고, 어스름히 보입니다.
그렇지 않습니까? 이것은 무엇 때문일까요?

이 세상에는 많은 물체가 있고, 그 물체들은 태양으로부터 나온 빛을 받아 반사하거나 , 흡수하고 있습니다. 때문에 빛이 직접 닿지 않는 곳이라 하더라도 새카맣게 보이는 경우는 없지요.

이 계산을 실제로 한다면 엄청나게 복잡할 수 밖에 없습니다 .때문에 이런 ‘환경 반사광’ 을 직접 계산하지 않고, 단순히 칼라를 더해 (+) 줌으로써 이를 흉내내 주곤 하지요. 이것이 환경광 (Ambient light) 입니다.

이 빛은 방향성도 없고, 그냥 전체 화면에 일정 색을 더해주는 것 뿐입니다. 이것은 어떤 환경이냐 따라 다양한 색을 가지는데요. 쉽게 말해서 석양이 질 때는 붉은 계열 색을, 맑은 날에는 푸른 계열의 색을 쓰는 것이 일반적입니다.

아주 맑은 날은 건물의 어두운 부분이 하늘색입니다. 이것이 Ambient light.
자, 이렇게 Ambient Color에는 그냥 단색 칼라를 연결해 주도록 합시다.[각주:4]

잘 보이게 하기 위해서 조금 강하게 넣었습니다. 조금만 밝아도 화면 전체가 밝아지니, 아주 어두운 색을 조심스럽게 쓰는 것이 요령입니다. 칼라를 조절하고 Set 버튼 누르는 것을 잊지마세요.

Specular Color 만들어 연결하기
Specular Color는 정반사 (正反射 : Specular Reflection) 의 색상을 의미합니다. 이것은 광원으로부터 나온 빛이 바로 반사하여 시야에 들어오는 ‘하이라이트’ 를 의미하는데요.
자세한 내용은 실버치매님의 글 http://gamedevforever.com/17 을 읽어보시면 되겠습니다. [각주:5]

여기서는 그냥 색을 넣어주기만 하면 가동됩니다.
일반적으로 아무 생각 없을 때에는 흰 색을 넣는데요. 실버치매님의 글을 읽어보시면 사실 이렇게 간단한게 아니라는걸 아실 수 있으실 겁니다 .

그래도 우리는 초보니까 흰 색을 넣지요 헤헷.

간단하게 Specular 라이팅이 활성화 되면서, 칼라도 들어갔습니다. 물론 흰색은 좀 이상하지요. 원하시는 색으로 바꾸셔도 무방합니다. 정렬의 빨강색이라던가
심지어, float3가 들어가니까 RGB텍스쳐를 따로 만들어 적용하는 것도 가능합니다.[각주:6]

Specular Level 연결하여 조정하기

이제 그 아래 있는 Specular level입니다. 이것은 스페큘러의 강도 같은 것을 결정하는건데요, float 하나가 들어간다는 것을 알 수 있습니다. 즉 0~1 사이의 값으로 강도를 조절한다는 거지요.
물론 상수를 하나 만들어서 저기다 연결해도 잘 작동합니다만…

자, 지금 더 돌 재질을 잘 보세요. 무슨 느낌인가요? 마치 덕수궁 돌벽같은 느낌이 아닌가요? 돌이 튀어나와있고 돌들 사이에 시멘트로 매워진 벽 느낌이요.
여기서는 그래서 돌 재질이 있는 부분만 반짝이고, 경계선 부분은 반짝이지 않게 하려면 어떻게 해야 할까요?
뭔가… 마스킹이 있어야 하겠지요? 돌 부분은 살리고 경계선은 죽이는.. 그런 이미지가 필요할겁니다.
그리고 그 마스킹 이미지가 이미 있습니다.

Diffuse Texture 로 사용했던 이미지의 Display Alpha 옵션을 켜보세요. 이건 이 이미지의 알파 채널이 있다면, 그 알파 채널이 어떻게 생겼나 보여주는 겁니다.

그걸 켜 보니까 이미지가 바뀝니다! 흑백의 알파 채널 이미지가 나옵니다.
네, 이 이미지는 알파 채널을 가지고 있었던 겁니다. 그것도 저런 모양으로.
마스킹으로 쓰기에 딱 좋은 이미지로 보입니다.

이전에도 누차 말씀드렸지만, 알파 채널에 그림이 있다고 전부 투명도는 아닙니다. 그 채널을 ‘Opacity’ 에 연결했을때 투명도가 되는거지, 아무 짓도 하지 않으면 어떤 채널에 있는 이미지건 그냥 float 덩어리일 뿐이란 말씀입니다.

이 오브젝트는 투명도가 필요 없습니다. 즉 이미지의 알파 채널은 어차피 쓰지 않는단 말이지요.
그래서 우리는 이 알파 채널을 Spacular level로 쓰기로 결심하였습니다. 이어줍시다.[각주:7]

연결했습니다 . Specular 영역이 잘 보이도록 Specular Color를 빨강으로 바꿔 보았습니다. 어떻게 보입니까?
돌이 있는 부분은 Specular 가 강하게 들어갔고, 돌이 없는 사이의 부분은 매우 약하게 들어갔다는 것을 볼 수 있습니다.
마스킹 이미지도 보시면, 밝은 부분이 아주 흰 색이 아니고 어두운 부분이 아주 검은 색도 아닙니다.
그래서 이렇게 적절한 강도로 들어간 것입니다. 위에 소개한 실버치매님의 글을 읽어 보신분은 아시겠지만, 완전히 Specular가 없는 물체는 없는 법이니까요. 오히려 이게 더 자연스럽다고 할 수 있겠습니다.

Glossiness 연결하여 조정하기
Glossiness는 Specular의 퍼짐 정도를 조절하는 메뉴입니다. 둔탁한 오브젝트일수록 Specular가 퍼질 것이고, 유리나 잘 닦은 당구공처럼 매끄러운 오브젝트일수록 Specular가 강하고 얇게 맺힐 것입니다. 이걸 조절하는 겁니다.

이건 단순하게 상수로 조절해 주도록 하겠습니다.
굳이 이젠 설명할 필요도 없겠지요. 직접 비교해 보세요.

1일때에는 넓게 퍼집니다.

10 정도 되니까 좀 줄어드는 군요.

100 정도 되니까 더 작아졌습니다.

물론 이것도 float이기 때문에 아까 Specular level에서 사용한 Alpha 채널을 마스킹으로 이용할 수 있겠습니다만, 그냥은 못쓰고 * 10 정도를 해 줘야 조금 쓸만할 겁니다. 그치만 여기서는 해도 잘 안보일것 같아서 넘어가도록 하지요. 다음에도 할 기회는 충분합니다.

자 이제 값을 20정도로 하고 Speculat Color도 다시 흰 색으로 만들었습니다.

Self - Illumination 만들어 연결하기
Self-illumination (자기 발광 自己發光) 은 스스로 빛나는 효과 같은 것을 만들때 사용됩니다. 스스로 빛을 내는 발광체 표현을 할 때 주로 사용되지요. Diffuse Color의 음영값과 상관없이 자신의 칼라가 언제나 나타나게 되는 특징이 있습니다. [각주:8] 셰이더 프로그래밍에서는 Self-illumination이란 말을 거의 쓰지 않고, Emission 이라는 말을 주로 사용합니다

사실 이번엔 안 쓸 재질이지만, 특별히 시험삼아 잠시 텍스쳐를 넣어 보았습니다.
caustics_001.bmp 가 적절해 보이는군요. [각주:9]

뭔가 빛나는 것처럼 보입니다.

시험삼아 넣어본 것이니, 삭제하도록 하겠습니다.

Normal map 넣어보기
네에 Normalmap입니다. 뭔가 마법의 텍스쳐같은 Normal맵이죠. 분명 폴리곤이 없는데도 막 울퉁불퉁해지는!!!
그 이유 같은건 역시 나중에 알아보고, 일단 넣어보도록 해보겠습니다.

노말맵을 만들 때에는 일반 텍스쳐처럼 만들면 안됩니다.
빈 화면에서 오른쪽클릭을 하고 Maps/NormalMap을 선택합시다.

일반 텍스쳐를 선택하면 안됩니다. 노말맵은 -1.0~ 1.0 사이의 값이 필요해서, 그냥 텍스쳐 영역을 쓰면 안되거든요.[각주:10]

그리고 여기에 N_cobblestone_ati.dds 를 넣어주겠습니다.
잘 나옵니다

…Opacity는 안넣겠습니다. 뭐 다 알잖아요?

오늘은 이렇게 메터리얼에 값 넣는 것을 해 보았습니다. 중간에 연산자 같은거 넣고 막 이러면… 복잡하게 할 수 있어 보이죠? 앞으로 하다보면 다 하게 됩니다. 힘내세요!

다음 시간에는 뭘 할까요? 이런걸 생각하고 있긴 한데..

Lerp로 텍스쳐 섞기
큐브맵 사용해 보기

난반사광 이라고도 불리며, 산광이라고 불리는 등, 여러 가지 용어로 불리우고 있습니다. 그냥 Diffuse light 라고 부르는 것이 나을 것 같습니다. [본문으로]
추후에 이 계산을 직접 수식으로 만들어 보게 됩니다. 그 때 더 자세히 알아보도록 하지요. [본문으로]
빛을 직접 설치하고 싶으신 분은, Directional light 하나를 설치해 보십시오. 여러 개도 가능하지만, 현재 설정으로는 한 개의 Directional light 밖에 적용되지 않습니다. [본문으로]
물론, IBL 이나 Ambient Cube 등의 발전된 기법들도 사용됩니다만 아직도 많은 게임들은 단순한 Ambient Color를 쓰는 경우가 많으므로 우리도 그렇게 하는 것이 아무런 문제가 되지 않을것입니다. [본문으로]
저는 이거보다 더 잘 쓸 자신이 없어서요. [본문으로]
텍스쳐가 한 장 더 필요하게 되므로 리소스도 사용하게 되고 만들기도 귀찮은 작업이 되지만, 최신 게임에서는 실제로 이렇게 만들어서 적용하고 있습니다. 당장 여러분의 다음 프로젝트에서도 쓸 지도 모르지요! 아니면 이미 쓰고 있다던가!!! [본문으로]
실무에서도 엄청나게 많이 쓰이는 요령입니다. 텍스쳐는 무조건 아껴야 하거든요. 남는 채널이 있으면 무언가의 마스크로 꼭 쓰도록 합시다. [본문으로]
뭔가 거창해 보입니다만, 사실은 Ambient와 다른게 하나도 없는 녀석입니다. Self - illumination에 넣지 않고 Ambient Color에 넣어도 완전히 똑같이 작동합니다. [본문으로]
앗! 노드들이 어떻게 저렇게 작은 사이즈로 변했지요? 라고 생각하신다면, 노드를 더블클릭 해 보세요. :) [본문으로]
뭐 지금부터 알 필요는 없지만…. 0.0~~1.0 사이에 있는 값을 -1.0~~1.0 으로 확장하는 법은 *2-1 을 해주면 됩니다. 이런 놀라운 (?) 공식을 ‘매직 넘버’ 라고 합니다 :) [본문으로]

그래 뭐 게임이 마약이라고 하자

Tue, 31 Jan 2012 14:42:18 +0000

게임은 마약이다.

이 나라를 걱정하신다는 높으신 분들께서는 고스톱 한 번 안치고 오락실 한 번 안가고 공부하신 고귀한 분들이시니 판검사 의사 외에는 직업도 아닌 그분들의 시선에서는 게임은 마약하고 다를 바가 없는게 당연합니다. 그 분들이 게임을 해보셨겠습니까 아니면 마약을 해보셨겠습니까? 사람들은 자신이 모르는 것은 대충 비슷하게 보기 마련이지요. 우리가 미국인과 덴마크인을 잘 구별 못하듯이 말이죠.

우리가 남미의 갱단과 마피아와 마약상의 차이가 뭔지 알게 뭡니까? 그거랑 마찬가지지요.

그리고 뇌과학이 그렇게 만만한 분야가 아니란걸 다들 알고 있을겁니다. 인간의 뇌가 100% 규명되었다고 생각하시나요? 아직도 제대로 규명못한 뇌 질환이 한두갠가… 감기도 못잡는 현대 의학 주제에…
그런데 그 빈약하기 그지없는 이론들을 가지고 게임을 하면 뇌가 짐승이 된다는 등의 근거없는 드립들을 날리고 있는데, 뭐 좋습니다. 저번에 뇌 관련 유명한 교수님들을 교과부에서 데려다놓고 공청회를 했을 때에도 ‘꼭 게임이 뇌가 안좋아지는데 영향이 있다고 말할 수는 없다’ 라는 애매모호한 결론을 내놨지만, 뭐 그것도 좋습니다. 원래 뇌 과학은 다 그런거지요.

사실 저도 게임 만드는 입장이지만, 게임 너무 많이 하면 안좋은것 같다는데 동의합니다.
근거? 근거는 둘째치고, 어쨌건 안좋은거 같단 말입니다.
TV를 너무 많이 봐도 안좋고, 공부를 너무 많이 해도 안좋고, 밥도 많이 먹어도 안좋습니다.
세상에 너무 많이 해서 좋은게 뭘까? 그런건 없습니다. -_-;

그런 의미에서 쓸데없이 뇌가 어쩌고 하는 개드립과 굳이 연결하지 않더라도,
저는 게임을 너무 많이 하면 안좋다는데 동의한단 말입니다.
그런 의미에서 게임을 하는 것도 , 적절하게 자신이 컨트롤 하면서 해야 한다는데에도 적극 동의합니다.
영화처럼, 아이들이 하기에 안좋아 보이는 게임이 있는 것도 사실이라고 동의합니다. 그러니까 등급이 있는거 아닙니까.

역사는 되풀이된다.

자, 좋습니다. 게임을 적절히 통제해야 한다는데 동의한단 말입니다. 밥먹는 것도 통제해서 다이어트 하는데 당연히 게임도 통제할 수 있겠죠.

근데, 웃기는건 그 통제하는 방법이란 말입니다.

십몇년전쯤인가 사건이

ShaderFX를 이용한, 그래픽 디자이너를 위한 기초 쉐이더 강좌 4강

Tue, 31 Jan 2012 09:32:00 +0000

밝힐 것이 있습니다.
사실 여기서 shaderFX를 강의하고, 이 강의가 자연스럽게 포프님의 쉐이더 강의로 이어지는 것이 목표였습니다.
포프님의 강의가 물론 매우 쉽다는 것 인정합니다만, 지금의 제 수준에는 그렇다는 거고…
제가 처음 쉐이더에 관심가지던 그래픽 디자이너였던 4-5년 전에는 그 정도도 결코 쉬운게 아니었었다는거지요!!! 프로그램 몰라!! 어려워!!! 그게 뭐야!!! 이쁘지도 않은 영어 메모장으로 일을하다니 이 천한것들

그리고 나서 다시 유니티 쉐이더로 와서 … 그래픽 디자이너들이 간단한 유니티 쉐이더 정도는 직접 코딩할 수 있게! 하는게 목표였는데… (겜브리오 쉐이더로 할까 하다가 , 겜브리오 쉐이더보다 유니티 쉐이더가 훨씬 쉽게 짤 수 있어서..)

한 3강 써보다 보니 이 속도로 쓰다간 원하는 걸 다 쓰려면 산 3-4 년 걸릴 것 같지 뭡니까 이히히히
그래서 걍 그냥 맘편하게 ShaderFX 만 집중해서 쓰기로 생각했습니다. 그래서 제목도 맨 앞에 ‘ShaderFX를 이용한’ 이라고 붙였지요. 아무도 관심없었다는거 잘 알지만.
어쩐지 덕분에 게임개발 포에버 사이트에서는 제가 오래오래오래 글 쓸 것 같은 생각이 들긴 합니다만 … ㅋ

하여간 그래서 오늘 강의 시작합니다.

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

Float을 산수로 가지고 놀자.

모든 색은 float3로 이루어질 수 있다고 저번 시간에 말씀드렸습니다. 그러니까 모든 그림의 한 픽셀 한 픽셀들은, 각각 float3의 색상 구조로 이루어져 있다는 거지요.

이렇게 모든 그림을 3자리 소숫점인 float3로 인식을 하는 ‘개념’ 이 매우 중요합니다.
제가 강의를 해 본 결과에 의하면, 그래픽 디자이너에게 가장 부족한 개념이 이 부분이었거든요.

자 , 저번 시간의 약간의 복습입니다.
일단, 회색 주전자가 있네요. 만만한게 주전자죠. 넹.

2377579

자 , 이 주전자의 텍스쳐를 빨리 숫자로 생각해 보세요! 3,2,1 땡!

넹

float3(0.5,0.5,0.5) 일겁니다.[각주:1]

여기까지는 쉽게 순간적으로 생각해 낼 수 있어요.
그럼 이제 다시 한 번, 약간의 산수를 해 봅시다. 색상은 잠깐 생각하지 마세요.

float3(0.5,0.5,0.5) 의 각각 요소에다가, 0.5 씩을 더하면 어떻게 될까요?
즉 float3(0.5,0.5,0.5) + float3(0.5,0.5,0.5) 라는 말이죠.

그래픽 디자이너라고 무시한다고 생각하실 수도 있겠지만 …
아시잖아요. 우리같이 그림만 그리고 살아온 사람들은 가끔 돈계산도 깜빡깜빡 합니다. 으흐흐.
간단하지요?

float3(0.5,0.5,0.5) + float3(0.5,0.5,0.5) = float3(1.0,1.0,1.0) 입니다.
… 흰색이네요??!??

넹 , 수학적으로는 알겠고, 이번엔 잠깐 봉인해놨던 색으로 생각해 보지요.

float3(0.5,0.5,0.5) + float3(0.5,0.5,0.5) = float3(1.0,1.0,1.0) 이니까,
회색 에다가 회색 을 더하면 흰색이 된다.

라는 말씀이지요?
달리 말하자면,
‘색끼리 더하면 값이 올라간다. 즉 밝아진다는 뜻이다’ 라는 말이 됩니다.[각주:2]

자 이제 그럼 이걸 직접 만들어서 증명해 봅시다.

ShaderFX로 연산해 보기

뭐 간단합니다. 회색 + 회색 이니까요. 만들어 봅시다.

일단 이 상태에서 시작합시다.

회색 칼라 노드를 하나 더 만듭시다. 빈 화면에서 오른클릭 -> Maps -> Color 를 선택하면 됩니다.[각주:3]

그리고 색상은 회색으로 지정합시다. 회색 노드가 두 개가 되었습니다.

자 이젠 덧셈 기호가 필요합니다.
이게 셰이더 코딩으로 하면 그냥 A+B 하면 되는데, 노드 구조에서는 굳이 이것도 노드를 만들어줘야 합니다 .
이게 사실 좀 귀찮긴 한데 개념적으로만 보면 쉽긴 하죠. 익숙해지면 귀찮아요 ㅋㅋㅋ

다시 빈 화면에서 오른쪽 클릭해서 Math / MathOperator 를 만듭니다. 이게 연산자 노드예요.

연산 노드가 나왔습니다. 기본은 * 연산으로 되어 있습니다. 오른쪽 메뉴에서 + 로 바꿔줍시다. 그럼 오퍼레이터가 + 로 바뀝니다.

둘을 더해야 하니까, Input A 와 Input B 에다가 회색 노드를 연결시켜줍니다.
그리고 결과물을 Ambient Color 에 연결해 줍니다.

자, 개념이 쉽게 잡히지요? 두 회색을 더한 겁니다. 즉 float3(0.5,0.5,0.5) + float3(0.5,0.5,0.5) 를 만들었고, 결과물을 Ambient Color로 연결한거지요.

자, 결과물이 나왔습니다. 흰색입니다. float3(1.0,1.0,1.0) 이 나왔지요.

만약 이걸 곱하기 (*) 로 바꾸면 어떻게 될까요?

자, 이렇게 나옵니다. 이제 쉽게 예상하실 수 있으시겠지요?
float3(0.5,0.5,0.5) * float3(0.5,0.5,0.5) = float3(0.25,0.25,0.25) 지요.
소수점 숫자들끼리 곱하기를 하면 숫자가 더 작아집니다. 그러니까 더 어두워진다는 거지요!

자 더 어두워졌지요? 배경이 꽤 새까맣기 때문에 그렇게 안보이지만, 회색보다는 더 어두운 회색이 되었습니다.
이것은 포토샵에서의 레이어 모드 중, Multiply 랑 똑같습니다!

알면 재밌습니다.

셰이더 연산을 할 때에는 위에서 본 것과 같이 덧셈과 곱셈 연산을 주로 쓰고, 뺄셈은 가끔 쓰고, 나눗셈은 거의 안쓰다시피 합니다. (2로 나누나 0.5를 곱하나…)[각주:5] 뭐 그래도 다른 것도 한 번 해보시고 이해해 보시면 더 좋겠지요?

숙제가 있습니다. 흑백으로만 하면 재미없으니까, 칼라를 가지고 놀아보세요. 빨강 (1.0, 0.0, 0.0) 과 파랑 (0.0,1.0, 0.0) 을 각각 더해보거나 곱해보면 무슨 일이 생길까요? 그리고 왜 그런 결과가 나올까요?

상수 추가하기

미리 얘기했듯 저는 정말로 쉬운 강의입니다.
어려운 예제같은건 안해요 우후후
어려운 예제하면 내가 힘들걸랑

그러니깐 이번엔 위의 예제랑 똑같은거 하나 또 만들어 봅시다.

지금 위의 연산은 이런거였죠?
float3(0.5,0.5,0.5) + float3(0.5,0.5,0.5)
다행히 위의 그림은 단색입니다. 즉, 어떤 부분의 픽셀을 선택하더라도 전부
float3(0.5,0.5,0.5) + float3(0.5,0.5,0.5)
라는 거지요.

복잡한 이미지의 칼라라면, 픽셀마다 색이 다르겠지만 저 단색 칼라는 어딜 찍어도 float3(0.5,0.5,0.5) 입니다.

그러니까.

요런것도 가능해져요.

float3(0.5,0.5,0.5) + 0.5

이것도 똑같은 결과가 나오게 됩니다.
뭐 일단 해볼까요?
일단 아래 그림에서 시작해 봅시다.

두 노드 중 하나를 지워보고, 하나를 숫자로 (상수로) 바꿔봅시다.
일단 노드 하나를 선택해서 DEL 키를 눌러 지웁니다.

지우고 나면, Input B 가 비지만, 위 그림의 오른쪽 화살표를 보면 기본값이 1.0이 들어가고 있다는 것을 알 수 있습니다.[각주:6]
자 이것 말고, 상수 노드를 따로 만들어서 추가해 봅시다.

위 그림처럼, Maps/Constant 를 추가해 봅시다. 이게 상수입니다.

이제 조금 익숙해졌을테니, 조금 빨리 진행해 보지요. Constant 노드를 만들면, float 이 빠져나오는 것을 알 수 있습니다. 한 자리 숫자지요. 그리고 이 숫자는 오른쪽 메뉴에서 수정할 수 있습니다. 실시간으로요!!!
이걸 Input B 에 연결하면, float3(0.5,0.5,0.5) + 0.5 가 됩니다.

이제 이것이 float3(0.5,0.5,0.5) + 0.5 라는걸 아실 수 있으실 겁니다.

숫자를 바꿔 보시고, 곱셈으로도 바꿔 보시고 … 조금 가지고 놀아 보세요.

더하면 밝아지고 곱하면 어두워집니다.

오늘 내용의 결론입니다.
이미지를 더하면 밝아지고,
곱하면 어두워집니다. (소숫점이거든요. 소숫점은 곱할수록 작아지지요)
여태까지 흑백 이미지만 가지고 노니 재미 없으니까 그냥 추가한 겁니다. :)

그럼 이제 위의 내용을 곰곰히 생각해 보면서, 아래의 다양한 내용을 이해하도록 해 보세요. 직접 해보셔도 좋겠습니다.

이전에 만들었던 것처럼 풀 이미지에 0.5를 더하면, 밝아집니다.

0.5가 아닌 0을 더하면 변화가 없겠지요? 한번 해보세요.

풀 이미지에 1.0을 곱하면? 그대로입니다.
곱하기를 하지 않고 1.0을 더하면 하얗게 날라갔겠지요?

그럼 풀 이미지에 0.5를 곱하면? 어두워집니다.
0 을 곱하면 완전 검은색이 되겠지요?

위 3가지 예제가 모두 이해 되셨습니까?

자, 이렇게 해서 ‘칼라를 숫자로 인식하는 것’ 을 저번 시간에 했고,
이번 시간에는 ‘그렇게 숫자로 인식한 칼라를 덧셈과 곱셈 등 수식으로 연산해 보는 것’ 을 해봤습니다.

다음 시간에는 이제 각종 메터리얼 옵션들을 간단하게 사용해 보도록 하겠습니다. 이미 만져보신 분들도 계시겠지만…

무채색이 될수록 RGB 숫자가 같아지지요. RGB가 완전히 같은건 그야말로 흑백 이미지. 요 개념 자주 쓰입니다. 밑줄 쫙. [본문으로]
흔히들 ‘포토샵의 Scren 이 이 원리로 밝아지는 거다’ 라고 말씀하시는 분들이 계신데 엄밀히 말하면 다릅니다. 포토샵의 Screen 공식은 (1.0 - ((1.0 - base) * (1.0 - blend))) 이고요. 지금 글과 같이 단순히 더하기만 하는 것은 Add 라고 부릅니다. 포토샵의 레이어 속성에는 이게 없고, 에프터 이펙트에는 있지요. [본문으로]
다른 요령도 가르쳐 드리겠습니다. 이미 만들어져 있는 Color 노드를 선택하고, Ctrl+C 를 눌러보세요! 아아 저는 Ctrl+C 가 너무 좋아요!!! 아흥 하악하악 [본문으로]
포토샵의 Screen 블렌딩은 단순한 덧셈이 아니지만, Multiply는 단순한 곱셈이 맞습니다 :) [본문으로]
사실 나눗셈은 일반적인 경우에 계산이 꽤 드리기 때문에, 보통은 0.5를 곱한다고 합니다. [본문으로]
B가 1.0이므로, 사실 결과는 0.5+1.0 이므로 float3(1.5,1.5,1.5) 겠지만, 컴퓨터 그래픽에서 1이 넘는 색상은 그냥 흰색일 뿐이므로 float3(1.0,1.0,1.0)과 차이가 없는 결과물이 나옵니다. [본문으로]

테크니컬 아티스트란?

Mon, 30 Jan 2012 00:46:19 +0000

http://gamedevforever.com/74

네임드 TA이신 핑속님의 글을 퍼왔습니다. :)
너무너무너무 좋은 글인데다가 제 생각하고도 딱 맞아서.
글도 너무 잘쓰십니다.

==========================================================================================================
Posted by 핑속

테크니컬 아티스트(Technical Artist)는 간단히 줄여서 TA라고 합니다. TA라는 명칭은 2009년정도만 해도 국내 게임 업계에서 생소한 명칭이였지만 이제는 업계에서 모르는 사람이 없는 단어가 되었고 TA를 하겠다고 지원하는 신입 개발자도 많아졌습니다.

그런데 TA에 대해 잘못 알고 있는 사람들도 종종 보게 되고 명함에 TA라고 써있으나 제대로 된 역할을 하고 있지 못하는 경우도 있어서 TA를 바라보는 개인적인 생각을 좀 적어보려고 합니다.

하지만 TA에 대해 애정남이 정해준 것도 아니고 브리태니커 백과사전에 써있는 것도 아니므로 저의 개인적인 주관이 반영된 내용입니다. 또한 게임 개발 업계는 가장 다이나믹하게 구조가 변화하는 곳들 중 하나이기 때문에 1년 뒤에는 상황이 달라져 있을 수도 있습니다. 그리고 늘 그렇듯이 직책이나 직급의 명칭은 회사마다 의미가 다르기 때문에 절대적인 것은 아닙니다.

저도 유행 따라 짤방 하나 투척…

TA는 프로그래머인가?

넥슨 컨퍼런스에서 TA에 관한 패널 토크에 패널로 참여를 준비하기 위해서 그래픽 아티스트들이 TA에 대해 어떻게 생각하는지 간단히 조사했던 적이 있었습니다. 당시 조사 자료는 회사 하드 어딘가에 있어서 지금은 기억나지 않지만 가장 인상적이였던 대답은 ‘프로그래머’ 라는 대답이였습니다.

그런데 프로그래머에게 똑같은 질문을 하면 어떤 대답이 나올까요? 아직 설문 조사를 해보진 않았지만 정말 다양한 대답이 나올 것으로 예상됩니다. 하지만 ‘프로그래머다’ 라는 대답은 나오기 힘들 것으로 생각됩니다.

여담이지만 프로그래머들 사이에서도 ‘프로그래머’ 라는 호칭이 붙기 위한 기준이 참 다양하더군요. 경험상 프로그램을 잘 하는 사람일 수록 ‘프로그래머’ 에 대한 기준이 엄격했던 기억이 납니다.

저는 TA가 아티스트라고 생각합니다. 단어에서 이미 답이 나와 있거든요. 테크니컬한 아티스트라는 뜻입니다. (Technical) Artist 라는거죠. 어쨋든 아티스트인데 테크니컬하다는 단어입니다.

비슷한 경우가 또 있는데요, 비주얼 프로그래머라는 역할이 있더군요. 이 사람은 프로그래머입니다. 시각적인 효과에 관련된 프로그래밍을 해서 비주얼 프로그래머라고 부르는 것으로 생각됩니다. 액션 영화에서 무술을 담당하는 무술 연기자는 무술가일까요 연기자일까요? 시작을 무술로 했더도 저는 연기자라고 생각합니다.

그런데 ‘문법상 TA는 아티스트다’ 라는 말을 하려는건 아닙니다. TA가 하는 역할을 자세히 살펴보면 프로그래머는 아니라는 사실을 알 수 있습니다.

TA의 역할 분류

엔지니어링(Engineering) - 뭔가를 만들어내는 작업

쉐이더 개발에 참여
맥스 스크립트 혹은 MEL 스크립트 등을 이용한 툴로 아티스트 생산성 향상
최적화 되고 진보된 캐릭터 리깅을 제공함으로써 애니메이터 생산성 향상
프로그램 팀에 샘플 데이터 신속히 제공

문서화(Documentation) - 뭔가를 알려주는 작업

엔진 분석 및 아티스트용 작업 지침서 제작
아티스트용 개발 규약(Convention) 설정 및 배포
새로운 툴 도입 및 전파 - 예를 들면 CAT이나 모션 빌더 등. 포토샵의 신기능 소개라던가.

조율(Coordination) - 원활한 커뮤니케이션

프로그래머의 작업 대비 시각적인 개선 효과를 아티스트 관점에서 판단하여 작업 우선 순위를 결정할 때 의견 제시
오브젝트 배치 툴 등 인하우스 툴을 개발할 때 가장 적은 비용으로 효과적인 기능을 수행할 수 있도록 의견 제시하고 오버 엔지니어링이 되지 않도록 함
각종 회의 상황에서 프로그래머와 아티스트간 동시 통역

이 중에서 프로그래머라고 볼 수 있는 항목은 쉐이더와 스크립트 툴 정도입니다. 전반적인 TA의 역할은 프로그래머 이외의 것들이 더 많죠.

하지만 쉐이더와 스크립트 역시 프로그래머라고 보기에는 무리가 있다는 생각입니다. 게임에서 쉐이더는 최적화라던가 게임의 그래픽 옵션 연동이라던가 저사양 그래픽카드 지원 등 꽤나 하드코어적인 이슈들이 많아서 프로그래밍만으로 오랫동안 고생해온 사람들에게도 쉽지 않은 일입니다.

스크립트 역시 그래픽 아티스트의 단순 반복 작업을 개선해주는 간단하고 귀여운 것들이라면 상관 없지만 오브젝트를 배치하는 등 게임의 핵심적인 기능을 스크립트 툴로 구현하려고 하는 시도는 좋지 않습니다. 예를 들어 툴을 개발한 스크립터가 퇴사한 뒤에 게임의 핵심적인 기능을 수행하는 툴을 수정하거나 업그레이드 해야할 일이 생기면 곤란해집니다. 아마 대부분의 프로그래머들이 맥스 스크립트 자체를 들여다보는 것을 꺼려할테고 들여다보더라도 조악한 수준의 스파게티 코드를 보면 기겁을 할테니까요. 혹시나 천재적인 스크립터가 아름다운 구조로 툴을 만들었을 수도 있겠지만 그런 사람이라면 맥스 스크립트로 툴을 만들지 않았을거란 생각입니다.

마야의 MEL 스크립트는 그나마 나은듯 하지만 게임 개발 환경에서 핵심적인 기능을 맥스 스크립트에 의존하게 될 경우 치명적인 단점이 또 있습니다. 맥스 자체가 버그 덩어리라는 점입니다. 오브젝트 20개에서 잘 되던 툴이 200개가 되면 메모리 오류가 나면서 맥스가 뻗어버리는 일들이 정말 많거든요. 이런 일이 생기면 오토데스크에 건의해서 맥스를 고쳐달라고 해야할까요?

사실 프로그래머로서 재능이 있는 TA들이 종종 있습니다. 또한 프로그래머 못지 않은 쉐이더 코드를 만들 수 있는 사람들도 있구요. 하지만 예외적인 경우 말고 일반적으로는 TA가 만드는 쉐이더 코드는 프로그래머와 대화하기 위한 도구로 사용하는 것이 가장 바람직하다고 생각합니다.

전부 다 해야 하는건가?

역할 분류를 보면 참 다양한 일을 하는게 TA입니다. 그렇다면 이 모든 것들을 다 해야 할까요? 그렇지 않습니다. 대부분의 경우 현재 팀원의 능력에 맞게 본능적으로 역할을 분배하게 됩니다.

사실 TA라는 명칭이 생기기 전부터 TA의 역할은 누군가에 의해 수행되어 오고 있었습니다. 대부분 경험 많은 그래픽 팀장이나 아트 디랙터에 의해서 작업 효율 향상이라던가 작업 프로세스의 문서화라던가 프로그래머와의 커뮤니케이션이 이루어져 왔습니다.

앞서 적었던 TA의 역할 분류에서 문서화라던가 조율에 관한 부분들은 수 많은 실전 경험 없이는 수행하기 어려운 역할이며 ‘TA가 교육될 수 있는 것인가’ 하는 질문에서 가장 어려운 부분이기도 합니다. 반면에 엔지니어링에 관한 부분은 프로젝트를 수행해본 경험이 별로 없어도 가능하고 교육도 가능합니다.

TA의 성장 트리

요즘 기준에서 TA가 되려면 어떻게 해야하는지를 생각 해보면 두 가지 정도 방법이 있는 것 같습니다.

쉐이더나 스크립트를 배워서 엔지니어로 입사한 뒤 개발 경험을 쌓으면서 점차 문서화 및 조율의 역할로 확장해 나가는 길
기존 아티스트 역할을 하면서 자신이 테크니컬에 관심이 많은 경우 자연스럽게 엔진 분석을 하고 문서화를 하며 프로그래머와 기술적인 조율을 많이 하게 되고 쉐이더나 스크립트에도 관심을 가지게 되면서 자연스럽게 TA로 전직하는 길

그런데 여기서는 프로그래머가 TA로 성장하는 것에 대해서는 배제했죠. 그 이유는 TA가 일단 아티스트이기 때문입니다. 과거에는 프로그래머였지만 현재는 아티스트다 라는 경우가 있을 수 있습니다. 그래도 그 사람은 어쨋든 아티스트입니다. TA를 하려면 아티스트에 대한 이해가 더 우선되어야 한다고 생각합니다. 왜냐하면 어쨋든 아티스트이니까요.

아티스트가 아닌 사람이 TA 역할을 하는 것에 대해서는 개인적으로 부정적인 생각입니다. 아티스트가 가려운 곳을 긁어주진 않고 오버 엔지니어링을 하기 쉽거든요.

팀 내 커뮤니케이션

TA는 이처럼 생각보다 넓은 영역의 역할을 수행할 수 있고 그래야 합니다. 하지만 현실은 그렇지 못한 경우가 많습니다. 간단한 예를 한가지 들어보겠습니다.

어떤 개발 팀에 유명한 원화가로 이름을 날리던 사람이 아트 디랙터 역할을 하고 있습니다. 그런데 이 사람은 기술적인 부분이 취약한데다 요즘 개발팀에 TA는 다들 있는거라고 해서 스크립트와 쉐이더를 작업할 TA를 뽑습니다. 신입 TA는 열심히 시키는 대로 툴을 만들고 게임용 쉐이더를 만들지만 게임의 프레임은 안나오고 아티스트들은 버그 많다고 툴은 안씁니다. 또한 파트장 회의라고 해서 기획팀장과 프로그램 팀장과 아트디랙터와 프로듀서가 참여하는 회의체에서 아트디랙터는 기술적인 부분을 몰라서 비 효율적인 진행이 됩니다. 그래서 앞으로 모든 회의마다 TA를 참여시켜야겠다고 생각하지만 비슷한 취지로 추가되어야 할 인원이 갑자기 너무 많아집니다.

쓰고 보니 간단한 예는 아니군요.

기술적인 기반이 없는 사람은 아트 디랙터로 적합하지 않다고 쓴 예는 아닙니다. 저는 오히려 아트 디랙터라면 기술적인 기반보다 아트의 비젼을 제시할 수 있는 능력이 더 중요하다고 생각합니다.

어떤 사람이라도 아트의 감각과 기술적인 능력을 동시에 충분히 가지기란 쉽지 않습니다. 하지만 게임 개발의 아트 팀에서는 이 두 가지 능력이 동시에 필요하기 때문에 해당 팀원들의 스펙에 맞게 유연하게 역할을 조율해야 하고 대부분 그러고 있습니다.

그렇다면 TA가 굳이 아트 디랙터나 그래픽 팀장이 아니더라도 TA의 전체 역할이 잘 수행되려면 어떻게 해야할까요? 전문적인 TA이면서 모든 역할을 하려면 어떻게 해야할까요?

이 질문에 대한 답은 아직까지 확실히 결론이 나지 않았지만 팀내 개발 커뮤니케이션을 개선해서 해결해야 한다고 생각합니다. 개발에 관한 중요한 결정을 몇몇이 결정하고 나머지 사람들은 그저 시키는 일만 군소리 없이 해야하는 폐쇄적인 커뮤니케이션에서는 TA 뿐만 아니라 다른 모든 역할도 제 기능을 못할 것입니다.

반대로 만들려는 게임의 청사진과 의사 결정의 과정이 투명하게 공유되고 활발하게 의견이 오고가는 팀에서라면 말단 신입 TA라도 충분히 조율할 수 있는 여지가 있으며 TA로서 빠르게 성장할 수 있다고 생각합니다.

결국 TA의 역할이 제대로 되기 위해서는 팀내 커뮤니케이션이 중요하다 라는 말인데요, 팀내 커뮤니케이션이 잘 되면 TA만 행복한건 아니겠죠. ^^

Unity 3.5 신기능 : Gamma correction

Sat, 28 Jan 2012 23:22:32 +0000

Linear Lighting

선형 조명

overview 총론

Linear lighting refers to the process of illuminating a scene with all inputs being linear. Normally textures exist with gamma pre-applied to them this means that when the textures are sampled in a material that they are non linear. If these textures are used in the standard lighting equations it will lead to the result from the equation being incorrect as they expect all input to be linearized before use.
리니어 라이팅(선형 조명) 은 빛 계산 프로세스에서 모든 들어오는 인풋 이미지가 리니어 하다는데 기인합니다. 일반적인 텍스쳐는 감마가 미리 적용되어 있으며, 이것은 텍스쳐가 메터리얼에서 샘플링 될 때 이미 리니어한 상태가 아니라는 (역주: 리니어 영역이 아닌, 감마 영역에 있다는 것) 을 의미합니다. 만약 이 텍스쳐가 표준 조명 방정식에 사용되면 이 결과는 , 모든 이미지는 사용되기 전에 리니어화 되길 기대했던 것으로 기인하여 옳지 않게 됩니다. (역주: 라이팅 계산은 모든 이미지가 리니어 영역에 있을것이라고 생각하고 계산되기 때문에, 감마 영역으로 이미지가 들어오면 옳지 않은 계산이 나오게 된다는 말입니다. 그런데, 지금 모든 이미지는 감마 영역으로 들어오고 있습니다)

Linear lighting refers to the process of ensuring that both inputs and outputs of a shader are in the correct color space, this results in more correct lighting. 리니어 라이팅 기능은 쉐이더에서 인풋과 아웃풋 결과가 올바른 칼라 영역에 있게 해주는 것이고, 이것의 결과로 더 정확한 라이팅을 얻게 됩니다.

Existing (Gamma) Pipeline 현존하는(감마)파이프라인

In the existing rendering pipeline all colors and textures are sampled in gamma space, that is gamma correction is not removed from images or colors before they are used in a shader.
현존하는 렌더링 파이프라인에서는 모든 칼라와 텍스쳐는 감마 영역에서 셈플링 됩니다. 이것은 쉐이더에서 이미지나 칼라가 사용되기 전에 감마 영역이 제거되지 않는다는 것을 의미합니다.
Due to this a situation arises where the inputs to the shader are in gamma space, the lighting equation uses these inputs as if they were in linear space and finally no gamma correction is applied to the final pixel. Much of the time this looks acceptable as the two wrongs go some way to cancelling each other out. But it is not correct.
이것에 기인하여 쉐이더에서 감마 영역의 이미지가 인풋되게 되는 일이 발생하고, 조명 방정식은 이미지를 리니어 영역에 있는 것 처럼 사용하여 최종적으로는 마지막 픽셀에 감마 코렉션이 적용되지 않게 됩니다. 많은 기간동안 이것은 두 가지의 잘못이 서로를 상쇄시켜서 이것이 적합하게 보이도록 했습니다. 그러나 이것은 틀렸습니다.

Linear Lighting Pipeline 선형 조명 파이프라인

If linear lighting is enabled inputs to the shader program are supplied with the gamma correction removed from them. For colors this conversion is applied implicitly if you are in linear space.
만약 선형 조명이 활성화 되면 쉐이더 프로그램에 제공되는 것들이 감마 코렉션이 제거된채 제공됩니다. 당신이 선형 공간에 있다면 색상의 변환은 무조건 이루어집니다.
Textures are sampled using hardware sRGB reads, the source texture is supplied in gamma space and then on sampling in the graphics hardware the result is converted automatically. These inputs are then supplied to the shader and lighting occurs as it normally would. The resultant value is then written to the framebuffer. This value will either be gamma corrected and written to the framebuffer, of left in linear space for later gamma correction; this depends on the current rendering configuration.
텍스쳐는 하드웨어 sRGB로 샘플링되고, 이 소스 텍스쳐는 감마 공간으로 제공되고 그리고 그래픽 하드웨어에서 샘플링되어 자동적으로 변환됩니다. 이들 인풋은 그리고 쉐이더와 라이팅에서는 일반적으로 제공됩니다. 결과 값은 또한 프레임 버퍼에 씌여집니다. 이 감마 코렉션 된 값과 프레임 버퍼에 씌여진 두 값은, 리니어 스페이스에 남습니다 나중의 감마 코렉션을 위해 ; 이것은 렌더링 설정에 달렸습니다.

Differences Between Linear and Gamma Lighting 선형 / 감마 라이팅의 차이

When using linear lighting input values to the lighting equations are different than in gamma space. This means that as lights striking surfaces will have a different response curve to what the existing Unity rendering pipeline has.
리니어 인풋 값을 라이팅 방정식에 쓰면 감마 영역을 쓰는 것과 다릅니다. 이것의 의미는 기존에 존재하는 유니티의 렌더링 파이프라인의 결과 값과는 다른 조명 커브 결과물을 나타낸다는 것을 의미합니다.

Light Falloff 조명 감쇄

The falloff from distance and normal based lighting is changed in two ways.
거리에 따른 감쇄와 노말 베이스의 라이트는 두 가지로 변합니다.
Firstly when rendering in linear mode the additional gamma correct that is performed will make light radius’ appear larger.
첫 번째로 추가적인 감마 코렉션이 적용된채 선형 모드로 렌더링 되면 빛의 영역이 커집니다.
Secondly lighting edges will also be harsher. This more correctly models lighting intensity falloff on surfaces.
두 번째로 빛의 경계가 거칠게 됩니다. 이것은 더 정확한 모델 라이팅 밝기 감쇄가 표면에 이뤄집니다. (주: 뭔소리야)

(주: 아무래도 그림이 서로 바뀐게 아닌가…)

Linear Intensity Response 선형 강도 반응

When you are using gamma space lighting the colors and textures that are supplied to a shader have a gamma correction applied to them. When they are used in a shader the colors of high luminance are actually brighter then they should be for linear lighting.
당신이 감마스페이스 라이팅을 사용할때 쉐이더에 쓰이는 칼라와 텍스쳐는 감마 커랙션이 적용됩니다.
그들이 쉐이더에서 사용될 때 밝은 칼라는 실제로 리니어 영역보다 더 밝아지게 됩니다.

This means that as light intensity increases the surface will get brighter in a non linear way. This leads to lighting that can be too bright in many places, and can also give models and scenes a washed out feel. When you are using linear lighting, as light intensity increases the response from the surface remains linear. This leads to much more realistic surface shading and a much nicer color response in the surface.
이것의 의미는 조명의 표면 밝기 증가는 선형 상태보다 더 밝다는 것입니다. 이것은 많은 경우에서 조명이 너무 밝게 나타나게 합니다. 그리고 모델과 신이 하얗게 타게 만듭니다. 당신이 선형 라이팅을 쓰게 되었을 때에는, 밝기 강도가 표면에 있는 선형에 반으앟여 올라갑니다. 이것은 보다 실감나는 표면 쉐이딩과 보다 괜찮은 표면 칼라 반응을 주도합니다.

Infinite, 3D Head Scan by Lee Perry-Smith is licensed under a Creative Commons Attribution 3.0 Unported License. Available from: http://www.ir-ltd.net/infinite-3d-head-scan-released

Linear and Gamma Blending 선형과 감마 블렌딩

When performing blending into the framebuffer the blending occurs in the color space or the framebuffer. When using gamma rendering this means that non linear colors get blended together. This is incorrect. When using linear space rendering blending occurs in linear space, this is correct and leads to expected results.
프레임 버퍼에서 칼라 블렌딩이 일어날 때는 프레임 버퍼의 칼라 영역 안에서 일어납니다. 감마 렌더링이 사용되었을 때에는 이것은 블렌딩이 서로 선형 공간에서 일어나지 않는다는 것을 의미합니다. 이것은 옳지 않습니다. 만약 선형 공간 렌더링 블렌딩이 선형 공간에서 일어났을때, 이것은 옳으며 기대한 결과가 나올 것입니다.

Using Linear Lighting 선형 조명 사용하기

Linear lighting results in a different look to the rendered scene. If you author a project for linear lighting it will most likely not look correct if you change to gamma lighting. Because of this if you move to linear lighting from gamma lighting it may take some time to update the project so that it looks as good as before the switch. That being said enabling linear lighting in Unity is quite simple. The feature is implemented on a per project level and is exposed in the Player Settings which can be located at Edit -> Project Settings -> Player -> Other Settings
선형 조명 결과는 렌더된 신에서 다르게 보입니다. 만약 당신이 프로젝트를 선형 라이팅에서 만들었다면 그것은 만약 당신이 감마 라이팅으로 바꾸면 씬이 옳지 않게 보일 것입니다. 때문에 만일 당신이 감마 조명에서 선형 조명으로 이동했다면 업데이트하는데 시간이 좀 걸릴 것이고 고치기 전보다 나아 보일 것입니다. 이것은 유니티에서 선형 조명으로 만드는게 무척 간단하다는 것을 의미합니다. 이 기능은 매 프로젝트 레벨에 장착되어 있고 플레이어 셋팅에 노출되어 있습니다. 이것은 Edit -> Project Settings -> Player -> Other Settings 에 위치하고 있습니다.

Lightmapping 라이트맵핑

When you are using linear lighting all lighting and textures are linearized, this means that the values that are passed to the lightmapper also need to be modified. When you switch between linear lighting and gamma lighting or back you will need to rebake lightmaps. The Unity lightmapping interface will warn you when the lightmaps are in the incorrect color space.
당신이 선형 조명을 사용할 때 모든 라이팅과 텍스쳐는 선형되어집니다. 이 의미는 라이트맵퍼를 지나가는 값들도 모두 수정될 필요가 있다는 말입니다. 당신이 선형 조명과 감마 조명사이를 스위치하거나 다시 돌아갈 때 당신은 라이트맵을 다시 구워야 할 필요가 있습니다. 유니티 라이트맵 인터페이스는 라이트맵이 올바르지 않은 조명 영역일 때 경고를 할 것입니다.

Supported Platforms 지원 플렛품

Linear rendering is not supported on all platforms. The build targets that currently support the feature are:
선형 렌더링은 모든 플렛폼에서 지원하지는 않습니다. 현재 기능을 지원하는 빌드 타겟은 :

Standalone PC player* Standalone Mac player* OSX Webplayer* PC Webplayer

Even though these targets support linear lighting, it is not guaranteed that the graphics hardware on the device will be able to render the scene properly.
비록 이 타겟들이 선형 라이팅을 지원하더라도, 그래픽 하드웨어 디바이스들이 이 기능을 적당하기 지원할지는 보장되지 않습니다.
You can check the desired color space and the active supported color space by looking at PlayerSettings.desiredColorSpace and PlayerSettings.activeSupportedColorSpace if the desired color space is linear but the active color space is gamma then the player has fallen back to gamma space.
당신은 원하는 칼라 스페이스와 실행되는 칼라 스페이스를 PlayerSettings.desiredColorSpace 와 PlayerSettings.activeSupportedColorSpace 에서 체크할 수 있습니다. 만약 원하는 칼라 스페이스가 선형인데, 실행되고 있는 칼라 스페이스는 감마라면 플레이어가 감마 스페이스로 떨어져 버린것입니다.
This can be used to show a warning box telling the user that the application will not look correct for them or to force an exit from the player. 이것은 유저에게 이 이미지가 제대로 보이지 않는다고 경고하거나 플레이어에서 나가게 할 때 사용될 수 있습니다.

Linear and Non HDR 선형과 non HDR (주: Non - High Dynamic Range)

When not using HDR a special framebuffer type is used that supports sRGB read and sRGB write (Degamma on read, Gamma on write).
HDR이 사용되지 않을때 스페셜한 프레임버퍼 타입이 sRGB 읽기와 쓰기에 사용됩니다. (감마없앰으로 읽고, 감마 있음으로 쓴다)
This means that just like a texture the values in the framebuffer are gamma corrected. When this framebuffer is used for blending or bound as texture the values have the gamma removed before being used.
이 의미는 프레임버퍼 안의 텍스쳐의 값이 올바르다는 것을 의미한다. 이 프레임 버퍼가 블렌딩이나 텍스쳐 바운드에 사용되면 감마 값은 사용되기 전에 제거된다.
When these buffers are written to the value that is being written is converted from linear space to gamma space. If you are rendering in linear mode, all post process effects will have their source and target buffers created with sRGB read and write enabled so that post process and post process blending occurs in linear space.
이런 버퍼들이 값에 씌여질 때는 선형에서 감마 영역으로 컨버팅됩니다. 만일 당신이 선형 모드에서 렌더링하면, 모든 후처리 이펙트는 그들의 소스와 타겟 버퍼를 sRGB로 읽기와 쓰기가 가능하게 만들고 그래서 이 후처리 효과들은 선형 공간 안에서 블렌딩되게 됩니다.

Linear and HDR 선형과 HDR

When using HDR, rendering is performed into floating point buffers. These buffers have enough resolution to not require conversion to an from gamma space whenever the buffer is accessed, this means that when rendering in linear mode the render targets you use will store the colors in linear space.
HDR이 사용되면, 렌더링은 플로팅 포인트 버퍼들로 행해집니다. 이 버퍼들은 충분한 해상도를 가지고 있어서 감마 공간에서 어떤 버퍼가 접근하던지 간에 컨버팅이 필요하지 않습니다. 이 의미는 선형 모드에서 렌더링 되는 당신의 렌더 타겟은 선형 공간 안에 저장이 된다는 것을 의미합니다.
This means that all blending and post process effects will implicitly be performed in linear space. When the the backbuffer is written to, gamma correction is applied.
이 의미는 모든 블렌딩과 후처리 효과들은 무조건 선형 공간에서 이루어 진다는 것을 의미합니다. 백버퍼가 씌여질 때, 감마 코렉션은 적용됩니다. (주: HDR로 사용되면 라이팅 영역이 넓어서 변환 자체가 필요 없이 그냥 쓸 수 있다는 뜻입니다)

GUI and Linear Authored Textures 인터페이스와 선형으로 제작된 텍스쳐들

When rendering Unity GUI we do not perform the rendering in linear space. This means that GUI textures should not have their gamma removed on read. This can be achieved in two ways.
유니티 GUI가 렌더링 될 때 우리는 선형 공간으로 작업을 하지 않습니다. 이 의미는 인터페이스 텍스쳐는 읽을때 감마가 제거되지 않는다는 것을 의미합니다. 이것은 두 가지 방법을 도달할 수 있습니다.

Set the texture type to GUI in the texture importer
텍스쳐 타입을 임포트 할때 GUI로 지정하시오* Check the ‘Sample in Linear Space’ checkbox int the texture importer
임포터에서 ‘Sample in Linear Space’ 체크박스를 체크하시오

This will force the sampled texture to not have gamma removed before being used by the graphics hardware. This is also useful for other texture types such as masks where you wish the value that is passed to the shader to be the exact same value that is in the authored texture.
이것은 샘플링된 텍스쳐가 그래픽 하드웨어에서 사용되기전에 감마가 제거되지 않도록 해줍니다. 이것은 또한 마스킹 같은 다른 타입의 유용한 텍스쳐들 - 여러분이 만든 값이 정확하게 쉐이더에 전달되기를 바라고 제작한 텍스쳐 - 등에 유용할 것입니다.

Page last updated: 2011-12-01

Unity 3.5 신기술 : Level of Detail

Fri, 27 Jan 2012 23:30:49 +0000

Level of Detail 레벨 오브 디테일

As your scenes get larger, performance becomes a bigger consideration. One of the ways to manage this is to have meshes with different levels of detail depending on how far the camera is from the object. This is called Level of Detail (abbreviated as LOD)
당신의 신이 커지면, 퍼포먼스는 중요한 고려사항이 됩니다. 이것을 컨트롤 하는 방법 중 하나는 카메라에서 얼마나 멀리 있느냐에 따라서 오브젝트 메쉬의 디테일 레벨을 변화 시키는 것입니다. 이것을 레벨 오브 디테일 (줄여서 LOD) 라고 합니다.

Here’s one of the ways to set up an object with different LODs.
여기에 오브젝트에 다른 LOD를 셋업하는 방법중 하나가 있습니다.

Create an empty Game Object in the scene
신에 빈 게임 오브젝트를 만듭니다.- Create 2 versions of the mesh, a high-res mesh (for L0D:0, when camera is the closest), and a low-res mesh (for L0D:1, when camera is further away)
2개 버전의 메쉬를 만듭니다. 하이폴 메쉬 (LOD:0, 카메라 근접용) 그리고 로우폴 메쉬 (LOD:1) 카메라 원거리용- Add a LODGroup component to this object (Component->Rendering->LOD Group)
LODGroup 컴포넌트를 이 오브젝트에 추가합니다. (Component->Rendering->LOD Group)- Right click the rectangle with the word CULLED on it, and select Insert Before. This should create L0D:0
CULLED 라고 써진 사각형을 오른쪽 클릭하고 , insert before 를 선택합니다. 이러면 LOD:0 가 만들어 질겁니다.- Right click the remainder of the CULLED rectangle, and select Insert Before again. This should create L0D:1
아직 남아있는 CULLED 사각형을 오른클릭하고, InsertBefore를 또 합니다. 이것은 LOD:1 이 됩니다. - Drag in the object with the high-res mesh onto the first Renderers box for L0D:0. Say yes to the “Reparent game objects?” dialog
하이폴 메쉬를 드래그해서 LOD:0에 있는 첫번째 렌더러 박스에 넣습니다. “Reparent game objects?” 다이얼로그가 나오면 yes 를 선택합니다.- Drag in the object with the low-res mesh onto the first Renderers box for LOD:1. Say yes to the “Reparent game objects?” dialog
로우폴 메쉬를 드래그해서 LOD:1에 있는 첫번째 렌더러 박스에 넣습니다. “Reparent game objects?” 다이얼로그가 나오면 yes 를 선택합니다.

At this point the empty object should contain both versions of the mesh, and “know” which mesh to show depending on how far away the camera is.
이 시점에 빈 오브젝트는 두 개 버전의 메쉬를 가지게 됩니다. 그리고 어떤 메쉬가 카메라가 얼마나 멀리 있는지에 영향을 받으며 보여지게 될지 ‘알게’ 됩니다.

You can preview the effect of this, by dragging the camera icon left and right in the window for the LODGroup component. 당신은 저기 LODGroup 컴포넌트에 있는 카메라 아이콘을 드래그해서 이 효과를 미리보기 할 수 있습니다.

camera at LOD 0

camera at LOD 1

In the Scene View, you should be able to see
신 뷰에서, 당신은 이런 것을 볼 수 있습니다.

Percentage of the view this object occupies
이 오브젝트가 점유한 뷰 퍼센트* What L0D is currently being displayed
지금 어떤 LOD가 보여지는가* The number of triangles
삼각형의 수

LOD-based naming conventions LOD 기반 이름 규약

In order to simplify setup of LODs, Unity has a naming convention for resources at different resolutions.
LOD 셋업을 간편하게 하기 위해서, 유니티는 각 해상도별로 리소스의 이름 규약을 가지고 있습니다.

Simply create your meshes with names ending with _LOD0, _LOD1, _LOD2, etc., and the LOD group with appropriate settings will be created for you.
간단히 당신의 메쉬 이름 끝에 _LOD0, _LOD1, _LOD2, 등을 붙이십시오. 그리고 적합한 셋팅의 LOD 그룹이 당신을 위해 생성될 것입니다.

Note that the convention assumes that the meshes with the highest resolution have the lowest LOD number.
이 규약은 가장 낮은 번호의 LOD가 가장 높은 해상도의 메쉬를 가지고 있다고 가정하는 것을 주의하십시오.

Page last updated: 2011-11-11

ShaderFX를 이용한, 그래픽 디자이너를 위한 기초 쉐이더 강좌 3강

Fri, 20 Jan 2012 14:43:57 +0000

http://gamedevforever.com/category/아트

여기에 연재되는 글입니다. 이글루스에는 며칠 늦게 올립니당

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

안녕하십니까 남들은 조낸 멋진거 막막 쓰고 인기높고 막 그러는데
저만 괜히 정말 아무것도 모르는 초보를 위한다고 너무 수준낮게 쓰느라
팀블로그 그래픽 반의 질을 떨어뜨리는건 아닐까 하고 걱정하고 있는 대마왕J 입니다.

나… 나도 쓸꺼야! 실버치매님처럼 멋진 글을!!!!

근데 생각해 보니까 하지만 난 어차피 수준이 초딩이잖아?
컨트롤 C+V 밖에 못하는

그러니 닥치고 저는 이 사이트의 낮은 레벨을 담당하는 것이 낫습니다.

시작합니다. 이히히 ~

텍스쳐를 넣어 봅시다.

자 드디어 텍스쳐를 넣을 시간입니다! 텍스쳐를 넣는 것도 지극히 간단하지요.
아까 만든 것처럼 빈 화면에서 오른쪽 클릭을 해서 Maps로 간 다음,
이번엔 Color가 아니라 TextureMap을 선택합니다.

텍스쳐를 넣어야 하니까, 당연한 선택이겠지요?

자, 이렇게 TextureMap이 생겨났습니다.
아직 아무 그림도 없지요.

역시 이 것을 선택하면, 오른쪽에 인터페이스가 좌아악 펼쳐집니다…
이 옵션들은 사실 굉장히 기능이 많습니다. 각종 시멘틱(Semantic) 설정에, 텍스쳐 UV 채널, 샘플러 셋팅, 밉맵의 개수, 심지어 감마 코렉션(Gamma correction) 을 위한 기능까지 들어 있습니다.
간편하게 다루는 툴인데 비해, 상당히 많은 기능이 들어 있지요.

뭐 그치만 그딴건 아직 안봅니다. 신경쓰지 마세요

어쨌건 텍스쳐를 하나 넣어 봅시다.
아래 그림처럼, UI Name 아래 있는 버튼을 눌러 볼까요.

저는D_grass.dds 라고 하는 풀 그림이 그려진 그림을 선택했습니다. [각주:1]
드디어 그림이 보이는 군요.

자, 이제 이 TextureMap을 왼쪽의 셰이더 루트의 Ambient Color에 연결해 주면 될텐데…
아까 칼라를 연결할 때에는 하나밖에 없었는데, 이젠 다양한 색깔로 여러 종류가 있습니다. 분홍색의 RGBA , 녹색의 RGB, 그리고 파랑색의 R,G,B,A …

일단 결과를 보는게 급하지요! 답을 알려 드리겠습니다. 여기서는 색이 중요합니다!RGB라고 씌인 녹색 공과 Ambient color를 연결해 주세요! [각주:2]

그리고 이 쉐이더를 주전자와 연결시켜 주시면, [각주:3] 드디어 주전자에 텍스쳐가 입혀집니다!!!

축하드립니다. 드디어 텍스쳐를 연결하셨습니다. 이제 이곳 저곳에 연결해 보시고 끊어보시기도 하면서 가지고 놀아보세요. 잘 작동하는 것도 있고 잘 작동하지 않는 것도 있을 겁니다.

그리고 특히, 아래 그림의 이 부분을 제일 주목해 주세요.[각주:4]
아래 그림의 붉은 박스 영역과 같이
RGBA 들이 같이 있기도 하고 , 떨어져 있기도 한 이 부분 말입니다.

우선 생각하기에 RGB 값이 연결되는 것은 당연하게 보이긴 합니다. 이미지는 보통 RGB로 구성되니까요.
하지만 알파가 포함된 RGBA , 그리고 r,g,b,a 가 각각 떨어져 있는 것도 있습니다.
이것을 어떻게 사용해야 할까요?

이걸 알기 위해서는 색상의 각 요소가 프로그램에서 어떻게 사용되는지를 알 필요가 있습니다.

Float 의 비밀

이전에 빨강 공을 만들때, float3라는 말을 언급했었지요?

자… 이게 무슨 소리인지 이제 알아볼 시간입니다. :)
원래대로 풀버전으로 설명하면 칼라의 bit 부터 시작해서 너무 길어지므로 최대한 축약해 보도록 하겠습니다.
풀버전 설명은 다음기회에 따로 준비하도록 하지요. 오늘은 간략하게 간락하게 쉽게 쉽게 …

우선, 컴퓨터 그래픽에서의 ‘색’ 에 대해서 생각해 보도록 하지요.
학교 수업시간에 배운바에 의하면, TV나 모니터의 빛은 ‘가산혼합법’ 이라고 해서, 다 더하면 하얗게 되는 색이라고 합니다.

이런 그림 기억나시죠? 빨강색 , 녹색, 파랑색이 있고, 이 세 가지의 색을 모두 더한 색은 흰색이고, 세 가지의 색이 전혀 없는 색은 검은 색이다 … 라는 거 말이죠.

이거와는 반대로, 잉크로 인쇄하는건 달라서, 섞으면 섞을수록 어두워지고… 다 더해도 진짜 검은색이 사실 안나오기 때문에 검은색을 따로 추가하고 어쩌고 해서 CMYK[각주:5]다 … 라는거 말이죠.

네, 그렇지만 우리들의 모니터는 가산혼합법으로 이루어지는 녀석이라, 3가지의 색 (Red,Green,Blue) 이 모여서 더해지는 색 구조를 따르고 있습니다. 그리고 색을 모두 더하면 흰색이 되구요.

만일 빨강색이 있다면, 우리 그래픽 디자이너들이 익숙한 포토샵에서는 이렇게 보이겠지요?

빨강색을 선택했더니, (R,G,B) 가 (255,0,0) 이라고 합니다.
이건 그래픽 디자이너분들한테는 매우 익숙한 광경이지요.
그렇다면 흰색은 무엇이겠습니까?
흰 색은 RGB가 모두 최고 밝은 상태이므로 (255,255,255) 겠지요?

그렇다면 검은색은 ?
검은색은 RGB에 아무런 값도 없는 상태를 의미하니 (0,0,0) 일겁니다.

자, 그럼 회색일때 RGB 값은 어떤 값일까요?

… 네 그렇습니다. (128,128,128) 입니다. [각주:6]

이렇게, 우리는 일반적으로 0255 까지의 수를 가지는 세 가지의 색(RGB) 의 조합으로 모든 색을 표현하고 있습니다.
이 때, R, G, B 라고 불리우는 각 색의 값을 ‘채널’ 이라고 부릅니다. 즉 색을 만들기 위해서는 3개의 채널이 필요하고, 우리가 일반적으로 사용하는 채널당 8비트 이미지는 [각주:7] 0255 까지의 값을 가진 R,G,B 채널들의 조합으로 만들어 진다는 것이지요.

자, 다시 한 번 정리해 봅시다. 채널당 8비트인 이미지에서 RGB 값은,

R G B
빨강색은 ———— (255, 0, 0)
흰색은 ————– (255, 255, 255)
검은색은 ———— (0, 0, 0)
회색은 ————– (128, 128, 128)

이란 말입니다. 이해가시겠지요?

근데 프로그래밍에서는 이런 숫자를 쓰지 않습니다. 그 이유에 대해서 제대로 쓰면 또 양이 많아지기 때문에, 간단히 말해서 ‘컴퓨터가 원래 그렇게 돌아가기 때문임’ 이라고 우기도록 하겠습니다

이힝힝. 모, 몰라서 그러는 거 아니라능!! 믿어달라능!!!

프로그래밍에서는 그럼 색을 어떻게 쓸까요?
바로 포프 스승님 강의를 읽어보셨으면 알만한 내용인, “% 로 표시합니다"라는 겁니다.
즉

R G B
빨강색은 ———— (100%, 0%, 0%)
흰색은 ————– (100%, 100%, 100%)
검은색은 ———— (0%, 0%, 0%)
회색은 ————– (50%, 50%, 50%)

라는 거지요.
그리고 다시 이것을 소숫점으로 나타내면 Float(부동소수점)[각주:8] 이 되는데요.
그럼 이렇게 나타나게 됩니다.

R G B
빨강색은 ———— (1, 0, 0)
흰색은 ————– (1, 1, 1)
검은색은 ———— (0, 0, 0)
회색은 ————– (0.5, 0.5, 0.5)

즉, float 이란 부동소수점으로 표시한 채널을 의미하며, 이것이 RGB 일 경우에는 소수점 3개가 필요하니 float3 라고 표시하는 겁니다. 최종적으로는 이렇게 표시되겠지요.

R G B
빨강색은 ———— float3 (1.0, 0.0, 0.0)
흰색은 ————– float3 (1.0, 1.0, 1.0)
검은색은 ———— float3 (0.0, 0.0, 0.0)
회색은 ————– float3 (0.5, 0.5, 0.5)

그러므로 이 그림에서 float3란, ‘3개의 소수점으로 이루어진 값’ 이라는 의미가 되는 겁니다.
그러면 아래 그림에서 Ambient Color로 넘어가는 값은 float3(1.0, 0.0, 0.0) 이라는게 이해 되시겠지요?

여기서 또 하나 재미있는 것은, float3의 값을 받는 Ambient color 도 녹색 박스라는 겁니다. 다시 말해서 float3만을 받을 수 있다는 말이지요. color 니까 당연하겠지요.

Float을 그림으로 보자

float3 는 float + float + float 3개가 모여서 만들어 졌다는걸 아시겠지요?

그럼 이 이미지가 슬슬 이해 되실 겁니다.
RGBA 란? A 란 ‘알파 채널’ 을 의미하지요. 투명도를 나타내는 바로 그 값이 포함된것 말이지요.
투명도 역시 0~255 라는 단계를 가질 수 있습니다. 즉 RGB에다가 A 가 추가로 포함되어서, 투명도가 포함된 이미지를 의미한다는 말이지요. 그러므로 이건 float으로 나타내면? float+float+float+float 4개가 모여 4자리니까 float4 라고 말할 수 있겠지요? 아래처럼 말이지요.

R G B A
빨강색인데 불투명 ———— float4 (1.0, 0.0, 0.0, 1.0)
빨강색인데 완전투명 ———- float4 (1.0, 0.0, 0.0, 0.0)
빨강색인데 절반정도 투명 —- - float4 (1.0, 0.0, 0.0, 0.5)

그렇다면 각각 떨어져 있는 R, G, B, A 의 단위는 무엇일까요?

…. 네 그렇습니다. 그냥 float이지요. 한 자리 소숫점 숫자일테니까요.
이런 식이란 말입니다.

빨강색인데 R채널 ———— float (1.0)
빨강색인데 G채널 ———— float (0.0)
빨강색인데 B채널 ———— float (0.0)

이 부분이 가장 중요하면서 초반에 그래픽 디자이너분들이 가장 많이 포기하는 부분이므로 좀 더 자세하게 써 보겠습니다.

자, 익숙해 보이는 포토샵 화면입니다. 풀 그림이 있고요, 채널 탭이 보입니다.
알파 채널이 있다는 것도 보이시지요? 그리고 지금 ‘눈’ 마크가 RGB가 켜 있어서, RGB채널이 모두 보이고 있는 상태라는 것도 알 수 있습니다.

자 이제 채널을 하나 하나 따로 따로 보겠습니다.

Red 채널입니다. Red 채널만 활성화 시키자, 그림이 흑백으로 변했습니다.
이미지를 잘 보시죠. 무슨 의미일까요?
이 이미지의 한 픽셀 한 픽셀은, float 값들을 의미합니다. Red 값의 강도만 0.0~1.0 사이로 나타내면 되기 때문에, 흑백으로 충분한 것입니다.

즉 흰색 점들은 float (1.0) 을 의미하고, 회색인 점들은 float(0.5)를 의미합니다. 검은색 점은? 당연히 float(0.0) 을 의미하겠지요. 각 점은 밝기에 따라, 다양한 한 자리의 소수점 값을 가지고 있습니다.

이번엔 녹색 채널입니다. 아까보다 밝아 보이죠? 당연합니다. 그림 전체가 녹색에 가깝기 때문에 녹색 값이 높은 겁니다. 그래서 녹색 채널만 보면 밝아 보이는 거구요

Blue 채널을 보니 좀 어둡습니다. 즉 이 이미지에는 파랑색이 별로 들어가 있지 않다는 얘기겠지요.

알파를 보겠습니다. 역시 다른 채널과 마찬가지로, 흑백으로 되어 있습니다.
또한 다른 채널과 완전히 마찬가지로, 0인 부분 (투명한 부분) 은 완전한 검은색으로 되어 있고, 1인 부분 (불투명한 부분) 은 흰색으로 되어 있으며, 0.5 (반만 투명한 부분) 은 흰색으로 되어 있습니다.

이렇게 4개의 채널을 봤습니다.

…무언가 발견하신 것이 있는지?
사실, R,G,B,A 내 개의 채널은 아무런 차이가 없습니다! 모두 똑같은 ‘float1’ 구조를 가지고 있습니다!
모두 각 픽셀당 소수점 하나만을 가지는 숫자로 되어 있을 뿐입니다. 즉 언제건 Red와 Green을 바꿔도 상관없고 , Blue와 Alpha를 바꿔도 문제없이 정상 동작합니다. 단지 이미지의 색이 달라질 뿐이겠지요.

그래서 아래와 같이 , R,G,B,A가 각각 따로 동일하게 취급을 받을 수 있는 것입니다.
이것이 가장 중요한, 채널과 float에 대한 간략한 개념입니다. (말씀 드렸다시피, 풀버전은 나중에…)

Opacity를 만들자.

프로그래머들은 Opacity라고 하면 잘 못알아 듣습니다. Alpha나 Transparant 라고 하면 잘 알아 들어도…
어쨌건 여기까지 잘 하신 상태란 말입니다.

이제 Opacity에 값을 추가할 차례입니다.
잘 보세요. Opacity는 파란 색 값을 원하고 있습니다.

파란 색 값이란? float 값을 의미합니다. 한 자리의 숫자요. 위에서 말한.
하긴 투명도 결정하는데 RGB 세 채널은 필요없겠죠. 한 자리면 됩니다. 투명한 것은 ‘얼마나 투명하냐 ’ 라는 한 자리의 수만 있으면 되니까요.

흔히 그래픽만 하시던 분들이 쉐이더를 공부할때 이 부분에서 혼동을 많이 하시는데, 3Dmax의 Opacity는 “흑백으로 된 RGB” 이미지를 따로 만들어서 Opacity에 넣지요. 이것은 그거랑 다릅니다. 그정도로 필요 없습니다.
사실 Opacity를 표현하기 위해서는 ‘채널 하나’ 만으로도 충분하고, 그래서 알파 채널 하나만 있으면 투명도를 결정하는데 충분하게 사용할 수 있다는 말입니다.

자, 알파 채널 (A) 를 클릭해서 끌어내 봅니다. float 이 나오는 것을 알 수 있습니다!!

즉 지금 이 그림이 나오고 있는 것이지요?

이것을 Opacity 에다가 끌어 놓으면 되는 것입니다.

주의할 점은, float은 반드시 float에 넣어야 하고, float3는 반드시 float3에 넣어줘야 한다는 겁니다.
Opacity는 파란색 (float) 만을 받는 값이기 때문에, 반드시 float을 넣어줘야지,
여기다가 녹색 (RGB)데이터를 넣어봐야 들어가지도 않습니다.

자! 결과물이 드디어 나왔습니다. 원하던 모양이 나왔네요.[각주:9] 이것이 채널을 사용하는 법입니다.
RGB 채널은 Ambient Color에 연결했고, A 채널은 Opacity에 연결했습니다.

이번 강의는 여기서 끝입니다 . 잘 하셨어요.
그런데 퀴즈가 하나 있어요… 이해하셨나 테스트!

만약 Opacity에 A 채널을 넣지 않고, B나 G, R 채널을 끌어다 놓아도 될까요?

정답은

됩니다!!! B 채널을 Opacity로 끌어다 놓았습니다.
Alpha 채널과 똑같은 float 이기 때문에 당연히 됩니다. 그것만 맞으면 뭐든지 들어간다니깐요.
지금 현재 B채널은 Ambient Color에서도 쓰이고 있고, Opacity 에도 쓰이고 있군요.

대신 투명도가…

이 이미지의 강도에 맞게 결정되었다는건 이해하시겠지요? 자, 놀랍지요? 이것이 기존에 그래픽 디자이너들이 잘 모르던, 채널의 속사정입니다. 가장 중요하면서, 가장 기초가 되는 바로 그 부분이지요.

각각의 채널은 동등한 구조의 float으로 구성되어 있고, 이게 단지 순서에 따라 Red냐 Green이냐 Blue냐 Alpha 이냐를 결정하고 있으며, 이걸 서로 섞어도 일단 서로 호환은 된다는 말입니다.

이걸 잘 이해하셨다면, 이제 오늘 강의는 진짜로 끝입니다. 다음부터 재미있어 지겠군요.

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

다음 시간에는, 쉐이더를 가지고 놀아보는 시간입니다. 산수야 놀자! 입니다.
모든 색의 채널이 0.0~1.0 사이의 숫자라는 것을 알았으니, 이것을 더하고 곱하고 가지고 놀아봅시다.
시간이 된다면, 조금 더 이미지를 조합해 봅시다. 재미있을겁니다.

이 텍스쳐 파일은 ShaderFX를 설치하면 자동으로 깔리는 텍스쳐 중 하나입니다. 저는 C:Program FilesAutodesk3ds Max 2009maps 안에 있네요. [본문으로]- Ambient Color에만 연결하는게 지겨우신 분들은 Diffuse Color나 Self-illumination에도 연결해 보세요. 재미있는 변화가 일어날 겁니다. [본문으로]- 쉐이더와 주전자를 동시에 선택한 채, Tools / Assign Material to selection을 해주면 됩니다. [본문으로]- 어떻게 Texture Map 오브젝트가 저렇게 크게 보이게 할 수 있느냐고요? 마우스 휠을 굴려보세요. 확대, 축소가 됩니다. 마우스 가운데 버튼을 누른채 이동하면 패닝이 되구요. [본문으로]- Cyan, Magenta, Yellow, Black 을 의미합니다. [본문으로]- 사실, 모니터의 출력특성에 따른 색상보정으로 감마 코렉션(Gamma correction) 이라는게 적용되어서, 진짜 회색은 128,128,128 이 아닙니다만 여기서는 그 얘기를 무시하고 넘어가겠습니다. 분명 실버치매님이 써주실 거다에 한표. ㅋㅋㅋ [본문으로]- 채널당 8비트는 R,G,B 채널들이 각각 2의 8승 = 256 단계 로 이루어져 있다는 말입니다. 물론 채널당 다른 비트도 존재합니다. [본문으로]- 소수점이 있는 수를 표현할때 사용하는 방식이라고 생각하시면 편합니다. 물론 어느 정도 한계치가 있어서, 너무 큰 수나 너무 작은 수는 표현 불가능하지만 일반적인 셰이더 작업을 위해서는 충분하고 남습니다. [본문으로]- 참고로, 맥스 2012에서는 잘 나오지 않습니다. 현재 사용하고 있는 맥스는 2009 버전이며, 2010 버전에서도 잘 나오던걸로 기억합니다.. [본문으로]

삼국지를 품다 서포터즈 테스트 시작

Thu, 12 Jan 2012 23:35:28 +0000

삼국지를 품다 서포터즈 모집

삼국지를 품다 서포터즈 시작

… 모집 끝나고 뒷북치는 게시물이라니..
하여간 벌써 시작했습니다.

시작한 기념으로, 삼국지를 품다 게시판의 일부 비밀글을 오픈하였습니다!

http://3p.nexon.com/event/main

그래픽 디자이너를 위한 기초 쉐이더 강좌2

Tue, 03 Jan 2012 00:07:45 +0000

http://www.gamedevforever.com/32
에서 연재하는 글입니당 :)

시작합니다.

저번 시간에는 프롤로그에 가까웠지요. 이번부터가 진짜 강의입니다. shaderFX는 다 설치 하셨는지요?
이번 시간에는 shaderFX의 기본 사용법과 기초 이론을 알아보도록 하지요.
또한 shaderFX 를 이용해서 할 수 있는 일도 간단하게 소개해 드릴께요.

ShaderFX 기본 사용법

2-1 실행해 봅시다.

이제 ShaderFX가 설치되었으면 우선 실행을 해야 합니다. Render/ShaderFX를 실행해 봅시다.

이런 창이 열릴 겁니다. 왠 도마뱀이 꼬리를 치고 있네요.
등록되었다지 않았다는 말이 나오고 있긴 하지만, 어차피 무료입니다. 사용하는데는 아무런 문제가 없습니다.

이게 shader FX 라고 하는 프로그램이고, 그냥 ‘또 하나의 메터리얼 에디터’ 라고 생각하셔도 아무런 문제가 없습니다. [각주:1]

2-2 쉐이더를 만들고, 오브젝트에 적용해 봅시다.

자 그럼 뭔가 일단 하나 만들어 보고 시작할까요.
가장 만만한 녀석인, 주전자 하나 만들어 봅시다. 그래픽 디자이너라면 이 정도는 쉽게 하시겠지요?
네? 원화 디자이너라서 못하신다고요? 허허허허허허허허허허허허허허허허허허허허허허허허허허허허허허허허허허
이건 기술 축에도 들지 못하는 간단한 기능입니다. 그냥 클릭 두 번만 하면 되는건데요. [각주:2]

주전자가 만들어졌으니 이제 여기에 메터리얼(shader)을 입혀야 겠지요

shaderFX의 창에서 StandardMat_ 어쩌고라고 씌여진 창을 클릭합니다.
이게 지금부터 만들 shader의 루트(Root) 창 입니다. 가장 기본이 되는 베이스예요.

그리고 주전자도 클릭합니다. 이제 주전자에 이 shader를 적용할 예정이니,
반드시 두 개가 같이 선택이 되어 있어야만 하는 거지요.

자, 이렇게 두 개가 모두 선택이 되었다면, 이번엔 shaderFX의 창에서Tool/Assign Material to Selection 을 누릅니다.

음? 왠 경고가 뜹니다.

경고 내용을 차분하게 읽어보면, ‘당신은 아직 FX 파일이 어디에 생성될 것인지 결정하지 않았으니 임시로 내가 만들어 놓겠소’ 라는 뜻입니다. 뭐, 일단은 큰 상관 없습니다. [확인] 을 눌러서 다음으로 넘어가 보지요.

짜잔.

축하드립니다! 첫 번째 쉐이더를 완성하셨습니다!!! 자 이제 끝!

… 물론 이건 끝이 아닙니다. 이제 시작일 뿐이죠.

2-3 빠알간 주전자를 만들어 봅시다.

프로그래머가 쉐이더를 배울 때, 제일 처음 하는 것이 바로 이 ‘빨간 공’ 만들기 입니다 .
우리는 명색이 그래픽 디자이너이니, 빨간 공으로 만족할 수 없습니다. 빨간 주전자를 만들어 봅시다!!! 간디작살
만들기는 매우 간단합니다.

shaderFX의 화면의 빈 곳에서 오른쪽 클릭을 하면 나오는 메뉴에서, Maps/Color 를 선택하는 것입니다.
Map는 말그대로 맵을 만든다는 것이고, 그 중 “Color Map” 하나를 만든다는 것이지요.

필자의 이름이 그림에 고스란히 노출되었지만, 못 본 척 하고 지나가도록 합시다.

이렇게 하면, 왠 회색 사각형 카드 같은게 하나 나오게 됩니다. 이게 Color Map 오브젝트 입니다.
이름도 Color 네요.
이 Color 오브젝트를 선택하면 오른쪽에 해당되는 인터페이스가 나오므로, 여기서 빨간색으로 바꿔 줘 봅시다.
오른쪽 인터페이스에서 이름도 바꿀 수 있으니까, 원하시면 바꾸시면 되지요.

빨간색 오브젝트가 되었습니다. 공은 아직도 하얀색이지요. 별로 바뀐게 없습니다.

자 이번엔 빨간색 오브젝트 아래에 있는 RGB 라고 씌인 녹색 동그라미를 보십시오.
이걸 마우스 왼쪽 클릭 - 드래그 하면 왠 선이 나오는데 , 이것을 Ambient Color 로 이어줍니다.

선 끝에 float3 라고 씌여 있습니다. 조만간 이걸 설명할테니 관심을 가져 주세요.

그냥 드래그해서 Ambient Color에 놓고 오면 됩니다.
즉 “빨간 맵을 엠비언트라고 하는 요소에 적용” 했습니다.
공이 빨갛게 변했습니다!!! 이런 종북좌파빨갱이!

선을 끊는 방법은, 선을 선택하고Delete 키를 누르기만 하면 됩니다.
다시 이어주는 것은 언제건 상관없이 할 수 있습니다.

색을 바꾸는 것은 다시 color 오브젝트를 선택하고 , 다른 색으로 바꿔주면 됩니다.
그런데 되지 않습니다. 응?

놀랄 필요 없습니다. 이렇게 칼라를 바꾸는 경우에는 F5나 Color옆의 ‘Set’버튼을 눌러주기만 하면 적용됩니다.

주의사항 : shader FX로 만들고 적용한 재질은 렌더링되지 않습니다!!!! 보통 그래픽 디자이너들이 말하는 렌더링은 , Render 버튼을 눌러서 파일로 렌더링 하는 오프라인 렌더링 (Offline Rendering)을 의미합니다만, 그것은 불가능합니다.

여기서 만들고 있는 Shader는 뷰포트에서만 보이는 리얼타임 렌더링(Realtime Rendering) 전용이기 때문에 뷰포트에서 보이는 것이 곧 결과물이므로, 이 결과물을 그래픽 파일로 만들고 싶으시면 화면을 캡쳐(PrintScreen) 하는 수 밖에 없습니다.

2-3 저장하기
일단 첫 쉐이더를 완성하셨음을 축하드립니다. 프로그래머들도 이런 식으로 첫 번째 쉐이더를 만들거든요. [각주:3]
어쨌거나 이제 이 쉐이더를 저장하는 법을 알려 드리겠습니다.

shaderFX 에서 저장하는 법은 두 가지가 있습니다. 하나는 shaderFX에서 만든 이 구조 (선을 연결해서 이어 만드는 구조 - 노드구조- 라고도 하지요) 를 .SFX 파일로 저장하는 것과, 여기서 제작한 것을 표준 쉐이더 파일 포맷인 .FX 파일로 저장하는 것입니다.

일반적으로 이 작업을 하실 때에는.SFX 파일을 꼭 저장하셔야 나중에 불러와 수정하거나 할 수 있기 때문에 이것은 꼭 저장을 하셔야 합니다. 이것이 일반적으로 그래픽 디자이너가 알고 있는 ‘저장’ 의 개념이지요.[각주:4]
.SFX 파일은 shaderFX 전용 파일 포맷으로, 다른데서 쓸 수 없습니다. 오직 shaderFX에서만 쓸 수 있는 파일입니다.

.FX 로 저장한다는 것은, 마치 그래픽 프로그램에서 다른 프로그램으로 파일을 넘기기 위해 익스포트(Export) 하는 개념과 비슷합니다. .FX는 쉐이더 프로그램 언어인 HLSL(High Level Shader Language) 의 표준 파일 포맷으로, 이것으로 저장하게 되면 3D max를 비롯하여 일부의 게임 엔진에서도 이 쉐이더 파일을 직접 사용할 수 있으며, 다른 게임 엔진이라고 하더라도 약간의 수정을 통해 게임에서 실제로 사용할 수 있게 만들 수 있습니다.

.SFX 파일로 저장하기는 어렵지 않습니다.

그냥 우리가 알고 있는 일반적인 저장이기 때문입니다. Ctrl+S 만 눌러줘도 저장할 수 있습니다. .SFX 파일로요.

그런데, 이 쉐이더 파일을 게임엔진이나 맥스에서 사용할 수 있는 전용 쉐이더 프로그램으로 export 하려면, 다른 메뉴를 사용해야 합니다. 이것은 실제로 이 강의 동안에 사용할 일은 없을 것입니다만, 만약 여러분들이 만든 쉐이더를 실제로 게임에 사용해야 할 필요가 생겼다던가 할 때에는 FX 파일로 익스포트를 해 주어야 합니다.

이렇게 저장하기 위해서는 아래 그림과 같이, 3D max에서 사용할 수 있는 FX 파일과
기타 다른 프로그램들에서 사용할 수 있는 FX 파일로 익스포트 할 수 있습니다.

익스포트 옵션은 여러 개가 있습니다. DirectX 를 위한 옵션도 있고, 다른 여러 엔진에 따라 저장할 수 있는 옵션들이 있습니다. 미리 익혀 둘 필요는 없고, 만약 사용할 일이 생기면 그 때 엔진 프로그래머와 상의하면 되겠습니다.

이렇게 FX로 출력하면, “표준 hlsl 언어"로 출력되어, 대부분의 게임엔진에서 어느 정도만 수정하면 사용할 수 있게 됩니다. 그렇지만 연습용이 아닌 이상 실제로 사용하기는 쉽지 않은데요,

그것은 바로 아래와 같이 ‘코드가 너무 쓸데없이 복잡하게 나오기 때문’ 입니다.
단순히 붉은 주전자 하나만 출력하는 쉐이더 코드임에도 불구하고, 최적화를 전혀 해주지 않기 때문에 복잡한 라이트 연산이 모두 들어 있는 채로 출력됩니다. [각주:5]

즉 제작하기 간편한 대신 최적화가 전혀 되어 있지 않은 채로 익스포트 되기 때문에, 사실상 실무에서 사용하기 위해서는 이 fx 파일을 바로 사용하기 보다는 이 파일을 참고해서 재 작성하는 쪽이 훨씬 빠르고 편합니다.

저도 hlsl언어를 직접 다루게 된 이후부터는 이렇게 shaderFX에서 출력한 쉐이더 코드를 직접 사용하지는 않게 되었지만, 가끔씩 기능 구현의 힌트를 얻고 싶을 때에는 이렇게 쉽게 짜서 출력한 코드를 보고 참고하면 꽤 도움이 될 때도 있었습니다.

자, 이렇게 해서 가장 기본적인 쉐이더를 shaderFX를 이용하여 작성해 보았습니다. 다음 시간에는 이런 것이 연재됩니다.

텍스쳐를 넣어봅니다!!! 뭐, 사실 위의 것을 할 수 있으시다면 벌써 할 수 있으십니다!!! 매우 쉽지요.
그런데, 여기서 드디어 이론이 들어갑니다! float3의 비밀이 풀리는 시간입니다. 색의 이론에 대해서 배우게 되지요.

실제로 최신 버전 3D max의 메터리얼 에디터는 shaderFX와 흡사한 모양의 에디터 창을 가지고 있습니다. [본문으로]- 미리 말씀드렸다시피, 3Dmax의 기초 정도는 아셔야 가능한 강의입니다. 기초 책을 봐도 2-3일 정도만 공부하시면 알 수 있는 레벨이지요. 별로 안어렵습니다. 공부하세요. [본문으로]- 물론 프로그래머들은 같은 일을 각종 코드들을 쳐 넣어서 하지만요 [본문으로]- 프로그래머들은 ‘워크 스페이스를 저장한다’ 라고 말하면 알아듣습니다. [본문으로]- 실제 저 빨간 주전자 구현을 코드로 짜면, 몇 줄밖에 되지 않습니다. [본문으로]

2011년 내 이글루 결산

Mon, 02 Jan 2012 14:23:22 +0000

올해의 운세..

Sun, 01 Jan 2012 20:14:55 +0000

올해의 운세~

자무님 글에서 트랙백.

총운 : 멀리서 귀인이 찾아오니 반갑게 맞이하라.

직업운 : 유종의 미를 거두게 된다.

사랑운 : 사랑에 속고 돈에 울고

* 길방: 西, 길한 달: 2월

사랑만 안하면 되는건가….

ExSound Portable Speaker MX 리뷰

Sat, 31 Dec 2011 23:39:31 +0000

이번에는 제주도 여행 갔다 오느라 시간이 꽤 걸렸네염.
길어서 가립니다.

TA직군 인터뷰

Sat, 24 Dec 2011 03:54:11 +0000

Q:먼저 자기 소개 부탁드립니다.

Ndoors 개발1본부의 테크니컬 아트 디렉터(Technical Art Director) 정종필이라고 합니다.

Q:어떻게 게임업계에 들어오게 되었나요?

이제 대충 20년이 되었네요. 처음에는 그냥 친구들과 함께 만화를 즐겨 그리던 평범한 학생이었는데, 어느 날 친구들이 게임을 만들기 위해 그래픽이 필요하다는 얘기를 듣고 HQteam 이라는 팀을 만들어 게임에 들어갈 그래픽 데이터를 그리기 시작한 것이 어느새 직업이 되었습니다. 처음 시작할 때에는 게임 개발에 대한 제대로 된 책이나 교육기관 같은 것이 전무하다시피 했기 때문에 그냥 독학으로 진행할 수 밖에 없었고, 때문에 캐릭터부터 시작해서 배경, 이펙트 UI 등 게임의 모든 부분을 작업해 볼 기회를 얻게 되었습니다.

그 이후에 충무공전, 임진록, 천년의 신화, 거상, 군주온라인, 아틀란티카 등의 프로젝트에 참여하면서 약 15년간 그래픽 파트에서 일해오다가 2~3년 전 TA라는 직군으로 전직하게 되었습니다.

Q:TA란 어떤 일을 하고, 게임 개발에 어떤 식으로 참여하나요?

TA는 모델러나 애니메이터처럼 특정하게 고정된 업무가 지정되어 있지는 않습니다. 저 같은 경우는 그래픽 직군을 AD와는 다른 측면에서 총괄하는 역할을 하고 있기도 하고 있기 때문에 사실상 모든 일에 접근 가능합니다. 또한 이것은 회사마다, 프로젝트 팀의 성격에 따라 모두 다를 수 밖에 없으며 아직까지는 그게 정상이라고 생각하고 있습니다.

저 같은 경우는 주로 담당하는 업무가 게임 전체의 셰이더(shader) 제작과 관리, 유지보수등을 담당하고 있으며, 게임 그래픽의 옵션 결정과 관리, 주로 GPU에 한정되는 게임 퍼포먼스 체크 및 관리, 그래픽 리소스들의 효율성 체크등도 담당하고 있습니다. 또한 회사 내의 기술공유와 이슈 사항 교육들도 TA들의 필수적인 업무 중 하나입니다.

저와 같이 일하고 있는 또 한 명의 TA는 캐릭터 애니메이션 기술에 특화되어 있으며, 물리 엔진의 실무적 사용과 효율적인 스키닝을 위한 기술연구, 각종 맥스 스크립트 제작등을 주 업무로 하고 있습니다.

Q:TA가 가지는 보람은 무엇이라고 생각하나요?

TA라는 직종이 본격적으로 나타나기 이전에는 그래픽 아티스트들이 접근할 수 있는 범위는 게임 엔진으로 넘기는, 완성된 리소스 까지였습니다. 물론 이것은 이전의 2D 게임에서는 더 이상 접근할 필요가 없었던 것도 사실입니다. 포토샵에서 예상할 수 있는 그대로 게임에서도 리소스가 나오기 때문이지요. 그러나 3D 게임 시대가 되면서 더 이상 3D max 라는 저작툴과 게임 안에서의 그래픽 모습이 동일하지 않게 되었습니다. 게임 엔진에서 표현되는 3D는 초반에는 단순한 텍스쳐와 모델링의 출력이었지만 각종 기술들, 특히 셰이딩(shading) 이 본격적으로 들어가게 되면서 전혀 다른 이미지로 변하게 되었기 때문이지요.

그래서 그래픽 아티스트가 만든 리소스 데이터가 게임에서 얼마나 아름답고 효율적으로 나오는지에 대한 결정은 철저하게 최고 프로그래밍 결정자의 몫이었습니다. 물론 우리가 만드는 것이 그래픽을 자랑하기 위한 결과물이 아니라 유저들의 PC에서 제대로 돌아가는 게임이라는 점에서 이러한 타협은 매우 중요하고 어쩔 수 없는 일이기도 하지만, 십수년간 그래픽 디자이너로 일하면서 이런 한정된 자원 안에서 그래픽 아티스트의 감각과 프로그래머의 머리로 생각할 수 있는 사람이 있다면 훨씬 더 만족스러운 결과물이 나올 것이라고 생각했습니다. 그래서 프로그래밍을 공부하고, TA라는 직종의 일을 시작하게 되었습니다.

그리고 아직 완전히 만족한다고는 할 수 없지만, 적어도 이전보다는 훨씬 더 그래픽 아티스트들이 만족할 수 있는 퀄리티를 표현하면서도 프로그래밍적 부하를 합리적으로 줄일 수 있는 선택지를 찾아 나가고 있다고 생각하고 있습니다. 이제는 적어도 게임 퍼포먼스의 저하요인을 해결하기 위해 합리적 이유없이 그래픽 데이터 퀄리티부터 우선적으로 줄여 나가는 일은 일어나지 않습니다.

이렇게 그래픽과 프로그래머의 중간에서 일하면서, 양쪽이 만족하는 이런 선택지를 찾아 내었을때의 감동은 무척 짜릿한 일입니다. 게임의 그래픽이 안정적인 프레임을 유지하면서도 풍부한 어셋(Asset)과 색감을 유지하게 되었을 때, 그래픽 아티스트로서 만족할만하고, 유저가 알아채지 못할 정도로 거의 동일한 품질의 이미지를 출력하면서도 메모리 혹은 GPU점유율을 크게 떨어뜨렸을 때
또한 TA라는 업무가 가장 보람있을때라고 할 수 있습니다.

또한 정확한 기술적 이론의 전파와 교육도 TA의 업무 중 하나입니다. 그래픽 디자이너들이 작업한 결과물을 체크하면서, DPcall을 고려하면서 제작한 흔적이 보일 때, 품질이 떨어지지 않으면서도 최상의 압축이 매우 훌륭하게 되어 있는 데이터들이 가지런히 정렬되어 있는 모습을 볼 때에도 매우 기쁩니다.

하지만 무엇보다 보람있을 때에는, 프로그래머와 그래픽 아티스트들이 만족할 때입니다.
프로그래머는 늘 곤란했던 ‘같은 자원을 이용하면서 더 아름답게 보이게 하는 기술적 방법’을 담당해 주는 TA를 만족해 하고, 그래픽 디자이너들은 ‘더 좋은 품질의 결과물과 자유도 보장, 그래픽 디자이너 입장에서 명확하게 이해할 수 있는 한계’를 제시해 주는 TA를 만족해 할 때 가장 큰 보람을 느낍니다.

Q:TA를 수행하는 데 도움이 되었던 경험은 어떤 게 있나요? 그리고 TA로서 자기개발은 어떻게 하고 있나요?

본래는 TA라는 직종이 있는지도 모르고 무작정 프로그래밍을 공부하였습니다. 시작은 맥스에서 제작된 캐릭터 이미지가 게임에 넣었을때 맥스에서보다 훨씬 못 생겨 보인다는 것을 깨닫고, ‘무슨 이유가 있을 것이다’ 라고 시작한 것이 셰이더(shader)였지요.
그리고 셰이더를 다루기 위해서 처음에는 무작정 독학을 하다가 나중에 야간 대학원에서 C와 DirectX를 한 학기씩 공부하였습니다. 이때 강의해주셨던 S대학원 홍교수님께는 지금도 감사하고 있습니다. 지금까지 들었던 어떤 프로그래밍 강의보다도 쉽고 유익했으니까요. 이 때 배웠던 지식이 사실은 기술적 지식의 전부라고 할 수 있겠습니다.

또한 그래픽 디자이너로 일할 때, 업계의 초창기부터 일할 수 있었던 것도 매우 큰 도움이 될 수 있었습니다. 도트 캐릭터 부터 시작해서, 배경 타일, 각종 이펙트와 UI , 동영상과 패키지 디자인까지 거의 모든 분야의 그래픽 작업을 혼자서 처리하거나 관여하였기 때문에 전체적인 그래픽 디자이너들의 입장과 전체 작업 플로우를 파악할 수 있었다는 것도 매우 큰 도움이 되었습니다. 오랜 시간동안 그래픽 팀장일을 했던 것도, 그래픽 아티스트들의 심리와 욕구를 파악하는데 큰 도움이 되었지요. 동시에 처음부터 작은 팀으로 시작했던 관계로 프로그래머들과도 밀접한 위치에서 오랜 기간 동안 일할 수 있었던 것도 매우 좋은 경험이었습니다.

현재도 프로그래밍 공부와 영어공부를 계속하고 있으며, 시간이 나는대로 그래픽 공부도 다시 해야 하겠다고 생각하고 있는데 솔직히 거기까지 몸이 따르지 않고 있네요. 또한 최근에는 국내외의 유명 프로그래머 분들과 친분이 생겨서, 그 분들을 통해 많이 배우고 공부하고 있습니다. 이 자리를 빌어 감사드리고 싶네요.

Q: 이런 걸 준비했더라면 좀 더 도움이 되지 않았을까 하는 무엇인가요? 또는 지금까지 개발하면서 아쉬웠던 점은 어떤게 있을까요?

게임업계 들어오면서부터 늘 생각하고 있던 부분이기도 하지만, 어째서 게임업계에서 학교공부가 이렇게 많이 필요하다는걸 아무도 가르쳐 주지 않았을까 하는 생각이 늘 듭니다 (웃음) 만약 제가 과거의 나를 만날 수 있다면, 수학의 정석에 있는 그 필요없어 보이는 공식들이 얼마나 나중에 도움이 될 것인지, 나중에 보게 될 문서가 알아듣지도 못할 수학공식과 영어로 씌여진 글이라는 것을 알려주고 싶습니다. 수학과 영어실력이 좀 더 높았다면 훨씬 더 빠르고 좋을 결과물을 낼 수 있었을 것이었을 겁니다.

아참. 현재도 몸이 따르지 않지만 테크니컬 애니메이터(Technical Animator) 라고도 불리우는 TA의 영역도 좀 더 공부해 보고 싶은 것도 사실입니다. 현재는 그 쪽 담당의 TA와 분업해서 일하고 있으니 한동안은 괜찮겠지만요.

Q: 최근 직무 분야의 트렌드와 이슈를 꼽는다면?

현재 들려오는 얘기에 따르면 여전히 해외에서도 TA들은 부족한 것으로 보이며, TA들에게 요구하는 수준이 좀 더 높아지는 추세로 보입니다. 또한 TA들이 접근하는 영역도 점점 깊어지고 있다고 합니다.

그리고 우리나라에서는 TA라는 직종이 외국보다 더 늦게 시작되었기 때문에 더욱 더 수요에 비해 TA의 공급이 턱없이 낮은 상황이며, 개인적인 의견이지만 상용화된 게임 엔진을 사용하여 게임을 만드는 회사와 게임 엔진을 제작하는 것을 전문으로 하는 회사의 분업이 더욱 더 확고해질 것으로 예상되므로 앞으로도 TA의 수요는 더 높아질 것으로 보이며 그 분야도 훨씬 더 넓어질 것으로 보입니다.

Q:이 직무를 지망하는 사람들에게 어떤 얘기를 당부하고 싶으신가요?

TA를 지망하는 사람들이 생각보다 많이 생겨서 사실 깜짝 놀라고 있습니다. 사실 굉장히 매력적인 분야이기도 하지요.
그리고 그것 때문에 심심치 않게 상담을 해주는 경우도 생기곤 하는데요. 주로 프로그래밍 혹은 기술적인 분야에 관심이 많은, 얼리아답터 성향의 그래픽 아티스트들이 관심을 보이는 경향이 있습니다. 이런 지원자들은 사실 상당 수준의 프로그래밍 기술을 가지고 있는 경우도 있어서, 간혹 깜짝 놀라곤 합니다.

그렇지만 이런 지원자들을 모두 TA로 선발하기 곤란한 이유가 있습니다.
TA란 그저 프로그램을 조금 잘하는 그래픽 아티스트의 의미가 아닙니다. TA는 궁극적으로 ‘최대한 효율적이고 아름다운 게임이 완성되도록 ’ 지원하는 것을 제일의 목적으로 하며, 그러기 위해서 특히 ‘그래픽 아티스트들이 자신들의 능력을 최대한 발휘해서 원하는 결과물을 낼 수 있도록 도와주며 프로그래머들에게 가장 효율적인 방법을 제안해 주는’ 일을 주 업무로 하는 것입니다.
그런 의미에서 자신의 지식욕을 충족하는것을 목표로 하고 있는 지원자는 TA와 맞지 않습니다.

TA는 자신이 연구한 것을 동료 개발자들에게 공유하는 것을 즐기며, 그들이 그 기술들을 불편하지 않게 잘 사용하는지를 지속적으로 관리하고 유지하여야 합니다. 즉 골방에서 연구하는 학자의 모습도 TA의 일부분이긴 하지만 가장 중요한 모습은 우리가 공부하고 알아낸 지식들을 가능한한 효율적으로 개발자들과 적극적으로 공유하고 참여시키는 영업사원의 모습이 필요합니다.

만약 이 글을 읽으시는 분들이 TA가 되고 싶으시다면, 기술적인 연구보다는 커뮤니케이션 기술을 더 중요하게 생각하시라고 말씀드리고 싶습니다. TA는 혼자서 일하는 사람이 아니라 모두와 함께 일할 수 밖에 없는 사람이기 때문입니다.

오즈라엘 아저씨 선물그림

Mon, 19 Dec 2011 22:51:34 +0000

이거 해 주면 오즈라엘 아저씨가 사주기로 했다 고기.

이것은 그냥 공

뒤집는다 확장한다 검다 공
한번 더 찍는다 공

당신은 만족한다 당신의 공으로부터

복잡하다 오브젝트
확장한다 당신의 피봇으로부터

어긋난다 당신의 아름다운 외각

보통은 도움으로 당신의 외각선을 확장한다.

만약 내게 물어보면 , 나는 왈도.

블로그 이사했습니다 / 방명록도 여기로

Sun, 18 Dec 2011 23:55:48 +0000

메인 블로그를 티스토리로 옮길까 하는 마음에 슬슬 준비하고 있습니다 :) 기능 차이가 아주 크군요 … 이글루스는 점점 개판이 되어 가고 있는데… 역시 SK가 손대다 보니 그런가 봅니다. 일단은 티스토리에 써도 여기에 옮겨적기는 하겠습니다만, 방명록 http://chulin28ho.tistory.com/guestbook을 이용해 주시기 바라겠습니다 :)

블로그 이사했습니다.

http://chulin28ho.tistory.com

그래픽 디자이너를 위한 기초 쉐이더 강좌

Sat, 17 Dec 2011 17:25:26 +0000

들어가며

이 글은 게임개발포에버 팀블로그에 연재되는 글입니다. 동시에 올라오거나, 다음부터는 링크만 … 지원할지도 모르겠어요.
이글루스의 외부로 사진 퍼갈때 해상도 저하시키는 시스템 문제로 블로그를 옮겨야 하나 심각하게 고민중이거든요.

다른 분들과는 다르게 그래픽 디자이너로 시작한데다가 기초도 없이 맨땅에 해딩하면서 배워왔던 지식이라, 다른 분들보다는 그래픽 디자이너 입장을 쉽게 알 수 있다고 생각해서 ’ 엄청나게 무식하고 쉽게’ 라는 모토로 기초적인 shader 실습 / 이론을 진행해 볼까 생각해 보았습니다.

마치 ‘만화로 쉽게 배우는 푸리에 해석’ 같은 느낌일까요 -_-; 뭐, 만화는 나오지 않습니다만…

성안당 : 만화로 쉽게 배우는 푸리에 해석.

대상
일단 대상은 ’ 프로그래밍을 하나도 모르는 그래픽 디자이너’ 를 대상으로 합니다.
그래서, 이론은 나올지언정 코딩은 전혀 하지 않으면서 쉐이더를 배우게 됩니다.

게임 제작이라는게 워낙 복합적이고 다양한 사람들이 모여 만들어야 하는 융합학문 계열인지라, 서로의 영역을 조금씩 침범할 수 밖에 없는 직종입니다.

그래서인지 이게 그래픽인지 , 프로그램인지, 기획인지 헷갈리는 영역이 존재하기도 하고, 두 개 이상의 분야가 제대로 이해하고 협력해야 결과가 나와야 하는 영역도 있습니다. 그 중에 shader 영역은 그래픽 디자이너의 영역이기도 하면서, 그래픽 프로그래머의 영역이기도 합니다. 그래픽 디자이너는 자신이 원하는 ‘느낌’ 을 감각적으로 표현할 수 있고, 프로그래머는 어떤 결과가 나오는 ‘과정’ 을 논리적으로 풀어갈 줄 아니까 말이지요.

그러므로 프로그래머가 ‘감각’ 을 익히거나, 그래픽 디자이너가 ‘과정’ 을 이해하거나 한다면, 훨씬 좋은 결과물이 나올 수 밖에 없는 것이 바로 이 shader 라고 할 수 있습니다.

프로그래머를 위한 기초 shader 강의는 포프님이 해 주시니까, 저는 그래픽 디자이너 (혹은 기획자, 혹은 진짜 개념만 잡고 싶은 프로그래머) 를 위한 기초 shader 강의라고 할 수 있겠지요.

Shader가 뭔가요?

가장 중요한 질문을 넘어갈 뻔 했군요.
포프 스승님이 강의에서 말씀하시길, 쉐이더란

“쉐이더란 화면에 출력할 픽셀의 위치와 색상을 계산하는 함수입니다. "

라고 하셨습니다.
음… 감이 오시는지? 저는 이걸 그래픽 디자이너 마인드로 다시 설명해 보겠습니다.

“쉐이더는 ‘재질’ 입니다. 일명 ‘때깔’ 이라고도 하지요.”

… 이것이 그래픽 디자이너가 이해하는 쉐이더입니다.

스승님이랑 싸우자는게 아니고, 위의 두 가지 표현이 포프님의 강의와 제 강의의 차이라고 할 수 있겠습니다. 포프님의 강의가 ‘교과서’ 라면, 저는 ‘그림동화’ 입니다 ㅎㅎ

당연하게도 내용은 재미위주고, 깊이는 훨씬 얄팍합니다.

자 여기 그림들이 있습니다.
http://izismile.com/2010/06/30/how_games_change_the_rock_21_pics.html

‘게임에서 돌이 어떻게 바뀌나’ 라는 재미있는 그림인데, 다소 과장이 섞여 있는 말그대로 재미를 위한 글입니다. 그렇지만, 의외로 쉐이더란 무엇인가라는 대답을 주고 있기도 합니다.

자, 이 중 몇 개만 비교해 보죠.

차이가 보이시는지? 같은 돌임에도 불구하고, 게임마다 뭔가 다르게 느껴지고 있다는 것을 알 수 있습니다. 사실 이 결과물은 단순히 색을 조작해서 게임의 분위기를 풍자하고 있는 글이지만, 조금만 생각해 보면 진짜로 게임마다 저런 ‘뭔가 독특한 질감’ 을 가지고 있었다는 것을 아실 수 있습니다.

또 아래 그림을 보시죠.


File:Toon-shader.jpg
http://upload.wikimedia.org/wikipedia/commons/b/b7/Toon-shader.jpg

같은 모델링인데, 분명히 ‘질감’ 이 다릅니다. ‘때깔’ 이 다르지요.

그래픽 디자이너가 shader 를 배워서 어디에 쓸 수 있나요?

요즘엔 shader를 사용 안하는 프로젝트가 전무하다고 할 정도로 게임 그래픽에서 매우 중요한 한 축을 담당하고 있습니다. 그래서 싫다고 해도 어쩔 수 없이 그래픽 디자이너가 shader의 많은 옵션들을 조절하기도 해야 하고, 마스킹 텍스쳐도 적절하게 제작해야만 하며, 필요하다면 원하는 느낌을 내기 위해서 그래픽 프로그래머에게 ‘어떠어떠한 느낌으로 만들어줘’ 라고 요구해야만 하지요. (저희 회사에선 제가 맘대로 합니다만 ㅎㅎ)
이럴때 이론적 지식은 큰 도움이 되게 됩니다. 아무래도 프로그래머가 만든 언어라 그래픽 디자이너와는 용어도 다르고, 원하는 느낌을 최고로 내면서 효율적으로 만들기 위해서 필요한 기술을 그래픽 디자이너가 익히려면 기본적인 지식 정도는 가지고 있어 주어야 하거든요.

그리고 프로그래머에게 이런 기술적 지식 없이 그래픽 디자이너의 언어로
“뽀샤시하지만 착 눌러앉은 색감으로 너무 딴딴하지 않은 질감이 나도록 만들어줘”
라고 요구한다면 프로그래머에게서는 이런 반응이 나오게 됩니다



프로그래머의 반응

또한 최근에는 언리얼처럼 노드 구조를 직접 그래픽 디자이너가 조합할 수 있도록 만드는 쉐이더 툴을 지원하는 엔진도 꽤 생겨나고 있는 편인데다가, 최신 3Dmax 에서는 아예 메터리얼 에니터를 이런 노드 구조로 만들기도 하였습니다.

즉, 좋은 그래픽을 위해 꼭 사용할 줄 알아야 하는 메터리얼 에디터가 될 것이라는 거지요.

뭘 준비해야 하나요?
원래 이 분야는 프로그램적 마인드로 제대로 접근하자면, 렌더링 파이프라인부터 시작해야 정상입니다. 그치만, 그래픽 디자이너의 마인드는 프로그래머의 마인드와 한참이나 다른 데 부터 시작합니다.

기본적으로 그래픽 디자이너는 비싼 타블렛이나 마우스에 목숨걸고, 프로그래머는 비싼 키보드에 목숨걸잖아요. 인터페이스 조작부터 그래픽 디자이너들은 다르게 접근해야 합니다.

생각해 보세요. 그래픽 디자이너는 첨에 ‘뭣도 모르고 무작정 이쁘게 그리려다 보니까’ 결국엔 더 이쁘게 그리기 위해 빛을 생각하게 되고, 선 그리는 법과 구도, 투시를 익히게 되지요.

그림에 관심도 없는 사람이 그림이론부터 차근차근 배우기 시작해서 나중에 보니까 그림을 잘 그리게 되었더라… 라는 케이스는 거의 없습니다.

멋진 프로그래머가 되기 위해서 그 지루한 기초 프로그래밍을 차근차근 밟아 가야 뭔가 기초적인 결과라도 볼 수 있는 프로그래머와는 달리, 그래픽 디자이너는 처음부터 연필을 잡고 아무생각 없이 휙휙 그려봤더니 뭔가 이쁘더라 … 에서부터 시작하곤 하거든요.



이 아저씨 강의 때 선 긋기부터 안나오잖아요. TV쇼라서 더 그렇겠지만.

여기서부터 프로그래머 마인드랑 정반대로 가는 거지요. 프로그래밍 책이 그래픽 디자이너에게 어려운 이유는 그것입니다.

‘아놔 첨부터 좀 멋진 거 하게 해 달라고! 버퍼는 뭐고 시멘틱은 또 뭐야!!! 안해!!! '

이게 그래픽 디자이너 마인드지요 :)

그래서 , 복잡한 기본 이론 따위는 나중으로 미뤄 버리려 합니다.
가능한한 첨부터 그림이 나오게 합니다!
바로 제가 수없이 삽질하면서 공부했던 그 방법입니다!

그리고 중간중간 필요한 이론만 간략하게 설명하겠습니다.
그러다보니, 필요한게 있습니다. 3D max 입니다.

3D max 는 다소 간략하긴 하지만, 인터페이스가 꽤 괜찮은 실시간 렌더링 툴이기도 합니다. 즉 게임과 다를게 없지요. 3D max 만으로도 초급 shader는 배울 수 있습니다. 무엇보다 그래픽 디자이너들을 위해, 마우스로 대부분의 조작을 할 수 있다는 것과 익숙하다는 장점도 매우 큽니다.

3D max 실력은 높을 필요는 없습니다만, 기본적인 오브젝트 정도는 설치할 수 있는 실력이어야 합니다. (보통, 주전자 정도 만들고 텍스쳐 하나 입힐 수 있는 수준이면 충분해요)

여기에 하나 더, 쉐이더를 다루기 위해서 무료 플러그인이 필요합니다.
앞서 말씀드렸듯, ‘바로 처음부터 재미있는 실습을 하기 위해’ 무언가 설치해야 합니다.

바로 Shader FX 라고 하는 플러그인이지요.

http://www.lumonix.net/shaderfx.html

다운로드는 위 홈페이지에서 받을 수 있습니다. 완전 무료입니다.

그리고 시간이 되시는 분은 이 사이트의 강좌 동영상을 훑어 보시면, 사실 제 강의가 필요 없을 정도로 쉽게 이 프로그램을 다루실 수 있습니다. 영어라서 문제지

이 프로그램을 설치해 두세요. 설치시의 유일한 주의사항은, 중간에 맥스의 버전을 잘 선택하시고, 설치 경로를 정할 때 반드시 3Dmax가 설치된 Root 폴더를 선택해 주셔야 한다는 겁니다.



맥스가 설치된 폴더를 정확히 지정해 주어야 합니다



자신의 Max 버전과 맞는 것을 선택하세요

이제 3Dmax를 실행시켜 봅니다. 튜터리얼 동영상 링크가 가득한 첫 화면이 뜨지요.
첫 화면에 이렇게 되면 완성입니다.



만약 이렇게 안나온다면 잘못 설치한 겁니다.

동영상만 봐도 사용법은 충분히 알 수 있습니다만, 문제는 이 동영상에서도 얘기해주지 않는 것입니다. 그래픽디자이너에게는 생소한 용어와 개념들 말이지요.
그러므로 다음 시간부터는 이 기초적인 용어와 개념을 그래픽 디자이너가 이해할 수 있도록 설명하면서 shaderFX를 이용하여 shader를 다뤄 보도록 하겠습니다.

삼국지를 품다 툰쉐이더 버전 테스트

Thu, 15 Dec 2011 19:17:06 +0000

연구삼아 만들어본 버전입니다.

혹시 나중에라도 쓸 데가 있을지도 모르니까요 .

검은 외각선이 안이쁘데서
텍스쳐의 색에 맞춰서 외각선이 나오도록 해봄.
이쁘다…

그치만 우린 안쓸거야.

나중에 캐릭터 선택할때 마우스 오버 효과등에 쓸 수도 있겠죠

Flag pass : 그리지는 않고 Z 버퍼만 쓰는 pass

Tue, 13 Dec 2011 09:35:55 +0000

백업임.

참고로
Tags { “Queue”=“Transparent+1” “IgnoreProjector”=“True” “RenderType”=“Transparent” }
Blend SrcAlpha OneMinusSrcAlpha
였음.

// flag pass

Pass
{
ColorMask A
Blend One Zero

CGPROGRAM

#pragma fragmentoption ARB_precision_hint_fastest
#pragma vertex vert_onlyAnimation
#pragma fragment frag_alphaMask
#include “UnityCG.cginc”

struct v2f_aniOnly {
float4 vertex : POSITION;
};

v2f_aniOnly vert_onlyAnimation(appdata_full v)
{
v2f_aniOnly o;

o.vertex = mul(UNITY_MATRIX_MVP, v.vertex);

return o;
}

half4 frag_alphaMask(v2f_aniOnly i) : COLOR
{
return half4(0,0,0, 1);
}

ENDCG
}

게임개발 포에버 팀블로그에 연재 시작합니다.

Mon, 12 Dec 2011 22:50:17 +0000

http://gamedevforever.tistory.com/

입니다. 어찌어찌어찌어찌 하다가 참여하게 되어 버렸는데, 개인적으로는 무척 영광스러우면서도 두렵기도 합니다.
그치만 요샌 트위터나 페북이다 때문에 블로그에 긴 글을 쓰는 것을 귀찮아 했었는데 잘 되었다 싶기도 하구요.
그리고 이글루스의 글을 외부 링크하면 사진의 해상도를 낮춰 버리는 정책 때문에 사이드 블로그를 하나 둘 까 (아니면 이전할까…)도 생각하고 있었고 말이죠.

일단 저 팀블로그에 글을 연재하기 위해서 티스토리 블로그를 하나 만들었으니, 좀 써 보고 그건 보조블로그로 놔둘 것인지 거기로 이전할 것인지 생각해 봐야겠습니다.

저는 3일과 18일에 글을 쓰는 것으로 결정되었구요. 가지고 있는 재주가 꽤나 알량하다 보니 (…)
다른 분들처럼 높은 수준으로는 쓰지 못하겠고, 제가 요새 관심있는 셰이더에 대해서 매우 쉽게 한 번 써보려고 합니다

목표는 ‘프로그램 하나 짤 줄 모르는 그래픽 디자이너가 셰이더를 짤 수 있게’ 라는 것이구요.
그리고 또 하나 목표는 ‘포프 스승님 글보다도 훨씬 쉽게!’ 입니다.
포프님이 연재하시는 셰이더 강의 http://kblog.popekim.com/2011/11/00.html
가 교과서라면, 저는 그림 동화책 정도!!!!

그러므로 시작은 가장 쉬운 프로그램중 하나인 ShaderFX 를 이용해 보도록 하겠습니다.
이거라면 특정 엔진에 매어 있지도 않으면서, 개념은 거의 같으니까요.
물론 중간중간 이론도 들어가지만, 실습을 하면서 중간에 끼워 넣을 거니까 그다지 많지 않 …( 아니군요 많겠네요) … 도록 노력해 보겠습니다. 그리고 나중에는 유니티 셰이더로 연결을 자연스럽게 하면서, 두 번째 공부할때는 포프 스승님 강의로 이어질 수 있게 말이죠.

아우 근데 참여하고 있는 다른 분들이 전부 쟁쟁한 네임드란 말이죠. 아우 떨려 어떡해 ㅋㅋㅋㅋ

게임브리오에서 버텍스 칼라에 라이트 베이킹하기

Mon, 12 Dec 2011 17:02:56 +0000

사실 게임브리오 뿐만 아니라, 버텍스 칼라를 이용할 수 있는 모든 엔진에는 사용 가능한 정적 라이팅 (Static Lighting) 입니다.

잘 사용하면 적절한 환경 라이트 이미지를 만들 수 있습니다.

일단, 테스트 맵을 만듭니다. 박스를 만들고 Normal 모디파이어를 이용하여 노말을 뒤집어 줍시다. 가운데 주전자 하나도 설치하였습니다.

폴리곤은 대충 이 정도입니다. 조금 많긴 하네요. 가능한한 규칙적일 수록 좋고, 폴리곤 크기가 모두 같으면 같을 수록 좋습니다.

이제 라이트를 설치합니다.
일반 라이트가 아니라 Photometric 라이트라는 것을 주의하세요
Render / Raytrace 를 눌러서 창을 꺼냅니다.
Advenced Light 탭을 열고, 일단 Start 버튼을 눌러봅시다.

한 번만에 이렇게 나왔다면 대단히 운이 좋은 것입니다.
너무 밝거나 너무 검게 나온다면, Render / Exposer Control에 가서 Brightness를 올려 봅니다. 그 외에 Contrast 등 여러 옵션을 조절해 봅니다.

색상도 바꿔봅시다.
일단 라이트를 선택하고, 필터 칼라를 선택합니다.
그 후 Reset All을 눌러서 초기화 시킨 후에 다시 Start 버튼을 누릅니다.

마음에 들지 않으면 마음에 들 때까지 조절하고 Reset -> Start 를 반복합니다.

이제 라이트를 복사해서 색과 밝기를 바꾸면서 원하는 느낌을 내 봅니다.
찾아보면 기둥모양의 조명이나 평면조명도 사용 가능합니다. 이 부분은 직접 찾아보시길 바립니다.

매번 라이트를 추가하고 수정할 때마다 Reset All -> Start를 눌러주는 것을 잊으면 안됩니다.

맘에 들었다면 조명을 삭제해 봅시다.
자, 조명을 삭제했는데도 , 조명의 느낌은 그대로 남아 있습니다.
이것은 vertex Color 에 구워(Baking) 되었기 때문입니다.

그대로 엔진으로 넘겨도 동일하게 적용됩니다.

단, 이 라이트 효과는 고정된 라이트 효과이기 때문에 에니메이션이 되거나, 물체를 움직여서도 안되고 캐릭터가 근처에 가도 영향을 받지 않는다는 것을 잊으면 안됩니다.

왜 우리 게임의 병사는 HP로 보이는가?

Thu, 08 Dec 2011 19:14:29 +0000

게임에는 ‘문법’ 이라는게 있습니다.
영화에서도 문법이 있지요.

이런 영상매체의 문법은 그 매체들을 계속 만들어 가면서 약속된 규칙 같은 것입니다.
예를 들어 영화에서 뭔가 주인공이 죽을것 같은 복선 등은, 약속된 문법을 충실히 따릅니다. 그래야 관객들이 이해하고 지나가기 때문이죠.

게임에서도 물론 마찬가지입니다. 디아블로에서 떨어지는 동전, 빨간색 바는 HP, 파랑색은 MP를 의미한다던가, 기타 많은 문법들이 빽빽하게 있는 것이 게임입니다.

그럼 빨리 본론으로 들어가서, 왜 우리 게임의 ‘병사’ 는 HP로 밖에 안보이는가?

그건 문법을 제대로 지키지 않아서 그렇습니다.

자 봅시다.

이게 뭡니까?

게이머 백명을 잡고 물어봐도, 이것은 HP 가 닳는 것이라고 할 것입니다.

네 그렇습니다. 이것은 HP의 문법입니다.
누구도 이걸 ‘병사수’ 라고 생각할 리가 없습니다.

그렇다면 이건 어떻습니까?

어떤 문법이 되었지요? 이것은 약간 모양이 이상하기는 하지만 … 사람들중 대다수는 ‘어 돈이 깎이나 보네..? ’ 라고 이해하게 됩니다. 이것이 문법이지요. 돈을 더 잘 그리고, 돈과 숫자의 디자인이 연결되게 그리면 더 잘 느껴질 겁니다.

그렇다면 이건 어떨까요?

바로 우리가 어렸을때부터 많이 왔던 게임에서 가끔 나오던, ‘병사수’ 가 깎이는 표현 중 하나입니다. 그렇지 않습니까?

우리는 이 ‘병사수’ 라고 하는 , 매우 중요한 개념을 가지고 있고, 그 개념이 또한 독특하기까지 하고 참신하기까지 합니다!

이렇게 낯설은 개념을 유저들에게 어떻게 인지시켜줄 수 있을까요?

자 ▶ 이 버튼은 무엇입니까? 플레이 버튼입니다. 누가 가르쳐 줬습니까? 카세트 테이프가 가르쳐 주었습니다!
그럼 ▶▶ 이건? 뭔지 알겠죠?

이렇게 인터페이스는 익숙한 문법을 써야만 하고, 그 문법이 공통되어야만 합니다.

그런데 우리의 병사수를 표현하는 인터페이스를 보겠습니다.

이게 병사수가 깎이는 겁니다

여기의 병사 표현은 아이콘과 계급장, 숫자입니다.

그리고 여기의 병사 표현은 깃발과 ‘사망병’ 이라는 글씨와 숫자입니다.

이 세 가지에서 어떤 연결된 문법을 찾을 수 있습니까?
일반적인 유저라면, 이 세 개의 다른 인터페이스에서 어떠한 연결고리도 찾을 수 없을 것입니다.

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

만약, 이렇게 바꾼다면 어떨까요?

예를 들어, 저 아이콘이 병사수를 표시하는 것이라고 칩시다.

그렇다면, 여기서는 병사수를 이런 식으로 표시해 주는 것이 좋습니다. (아 , 위의 숫자는 좀 틀렸군요. 한 320/400의 느낌인데요)
이렇게 , 당신이 가지고 있는 병사를 강조해 주어야만 합니다. 숫자는 두 번째 문제입니다.

전투가 끝났을때도 마찬가지입니다. 여기서 병사대기소 그림은 반드시 필요합니다. 더 ‘대기소’ 스러운 집 모양인 것도 좋겠지요.
저기서 병사들이 좌르륵 줄어들면서 , 아래에 있는 각 장수들의 병사가 차 올라가는 애니메이션이 있다고 상상해 보십시오.(동시에 그래프도 올라갑니다)
이게 가장 중요한 부분입니다. 여기서 바로 유저에게 HP바 처럼 보였던 것은 사실은 병사수였구나! 라고 알려줄 수 있는 가장 중요한 부분이 될 것입니다!

대충 그려서 안이쁘지만, 이쁘게 그리는 방법은 많이 있습니다.

그리고 전투에 들어가면, 이렇게 줄어든다고 생각해 보십시오.

이래도 연결이 되지 않을까요?

요건 쫌 오바 같긴 하지만, 메인 창의 아래를 이렇게 표시할 수도 있겠지요. (잘 안보입니다만 어쨌던)

어쨌건 이것은 문법에 충실하고, UI들의 통일성을 강화시켜서 유저에게 연관성을 주게 하는 가장 좋은 방법입니다.
플레이 버튼은 플레이 버튼처럼 생기고, 어디에서나 (심지어 아이폰에서도! ) 이 아이콘을 쓰는 것 처럼, 통일되어야 합니다.

또한 작지만, 위의 그림을 다시 보십시오. 병사수 bar가 압도적으로 크고, 경험치 bar는 아주 작습니다.
경험치 bar는 그다지 중요하지 않습니다. 몰라도 됩니다. 이런 것은 이렇게 작게 빼도 됩니다. 색깔만 더 밝게하면 충분히 나중에 눈에 띄지요. 하지만 병사수는 무척 중요합니다.

자 만약 이것이 되었다 하면, 이런 문법도 가능해 집니다.
위에 두 그림은 뭘로 보이십니까?

왼쪽이 부상병이고, 오른쪽은 더 강한 병사처럼 보이지 않습니까?

이렇게 UI들의 통일성은 무척 중요하고, 게임에서 원하는 것을 유저에게 명쾌하게 주입시킬 수 있는 것입니다.

우리의 병사수가 병사수로 안보이는 것은, 이 통일성이 지켜지지 않고 있기 때문입니다.

…. 오랜만에 도트질했더니 손에 쥐난다….

누가 요청해서 올리는 사진

Thu, 08 Dec 2011 01:04:05 +0000

누군가 요청해서 올리는 사진

포토샵의 모든 블렌딩 공식 셰이더 코드

Tue, 06 Dec 2011 18:31:29 +0000

오버레이 구현하다가 찾았다능…

이거 한 방에 해결이라능…

http://mouaif.wordpress.com/2009/01/05/photoshop-math-with-glsl-shaders/

혹시 링크가 끊어질지 모르니, 파일을 다운받아서 여기다 올려놔야겠어요.

PhotoshopMathFP.glsl

포토샵 블렌딩 모드

Tue, 06 Dec 2011 16:15:45 +0000

Multiply 는 두 컬러를 곱하는 것 즉 A x B 의 결과 C 를 취하는 것 (어두워짐)
Screen 은 두 컬러를 곱하되 (1-A) x (1-B) 의 결과 C 의 (1-C)를 취하여 밝은 쪽으로 만드는 것
Overlay 는 둘 다 해주는 것으로 어두운 쪽은 더 어두워지고 밝은 쪽은 더 밝아지는 것

http://cgmemo.blogspot.com/2010/09/photoshop-overlay-blending-mode.html

반투명 셰이더 완성

Tue, 06 Dec 2011 11:45:56 +0000

깔끔한 반투명 셰이더 완성!!!

포프 스승님 (http://kblog.popekim.com/) 께서 가르쳐 주신 방법으로, 나름 고안해서 만들어 봤습니다.
그림자까지 나오게 하느라 3pass를 써버리긴 했지만, 어쨌건 완벽하게 해결.

자, 그럼 문제는 내가 이걸 어떻게 짰는지 모르겠다는 ….

하하하하하하하하하하하하하하하하하하하하하핳하하핳

아니 어려워. ㅋ
셰이더만으로 렌더 오더 조정하는게 쉬운줄 알어 ㅋ ?

감마 코렉션에 대한 정리

Sun, 04 Dec 2011 14:36:38 +0000

감마 코렉션의 시작 (Gamma correction)

감마 코렉션은 원래 CRT에 이미지를 넣으면 약간 어두워진다 - 이유는 여기서 중요하지 않아요. 기계적 특성이라고 생각합시다 - 에서 시작한다고 합니다. 뭐, 그렇다고 알고 있기로 합시다. 이건 하드웨어의 문제니까요.

그렇지만 요즘엔 CRT를 안쓰잖아요? 그럼 상관 없는 것 아닌가?
… 그렇지만 여전히 CRT처럼 약간 어두어지도록 처리한다고 합니다.
이 이유는, 사람의 눈이 약간 어두운 쪽의 밝기 변화에 민감하기 때문입니다. 사람의 눈은 밝은 계조(다이나믹 레인지 : 음영값) 에는 둔감하고, 어두운쪽의 계조에는 민감합니다.

그렇게 따졌을 때, 출력하는 장치를 봅시다… 모니터나 출력물이나… 우리가 보기엔 뭔가 색이 부족해 보입니다. 아니 , 정확히 밝하면 밝기가 부족하지요. 우리가 인식하는 밝기 영역보다 훨씬 작습니다.
이것 때문에 HDR이라는 기법이 나온 거니까요.
참고자료 : 9강 camera advanced light2

그래서, 가뜩이나 부족한 밝기 영역, 윗쪽(밝은 쪽) 에 몰아버리느니 어두운 쪽(아래쪽) 에 몰아버리자… 라고 해서 여전히 모니터는 약간 어둡게 조절되는 것이라고 합니다.
http://shotgunlee.egloos.com/10607756
이것도 NTSC냐 PAL이냐에 따라 막 차이가 있고 막 이러는 것 같지만 여기선 더 파고들지 말도록 합시다…

어쨌거나 그래서… 모니터에 들어가는 이미지는 어차피 어두워질 것이므로 이것을 예상하고 , 모든 색상은 일단 밝게 올려 버리고 맙니다. 자동으로요. 이것이 Gamma correction 입니다. 하드웨어에서 알아서 처리하는 거지요.

어쨌건 결론 :
모니터는 약간 어둡게 나온다.(CRT Gamma) 그래서 원래의 느낌으로 나오게 하려면 감마를 조절해서 약간 밝게 이미지를 만들어야 한다. 이것이 감마 코렉션 (Gamma Correction) 이다. 이것은 자동으로 처리된다.
http://blog.naver.com/PostView.nhn?blogId=muskccat&logNo=120134811163&redirect=Dlog&widgetTypeCall=true

http://sv.wikipedia.org/wiki/Fil:Gamma06_600.png

컴퓨터 그래픽스에서의 감마 코렉션의 영향

그럼 모니터에서 어둡게 나온다는건 대충 알겠습니다. 그래서 각종 이미지들은 모니터가 어두워지는 만큼, 밝게 저장이 됩니다.
누가 해주냐? 그래픽 카드가 해줍니다. 아 - 주 편하게 자동으로 해줍니다

감마 코렉션 기능 완성!

Fri, 02 Dec 2011 18:02:14 +0000

포프님 도움으로 감마 코렉션을 적용하였습니다. 물론 그 외에도 많은 스승님들이 .. 개불아저씨와 티스님 빼고 …
도와주셔서 잘 완성할 수 있었죠.

이론적으로도 찾아봤는데 아직 이해가 안가는 점이 꽤 있습니다.
트윗에 물어보기에는 너무 길어서 블로그에 써놔야 할듯.

읽어보니 컴퓨터로 색 정보가 들어오면 어두워진다는데 (중간이 아래로 내려가는..) 이게 sRGB 공간인가요? 아닌가요? 반댄가?
출력할때도 어두워진다는데 그럼 이중으로 어두워지게 되는건가요? 아니면 밝게 들어온걸 어둡게 처리해서 리니어 해지는 건가요? 아 모르겠다.
근데 첨 색을 받아올때 pow(X, 2.2) 를 하는데 이건 더 어둡게 되는 것 아닌가요? 이걸 연산해야 리니어 공간으로 온다면, 그럼 첨에 들어올때 2.2 밝게 들어오는건가요…? 그럼 sRGB 공간이란 중간이 밝은걸 말하는 건가요?
연산 끝나고 pow(X,1/2.2) 를 하니까 다시 밝게 조정해 주는건데요. 조정해 주면 리니어 공간에서 밝은 공간으로 가는건데 이게 sRGB 공간인가요? @_@ 아 어지러.

하여간 일단 결과물은 이쁘네요.

움직이는 GIF인데 안움직이면 F5 해보셈.

어라.. 그래도 안움직이네염. 그럼 아래 두 그림으로 나눠 올려봄.

이쪽이 감마 코렉션 전 이쪽이 감마 코렉션 후

밝아 보이는게 이전 쉐이더 입니다.
슬쩍 봐서 어두워 보이는게 감마 코렉션 된겁니다.

-밝아보이는걸 보시면… 저 뚱뚱이 등이 하얗게 타버립니다. 디테일이 날라가죠.
가슴쪽이 빛때문에 변화하는 색 그라디에이션 변화를 보시면, 다이나믹 레인지가 부족해서 급격히 변화되는걸 볼 수 있습니다. 이게 잘못된 거죠.

-어두워져 보이는것이 감마 코렉션이 된건데, 비록 GIF라서 좀 거칠어 보이지만, 뚱뚱이 등 부분이 밝아졌더라도 제 색깔과 디테일은 다 나오는 것을 알 수 있습니다. 이게 당연하죠. 빛은 아무리 계산해도 1인데, 어두운 텍스쳐가 있는데도 날라갔다는건 결과물 자체가 최고값이 1을 넘어갔다는 얘기였으니까요. 지금 이게 정상.
가슴 부분에서 색 넘어가는 것도 이전보다 다이나믹 레인지가 훨씬 섬세해 진 것을 볼 수 있습니다. 전체적으로 어떤 느낌이냐면, 한 눈에 보면 부드러워 보입니다. 색상이 이전보다 훨씬 자연스러워요.
이젠 그동안 너무 날라가 버려서 -완전히 하얗게 타버려요- 쓸 수 없었던 블룸도 더 자연스럽게 쓸 수 있을듯 합니다. 완벽히는 아니어도. 그 외에도 좀 더 텍스쳐와 색상 선택의 폭이 넓어지겠네요.

물론 제대로 하려면 하드웨어에서 연산해야 최종적으로 올바른 결과물이 나오는데, 유니티에서는 3.5에 지원해준다고 되어 있으니 미리 만들어 넣을 필요도 없고, 소스 산 것도 아니어서 렌더러 뜯기도 좀 그렇죠. 이정도로 일단 참으려 합니다.

스승님 말씀대로, 이쁘면 장땡이지!!!

참고한 고리들

http://visualxock.tistory.com/entry/%EA%B0%90%EB%A7%88-%EC%BD%9C%EB%A0%89%EC%85%98GAMMA-CORRECTION

http://blog.naver.com/PostView.nhn?blogId=muskccat&logNo=120134811163&redirect=Dlog&widgetTypeCall=true

http://blog.naver.com/PostView.nhn?blogId=jade5210&logNo=150070616107

http://blog.naver.com/PostView.nhn?blogId=chst27&logNo=40125348685

테크니컬 아트 강의자료 올립니다.

Sun, 27 Nov 2011 23:39:59 +0000

게임아카데미와 사내에서 강의했던 테크니컬 아트 과목의 PT자료들을 올립니다.
외부 공개되면 곤란한 것들은 모두 삭제된 버전이므로, 중간중간 이상하게 훵 - 하거나 끊어진 것이 있을 겁니다 :)

일반적으로 이론인데 … 이론만 하면 쓰러지는 친구들이 많아서 실습도 넣은거라 중간중간 실습 강의도 보일겁니다.

그리고 또 제가 그동안 공부하면서 정리한 내용을 강의한거라… 제가 제대로 알고 있지 못하거나 틀렸거나 변화되었거나 추가된 것이 있을 수도 있습니다. 그럴 경우에는 너그럽게 봐주시고 지적해 주시면, 다음 강의때 업그레이드 할 수 있어서 매우 도움이 될 것 같습니다.

1강의 회사 소개와 TA의 작업 내역 같은 강의라서 … 전부 기밀문서입니다. 그래서 1강은 삭제. 2강부터 올립니다.

2강 텍스쳐 포맷과 기초 / 오타수정

View more presentations from jpcorp

3강 shader fx 기초실습_텍스쳐 조작

View more presentations from jpcorp

4강 shader fx 기초실습_텍스쳐 조작2

View more presentations from jpcorp

5강 알파와알파소팅

View more presentations from jpcorp

6강 light shadow 기초

View more presentations from jpcorp

7강 shader basic lighting_배포용 삭제버전

View more presentations from jpcorp

8강 camera advanced light

View more presentations from jpcorp

9강 camera advanced light2

View more presentations from jpcorp

10강최적화 가속화

View more presentations from jpcorp

2강 텍스쳐 포맷과 기초

Fri, 25 Nov 2011 17:19:54 +0000

2강 텍스쳐 포맷과 기초

View more presentations from jpcorp

..이거 바로 화면에 나오게 하려면 어떻게 해야 해요?

삼품 타격감 강화계획1- 카메라 각도 수정

Mon, 21 Nov 2011 11:34:41 +0000

타격감 강화라는 제목이지만…
사실 QB 시트를 봤을때도 느꼈지만, 단순히 ‘타격감’ 이 적어요 라는 의견들은 아니었습니다.
제 의견도 그렇지만, 사실 그 안의 속뜻은 ‘전투가 간지가 안나요’ 라는 뜻이지요.

게다가 타격감이라는게 뭐 하나 뿅 올리면 뿅 올라가는게 아니라는게 큰 문제. 사운드와 그래픽과 이펙트와 카메라와 게임 스타일까지 모두 연관되는거라, 누가 쉽게 건드리기가 쉽지 않은 분야이기도 합니다. 때문에 사실 타격감이 적다는 얘기는 그냥 간지가 안난다는 얘기와 동질급.

어쨌건 타격감 올리는것은 UI와 꽤 비슷한 면이 없지 않아서, ‘감성적이고 섬세한 조작’ 으로 효과의 호불호가 갈린다는 말입니다.
뭐, ‘마리오의 점프가 그 정도 높이와 시간인게 가장 [기분좋은 정도] 이기 때문에 성공했고, 많은 성공한 게임들의 [점프]의 시간과 높이가 거의 비슷하다’ 라는 논문이 있을 정도니까요.

이 부분은 시간도 많이 걸리고 삽질도 꽤 해야 합니다… 경험이 필요한 분야인데 이거 경험을 많이 해 본 사람이 있는 것도 아니고…

하지만 그렇다고 무한대의 시간에 무한대의 삽질을 할 수도 없습니다. 그러므로 결국은 취사선택을 해야 한다는 것인데…

일단, 뭘 하기 이전에 기본적으로 간지안나는 카메라 각도부터 좀 수정하고 갔으면 합니다.

지금의 카메라 각도는 마치 탑 뷰와 마찬가지로, 조작의 쾌적성을 위해 모든것을 희생한 모양을 하고 있습니다.
아니, 그 전에 왜 카메라의 시작점이 저 모양이지요?
전투를 처음 시작할때의 화면은 그 게임 전투 전체의 첫인상이라고 해도 과언이 아닐 만큼 중요합니다.
그치만 이 전투 화면은 뭘까요?
어디가 중심인 건가요?

뭔가 기울어져있고, 불안하고, 간지나지도 않고 만들다 만 것 같습니다.

그리고 너무 머리 위를 비추다 보니, 캐릭터의 실루엣도 문제가 있습니다.
이런 식으로.
주인공은 형태도 알아보기 힘들 정도이며 다른 캐릭터도 마찬가지입니다. 탑뷰의 가장 큰 나쁜 점인, ‘형태가 제대로 느껴지지 않는다’ 의 문제가 나옵니다. 이래서야 어디가 몸이고 머리인지 본능적으로 느끼기 힘들기 때문에 (우리는 사람들 머리 위를 보는데 익숙하지 않거든요 ) 캐릭터의 매력은 감소하고, 액션을 하더라도 눈에 제대로 들어오지 않아서 타격감이 줄어들 수 밖에 없습니다.

이건 카메라를 기울이고, FOV를 조작해서 멋진 뷰를 만들면 됩니다.
그렇지만, 그렇다고 조작성을 희생시킬 수도 없지요.
뭐 적당히 타협하는 각도는 분명히 있습니다. 적당히 보수적이면서 적당히 멋져 보일 정도로요.

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

이게 제안하는 뷰입니다.

FOV는 무려 20도 !
기존의 것이 30도였던데 비해 더 보수적이고 평면적인 각도입니다.
렌즈로 따지면 120mm 렌즈에 버금가는 망원렌즈입니다.

각도가 60도에서 45도 정도로 바뀌었습니다.
기울이니까 좀 더 앞이 보이면서, 답답함도 줄었습니다. 기울어지면 조작성은 줄어드는데,
FOV를 줄였으므로 조작성이 올라갔으므로 결론적으로는 이전과 크게 차이가 없어졌다고 보여집니다.
거의 완전하게 옛날의 쿼터뷰 모습의 게임처럼 되었지요.

그리고 중심도 옮겨갔습니다.
중심은 여기를 기준으로 하면 됩니다. 처음 시작에는 말이죠. 간단해요. 어차피 우리 장수들은 그리 많이 늘지 않을테니까.

사실 더 많은 아이디어가 있습니다. 처음에 시작할때 역동적으로 시작하는 아이디어 말이죠 …
카메라가 적진으로부터 쏴악 빠지면서 우리 진형쪽으로 빠지면서 줌아웃되면서 전투화면이 되는…
이건 나중에 전투의 박진감을 올려야 할 때 필요합니다. 일단 자제.

그리고 캐릭터의 실루엣도 좋아졌습니다. 박진감 넘치는 애니메이션이 더 잘 보이게 하기 위해서도 역시나 기울어진 뷰가 제격입니다. 탑뷰에서는 가로로 휘두르는 것 밖에 제대로 보이지 않거든요.

당연하게도 캐릭터의 실루엣도 꽉 차고, 안정적으로 보입니다. 아까는 영웅형인지 호남형인지 솔직히 잘 알 수 없었습니다만,
지금은 호남형이라는걸 확실히 알 수 있겠지요.

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

일단 위의 것은 바로 적용했으면 좋겠습니다.
그리고 나중에 타격감 작업 후 추가로 작업했으면 하는 것은

시작할때과 끝날때 카메라 워킹 추가
휠 굴렸을때 어떻게 되게 할까?
정도.

유니티에서 Package Import가 안될때

Sat, 19 Nov 2011 11:52:49 +0000

회사에서 Asset Store 결재가 안되길래 집에와서 결재했는데, 결재는 성공했는데 다운로드가 안돼?

보니까 패키지를 임포트 할 때 오류가 나는거다. 이유가 뭘까.. 하고 별 짓을 다 하고 찾아봤지만
아예 다운로드한 패키지의 압축을 풀지 못하는거다.

근데 회사에서는 또 패키지가 압축도 잘 풀고 임포트도 잘 돼 … OTL

그래서 회사에서 패키지를 가져다가 집에서 압축을 풀어보니까 역시 안돼 … OTL

삽질끝에 정답을 찾았다.

…. 패키지가 있는 폴더 경로명중에 한글이 있으면 안된다… D나 E에 넣고 하니까 바로 열림.

야 이 민ㅇㅁ ㄴ야램ㅎ ㅣㅁ넝라ㅓ모아ㅓㄹ마ㅓㄴㅇ리마ㅓ농ㅎ머ㅏㄴㅇ리ㅏㅓㅁ농ㄹ
프로그램짤 때 유니코드 지원은 필수 아니냐 이놈들아.

strumpy shader editor tut

Sat, 19 Nov 2011 10:54:24 +0000

언리얼이나 유명 엔진의 그것과 같이, 유니티에서 노드 구조로 쉐이더를 짤 수 있게 해준다.
어셋 스토어에서 다운받을 수 있고, 무엇보다 무료다!

그렇지만 아직 채널 분리 컨트롤이 안되(는듯 싶)고 ,
나온 결과물의 쉐이더 코드가 좀 지저분한 편이다. 변수선언도 너무 많고…

그렇지만 교육용이나 간편하게 선행 테스트 해보기에는 좋은 툴이며 앞으로의 발전이 기대된다.
(그래도 아직 걍 코딩하는게 편하고 빨러 … ㅋㅋ)

Shader Editor Beta 4 from Tim Cooper on Vimeo.

light 기초

Fri, 18 Nov 2011 00:44:16 +0000

6강 light shadow 기초

View more presentations from jpcorp

아카2의 타격감 / 액션감 증가를 위한 기술적 제안 내역

Wed, 16 Nov 2011 15:11:52 +0000

일단 긴글

액션 카메라 컨트롤 시스템

보스를 만났을 때, 막타를 때릴 때, 커다란 스킬을 쓸 때 등에서 턴제 게임에 어울리는 카메라 연출이 들어가야 합니다.
턴제 게임에서 역동적인 카메라 연출이 ‘힘들고 다른’ 것이지 ‘불가능’ 한 것이 아닙니다.

그리고 이 카메라 연출은 액션게임의 그것과 같은 수준의, 트리거 시스템에 연동되는 섬세한 카메라 조작 툴이 필요합니다.
툴 제작 외에 따로 도입하거나 연구하여야 할 기술 과제는 없으며, 툴 제작 없이 인력만으로도 가능한 분야이긴 합니다.(효율이 낮지만) 적절한 툴의 개발과, 이를 이용한 수작업이 필수로 보입니다.

2. 타격시 렉돌(Ragdoll)을 포함한 물리 시스템

타격시 타격감을 향상시킬때 쓰이는 기능의 예상되는 일람은 다음과 같습니다.

캐릭터를 띄워서 날려 보낼 수 있다.
강/약에 따라 캐릭터가 날라가던가, 밀리던가 등의 변화가 있다.
캐릭터가 날라가서 주변과 상호작용 할 수 있다.
캐릭터의 관절이 절차적 애니메이션 (procedural animation) 을 통해 자동으로 애니메이션이 생성된다.

이를 위해 캐릭터와 오브젝트들의 다이나믹한 상호작용을 위해 물리 시스템의 추가가 필요합니다.

일반적으로 캐릭터를 날려 버리는 것은 기본으로 내장되어 있는 피직스 시스템으로 충분하지만,
자연스러운 캐릭터 애니메이션을 위해서는 렉돌 피직스 (Ragdoll physics : 주로 캐릭터의 죽는 모습에 사용되는 절차적 생성 물리 시스템) http://ko.wikipedia.org/wiki/%EB%9E%98%EA%B7%B8%EB%8F%8C_%ED%94%BC%EC%A7%81%EC%8A%A4 기능이 추가로 필요합니다.
렉돌을 직접 만져 보시려면 http://www.planetdan.net/pics/misc/tetka.html 에 가 보세요. 캐릭터를 집어서 던질 수도 있습니다.

2-1 렉돌/물리를 사용하기 위한 클라이언트 기술적 요구사항 - 축약된 기능구현으로 해결.

턴제라는 게임의 특성상, 렉돌의 자유도를 100% 로 할 이유는 없어 보입니다. 렉돌 피직스의 각종 변칙적 요인들은 다양한 상태의 물리 소스에서부터 비롯되는데, 실시간 전투라면 다양한 공격이 다양한 경우에 발생할 수 있지만 턴제 전투에서는 물리적 벡터 자체가 한정적이고 변수가 거의 없다시피 하므로, 미리 힘을 규격화하여 계산해 놓고, 이를 이용하는 방식을 사용하는 등으로 예상치 못한 변수를 줄이고, 화면을 제어할 수 있을 것으로 보입니다.

단, 클라이언트 상에서 지형과 오브젝트들의 3차원 충돌처리를 해 놓아야 하며 이는 지금도 가능한 상태입니다.
기타 사소한 문제들이 예상될 수 있지만 대부분 극복 가능한 수준이며, 어느 정도의 시행착오만 필요할 것으로 예상됩니다.

그래픽적으로는 , 관절이 꼬이는 candy wrap 현상등이 일어날 수 있어서 이 부분을 개선해야 하나. 사실상 화면에 보여지는 캐릭터의 사이즈로 볼 때 개선하지 않아도 별 문제가 없으리라 보여집니다.
또한 렉돌의 영향에서 벗어나 있는 망토와 머리카락등의 물리 기술은 따로 개발하여야 합니다.
고급 기술로 망토와 같은 천을 리얼하게 움직이게 할 수 있는 Cloth physics 를 사용할 수 있지만, 이번 경우에는 사용하지 않고 bone을 이용한 물리 기술로 응용하여도 충분할 듯 합니다. (물론, Cloth Physics 를 먼저 검토해볼 예정입니다)

2-2 렉돌/물리를 사용하기 위한 서버 기술적 요구사항 - 기존대로 2D로 동작. 변화없음.

턴제라는 게임의 특성상, 공격할때의 물리적 벡터가 충분히 예측 가능하므로 다소 변수가 있더라도 대부분 큰 문제없이 계산할 수 있을 것으로 보입니다. 물론 기울어진 언덕 등으로 인해 예측과 다른 현상이 일어나더라도, 서버는 기존대로 2D 동작해도 상관 없을 것으로 보입니다.

캐릭터가 죽었을 때는 서버는 계산할 필요 없이 클라이언트 단에서만 물리 표현을 하고 끝내면 되며,
캐릭터가 날라간 후에 죽지 않고 다시 살았다 하더라도 서버에서는 이동한 (이동했으리라 생각되는) 위치만 미리 점유하여 가지고 있다가 날라간 캐릭터가 다시 일어나 그 셀로 걸어오면 문제 없습니다.
이렇듯, 완전한 실시간 액션게임보다는 조금 못하겠지만 간략화된 기술로 게임의 특성에 어울리는 충분한 효과를 낼 수 있으리라 보여집니다.

2-3. 렉돌 사용에서 예상되는 문제사항 및 결론 - 사용 가능.

기획적 문제 :
타겟 캐릭터가 위치를 이동해 버림으로써 생길 수 있는 기획적 문제. 이건 팀장이 정리중입니다.

퍼포먼스 문제 :
정확하게는 조사를 해봐야 알겠지만, 분명히 부하를 유발합니다. 사양이 예상보다 높아질 수 있으며, 저사양 또는 물리엔진이 돌아가지 않는 환경에서는 어떻게 표현할 것인지 연구해 볼 필요가 있습니다.

기타 예상하지 못한 문제들 :
물리 시스템의 렌덤성으로 인해, 예상하지 못한 움직임을 보이는 경우가 생길 수 있습니다. 이런 경우를 위해 시행착오의 시간이 필요할 듯 합니다.

Oren-Nayar Lighting Model

Wed, 16 Nov 2011 11:47:02 +0000

출처: 렐릭의 포프님!!
공개하셨다길래 무의식중에 일단 퍼왔…

Oren-Nayar Lighting Model

We used a lookup texture for optimization for a while
( http://content.gpwiki.org/index.php/D3DBook:(Lighting)_Oren-Nayar )

●

half computeOrenNayarLighting_TextureLookup( half3 N, half3 L, half3 V, half roughness )
{
half LdotN = dot( L, N );
half result = saturate(LdotN);
if ( roughness > 0 )
{
// compute the other aliases
half VdotN = dot( V, N );
half gamma = dot( V - N * VdotN, L - N * LdotN );
half rough_sq = roughness * roughness;
half A = 1.0 - 0.5 * (rough_sq / (rough_sq + 0.33));
half B = 0.45 * (rough_sq / (rough_sq + 0.09));
// The two dot-products will be in the range of
// 0.0 to 1.0 which is perfect for a texture lookup:
half2 tex_coord = half2( VdotN, LdotN ) * 0.5 + 0.5;
half C = tex2D(gOrenNayarSampler, tex_coord).x;
result *= (A + B * max(0.0, gamma) * C);
}
return result;
}

Oren-Nayar Lighting Model

But we made it even faster with an approximation

●

Practically, we didn’t notice any badness from this

●

half ComputeOrenNayarLighting_Fakey( half3 N, half3 L, half3 V, half roughness )

{

// Through brute force iteration I found this approximation. Time to test it out.

half LdotN = dot( L, N );

half VdotN = dot( V, N );

half result = saturate(LdotN);

half soft_rim = saturate(1-VdotN/2); //soft view dependant rim

half fakey = pow(1-result*soft_rim,2);//modulate lambertian by rim lighting

half fakey_magic = 0.62;

//(1-fakey)*fakey_magic to invert and scale down the lighting

fakey = fakey_magic - fakey*fakey_magic;

return lerp( result, fakey, roughness );

}

캬오

Tue, 15 Nov 2011 11:52:39 +0000

캬오

위대하신 대마왕 개발자J 의 프로필 사진 (그림이 아님).

이미지 저작권 따위 없으니 널리 퍼뜨려 찬양할 지어다

오늘의 사내강의

Tue, 15 Nov 2011 00:43:56 +0000

오늘은 라이팅에 대한 이론강의였습니다.

거기 졸지마.

이힛

회사는 조쿠나

Tue, 15 Nov 2011 00:41:09 +0000

회사에서 먹을것도 주고 재워도 주고 (난 기숙사 안쓰지만) 입혀도 줍니다 에헤야 디야.
그리고 가끔 뮤지컬 등 문화생활도 즐기게 해주고

정서함양을 위해 음악CD도 주네

게다가 아직 공개도 안된 게임을 지하철에서 테스트할 수 있게 해 주고

여행도 보내주는군요. 에헤라디야.

캠핑카 여행기 / 굿타임캠핑카 별이타고 여행하기 4부

Wed, 09 Nov 2011 00:21:09 +0000

아침이 되었습니다. 역시 비는 안옵니다. 예에이이이이이!!!! 존경스러운 기상청님들 ㅠㅠ

아니 그냥 기분만 그랬다고요 기분만.

이불 개고 정리하고 테이블 모드로 변신.

소박한 여행지에서의 가족 아침식사. jpg

가스레인지 화력이 세니까 요리를 할 만 합니다. 속도도 빠르고.

전기랑 물 체크. 이상없습니다.
보일러도 다시 온수전용 모드로 .

날씨가 정말 안추워서 , 설겆이 하러 나왔습니다. 아무래도 좀 더 넓은데서 하는게 편하긴 편하죠. 물도 별로 안차갑고. 음식물 쓰레기통도 같이 있구요.

전부 개방하고 환기중인 별이가 보입니다.
오늘은 일단 씻고 정리한 다음에, 어제 다 못본 전시관을 돌 예정입니다.

모닝커피로 정리를 끝냅니다. 자 슬슬 씻으러 움직입시다…

수돗가 근처로 가면 물을 채우기도 편한데다가, 배수구에다가 차를 세우면 물 빼기도 쉬우니까요.

역시 캠핑카의 장점은 이런 것.

출발하는데 어라. 비옵니다 ㅋㅋㅋㅋㅋ
놀 거 다 노니까 비와 ㅋㅋㅋㅋㅋㅋㅋㅋ
타이밍도 기가 막히지 ㅋㅋㅋㅋ

나는 럭키가이 ㅋㅋㅋ

비가와도 걱정없습니다. 오히려 배수로를 안찾아도 되니 좋긴 한데,
버릴 물 양이 좀 많으니 이동하는게 좋긴 하죠.
비도 좀 오는가 싶더니 곧 보슬비로 바뀌더군요.

배수로에 차를 맞춰 대고

힘차게 배수합니다! 저기 보이는 레버를 밀어 넣으면 배수관이 잠겨서 물이 나오지 않습니다.
배수할때는 저 레버를 당기면 되는 거지요.

물통 양에 비해서 오수통의 용량이 훨씬 작기 때문에 수시로 배수해 주는걸 잊어서는 안됩니다 .

이렇게 씻기까지 끝내니 또 비가 잠깐 그치네요.
차를 몰고 체험관 가까운 곳 까지 옵니다. 역시 이런게 캠핑카의 장점.

흔한 반도의 선행학습.jpg

아참. 전기도 연결이 안되지만 이 캠핑장의 가장 큰 장점은 와이브로가 잡힌다는 것 ㅋ
덕분에 인터넷은 신나게 했지요.

자 이제 관람하러 가지요.

여전히 비는 보슬보슬

날씨가 맑았으면 여길 돌아다니면서 놀았을텐데 말이죠.

동상을 지나 관람실로 갑니다.

근대 문물이 들어오면서 들어온 최초의 전차.
어엇. 센프란시스코에서 봤던 케이블카와 구조가 완전히 똑같다는게 놀라움.
고종황제 밀납인형이 있습니다.

요기 얼굴이 제일 잘 보이는게 이완용.
그리고 저기 깊이 앉아 있는게 이토 히로부미
그러니까 이게 을사조약이고, 저게 을사 오적들이로군요. 아 막 가물가물하려고 그래.

제가 그래서 미래가 없 …
을까봐 여기 왔습니다.

아이들에게 알려줘야 할 사실들.

전시장은 생각보다 다양한 매체로 잘 되어 있습니다.

4관이던가? 3.1 운동에 대해 설명하는 전시관인데, 연출이 무척 괜찮더군요! 그 때 그 상황을 긴장감 넘치게 설명하면서 멋지게 만들어 놓았습니다. 독립기념관 전시관이 이렇게 연출이 좋았던 곳이었던가…

나름 체험관도 있습니다 ㅎ 아이들이 좋아하네요

이봉창 의사. 왠지 즐거운 얼굴입니다.

오오 ‘도시락 폭탄’ 의 윤봉길 의사.
요새 많이 헷갈리시죠. 도시락이 이분입니다. 미남이십니다.

그래도 의사중 최고의 간지는 백정기 의사 (…) 뭡니까 저 포스는.

어렸을 때 이것만 봤던 기억을 보통 가지고 계시지요. ‘그게 33인이던가 …?’ 라고 기억하던 밀납인형이요.
척 봐도 33명은 넘습니다. 임시정부 요인 상이군요.

닭살돋는 스토리의 4D 입체상영관이라는데, 어제들 봤으니 패스.

간만에 봐서 그런지. 꽤 흥미진진했습니다.
보통 이렇게 옛날에 만들어 놓은 것은 요즘 수준으로 보면 많이 유치해야 정상일 것 같은데 말이죠.
생각보다 매우 만족.

자 이제 슬슬 돌아갈 시간입니다 .

경부고속도로의 일요일 오후라. 종잡을 수 없지요. 위험합니다 .

그래도 점심은 먹고 가야겠길래…

천안에 있는 화덕피자집이라는 시뇨레를 재빨리 검색해서 슝슝.
회나 고기를 먹으러 갈까 했는데, 고기를 어제 너무 많아서 이런 음식이 땡긴다는군요 ㅋ

난데없이 매장 창문을 다 가려버리는 캠핑카의 등장에 놀라워하는 종업원 분들.

죄송합니다. 이정도로 가리고 싶진 않았는데…

어머나 샐러드가 푸짐하기도 하지.

빵으로 덮여진 스프. 빵이 맛있습니다 :)

거대한 피자 등장 ㅋ
오오 과연. 기름기 하나 없이 깔끔한 화덕피자의 전형적인 모습을 보여주고 있습니다.
도우까지도 바삭대면서 가볍게 먹을 수 있네요.

한 장 더 ㅋ

스파게티의 양이 굉장히 많습니다.
맛은 , 애석하게도 별 특징이 없는 느낌. 피자는 훌륭했는데 스파게티는 좀 아쉽네요.
면이 알 덴테가 아니라 너무 익혀졌고, 토마토 소스도 평범한게 좀 아쉬웠습니다.
그래도 전체적으로는 가격대비 좋은 맛!

아아 역시… ㅠㅠ 올라오는 길은 지옥같았습니다.
내 다시 주말에 경부고속도로를 이용하나 봐라이ㅏㅁㄴ 아ㅓ뫄ㅓ마넝롸ㅓㄴㅇ라ㅓㅇ니망리ㅓㅀ;ㅣㅓㅁ 리

일찍 출발했기에 망정이지 더 여유부렸으면 아마 늦었을 거예요.
마지막 휴게소에서 마지막으로 쓰레기를 비우고, 청소하고, 짐을 챙기고 난 후 겨우겨우 30분 전에 도착!

이렇게 두 번째 캠핑카 여행을 끝마쳤습니다 :)
여전히 이번에도 꼼꼼하게 챙겨주신 굿타임 캠핑카 사장님 감사합니당.
그리고

… 차 좀 그만 닦으세요 ㅋㅋ 이거 원 더러워질까봐 미안해서 차를 탈 수가 없어 ㅋㅋㅋ
뿅.

캠핑카 여행기 / 굿타임캠핑카 별이타고 여행하기 3부

Tue, 08 Nov 2011 23:08:35 +0000

가족들이 돌아왔으니, 본격적으로 캠핑을 시작합니다.

능숙하게 불을 붙입니다. 초보자라는 것을 아이들에게 들켜선 안돼!

오오오오 잘붙는다.

나무가 상당히 건조가 잘 되어 있습니다. 좋네요 이거.

음식이 준비되기를 기다리지 못하고 소세지를 구워먹는 김모양(33)

불이 아직 잦아들지도 않았는데 성급하게 고기구울 준비중입니다.

와와와와와
집에서 양념해온 돼지고기가 구워집니다.
평소에는 돼지냄새난다고 못먹던 마나님도 만족해 하는 맛!

꽤 많이 가져갔다고 생각했는데, 저 고기를 다 먹어 치웠다지요.
역시 밖에서, 그것도 숯불로 굽는 고기의 맛은 각별합니다.

슬슬 불도 좋아지고 있습니다. 은박지를 안가져갔고 고구마도 저것뿐이라 고구마 구워먹는걸 못한게 조금 아쉽.

금방 어두워 지는군요. 어닝 아래 달린 LED 불빛은 다른 집의 조명에 비해 월등히 밝습니다.
다들 배고파서 허겁지겁 먹느라 사진이 없어유. ㅋㅋㅋ

무한도전 감상중. 소리가 작아서 아이패드 2대를 동원해서 보는 중.

그 사이 마나님의 한약은 데워져 가고…

아 배부르고 좋다. 별로 춥지도 않네. 딱 시원한 정도….

… 누가 오늘 비온댔어…

이렇게 어두워져 갑니다.

캠핑족들이 하나 둘씩 채워져 캠핑장도 꽤 북적대고 있네요.

달무리가 진 걸로 봐서 낼도 맑은건 아냐 이거?

다른 캠핑카들도 몇 대 보입니다. 하지만 다들 시에스타. 저번에 저희가 몰았던 바람이와 같은 모델이고, 오페라 V9은 저희뿐.

슬슬 잘 시간이 다가오는군요.

그래도 잔불정리 할 때까지는 잘 수 없습니다. 전날 비가 좀 내린 후라 땅이 촉촉하게 젖어서 불 날 일은 없겠지만 그래도 말이죠.

차 안에 들어갈 일이 없을 것 같아서 낮에 미리 침대모드로 변신시켜 놓았습니다.

저 테이블만 낮추면 끝나죠.

역시 저 레버를 젖히고 당기면

쉽게 접힙니다.

이걸로 다 끝났다고 해도 과언이 아닙니다.

바닥 쿠션을 가운대로 옮기고, 벨트를 정리하고..

바닥 쿠션을 끼워 놓은 다음

등받이를 바닥에 맞춰 깔면 훌륭한 침실이 됩니다. 성인 4인이 약간 어깨 닿으며 잘 수 있는 크기예요.
짧은 쪽은 170 정도 되시는 분까지 허용 ㅋ

2층을 펴면 다시 3인 정도 잘 수 있는 공간이 마련됩니다.

2층은

이렇게 쑥 펴고 메트리스만 깔면 끝.

짠.

왼쪽에 나무 사다리도 보입니다. 아이들이 올라가기 좋겠네요 .
170이 좀 넘는 저한테는 살짝 기울거나 다리 벌리면 잘 수 있는 정도의 길이입니다.

재미있게도, 저 끝에 히터 온풍구가 있습니다. 이것 역시 주인아저씨의 개조작품.
이용해 본 바에 의하면 발이 따땃해져서 상당히 좋다는군요.

2층 벙커베드 안쪽에서 보면 저런 것이 보입니다. 옆에 등이 있고, 시거잭 구멍, 그리고 220V 외부전원 연결시에 사용할 수 있는 전기 콘센트, 그리고 전동 프로젝터스크린.

반대쪽은 귀여운 모니터가 있어요 ㅋㅋ TV와 같은 장면이 나옵니다.

덕분에 2층은 아이들 차지.

차의 서스펜션이 단단한 덕분인지, 2층에서도 차가 그렇게 출렁이지 않습니다. 바람이를 몰았을 때는 2층이 너무 출렁대서 무섭다고 거부했던 아이들이 , 별이의 2층 침대는 매우 만족하는군요.

주인아저씨가 엄선해서 빌려주신 DVD 감상중.
차 안에는 저렇게 앞 부분을 가릴 수 있는 천도 들어 있습니다. 이것도 역시 커스텀 개조품.

저는 잔불처리하고, 짐을 다 정리해 놓습니다. 어닝도 접구요. 밤에 어떻게 바람이 불어서 뒤집어질지 모르니… 아저씨가 저거 고장나면 비싸다고 겁줬 (…)

내일은 정말로 새벽부터 비올지 모르니 확실히 정리해 두는게 좋겠지요.

물도 빵빵하게 채워놓고, 보일러도 가동시키고, 혹시나 전원 모자랄까봐 공회전도 30여분 시켜 놓고, 추가로 물 한통 더 떠다가 조수석에 올려놓았습니다.

다른 집은 캠핑오면 아빠가 설겆이까지 전부 다 한다는데 저희는 그것도 안하니 이런거라도 충실히 해야죠 . (노년에 구박 안당하려면)

다른 집들도 슬슬 자러 들어갑니다. 조용해 지는군요.

정리가 끝났으니 들어와서 문잠그고 잘 준비 합니다.

으헉. 이게 아저씨가 자랑하던 별이의 트루마 보일러군요.
곳곳에 있는 저 흰색 히터 구멍에서 지옥의 불길을 연상시키는 열기가 나옵니다. ㄷㄷㄷ
너무 더워서 4단으로 내려서 잤습니다. 확실히 겨울에도 충분할 듯.

이렇게 밤이 저물어 갑니다.
정리하면서 장노출 야경 설정사진 찰칵.
안녕히 주무세요.

캠핑카 여행기 / 굿타임캠핑카 별이타고 여행하기 2부

Tue, 08 Nov 2011 22:29:32 +0000

차량 왼쪽을 둘러 보겠습니다. 아 빨리 다 열어보고 싶어서 두근대는군요. 하악하악하악하악

변태 맞는듯.

물 주입구입니다. 이건 이전에 탔던 바람이와 동일하군요. 열쇠로 열고, 힘차게 눌러서 돌리면 빠집니다.

뿅.

물탱크에는 약 120리터쯤 들어간다고 하시던데, 아쉬운점은 물을 채우면서 얼마나 채워지고 있는지를 알 수가 없다는 겁니다.
한 통 채우고 차 안에 있는 게이지 체크하고, 다시 한 통 채우고 체크하고.. 좀 귀찮아요.
그래서 채우다가 많이 넘쳤지요. 밖에 작은 게이지라도 있으면 좋겠…

물 주입구 옆에 있는 보관함에는 물을 나를 수 있는 물통과 기~~~인 물 호스, 그리고 전기를 길게 연결할 수 있는 전기 릴선이 들어 있습니다. 역시 조명등도 안에 보이구요.

물통을 빼내면 물호스가 있어서, 수돗가가 옆에 있다면 바로 물을 공급할 수 있습니다.
그치만 역시 얼마나 채워지고 있는지는 안에서 누가 봐주지 않는 한 모른다는게 문제.

그 오른쪽에는 주유구가 보입니다 .당연히 디젤.

마지막에는 화장실 관련 함 들입니다
위에는 화장실용 물 주입구 (샤워용 아닙니다. 순수하게 화장실 변기용)
아래는 화장실 오물함입니다.

물 주입구는 이렇게. 물론 게이지 같은건 없습니다.

걍 넘칠때까지 따르면 됨.

아래도 역시 열림으로 돌려서

눌러서 엽니다.

뭐 이건 똑같군요. 표준인듯.

노란 레버를 들어 올려서 빼면 빠집니다 .

단, 화장실 안에서 중간 밸브를 열어 놓은 상태면 안빠집니다. 화장실 중간밸브가 닫혀 있는지 확인 필수.

요렇게 빠지죠.

그리고 저기를 돌려서 뚜껑을 열고.. 처리하면 되는 겁니다.

응? 오물통 빼낸 자리에 왠 로션같은게…?

아항. 냄새 제거제입니다. 오물처리한 후에 오물통에 소주컵 반컵 정도를 넣어주면 냄새가 사라집니다.

하지만, 화장실 안쓸거임. 비상시라면 모를까, 멀쩡히 화장실이 옆에 있는데 쓸 이유가 없지요 후후후.

뒷면에는 자전거 캐리어가 보입니다. 2대까지 실을 수 있지만, 안가져왔지요.

이렇게 차량을 점검하고 있는데, 독립기념관 승마순찰대 분들이 몰려와서 이것저것 질문하십니다.
이분들은 차량이 신기하고, 저는 말이 신기하고 막 이런 분위기.
이렇게 많은 말에 둘러쌓여본건 처음이었구만유.

자 이제 어닝을 펼칠 차례입니다. 현재 날씨는 약간 흐린 정도. 혹시나 비가 올 때를 대비해서 미리 펴 놓는 것이 좋겠지요.

어닝을 펼치기 위해 일단 대문을 열고 … 화장실 문이 보이네요…

신발 벗고 이용하는 겁니다. 신발 신고 돌아다니시면 안돼요

요 쪽에 신발장이 있으니까요.

오른쪽에 현관 등과 어닝램프 스위치가 보입니다.

그리고 그 옆에 수줍게 숨어 있는 어닝 (차양막) 펴는 도구.

그리고 그 위에는 이번에는 쓸 일이 없는 프로젝터 스크린 스위치가 있습니다.

저겁니다 저거. 돌돌돌 돌리면 어닝이 펼쳐지지요.

손이 닿을 만큼 펼친 다음에

끝에 달려있는 다리를 들어서

요렇게요.

내려서 세워준다음 적당히 높이 맞추고 잠궈줍니다.

짠. 대충 3미터까지는 나옵니다.

힘을 받기 좋게 하기 위해 약간 다리를 안쪽으로 해주는게 좋구요. 비가오면 한 쪽을 기울이는게 좋습니다.

저는 저 평상처럼 생긴걸 조리용 테이블로 이용하기 위해 이런 이상한 모양으로 폈지요.

저는 캠핑장비를 하나도 가지고 있지 않은 뉴비인 관계로, 이번에 테이블 세트와 화로세트를 추가로 대여했습니다.
이렇게만 대여하면 일단 아쉬울건 없지요.

조수석 뒤에 넣어주셨군요.

의자와 테이블 조립하고, 화로대 조립하고, 나무 쌓아 불붙일 준비도 해 놓습니다.

불 붙이는 법도 배워서 온 나는 개초보 캠핑족.
나무는 첨부터 많이 쌓으면 불이 너무 크게 오르겠지요. 적당히 꺼내 놓습니다.

외부 준비가 끝났으니, 이제 슬슬 실내를 체크해 볼 차례군요.

대문을 열고 안으로 들어갑니다. 저렇게 생겼습니다. 좌측 끝에 전자렌지와 냉장고도 보이고, 가운데 테이블도 보이고… 왼쪽 앞에 리모콘 한식구들이 보이고, 오른쪽엔 모니터와 AV 시스템이 있습니다.

반대쪽으로 보면 이렇지요. 왼쪽에는 수납장과 컨트롤 판넬, 가운데는 주방. 오른쪽엔 화장실과 전자레인지 / 냉장고 / 보일러가 보입니다.

지난 여행의 경험을 되살려, 기본으로 들어있지 않은 (아쉬운) 것들을 챙겨왔습죠. 우후후
목장갑 하나 있으면 좋구요. 멀티탭 하나 있으면 좋습니다.
그리고 USB 충전기 가능한 포트 가지고 오면 좋지요. 일단 우리 식구는 아이폰 3대에 아이패드 2대니…

근데 화로세트를 빌리니 거기 안에 목장갑이 있어 OTL
그리고 멀티 돼지코를 가져왔는데 인버터 작동스위치에 걸려서 안들어가 OTL

좌/우 보조램프는 말그대로 양쪽 창문 위의 LED 등입니다. 이것만으로 충분히 밝아요.
메인램프는 가운데 달린 조명이고.. 화장실 조명도 있구요.

12V 는 시거잭입니다. 지금 24핀 충전기가 있지만 저희같은 아이폰족들한테는 무용지물.
220 전용은 외부 전기가 연결되었을때 사용 가능한 220V 콘센트인데요, 이번에 우리는 무용지물이죠.
인버터는 역시 220V 콘센트인데, 차량 내부 배터리를 사용하고 인버터 작동스위치를 눌러야 쓸 수 있습니다.

이게 좌/우 보조램프.

흑흑 멀티 돼지코가 걸려서 안들어가니까 할 수 없이 이렇게 …

그래서 이런거 하나 사왔습니다. 차 안에 시거잭은 여기 말고도 2군데나 더 있거든요. 이용하실 분들은 시거잭 관련 제품들을 가져오시면 유용하실 것 같습니다.

그리고 거기서 고개를 들어 위쪽을 보면 컨트롤 판넬이 있습니다.
바람이보다 확실히 직관적이군요. 좀 더 사용하기 편해졌습니다. 그래도 여전히 처음 사용하시는 분들에게는 어렵겠지만요.

배터리 용량체크는 위를 누르면 차량용 배터리, 아래로 누르면 캠핑카 영역쪽의 배터리 용량을 나타내 줍니다. 색으로 되어 있으니 빨간불까지 떨어지면 시동을 한 30분 걸어놓아서 충전해 주어야 합니다. 전기 연결이 안되니까요! 전기 연결이 되면 저런거 신경 쓸 필요도 없는데!

요쪽은 위로 올리면 물통 게이지이고, 아래로 내리면 하수통 게이지입니다. 화장실 말고요. 샤워냐 주방에서 물쓰면 모이는 오수통이 있거든요.

물을 쓰려면 물펌프는 반드시 켜야 됩니다.
바람이보다 훨씬 쓰기 편하긴 합니다.
그렇지만 역시 여전히 귀찮은 것은, 수시로 확인해 줘야 한다는 거지요. 어떻게 그냥 간편하게 한 번에 알 수 있는 방법이 없을까요. 예를 들어 차량 밖에 저 게이지가 늘 보이는 판넬이 하나 존재하면 (숫자 바늘로 된) 훨씬 더 편할텐데요.
아니면 네비게이션처럼 위험할때 음성으로 말해주던가!

주방입니다. 깔끔하기도 하지. 싱크와 가스렌지는 강화유리판으로 덮여 있습니다.

한쪽씩 오픈할 수 있지요. 남은 쪽은 간이 테이블로 사용할 수 있고.

가스렌지는 서랍에 들어있는 요걸로

찰칵. 하고 불붙이면 됩니다.

주의해야 할 점이, 이 상태로 오른쪽 화구를 사용하면 옆의 유리도 가열된다는 것입니다. 오른쪽 화구를 쓸 때는 두 유리를 다 열어줘야겠지요.

서랍도 그냥 안열립니다. 흔들리는 캠핑카니까요. 반드시 잠겨 있습니다.
이렇게 눌러서

딸깍. 이제 열립니다.

유리창은 늘 그렇듯 누른 채 돌려 열어야 합니다. 아니, 유리창이 아니군요. ‘플라스틱’ 재질의 창입니다.

양 옆에도 마찬가지.

살짝 밀었다 놓으면 고정됩니다 .

닫을 땐 다시 한 번 더 밀었다 놓으면 되지요.

위쪽엔 환기 팬과 조명이 달려 있습니다만, 창문만 열고 조리해도 큰 문제는 없습니다.

팬 위의 장도 역시 눌러서 열면…

짜잔. 주인 아저씨의 회심의 자랑거리인 빔 프로젝터가 등장합니다.
DVD도 몇 편 챙겨 주셨지만, 아쉽게도 이건 외부 전원이 연결했을때만 사용 가능하니까 이번엔 못씁니다. 봉인.

또 하나 봉인해야 할 것은 천장에 달린 독립형 에어컨/히터 입니다. 원래 히터와 에어컨은 차량 것을 사용할 수 있게 되어 있지만, 이것은 그거와는 또 별개로 동작할 수 있는 에어컨과 히터이지요. 즉 에어컨과 히터가 2개씩 달린 거라는 말씀.

그치만 이것도 외부 전원이 연결되어야 사용할 수 있습니다 …

화장실 문에는 옷걸이같은게 있네요.

아담하지만, 있을건 다 있는 화장실이 보입니다.

기본적으로 휴지, 세정제 (비누대신 사용 가능한) , 치약, 샴푸, 린스는 구비되어 있으므로 수건만 준비하면 됩니다.

아아….. 세면대가 독립되어 있다…
이것만으로도 큰 발전입니다. 아래쪽엔 각종 수납함도 있네요.
저 수도꼭지는 잡아당기면 샤워기가 되므로, 사실상 샤워도 가능합니다 .

천장에는 늘 그렇듯 양방향 강제 송풍기가 달려 있구요.

휴지와 보관함이 이쪽에도 달려 있습니다.

그전보다 나아졌다고는 하지만, 여전히 비행기 화장실 느낌이긴 합니다. 뭐 어쩔 수 없지요.

변기는 재미있게도 의자가 돕니다. 편한 방향으로 돌려서 쓸 수 있게 말이죠.

젖을까봐 뚜껑을 엎을 수 있는 화장지 케이스가 이채롭습니다.

요렇게 돌리니까 중간밸브가 보이네요. 요걸 꼭 잠그고 다녀야 합니다.

안그러면 오물통에 있던 오물들이 차가 흔들릴때 막 튀고 막 … 으아아아…

물 내리는 펌프입니다. 요걸 푸샥푸샥 해 주면 물이 솩솩 나와서 … 옆에 있는건 오물통이 찼을때 켜지는 램프인듯.

중간밸브가 잘 닫혀 있습니다.

역시 220V 외부전원이 연결해야 사용가능한 전자레인지와 차량 에어컨과 연결된 에어컨이 보입니다.

냉장고가 좀 특이하군요. 보통 AUTO 모드로 이렇게 놔두면 되는데, 이렇게 놔두면 자기가 알아서 전기, 배터리, 가스를 왔다갔다 하면서 냉장고를 가동시킵니다. 그래요 이걸 원했어요. 캠핑카 제품은 이래야 해요.

냉장고 문도 눌러서 열어야 열립니다. 캠핑카니까요. 흔들리는 캠핑카.

냉동실 칸도 따로 있고, 제법 넓고 좋습니다.

냉동실 냉동실.

냉동실 아래에는 보일러 조작 판넬이 있습니다. 냉장고 듀얼팬 시스템은 건드릴 필요 없고. 맨 아래 있는 가스 감지기도 건드릴 필요가 없고.. 가운데에 있는 보일러 스위치만 건드리면 됩니다 .
이게 별이의 자랑, 트루마 보일러라는군요.

자랑스럽고 무시무시한 경고사항. 주유중에는 사용말래요. 하긴 기름보일러니까.

이게 한 번 제대로 가동되면, 저기 검은 부분에서 꽤 강한 열기가 뿜어져 나옵니다.
높이가 왠만한 애들 얼굴 높이라, 주의시켜야 합니다.

가동되는 모습입니다. 파랑색 5는 현재 온도를 표시하고, 붉은 라이트는 현재 가열되고 있다는 증거.
테두리에 있는 조절링으로 ‘온수전용’ 모드와 ‘난방’ 모드를 선택할 수 있는데, 위의 60 / 40 두 개가 온수전용이고,
가운데 ‘0’ 이 꺼짐. 아래쪽 불 그림 두 개가 ‘난방’ 모드를 의미합니다.

공기 정화기 바이러스 닥터를 설치해 놓으셨네요. 이런거 좋습니다.

그리고 각종 리모콘 모음들. 많기도 하다… 나이드신 분들은 다루시기 좀 힘드실 만도 하네요.

AV 시스템은 이렇게 되어 있습니다. 아무래도 개조하신 것 같은데…
여기도 12V 시거잭이 있고, 외부입력이 가능하므로 … 응?
… 다음에는 전기 연결되는 캠핑장에 와서 이걸로 XBOX연결해 버리면 잼겠다! 그것도 프로젝터로!!!!

그 옆에는 DVD도 들어가는 자동차용 오디오, 그담에 전환 스위치들입니다.
스카이라이프가 저 구석에 있어서, TV도 볼 수 있지요.

확실히 근데 쉽지 않긴 합니다. TV를 보려면 모니터를 켜고, 스카이라이프를 켜고, 저 오디오를 Line IN으로 맞춰 놓고 해야 겨우 볼 수 있습니다. 리모콘만으로 조작한다면 3개를 조작해야 ㅋㅋㅋ

천장에는 온도 감지까지 되는 양방향 대형 송풍팬과

천장에 있는 이거 뭡니까 썬루프는 아닌데 ㅋㅋㅋ

저기다 카메라만 쑥 내밀고 찍어봤어요 ㅋㅋㅋ 태양열 집진판이 보입니다!!! 이걸로 배터리 충전한다는 그것!!!

가만… 나머지는 뭐지? 바로 그 뒤에 있는 건 송풍팬 덮개겠고, 오른쪽은 스카이라이프 안테나?

뒤에는 도메틱 독립 냉/난방기, 오른쪽은 화장실 팬 덮개군요 ㅋㅋ

그 외에도 이것저것 다 둘러 봤는데도 시간이 조금 남네요. 간만에 책이나 읽으면서 여유로운 시간을 가져봅니다.
아이패드로 음악을 들으면서…

이런 식으로 둘러본거 다 쓰다간 메뉴얼 되겠어요

… 얼마만이야 이렇게 여유로운 시간이.. 크흑…

감격스러워 눈물이 다 납니다.

조금 기다리자 독립기념관 체험코스를 마치고 온 아이들과 식구들이 돌아오고, 본격적으로 불장난에 들어갑니다.

캠핑카 여행기 / 굿타임캠핑카 별이타고 여행하기 1부

Tue, 08 Nov 2011 01:28:22 +0000

예에 뭐 그렇습니다. 살다보니 캠핑카라는걸 두 번이나 타게 될 줄이야. 저는 꽤 운이 좋은 편인 것 같습니다.
문제는 이렇게 로또에 쓸 운을 조금씩 다른데 쓴다는 것… 으헝헝…

어쨌거나 운좋게 또 기회가 되어서 두 번째로 캠핑카를 이용하게 되었습니다. 굿타임 캠핑카 사장님 감사함다 ㅎㅎ

이번엔 바람이가 아니라 ‘별이’ 입니다!
나온지도 얼마 되지 않은 최신식 캠핑카! 바람이와는 다르다 바람이와는!! 최신식이란 말이다!

더이상 단종된,
가슴으로부터 브레이크를 밟아야 하던,
그 리베로가 아니야!

‘별이’라고 불리는 이 캠핑카는 ㈜카라반클럽코리아 http://www.caravanclubkorea.co.kr/ 에서 제작된 2010년 모델 , 오페라 V9 캠핑카입니다. 차체는 그랜드 스타렉스를 기반으로 하여 개조된 차지요.

캠핑카 한 번 타봤다고 관심생기고 아는척하고 막 이럽니다.
어쨌건 2010년 형이라… 흐음 과연 신형이라고 할만 하군요.
오케이, 이번 여행은 이 녀석이랑 하는 겁니다.

어디를 갈까 찾아보다가, 가깝기도 하고 아이들 교육에도 좋을 것 같은 독립기념관 야영장 (서곡야영장) 을 선택했습니다.
…좋아. 이번엔 그 때 여행처럼 너무 멀어서 여행의 대부분을 차만 타고 다니지 않아도 된다…
거기에 나름대로 교육의 의미도 있고 말이죠.

게다가 지방에 결혼식 갔다 올 일이 있어서 잠깐 답사를 갔다 와 봤더니 넓고 좋은 겁니다. 자전거 타기 딱 좋겠어요.

넓다. 자전거 대여도 됩니다.
하지만 집에 세 대나 있지롱.

야영장도 무척 넓구요.
급수 시설도 잘 되어 있고 쓰레기장도 잘 되어 있습니다.

그렇게 다 하고 예약까지 했는데.

주말 내내 비온데요 OTL
캠핑장에 전기 연결 안된데요 OTL

… 그래서 주인 아저씨가 개조해 놓으셔서 안에 영화관처럼 만들어 놓으신 프로젝터도 사용못하고,
차 안의 전자레인지도 사용 못하고, 자전거 가져가려던 계획도 접을 수 밖에 없었습니다 .
근데 왜 저보다 사장님이 더 실망하시는 건가요 ㅋㅋㅋㅋㅋㅋㅋㅋㅋ

뭐 그렇지만 예약해 놓은 걸 어쩌겠습니까.
그리고 별이는 전기 연결 안해도 웬만한건 다 쓸 수 있고 말이죠.

일단 ‘달리기 전용’의 1호기는 세차해서 잘 봉인해 놓고,
‘주말 여행 전용’의 2호기 출똥!

하남시에 있는 차량인계지로 갑니다.
여기가 좋은게, 가지고 간 차를 보관시킬 수 있어서 좋아요.
아침 8시에 도착.

전혀 차량 인계지라고 상상되지 않는 이 곳이 차량기지입니다 ㅎㅎ

홈페이지 약도에 있는 저런 건물 아닙니다 ㅋㅋㅋ 뭐야 너무 이질감 넘치잖아 ㅋㅋㅋㅋ
첨에 왔을때는 ‘제대로 온 것 맞아 이거?’ 라고 당황했었는데, 두 번째 보니 익숙하군요.

이 녀석입니다. 설렁설렁 설명 들은 것 같은데 어느새 1시간 정도가 훌쩍 지나 버렸군요.
캠핑카라는게 워낙 배울 것이 많기 때문에, 대충 하는 것 같아도 굉장히 설명 들을 양이 많습니다.
게다가 절반 정도는 이전에 몰았던 바람이와 동일하기 때문에 금방 될 줄 알았는데, 전혀 그렇지 않았습니다. 흐음.

그럼 뭐 일단 출발.
… 이영차. 아 높다. 거의 ‘올라타는’ 분위기네.

역시나 첫 휴게소까지는 새로운 차에 긴장하느라고 사진이 없습니다 :)
첫 휴게소까지 오니까 진정이 되고, 긴장이 풀리네요.

확실히 ‘가슴으로부터 브레이크를 밟았던’ 바람이와는 상대가 되지 않습니다.
훨씬 가볍게 움직이고, 훨씬 가볍게 섭니다. 물론 그렇다고 해서 1호기나 2호기에 비할 바는 절대로 아니고 ;;
상식적인 수준에서 움직이긴 한다는 겁니다. 그렇다고 하더라도 4톤이 다 되는 차가 그렇게 가볍게 달리고 서기를 바라면 안되지유.

보시면 알겠지만, 3미터의 위엄은 옆의 트럭들과 비교해서 전혀 꿀리지 않습니다.

자 모두 따라하세요 .

나는 트럭이다 나는 트럭이다 나는 트럭이다 나는 트럭이다 나는 트럭이다 나는 트럭이다 나는 트럭이다
나는 트럭이다 나는 트럭이다 나는 트럭이다 나는 트럭이다 나는 트럭이다 나는 트럭이다 나는 트럭이다

톨게이트 지나갈때에도 맨 오른쪽으로, 트럭 통과하는 곳으로 가야 합니다. 지하 주차장이나 골목길 절대 금지.
간판에 걸린단 말입니다! 후방카메라가 있어도 위는 못봐요! 뒷 오버행이 길기 때문에 회전도 급하게 하면 반드시 뒤꽁무늬가 벽에 긁게 된단 말입니다! 걍 트럭이예요 이건!!! 2종도 몰 수 있지만!!! 트럭이라구요!!!

그치만 참 아이러니컬하게도 차 움직임이 가볍고 좋다보니까, 자꾸 잊어먹게 되어서 위험합니다. 아 맞다 나 트럭이었지 ㄷㄷㄷ

이제 찬찬히 차를 둘러 봅니다.
사장님 성격답게 먼지 하나 없는 실내가 후덜덜합니다. (바닥에 깔판이 세 개나 깔려 있…)

25000쯤 달렸군요. 이정도면 뭐 거의 새거네요.

하이패스도 장착되어 있지만 전 안쓰니까 뭐.

네비는 삼성 엠피온. 맵은 아틀란입니다. 괜찮지요 아틀란. 아이나비나 맵피보다 시원시원하고 업데이트도 괜찮고.
뭘 가져다 주건 잘 쓸 수 있으니까 상관 없습니다 저는.
IPOD 연결을 위한 USB 포트가 보입니다만, 저건 전용 케이블 용이라 아이폰이 충전되거나 하지는 않습니다.

그랜드 스타렉스는 처음 몰아보는데, 생각보다 몰기 편하고 가볍습니다. 2호기 (뉴카렌스) 모는 느낌하고 비슷.
디젤이라 토크는 말할 것도 없이 좋고, 브레이크도 잘 듣습니다.
작정하고 밟으면 120은 우습게 나올 수 있을 것 같은데…

문제는 가는 내내 주차장 모드 제길 … ㅠㅠ

제가 이래서 경부고속도로를 싫어합니다.

역시나 백밀러는 가족감시용.

… 이라고 생각될 수 있지만 사실은 후방 감지 카메라 모니터라는게 훼이크.
카메라에 차 뒤에 달린 자전거 케리어가 보입니다.

왼쪽 아래에는 차량 서스펜션을 조절할 수 있는 듯한 계기판이 보입니다만, 건드리지 않도록 합시다.
높이 조절은 이미 되어 있으니까요.

쇼바도 적절히 탄탄해서, 운전하는 맛 까지 느낄 정도입니다. 아, 앙대… 이건 트럭이라고… 또 긴장 풀 뻔 했네…
한시라도 긴장을 풀어선 안됩니다.

이번엔 (상대적으로) 거리도 가깝겠다, 길도 막히니 휴게소마다 쉬어갑니다.
쉬어가면 지나가는 사람들마다 기웃대거나 묻는것도 이제 익숙합니다 .

그런데, 여기서 재미있는 것 하나는
“얼마에 빌리셨어요?” 라고 묻는게 아니라 “얼마에 사셨어요?” 라고 묻는다는 것.
아무리 봐도 ‘허’ 번호판이잖아요. 렌트예요.
… 아…

그러고보니, 광고가 하나도 없군요.
보통 빌린것에는 커다랗게 렌트카 회사명과 전화번호가 박힐텐데,
사장님 왈 “빌린 것 처럼 보이지 않고 산 것처럼 보이게 하고 싶어서” 광고는 하나도 안 박으셨답니다 ㅋㅋㅋㅋ
홈페이지에서 읽었어요 ㅋㅋㅋ 사장님 꼼꼼해 ㅋㅋㅋㅋ

뭐, 덕분에 매우 깨끗해 보이기도 합니다. 진짜 오너가 된 기분도 들고.

끄응… 하지만 이놈의 고속도로는 뚫릴 줄 모릅니다.
미리 이럴 줄 알고 , 캠핑카는 버스 전용차로로 가면 안 되는가 하고 검색해 봤더니
“9인승 차량에 6인 이상 탔을 때” 버스 전용차로로 갈 수 있더군요.

…하지만 이건 6인승으로 신고되어 있고 우린 5인이잖아… 안될꺼야 아마…
아이들을 위해 독립기념관 체험 예약을 잡아 놨는데 간당간당 할 지도요.

그래도 생각보다 여유가 있게 도착해서, 마트에 들렀습니다. 캠핑카 최대 장점이죠.
마트에서 곧장 사서 채우고 출발하면 된다는거.

날씨도 춥지도 않으니 딱 좋고 기분좋습니다.

…. 응?

잠깐. 비온다며 …. -_- ;;;

비 안옵니다. 날씨 딱 좋고 따뜻합니다.
나중에 보니 관측사상 11월 최고 온도 기록 …
자전거 가져올 걸…
하여간 기상청을 믿은 내가 바보지.

기상청. 싸우자.

이렇게 캠핑장에 도착했습니다. 캠핑장은 독립기념관 안으로 들어와서, 다시 입장료를 내고 깊이 더 들어오면 있지요.

아이들 체험 시간이 다 되었기 때문에, 저만 남고 나머지 식구들은 모두 독립기념관 체험장으로 갔습니다.

저는 남아서 차량 점검 및 셋팅.

이거 뭐라고 그러는지 모르겠지만 사람들이 저 평상같은거 위에다가 텐트를 치더라고요.
캠핑 초보가 알리가 있나.

이리 저리 차를 대면서 어디가 좋을까 재 봅니다.
일찍 와서 그런지 한산합니다. 저녁되면 북적북적한다네요 여기.

앞은 탁 트여서 좋습니다. 군데군데 화장실과 급수대, 쓰레기장도 잘 구비되어 있구요.

앞에 보이는 전망에 아파트도 보이고 좀 그렇긴 하지만, 뭐 상관 없습니다.

가족들을 보내고 홀로 남아 다시 한 번 복습을 하고, 찬찬히 차를 둘러 보면서 셋팅을 합니다.
일단 좌측의 1 자 열쇠는 외부의 각종 보관함 열쇠고, 오른쪽의 영어 열쇠는 화장실 관련 외부 열쇠입니다.

요 뭉툭한건 캠핑카 대문열쇠

이거야 뭐 그냥 차키

굳이 필요할까 싶은 물 주입구 열쇠입니다.

좀 하나로 통합되면 좋겠다라는 생각이 드네요.

이제 제가 좋아하는, 찬찬히 뜯어보기 시간입니다 ㅋ
왼쪽부터, 가스통 함, 대문, 그리고 바퀴 옆 작은 박스는 외부 전원 연결단자이고, 그 옆에는 외부 보관함이 있습니다.

대문부터 보죠.

레버를 당겨 대문을 열면, 여기에 고정시켜 둡니다.
캠핑카는 비행기처럼 여기저기에 고정해 두는 기구들이 많이 달려 있지요.

대문은 이렇게 생겼습니다 블라인드 자바라를 올려 봤습니다. 모기장도 올릴 수 있구요.

… 음 근데 저렇게 생긴 문은 보통 분리 가능하던데… 모기장 문으로…

이리저리 만저 보다가 저걸 좀 세게 젖히니 문이 빠지면서 모기장 모드로 변하는걸 발견했습니다.
아 이놈의 직업병… 새로운거 만나면 무조건 뜯어봐야 직성이 풀리니…

와와 분리됐다.

근데 , 저 긴 부분은 모기장을 아래에서 올리면 된다 치지만 손잡이 부분은 그냥 뻥 뚫려 있습니다.
이래서야 파리도 막지 못하겠군요.

메뉴얼을 보면 저 부분에 플라스틱 덮개가 있는데 말입니다.

원래는 덮개가 있는데 겨울에는 파손우려해서 떼어놓으신다는군요.
아항 그래서 나사자국이 있구나 저기.

뭐, 겨울에 무슨 모기장입니까. 그냥 닫으면 되지요.

이동할때, 잘때는 저길 잠그면 됩니다.

열때는 이렇게 찰칵. 흠 그렇구나.

가스함 한 번 열어봐야겠습니다.
열쇠 꽂고 그냥 돌립니다. 누르지 말고.

휘릭. 열림 쪽으로 .

아래도 열고

동시에 누르면서 이렇게 잡고 엽니다.

오오 가스다 가스.

부탄가스 연결하던 바람이와는 차원이 다른 화력을 보여주는 이유입니다.
그리고 냉장고도 이 가스를 이용해서 가동된답니다.

요건 이번에 사용 못하는 전기 콘센트.

3구 콘센트입니다. 전기선과 확장 릴선은 차에 구비되어 있습니다.
저기 저 파란 레버 부분을 누르면서 뽑게 되어 있습니다.

보관함도 열어봅시다.

오오 추가로 대여한 화로세트 관련 물품들이 들어 있습니다. 토치도 있고 장갑도 있고 부탄가스도 있고 철망도 있고 나무도 있고…
화로대는 조수석 뒷자리에 있습니다.

왼쪽에 조명등도 보이는군요.

단지 주의할 점은, 조명등은 저 문 닫는다고 자동으로 꺼지거나 그렇지 않기 때문에 실수로 켜놓은채로 문을 닫고 잊어버리면 차체 배터리 과다소모의 주범이 된다는 말씀.

이번엔 차량 왼쪽을 둘러봅니다. 왼쪽부터 물 주입구, 외장 보관함, 주유구가 보이고, 그 오른쪽에 보일러 배출구가 보입니다.
그리고 맨 오른쪽에 화장실 관련된 곳이 보이네요.

2부에 계속.

캠핑카 여행을 '또' 다녀왔습니다.

Mon, 07 Nov 2011 00:46:18 +0000

아이폰 거치대 리뷰 1등으로 캠핑카 1박 2일 여행 당첨 -> 여행기 작성 -> 여행기를 캠핑카 사이트에 올렸더니 사장님이 연락해주심 -> ‘새로 나온 모델 체험해 보세요’ -> 그래서 갔다왔습니다. 흠흠.

일단 오늘은 사진정리만 해놓고 자야겠습니다… 피곤해욤 ㅋㅋㅋ
사진만 400 몇 십 장을 찍었으니..

조만간 후기 올릴께요

삼국지를 품다가 공개되었네요.

Fri, 04 Nov 2011 23:19:31 +0000

제가 지금 참여하고 있는 프로젝트 중 하나인 [삼국지를 품다] 가 드디어 공개되었군요.
그래서 비밀 프로젝트에서 공개 프로젝트로 올립니다. 게시판도 독립해서 만들었습니다.

게시판에는 비밀글이 더 많군요… 아직 풀지는 않으렵니다 후후후
나중에 게임 오픈하면 그때 다 풀어야지.

http://www.thisisgame.com/board/view.php?id=907271&category=102

역시 TIG가 가장 빨라요. 정확도랑 속도는 최강…

-ml:namespace prefix = o ns = “urn:schemas-microsoft-com:office:office” /-ml:namespace prefix = o /-ml:namespace prefix = o /

동영상도 퍼올려고 했다가 아무래도 TIG 저작권 문제가 있지 않을까 해서 출처 표기된 이미지만 올려봅니다.
AD 는 JJ 가 고생 많이 했지요. http://jx2comics.egloos.com/
부디 대박나길 ㅋ

개발자J의 오늘의 최저사양 테스트

Fri, 04 Nov 2011 15:38:42 +0000

이제 급한 일도 마무리했겠다. 본격적으로 테스트입니다.
최저사양은 펜4 2.4에 1G , 지포스 5700 입니다. 이건 뭐 지금 창고에서 찾아봐도 찾기가 힘든 수준의 컴퓨터…
해상도는 1024 * 600 익스플 8.0 윈 xp입니다.

마을(계성) 쪽에서 그다지 티는 나지 않지만 가끔씩 튀네요.
역시 메인프레임 워크 . 업데이트입니다.
게임하는데 지장갈 정도는 아닙니다만, 나중에 캐릭터가 많아지고 게임이 무거워지면 우려해야할지도 모르겠습니다.
캐릭터가 많아졌을때 . 즉 화면에 50-60명 이상 있을 때 처리를 슬슬 고민해 봐야 할 때가 아닌가 생각합니다.

카메라 백그라운드 색상을 전부 파란색으로 바꿔주세요. 스카이박스가 무겁다고 블랙으로 놔두니 좀 그렇군요.
월드맵에서는 오히려 디바이스.프레젠트가 튑니다. 게임할때 지장주지는 않습니다만. 어쨌거나 데이터의 양이 그래픽 카드가 처리하기에는 좀 많다는 말입니다. 최저사양에서는 월드맵에 데이터가 늘지 않도록 주의합시다.
최저사양에서 게임하면서 다른 짓을 한다는건 현실적으로 무리 같습니다. CPU 점유가 100% …

- 전투때 간혹 튀는 것들은 번들서비스의 리드 오브젝트입니다. 이쪽이 간혹 튀는 경우가 생기네요. 살짝 끊어지기도 합니다.
매번 그런건 아닙니다만… 훈련소에 있는 창병과 싸울때 이랬습니다.
오히려 물동이 든 황건적이랑 이런 녀석들은 굉장히 이상적인 그래프가 나오기도…

-전략전투중 채팅하다가 스페이스바 누르니까 이동 그리드가 사라집니다.

전략전투에서 이펙트 좀 상중하 옵션 넣어주세요!!!! 청주성 전략전투가 안개효과등 각종 이펙트 때문에 게임 플레이가 불가능할 정도가 됩니다 불 붙이고, 화살 쏘고, 모래바람 이펙트 등 까지 나오면 3~5프레임까지 떨어집니다. 심각한 레벨이네요.
이펙트 제작할 때마다 저사양 옵션을 넣어서 제작해 달라곳.
순기가 고친다고 들었는데, 여전히 죽기도 전에 이벤트가 나옵니다. 장비가 마지막 병사를 향해 공격 명령을 내리는 순간, ‘으하하 형님 전략이 맞았습니다’ 하면서 때린다던가, 퀘스트 완료 메세지가 나온다던가 해서 김새게 만들고 있습니다. 아직 업데이트가 안되서 그런듯?
청주성 이벤트에서 최저사양에서 뒤에 서있는 병사는 반 정도 안나오게 하고 싶습니다만, 연출에서는 상중하 옵션 컨트롤 기능이 없습니다. 맵에 있는 오브젝트/이펙트 라면 옵션 컨트롤이 가능하지만… 그러니 가급적이면 맵에 이펙트나 오브젝트를 넣어주세요. 저사양때는 날려버리게. 그리고 지금 아슬아슬합니다. 더 이상 쓰면 위험할지도요.
청주성 이벤트 장면에서 스카이박스는 안나옵니까? 단색 하늘이 마음에 들긴 합니다만 연출에서는 스카이박스가 나오기로 하지 않았나요? 가능하다면 스카이박스 안나오는 지금 상태가 더 마음에 들긴 합니다.

[필독]째째하게 모바일에서 텍스쳐 메모리를 줄여봅시다.

Thu, 03 Nov 2011 15:15:17 +0000

모바일의 텍스쳐 포맷

한 번에 다 쓰려다가 길어져서 나눠서 쓰겠습니다. 테스트 하기전에 데이터 체크하는데 눈에 띄어서 말이죠…
(이러다가 나 테스트 언제 해…)

모바일에서의 텍스쳐 포맷은 앞에 소개했다시피 4종류가 있습니다.

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


RGB Compressed PVRTC 2 bits	Compressed RGB texture. Supported by Imagination PowerVR GPUs. 2 bits per pixel (16 KB for a 256x256 texture)
RGBA Compressed PVRTC 2 bits	Compressed RGBA texture. Supported by Imagination PowerVR GPUs. 2 bits per pixel (16 KB for a 256x256 texture)
RGB Compressed PVRTC 4 bits	Compressed RGB texture. Supported by Imagination PowerVR GPUs. 4 bits per pixel (32 KB for a 256x256 texture)
RGBA Compressed PVRTC 4 bits	Compressed RGBA texture. Supported by Imagination PowerVR GPUs. 4 bits per pixel (32 KB for a 256x256 texture) (주: RGB가 아닌 RGBA인데도 RGB일때와 파일 크기가 똑같습니다. 그 얘기는 다른데서 색상을 줄였다는 얘기겠지요? 도움말에서 자세한 내용을 찾을 수는 없었습니다. )

==========================================================================================================
물론 이외에도 더 있지만, 압축 포맷은 이 4개 뿐입니다.

2비트 RGB와 RGBA
4비트 RGB와 RGBA

웃긴건, 4비트건 2비트건 RGB와 RGBA의 사이즈가 같습니다.
이 말은 4:4:4 였던 것이 3:3:3:3 이 되었다는 것으로 유추해 볼 수 있겠습니다. 세상에 색상이 느는데 용량이 안 주는 일은 없으니까요. 자세한 포맷은 메뉴얼에 없네요.

그렇다면 어쨌건 이전에 ‘알파채널이 필요 없는데 알파채널이 들어가있는’ 파일 포맷은 사실 모바일에서는 큰 문제가 되지 않을 수 있을 것 같습니다. 용량은 똑같으니까요. 색상이 좀 줄지만 크게 티도 안납니다.
어쨌건, 그렇다고 쓸데없는 알파 채널을 남겨놓는건 절대로 금기겠지요. 이건 이전에 썼던 1부 글과 마찬가지입니다.
용량이 차이나지 않는다 하더라도, 일부러 알파 채널을 남겨놓을 필요는 없으니까요.

근데,

색상이 줄어도 티가 안난다?

…
그렇다면 2비트 칼라로 바꾸면 어떻게 됩니까?

2비트와 4비트 칼라

2비트 칼라로 바꾸게 되면, 이론상 4비트 칼라의 절반이 됩니다.
그리고, 실제로도 용량이 절반으로 떨어지게 되지요.

2비트 칼라는 그럼 못 쓸 물건이냐?

직접 보시죠.

위에가 2비트 칼라 256kb
아래가 4비트 칼라 500kb

딱 두 배 차이지만, 별로 큰 차이가 나지 않습니다.
아니 오히려 4비트 칼라로 압축되느라고 복잡해진 색상이 2비트가 되면서 더 진정된 분위기입니다.

건물을 봐도 그렇습니다. 위에가 4비트, 아래가 2비트.
이 정도로 확대했는데도 차이가 거의 보이지 않습니다 (…)
당연히 2비트가 낫지요.

물론, 넓은 면적이 보여야 하는 터레인 텍스쳐는 이것이 어울리지 않습니다.

하지만 작은 디테일의 텍스쳐는 이것으로 충분합니다. 캐릭터도 마찬가지라고 미루어 짐작할 수 있겠지요.
이렇게 적용한다면 기존 텍스쳐 총량의 25%~30% 는 줄일수 있지 않을까 생각되는군요.

밉맵

가끔 보면 밉맵 옵션이 켜져 있는 경우가 있습니다.
이것도 뭐 제가 강의하는 시간에 얘기했지만… (강의 깔대기.. ㅋㅋㅋ)
밉맵을 쓰게 되면 용량이 150% 가 늘어납니다!!!!

특히 모바일에서 밉맵을 쓰게 되면 큰일납니다 !
반드시 모바일에서 밉맵 옵션이 꺼졌는지 체크해 주세요.
꺼야 됩니다.

켜면
용량이

150% 정도 로 증가하지요. 같은 이미지인데도 말이죠.
모바일에서 밉맵은 반드시 꺼주시기 바랍니다.

[필독] 째째하게 텍스쳐 메모리를 줄여봅시다!!! / 내 수업 듣는 사람 더 필독

Thu, 03 Nov 2011 13:47:19 +0000

텍스쳐 메모리는 사실 그래픽 데이터 중 가장 큰 영역에 속합니다.
그리고 그 텍스쳐 파일 포맷은, DirectX 게임에서는 DXT 라고 하는 픽셀 포맷을 사용하는 DDS 파일 포맷으로 사용됩니다.

그래픽 데이터에서 이렇듯 큰 영역을 차지하고 있는 그래픽 데이터는, 결국 메모리를 차지하게 되고 이것들이 쌓여서 사양을 높이거나, 메모리 크기를 크게 못 쓰게 되거나 하게 되는 것입니다.

이 텍스쳐 메모리를 깐깐하게 줄이는 방법은 그래픽 디자이너들은 꼭 알고 있어야 하는 내용입니다.
제 수업 (월요일마다) 들으시는 분들은 이미 다 이해하신, 바로 그 내용입니다. 실무에 적용되는 예라고 할 수 있겠네요.

일단 픽셀 포맷을 볼까요? DDS 파일의 픽셀 포맷은 , 1강때 얘기한 내용에서와 같이 DXT1 ~DXT5 로 이루어져 있습니다.

자세한 설명을 지금 좔좔좔 하자면 너무 길어지니까…
설명을 듣고 싶으신 분들은 제 강의 들으시는 분께 물어보세요. (만약 잘 설명 못하면 저한테 이르세요. 감점시켜 버릴테닷)

어쨌건, 그냥 DDS 를 쓰면 저렇게 텍스쳐를 세부 옵션으로 정의할 수 있습니다만, 유니티에서는 PC에서 쓸 수 있는 DXT 포맷이 한계가 있습니다.

유니티에서 지원하는 DXT 텍스쳐 포맷을 보면…


RGB Compressed DXT1	Compressed RGB texture. This is the most common format for diffuse textures. 4 bits per pixel (32 KB for a 256x256 texture). 디퓨즈 텍스쳐에 권장되는 픽셀당 4비트 텍스쳐입니다.
RGBA Compressed DXT5	Compressed RGBA texture. This is the main format used for diffuse & specular control textures. 1 byte/pixel (64 KB for a 256x256 texture). 압축된 RGBA 포맷입니다. 디퓨즈와 스페큘러 컨트롤때 쓰이는 텍스쳐 포맷입니다. (역주: 스페큘러 컨트롤을 알파 채널로 쓰게 기본 쉐이더에서 되어 있다는 얘기입니다)

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

요렇게 두 개밖에 없네요. DXT1과 DXT5. (개인적으로 DXT1 ARGB가 지원되었으면 좋겠는데…)

즉 알파가 없으면 DXT1을 쓰고, 알파가 있으면 DXT5를 쓰라는 것입니다.
이것은 모바일 버전에도 똑같습니다. 단, 모바일 버전에는 PVRTC 포멧을 사용한다는…

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


RGB Compressed PVRTC 2 bits	Compressed RGB texture. Supported by Imagination PowerVR GPUs. 2 bits per pixel (16 KB for a 256x256 texture)
RGBA Compressed PVRTC 2 bits	Compressed RGBA texture. Supported by Imagination PowerVR GPUs. 2 bits per pixel (16 KB for a 256x256 texture)
RGB Compressed PVRTC 4 bits	Compressed RGB texture. Supported by Imagination PowerVR GPUs. 4 bits per pixel (32 KB for a 256x256 texture)
RGBA Compressed PVRTC 4 bits	Compressed RGBA texture. Supported by Imagination PowerVR GPUs. 4 bits per pixel (32 KB for a 256x256 texture) (주: RGB가 아닌 RGBA인데도 RGB일때와 파일 크기가 똑같습니다. 그 얘기는 다른데서 색상을 줄였다는 얘기겠지요? 도움말에서 자세한 내용을 찾을 수는 없었습니다. )

==========================================================================================================
제 수업을 들어오신 분은 알겠지만, 2비트 칼라의 텍스쳐는 너무 깨져서 ‘굉장히 작아서 걍 있구나 라고 표현하면 될 텍스쳐’ 에 사용하면 좋을 포맷인걸 짐작하실 수 있으실 겁니다. 실제로도 그런 오브젝트가 꽤 있지요? 그 때 사용해 주시면 되겠습니다.

하지만 보통은 4비트 텍스쳐로, RGB (알파 없는것) RGBA (알파 있는것) 을 사용하겠지요. 4비트면 DXT 시리즈와 같은 파일 포맷이니까요.

이렇게 , 알파가 있고 없고에 따라서 사용하는 텍스쳐 포맷이 달라져야 합니다.
알파가 없어야 하는 것에 알파가 들어가면 DX 버전(PC버전) 에서는 256*256 사이즈의 텍스쳐일때 용량이 2배가 차이나게 됩니다.

이것은 왜냐면… DXT5 의 알파채널은 다른 채널과 다르게 혼자 8비트를 사용하기 때문입니다. 엄청나지요.

모바일버전에서는 일단 ARGB와 RGB가 같은 용량으로 나옵니다만, 수업했던 내용에 따르면, 이렇게 되면 반드시 A를 표현하기 위해서 RGB의 어느 부분을 빼버렸을 거란 말입니다. 색상이 줄게 되지요.

그러므로, 텍스쳐의 픽셀 포맷을 제대로 정하는 것은 메모리를 위해서 매우 중요한 일이 됩니다.
특히 모바일처럼 메모리의 양이 아주 민감한 경우에는 잘못하면 치명적이 될 수 있는 것이죠.

====================================================================================================
작업하신 분을 비난하려는 의도는 전혀 없지만, (누가 했는지도 몰라요…)
경각심을 불러 일으키고자 이런 예를 한두개 소개해 보겠습니다.

예를들어 현재 모바일에 들어가 있는 build_basecamp_03_01_mobile 이라는 텍스쳐를 보도록 하겠습니다.
이 파일은 512*512 라는 사이즈에 RGBA , DXT5 입니다. 알파 채널이 있다는 말이죠. 용량은 256KB 입니다.
그런데, 알파를 확인해 보면? 아무것도 없습니다! 전부 흰색, 즉 1 값이므로 이건 불투명한 이미지인 것입니다. 알파가 없어야 하는 이미지인 것이죠.

어째서 이런 일이 일어났을까요?

그것은 포토샵으로 tga를 세이브 할 때의 일입니다.
열심히 작업을 하신 후, 세이브할때

무심코 알파 채널이 생성되어 있었고, 그것을 다시 무심코 32비트로 저장하셔서 그렇습니다. 32비트라는 말은 알파 채널을 만들겠다는 말이니까요. (왜 그렇냐면 역시 강의 들으신 분들께 문의를…)

이렇게 되어서 저장하면, 이미지에는 필요없는 알파 채널이 생성되게 됩니다.

그런데 다행히 유니티에는 이걸 다시 수정해서 저장할 수 있는 기능이 들어 있습니다만…
대부분 그냥 자동으로 해 버리지요.

자동 옵션입니다. 이렇게 되면, 유니티는 ‘알파 채널이 있으니까 필요한 건가부다..’ 라고 생각하고 DXT5로 저장해 버리는 것입니다.

만약 실수로 이미지가 이렇게 들어왔다면, 유니티에서 강제로 DXT1으로 바꿔만 줘도 됩니다.

그럼 알파 채널이 자동으로 짤리지요.

그렇게 되면?

용량이 256kb에서 128kb로 ! 절반이 줄었습니다! (DXT5 4:4:4:8 이 DXT1 4:4:4 로 바뀌었는데 용량이 절반이 주냐고 물으신다면.. 잘 모르겠습니다… 헤더를 비롯한 기타 용량이라고 짐작할 수 밖에요…)

그리고 이것은 모바일에서도 마찬가지입니다. 애석하게도 모바일에서는 용량차는 없겠지만, 칼라의 깊이가 떨어지는 결과물이 나오겠지요. 이건 다음 시간에.

또 하나의 예를 보여드리겠습니다.

build_farm_03_mobile 파일은 농가의 집 텍스쳐 같군요.
척 봐도 알파가 필요 없을 것 같은 파일에, DXT5가 적용되어 있습니다.
용량은 1024*512 에 0.5M

알파 채널은 …?
네네. 이건 맥스에서 Unwrap 작업할때 쓰던 데이터로군요. 알파 채널에다가 이 참고 데이터를 넣어두신 후, 잊어버리시고 그냥 저장한 듯 합니다. 하지만 이것도 고스란히 용량으로 잡힌단 말이죠.

이것도 DXT1으로 바꾸어서 알파를 날려 보았습니다. 결과는?

역시 텍스쳐 사이즈가 절반으로 줄었습니다. 즉 1024*512 라는 거대한 텍스쳐를 한 장 더 쓸 수 있는 메모리가 늘었다는 말이죠!!

알파로 낭비하는 텍스쳐의 사이즈만 정리해줘도 큰 일이 됩니다. 이런게 쌓이면 바로 큰 낭비가 되는 것이지요!
아주 꼼꼼하고 깔끔하게 정리해 주셔야만 합니다.

2부는 모바일에서의 얘기입니다. 좀있다가 모바일 게시판에 적지요.

rwar

Thu, 03 Nov 2011 13:42:48 +0000

warwr

삼품 QB

Tue, 01 Nov 2011 16:57:45 +0000

본 테스트는 최저사양 . p4 노스우드 싱글 2.4 G , 메모리 1G , 그래픽 카드 지포스 FX 5700 에서 진행되었습니다.

로그인까지 로딩 50초가 걸립니다. 좀 걸린다는 느낌입니다.

-캐릭터 선택창은 아슬아슬한 수준입니다. 좀 더 최적화를 하고 싶달까요. 그리 오래 보지는 않지만 전 게임을 통틀어 가장 느립니다.

캐릭터 선택 후 게임 실행까지 다시 약 50초가 걸립니다. 이젠 좀 로딩이 많네 라고 느끼는 정도입니다.
초반 로딩은 개선하면 개선할수록 좋을듯 싶습니다.

-간혹 불규칙하게 튄 부분은 위의 두 부분입니다. 빈도수가 높지는 않고, 참을만 합니다. 가끔이니까요.
전체적으로는 많이 안정된 프레임을 보여주고 있습니다.

NPC 근처에 너무 모여 있습니다. NPC 근처 일정 범위를 접근하지 못하도록 하는게 좋지 않을까 합니다.
프레임은 약 10프레임~15프레임. 다소 버벅이지만 플레이가 가능한 정도입니다. 황건적 요새입니다
네임플렌이 늦게 따라옵니다. 저사양에서 회전할 때 주로 일어나는 일인데, 덕분에 기울어진 네임플렌을 자주 볼 수 있습니다.
아직도 병사로 보이지 않고 HP로 보입니다. 전투결과창에서 “병사"가 줄고, 다시 “병사” 가 채워졌다는 것을 동적으로 보여줄 필요가 있다고 보입니다.
여전히 죽기도 전에 ‘으윽 내가 지다니’ 라는 말풍선이 나옵니다. 굉장히 기분나쁘달까.신경을 안쓰고 대충 만든 느낌입니다.
죽기도 전에 죽는 대사부터 출력하는거 우리회사 고질적 문제인데 아무도 고치려 안하고 있습니다.
월드맵에서 수동으로 이동하다가 걸리면 덜덜덜 떨리는게 무척 기분나쁩니다. 모두 자동이동만 할거라고 생각하지 말아주세요.
‘페이지에 오류가 있습니다’ 라는 문구는 웹 하단에 계속 뜹니다. 나는 오류 프로그램을 실행하고 있는 걸까요.
콘솔 메시지 흰글자 노란글자 녹색글자 아아악 누가 이것좀 지워줘 아아아아아악

아이노트 블루투스 키보드 X-KEY

Mon, 31 Oct 2011 02:24:29 +0000

헥헥 주말에 끝마치기 위해 최선을 다했습니다.
역시 흰 제품을 백색 배경지에서 찍기는 정말 힘들어요.
그래서 다음부터는 흑색 배경지를 구해놓기로 했습니당.

오늘 강의 자료는 대박이로구나아

Sat, 29 Oct 2011 13:41:47 +0000

매 주 마다 새롭게 양을 갱신하는 PT자료 …
이러다 담주엔 100페이지를 넘어갈지도 모르겠군요.
3시간이 강의시간인데, 3시간동안 학생들이 들으면서 안 졸게 하는 것도 엄청나게 고민하고 꼼꼼하게 시뮬레이션 해야 하는 거지용.
안 조는 강의 방법은 몇 개가 있다고 봅니다. 제 강의 경험으로 얻은 몇 가지 소소한 요령은…

학생들이 강의듣다가 이렇게 자버리면 시ㅋ망ㅋ

일단 자료가 재밌거나 친숙.
:흥미있는 사진이나 놀라운 영상자료를 공개하면 재미가 상승하면서 집중도가 올라갑니다.
단, 강약을 조절해야지 그것도 연속으로 보여주면 슬슬 지겨워지지요

2. 익숙한 상황을 예로 들어서 강의를 들으면서 상상하게 만듬
:개콘의 비상대책 위원회를 상상하시면 돼요. ㅎㅎ
ex)너네가 여친사진을 스키장에서 딱 찍었단 말이지! 근데 막 여친 얼굴이 시커멓게 나와! 이거 큰일이야! 어쩔꺼야!

3. 기존의 상식을 살짝 깨버리는 사실 알려줌. 질문과 병행하면 효과가 더더욱 좋음
: ex)빛이 가까우면 밝고 멀면 어둡다고? 정말이라고 생각해? 사실 정반대야! 빛은 멀수록 밝아!!

마지막으로 이렇게 궁금증을 유발하게 한 후 원리를 알려줌
: 사람이 가장 오래 기억할 때는 ‘감탄할때’ 이다. 사실은 이거였다!!! 여러분은 모두 알면서 속아왔던 것이다!!!!
첫 휴식은 빨리 하는게 좋다.
: 첫 휴식은 반응 봐서 1시간 이전, 30분쯤 지난 후 정도가 좋다. 학생들이 강의 리듬에 아직 적응하지 못해서
초반에 금방 졸려 하기 때문. 이 때 10분 정도 살짝 자고 나면 갑자기 쌩쌩해진다. 10 분 이상은 역효과.

강의 내용도 한 1년되니까 좀 더 숙성되어서 회사에서도 동일한 내용으로 매주 강의하고 있는데 반응이 꽤 좋습니다.

슬슬 씻고 나갈 준비 해야겠군요.
아 강의 안가고 무한도전 보고 싶어.

모바일 개선사항

Sun, 23 Oct 2011 11:42:35 +0000

아이콘 바꾸기
게임명 제대로 넣기
첫 화면에서 훈련교관을 못찾겠다. 보이는 것도 아니고.
“훈련교관을 찾아보세요” 라고 하나 띄워주던가 (이미지와 함께) 아니면 처음에 보일 수 있도록 캐릭터를 좀 더 위에 생성되게 하자.
훈련교관 클릭. 퀘스트 받음.

‘훈련교관을 만났습니다’ (..던가?) 시스템 창과
퀘스트 리스트창과
훈련교관이 완벽히 겹쳐서 뭐가 뭔지 알 수가 없다. 화면 배치 다시!!

퀘스트 더블클릭? 방법이 이것뿐인가?
모바일에서 더블클릭이라. 불가능하진 않지만 영 어색하다.
여전히 X 와 » 를 먼저 누르더라. ? 에 나오는 글을 선택하게 하기 위해 X와 » 의 강도를 줄여야 할 듯.
훈련교관과 만남 [완료] 는 한 번 누르면 선택되고, 두 번 눌러야 작동된다. 갑자기 새로운 인터페이스가 나와서 당황하게 됨.
왜 다른건 한 번인데 이것만 두 번 선택인가? 게다가 한 번 눌러 선택된 것도 잘 보이지 않는다.
은 도대체 어디다 쓰는 것인가?
가죽 갑옷을 장착하라는데 어떻게 하는 건지 아무도 안가르쳐 준 것 같은데? 괜찮은가?
근데 무기 장착할때는 장착창을 열어준다???
동영상 로딩이 너무 길어서 다운된걸로 인식된다. (용량 줄이면 괜찮을듯)
병사대기소 여는 법도 모르겠음. > 버튼이 깜빡거리기라도 하던가…
병사대기소를 열었는데 퀘스트가 끝났는지 느낌이 전혀 안옴. 어지러운 녹색 글씨만 지나가고. 최소한 사운드라도 완료 사운드를 넣어줘야 하지 않는가?
조이스틱 이동이 문제 많음.(낀다던가 다운된다던가) 해결 못할거면 지스타에서 삭제할것.
전투 튜터리얼에서 말이 너무 느리게 나와서 뭘 해야 할지 모르겠음. 막 이거저거 누르고 싶음.
튜터리얼하다가 먹통됨

지스타 전까지 모바일 버전을 어떻게 바꿔야 할까요?

Fri, 21 Oct 2011 17:41:11 +0000

지스타가 3주 남았습니다 3주!
지금 상태는… 제가 기획쪽이 아니라 정확히 어디까지 하자고 되어 있는지는 모르겠지만.
지금 이 상태는 게임이 아니로군요…
3주 전이면 완성된 상태에서 폴리싱을 하고 있어야 할텐데, 기본 조작도 완성되지 않은 상태라 무척 위험해 보입니다.
이대로라면 공개해야 할지 말아야 할지 고민해야 할 수준이네요.

짧게 봤습니다만 그 짧게 본 상태에서도 보여진 문제점들과 해결책, 이미 고친 것들은 다음과 같습니다.
아주 기본적이고 눈에 확 띄는 것만 본거라 섬세하게 보면 한도 끝도 없겠지요.

다운이 잘됩니다. 여러 번 되네요.

조이스틱을 이용해서 이동하면서 워프게이트를 탈 때 다운이 연속으로 되었습니다.
그 외에도 다운이 꽤 잘되는 프로그램이군요. 안정성은 완벽히 올리지는 못해도, 어느 정도까지 할 수 있는데까지는 해야 할 것입니다. 조이스틱 이용시에 다운이 잘된다면, 정 안되면 조이스틱 컨트롤을 이번 지스타때는 빼버리는것도 고려하는 것이 좋을 듯 합니다.

동영상이 뚝뚝 끊어지네요.고쳐야 합니다.

동영상이 나오는데, 전 이거 3D 데이터 돌린 줄 알았습니다! 너무 자연스럽고 화질도 좋고 음향도 좋네요.
단, 그 퀄리티로 나오면서 부드럽게 나오면 좋은데, 마치 3D로 돌리는 것인가? 라고 생각할 정도로 중간에 뚝뚝 끊어지네요.
다른 기기에서는 문제 없나요? 테스트 되었나요? 스트리밍 사이즈를 올리거나, 해상도를 낮추는 것으로 해결할 수 있지 않을까요?
지금 소스의 해상도는 굉장히 높아 보이던데, 얼마인가요?
여하간 동영상 플레이를 더 가볍게 돌아갈 수 있도록 만들어야 할 것입니다.

카메라와 캐릭터 사이즈 조정했습니다.

주인공 캐릭터를 2.3배, 몬스터를 2배로 조정했습니다. 그전은 2.8배였죠. 카메라 조절하면서 캐릭터가 좀 더 작아질 필요가 있어서 조절했습니다.
카메라는 필드 화면에서는 적당한 각도를 지정했습니다. 좀 더 뒤로 뺄 생각도 가지고 있지만, 이정도 뷰에서 큰 불만은 없습니다.
몰라 또 상무님이 바꾸라면 바꾸는거지만 암 얘기 없으면 제맘대로 하는겁니다. 원래 일은 그렇게 하는거임.

전투 화면은 좀 더 섬세하게 봤습니다.
일단 그리드가 손가락으로 선택할 수 있을만큼 작아야 합니다. 크면 좋지만 답답하고, 너무 작으면 선택하기 짜증나지요.
약간 작다 싶은 정도로 조절했습니다. 손가락으로 덮을만큼 되는 사이즈이지만, 후후후후 걱정마십쇼 다 방법있음.

그리고 ISO 뷰를 사용하지는 않았지만, ISO 처럼 보이도록 조절했습니다. 이런 2D 스러운 카메라를 사용하면 멀리 있다고 캐릭터가 작아지고, 가까이 있다고 캐릭터가 커지는 일같은건 안 일어나거든요. 조작이 쉬워집니다.
이렇게 하면 화면을 약간 기울여도 돼요. 화면이 이뻐지고, 컨트롤도 편해집니다. 그리고 덕분에 캐릭터 사이즈도 좀 수정했지요.
몰려 있을때 좀 걱정이 안되는 것도 아닙니다만… 일단 컨트롤은 됩니다.

그렇게 해서 나온게 이 뷰. 45도로 기울였기 때문에, 캐릭터가 움직일 수 있는 그리드가 안짤리고 최대한 보여진다는 것이 장점 :)
그러면서도 가까이 있는 타일과 멀리 있는 타일의 크기가 다른 것도 아니고, 어느 정도 언덕이 있어도 선택 가능한 각도입니다 :)
캐릭터도 살짝 줄여서 웹게임과 비슷하게 만들었지요.

인터페이스 조작은 이렇게 바꾸겠습니다.

인터페이스 조작이 지금 가장 안좋은 부분이더군요. 게임에서 인터페이스가 안좋으면 게임 전체가 안좋아 보이지요.
모바일 기기의 특성을 거의 살리지 못하고 만들어져 있어서, 이건 대대적으로 뜯어야 할 것 같습니다.
조작은 가능하면 필드와 전투맵을 동일하게 만들고 싶지만, 애석하게도 완벽히는 못할 것 같네요.

일단 필드

이동은 원클릭입니다. NPC 선택도 원클릭.
좀 미묘하지만 그런대로 동작합니다. NPC 선택의 맛이 좀 딸린다는 단점이 있어서 나중에 섬세하게 볼 때에는 조절이 필요할지도 모르겠습니다.
조이스틱 이동도 가능합니다.
조이스틱은 다운이 많이 되면 지스타때는 빼버리니다.
화면 회전은 원클릭 - 드래그 였었습니다만, 버튼식으로 바꾸겠습니다.
이건 전투때의 인터페이스와의 통합을 위해서입니다. 전투 때에 화면을 돌릴 일이 없지 않은가? 라고 했더니 높은 산 속 굽이굽이 있는 맵 같은 경우는 회전이 중요하다고 하시네요. 전투 때 화면 돌리는게 필요하다면, 결국 고심끝에 좌우 버튼식으로 만들기로 하였습니다. 단 ‘다운’ 만을 인식하게 해주세요. ‘업’ 이 인식되면 안됩니다. 드래그해서 저 버튼 영역까지 손가락이 가도 작동하면 안됩니다. 이거 중요하죠.
전투 때와 필드때의 인터페이스 통일을 위해서 , 눈물을 머금고 버튼을 추가했습니다.
좌우 회전 버튼이 추가되었습니다.

전투시에

턴제이므로 이동은 클릭드래그 - 업 일때를 인식하게 하겠습니다.
화면이 작고 그리드를 손가락으로 가릴 수 밖에 없게 됩니다. 손가락을 세워서 정성들여 클릭해야 하는 지금의 방법으로는 게임하기 힘듭니다.
대신 그리드 이동시에 가이드라인이 나와서, 캐릭터 이동을 쉽게 도와주는 방식으로 하겠습니다.
이것은 ‘식좀’ 에서 차용한 아이디어로, 모르겠으면 식좀해보세요!!!! 강추게임!!!!
대충 이정도면 게임할때 무리가 없는 사이즈입니다. 제 손이 좀 작긴 하지만…
이렇게 하면 이동하고 예 아니오 물을 필요 없습니다.
영역을 벗어나거나 이동불가 지역에 가면 가이드라인를 없애 버립니다.
아님 더 연하게 해버리거나…
적 위에 있을 때에는 가이드 색을 변화시킵니다.
뻘겋게!!!!
저 뻘건 사각형도 , 내가 선택한 몬스터만 나왔으면 좋겠어요.
공격 가능한 몬스터는 그냥 색 전체를 뻘겋게 번쩌억 번쩌억 대지요.

아님 대면서 이렇게 이름과 초상화가 나와도 굿.

책략..은 어떻게 씁니까? 그러고보니 그걸 안봤네. 슬쩍 보느라 그래요.

전투 스크롤은 두 손가락으로 합니다.

요게 필드에는 없는 컨트롤입니다. 이건 튜터리얼때 꼭 얘기해 줘야 할 내용이예요.
두 손가락으로 스크롤하면 화면이 스크롤됩니다.
단! 지금처럼 가상 조이스틱 컨트롤은 안됩니다. 악셀레이션이 먹어서 사람들의 예상과 달라져요!
그냥 스크롤로 만드세요!!!
물론 이걸로 버튼 터치같은건 다 안되어야 겠지요?

그 외에도 세세한 컨트롤이 보입니다.
지금 전부 클릭 컨트롤로 되어 있어서, 인터페이스가 매우 아마추어틱하고 불편한 것들이 보입니다.
이것도 클릭클릭으로 되어 있더군요.
저 소지품창. 장수목록… 클릭하기 힘들고 느낌도 안좋습니다.

이런 것들도 버튼클릭 - 드래그 , 터치 업 식으로 선택하면 훨씬 맛깔스러울 텐데요.
이런 것들이 제대로 되어 있는게 없어서 무척 아쉽네요.

슬쩍 본것들만 이정도입니다. 자세히 보면 더 많겠지요. 하지만 우선 이것들부터 진행해야 할 것 같습니다.
사실, 진행중입니다.
부끄럽구요. 관심은 자제해 주세요.

ps.
지스타 때문에 이번에는 안되겠지만, 퀘스트 받으려고 캐릭터에 카메라가 가까이 가는데,
이걸 굳이 가까이 갈 필요 없이 그냥 게임 화면으로, 약간 확대시켜 놓고 퀘스트를 받으면 (필요하면 NPC 작은 초상 하나 첨가)
캐릭터의 텍스쳐를 256*256 으로 갈 필요가 없습니다.
이렇게 바꾸면 전 캐릭터를 128*128 로 해도 충분해요. 오히려 더 자연스러워 질겁니다.
이것도 진행해볼 생각입니다. (지스타 끝나고)

SSS 쉐이더 만들었어요 뿌우

Wed, 19 Oct 2011 10:31:11 +0000

SSS (Subsurface Scattering : 표면하산란(表面下散乱)) 이란, 피부와 같은 재질에서 피부 안쪽의 재질이나 색깔이 밖으로 비쳐보이게 되는 현상을 의미합니다. 사실 굉장히 복잡다난한 규칙이지요.

우리 피부는 사실 완전히 불투명하지 않습니다, 사알짝 반투명하지요. 그래서 핏줄이 보이는거고, 혈색이 도는 거지요.
빛은 우리 피부에서 일부는 반사되고 일부는 통과되며, 일부는 피부 안의 조직등에 반사, 흡수되는등 다양한 조작이 일어나게 됩니다.

출처 : https://graphics.stanford.edu/wikis/cs348b-08/ihkfinal

때문에 우리 피부는 살짝 반투명하며, 그것은 특히 빛을 등지고 있을 때 선명하게 나타나곤 합니다.
이것이 살아 있는 피부와 마네킹의 차이이며, 컴퓨터 그래픽스에서도 이것을 표현하기 위해 많은 노력을 해 왔었습니다.

극단적으로 얘기하면, 저 위의 귤과 소 모형의 차이라고 할 수 있을 것입니다.
귤은 빛이 투과되고 산란된 반면, 소는 빛에 의해 어떠한 투과현상도 일어나지 않았습니다.

http://gurneyjourney.blogspot.com/2008/05/subsurface-scattering.html

컴퓨터 그래픽스에서는 이미 이런 표현을 위해 많은 논문들이 발표되어 왔었습니다.

이미 몇 년 전에 NVIDIA에서 발표된 “Human Head Demo” 는 이 효과를 극대화해서 리얼한 사람 피부를 리얼타임으로 구현해 내는데 성공했습니다. 8800 Ultra에서 돌아가는 이 피부 효과를 슬쩍 본 적이 있는데, 생각보다 많은 기법이 들어가 있었습니다.
대표적인 기법이라면 역시 텍스쳐 레이어 …
피부의 깊이감 효과를 위해서 레이어 텍스쳐를 여러 장 만들어 블러시켜서 덧붙인다던가 ,
또는 빛이 들어오는 경계선 부분의 RGB를 산란시켜 SSS 느낌이 나오게 한다던가 등의 수준높은 기술들이 구현되었지요.
(자세히 안봤습니다 . 슬쩍 봤다니까요 ㅋ)

하지만 최근 MMO에서는 이정도까지 쓰는건 솔직히 좀 무리 … 가 있지요.
때문에 대부분의 게임에서는 Fake SSS 로 , 비슷하게 구현을 하도록 하였습니다.

마비노기 영웅전 같은 경우에서는 Diffuse 의 색상이 어둡게 되는 경계선 부분에 붉은 색을 칠해주는 방식을 사용했었습니다.
http://codevania.springnote.com/pages/3418155.xhtml
에서 소개한 방식과 같지요.
GPU Gem 에서도 소개된 방법입니다.
http://http.developer.nvidia.com/GPUGems/gpugems_ch16.html

이것은 일종의 warp lighting 계열로도 표현할 수 있는 방식입니다.

언리얼에서 이번에 발표한 데모 ‘사마리아인’ 에서는 좀 더 수준높은 SSS가 구현되었습니다.
유명한 그래픽 칼럼리스트 니시카와 젠지는
“이것은 통상의 거울반사 모델과 확산반사 모델을 조합한 통상의 라이팅을 한 결과와 그것을 색변조규칙(色変調規則)을 기준으로 화면좌표계(画面座標系)로 blur 시킨 것을 합성하여 구현하고 있다. 색변조규칙이란 한 점을 빛이 투사했을 때 그 빛이 피부에 침투, 확산하여 색이 변한 뒤(주로 빨간 경향을 띈다) 재차 출사(出射)한 측정결과에 근거한다”
이라고 설명했었지요.

테라에서는 정확히는 알 수 없지만 일단 기술강연에서는 ‘전체적으로 피부 부분에만 붉은색을 추가했다’ 라고만 발표했지요.
어쨌거나 굉장히 값싸게 표현했다는 것은 알 수 있습니다.

뭐 그래서 저희는 어쩌지… 라는 고민끝에,

기본적으로는 에미시브가 아닌 라이팅에서 적색 (혹은 지정된 색) 라인 추가
마스킹에서 텍스쳐를 사용해서 데이터를 낭비하고 싶지 않기 때문에, 붉은 색의 vertex color를 마스킹으로 이용. 당연하게도 붉은 색이 연하면 SSS도 연하게 적용된다.
동시에 여자 캐릭터 (혹은 요정류) 를 위한 half-rambert 조절자 추가. 역시 이것도 vertex color로 마스킹됨.
그냥 붉은 색만 추가하는 것만으로는 빛 투과 효과가 나오지 않기 때문에 Translucent 기능도 추가되어야 함.
이 모든 것은 최저 데이터와 가벼운 계산을 목표로 함

정도로 정하게 되었습니다.

일단, 계산양을 줄이고 싶었기 때문에 SSS 도 복잡한 함수를 사용하지 않고,
기본으로 계산된 빛 계산 공식인 Lambert의 값을 그냥 사용하고 싶었습니다.
이것은 어셋 스토어에서 25$나 주고 결재한 쉐이더 세트를 분석해서 도움을 받았지요 ㅋ

일단 그냥 Lambert

이 값을 뒤집고 Pow (쉐이더에서의 파워는 X^Y 를 의미합니다) 와 Multi로 강하게 만들고 다시 색을 넣어서 SSS 기본 완성.
다시 이걸 Lambert와 곱해서 SSS 구현.

짠.

간단합니다. 때문에 Lambert 의 계산값이 바뀌면 SSS에도 영향이 좀 갑니다만, 익숙해지면 그러려니 할 수 있는 레벨입니다.

pow 값은 넓이를 조절하고,
multi값은 강도를 조절합니다.

여기에 또 하나 추가된 기능은 Half Lambert.
하프 라이프2 에서 사용되고 발표된 , 대인배 밸브횽아가 발표한 새로운 렘버트 방식으로, 이걸 사용하면 빛이 부드럽게 넘어가는걸 아주 간단하게 구현할 수 있어서 여자 캐릭터한테 좋습니다. 단 노말 같은게 좀 평평해지는게 단점.

그래서 이걸 조절할 수 있게 만들었지요.
이렇게 조절됩니다.

적절하게 이용하면 Translucent 기능까지 흉내낼 수 있지요.

좀 더 반투명한 느낌이 나게 할 수 있습니다.

그리고 이것은 피부와 같은 재질 전용이기 때문에, 마스킹이 필요한데요.
이것은 vertex color로 처리하였습니다. 텍스쳐 용량을 늘이지 않기 위해서요.

일단 검은색으로 바꾸고, 피부인 부분만 붉은색으로 올려주면 됩니다.
연한 붉은색으로 하면 연하게 먹지요. 피부가 투명하면 진한 붉은 색으로, 조금 불투명한 부분은 연한 붉은 색으로 섬세하게 조절할 수 있게 해 놓았습니다.

그럼 이렇게 적용됩니다.

아직 역광 상태일때 더 빛나는 Translucent 기능은 제작되지 않았습니다. 이건 조금 지켜보고 추가하려구요.

어쨌건 이걸 적용하면 이렇게 됩니다.

어허허허허. 엇 아니 이건 실수.
그렇다고 프로젝트를 다 보여드릴 수도 없으니 ㅋㅋㅋ (아직 비밀 프로젝트!)
사내게시판에는 다 올라갔지만요.
뭐 그래서 코만 일부분을 …

이랬던 코가

이렇게 됩니다. 쬐끔 쎄게 해봤음 자랑하느라.

이 아저씨도

저희 제품을 이용하시면 마치 20대같은 투명하고 탱탱한 피부를 얻으실 수 있게 된답니다.
뉴칼레도니아 센서티브 모이스쳐라이징 센서티브 딥클린 페이셜 포밍 클린징 크림

이렇게 강하게 생긴 아저씨는 half lambert 수치를 줄이는 것이 좋습니다.
half lambert는 너무 주면 노말맵의 효과가 깎이는 단점이 있거든요.

앞으로 추가할 것은 빛이 반대방향에 있을 때, 귀나 손같이 얇은 피부는 빛이 와방 투과가 되어서 빛나는 효과를 넣고 싶은데요.
요것도 그렇게 무거운 계산은 필요없어요 . 잔재주 피우느라 머리가 아파서 문제지.

http://www.zbrushcentral.com/showthread.php?21774-creature-bust&p=177760

대충 뭐 요런 거 말이죠.

하지만 뭐 일단 요걸로 끝…

SSS 쉐이더 추가

Tue, 18 Oct 2011 18:48:27 +0000

출처 : https://graphics.stanford.edu/wikis/cs348b-08/ihkfinal

http://gurneyjourney.blogspot.com/2008/05/subsurface-scattering.html

컴퓨터 그래픽스에서는 이미 이런 표현을 위해 많은 논문들이 발표되어 왔었습니다.

하지만 최근 MMO에서는 이정도까지 쓰는건 솔직히 좀 무리 … 가 있지요.
때문에 대부분의 게임에서는 Fake SSS 로 , 비슷하게 구현을 하도록 하였습니다.

뭐 그래서 저희는 어쩌지… 라는 고민끝에,

기본적으로는 에미시브가 아닌 라이팅에서 적색 (혹은 지정된 색) 라인 추가
마스킹에서 텍스쳐를 사용해서 데이터를 낭비하고 싶지 않기 때문에, 붉은 색의 vertex color를 마스킹으로 이용. 당연하게도 붉은 색이 연하면 SSS도 연하게 적용된다.
동시에 여자 캐릭터 (혹은 엘프) 를 위한 half-rambert 조절자 추가. 역시 이것도 vertex color로 마스킹됨.
그냥 붉은 색만 추가하는 것만으로는 빛 투과 효과가 나오지 않기 때문에 Translucent 기능도 추가되어야 함.
이 모든 것은 최저 데이터와 가벼운 계산을 목표로 함

정도로 정하게 되었습니다.

일단 그냥 Lambert

짠.

간단합니다. 때문에 Lambert 의 계산값이 바뀌면 SSS에도 영향이 좀 갑니다만, 익숙해지면 그러려니 할 수 있는 레벨입니다.

pow 값은 넓이를 조절하고,
multi값은 강도를 조절합니다.

그래서 이걸 조절할 수 있게 만들었지요.
이렇게 조절됩니다.

적절하게 이용하면 Translucent 기능까지 흉내낼 수 있지요.

좀 더 반투명한 느낌이 나게 할 수 있습니다.

그리고 이것은 피부와 같은 재질 전용이기 때문에, 마스킹이 필요한데요.
이것은 vertex color로 처리하였습니다. 텍스쳐 용량을 늘이지 않기 위해서요.

그럼 이렇게 적용됩니다.

아직 역광 상태일때 더 빛나는 Translucent 기능은 제작되지 않았습니다. 이건 조금 지켜보고 추가하려구요.

어쨌건 이걸 적용하면 이렇게 됩니다.

어허허허허. 엇 아니 이건 실수.

이 아가씨가
이렇게 됩니다.

옷이랑 머리에도 들어갔는데 그건 신경쓰지 마세요. 마스킹 안한 캐릭터라 그렇습니다.
코 끝 부분에 붉게 효과 나오는걸 보세요. 쬐끔 쎄게 해봤음 자랑하느라.

이 아저씨도

좀 더 혈색이 돕니다. 주름 부분에 붉게 들어간 칼라를 보세요.
이렇게 강하게 생긴 아저씨는 half lambert 수치를 줄이는 것이 좋습니다.
half lambert는 너무 주면 노말맵의 효과가 깎이는 단점이 있거든요.
그리고 굳이 SSS 를 안써도 효과가 좋은 이런 캐릭터라면, (털이 있다던가…) 굳이 이 쉐이더를 쓰지 않아도 됩니다.
옛날 캐릭터 쉐이더만으로도 충분히 멋지다면 말이죠.

이렇게 나이든 멋진 할아버지도.

저희 제품을 이용하시면 마치 20대같은 투명하고 탱탱한 피부를 얻으실 수 있게 된답니다.
뉴칼레도니아 센서티브 모이스쳐라이징 센서티브 딥클린 페이셜 포밍 클린징 크림!!!

얼굴을 자세히 보세용. 빛 돌아가는게 다르죠? 잇힝.

http://www.zbrushcentral.com/showthread.php?21774-creature-bust&p=177760

대충 뭐 요런 거 말이죠.

하지만 뭐 일단 요걸로 끝…

ps. 모든 캐릭터 쉐이더에, Vertex Alpha로 음영을 추가하는 기능이 추가되었습니다.
vertex alpha를 검게 하시면, 최종 이미지도 검게 됩니다. 머리카락 안쪽 등에 사용하실 수 있겠지요.

SSS 쉐이더 분석중...

Fri, 14 Oct 2011 09:55:47 +0000

SSS 만들어야 해서 어떻게 할까…
그냥 늘 하던 것처럼 스무스스탭으로 램버트 일정 부분에 칠해버릴까….
아니면 진짜로 텍스쳐 블러링 줘서 레이어 띄울까…
예제 없나 어디… 근본이 없는 인간이 쉐이더 짜기 너무 힘드네….
하다가

어셋 스토아에 보니 SSS 쉐이더 시리즈와 쿡 토런스, 패럴렉스 쉐도우 등 여러 기능이 다 들어있는 쉐이더와 예제 한 셋트가 단돈 25$ !!!!

어셋 스토어 짱이구만요. 우왕우왕

잽싸게 결재해서 지금 분석중.
세상 참 좋아졌네.

위대한 게임의 탄생 (Making Great Game) 책이 나왔습니다.

Thu, 13 Oct 2011 09:16:19 +0000

제가 4번째로 번역한 책 ‘위대한 게임의 탄생(원서 : Making Great Game)’ 이 나왔습니다.

알라딘 링크

박PD 님이 번역한 책.
한국판에는 외국 게임들과 함께 마비노기 시리즈를 비롯한 한국 유명 게임들도 추가되었습니다.
이건 사 줘야 합니다.

절대 아틀란티카 부분이 제가 써서 그런게 아니라는 … ㅋㅋㅋ

캐릭터 쉐이더 백업

Tue, 11 Oct 2011 16:20:05 +0000

캐릭터 쉐이더 재작업으로 인해, 기존 쉐이더 백업

Shader “AT2/Char/Main” {

Properties {

_Color (“Main Color”, Color) = (1,1,1,1)

_SpecColor (“Specular Color”, Color) = (0.5, 0.5, 0.5, 1)

_Shininess (“Shininess (Normal.b)”, Range (0.01, 1)) = 0.078125

_SpecColor1 (“Camera Direct SpecColor (Only Forward)”, Color) = (0.5, 0.5, 0.5, 1)

_Shininess1 (“Camera Direct Shininess (Only Forward : Normal.b)”, Range (0.01, 1)) = 0.078125

_MainTex (“Base (RGB) Alpha (A)”, 2D) = “white” {}

_Normalmap (“Normalmap”, 2D) = “bump” {}

_EmissionLM (“Emission (Lightmapper)”, Float) = 0

_UpperGlobalLight (“UpperGlobalLight”,Color)=(0.0,0.0,0.0,1)

_LowerGlobalLight (“LowerGlobalLight”,Color)=(0.0,0.0,0.0,1)

_RimColor (“Rim Color”, Color) = (0.26,0.19,0.16,0.0)

_RimPower (“Rim Power”, Range(0.5,8.0)) = 3.0

_Reflection (“Reflection Texture”, CUBE) = “grey” {}

//~ _Cutoff (“Alpha cutoff”, Range (0,1)) = 0.0

}

SubShader {

//Tags{“Queue”=“AlphaTest” “IgnoreProjector”=“True” “RenderType”=“TransparentCutout”}

Tags{

“RenderType”=“Opaque”

}

LOD 600

Cull Off

ZWrite On

//AlphaTest Greater [_Cutoff]

CGPROGRAM

#pragma surface surf BlinnPhong alphatest:_Cutoff vertex:vert

#include “UnityCG.cginc”

#pragma target 3.0 // it’s for prevent “arithmetic instruction limit” -JP-

#pragma only_renderers d3d9

sampler2D _MainTex;

sampler2D _Normalmap;

samplerCUBE _Reflection;

float4 _UpperGlobalLight;

float4 _LowerGlobalLight;

float4 _Color;

//~ float4 _SpecColor; // Declare previous (another file)

float _Shininess;

float4 _SpecColor1;

float _Shininess1;

float4 _RimColor;

float _RimPower;

struct Input {

float2 uv_MainTex;

float2 uv_Normalmap;

float3 viewDir;

float3 viewDirWorld : TEXCOORD2;

float3 LightDirWorld : TEXCOORD3;

float3 normalWS : TEXCOORD4;

float3 tangentWS : TEXCOORD5;

};

void vert (inout appdata_full v, out Input o)

{

o.viewDirWorld = mul( (float3x3)_Object2World, -ObjSpaceViewDir( v.vertex ) );

// we transform the normal and tangent in world space as well

o.normalWS = mul( _Object2World, float4(v.normal,0) ).xyz;

o.tangentWS = mul( _Object2World, float4(v.tangent.xyz,0) ).xyz;

o.LightDirWorld = WorldSpaceLightDir( v.vertex );

}

void surf (Input IN, inout SurfaceOutput o) {

//Main Texture

float4 tex = tex2D(_MainTex, IN.uv_MainTex);

float4 c = tex * _Color;

o.Albedo = c.rgb;

// Make Normal : World Nomal

float4 NormalTex = tex2D (_Normalmap, IN.uv_Normalmap);

o.Normal = (float3(NormalTex.r,NormalTex.g,1)*2.0f-1.0f);

o.Normal = normalize(float3(o.Normal.r,o.Normal.g,o.Normal.b));

float3 binormalWS = cross( IN.normalWS, IN.tangentWS ) ;

float3 WorldNormal;

// Make World Nomal : Normal Inverse Test

if ( 1.0 == sign(IN.uv_Normalmap.x-1.0f) )

{

WorldNormal= o.Normal .x * normalize(IN.tangentWS);

WorldNormal += -o.Normal .y * normalize(binormalWS);

}

else

{

WorldNormal= o.Normal .x * normalize(IN.tangentWS);

WorldNormal += o.Normal .y * normalize(binormalWS);

}

WorldNormal += o.Normal .z * normalize(IN.normalWS);

WorldNormal= normalize(WorldNormal);

// Make GI Color

float GITerm =saturate(dot(WorldNormal, float3(0,1,0))*0.5+0.5);

float GITermInv =saturate(dot(WorldNormal, float3(0,-1,0))*0.5+0.5);

float3 GIColor = (_UpperGlobalLight.rgb* GITerm ) + (_LowerGlobalLight.rgb * GITermInv );

// Make second Specular

half3 h = normalize( WorldNormal - IN.viewDirWorld );

float nh = saturate( dot( h, WorldNormal ) );

float spec = pow( nh, _Shininess1 *256) *NormalTex.b ;

float3 CameraSpecColor =_SpecColor1.rgb * GIColor * spec;

// Make Rim Light

float Fresnel= 1.0 - abs(dot( normalize( float4(-IN.viewDirWorld, 1.0).xyz), WorldNormal) ) ;

float rim = (pow(saturate(Fresnel+ 0.3) ,_RimPower)) ;

float3 rimlight = rim* _RimColor.rgb * GIColor;

// Reflection

float3 reflectVec = reflect( IN.viewDirWorld ,WorldNormal);

float3 ReflectTex = texCUBE (_Reflection, reflectVec ).rgb;

ReflectTex *= 1-NormalTex.a;

o.Albedo = lerp (c.rgb, ((ReflectTex*3) * (c.rgb*0.5) ), 1-NormalTex.a) ;

o.Emission = (c.rgb * GIColor)+CameraSpecColor + (rimlight*0.8);

o.Gloss = NormalTex.b;

o.Alpha = 1;//tex.a* _Color.a;

o.Specular = _Shininess ;

}

ENDCG

}

FallBack “Self-Illumin/Specular”

}

StaindGlass 쉐이더 제작

Tue, 11 Oct 2011 15:19:07 +0000

들어가는 데이터는 텍스쳐 3장입니다. 베이스 텍스쳐와 노말맵, 큐브맵입니다.

기본값은 아마 이거보다는 밝을겁니다. 일단 base맵만 보이게 옵션을 해 놓으면, 큐브맵과 합성된 베이스맵이 나오게 됩니다.
사실 굴절을 넣어야 하지만, 반사벡터를 넣었습니다. 원래 물리학적으로 이러면 안되겠지만, 사실 제대로 구별하는 사람은 거의 없습니다.

스페큘러 칼라와 수치를 조절하면 이런 모양이 나오게 할 수 있습니다. 빛 들어오는 반대편의 유리창은 이런 식으로 셋팅해 주시면 되겠지요 .

하지만 빛들어오는 방향의 유리라면 이렇게, Emissiove value 를 올려주시면 빛나게 됩니다.
이것만으로도 괜찮지만,

더 눈부신 효과를 원하신다면 Reflection Color를 살짝 올려주세요. 특정 색으로 번지는 모습을 보실 수 있으십니다.

블룸같은 후처리 효과까지 적용되면 대충 이 모습.

물리학적으로 완벽하진 않지만 이 정도면 보기엔 이쁘고 문제 없심다. 잇힝.
나중에 저사양용도 만들어야 할 듯.

구리시에서 불꽃놀이를

Tue, 11 Oct 2011 07:37:46 +0000

그젠가는 바로 앞 선사유적지에서 축제라고 불꽃놀이를 했는데 오늘은 강건너 구리에서 불꽃놀이를 하네요
가만히 앉아서 모든 불꽃놀이를 감상할 수 있는 우리 집은 명당 (…)

요즘엔 하트나 스마일같은 모양불꽃이 유행인가봐요. 일요일에도 이런거 나오더니.
굉장히 기술적으로 정밀해야 가능하단 얘길 들은 적이 있는 것 같은데.

뭐 불꽃놀이 사진은 아주 좋은 카메라 아니고서야 누가 찍어도 비슷비슷하니까…

Gold & Metal Shader 추가

Mon, 10 Oct 2011 15:11:53 +0000

AT2에서 금코끼리에 사용했던 char 쉐이더를 대용할 쉐이더를 제작하였습니다.
char 쉐이더는 캐릭터만을 위해 제작되는 쉐이더로, 다양한 기능들이 들어가거나 변화될 것을 예상해야 하기 때문에
배경에서 사용되는 것은 권장되지 않으므로, 지금과 같이 테스트용으로 사용하시는 것은 상관없으나 지속적으로 사용하는 것은 곤란하므로 따로 제작하였습니다.

제작방법은 char 쉐이더를 바탕으로 하여, 쓰지 않은 기능과 쓰면 곤란한 기능들을 삭제하여 제작하였습니다.
이렇게 몇몇 기능들을 삭제하여 만든 쉐이더는, 이전에 사용하셨던 char 쉐이더와 외형은 동일합니다.

새로 만든 쉐이더는 사용되지 않은 기능인 리플렉션 기능이 삭제되었으며,
사용하면 조금 곤란한 글로벌 라이트 기능이 삭제되었습니다.

또한 노말맵도 캐릭터에서 사용하던 녹색 노말맵이 아닌, 정상적인 푸른색 노말맵을 사용하도록 교체되었습니다.
때문에 스페큘러 마스킹은, 노말맵의 알파 채널을 이용하도록 만들어졌습니다.

알파는 지원하지 않습니다.

AT2_GoldMetal 쉐이더를 사용하시면 됩니다.
노말맵고 ㅏ림라이트와 이중 스페큘러가 사용가능한 쉐이더가 되겠습니다.

Unite11 : 유니티 컨퍼런스 2011 2편

Sat, 08 Oct 2011 12:58:57 +0000

Unite11 : 유니티 컨퍼런스 2011

2번째 시간입니다. 기조강연 끝내고 …
이번에 출시된 ShadowGun 이라는 게임의 포스트모템과
“How to make your Art POP” 이라는 강연을 들었습니다.
shadowgun은 아직 공개되지 않은 3.5 유니티 엔진에 들어갈 기능을 사용해서 만들었던데요.

아오 밝은 렌즈를 사던가 풀프레임 바디를 사던가 해야지 이거 빡쳐서.

일단 뭐 커다란 회사는 아닙니다만.

그냥 간단히 말하자면 아이폰용 기어즈워.
근데 퀄리티가 그런대로 괜찮아요.

솔직히 색감은 좀 싸보였지만 기술이 딸린게 아니라 디자이너가 딸린 것 같달까.

아이폰과 아이패드에서 돌아갑니다.

별 짓 다해서 최적화 시켰어유.
하지만 아이패드 2는 열라 좋아서 4*MSAA (안티 알리아싱) 까지 하고도 100프레임이 나오더라능!!! 우와!

그렇게 하기 위해서 기본 쉐이더 안썼구요.
직접 수작업으로 짠 핸드 옵티마이즈 쉐이더를 가카처럼 꼼꼼하게 이용해야만 했어요 (주: 강하게 동감)
뭐 이렇게 저렇게 렌더링 오더도 쉐이더로 제어했고.. (주: 어떻게???)
다음 유니티에 들어가는 기능들이랍니다 .

메모리 아끼는게 중요하죠. 전부 128m 아래 녀석들이니까.
그래서 밉맵 안썼어요! (당연하지!)

라이트와 쉐이딩은, 화면빨을 위해 엄청나게 중요한 요소지요
고정된 물체는 글로벌 일루미네이션 라이트맵을 썼구요
움직이는 물체는 라이트 프로브를 이용했어요 라이트 프로브의 라이트는 SH(구면조화함수) 로 저장되어 있지요.

맵마다 1024*1024의 압축되지 않은 라이트맵을 사용했습니다 (!!!) 사이즈는 좀 작지만, 정확하고 부드럽게 나오거든요.
라이트 프로브는 한 500개 안쪽으로. 3~5미터마다 하나씩 박았죠

(… 어라 편집 잘못했다)
(바삭바삭한 텍스쳐? ㅋㅋ 아마도 알리아싱 효과를 말하는 듯 )

밉맵을 안썼으니 당근 먼거리 텍스쳐 알리아싱이 문제가 생기죠.
anisotropic 필터링을 사용했습니다. 밉맵 바이어스 설정보다 빠르고요, 퍼포먼스에 따라 옵션 조작질이 쉬워요.
게다가 포터블에서 돌아가니까요
(PC버전에서는 마지막에 쓰는 최고 옵션의 필터링인데 모바일에서는 오히려 이것만 썼다는 거군요)

가짜 스페큘러 썼습니다. 라이트맵에 의한 하이라이트는 너무 비싸거든요.
메인 텍스쳐의 알파를 마스킹으로 써서, 그냥 카메라 쪽에서 보이도록 대충 카메라에 붙여 만들었습니다. 그것도 버텍스 계산으로.

각종 대충 표현하는 방법들로 볼륨 이펙트는 표현했심다.

아주 간단한 쉐이더로, 심지어 텍스쳐도 사용 안하는 경우도 많이 있었심다. 그냥 버텍스에 색상 줘서 처리하는 거지요 (주: 앗 이번에 하려고 한 방법인데…)
안 부드러우면 … 걍 버텍스 추가했죠 뭐.

(이건 어떻게 했다는 건가요…영어가 짧아서…잘 모르겠는 기술인데요)

캐릭터는 이정도 썼습니다. 일반적이네요

라이트 프로브에서는 버텍스 라이트로 계산하고, 이걸 픽셀라이트와 모듈레이트?

엠비언트 오클루젼! 을 이용한 캐릭터 그림자!!! 오오. 재밌네

이 두 군데에 썼습니다. SSAO 같은방식이지요

과연. 자연스럽긴 하겠다.

화면 일렁이는 효과도 넣었습니다

풀스크린 이펙트는 모바일에서 쓸 것이 못됩니다.너무 느려요
그래서 스크린보다 작게 그리드를 만들어 계산해서 썼습니다 버텍스 연산이지요

만든 그리드는 대충 이 정도.

물 표면을 움직이게 만들었군요 . 그것도 인터렉티브하게 ㄷㄷㄷ

알고리즘 설명중.

물 표면의 쉐이딩 얘기입니다. 넣을건 다 넣었네요. 이 계산이 돌아간단 말인가…

이렇게 끝냈습니다. 한 번 다운받아 봐야겠군요 :) 잘했네요.

이어서 빅포인트의 AD가 어떻게 디자인을 잘할거냐 설명. 요건 뭐 짧게 하겠습니다.

대충 요런 일반적인 내용이었거든요.
교양에 가까운.

그중에 조금 인상깊었던건, 아트 포커스를 맞추는 부분에서, 종족별 실루엣을 디자인 하는 장면이었습니다. 제가 좋아하는 스타일이기도 하고.

효율적인 아트라.

간단해요. 요건 옵션별로 타협할 그래픽을 의미하는 거였어요

그런 식으로 이런걸 만들었다죠

이런 식으로 디자인했구요

대충 이런 얘기였습니다. 자신의 경험을 주로 얘기하는 시간이었어요

모바일 필드에서 그림자 사용하기 : Auto Change Shader

Fri, 07 Oct 2011 10:23:04 +0000

모바일 필드에서 실시간 그림자는 당근 사용 안됩니다.
그림자가 있는것 처럼 멋지게 만들어주는 제일 좋은 방법은, 사실 맥스에서 모든 배경 데이터를 제작하는 것입니다!
그리고 렌더 투 텍스쳐로 모든 빛 효과를 텍스쳐로 구워 버리는 것이지요.
인피니티 블레이드에서 사용했던 방법이기도 합니다. 맥스를 이용하세요 맥스를!

… 그치만 우리 게임은 웹 연동이라서 그렇게 할 수 없습니다. 어쩔 수 없이 에디터에서 건물을 찍어줘야 해요. 수정도 가능해야 하고요. 그렇기 때문에 인피니티 블레이드에서 사용했던 방법은 쓸 수 없습니다.

그렇다면 그림자를 뽑아내는 방법은? 라이트맵 기능으로 베이킹 해놔야 하는 것입니다! 그렇게 하면 그림자가 베이킹 되어서 그림자를 표현할 수 있게 됩니다!

… 또다시 그렇지만 , 라이트맵 굽는 기능은 시간이 너무 많이 걸립니다. 몇 시간씩 걸리기 때문에 하염없이 8층에서 아메리카노를 빨면서 기다려야 한다던가, 수정 한 번 할때는 밥먹고 와야 하는 일까지 생겨 버립니다. 게다가 라이트맵의 정밀도가 그렇게 높은 편이 아니라서, 자질구레한 오브젝트의 그림자는 또 안나오게 됩니다.

게다가 모바일에서는 어차피 지형 텍스쳐의 블렌딩이 이루어 지지 않기 때문에 (모바일4터레인을 사용하면 되긴 하지만 더럽게 느리지요) 통짜 텍스쳐를 이용하고 있어서, 그냥 웹용으로 만든 지형을 TOP에서 캡쳐해서 사용하고 있습니다. 무식하지만 효율적이지요.
그러니까 여기서 아이디어는, 그림자를 실시간으로 나타나게 한 다음에 그림자만 남기고 건물만 사라지게 하면 아주 빠르고 효율적인 라이트맵 비스무리한게 만들어진다는 것이지요.
그래서 만든스크립트. Auto Change Shader 입니다.

간단히 버튼을 눌러주면 쉐도우 쉐이더로 체인지 됩니다.
언두 같은거 안됩니다. 큰거 기대 마세요. ㅋㅋㅋㅋ

해보면 어려운 작업 아닙니다. 이 상태에서도 그림자 속성을 모두 실시간으로 바꿀 수 있습니다.

이렇게 간단하게 라이트맵이 추출되었습니다. 단점이라면, 건물에는 이 그림자맵이 적용되지 않기 때문에, 건물의 하단부 (혹은 그늘진 부분) 에는 적당히 어둡게 눌러줘서 이질감이 없도록 해줘야 한다는 것입니다.
혹은 그림자의 농도를 적당히 연하게 해서 자연스럽게 만들어 주는 것도 좋은 방법 같습니다.
맵 텍스쳐와 함께 베이킹 되는 것이기 때문에, 따로 그림자를 수정할 수 없는 것은 단점이긴 합니다.

또한, 이 방법을 이용하면 군데군데 포인트 라이트 등을 박아서 지형의 느낌을 좋게 만들 수도 있습니다. 이 모든것이 실시간이기 때문에 수정이 용이하고, 매우 편리합니다. (건물 근처에 너무 티나게 박으면 좀 곤란하겠지만요 ㅎㅎ)

모바일 필드에서 그림자 사용하기 : Auto Change Shader

Fri, 07 Oct 2011 10:21:11 +0000

이전에 만든 쉐이더 체인저에 버튼만 추가했습니다. 이전 것은 Diffuse Fast 로 만든 오브젝트를 vertexlit 쉐이더로 자동으로 만들어주는 스크립트였지요 - 생각해보니 모바일에서는 별 필요가 없겠군요. 삭제를 고려해야겠습니다 -
아래 버튼이 일명 ‘쉐도우 쉐이더’ 라는 놈으로 바꿔주는 버튼입니다.
쉐이더명은 TKSpecial_ShadowOnly_mobile 이구요. 수동으로 사용할지도 몰라서 Hidden은 시켜놓지 않았습니다.

사용법은 개간단합니다.

일단 실시간 그림자가 동작하도록 만들어 놓으셔야 합니다. 이 방법은 무식한 방법이라 그림자를 따로 떼어낼 수 없기 때문에,
소프트 쉐도우 설정이나 엠비언트 칼라 등으로 색상 보정을 잘 해놔 주셔야 합니다.

그다음 적당한 크기로 오브젝트들을 선택하세요. 너무 크게 선택하면 지형까지 선택될 수 있으니 주의하세요.
하이어라키 창에서 선택하는 것도 좋겠지요

간단히 버튼을 눌러주면 쉐도우 쉐이더로 체인지 됩니다.
언두 같은거 안됩니다. 큰거 기대 마세요.

해보면 어려운 작업 아닙니다. 이 상태에서도 그림자 속성을 모두 실시간으로 바꿀 수 있습니다.

또한, 이 방법을 이용하면 군데군데 포인트 라이트 등을 박아서 지형의 느낌을 좋게 만들 수도 있습니다. 이 모든것이 실시간이기 때문에 수정이 용이하고, 매우 편리합니다. (건물 근처에 너무 티나게 박으면 좀 곤란하겠지만요 ㅎㅎ)

커밋되어 있으니 바로 사용하시면 됩니다!

모바일용 Font shader : TkMobile_Font_Headuptext

Fri, 07 Oct 2011 09:31:23 +0000

일반적으로 그래픽 파일은 RGBA 로 이루어져 있습니다.
DXT처럼 압축하지 않는 픽셀 포맷이라면 보통 채널당 8비트씩, 알파 채널이 포함된 이미지라면 32비트로 이루어져 있지요.

보통 일반적인 게임용 텍스쳐는 일단 DXT를 이용해서 낮은 비트수로 압축하기 때문에 32비트 이미지를 보기 어렵지만,
특별히 UI에 한해서는 32비트가 FULL로 사용되는 경우가 자주 있곤 합니다. 압축하면 확실히 이미지가 깨져 버리기 때문이지요.

하지만 이것이 역시 문제를 유발시키는 것이… 폰트 사이즈가 1024*1024 24bit 이미지로 압축하지 않은 이미지로 넣으면 4MB 이미지가 되는데, 이게 런타임으로 올라가면 5MB 정도 차지한다는 것입니다. 전체 쓸 수 있는 메모리 중에 그래픽에서 쓸 수 있는 메모리가 기껏해야 30메가 내외인 상태에서 , 폰트만 5MB 정도 차지하는건 꽤 큰 용량이 아닐수 없습니다.

그래서 모바일용으로 개선책을 찾다가… 그전에는 몰랐던 싱기한 픽셀 포맷이 존재한다는 것을 알아냈습니다. 아이 싱기해.
게다가 이게 PC용으로도 있어??? 뭐지 이거???


Alpha 8 bit	High quality alpha channel but without any color. 64 KB for a 256x256 texture

바로 이거. 데스크탑용으로도 있고, 모바일용으로도 있군요.
알파만 존재하는 파일 포맷입니다. 그동안 파일을 포토샵에서만 만들어 와서, 이런게 만들어지리라고는 상상하지 못했는데
유니티에서는 일단 원본 그래픽 파일을 엔진에 넣고 엔진에서 텍스쳐 포맷을 변형시키기 때문에 이런 싱기한 짓도 가능한 것입니다.
걱정되는 건 이게 GUI속성태그가 붙은 텍스쳐 타입이 아니라는 건데… 뭐 문제생기면 모바일팀에서 알아서 해주시겠 … (후다닥ㅋㅋㅋ)

어쨌건 사용이 가능해진다면, 8bit (256칼라) 이미지의 용량으로 최고의 퀄리티의 폰트를 만들어 낼 수 있겠지요.
그래서 뭐 간단히 쉐이더를 제작했습니다. 폰트명은 TkMobile_Font_Headuptext.
다행히 모바일에서는 폰트에 외각선 같은걸 그리지 않게 되어 있더군요. 폰트 칼라를 위해서 버텍스 칼라만 지원하면 되고,
PowerVR 그래픽 카드에서는 알파 블렌딩이 더 빠르니 간단하게 알파 블렌딩이 되는 쉐이더만 제작하면 되는 것이었습니다.

그래서 뭐 완성. 잘 나오네요. 메모리도 약 3M 정도 줄일 수 있었습니다.

Unite11 : 유니티 컨퍼런스 2011

Fri, 07 Oct 2011 00:22:29 +0000

총평

지난주에 유니티 컨퍼런스를 갔다 왔습니다.
전체적으로는 유니티의 발전 방향과 현재의 상황, 분위기등을 유추해 볼 수 있는 기회였습지요.
느낄 수 있는 전체적인 분위기는 크게 두 가지로 분류할 수 있을 것 같습니다.

샌프란시스코 국제공항…

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

유니티의 발전속도는 여전히 공격적이다.

유니티의 발전속도는 예전과 마찬가지로 여전히 경이로운 수준이라는 것입니다. 내년쯤에 발표된다는 3.5에서 개선될 각종 내용을 봐도 점점 범상치 않은 엔진으로 발전해 가고 있는걸 알 수 있지요.

그리고 여전히 쉬운 인터페이스와, 진보된 앱스토어등이 유니티를 기대하기 만드는 요인이라고 할 수 있겠습니다. 게다가 이제 대형 엔진으로의 도약을 위해, 대형 프로젝트를 위한 기능을 적극적으로 추가하고 있는 모습도 기대되는 요인이었습니다.

그래도 여전히 작은 프로젝트 위주의 아쉬움

그렇지만 아직까지 아쉬운 것은, 2.X 때까지의 경험 등의 이유로 - 2.X 때의 엔진은 정말로 기초적인 기능을 가진 아이폰용게임 전문 엔진이었죠 - 아직은 ‘작은, 혹은 개인 프로젝트용’ 엔진이라는 인상이 있다는 것입니다. 이것은 사실, 주로 유니티로 만든 게임들이 아이폰용 게임이었다는 이유이기도 하겠지요. 그래서인지 발표한 포스트모템 혹은 세션들이 대부분 ‘개인 개발자를 위한’ 이나 ‘아이폰 프로젝트용’ 이란 것이 아쉬웠습니다.
유일하게 제기드 얼라이언스가 웹으로 나오게 되어서 관심을 끌었네요. 아마 지금도 우리 프로젝트만큼 이 엔진을 큰 규모로 사용하는 회사는 거의 없을 것으로 보입니다.

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

그렇지만 아마도 내년부터는 판도가 뒤바뀔 것이라 보여집니다. 우리 나라를 비롯하여 점점 유니티를 이용하는 개발사들이 늘어나고 있고, 프로젝트도 중대형급으로 올라가면서 발표되는 게임의 수준도 , 컨퍼런스의 수준도 올라갈 것으로 보입니다. 여기에서 우리 게임이 선구자적 역할을 하면, 엔진 개발사의 지원과 협력도 높은 수준으로 기대할 수 있을 것으로 보입니다.

강연 내용 요약

강연은 샌프란시스코 놉힐 꼭대기에 있는 마조닉 기념관에서 열렸습니다.

기조강연은 디아블로 등을 만든 유명한 프로그래머라는데… 잘 모르는 사람입니다.

처음에 강연한 사람은 기조강연자가 아니군요. 유니티 관계자인듯 합니다.
유니티가 얼마나 잘나가고 있는지 얘기하고 있네요.

한국 지원을 그렇게 잘해주면 왜 IME가 여태까지 그렇게인건데 .

네 상도 많이 받았지요.

안드로이드에서도 나온지 얼마 안됐지만 잘나가고 있구요,

아이폰에서는 꽉잡고 있지요

유니티 어셋 스토아 설명할때는 사람이 바뀌었습니다.

유저들이 플러그인을 만들어 팔 수도 있고, 리소스를 만들어 팔 수도 있는 어셋 스토아도 가파르게 발전하고 있습니다.

예를 들어 스크립트를 노드처럼 연결하면서 짤 수 있게 해주는 플러그인이라던가

베지어 스플라인을 조절하게 해주는 기능

마치 언리얼 쉐이더 에디터처럼 노드연결로 쉐이더를 만들수 있게 해주는 스텀피 쉐이더 에디터처럼 말이죠.

이렇게 잘나가는 어셋 스토어들을 보다 편하게 개량할 겁니다. 결재도 페이팔로 하게 해주고… 게임에서 바로 쓰기 편하게 해주고 .. 블라블라.. 관심없음.

또한 하나의 API로 전 분야에서 돌아갈 수 있도록 해줄거랍니다.

분석툴도 만들어 줄거랍니다.

예를 들어 앵그리 봇 (엔진 기본 예제 프로젝트) 에서

유저가 어떻게 돌아다녔는지, 어디서 많이 죽었는지 등을 이렇게 표현해 줄겁니다.

앱 내에서의 구매도 가능하도록 지원해 줄거구요.

AAA 급 프로젝트를 위한 지원 계획도 잡혀 있습니다. 큰 프로젝트, 많은 개발자들이 일할 수 있게 하는 새로운 기준들.
SVN을 지원한다던가..

유니티 3.5를 소개합니다.

LOD 기능이 특히 강화되었습니다.
지금 수많은 집들이 보이시지요? 전혀 느리지 않습니다.

하지만 가까이 가면 상당한 디테일이지요

에디터에서 실제로 거리에 따라 LOD가 되는 모습을 보면서 정할 수 있습니다. 조절자를 드래그하면, 건물들이 LOD 됩니다.

길찾기 기능도 개량합니다.

이동할 수 있는 면을 지정할 수 있지요 (파란색)

점프하는 곳도 지정합니다.

사다리 등도 지정해서 올라가게 할 수 있지요 . 이렇게 인공지능으로 파란 색 캐릭터는 파란 깃발로, 붉은 색 캐릭터는 붉은 깃발로 이동하는걸 보실 수 있습니다.

군중 시뮬레이션도 지원합니다. 이렇게 중심을 향해 모이다가, 서로 약간씩 빗겨나가면서 충돌하지 않고 자연스럽게 서로 지나가게 됩니다.

내장된 UI도 개량하고, SVN도 지원합니다.

오클루젼 컬링도 대폭 개량했지요.

기존에 10시간 걸리던 컬링 베이킹이, 무려 5분으로 줄어들었습니다! (일동 박수)

이런 건물들이 빼곡한 도시가 있죠

카메라 프러스텀으로 잘라내면서 보면 이렇게 보이게 됩니다.
하지만 오클루젼 컬링을 이용하면, 바로 앞의 3-4개 건물만 보이게 되지요.

라이트맵도 대폭 개량합니다 .

기존의 라이트맵은, 그냥 라이트맵이었을 뿐입니다. 제대로 노말도 표현되지 않았고, 스페큘러는 당연히 표현 안되었었습니다 .
하지만 이번에 바뀌는 라이트맵은, 세부 디테일의 노말맵까지 전부 표현됩니다! 그리고 스페큘러까지도 표현됩니다!
실시간 라이트가 아닌 라이트맵일뿐인데도 말입니다!

라이트 프로브 기능도 추가됩니다.

이 그림은 쉐도우건이라고 하는 ios 게임입니다. 배경이 전부 라이트맵으로 되어 있습니다만,
노란 불 아래 가면 캐릭터도 노랗게 되고, 녹색 근처에 가면 캐릭터도 녹색이 됩니다! 라이트가 없는데도! 라이트맵인데도요.

그 비밀은 이렇게 맵 군데군데 박아 놓은 공 - 라이트 프로브 - 에 있습니다. 이 공은 라이트가 있었을때의 색을 저장해 놓고 있다가, 캐릭터가 가까이 접근하면 자기의 칼라를 캐릭터에 투사합니다. 캐릭터는 이 공들 사이를 보간하면서, 라이트가 마치 있는 것처럼 영향 받습니다.

그래서 결과적으로 ios에서도, 라이트 없이 주변광 영향을 시뮬레이트 할 수 있게 됩니다.

감마 콜렉션도 들어갑니다.

(주: 만세! ㅠㅠ . 아니 뭐 생각해 보니까 지금도 만들 수 있…)

이 그림이 감마 콜렉션이 들어간 그림입니다. 감마 콜렉션은 출력된 리니어한 색상의 그래픽 데이터를 모니터의 색상분포값에 맞춰줘서 훨씬 자연스러운 느낌이 나게 해 줍니다.

이게 없을때입니다 .

HDR 연산도 들어갑니다
(주: 이 복잡한걸 이렇게 짧게…)

또한 기존의 CPU 프로파일러 외에, 높은 그래픽을 위하여 GPU 프로파일러를 따로 지원합니다. 이것으로 그래픽 카드에 병목현상을 감지할 수 있게 됩니다.

그외에도 멀티 쓰레드 렌더러나 새로운 메모리 관련 개선, 수많은 최적화로 훨씬 빨라지게 됩니다.

슈리켄 (주: 표창) 이라고 하는 파티클 시스템이 들어갑니다.

다양한 움직임과, 2중 3중 이상의 연속적 노드를 가진 완전히 새로운 파티클 시스템입니다.

당연하게도 메쉬도 파티클로 쓸 수 있고, 베지어 그래프로 각종 옵션들을 애니메이션 시킬 수 있습니다.

그 외에도 많… (커스텀 오디오 필터??)

그리고 또하나 보여드리죠.

앵그리봇이 플레쉬로 돌아가는 장면입니다! 이건 지금 swf로 만들어져 있습니다! 우리 엔진은 이제 플레쉬로 포팅이 가능해 질것입니다! (일동박수)

이제 진짜 기조강연을 듣기로 하죠.

골든 에이지. (황금시대)

무려 블리자드 노스의 대표로군요. 그것도 10년동안. 플래그쉽 설립자이기도 하고.

이건 뭐 진짜로 요약만 하죠

네트웍의 혁명으로 황금시대가 열리고 있죠

그래픽도 혁명입니다

입력장치도

배포도

다음 황금시대는 뭘까요? 이런게 예상되지요

인스톨이 필요 없을 겁니다. 브라우저 게임이 콘솔 수준이 될거예요
컴퓨터의 미래를 타블렛에서 보지요
어디서나 어떤 디바이스에서나 게임 접근이 가능해요
당신의 게임을 할 유저를 쉽게 구하지요

새로운 황금시대를 컨트롤 하세요!!

그리고 유니티는 이 모든 조건을 충족하고 있습니다!!!

땡큐

이렇게 아주 긴 기조연설이 끝났습니다. 예정시간보다 훨씬 더 길게 되어 버리는 바람에, 뒤의 강연들이 전부 오후로 밀려 버렸을 정도였지요.

나머지 강연들은 심플합니다. 이미 아는 내용이거나, 작은 프로젝트이거나, 광고이거나…
세션의 양이 아직 부족함을 알 수 있습니다 .이 정리는 다음에 하지요.

thx. Steve

Thu, 06 Oct 2011 09:43:21 +0000

삼국지를 품다 동영상 유니티 엔진 사이트에 공개.

Wed, 05 Oct 2011 11:08:06 +0000

삼국지를 품다 게임 동영상이 유니티 사이트
http://video.unity3d.com/video/3440891/epic-of-the-three-kingdoms

에 공개되었습니다.

으악. 퍼오기가 안된다.

샌프란시스코 케이블카 여행

Mon, 03 Oct 2011 20:07:32 +0000

여행까지는 거창하고…

컨퍼런스 장소였던 놉힐의 마조닉 센터가 옴니호텔에서 무척 높은 위치에 있었기 때문에, 오갈때 케이블카를 사용하는게 유리했습니다.

또한 포웰 스트리트에서, 애플센터와 피셔스 후프를 연결하는 라인으로 갈아탈수도 있어서 좋았지요.

특히 밖에 매달려가는게 제맛.

포웰 스트리트는 하도 갔더니 거의 가락시장역만큼 익숙해졌다는 .. .

[#VIDEO|20111003201000015128911701.jpg|pds/201110/03/03/|mid|640|360|pds22#]
요건 애플스토아쪽 - 마켓 스트리트로 가는 장면.

[#VIDEO|20111003201000015129231701.jpg|pds/201110/03/03/|mid|640|360|pds22#]
요것도 마켓 스트리트로 가는 장면 같은데, 언덕에서 내려갈때 롤러코스터를 타듯 내려가는 장면을 보실 수 있습니다.
브레이크 잡는 모습도 볼 수 있구요. 샌프란시스코의 언덕은 유명하니까요.

[#VIDEO|20111003201000015129551701.jpg|pds/201110/03/03/|mid|640|360|pds20#]요건 밤에 호텔로 돌아갈때 밖에 매달려 가는 장면입니다.

제가 내린다고 하니까 차장이 못내려준다고 장난치면서 대화하던게 녹음되어 있네요 ㅋㅋㅋ

타는 법은,

그냥 탄다 : 안걸리면 그냥 타시면 됩니다. 중간중간 있는 케이블카 정류장에서 기다렸다가 대충 선 것 같으면 차장한테 눈치주고 타면 됩니다 . 타고나서 표 보여달라고 그러면, 그 때 6$ 내면 됩니다. 편도에 6천원이 넘다니! 비쌉니다. 이렇게 타는건 완전 손해.

보통 블럭마다 하나씩 있습니다.

그래서 케이블카를 이용하려면 추천하는 방법이

정기권을 구입한다 : 종점에 보면 티켓 판매처가 있습니다 . 여기서 원하는 정기표를 사는게 훨씬 싸지요.
3일권을 샀는데 21$ …

입니다.

여기서 삽니다.

3일권이므로, 해당하는 월과 일을 스크래치 해서 보여줍니다.
사실 뭐 대부분 대충 보니까 스스슥.. 해도 … ㅎㅎ

아주 이쁘고 재미있습니다. 또한 이 표를 사면 뮤니버스도 공짜로 탈 수 있지요.
뮤니버스 노선보다는 케이블카 노선이 직관적이고 , 갈만한 곳을 다 가서 사실 한 번도 이용 안했습니다만.

잘 있습니다.

Thu, 29 Sep 2011 20:33:05 +0000

샌프란시스코에서 …

가는 동안은 시차조절을 좀 잘못해서 무척 힘들었습니다. 10시간이 넘는 비행기는 무조건 졸린채 타야 하는데…

강연 자체의 수준은 으악 … 역시 …. 시to the망

너무 원론적인거 아니면 그냥 주저리 주저리 자기자랑이 너무 많더군요.

뭐 예상했지만 그래도 이것보단 좀 잘할 수 있잖아.

결코 제가 못알아들어서 재미없었다고 이러는거 아닙니다.

이번 여행의 수확은 케이블카가 엄청 편한 거였구나 라는거 …?

주제사진을 안올리면 섭섭하지요

Unite11 강연시간표

Mon, 26 Sep 2011 22:37:44 +0000

첫날 강연

… 들을게 없네…
11시 30분 SHADOWGUN: Rendering Techniques and Optimization Challenges 은 제목은 끌리자만 내용을 모르겠고,
Advanced Reflection Techniques 와 겹침.

2:00 에는 AI는 내가 들을 내용이 아니고, 그래픽은… 섭스턴스라니!!! 질리도록 들었단 말야!!!

3:30 에 Bang For Your Buck: How to make your Art POP 정도가 좀 들을만 하겠고.
그외엔 없다… 이거 뭐 이렇게 럴럴해….
그렇네요.

두 번째 날 강연

오호 키노트

Road Map and Wish List

A Unite tradition! The founders and leads speak candidly with the audience about their plans for Unity. This session is off the record and not recorded.

살짝 흥미돋네요. 하지만 의외로 별 것 아닐수도.

11시 30분 강의는 Taming the Beast / Particle Effects 를 들어야 할 것 같지만 나머지 두 강연도 모두 관심있어요.
으음..

2시에 Artists as Programmers 를 들어야 하겠지만
Jagged Alliance Online 쪽도 듣고 싶어요!!!! ㄷㄷㄷ

3시 30분은 들을게 없네요. Intro to Shaders 이건 내 수준이 아닐테고. Postmortem: Smuggle Truck 은 조금 관심없고.. .

5시

Unity Awards

The Unity awards features the best content made with Unity.

는 참석해 볼까요. 내년에는 우리 게임이 걸려있을듯.
그리고 파티가 있네요 흐음.

세 번째 날

10:00 첫 시간엔 Best Practices for Real-Time Characters 을 들어야 할 것 같지만 좀 애매..

11:30 에는 The Pipeline of Prime World 을 들어야 하겠지만 어째 주제가 좀 안땡기고,
대신 Optimizing Graphics for PowerVR GPUs 가 땡기네요.
Console Development with Unity 도 좀 땡기는데 어쩌지.

으악 그다음엔 정말 들을 거 없음 … ㄷㄷㄷ

Tech Artist Bootcamp and Interviews

Sun, 25 Sep 2011 19:03:22 +0000

Tech Artist Bootcamp and Interviews

오즈라엘님이 올려주셨다! 올려주셨다!!

원문:

http://www.gamedev.net/page/resources/_/reference/visual-arts/tech-artist-bootcamp-and-interviews-r2818

Introducing Tech-Artists.org

We are the premiere (and only!) community focused on tech art for games and film. Whether you’re looking for tips on creating tools and pipelines, help with using a language or API, or just want to hobnob with some of the best technical artists in the industry, tech-artists.org is for you. Anybody who’s anybody in the tech art world - and plenty of people outside of it - are a part of our great community.

-Rob Galanakis
Founder, tech-artists.org
I came to this site through good friend and tech artist evangelist Bill Crosbie and was delighted to find a community that reminded me so much of GameDev.net in its early years. This is another one of those niche sites focusing on a game development field and actively run by those actually in that field, so you know you’re getting content that’s beneficial to you as an aspiring or active tech artist. We look forward to working more with them in the future, but for now check out what they’ve done at the last GDC!

Drew SikoraExecutive Producer, GameDev.net
GDC ‘11 Tech Artist Bootcamp

This past GDC, Jeff Hanna from Volition organized with various other technical artists a “bootcamp” tutorial session with the focus of educating instructors, studio management and other technical artists about the role of TAs and the skills needed to be proficient in this field of the games industry.

Tech-Artists.org has the compilation of slides and videos that came out of this session:

.zip with all 8 talks (No videos)

Keith Self-Ballard “In Advocacy of Tech Art”
Scott Goffman “Making Tools Your Artists Will Use”
Rob Galanakis “Ending The Culture War”
Seth Gibson “TA Personality Assessment”
Steve Theodore “Epic Fail”
Adam Pletcher “Tech Art and Databases”
Bryan Moss “Using Sim Data In Realtime With Video Textures” (Videos)
Bronwen Grimes “Shader Techniques in Portal 2”

You can also visit Tech-Artists.org for additional notes and discussion on the session.

Recently an email was sent out by Jeff to begin discussing details for another bootcamp at GDC 2012 - so keep your eyes peeled both here and over at Tech-Artists.org for more details as they become available!

Technical Artist Interviews

Bill Crosbie from the IGDA Educational SIG spent some time at GDC ‘11 interviewing a number of technical artists, 18 in total, and has posted these interviews on his YouTube channel. The goal was to talk to both professional tech artists and students to get a better understanding of what was needed for a more formal education in the field of technical art.

He’s selected 5 of his favorite for us to feature below. Check them out for a revealing look into what it means to be a technical artist in the industry today and how people would like to see their field evolve in the years to come.

Jeff Hanna

Jeff Hanna, Senior Technical Artist at Volition and leader of the Technical Artist boot-camp at GDC11, describes what it means to be a technical artist in the games industry.

Rob Galanakis

Rob Galanakis, TA for CCP Games, talks about the importance of programming and why a TA must learn to be ‘ruthless’ to help better the production environment. Don’t miss this one!

Craig Goodman

Craig Goodman, Insomniac Games, shares some laughs and really deep concepts about the need for TAs to be broadly educated, perpetually asking questions about the world and always learning. This video is a little longer, but stick with it to the end. It’s worth it.

Bronwen Grimes

Bronwen Grimes, TA for Valve Software, discusses why it is important for a TA to have flexibility in both education and job structure.

Ben Cloward

Ben Cloward, TA for Bioware Austin, talks about how a TA can solve huge problems or automate complex tasks quickly through the power of scripting, resulting in more time to engage in other creative work. Also, he gives a stern warning for students looking to enter the industry with work that is ‘good enough’ in school.

if(!document.getElementById(“empathyButtonJS”)) { strLoginURL = “http://ozlael.egloos.com/pop_bridge.php?url=http%3A%2F%2Fozlael.egloos.com%2F3739565”; window.sp_pop_url = “http://cyxso.cyworld.com/PopUpLogin.sk?loginstr=direct&redirection="+encodeURIComponent(strLoginURL)+"&pop=direct"; var se = document.createElement(‘script’); se.type = “text/javascript”; se.src = “http://csp.cyworld.com/js/sp.js"; se.id = “empathyButtonJS”; document.getElementsByTagName(‘head’)[0].appendChild(se); }

ELPIS 아이패드2 스마트케이스 ELP-IP2

Sat, 24 Sep 2011 16:09:43 +0000

백만년만에 리뷰한번 해 봤습니다.
아유 오랜만에 하니까 힘들다. 확실히 체력이 떨어진 듯.

SSAO( Screen Space Ambient Occlusion )

Fri, 23 Sep 2011 12:20:04 +0000

다음주에 샌프란시스코를 가야 되네

Fri, 23 Sep 2011 00:46:59 +0000

근데 아 미친 환률 어쩔꺼야

SSAO 를 Z버퍼와 연결하기

Thu, 22 Sep 2011 18:23:58 +0000

공개 레벨로 수정후 올림.

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

SSAO (Screen - space Ambient Occlusion) 은 후처리 효과 중 하나로, 구석진 부분에 음영을 더 추가해서 자연스러운 느낌을 나타나게 해주는 기능입니다.

각 점들이 사방으로 벡터를 쏴서 자신이 얼마나 구석진데 있는지 인식해서 검게 칠합니다.
(그냥 보면 잘 안보이기 때문에 매우 강하게 증폭했습니다)

그리고 이걸 그냥 쓰지 않고.. 다운샘플링 (메모리를 절약하기 위해 작은 사이즈로 샘플링) 하고 블러 등의 과정을 거칩니다.
매우 느리기 때문에 옵션도 좀 낮추고요.

그래서 실제 사용하게 되면 이런 모양이 됩니다.

그런데 이게 원래 렌덤한 도트를 블러시킨 것이라 조금 지글대는 점이 적지 않은데 게다가 DOF 등과 합성되면서,
특히 먼 거리에 있는 SSAO가 특히 거슬리도록 작동된단 말입니다.

때문에 SSAO를 조금만 강하게 쏘면 뒷 배경에 검은 아티펙트가 너무 눈에 거슬려서, 매우 약하게 사용할 수 밖에 없었던게 지금까지의 현실이었습니다.

일단. SSAO는 세 개의 파일로 동작합니다.

SSAOEffect.cs - 스크립트 파일과
SSAOShader.shader - 쉐이더 파일입니다.
frag_ao.cginc - 인클루드 파일입니다.

cs 파일에서는 각종 셋팅값을 잡아줍니다. 카메라의 모드라던가, 메터리얼을 만들어 준다던가, 그렇게 해서 RT( 렌더링 타겟)을 가능하게 해주는 것이죠 . 인터페이스도 여기서 만들어 줍니다. 그리고 RT와 씬을 연결해 주는 일도 합니다.

shader 파일에서는 여러 패스를 통해 SSAO의 연산을 해 줍니다.
인클루드 파일에서는 쉐이더에서 값을 받아 SSAO 깊이값을 계산해서 리턴해 줍니다. 가장 핵심적인 일을 하지요

어쨌건 최종 값은 shader 파일의 맨 아래, composite pass 에서 합성됩니다.

half4 frag( v2f i ) : COLOR
{
half4 c = tex2D (_MainTex, i.uv[0]);
half ao = tex2D (_SSAO, i.uv[1]).r;
ao = pow (ao, _Params.w);
c.rgb *= ao;
return c;
}

매우 간단합니다 … 그냥 텍스쳐와 ao 값을 곱해주는 것 뿐.
그러니 여기다가 카메라 깊이값인 Z버퍼를 같이 연산해주면, 가까이 있는 곳에는 SSAO가 보이고, 멀리 있는 곳은 SSAO가 안보인다던가 하는 짓이 가능하단 말입니다.

그렇다면 일단 Z버퍼를 빼 내 오는 것이 문제…

수없이 삽질을 하다가, 힌트를 발견하였습니다.
그것은 _CameraDepthNormalsTexture.

half4 DepthNormTex = tex2D (_CameraDepthNormalsTexture, i.uv[1]);

으로 사용되는 이 기능은, SSAOEffect.cs 파일에서
camera.depthTextureMode |= DepthTextureMode.DepthNormals;
로 활성화 시켰을때 사용되는 기능입니다.

이렇게 해서 Depth와 Normal을 쉐이더에서 사용할 수 있게 됩니다. 설명은 아래와 같습니다.
한 텍스쳐 안에 노말과 깊이값이 모두 들어 있다는 말이지요.

DepthTextureMode.DepthNormals: depth and view space normals packed into one texture.

그러므로 이것을 디코딩 시켜주면 쓸 수 있게 됩니다.
노말은 XY 채널에 들어가고, 깊이값은 ZW 채널에 들어가므로, 디코딩 기능을 찾아보니 찾을 수 있었습니다. 즉

float DepthMask = DecodeFloatRG (DepthNormTex.zw);

을 쉐이더에서 사용하면 Z버퍼를 구해낼 수 있게 됩니다. DecodeFloatRG 는 UnityCG.cginc 안에 예약되어 있습니다.

그래서 Z 버퍼를 사용하면 이렇게 …

그냥 까만 화면으로 보여서 잘못된 것인 줄 알고 삽질을 좀 했습니다만, 사실은 0~1 이 카메라의 far 플렌까지의 거리이기 때문에 이정도 거리의 이미지는 까맣게 보이는게 정상이었습니다.

땅 아래로 카메라를 집어넣어서 멀리 보면 확인할 수 있었지요. 이걸 일찍 봤었으면 .. .

어쨌거나 Z 버퍼가 제대로 동작한다는 것을 확인했으므로, 이제 거리를 줄이는 일만 남았습니다. smoothstep 명령어가 있습니다.

DepthMask = smoothstep(0,_NoiseScale.z,DepthMask);

을 이용해서 거리를 줄여줍시다. _NoiseScale.z 은 cs 파일에서 생성한 백터값 중 안쓰는 값을 빌려서 사용하였습니다.

이렇게 해서 …

깊이값이 잘 나왔습니다. 일정 거리 이상은 하얗게 날라가는 것을 볼 수 있습니다.

이제 이것을 , 다시

이 이미지와 더해줍시다. 밝은 부분은 1을 넘어갈 것이므로, saturate 시켜주는 것을 잊지 맙시다.

잘 되었습니다. 일정 거리 이상은 SSAO가 보이지 않습니다.

이 수치는 , 인스펙터 창의 SSAO 컴포넌트에 추가해 놓았습니다. 원하시는대로 조절해서 사용 가능하지요.

SSAO Z버퍼 연동 수정완료

Thu, 22 Sep 2011 18:16:26 +0000

수정사항 백업 겸 올립니다. 이게 자주 건드릴 녀석이 아니라서, 나중에 다시 작업할 일이 있을 때 뭐가 어떻게 되었었는지 잊어버리는 경우가 많거든요. 그래서 코드 부분 설명도 좀 나옵니다.

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

SSAO (Screen - space Ambient Occlusion) 은 후처리 효과 중 하나로, 구석진 부분에 음영을 더 추가해서 자연스러운 느낌을 나타나게 해주는 기능입니다.

원리는 각 픽셀에서 사방으로 벡터를 쏴 봐서, 충돌하는 영역이 얼마나 되나를 인식해서 자신이 구석에 있는지 없는지를 인식하는 것입니다.

즉 원래 이런 이미지인데.

각 점들이 사방으로 벡터를 쏴서 자신이 얼마나 구석진데 있는지 인식해서 검게 칠합니다.
(그냥 보면 잘 안보이기 때문에 매우 강하게 증폭했습니다)

그래서 실제 사용하게 되면 이런 모양이 됩니다.

그래서 이걸 원래 화면과 더하면 이렇게 되지요

화살표 있는 부분을 보시면 좀 더 어둡게 눌러진 것을 볼 수 있습니다.

때문에 SSAO를 조금만 강하게 쏘면 뒷 배경에 검은 아티펙트가 너무 눈에 거슬려서, 매우 약하게 사용할 수 밖에 없었던게 지금까지의 현실이었습니다.

================================= 여기서부터는 코드설명 ============================

일단. SSAO는 세 개의 파일로 동작합니다.

SSAOEffect.cs - 스크립트 파일과
SSAOShader.shader - 쉐이더 파일입니다.
frag_ao.cginc - 인클루드 파일입니다.

어쨌건 최종 값은 shader 파일의 맨 아래, composite pass 에서 합성됩니다.

half4 frag( v2f i ) : COLOR
{
half4 c = tex2D (_MainTex, i.uv[0]);
half ao = tex2D (_SSAO, i.uv[1]).r;
ao = pow (ao, _Params.w);
c.rgb *= ao;
return c;
}

매우 간단합니다 … 그냥 텍스쳐와 ao 값을 곱해주는 것 뿐.
그러니 여기다가 카메라 깊이값인 Z버퍼를 같이 연산해주면, 가까이 있는 곳에는 SSAO가 보이고, 멀리 있는 곳은 SSAO가 안보인다던가 하는 짓이 가능하단 말입니다.

그렇다면 일단 Z버퍼를 빼 내 오는 것이 문제…

수없이 삽질을 하다가, 힌트를 발견하였습니다.
그것은 _CameraDepthNormalsTexture.

half4 DepthNormTex = tex2D (_CameraDepthNormalsTexture, i.uv[1]);

으로 사용되는 이 기능은, SSAOEffect.cs 파일에서
camera.depthTextureMode |= DepthTextureMode.DepthNormals;
로 활성화 시켰을때 사용되는 기능입니다.

이렇게 해서 Depth와 Normal을 쉐이더에서 사용할 수 있게 됩니다. 설명은 아래와 같습니다.
한 텍스쳐 안에 노말과 깊이값이 모두 들어 있다는 말이지요.

DepthTextureMode.DepthNormals: depth and view space normals packed into one texture.

float DepthMask = DecodeFloatRG (DepthNormTex.zw);

을 쉐이더에서 사용하면 Z버퍼를 구해낼 수 있게 됩니다. DecodeFloatRG 는 UnityCG.cginc 안에 예약되어 있습니다.

그래서 Z 버퍼를 사용하면 이렇게 …

땅 아래로 카메라를 집어넣어서 멀리 보면 확인할 수 있었지요. 이걸 일찍 봤었으면 .. .

어쨌거나 Z 버퍼가 제대로 동작한다는 것을 확인했으므로, 이제 거리를 줄이는 일만 남았습니다. smoothstep 명령어가 있습니다.

DepthMask = smoothstep(0,_NoiseScale.z,DepthMask);

을 이용해서 거리를 줄여줍시다. _NoiseScale.z 은 cs 파일에서 생성한 백터값 중 안쓰는 값을 빌려서 사용하였습니다.

이렇게 해서 …

깊이값이 잘 나왔습니다. 일정 거리 이상은 하얗게 날라가는 것을 볼 수 있습니다.

이제 이것을 , 다시

이 이미지와 더해줍시다. 밝은 부분은 1을 넘어갈 것이므로, saturate 시켜주는 것을 잊지 맙시다.

잘 되었습니다. 일정 거리 이상은 SSAO가 보이지 않습니다.

이제 다시 원래의 이미지와 합성해 봅시다.

SSAO를 강한 선이 나올 정도로 강조했는데, 원거리에는 적용되지 않았음을 볼 수 있습니다. 성공입니다 잇힝.

원래대로라면 이랬었겠지요

이 수치는 , 인스펙터 창의 SSAO 컴포넌트에 추가해 놓았습니다. 원하시는대로 조절해서 사용하실수 있게 말이지요.

제가 설정해 놓은 기본값은 0.05 입니다. 0~1.0 까지 동작하지요. 1.0이면 옛날과 똑같습니다. 0 이면 SSAO가 전혀 안보이지요.
적당히 사용하시면 되겠습니다.

단비단비

Tue, 20 Sep 2011 23:26:19 +0000

리뷰쓰다가 사진찰칵

무한도전에서 TS렌즈를 구입했나보군요.

Sun, 18 Sep 2011 22:48:50 +0000

무한도전에서 했다기보단 MBC에 구축되었겠죠. 이번에 들고 나온거겠지.

어쨌건 TS렌즈는 일반적인 렌즈와 달리 원근감을 과도하게 억제해 버림으로써 미니어처같은 느낌이 나게 해주는 렌즈입니다.

엄청 비싸다고 하기 때문에 저도 역시 만져본적은 없지만 말이죠. 좋겠다 회사에서 사준건.

이번에 무한도전에서 가끔 나오더군요. 요새 무도팀은 DSLR로 찍는데 재미들렸나 봅니다.

전형적인 TS렌즈의 이미지이죠.

그냥 줌값만 땡겨서 원근감이 없어진 것과는 다른 느낌이 납니다. 뭐랄까 가까운 곳과 먼 곳의 원근감을 강제로 줄이고 늘여버려서 가운데에만 촛점이 맞는 느낌이랄까. 저 비싼걸 (그리고 별로 쓸모도 없는 걸) 가져본적이 없어서 이정도 밖에 예상할 수가 없지만 말입니다.

그러니까 초광각렌즈(아마도 어안렌즈)는 넓게 보이는 대신 아래와 같이 왜곡이 심하게 되고…
(아무래도 차량에 작게 설치해야 되어서 렌즈도 CCD도 작을테니 넓게 찍으려면 어안렌즈 스타일이 될 수 밖에 없겠지만요)

일반적인 렌즈값은 아래와 같이 그냥 일반적인 원근감이 나오게 되고..

장거리에서 땡긴 망원값은 아래와같이 원근감이 사라지게 된단 말이죠.
이거 강의용 자료로 써야겠당.

백만년만의 포스팅

Sun, 18 Sep 2011 22:40:10 +0000

트윗이랑 페이스북 올리는 것도 힘들어 죽겠구만요
이젠 정말 블로그는 작업한거 올리는 것만 사용해야 할 듯.
그렇지만 요새 작업은 전부 비밀글이잖아.. 안될거야 …

오늘 한 작업은 강의준비하고…

또하나는 구형 넷북을 메모리 2기가로 업하고 SSD 달아줘서 개량한다음에
크레이지 리모트 깔고 에어비디오와 에어코믹스 서버를 돌리고… NAS 컨트롤도 가능하게끔 만들어서 토렌트 머신으로도 쓸 수 있는 종합 미디어 서버를 구축했심다. 이것으로 데스크탑을 켜놓고 다닐 필요가 없게 되었네요.
밖에서도 아이패드로 모든 컨트롤이 가능 … 세상 참 좋아졌네요.

TsFont_HeadupText 쉐이더 제작

Wed, 07 Sep 2011 17:58:48 +0000

기존의 헤드업 텍스트가 DOF와 겹칠때 뿌옇게 된다는 문제가 보고되어 작업이 시작되었습니다.
이렇게 말이죠.

처음에는 그냥 Z write를 하지 않아서 그런 줄 알고 간단하게 처리하려 했는데 생각보다 문제가 커서,
귀하게 자라신 00님이 하기에는 맞지 않은 천한 쉐이더 작업이라 생각하여 제가 가져 왔습니다.

작업 내역은 기존에 있던 쉐이더를 유지하면서 , Alpha Blending 으로 되어 있던 쉐이더를 Alpha Testing으로 바꾸는 것이었습니다. Alpha Blending 쉐이더는 어떤 경우에서라도 DOF와 충돌문제가 생기는 것이 발견되었고, 00이가 Unity에 문의해 놓은 상태입니다. 때문에 저희는 이 쉐이더를 Alpha Testing으로 만들어 보고, 00씨가 마음에 들어하는 쪽으로 진행하기로 결정하였습니다.

특이하게도 Alpha Testing으로 바꾼 후에도 이 문제는 지속적으로 유발되었기 때문에 한나절 고생을 좀 했습니다만,
Properties 에 _Color (“Main Color”, Color) 가 존재해야 문제가 해결된다는 것을 발견하고 벙쪘습니다. -ㅁ-;;;
물론 알파 테스팅이라서, _Cutoff (“Alpha cutoff”, Range(0,1)) 도 토씨 하나 안틀리고 존재해야 합니다. 뭐 이런… ㅁㄴㅇㄹ마ㅓ

이런 원리도 알 수 없는 쓸데없는 규칙 좀 만들지 마.

여하간 그래서 만들었습니다.

비교 들어갑니다.

이게 원래 것.
이게 새로만든 헤드업 텍스트. 미묘하게 외각이 거친 대신, 역시 그만큼 더 선명한 것이 특징입니다.

확대해보면 명확해 지는데, 좀 더 거칠어지고 선명해 지는 것을 볼 수 있습니다. 알파 테스팅이니까용. ♥

역시 이 문제도 해결되었습니다.

기존에 이렇게 오브젝트에 절반쯤 겹쳤을 때 절반만 날라가는 증상이 해결되었습니다. 겹쳐도 잘 나옵니다 이예이!

사실은, 완벽하진 않습니다. 화살표 부분을 잘 보시면, 외각의 검은 테두리는 DOF에 먹혀 버리긴 합니다.

그치만 뭐 못 본 걸로 하기로 했습니다. (후다닥)

어쨌건 최저옵션에서도 선명하게 잘 나옵니다.

장점과 단점은 다음과 같습니다.

장점 :

알파 테스팅이라 더 빠르고 가볍습니다.
- 뒷면의 DOF로 인해 흐려지지 않습니다.
전보다 글씨가 또렷합니다.
기존 느낌과 작업 방식을 거의 해치지 않습니다.

단점:

텍스쳐에 알파 채널이 반드시 들어가 줘야 합니다
기존 셋팅값을 미묘하게 수정해야 합니다.
일단 문제는 없어 보이지만, 혹시 버그가 있을지도…

그래서, 다른 폰트에도 써도 되지만 혹시 몰라서 헤드업 텍스트 전용 쉐이더로 따로 제작하였습니다.

9월2일 삼품테스트

Fri, 02 Sep 2011 17:57:14 +0000

최저사양 테스트입니다.
일반적으로 캐릭터가 많이 않은 환경에서는 게임을 즐기기 아무 무리 없습니다.

그치만 드디어 스트레스 테스트가 되자 문제가 발생하기 시작합니다.

오픈하게 되면 대흥산에서 많은 전투가 집중적으로 일어날 것입니다.
여기는 인던 처리도 안되어 있어서 엄청난 부하가 유발될 것으로 예상됩니다.

특히 저 전투 아이콘 때문으로 생각되는데, 반투명 부하가 50% 를 넘었습니다.
전투 아이콘은 수정될 예정인데, 지금처럼 많이 나올 경우를 대비해서 저사양용 레이어 구분을 확실하게 해주면 좋겠습니다.
3프레임 나오는걸 보실 수 있습니다. 뜻밖에 그런데도 프레임이 안정적이라 게임은 가능했다는.

마을에서 스트레스 테스트할 때 채팅부하는 저사양에서 심각한 문제를 초래합니다.
보통 캐릭터만 저정도 있었을 때 10프레임 정도 나오던 것이 2~7프레임을 보였습니다.

이 때의 프로파일링 데이터는 알 수 없는 메인프레임 워크 부하로 나타납니다. 80% 를 차지하고 있고 657ms 를 차지하고 있습니다.

그 외 순간순간 보인 이슈는 리드 오브젝트 이슈가 가끔 보입니다.

혹은 여전히 알기힘든 메인프레임 워크 업데이트가 , 전보다는 확연히 줄었지만 여전히 간혹 보이긴 합니다.

시그라프 2011 강연자료

Thu, 01 Sep 2011 17:52:03 +0000

http://advances.realtimerendering.com/s2011/index.html

캐나다 안가도 되겠구만 !

…하지만 가고 싶어요 어헝헝헝헝

AT2 사양결정용 초벌테스트

Thu, 01 Sep 2011 14:23:12 +0000

‘어느 정도로 만들어야 제대로 돌아갈 것인가’ 에 대한 내용입니다.
사실상 버텍스 수로 제한하려고 했던 것은 실패 OTL 일반적인 버텍스 수 제한으로는 답이 나오지 않습니다.
버텍스를 줄이는 것은 버텍스 처리 속도를 위해서가 아니라, 용량과 스키닝 등의 부하를 줄이기 위한 것이지, 버텍스가 줄어든다고 무작정 게임이 빨라지는 것은 아니라는 것을 알 수 있었습니다.

그렇다면 이제 남은 방법은 직접 게임을 돌려보면서 잡아내는 수 밖에 없지요.

전 맵을 다 돌면서 테스트하는 것도 진행해야겠지만, 일단 극초반 초벌테스트이므로 그렇게는 말고
가장 무겁다고 누구나 말하는 로마 지역을 기반으로 진행하였습니다.

테스트는 듀얼코어에 지포스 7600GS 입니다. 원래는 8600으로 할 생각이었지만, 패널티 부여한다고 생각하면서 7600으로 테스트하였습니다. 메모리는 1G.
옵션은 권장사양용 옵션으로 ‘보통’ 입니다. 그림자는 없고, 블룸X , DOFX(아래 사진에는 있습니다만), AnisotropicX , AAX 등등입니다.
스크린샷 캡쳐를 전용 프로그램 사용했더니 캡쳐하는 순간 프레임이 절반으로 하락해서 OTL 지금 보시는 프레임보다 약 두 배 정도라고 생각하시면 됩니다.

로마의 가장 무거운 지역이라는 곳에 캐릭터들을 30여종 올려놓고 테스트했습니다. 애니메이션 들어간 놈들도 있고, 최적화가 안된 놈들도 있습니다. 테스트용으로는 최적일듯.

저 멀리 피사의 사탑 보이는 뒷쪽으로 상당히 많은 수의 오브젝트가 존재합니다.
현재 데이터 분석을 해 보자면.. 프레임이 10 몇 프레임! 매우 느립니다.
이걸로는 안됩니다. 느리다는 얘기가 나오는게 당연할 듯.

DPcall은 1500. 쬐끔 많기는 하지만 권장에서 못버틸 정도는 아니라고 생각했는데 말입니다.
Tris 와 Vert 는 신경 안써도 됩니다.
오히려 VBO 쪽이 버텍스 양을 체크하는데 도움이 되지요. 31.6M 입니다. 좀 많기는 한 것 같네요. (상대적으로)
하지만 아직 개념을 정확히 잡지는 못하고 있습니다.
비디오 메모리는 200메가까지 쓰고 있습니다. 슬슬 한계가 보이려 하네요.
텍스쳐가 160메가를 사용하고 있습니다. 이걸 좀 어떻게 줄여야 로딩시간이 빨라질듯.
렌더 텍스쳐가 14개에 37.5 메가 ? 비디오 메모리의 15%?

그래서 이번에는 간단하게 프로파일링 분석해 봤습니다. 큰 것만 잡는 겁니다. 큰 것만.

아하.. TsGlobalLightColor가 40%나 잡아먹고 있네요 으흐흐.
이게 뭐냐면 각 맵에 따라 캐릭터의 Upper Color와 Lower Color를 자동으로 잡아주는 쉐이더 기능 보조의 스크립트입니다.
이건 원래 처음 시작할 때 한 번만 잡아주면 되는건데, 작업 편의를 위해서 매 프레임 잡게 되어 있습니다.
일단 막아버리면 되겠네요. 벌써 40% 퍼포먼스 향상 .

그다음에… 드로잉이나 렌더링이 느린건 사실 어쩔 수 없는 부분입니다. 그런데 컬링에서 15% 라는 이상한 숫자가 …
찾아보니 Water3 입니다. 바다에 사용하고 있는 부분이지요.
Water3라… 찾아보니 이거 물건입니다. Full 로 기능을 다 쓰면 엄청 무거운 녀석입니다만, 옵션이 다양해서 옵션만 줄이면 어떻게 될 수도 있을 것 같습니다. 가장 무거운 영역은 실시간 리플렉션 기능이네요.

반대쪽도 확인해 봤습니다. 역시나 비디오 메모리는 좀 위험하게 사용하고 있고, VBO는 30메가쯤 쓰고 있습니다. 일단 가설로, 30메가쯤 VBO를 쓰면 한계라고 해 둘까요.
텍스쳐 메모리는 160메가쯤 쓰고 있습니다. 줄이면 로딩시간과 비디오 메모리 여유분에 도움이 되긴 하겠지요. 그치만 대부분의 그래픽 카드가 최소 256 이상의 메모리를 가지고 있으니… 굳이 나서서 줄일 필요는 없어 보이기도 하고 말입니다.

분석해 봅니다. 역시 물과 Global light 기능이 문제입니다.

Global Light 기능은 어차피 고칠 거니까…

일단 이놈의 물 부터 어떻게 좀 해보겠습니다. 바다에서 뭔가 한다면 모르겠는데 그다지 중요하게 하는 것도 없고… 특히 실시간 반사 기능을 켜면, 화면 전체를 한 번 더 렌더링 하다시피 하니 느려질 수 밖에 없습니다.
비칠 것과 안 비칠 것을 제한하는 방법이 있던데, 응용해서 바닷물은 최적화를 사용해야 할 것 같습니다.
또한 땅 아래에도 바다가 있는데, 이런 경우 계속 렌더링 되고 있는것도 마음에 들지 않습니다.

그래서 이 두 가지 기능을 제거해 봤습니다. 강물은 가장 가벼운 물 쉐이더로 바꿔봤고, 바닷물은 옵티마이즈 옵션으로 가볍게 바꿨습니다. 글로벌 라이트 기능은 실시간 업데이트 하지 않고 Start 부분으로 빼서 한 번만 가동되게 만들어 봤습니다.

또한, 저 뒤 피사의 사탑에 있던 자질구레한 오브젝트들을 숨겨 보았습니다. 일종의 small object 옵션을 가상으로 실행시켜 본 거죠.

그 외에 옵션은 동일합니다.

보시면 알겠지만, 프레임이 대폭 상승하였습니다. 여기서 21프레임이 나온다는 말은 평소에는 30프레임 근방이 나온다는 뜻이니까요. 스크린 캡쳐 프로그램이 가동될때 갑자기 느려지는 증상이 일어납니다.

즉 위 두 가지만 해결했는데도 30프레임이 나온다는 말씀.
비디오 메모리나 텍스쳐, 버텍스 , DPcall은 거의 변화가 없는데 프레임이 두 배 이상 상승 . 예이!

그리고 여기서부터가 진짜입니다. 드디어 렌더가 가장 높게 나오는군요. 뎁스 텍스쳐를 업데이트 한다는 말은 디퍼드 렌더링을 위해서 Z 버퍼를 업데이트 한다는 말이겠지요.
그리고 드디어 메쉬.드로우 VBO (버텍스 버퍼 오브젝트) 가 나왔습니다. 버텍스 처리하는게 가장 무겁다는 말이겠지요.
처리는 초당 30프레임 정도로 할 수 있으나 어쨌건 돌리는건 가장 무겁다… 매우 좋은 기준이 나온 것 같습니다. 13.44ms 면, 상당히 높은 양이지요. 전체 렌더링 부하의 1/3 이니까요. 드디어 줄일 수 없는게 나왔습니다.

여기서부터는 정말로 오브젝트의 최적화 / 컬링 등으로 숨겨야 하겠지요. 이제부터가 진짜 최적화.
일단 자질구레한 오브젝트를 컴바인 mesh 기능 등으로 묶어주는게 필요할 듯 합니다. 또한 터레인 디테일도 조절해야겠고, 보이는 거리에 따른 스몰 / 미들 / 빅 오브젝트 레이어 설정까지 해주면 더 향상될 겁니다.

게다가 지금 DOF 같은 기능도 제대로 안 뺐단 말이죠. 이것도 개선될 여지가 있는 상태입니다.

그리고 드로잉이 23% 음 뭐 이게 디퍼드 렌더링 프로세스고…

어쨌건 꽤 무거운 캐릭터들이 ‘서로 다른 녀석들’ 이 30여종이 넘게 있는데도 30프레임이 나오고 있는건 매우 긍정적인 결과입니다.

물론 예상되는 반대급부도 있지요.
지형이 좀 썰렁하니 오브젝트가 보강될 겁니다. 이펙트도 보강될거고, 인터페이스도 제법 잡아먹을 겁니다.
그리고 나중에 로직도 들어가겠죠? 스키닝 수치도 늘어날 겁니다…

그렇지만 반대로 그래픽 카드가 올라갈테고 최적화 옵션과 옵션설정값들이 수정될 겁니다. 게다가 캐릭터들 중에서는 아직 폴리곤 정리도 안된 녀석들이 들어가 있겠구요. 물 쉐이더나 기타 쉐이더들도 가벼워 질 가능성도 있습니다.

이렇게 대충 때려보면, 안될 것 없겠지요?

자 그럼 이게 어떤 ‘좋은 기준’ 이라는 가설을 세워봅시다. 이정도가 ‘돌릴 수 있는 딱 적당한 수준’ 이라고 친단 말이죠.

캐릭터를 지워보고 배경만 남겼습니다. DOF도 없애고 옵션을 좀 만졌습니다.

아직 데이터가 하나뿐이기 때문에 귀납적 데이터가 되기에는 한참 모자랍니다만, 경험과 감각으로 때려맞추는 거죠 ㅋ

이렇게 해서 세운 1차 가설은 다음과 같습니다.

배경은 드로우콜이 가급적 1000 이하면 좋을 것 같습니다 .
트라이 / 버텍스 는 AT2에선 신경쓰지 마십시오.
대신 배경의 VBO는 400 이하, 30메가 이내면 좋겠습니다.
비디오 메모리도 배경에서는 100메가 안쪽으로만 사용하시면 좋겠네요. 더 줄이면 물론 좋구요. (VRAMusage)

대충 이정도면, 특별한 컬링 조건 없을 때 원활하게 돌아갈 수 있는 게임을 만들 수 있을 것 같습니다.

중요한건, 이게 1차 가설일 뿐이란 것입니다.
이제 앞으로 각종 맵을 탐방하면서, 위 조건이 타당한지 증명할 것입니다. 그리고 데이터들도 하나하나 보면서, 특별히 무거운 방식으로 만들어 지는건 혹시 없는지 , 더 좋은 방법은 없는지 찾을 것이구용.

그리고 곧장 쉐이더 정리부터 해야겠지요 휴우. ㅋ

부록 ———————————————————————————————

이 정도 데이터가 굉장히 안정적인 편이라는걸 증명하기 위해…
아까 캐릭터 있는 상태를 Fast 옵션으로 만들어 6600 (원래 최저사양으로 하려 생각했던 그래픽 카드) 로 돌려 봤습니다.

짜잔.

나무나 풀들이 대폭 사라지면서 DPcall이 작아지고 . 여러 수치들도 조금씩 좋아졌습니다.
그렇지만 20프레임 이상이 나오네요 즉 이 정도만 되면 7600 아니라 6600 에서도 옵션만 좀 조절하면 꽤 볼 만한 상태에서 잘 돌아간다는 것이 증명되었습니다. ㅎㅎㅎ

물론 7600보다 렌더링할때 더 힘들어 하는게 보이긴 합니다. 그렇지만 어쨌건 돌아는 간다는거.
조금 더 옵션 낮추고 최적화 기능 집어 넣으면 6600으로도 최저사양을 만들 수 있을 것으로 보입니다. :)

7600GS의 성능분석 / AT2 초벌 사양조사 / 버텍스 용량제한

Wed, 31 Aug 2011 15:50:27 +0000

변수가 하도 많아서 골치가 아프네요.
종일 걱정은 하고 고민은 하는데 해결은 안나는 느낌?

인터넷 돌다가 발견한 황재철군 도플갱어 사진으로 한 컷.

그렇다고 여태까지 며칠 잡고 있었는데 더 잡다간 바보될 것 같아서 정리하겠습니다.

7600GS를 기준으로 잡은 이유는 저번에 말씀드렸는데요.

8000 대를 기준으로 잡으면, 통합 쉐이더 프로세서로 인해서 버텍스와 픽셀 쉐이더 비율이 무의미해진다.
그렇지만 우리는 블소처럼 최소가 8000 이 아니기 때문에 이 비율은 중요하다.
7000 대 중 보유하고 있는 최고가 GS라서 아쉽. GT가 없다. (기증해주실분?) GT의 성능은 완전 다른데.
나중에 여러 가지 변수를 고래해 볼 때, 7600에서 제대로 돌린다면 8000 대를 권장으로 삼는다고 해도 좋을 것이다.

이렇게 해서 7600의 성능을 분석해 보았습니다.
7600 GS로 계산해 보면

7600 GT 80nm 로 계산해 보면 (숫자 높은것)

7600 GT는 정말로 성능이 팍 튀는군요. 그치만 완고하게 GS로 계산해 보겠습니다.
아시는 분은 아시겠지만, 나중에 실제 게임이 되면 이렇게 보수적으로 잡은 성능이 딱 맞아 떨어지는 경우가 많거든요.
퍼포먼스 저하요인은 무궁무진하니까요.

완고하게 양보 안할꼬야.

어쨌건 7600 시리즈로 아주 양보없이 짜게 봤을 때, 버텍스의 처리 용량 한계는 1/30 초 당
16Mega 개 (= 1천6백만개) 라는 것을 알 수 있습니다. 우와 대단.

픽셀은 당연하게도 훨씬 더 많지만, 픽셀은 굉장히 많은 요소에 좌우되며 유동적이기 때문에 여기서 정하긴 무리입니다.
특히 픽셀 쉐이더 버퍼는 이펙트와 후처리 효과등에 연관이 아주 많고, 해상도에도 영향을 많이 받기 때문입니다.
즉 픽셀은 보면서 해야 한다는. 까짓거 보면서 하지 뭐.

근데, 속으면 안됩니다. 버텍스가 몇 개라고 했지만… 이건 정말로 순수한 버텍스 (일 겁니다) 기준이 다 그렇지요 뭐.
자동차 연비가 제조사 보고만큼 나오시는 분 손?
게다가 우리의 버텍스가 순수한 버텍스일까요? 절대 그렇지 않습니다.

순수한 버텍스는 위치값만 가지고 이루어지기 때문에 매우 가볍습니다.
용량으로 따지면 다음과 같지요 .

====================================================
버텍스는 Position(위치) 정보만 가지고 있으면 된다.
Position은 X, Y, Z 값이필요. 각값은 float으로 float 1개당 4byte를쓴다.
따라서, 1개의 Position을표시하기위한용량은 43 = 12byte
1,000개의버텍스를가졌기때문에 12 1,000 = 12,000 byte = 12kb가된다.
하지만, 요즘은 Index 없이버텍스를표현하지않으므로 Index를추가한다.
Index는 버텍스를 그리는 순서를 저장하는데, 통상 버텍스보다 많다.
Index는 Integer 하나를 사용하는데, Integer 하나당 4byte를쓴다.
대략 버텍스 숫자만큼만 쓴다고 가정하면, 4 * 1,000 = 4,000 byte = 4kb가된다.
1,000개의 버텍스를 가진 기본오브젝트의 용량은 12 + 4 = 16kb이다.
* NIF의 경우 여기에 각종 정보들이 포함된 헤더가 추가되므로 용량은 이보다 늘어나게 된다.

하지만 우리가 쓸 버텍스는 그렇게 순수하지 않을 겁니다. UV도 들어갈테고, UV가 두 개가 들어갈 수도 있지요. 라이트맵 쓰면 UV가 무려 3개가 들어갑니다. 이정도 되면 버텍스보단 픽셀에서 문제가 …
게다가 노말도 들어가지요? 노말을 처리하기 위해서 버텍스에서부터 이미 데이터를 안고 가야 하는 것이 있습니다.

===================================================
만약어떤오브젝트가 Index, Position, UV1, UV2, UV3, Normal, BiNormal, Tangent를가지고있다면용량이얼마나될까?(텍스처제외, NIF 헤더제외)
버텍스 1개당용량 = Index (4) + Position (12) + UV1 (8) + UV2 (8) + UV3 (8) + Normal (12) + BiNormal (12) + Tangent (12) = 76byte
버텍스가 1,000개라면 76kb
버텍스가 10,000개라면 760kb

대충 뭐 이런거 말이죠. 이렇게 버텍스도 복잡하기 때문에, 버텍스 처리가 순수하게 제조사에서 밝히는 파워가 나온다고 생각할 수는 없습니다.

그래서 버텍스의 개수보다 버텍스의 VBO(버텍스 버퍼 오브젝트)로 제한하라는 것입니다.
이것은 버텍스가 차지하고 있는 용량을 의미하니까요. 문제는 이 그래픽 카드가 몇 메가까지 처리 가능하느냐인데…

1천6백만개의 순수 버텍스를 처리한다고 봤을때 예상되는 VBO의 용량은 16,000,000*12kb=192,000,000kb = 18750Mbyte = 18.37Gbyte

18기가….?

계산이 잘못된게 아니라면, 이미 그래픽 카드메모리 한도를 넘어가 버려도 한참 넘어가 버렸습니다. ㄷㄷㄷㄷ
버텍스가 꽤 무거워서, 최소의 데이터가 아닌 최대의 데이터라고 치면 약 6배니까 1/6 로 나누어도 3기가바이트 용량의 버텍스를 처리할 수 있다는 말이니까요.

즉 버텍스 쉐이더를 많이 써도 되겠다는 말이 되네요. 이정도라면..
이래서 버텍스 용량은 신경쓰지 말고 , 차라리 VBO의 메가수를 걱정해라라는 말이 나왔나 봅니다. 그래픽 카드의 메모리 용량이 저렇게 클리가 없으니까요.

물론 여기에서 안주할 수 만은 없습니다. 아직 여기에는 버텍스의 트렌스폼 정보 등 역시 빠져 있는 부분들이 꽤 있으니까요.
어쨌건, 확실한거 하나는 이거겠네요.
‘버텍스의 처리속도 한계는, 버텍스만이라면 정말로 신경쓰지 않아도 된다’
오히려 용량을 걱정하면 되지, 버텍스는 그래픽 카드의 메모리만큼 꽉 채워서 써도 느리지 않다 … 라는 것이겠네요. 아 물론 권장사양에서는요.

우리가 지금 로마에서 대충 권장사양으로 때려맞춰 봐도 버텍스 개수는 2Mega (한계는 16Mega) 정도밖에 안되고, VBO 용량은 30메가바이트 밖에 되지 않습니다.

그런데도 빠르지 않지요? 다시 말해서 지금 느린것은 버텍스를 줄여서만 해결할 문제는 아니라는 것입니다.
물론 버텍스를 줄이면 다른 요인들도 줄어들기 때문에 유리해 집니다만, 버텍스’만’ 줄여서 해결될 거라고 생각은 안하는게 좋다는 거겠지요.

자… 그럼 이제 이 정보 기반을 바탕으로, 실제 데이터 조사를 분석하여 결과를 도출해 내도록 하겠습니다.

CPU 클럭과 코어와 캐쉬와 아키텍쳐

Mon, 29 Aug 2011 01:58:20 +0000

출처

http://pc.daum.net/communication/communication_forum_view.jsp?id=1023&mypage2=6

컴퓨터의 성능을 가늠하고자 할 때 가장 먼저 살펴보게 되는 것이 바로 기본 사양표다. 여기에는 해당 컴퓨터를 구성하고 있는 부품의 항목이 일목요연하게 정리되어 있는 데, 가장 상단에는 대부분 ‘CPU’라는 항목이 위치해 있다. 그만큼 컴퓨터에서 CPU는 전반적인 성능을 좌우하는 가장 중요한 부품이라고 할 수 있다.

‘CPU’, 혹은 ‘마이크로프로세서’라고 부르는 그것

CPU는 ‘Central Processing Unit’의 약자로서, 직역 하면 중앙처리장치(中央處理裝置)다. 단어 그대로, 컴퓨터의 정중앙에서 모든 데이터를 처리하는 장치라는 뜻이다. CPU는 컴퓨터의 두뇌에 해당하는 것으로서, 사용자로부터 입력 받은 명령어를 해석, 연산한 후 그 결과를 출력하는 역할을 한다. 그리고 이렇게 하나의 부품에 연산 장치, 해독 장치, 제어 장치 등이 집적되어 있는 형태를 일컬어 ‘마이크로프로세서(Micro-processor)’라고 한다. CPU와 마이크로프로세서는 거의 같은 의미로 쓰이는 일이 많다. 다만 마이크로프로세서 중에는 전기밥솥이나 세탁기와 같은 제품의 제어용으로 쓰이는 것도 있어, 일반적인 컴퓨터에 장착되는 CPU와는 미묘하게 뜻이 구분되기도 한다(여기서는 CPU라고 통일해 부르기로 한다).

CPU는 데이터를 처리하는 컴퓨터의 두뇌이다.

컴퓨터 CPU의 가장 기본적인 역할은 연산/계산 작업이다. 이를테면 사용자가 ‘0 + 1’이라는 명령을 내리면 CPU는 이를 받아들여 계산을 한 후 ‘1’이라는 결과를 영상 출력 장치(모니터 등)로 보여준다. 물론, 지금 우리가 사용하는 컴퓨터의 CPU는 이러한 단순한 계산 작업만 처리하지는 않으며, 문서나 그림, 음악이나 동영상 처리 등 다양한 데이터를 취급한다. 하지만 처리하는 데이터의 종류가 다르다 해도 CPU가 데이터를 처리하는 기본 원리는 ‘0 + 1 = 1’을 계산할 때와 크게 다르지 않다.

왜냐하면 컴퓨터의 내부에서 이동하는 데이터는 어차피 ‘0’과 ‘1’로만 구성된 디지털 신호의 조합이기 때문이다. 예를 들어, 사용자가 숫자 ‘3’을 컴퓨터에 입력하면 CPU는 이를 ‘00011’이라는 0과 1의 조합으로 인식한다. 만약 단순한 숫자 데이터가 아닌 영상이나 음악 등의 복잡한 데이터를 CPU가 인식, 처리할 수 있는 디지털 신호로 구성하려면 수많은 0과 1의 조합이 필요하다.

예를 들어 5MB 용량의 음악 파일 1개가 있다면, CPU는 이를 총 4천만 개 정도의 0과 1이 조합된 집합체로 인식한다. 이에 따라 사용자가 PC 상에서 음악 파일 하나를 클릭하여 재생하는 순간, CPU 내부에서는 ‘1100011000111101100011000110011001110~’ 등으로 길게 이어지는 연산 작업이 초당 몇 천만 번, 혹은 몇 억 번씩 이루어지고 있는 셈이다.

클럭 속도? 코어 수? 무엇이 중요해?

2개의 코어를 장착한 듀얼 코어 CPU

이러한 연산 속도는 CPU의 종류마다 다르다. CPU의 속도를 나타내는 대표적인 단위는 ‘클럭(clock)’인데, 이는 1초당 CPU 내부에서 몇 단계의 작업이 처리되는 지를 측정해 이를 주파수 단위인 ‘Hz(헤르츠)’로 나타낸 것이다. 따라서, 이 클럭 수치가 높을수록 빠른 성능의 CPU라고 할 수 있다. 참고로, 1971년에 등장한 세계 최초의 컴퓨터 CPU인 ‘인텔(Intel) 4004’의 최대 동작 클럭은 740KHz(74만Hz)였으며, 2010년 현재 판매 중인 CPU인 ‘인텔 코어(Core) i7 960’의 동작 클럭은 3.2GHz(32억Hz)에 달한다.

과거에는 이러한 클럭 속도가 CPU의 성능을 나타내는 절대적인 기준이었지만, 최근에는 하나의 CPU에 2개 이상의 코어(Core)를 집어넣은 다중 코어(멀티 코어, Multi Core) CPU가 등장하여, CPU의 성능을 나타내는 또 하나의 기준이 되고 있다.

컴퓨터 CPU에서 코어란 CPU에 내장된 처리회로의 핵심 부분으로서, 예전에는 1개의 CPU 당 1개의 코어(단일 코어: Single Core)만을 가지고 있는 것이 당연했다. 1990년대 후반과 2000년대 초반을 즈음하여, 산업용/전문가용 컴퓨터를 위한 다중 코어 CPU가 출시된 적은 있었으나 특수한 환경에서만 사용되어 컴퓨터 시장에 미치는 영향은 극히 미미했다. 하지만 2005년, 2개의 코어를 갖춘 듀얼 코어(Dual Core) CPU인 인텔의 ‘펜티엄(Pentium) D’와 AMD의 ‘애슬론(Athlon)64 X2’가 등장하면서 다중 코어 CPU가 점차 대중화되기 시작했다.

2007년에는 4개의 코어를 갖춘 쿼드 코어(Quad Core) CPU인 인텔의 ‘코어2 쿼드(Core2 Quad)가 등장했으며, 2008년에는 듀얼 코어와 쿼드 코어 사이의 틈새시장을 노린 코어 3개짜리 트리플 코어(Triple Core) CPU인 AMD의 페넘(Phenom) X3도 출시되어 사용자들의 관심을 받았다. 또한, 2010년에는 코어를 6개나 내장한 헥사 코어(Hexa Core) CPU, 인텔의 ‘코어 i7 980X 익스트림 에디션(Extreme Edition)’도 출시된 바 있다.

이와 같은 다중 코어 CPU는 내장된 코어 개수만큼 실제 CPU를 장착한 것과 유사한 성능을 낸다. 즉 듀얼 코어 CPU는 일반적인 단일 코어 CPU가 두 번에 걸쳐 처리해야 하는 작업을 한 번에 끝낼 수 있어 전반적인 처리 효율을 높일 수 있다. 다만 다중 코어 CPU는 동시에 여러 가지 작업을 처리하거나(멀티태스킹, multi-tasking) 다중 코어 연산에 최적화된 소프트웨어를 실행할 때 진정한 성능 향상 효과를 얻을 수 있다. 다중 코어 연산을 지원하지 않는 소프트웨어를 사용하거나 한 가지 작업만 집중적으로 수행할 때는, 코어 개수는 적지만 클럭 수치가 높은 CPU가 오히려 월등한 성능을 발휘하는 경우도 많다. 그래픽 편집 프로그램이나 동영상 인코딩 프로그램, 혹은 파일 압축 프로그램 중에 다중 코어를 지원하는 경우가 많으니 참고하자.

CPU의 등급과 가격을 구분 짓는 중요한 지표, 캐시 메모리

클럭 속도와 코어의 수 외에도, CPU의 성능을 가늠할 수 있는 또 하나의 기준은 CPU 안에 들어 있는 캐시 메모리(cache memory)의 용량이다. ‘캐시’라 줄여 부르는데, CPU 내부의 임시 저장공간으로서 CPU가 데이터를 처리할 때 자주 사용하는 데이터를 임시 보관하는 곳이다. 이 캐시 메모리의 용량이 작으면 CPU에 비해 동작 속도가 훨씬 느린 주 기억장치(RAM, 메모리)나 보조 기억 장치(하드디스크, CD-ROM 등)로부터 직접 데이터를 불러들이는 빈도가 높아지는데, 이런 경우 컴퓨터의 전반적인 처리 속도가 크게 저하된다. 결론적으로 CPU의 캐시 메모리는 크면 클수록 성능 향상에 유리하다.

캐시 메모리는 CPU 코어와의 위치에 따라 1차 캐시 메모리(Level 1 cache memory)와 2차 캐시 메모리(Level 2 cache memory), 3차 캐시 메모리(Level 3 cache memory) 등으로 나뉜다. CPU와 가까운 곳에 위치한 캐시 메모리 일수록 성능 향상 폭이 크지만, 그만큼 제조가 어렵고 생산 단가도 높아진다.

1990년대 초반까지는 CPU에 1차 캐시 메모리만 내장하고, 경우에 따라서 컴퓨터 메인보드(주 기판)상에 2차, 3차 캐시 메모리를 추가 장착하는 방식이 주류를 이루었으나, 1990년대 중반 이후부터는 CPU 내부에 1차, 2차 캐시 메모리를 함께 내장하는 방식이 일반화되었다. 그리고 2007년, AMD ‘페넘 X4’의 발매를 즈음하여 3차 캐시 메모리까지 CPU 내부에 탑재하는 경향이 생겨났다.

캐시 메모리의 구성과 용량은 CPU의 등급과 가격을 결정하는 중요한 잣대가 되기도 한다. 1998년에 출시된 인텔의 ‘셀러론(Celeron) 300’ 모델은 상위 제품인 ‘펜티엄 II 300’ 모델과 유사한 코어에 클럭 수치도 동일했으나 가격은 그 절반 이하였다. 두 제품의 차이는 512KB의 2차 캐시 메모리의 유무뿐이었는데, 이로 인한 성능의 차이는 상당했다. 그 후 인텔은 기존의 셀러론 300에 128KB의 2차 캐시 메모리를 추가하면서 가격은 기존 제품과 비슷한 ‘셀러론 300A’를 출시하였는데, 가격 대비 성능이 매우 우수해 큰 인기를 끌었다.

성능 비교의 시작이자 끝, 아키텍처

그리고 마지막으로 알아두어야 할 점은 바로 CPU의 아키텍처(architecture)의 차이다. 아키텍처란 컴퓨터 시스템의 기본 구조 및 설계 방식, 그리고 제조 공정까지 포함하는 개념으로서, 클럭 속도나 코어의 수, 캐시의 용량이 모두 같더라도 아키텍처가 다르면 전반적인 성능에 차이가 난다.

대표적 CPU 업체 인텔과 AMD의 CPU 아키텍처 발전사

자동차로 비유하면 엔진 배기량이나 차체 크기가 유사한 모델이라도, 연식이나 시리즈에 따라 출력, 편의기능 등에서 차이가 나는 것과 유사하다. 즉 몇 기통 엔진을 장착했는가, 차체 뼈대를 어떻게 설계했는가, 어떤 옵션과 부품을 내장했는가 등의 기준에 따라 전반적인 성능 및 기능이 달라지게 되는 것이다. 이와 같은 기준들이 자동차 생산에 있어 하나의 ‘아키텍처’인 셈이다.

컴퓨터 CPU를 예로 들면, 2006년 1월에 출시된 ‘펜티엄 D 930’은 3GHz 클럭과 2개 코어, 총 4MB의 2차 캐시 메모리를 갖추고 있었다. 하지만 같은 해 7월에 출시된 ‘코어2 듀오 E6400’은 2.13GHz 클럭과 2개 코어, 그리고 총 2MB의 2차 캐시 메모리를 내장하여 전반적인 사양 기준이 펜티엄 D 930보다 낮음에도 불구하고 실질적인 성능은 더 우수한 것으로 평가됐다. 이는 코어2 듀오 시리즈에 적용된 아키텍처가 펜티엄 D 시리즈보다 한층 진보된 것이기 때문이다.

따라서 CPU끼리 성능을 비교하고자 할 때는 일단 아키텍처가 같은 제품끼리 분류한 후에 클럭 수치나 코어 개수, 캐시 메모리 용량 등의 우열을 따져보는 것이 바람직하다. 그리고 만약 아키텍처가 다른 CPU끼리 성능을 비교하고자 할 때는 세부적인 수치를 따지기 보다는 각종 매체나 관련 커뮤니티에서 얻을 수 있는 정보를 참고하거나, 가격 비교 사이트 등을 방문해 해당 CPU 제품 간의 가격 차이를 하나씩 체크해보는 것이 좋다.

지포스 8000대 이상의 Unified Shader

Fri, 26 Aug 2011 17:15:18 +0000

지포스 8000대의 하드웨어 성능표를 보니 버텍스 필레이트가 없네요??? 뭐지???
그래서 조사하다가 알게 된 것. Unified Shader.

다이렉트 X 10에서부터 요구하는 기본 사양인 “통합쉐이더 아키텍쳐 (Unified Shader)” 는
지포스라면 8000 대 이상부터, AMD 는 HD2000 대 급 이상부터 적용되었으며,
이 아키텍쳐의 특징은 다음과 같습니다.

지금까지는 그래픽 카드에 버텍스 쉐이더 프로세서와 픽셀 쉐이더 프로세서가 독립되어 있었습니다. 다이렉트 X 9 지원하는 그래픽 카드까지는 말이죠. 이런 경우 단점은… 버텍스 연산이 심하고 픽셀 연산이 적을때는, 픽셀 쉐이더 프로세서가 놀고 있음에도 불구하고 버텍스 쉐이더 프로세서가 병목현상이 걸려서 게임이 느려집니다.
반대로 말해서 픽셀 처리가 많아지면, 버텍스가 작더라도 느려진다는 거지요.

버텍스 쉐이더와 픽셀 쉐이더는 서로 절대 도와주지 않습니다

이런 단점을 극복하기 위해 만든것이 통합 쉐이더 아키텍쳐입니다. 이것은 즉 기존처럼 픽셀 쉐이더와 버텍스 쉐이더 프로세서가 독립되어 있는 것이 아닌, 그냥 통합된 하나의 쉐이더 프로세서가 존재하고, 이것이 픽셀이 무거우면 픽셀쪽으로, 버텍스가 무거우면 버텍스 쪽으로 유동적으로 이동하면서 처리해 준다는 말이지요.

통합 쉐이더 아키텍쳐에서는 서로 도와줍니다.

호오… 훌륭한 개념이네요. 정말 좋…
근데…
덕분에 그래픽 디자이너한테 ‘이정도로 만드세요’ 하고 제한하기는 더더욱 힘들어 졌네요 OTL 유동적이 되었으니 제한이 없다는 거잖아요 …
형규는 ‘버텍스 버퍼’ 로 계산해서 제한 때리라는데… 그래픽 디자이너들한테 그거 계산시키기가 쉽나… OTL

최저사양은 그래도 아직 지포스 6000 ~ 7000대에서 머물테니까, 버텍스는 거기에 맞춰야 겠습니다만, 근데 거긴 또 디스턴스 컬링 옵션이 다를테니까 귀찮네요 ..

일단 7000 대중에서 최고 성능의 그래픽 카드를 끼워다가 그걸 권장이라 생각하고 맞춰보는 작업부터 진행중입니다.
7600만 봐도 http://www.passmark.com/ 에서 비교해 봤을 때 8000 대보다 다소 떨어지긴 하지만 어렴풋이 힌트가 될 수 있을 것 같아서요.

어쨌거나 이래서 다른 게임에서도 권장사양으로 8000 대 이상으로 하는 거였군요. 우리도 테스트는 해 보겠지만, 권장에서 훌륭한 그래픽을 나타내려면 8000 대 이상을 권장으로 하는 것이 맞아 보이긴 합니다.

그래도 테스트는 일단 7600에 맞추는 이유는, 저사양때의 버텍스 / 픽셀 비례를 위해서이기도 하고 나중에 각종 기능과 캐릭터, 로직, 효과, UI 등이 추가되었을 때를 예상하기 위한 패널티랄까요.

아래 글은 자료글입니다.

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

출처 : http://sadiles.blog.me/10088627648

* embedded graphics hardware는 아직 unified shader core 기술이 적용되어 있지 않은 하드웨어가 많은 것 같다. 안타까운 일이다. 성능과 general computing 적합도를 고려해보면 언젠가는 unified shader core로 옮겨 가기는 하겠지만 말이다.

Q: What does unified shader core mean?

A: Historically, GPUs have had dedicated units for different types of operations in the rendering pipeline, such as vertex processing and pixel shading. With the unified architecture of the GeForce 8 Series, NVIDIA designed a single floating point shader core with multiple independent processors. Each of these independent processors can handle any type of shading operation, including pixel shading, vertex shading, geometry shading, and physics shading. GeForce 8 Series GPUs dynamically allocate processing power depending on the workload of the application, providing unprecedented performance and efficiency.

( Unified Shader Core를 설명하기 위하여 살짝 설명을 보태서 의역하면 아래와 같다. )

Q: unified shader core가 무엇인가요?

A: 역사적으로, GPU는 렌더링 파이프 라인에서 수행되는 각각의 단계별 작업에 특화된 여러개의 processing unit의 집합체였다. 예를 들어서, 그동안의 GPU는 vertex processing을 처리하는 vertex processor와 pixel shading을 처리하는 pixel processor의 집합체였다고 할 수 있다. (embedded 쪽의 GPU는 아직도 그렇다.)

GeForce 8 시리즈는 통합 구조의 GPU를 가지고 있다. 하나의 floating point shader core가 여러 개의 다른 일을 수행할 수 있다. 즉, 하나의 unified shader core가 pixel shading, vertex shading, geometry shading 그리고 physics shading과 같은 어느 타입의 작업이라도 처리할 수 있다는 것이다. 이 말은 작업량을 분할하여 처리하는데 효율성이 높아졌다는 것과 같다. 이전의 GPU구조에서는 vertex proessor와 pixel processor의 작업 부하를 사용자가 직접 조정하여 어느 한 쪽에 병목이 생기지 않도록 조정하여야 했다. 하지만, GeForce 8 시리즈의 unified shader core를 사용한 GPU는 응용 프로그램의 작업 부하에 따라서 동적으로 각각의 core에 처리량을 할당할 수 있다.

< Reference >

Site:http://www.nvidia.com/object/geforce_8600_8500_faq.html

8600 GT 성능은?

Thu, 25 Aug 2011 16:19:35 +0000

Nvidia graphics processing units : 그래픽 카드 성능표

요새 최신의 게임들이 대부분 권장이건 기본이건 8600GT를 기본으로 삼고 있는데요,
이 모델이 어쨌건 8000대의 대표가 되는 모델이라서 그런 것 같습니다.
8000 대라고 해도 숫자 낮은 녀석들은 7000대보다 떨어지는 놈들이 많으니, 그런걸로 기준을 잡기가 애매하겠지요.

그렇다면 8600GT의 성능을 함 보겠습니다.
에또… 봅시다.
8600GT라..

메모리는 256,512,1024가 나와 있군요. 흐음.
픽셀 필레이트는 4.32 기가 픽셀 / 초
텍스쳐 필레이트는 8.64기가 텍셀/초. 일반적으로 텍스쳐가 두 배니까 뭐 이건 그렇고…

응? 버텍스 처리속도가 없네요?
설마.. Transister (Million) 이 녀석이 버텍스 좌표 변환을 의미하는 건가…?
아놔… 이걸 어떻게 테스트 한댜…

일단 다시 여기서부터 또 시작 / 사양 정하기

Wed, 24 Aug 2011 09:09:36 +0000

Nvidia graphics processing units : 그래픽 카드 성능표

후후후후후 참여하는 프로젝트가 2개다 보니. 이 짓을 또 해야 해 OTL

그치만 뭐. 재미없지는 않습니다. 재, 재미있어요…

때문에 참고조사.

이건 아XX 라는 게임이군요.

이건 블X 라는 게임. 자, 잠깐, 최소랑 권장이랑 다른게 별로 없어 ..????

이건 우리 친척회사인 마X전 사양.
MO 라서도 그렇겠지만 사양 꽤 낮아용.

이건 테X

섭스턴스에 대한 정리

Tue, 23 Aug 2011 09:50:54 +0000

http://www.allegorithmic.com/

에서 내용을 볼 수 있구요.
아래 글은 번역글이라 아무래도 좀 딱딱한 감이 없지 않지요. 그래서 섭스턴스를 어쨌거나 편하게 정리해 보면 다음과 같습니다.

프로시져 메터리얼 (절차적 메터리얼) procedural material : 이라 부릅니다.
쉽게 말해서 3D MAX 메터리얼을 제대로 배워보신 분이라면 알 수 있는, 기본 텍스쳐 - 노이즈라던가, wood 라던가, 체커라던가, marble 이라던가… - 들을 의미하는 겁니다.
이런 텍스쳐는 다른 책에서는 ‘3차원 텍스쳐’ 라고도 불리기도 하는데요. 어쨌건 이것은 비트맵 이미지라기 보다는 벡터 이미지에 가까운 성질을 가지고 있습니다.
즉 수학적으로 계산된 렌덤한 이미지 패턴들을 섞어서 그럴듯 하게 만드는 것입니다.

덕분에 얻을 수 있는 것은 다음과 같습니다.

비트맵이 아니라 수학계산의 모임이므로, 해상도의 개념이 아닙니다. 해상도는 무제한.
단 , 수학공식으로 만든 텍스쳐라서, 약간 렌덤성이 있는 자연물 텍스쳐 스타일만 나옵니다.
해상도 개념이 아니라서, 용량걱정이 없습니다. 벡터처럼요.
그렇지만 수학공식으로 만든 텍스쳐라서, 손으로 터칭할 수는 없습니다. (손으로 터칭한 비트맵 이미지를 프로시져 메터리얼 안에 추가할 수는 있습니다만, 그렇게 하면 장점이 사라져 버리죠)
재미있게도 수학적으로 조합된 텍스쳐라서, 설정값만 바꿔주면 베리에이션이 엄청 다양하게 나옵니다.
게다가 런타임에서 (게임중에) 유동적으로 바꿔줄수도 있습니다.
용량걱정은 없지만, 런타임에서 연산하는거라 GPU와 CPU의 오버헤드 (연산량) 을 유발시킬 수 있습니다. 복잡하게 구성된 텍스쳐라면 더 그렇겠지요. 즉, 텍스쳐는 지금까지 메모리를 차지하는게 문제였었는데 이 텍스쳐는 CPU를 사용한다는 것이 문제라는 것입니다.
노말맵과 스페큘러 맵, 하이트 맵 등 모든 종류의 맵을 자동생성해 줍니다.

그럼 이걸 유니티에서 어떻게 쓰느냐?

기본적으로 섭스턴스 프로그램에는 크게 다음과 같은 프로그램이 있습니다.

플레이어 : 이미 제작된 텍스쳐를 기반으로 각종 옵션과 설정값들을 바꿀 수 있게 해 줍니다. 즉 베리에이션 생성기. 이것만으로도 굉장한 양의 텍스쳐를 제작할 수 있습니다. 슬라이드 바만 만져도 텍스쳐들이 달라지지요. 이건 공짜입니다.
디자이너 : 아예 처음부터 프로시져 텍스쳐들을 조합해서 프로시져 메터리얼을 만들 수 있게 해 줍니다.
이건 유료 프로그램입니다.

노드 구조로, 손으로 그린 이미지를 프로시져 메터리얼에 넣어 만드는 것을 보시고 있습니다.

에어: 이건 아예 섭스턴스 엔진인듯 합니다. 디자이너도 포함된 것인듯.
리덕스 : 이건 텍스쳐를 압축하는 툴입니다. 일반 비트맵 텍스쳐를 DDS보다 훨씬 더 압축할 수 있지요.
근데 장단점이 있어서.. .이건 이전에 제가 쓴 글을 참고해 보심이 좋을듯.
비트맵2메터리얼 : 크레이지범프와 비슷한 프로그램입니다. 비트맵 텍스쳐 하나로 노말맵이나 하이트맵, 스페큘러 맵등을 만들어 주는 기능을 가지고 있습니다.

유니티 엔진에는 그럼? 다 들어가 있습니까?

정확히 말하자면 , 유니티에는 일단 기본적으로 섭스턴스 엔진이 내장되어 있어서 섭스턴스 고유 포맷을 읽고 수정할 수 있습니다. 하지만 툴은 ‘섭스턴스 플레이어’ 만 들어가 있다고 생각하시면 됩니다. 리덕스나 비트맵2메터리얼을 별로 쓸 일도 없지요… 겜브리오 때라면 리덕스는 썼겠지만..
즉 유니티에는 프로시져 메터리얼을 ‘수정’ 해서 ‘사용’ 할 수 있는 기능은 내장되어 있습니다만, ‘제작’ 할 수 있는 기능은 들어있지 않습니다.
‘제작’ 하려면 디자이너를 사거나 해야 하는데, 추후 맥스에 내장된다는 얘기도 있으니 나중에는 그냥 맥스에서 만들 수 있을지도 모르겠습니다.

그럼 우리 게임에서 이걸 사용할 수 있습니까?

기본적으로 사용 못 할 이유가 없습니다. 그냥 제작되어진 메터리얼을 받아서 (혹은 사서) 쓰면 바로 적용됩니다. 아 , 물론 웹이나 스텐드얼론에 한해서지만요.
그치만 생각해야할 점이 있습니다. 이게 무조건 좋느냐? 라는 점에서 말입니다.
분명 텍스쳐 사이즈가 거의 없다는건 매력적인 일입니다. 그치만 CPU에서 연산하는 메터리얼이란 말입니다. 장점이 있으면 단점이 있는 법이지요.

그러므로 게임에 사용할 때에는 한 번 생각해야 할 필요가 있습니다.

만약 현재 메모리는 남고 CPU 부하가 심한 게임이 되었다면? 그럼 이건 가급적이면 써서는 안되는 메터리얼입니다.
만약 현재 메모리는 부족하고 CPU 부하가 여유있는 게임이 되었다면? 그럼 이건 적극적으로 써줘야 하는 메터리얼입니다.

그나마 다행한 것은, 이 메터리얼 기능이 엔진에 내장되어 있기 때문에 언제건 사용을 결정해도 상관없는 기능이라는 것입니다. 이런 것들은 최후까지 남겨 놓았다가 결정해야 하지요. ‘있다는 것’ 은 알고 있어야 하지만, ‘미리 결정할 필요는 없는 것’ 이라는 점은 무척 좋은 것입니다.

보통 최적화에는 두 가지가 있지요.
‘미리 정해놔야만 하는 최적화’ 와 ‘나중에 해도 별 상관없는 최적화’ 같은것 말입니다.
‘나중에 해도 별 상관없는 최적화’ 는 매우 간단하거나, 없어져도 큰 문제가 없는 것들을 의미합니다.

실시간 그림자라던가, DOF , 블룸과 같은 장식형 효과라던가, 텍스쳐 사이즈 같은 것들은 수정하기가 매우 간단하므로 맨 마지막에 최후의 수단으로 적용해야 하는 최적화 내용들입니다.
그렇지만, 3km 앞까지 보이고 진짜 갈 수 있다던가… 한 화면에 300명씩 보이는 전투가 기획되어 있다던가… 등등 근본적으로 해결해 놔야만 하는 최적화 내용들이 있습니다. 이런 것들은 ‘미리 정해놔야만 하는 최적화’ 지요.

이 섭스턴스의 경우에는 , ‘나중에 해도 별 상관없는’ 것에 속한다고 볼 수 있습니다. 넵 그렇습니다.
그러므로 지금부터 걱정할 필요는 없고, 프로젝트 중 후반부에 게임 봐 가면서 적용하는 것이 좋고, 그쪽이 효율적입니다.

Procedural Materials 에 대한 이야기. 섭스턴스 2부

Mon, 22 Aug 2011 17:30:25 +0000

뭐 섭스턴스가 어떤건지는 대충 알 것 같고, 사용하는 법도 알겠습니다만….
그렇다면 이번엔 이걸 사용했을때 장단점도 알아봐야겠지요. 이놈이 이게 쓸 때 치명적인 문제가 있음 큰일나잖아요?
안그래요 메튜? (섭스턴스 홍보담당 할아버지. 3번이나 날 만났는데도 여전히 못알아봄. 쳇.)

그래서 긁어본 유니티 메뉴얼의 프로시져 메터리얼 내용중 옵티마이제이션 얘기입니다.

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

Performance and Optimization

Procedural Materials inherently tend to use less storage than bitmap images. However, the trade-off is that they are based around scripts and running those scripts to generate materials requires some CPU and GPU resources. The more complex your Procedural Materials are, the greater their runtime overhead.
프로시져 텍스쳐는 근본적으로 비트맵 이미지보다 작습니다. 그럼에도 불구하고 거기에 상충해서, 이 이미지들은 스크립트로 제작되어 지고 돌아가는 메터리얼이기 때문에, 어쩔 수 없이 CPU와 GPU 자원을 소모합니다. (주: 메모리가 아니라 CPU 에서 만들어진다는 말이죠) 더 복잡한 프로시져 메터리얼들은, 더 큰 런타임 오버헤드를 유발시킵니다.

Procedural Materials support a form of caching whereby the material is only updated if its parameters have changed since it was last generated. Further to this, some materials may have many properties that could theoretically be changed and yet only a few will ever need to change at runtime. In such cases, you can inform Unity about the variables that will not change to help it cache as much data as possible from the previous generation of the material. This will often improve performance significantly.
프로시져 메터리얼은 캐싱의 폼을 지원합니다. 그로써 메터리얼은 파라미터가 마지막 생성되었을 때 이후에 파라미터가 변경될때에나 업데이트 됩니다. 나아가서, 어떤 많은 설정값들을 가지고 있는 메터리얼은 이론적으로 변화가능하고 그리고 일부는 런타임에서 변화할 필요가 있을 겁니다. 그런 경우 유니티에게 변하지 않는 변수에 대해 알려주면 미리 생성된 재질로부터 가능한 많은 데이터들을 캐시에 담아놓을 수 있습니다.
이것은 자주 의미있게 퍼포먼스를 향상시킵니다.

Procedural Materials can refer to hidden, system-wide, variables, such as elapsed time or number of Procedural Material instances (this data can be useful for animations). Changes in the values of these variables can still force a Procedural Material to update even if none of the explicitly defined parameters change.

Procedural Materials can also be used purely as a convenience in the editor (ie, you can generate a standard Material by setting the parameters of a Procedural Material and then “baking” it). This will remove the runtime overhead of material generation but naturally, the baked materials can’t be changed or animated during gameplay.
프로시절 메터리얼은 맡길 수 있습니다. 히든에, 시스템-와이드, 변수들에, 이들의 시간이나 수의 프로시져 메터리얼 인스턴스와 같은 (이 데이터는 에니메이션에서 유용합니다) . 이런 변수들의 값의 변화는 심지어 이들의 파라미터가 극도로 변하더라도 프로시져 메터리얼의 업데이트에 영향을 끼칠 수 있습니다.
프로시져 메터리얼은 또한 에디터에서 순수하게 편리하게 사용할 수 있습니다. (당신은 스텐다드 메터리얼을 생성할 수 있습니다. 프로시져 메터리얼을 셋팅하고 그걸 ‘베이킹’ 하는 것으로) 이것은 런타임 오버헤드를 제거하지만 근본적으로, 베이킹한 메터리얼은 애니메이션이 안되지라우.

Using the Substance Player to Analyze Performance

Since the complexity of a Procedural Material can affect runtime performance, Allegorithmic incorporates profiling features in its Substance Player tool. This tool is available to download for free from Allegorithmic뭩 website.

Substance Player uses the same optimized rendering engine as the one integrated into Unity 3.4, so its rendering measurement is more representative of performance in Unity than that of Substance Designer.
프로시저 메터리얼의 복잡도는 런타임 퍼포먼스에 영향을 끼치는 관걔로, 알레고리드믹은 섭스턴스 플레이어 툴에다가 프로파일링 기능을 만들었지유. 이 툴은 알레고리드믹 웹사이트에서 받을 수 있구요.
섭스턴스 플레이어는 유니티에 적용된 렌더엔진하고 같이 최적화 되었어요. 그래서 이 렌더링 측정기는 섭스턴스 디자이너보다 유니티에 더 대표적이라고 할 수 있지요.

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

휘리릭 발번역이라 내용이 개판이지만 (…)
대충 보기에도 원론적인 내용만 있다는 것을 알 수 있습니다. 그냥 ‘너무 복잡하게 쓰면 당근 느려지지’ 라는 말 한 줄을 풀어쓴 것 밖에 안되는군요.

뭐 일단 개념적으로, 텍스쳐의 메모리를 줄일 필요가 있거나 텍스쳐를 거대하게 사용하고 싶을 때에 주로 사용하는 것이 맞을겁니다. 또는 오버헤드 연산이 좀 남을 때 사용할 수 있겠지요. 우리 게임은 로직 연산량이 많은 편이라 가능할지 모르겠지만요…

Procedural materials tutorial – Substance in Unity - 유니티에서 섭스턴스 사용하기

Mon, 22 Aug 2011 15:28:24 +0000

유니티 3.4에서는 섭스턴스라고 하는 새로운 메터리얼 체계가 추가되었습니다.
듣기에 따라서는 혁신적인 이 메터리얼은, 프로시져로 제작된 텍스쳐들의 조합으로 , 굉장히 작은 용량에 거의 무제한의 , 실시간 변동 가능한 텍스쳐를 생성해 낼 수 있다는 것입니다.
전 옵션이 동적인 옵션이라서, 하나만 구매/제작해 놓으면 무한대의 베리에이션 생성이 가능하고요.
자세한 내용은 http://www.allegorithmic.com/unity 에서 볼 수 있구요.

아래는 실제로 이것을 유니티에서 어떻게 사용할 것인지에 대한 튜터리얼을 올려 놓은 것을 대충 발번역 해 보았습니다.

=======================================================================================
http://blogs.unity3d.com/2011/08/09/substances-procedural-materials-in-unity/

This guide is designed to briefly explain what Substance is, how to create new substance materials from a substance material asset, apply them to a mesh and edit parameters.
이 글은 섭스턴스가 뭐고, 어떻게 만들고 어떻게 적용하고 어떻게 수정하는지 등에 대해 간단히 씌여졌습니다.

What are Substance Materials?

Substance materials are procedurally generated assets, from technology developed by Allegorithmic. A ’substance’ is basically a set of maps, defining a whole material with all channels: Diffuse, Normal, Specular, Bump, etc. 3DS Max and Maya have substance support for rendering, but now with Unity implementation we can make use of them in real-time applications.
섭스턴스가 뭐냐면, 알레고리드믹에 의해 만들어진 프로시져 메터리얼 어셋입니다. ‘섭스턴스’ 는, 기본적으로 맵의 한 셋트이고 모든 채널과 함께 전체의 매터리얼을 정의합니다 : 디퓨즈, 노말, 스페큘러, 범프 등등. 맥스나 마야는 렌더링을 위해 섭스턴스를 가지고 있습니다. 그렇지만 유니티도 이제 리얼타임 어플리케이션을 위해 사용할 수 있습니다.

Why use Substance materials?

There are a number of reasons to use of procedural materials:
프로시져 매터리얼을 사용하는 이유들입낟.

Dynamically updateable in game
Resolution independent
Animation supported
Tiny file size
Really fast to create textures, especially bricks, tiles and other tileable surfaces, that are otherwise time consuming to generate from photographic source
Fast to duplicate and create library of unique material
They are cool
게임에서 동적으로 업데이트 가능하고요
해상도 무제한이고요
에니메이션 되구요
사이즈 열라 작구요
벽돌같은 타일링 되는 텍스쳐 만들기 열라 빠르고요, 근데 사진 소스에서 만드는건 좀 시간 걸려요
복제가 빠르고 독립적 메터리얼의 라이브러리를 만들어요
죽여줘요.

Where do I get Substance Materials?

The Asset Store in unity (Window > Asset Store) includes free and paid substance packages available to browse.
얻는법은, 어셋 스토어에 가서 무료나 유료 섭스턴스 패키지를 받아요.

How do I use them?

To customise a substance material and apply in Unity follow these steps:
섭스턴스 메터리얼을 수정하고 적용하려면 다음 스텝을 따라하세요.

Import or create a mesh onto which you want to apply materials;
메터리얼 적용하고 싶은 메쉬를 만들거나 불러오세요.
Make sure it is UV’d evenly, or as desired – use a checkerboard or dummy material (Currently unity cannot import subtance materials assigned in external packages)
UV 잘 펴 놓으세요.
Create a fairly even topology, polygons spread to rule out kinks etc.
토폴로지로 만들었어도 폴리곤 잘만드세요.
Apply relevant smoothing as required
스무딩도 잘해놓으세요

Check FBX import settings for the Mesh, Select Materials Generation ‘Per Material’ esp if using multiple materials per object
FBX 임포트 셋팅 체크하세요. 여러 메터리얼을 각 오브젝트에 적용하려면 특별히 퍼 메터리얼로 메터리얼 생성하세요.
Drag object into hierarchy or viewport and save scene
하이어라키로 불러오세요.
Find Substance material asset you want to use (the square substance icons)
사용하고 싶은 섭스턴스 메터리얼을 찾으세요. (네모난 섭스턴스 아이콘이요)

Select + to ‘Add substance from prototype’ or to create a substance material (spherical icon)
인스펙터 창에서 + 버튼을 눌러서 ‘프로토타입으로부터 새로운 메터리얼 만들기’ 를 하세요.
Name the new material
새로운 메터리얼 이름을 정하세요.

Apply to object by dragging directly onto the mesh in the viewport or with multi material meshes to the element (shown below)
그리고 적용시키세요. -_-; (해석할 가치도 없…)

Edit the parameters for your material instances;
당신의 메터리얼을 위해서 파라미터를 즉석에서 조절하세요
Randomise seed to create variations on the patterns
패턴 생성을 위해서 시드를 렌더마이즈 하세요
Adjust sliders for other parameters such as colour, dirt amount, normal strength or whatever your substance has exposed in the inspector
여러 가지 옵션들을 슬라이드 바로 조절하세요
Change shader if required to add reflections and other fx
리플렉션이나 특수효과들이 필요하면 쉐이더를 바꾸세요.
View the results in the viewport – can be useful to create shader spheres in your scene for representative lighting
뷰포트에서 확인하세요.

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

그러니까… 간단하게 말해서 프로시져 텍스쳐를 완전히 처음부터 만드는 기능은 유니티 안에는 없군요.
그건 전용 생성 툴을 이용해야 가능한듯. 섭스턴스 에어가 바로 그 프로그램이겠지요.
(주:Allegorithmic’s Substance Designer 라고 하네요. 어떤거야 -_-;; 같은건가? )
(주2: 이게 한 번 사용해 보니까… 확실히 디자이너들이 만들기 꽤 난해합니다. 효과적인 응용을 위해서 프리미티브 메터리얼을 만들어 놓고 이걸 수정해서 사용해라 … 라는건 확실히 수긍이 가긴 합니다)

일단 우리가 사용해 보려면, 다른 플러그인 설치는 필요 없지만 ‘프리미티브 메터리얼’ 은 받아야 합니다.
여기에서 받을 수 있네요. http://www.turbosquid.com/Search/Allegorithmic-Substances
일단 3개의 프리미티브 메터리얼을 프리로 받을 수 있습니다.
혹은 유니티 프로그램에 있는 어셋 스토어에서도 동일한 것을 받을 수 있습니다. (Window / Asset store. Ctrl+9를 눌러보세요!)

그리고 추가의 메터리얼은 5$ 쯤 되는게 굉장히 많은데, 이 라이센스가 어떻게 되어 있는지..? 일단 이게 파일로 받아지니까 그냥 하나 받아서 공유하면 끝 아닌가…? (찾기 귀찮…) 무료는 일단 받으니 그냥 메터리얼 파일(.sbsar) 이네요. 유료라도 별다를게 없을듯? 뭐 아니라고 해도 배경팀 한 두 명만 사용할테니 결재해도 큰 무리는 없을듯.

나중에 맥스 최신버전에 섭스턴스가 추가된다고 하는데, 거기서도 이런 스타일로 추가되는 것인지, 아니면 거기서는 직접 만드는 것인지 모르겠네요. 일단 가격이 그리 비싼 것은 아니기 때문에 만들어진 것을 그대로 개조해서 사용하는 것도 괜찮을 듯 합니다. 속도도 빨라지겠고, 베리도 편해지고요.

그 외에도 Bitmap2Material 이라는 소프트웨어도 유료로 받을 수 있습니다만. (앱스토어에서요) 이것은 오히려 크레이지 범프와 비슷한 느낌의 프로그램입니다. 기능은 좀 더 있는 것 같지만… 그다지 이건 안끌리네요.

분명히 잘 사용하면 장점이 있어 보입니다만… 단점이 없는지 확인 안하는 것도 이상하지요.
요건 2부로 넘어갑니다.

Making of Atlantica

Mon, 15 Aug 2011 10:37:50 +0000

실시간 전략 턴제 MMORPG 게임인 아틀란티카는 ‘군주 온라인’으로 새로운 경제와 정치 시스템을 MMORPG에 접목시킨 게임업체 Ndoors 에서 제작한, 전 세계 12개국에서 약 1천만명의 회원을 보유하고 있는 턴 베이스 방식의 전투를 가지는 유명 MMORPG 이다.

이 게임을 기획하고 제작한 김태곤 상무는 약 20년이라는 기간동안 충무공전과 임진록 시리즈, 천년의 신화 등 유명한 전략 시뮬레이션 게임을 개발하였으며 ‘임진록온라인 거상’을 비롯하여 ‘군주 온라인’ ‘아틀란티카 온라인’ 등 성공적인 게임을 연속으로 흥행시킨, 몇 안되는 한국의 스타 개발자중 한 명이다.

아틀란티카는 전 세계의 실제 지명을 기반으로 한 가상의 세계를 돌아다니면서 잊혀진 대륙 아틀란티스의 전설을 찾는 내용으로 이루어진 전형적인 방식의 MMORPG 이다. 주인공은 아틀란티스의 후예로, 사라진 아틀란티스 대륙을 찾아 전세계를 돌아다니면서 각국의 독특한 용병들을 영입하여 성장시키면서 최대 9명으로 조합되어진 독특한 용병단을 이끌게 되는데, 각 용병들은 다양하고 개성적인 외형과 스킬, 능력을 가지고 또한 그 다양한 조합에 따라 숨겨진 능력이 발현되기도 한다.

“아틀란티카의 시작은 사실 군주온라인(북미버전명 ‘루미나리’)에 그 뿌리를 두고 있다고 할 수 있습니다. 우리는 군주온라인의 실험적인 경제와 정치 시스템이 훌륭하게 안착되었음을 깨닫고, 그 단점을 개선하고 좀 더 글로벌하게 통할 수 있는 MMORPG 게임을 만들고자 했지요. 일단 군주 온라인에서는 한국적인 지형과 내용에 너무 치중한 나머지, 외국에 수출할 때 외국인들이 내용을 이해하고 몰입하는데 한계가 있을 수 밖에 없었습니다. 그렇다고 완전히 재창조된 낯설은 판타지로 우리 회사 제품들의 특징이었던 역사와 교육의 접목을 포기하고 싶지는 않았기 때문에 우리는 전세계의 전설, 설화, 지리와 역사를 모두 이용한 컨텐츠인 ‘아틀란티카’를 제작하기로 했지요”

아틀란티카 이건 개발팀장이 말했다.
“그동안 한국의 온라인 게임들은 콘솔게임 전투의 액션성을 따라잡아야 한다는 묘한 열등감을 가지고 있었습니다. 그렇지만 우리는 ‘재미있는 게임의 종류는 아주 많은데 어째서 대형 온라인 게임은 모두 실시간 액션 전투이어야 하는가’ 라고 생각했습니다. 사실 우리의 추억에는 수많은 턴제 전략게임이 남아 있었고 실제로 우리는 그동안의 경험에 비추어 볼 때 액션보다 전략성이 강한 게임쪽을 훨씬 잘 만들 수 있었습니다. 또한 장기간 즐겨야 하는 MMORPG의 특성상 지속적인 집중도를 요구하는 높은 수준의 액션성은 상당한 피로를 유발할 수 밖에 없었고, 그렇다고 아무 생각없이 기계처럼 클릭만 하는 전투를 만들고 싶지는 않았기 때문에 우리는 우리가 잘 할 수 있는 전략성이 강한 턴제 온라인 게임으로 방향을 잡게 되었습니다. 때문에 우리는 극한의 액션성을 추구하며 경쟁하는 다른 대형 온라인 게임들과 확실한 차별성을 가질 수 있게 되었지요. "

about Atlantica

개발사 : (주)Ndoors
유통사 : (주)Ndoors
출시일 : 2008.1.10
출시 플랫폼 : PC
사용된 주요 개발 엔진 :
Gamebryo
SpeedTree

게임 개발 소요 시간 : 약 2년
개발 팀 규모 : 오픈시 약 200 여명
개발 예산 : 약 30억원
수상 내역 및 실적 :

대한민국 게임대상 최우수게임상(국무총리상) 수상 / 우수개발자상(김태곤 개발이사) -ml:namespace prefix = o ns = “urn:schemas-microsoft-com:office:office” /-ml:namespace prefix = o /-ml:namespace prefix = o /-ml:namespace prefix = o /-ml:namespace prefix = o /-ml:namespace prefix = o /-ml:namespace prefix = o /-ml:namespace prefix = o /-ml:namespace prefix = o /-ml:namespace prefix = o /

문화관광부 이달의우수게임 수상

KGC AWARDS Game Design부문 대상

중국 금령상 ‘2008 중국 최고의 해외 온라인게임대상’ 수상

태국게임쇼(TGS)‘최고 온라인 게임상’ 수상

What Went Right

숙련되고 오래 호흡을 맞춰 온 핵심인력들

아틀란티카의 개발팀은 Ndoors가 생기기 이전부터 HQteam이라고 불리우는 팀으로 존재했던 개발팀이며, 그 핵심인력들이 대부분 그대로 유지되어 왔던 관계로 주요 인력들 중 상당수가 10년 이상 같이 한 팀에서 일해온 팀원들이었다.
“단지 경력만 오래 된 인원들이 아니라, 실제로 10년 이상 손발을 맞춰 온 인원들이 모여서 만드는 안정감은 생각보다 무척 큰 힘이 되는 것이었습니다. 또한 덕분에 초반에는 매우 적은 인원으로 프로젝트를 진행할 수 있었지요”

물론 오래된 팀이 장점만 있는 것은 아니다. 오래된 팀에서 흔히 볼 수 있는 대표적인 단점은 자신들의 방식에 너무나도 익숙해짐으로써 생기는 매너리즘인데, 다행히도 이것은 도전적인 프로젝트를 빠른 속도로 계속 만들어가야 하는 회사 특유의 상황으로 인해 오히려 장점으로 승화되었다.
“전혀 새로운 상황이나 문제가 닥쳐 오더라도, 김태곤 상무와 함께 오래 호흡을 맞춰 온 능숙한 리더들은 빠르고 합리적으로 문제를 해결하는 법을 알고 있었습니다. 그리고 서로가 그 해결책을 알고 있다는 것조차 서로 알고 있었지요. 남은 것은 불확실한 것들만을 골라 빠르게 테스트 해 보고, 빠르게 결정을 내리는 것 뿐이었습니다.중요한 것은 원칙이라던가 고정된 절차 같은 형식이 아니었습니다. 중요한 것은 ‘우리가 원하는 게임을 만들기 위해 지금 당장 필요한 것은 무엇인가’ 라는 걸 생각하고, 당장 실행하는 행동력이었습니다. "

빨리 만들기

‘아틀란티카’가 성공할 수 있었던 대표적인 요인 중 하나는 빠른 개발이다. 사실 ‘아틀란티카’가 개발되기 전, ‘아틀란티카’는 이미 ‘군주온라인’의 전투를 개량하여 턴제로 제작한 ‘군주배틀’ 이라는 이름의 게임으로 알파 버전까지 제작되었으며, 일부 유저들에게까지 공개까지 되었던 상태였다. 이 게임은 군주 온라인의 리소스를 대부분 재 이용하여 제작한 것이었기 때문에 매우 빠른 시간에 만들 수 있었다. “군주 배틀은 확실히 가능성이 있었습니다. 게임의 가장 중요한 핵심목표였던 턴 방식의 전투가 완성되자, 그 외의 것들은 군주온라인에서 제작한 것을 그대로 이어와서 개량하면 되는 것이었지요. 이렇게 재빠르게 게임을 만들고 보니 게임이 성공할 수 있다는 충분한 확신을 가질 수 있게 되었지요. 이제 남은 것은 이 재미있는 게임을 전세계에 통할 수 있도록 개량하는 일이었습니다”
그리고 약 1년동안, 2D로 제작되어졌었던 이 게임은 유명한 게임엔진인 게임브리오를 통해 3D로 다시 제작되어 아틀란티카로 완성되어 출시하게 되었다.

<아틀란티카의 전신이었던 군주배틀>

“계획이 구체화되고 집중되면 어떤 경우에서건 유리합니다. 우리는 난생 처음 만드는 3D 게임임에도 불구하고, 게임의 기본적인 구조와 목표가 구체적으로 완성되어 있던 상태였기 때문에 실수와 낭비를 최대한 줄일 수 있었습니다”
아틀란티카 프로그램팀장인 손석환 팀장이 말했다.

" 그렇지만 그렇다고 서버와 클라이언트의 안정성을 소홀히 할 수는 없었지요. 멋진 비주얼을 제공하고 재미를 보장하는 게임이라고 하더라도 불안정한 서비스와 운영은 유저들에게 버림받을 수 밖에 없기 때문에, 이 부분에 대해서는 절대로 양보할 수가 없었습니다. 많은 개발자들이 밤낮은 가리지 않고 수백번이 넘는 테스트를 진행하였고, 최대한 많은 에러 검출 환경을 구축해 테스트 하였습니다. 덕분에 짧은 개발 기간에도 불구하고 안정된 서비스를 할 수 있었습니다”

온라인 게임의 특성상, 절대로 양보해야 하지 말아야 할 것은 안정성이다. 아무리 잘 만든 게임이라 하더라도 수시로 접속이 끊어지는 게임이라면 절대로 성공할 수 없다. 때문에 속도를 우선시하는 개발 환경이었더라도 반드시 지켜야 할 필수적인 덕목은 재미와 안정성이었고, 이 두 가지가 갖춰지지 않은 상태에서는 게임을 공개하지 않는다는 것이 가장 중요한 목표였다.

개방된 커뮤니케이션

Ndoors에는 매우 단순한 게시판 형태의 인트라넷이 존재한다. 프로젝트와 직무 그룹에 따라 구분되어 있는 이 단순해 보이는 게시판은, 모든 개발내용을 비롯하여 운영과 영업내용에 대해서까지 거의 실시간으로 하나도 빼놓지 않고 올라온다. 모든 게시판은 모두에게 열람, 작성할 권한이 있으며 특별한 작업 보고서나 기획서등을 따로 문서로 제작하지 않고 인트라넷으로 공유하고 있다. (심지어는 매출과 동접내역까지도 어떠한 수정도 가하지 않은 실제 데이터가 올라온다) 직원 평가등 비밀로 해야 하는 내용을 제외하고는 회사의 거의 모든 데이터가 공유되는 이 게시판은, 하루 평균 200~300개의 게시물이 올라오기 때문에 꼼꼼히 챙겨보지 않으면 회사의 중요한 공지사항이나 개발 방향을 놓칠 수도 있다.

“지극히 단순한 구조의 인트라넷은, 누구나 보자마자 바로 적응할 수 있다는 장점이 있습니다. 그리고 의무적으로 인트라넷 사용을 활성화시키기 때문에, 인트라넷을 통하지 않으면 일이 진행되지 않습니다. 누구나 게임에 대한 의견을 말할 수 있고, 누구나 다른 팀에서 진행되는 내용에 관심이 있다면 볼 수 있고 질문을 할 수 있습니다. 때문에 인트라넷의 활용 여부를 조사하는 것 만으로 어느 직원이 회사에 관심이 있는지 쉽게 알 수 있었습니다. 모바일 버전도 준비되어 있어서, 해외 출장 중이건 여행중이건, 심지어 휴가 중에도 - 조금 슬프지만 말입니다 - 인트라넷을 훑어 보는 것 만으로 현재 프로젝트와 회사의 상태를 쉽게 알 수 있었습니다. 그리고 이것은 쓸모없는 ‘문제점 공유만을 위한 회의’로 낭비되는 시간을 대폭 줄일 수 있었고, 수 많은 인원으로 돌아가는 거대한 프로젝트가 제대로 굴러갈 수 있게 해 주었습니다.”

지금도 인트라넷에는 하루에 300개 이상의 글이 매일 올라오고 있고, 여기서 좋은 의견을 지속적으로 낸 그래픽 디자이너가 기획자로 발탁되는 경우도 여러 번 있었다.

What Went Wrong

그래픽 수준의 문제

“사실 이것은 커다란 문제였습니다” 그래픽을 담당했던 고동환 AD와 정종필TA가 말을 이었다. “이전까지는 귀여운 스타일의 2D 게임만 만들던 그래픽 디자이너들에게 갑자기 실사 스타일의 8등신 캐릭터가 뛰어다니는 3D 게임을 만들라고 하는 것은 보통 일이 아니었지요. 우리는 우리의 직원들이 꾸준히 발전하고 싶어한다는 욕구가 있음을 알고 있었고, 자신의 가능성을 발견하고자 하는 것을 알고 있었습니다. 때문에 새로운 프로젝트를 위해 새로운 직원을 고용하지 않고, 기존의 인력들 중에서 새 프로젝트에 도전해 보고 싶은 직원들을 자체적으로 교육시켜 아틀란티카를 제작하도록 하고 싶었습니다. 그렇지만 이것은 그렇게 쉬운 일이 아니었지요. "

이 문제는 그래픽 뿐만 아니라 프로그램에서도 마찬가지였다. 3D 엔진을 처음 다뤄보는 개발자들이 대부분인 상태에서 대형 3D MMORPG를 만드는 것은 쉬운 일이 아니었다. 때문에 가장 다루기 쉬운 엔진이었던 게임브리오를 선택 해서 사용했지만, 기술팀이 초반에는 존재하지 않았기 때문에 컨텐츠 개발자들만으로는 많은 그래픽 기술까지 섬세하게 지원하는 것은 한계가 있었다.

“그래픽 디자이너가 최선을 다해 만들어 놓은 그래픽이, 3D MAX 에서 볼 때보다 게임에 넣었을때 더 안좋아 보이는 경우가 많이 발생했었습니다. 덕분에 우리는 게임을 서비스하기 직전까지 게임 엔진과 셰이딩을 업그레이드 하면서 그래픽 데이터를 다시 제작해야만 했었습니다. 다행히도 후반부에 기술팀이 조직되면서, 서비스하기 직전에는 어느 정도 원하는 그래픽 수준까지 올릴 수 있었습니다만 많은 그래픽 디자이너들이 그 댓가를 감수해야만 했었습니다.”

유지보수가 쉽지 않았다.

빨리 제작한다는 것은 장점도 있지만 단점도 가지고 있는 양날의 검과 같다. 빠르게 제작하는 것은 분명히 성공적인 게임 개발을 위해 중요한 일이지만, 때로는 제대로 준비가 되지 않은채로 진행될 수도 있다는 위험성이 있다.
“당장은 필요 없어 보이지만 나중을 위해 필요한 것들을 잊어서는 안되었었습니다. 사실 경험이 부족했던 것도 한 이유라고 할 수 있었지요. 빠른 제작을 위해 너무 많은 하드코딩이 들어갔었고, 이것은 지속적으로 큰 폭으로 계속 개량되어야 하는 온라인 게임에서 큰 약점이었습니다. 대형 MMORPG에서 어느 정도의 예외코드들은 존재할 수 밖에 없지만, 가능하면 최대한 이런 상황을 줄여야 나중에 생길 수 있는 각종 문제나 새로운 요구사항등을 보다 안전하고 쉽게 처리해 나갈 수 있습니다.”

“또한 3D MMORPG 게임은 전세계의 다양한 PC의 사양에서 돌아가야 하기 때문에, 그 안정성을 확보하고 특이한 시스템에서 발생하는 퍼포먼스 저하 등의 이유를 재빠르고 쉽게 인지할 수 있도록 하는 프로파일링 툴과 기능을 꼭 초반에 집어넣었어야 했었다는 것을 배웠습니다. 나중에 게임이 복잡해지면 복잡해질 수록 생겨나는 문제들도 복잡해지는데, 미리 프로파일링으로 문제를 잡아낼 수 있었다면 보다 빠르게 문제를 대응할 수 있었겠지요. 초반에는 툴을 만드는 것보다 그냥 개발하는 것이 물론 빨랐습니다. 그러나 이러한 것들이 쌓이다 보니 서비스가 3년쯤 지나자 엉뚱한 부분에서 개발 시간이 지체되더군요”
아틀란티카 이 건 기획팀장이 말했다.

" 자동화된 툴이 빈약하게 갖추어저 있었기 때문에 수동적인 작업에 의존하는 부분이 많았습니다. 그러다보니 문제가 발생했을 때 원인을 찾기 힘들었고, 심지어 문제를 해결하기 위해서 1~2주간 했던 작업물들을 전부 뒤로 돌리고 새로 시작해야 하는 경우도 발행했었지요. 덕분에 QA 팀에서는 하나의 문제를 찾기 위해서 매주 업데이트 때마다 밤을 새는 일이 부지기수였습니다. 거대한 게임일수록 모든 기능들은 서로 연관성을 가지고 묶여 있기 때문에 새로 개발된 것들만 테스트 해야 하는 것이 아니라, 어디에 어떤 문제가 맞물려 있을지 몰라 항상 처음부터 끝까지 테스트를 진행해야 했기 때문입니다. "

다행히도 이를 깨달은 개발팀은 늦게나마 자체 툴을 제작하여 QA의 자동화를 시켜서, 가련한 QA팀들은 이제서야 집에 갈 수 있었고 일정은 더 이상 밀리지 않게 되었다. 그리고 이후에는 이 교훈을 되살려, 컨텐츠 양과 프로젝트 참여인원의 수가 상대적으로 적은 초기에 툴을 꼭 먼저 제작하는 시스템이 정립되었다.

게임이 너무 어려워졌다.

온라인 게임은 지속적으로 변화해야 하고 개선되어야만 한다. 지속적인 아이템, 퀘스트, 시스템과 컨텐츠들의 지속적인 업데이트만이 온라인 게임의 생명을 늘이고, 유저들이 떠나가지 않도록 붙잡아 둘 수 있다. 아틀란티카 개발팀은 특유의 빠른 개발속도로 다양한 나라의 요구사항에 맞추어 게임을 지속적으로 발전시켜 왔다.

“우리의 유저들은 더욱 더 많은 것을 요구했고, 개발팀은 유저의 다양한 요구들을 충족시켜 주기 위해 끊임없이 게임을 개량시켰습니다. 다양한 아이템을 만들고, 다양한 전략을 위해 다양한 용병과 다양한 스킬들을 만들었지요. 그렇지만 무엇보다 턴제 전투의 가장 큰 약점인, 1인 위주의 전투라는 것을 극복하기가 힘들었습니다”

아틀란티카 이 건 기획팀장이 말했다.

“온라인 게임 유저들은 다수의 유저가 서로 협동을 하면서 전투를 하고 싶어했습니다. 우리도 그렇게 만들고 싶었지요. 그렇지만 많은 유저가 많은 용병을 데리고 서로 협동을 하며 턴제 전투를 진행하기에는 다소 무리가 있었습니다. 한 턴에 30초의 시간이라는 것이, 상의하면서 게임을 진행하기에는 부족했고, 그렇다고 그냥 개인별로 상의없이 게임을 진행하자니 손이 빠른 유저는 손이 느린 유저의 턴이 끝날때까지 지루하게 기다려야 하는 사태가 벌어진 것입니다. 그래서 우리는 그것을 극복하기 위해 대규모 인원들이 협동해서 전투를 할 수 있는 완전히 다른 전투 시스템인 TBS 시스템을 넣기도 했습니다. 하나의 게임에 두 개의 전투 시스템이 들어가게 된 것이지요. 그런데 그렇게 정신없이 업데이트를 하고 있다가 문득 돌아보니, 우리는 우리의 게임이 너무 복잡해지고 있다는 것을 깨달았습니다.”

복잡해진 게임은 게임을 깊게 분석하면서 즐기는 하드코어한 유저들에게는 매력적인 것일 수 있다. 그렇지만 게임을 처음 시작했다던가, 한동안 게임을 쉬었다가 다시 접속한 유저들에게는 자신이 알지 못하는 수준의 과다한 정보는 오히려 게임에 대한 진입장벽이 될 수도 있다.

정리

한국의 게임 개발 역사는 그리 길지 않다. 그리고 그 길지 않은 개발 역사 속에서도, 한국 게임 제작의 태동기에 모인 게임 제작자들이 지금까지 흩어지지 않고 게임 개발 경험을 축적해가면서 매번 새로운 도전을 하는 게임을 제작하는 팀은 손에 꼽을 정도로 적다. 그들은 현재 웹 기반으로 돌아가는 대형 실시간3D MMORPG를 제작하고 있고, 이것 역시 이전까지 시도해 본 적이 없는 새로운 도전이다. 또한 이 게임은 모바일 기기에서도 연동되는 것을 목표로 하고 있다.

“새로운 도전을 하는 것은 언제나 멋진 일입니다. 그렇게 하기 위해서 저희는 가능한 한 빨리, 제대로 된 게임을 만들기 위해 모든 자원을 아끼지 않습니다. 게임 하나를 만들기 위해 5년이나 10년동안 만들게 되면, 온라인 게임에서의 가장 소중한 경험인 유저의 피드백을 받는 경험에 공백이 생긴다는 말이지요. 그렇다고 제대로 완성되지 않은 게임을 시장에 내놓으면 유저의 피드백을 받을 기회도 받지 못하고 사라질 것입니다. 저희는 패키지 게임을 제작해 본 경험이 충분하고, 온라인 게임을 제작해서 서비스 한 경험도 충분하기 때문에, 어느 정도까지 개발하고 어느 시점에서 서비스 해야 하는지에 대한 목표를 비교적 명확하게 정할 수 있는 능력을 가지고 있습니다. 문서나 책으로는 전달할 수 없는 집단의 스타일과 분위기를 꾸준히 유지하기 때문에, 저희는 그 능력을 믿고 계속 새로운 도전을 할 수 있는 것입니다”

모든 집단과 스타일에는 장점이 있는 만큼 단점이 있다. 그렇기 때문에 사실 궁극적으로 옳다라는 방법이나 답이 있을리는 없다. 이것은 누구나 인정하는 것이고, 피해 갈 수 없는 장애물인 것이다. Ndoors의 개발팀도 이 점에 대해서 동의하고 있으며, 가장 중요한 것은 서로간의 커뮤니티의 활성화라고 말한다.
“인원이 많아질수록, 의견도 많고 갈등도 많은 것이 당연합니다. 현실의 벽에 부딪혀 양보해야 할 수도 있고, 시간과 예산, 능력의 부족일 수도 있습니다. 특히 저희처럼 짧은 기간안에 전례가 없는 시도를 하는 프로젝트일 수록 이런 문제는 자주 일어나게 되지요. 이러한 경우, 갈등을 말할 창구가 없거나 숨기기만 한다면 아무런 해결책을 찾을 수 없게 됩니다. 가장 위험한 상처는 겉으로 드러난 상처가 아니라, 겉은 멀쩡하지만 안에서 곪고 있는 상처인 것입니다. 심각해 보이는 문제도, 모두 열어놓고 문제를 펼쳐보면 의외로 쉽게 풀리는 경우도 많습니다. 그리고 우리는 그러한 상처를 드러내고 해결하는 것을 매우 중요하게 생각하고 있습니다. 이것이 우리가 오랫동안 인원을 유지하면서 일할 수 있었던 방법입니다.”

7600GT는 권장사양.. 권장사양 자동인식 공식.

Wed, 03 Aug 2011 17:42:14 +0000

3.2 billion pixel/s and 4.8 billion texel/s

7600 GS의 필레이트가 3.2 빌리언, 즉 3200메가픽셀/초

니깐… 공식을 좀 바꿔야 겠네요.

권장사양은 1280*1024로 했을 때
(1280*1024+400*300)*(30/1000000) = 42.9216
42.9216 * [75] = 3219

new float [] {68.0f, 70.0f, 75.0f, 130.0f, 200.0f}; 가 될 수 있을겁니다.

S 프로젝트 자동사양결정.

Wed, 03 Aug 2011 15:16:22 +0000

현재 최소사양의 fillrate는 1800메가픽셀/초 입니다.
현재 권장사양의 fillrate는 9000메가픽셀/초 입니다 (9 Billion pixel/s)

그리고 레퍼런스 메뉴얼에 따르면 SystemInfo.graphicsPixelFillrate 는

static var graphicsPixelFillrate : int

Description

Approximate pixel fill-rate of the graphics device (Read Only).

Returns pixel fill-rate in megapixels/second, or -1 if fillrate of the device is not known.
그래픽 디바이스의 픽셀 필 레이트를 리턴합니다. (읽기 전용)
픽셀 필레이트는 메가픽셀/초 이며, 필레이트를 못읽을 때에는 -1 을 리턴합니다.

즉 최소사양은 자동설정공식의
fillneed = (float)((resx*resy + 400*300) * (30.0 / 1000000.0));

에서, res는 1024*768이라고 가정하면 (1024*768+400*300)*(30/1000000) = 27.19296
그리고 이것이 1800 이라는 fillrate 에 적합하기 위해서 필요한 상수는
27.19296 * [68] = 1849

이므로 최저사양의 levelmult 는 일단 68 이하에서부터 시작한다는 것을 알 수 있습니다.

권장사양은 1280*1024로 계산해 보도록 하겠습니다.
(1280*1024+400*300)*(30/1000000) = 42.9216
42.9216 * [200] = 8584.32

그러므로 권장사양이 시작되는 levelmult는 200부터 시작한다는 것을 알 수 있습니다

이 두 가지의 levelmult 값을 토대로 각 옵션별 값을 예상해서 배열로 만들어 보면

new float [] {5.0f, 68.0f, 134.0f, 200.0f, 320.0f}; 가 될 수 있을겁니다.
5.068.0 최소
68.0134.0 소
134.0200.0 중
200.0 ~ 320.0 상
320 최상

물론 중간숫자는 예상수치이므로 나중에 변할 수도 있을겁니다.
편하게 밖으로 빼주셔도 감사.

그리고 if문도 좀 수정이 필요한데
이 기준대로라면

if (fillrate < 0)
{
//if (shaderLevel < 10)
// fillrate = 1000; // 쉐이더 1.0 이하를 왜 신경쓰는데
else if (shaderLevel < 20)
//fillrate = 1300; —–> 실행불가로 해주세요. 우린 최소가 쉐이더 2.0 입니다.
else if (shaderLevel < 30)
fillrate = 2000;
else
fillrate = 3000;
if (cpus >= 6)
fillrate *= 3;
else if (cpus >= 3)
fillrate *= 2;
if (vram >= 512)
fillrate *= 2;
else if (vram <= 128)
fillrate /= 2;
}
… 나머지는 놔둬도 되겠네요 .

일단 이렇게 하고 보겠습니다. 기준이 미약한 관계로 추후 계속 수정하도록 하겠습니다.

Project S 퍼포먼스 테스트

Tue, 02 Aug 2011 17:06:07 +0000

뭐 대충 이런 겁니다.
동원할 수 있는 인력이 적어서 사용가능한 하드웨어의 1/3 도 안썼다는…

분석글은 우리 회사 입사하시면 볼 수 있습니다 ㅋㅋㅋ
이건 이미지 링크에 가깝…

그나저나 다른 회사에서는 이 분석 작업을 어디서 하나요? 프로그램에서? QA에서?

S 프로젝트 퍼포먼스 테스트

Tue, 02 Aug 2011 17:00:08 +0000

지난번 1차 테스트의 목적은 , 현재 가장 표준적으로 무거운 맵이 어느 것이며, 전체적인 제작 무게는 어떤가 - 였었고, 그 결과로 구성의 난 맵을 테스트 맵으로 하기로 결정하고 2차 테스트에 들어갔었습니다. 부사수 재철군이 수고 많았습니다.

그리고 이번에
2차 테스트 - 장기 프로젝트가 일단 완료되었습니다.
이 프로젝트의 목적은 다음과 같다고 할 수 있습니다.

현재 우리 게임의 최소사양은 어떻게 예상되는가?
현재 우리 게임의 권장사양은 어떻게 예상되는가?

그 전의 테스트는 사실 로직이 전혀 들어가지 않고 인터페이스도 들어가지 않았을 때 예상한 것이라, 이번에 이 테스트는 꼭 필요한 것이라고 할 수 있습니다.

테스트 방법은 일단 PassMark 사의 벤치마킹 점수를 바탕으로 보유하고 있는 기기를 나열하고, 테스트에 적절한 기기를 표본추출해 일정한 장소에서 프레임을 테스트하여 그 분포를 알아보는 것 입니다.

장소는 구성의 요새 한 가운데 전쟁터를 이용했고, 사용된 하드웨어는 다음과 같습니다. 실제 테스트 가능한 하드웨어는 훨씬 더 많으나, 전부 다 하려면 도저히 두 명이 할 수 있는 양이 아닌지라 상당부분 추려내서 나온 하드웨어 리스트입니다.

점수는 Passmark의 벤치마크 점수입니다.

메모리는 각 1G (기기에 따라서는 2G 이상) 을 사용하였습니다.

결과값

표로 나타내면 다음과 같지요. 그럼 표를 보고 세부 분석 들어가 보겠습니다.

펜4 2.8 입니다. CPU 벤치마크 점수로는 400점이 조금 넘는, 허접한 CPU 입니다.
이미 역사의 뒤안길로 사라진 머신이기 때문에, 사실 그래픽 카드 구성도 다릅니다. 이 CPU만 AGP라서, 그래픽 카드를 높은 녀석을 쓸 수 없어서 이 녀석만 독립적인 그래픽 카드들을 테스트 했습니다.

최저사양이라 하는 것이, 최저 옵션에서 ‘겨우 플레이 가능한’ 레벨의 컴퓨터라고 가늠해 보면, 현재의 이 머신에 그래픽카드는 Geforce 5700 정도가 유력합니다. 최하 옵션에서 13프레임이라는 프레임이 나왔지요.

하지만 속마음은 솔직히 , ‘좀 아쉬운데’ 라는 느낌입니다. 만약 지금 정하라면, 펜4 2.8은 좀 너무하고 펜4 3.0 정도로 하면 어떨까라는 생각이 듭니다. 그래픽 카드도 GF5800 정도로 살짝만 올려주면 어떨까라는 생각이 드네요.

어쨌건 현재 저 조합에서는 최고의 옵션 조합(5700)이 겨우 최저사양에 닿을 수 있다 정도로 보이고 있네요.

그다음 소개해 드릴 머신은 AMD 에슬론 64 3000+ 으로 , 역시 역사의 뒤안길에 사라져 있는 머신으로 펜4 3.2 와 비슷한 느낌의 머신입니다.

여기서부터 아래로는 더이상 AGP가 아니기 때문에, 2.8과는 테스트하는 조합구조가 다를 수 밖에 없습니다. 여기서의 최저 그래픽
카드인 1050이 위 테스트의 최고 그래픽 카드인 5700과 맞먹는 사양을 가졌으니 말입니다.

이 테스트는 그래프가 아주 이쁩니다… 이제 권장사양을 예상해 봐야 할텐데요.. 만약 이 머신이 권장사양이라면, ‘중급 옵션에서
20프레임대의 안정적인 결과’ 가 나오는 그래픽 카드여야 할 것입니다. 그러므로 여기에서는 Geforce 6600 (6600GT가 아닙니다. 그냥 6600이랑 GT랑은 엄청난 차이가 있는 머신입니다) ~ Geforce 9400GT (말이 9000번대이고 GT지만, 사실 9000이라는 이름이 무색하게 안좋은 그래픽 카드입니다. 6600보다는 좋지만) 정도가 될 것입니다.

벤치마크 점수로는 약 200점 정도라고 할 수 있겠네요.

펜4 3.2 테스트입니다. 역시 위 머신 사용과 그렇게 크게 다른 녀석은 아니기 때문에, (살짝 좋지요) 살짝 좋은 정도의 결과가 나옵니다. 가장 나쁜 그래픽 카드는 X1050는 큰 차이를 보이지 않습니다만, 6600부터는 위의 머신과 차이를 꽤 보이고 있는 것으로 보아 , (물론 최상 옵션은 6600으로는 택도 없지만요) 그러므로 이 엔진은 확실히 그래픽 카드도 카드지만 CPU를 상당히 타고 있다는 것을 볼 수 있습니다.

여기서도 역시 6600은 중간옵션에서 약 20프레임이 좀 안되는 모습을 보이고 있습니다. 아쉽지요. 9400GT 정도만 나와도 꽤 괜찮을 텐데요. 사실상 권장사양은 대충 눈에 보이고 있음을 알 수 있습니다. 그치만 여기서 또 갈등인것이,

최소사양은 펜4 3.0 인데 권장사양이 펜4 3.2 라는 것은 좀 아닌 것 같다는 거지요.
더군다나 게임을 즐기는 유저가 1024*600 이라고 하는 화면사이즈를 지킬 것 같지도 않고, 웹게임이다 보니 편하게 다른 작업도 할테니까 좀 더 높았으면 하는 건데… 문제는 이 다음 CPU가 장비실에 없어유… OTL

이 다음은 펜티엄 D 군인데, 우리는 D군 보유는 전혀 없고 곧장 코어2 듀어로 넘어가는게 문제네요 OTL

펜티엄 D 군은 없지만, 그나마 펜 D 보다는 좀 높고 코어2 듀얼보다는 살짝 낮은 CPU인 AMD 3600+ 입니다.
여기서도 보시면 알겠지만 X1050은 쓰레기 ….
6600은 되어야 CPU를 받아줍니다. 물론 최고옵션은 여전히 무리…

여기서 부터는 그래픽 카드가 6600만 되어도 권장사양에 충분하고 그 이상까지 올라간다는 것을 알 수 있습니다. 30프레임 제한까지 올라가니까요.
그렇지만 최고 옵션은 그래픽 카드가 올라가도 프레임이 15프레임에서 고정된다는 것은 좀 의외였습니다.
여러 가지 예상을 할 수 있는데, 정확히 무엇이 원인일지는 단정내릴 수 없네요. Vsync 같은 것부터 안티알리아싱 (지금은 빠졌지만) 등 … 어쨌건 최고 옵션에는 ‘무언가 있습니다’

코어2로 드디어 넘어왔습니다. x1050은 더이상 눈에 들어오지도 않습니다. 이미 권장사양은 대충 나온 상태거든요. 이제는 ‘최고사양’ 에 오히려 관심이 갑니다. 하지만 여전히 15프레임 이상 올라가지 않습니다. GTS250으로도 프레임이 안나오다니, 뭔가 문제가 있습니다. 옵션을 재조정 해 볼 필요가 … (사실 이미 조정했지만)

E6500입니다. 여기서는 6600이 중간 옵션에서 다소 이상한 결과를 나타냈군요. 쓰레기값이라고 보입니다. 어쨌건, 드디어 그래픽 카드에 프레임이 반응하기 시작합니다! 하긴… GTS 250에 E6500 이상은 끼워줘야 사실 말이 되긴 하지요.

AMD 페놈2 까지 왔네요. 이젠 뭐 사실 막장까지 왔지요. 이젠 최고 옵션에서도 최고 프레임이 슬슬 나오려고 합니다. 하긴 코어 4에 9400GT 같은, 9000 대의 수치라고 말할 수 밖에 없는 카드가 가당키나 한가요. 이제 좀 논리적으로 맞아갑니다.

장비실 최고의 극강의 CPU 쿼드 9550 입니다. 페놈 2와 거의 같은 결과입니다만 좀 더 높습니다. 역시 CPU가 올라가니까 밀어 쳐 주네요 … 옵션이 올라간다고 그래픽 카드에만 연연하지 않는게 확실합니다. 하긴 소프트 스키닝이니… CPU의 파워가 스키닝에서 확실히 역량을 발휘하니 좀 더 CPU 의존도가 높을 수 밖에 없겠죠.

위와같은 장기 프로젝트 - 한 2주 걸린 것 같습니다 . 업데이트 안되어 있는 장비도 너무 많고 가동중지된 장비도 많아서 고치느라 - 의 결과에 따라 결론을 내 보면, 일단 알게 된 것은 CPU의존도도 상당히 크다는 것과 넷북에서 돌아갈만큼 가벼운 게임은 확실하게 아니라는 것입니다. 고사양은 물론 아니겠지만, 최근 추세에 보면 꽤 낮은 게임이란 것도 맞겠네요.
또한 위 테스트는 인터넷 익스플로러 8.0 기반으로 제작되었습니다. 윈7에서 9.0으로 돌리면 조금 더 프레임이 나오고, 다른 브라우저에서 돌리면 프레임이 더 높게 나옵니다. 그렇지만 대부분의 유저는 익스플로러를 이용하고 있으므로 이 테스트가 적합하겠지요.
: 와우보다는 최소사양이 높습니다. 권장사양은 와우와 비슷한 편입니다.; 리니지2보다는 최소사양이 낮습니다. 권장사양은 비교하기 힘들지만 살짝 낮습니다.; 던파에 비한다면 CPU밖에 비교할 수 없으며, 던파와는 최소사양과 권장사양이 거의 동일합니다.; 아틀란티카에 비하면 최소사양이 높습니다. 권장사양도 높습니다. 단 , 모두 CPU만 높습니다.

결론

위 테스트에 따르면, 현재의 최소사양은 약
펜 4 3.0 이상 , 메모리 1G 이상, 그래픽 카드 지포스 FX5900 이상 정도라고 할 수 있겠습니다.

권장사양은 아래와 같겠지요
펜티엄 D 프로세서 이상, 메모리 1G 이상 (2G로 할까…) 그래픽 카드는 지포스 7600GS 이상이라고 할 수 있겠네요.

또한 위 테스트는 거의 확정된 결과값이라고 할 수 있겠습니다만, 여전히 변수는 존재합니다.

유저 캐릭터가 몰렸을때의 결과는 계속 봐야 합니다. 또 무슨 일이 일어날지…
현재 옵션 내용 일부가 바뀌었습니다. 예상하기로는 최저는 그대로지만 중간과 최상은 다소 가벼워지지 않았을까 생각합니다.
최적화 기능 제작이 꾸준히 되면 좀 더 나아질수도 있습니다.

다음은 제 3단계로, 적합한 최소와 권장의 표준PC를 만든 후, 세부 프로파일링 테스트를 해 가면서 진짜로 게임을 장기간 즐겨 보고 구체적인 개선안을 계속 찾아가는 것입니다. (아아 역시 긴 시간이 필요해요…)

어떻게 쉐이더를 공부했냐고요?

Fri, 29 Jul 2011 21:37:47 +0000

이것 또한 많이 받는 질문 ㅋㅋ
아 맥주 한 잔 걸치고 쓴김에 또 씁니다. 요샌 트위터만 쓰다 보니 아주 낯설군요 ㅎㅎ
솔직히 저도 한창 공부하고 있는 수준이라 이런 글 쓰는게 아주 창피해서 그동안 안쓰고 있었습니다만
굳이 그렇게 질문해 주시니… 그냥 참고만 해주세요. 저따위는 상대도 안되는 분들이 넘칩니다.
eyoung80 같은 굇수분들이 진짜 분들이죠… 혼자서 게임 하나를 다 만드실 수 있으신 분… 저같은거야..

쉐이더를 어떻게 공부하냐. 뭐 글쎄요.저같이 어깨너머로 대충 배운 사람한테 질문 하시는 것 자체가 무리입니다 ㅎㅎ
진짜로 제대로 공부하려면, 물리나 수학과를 졸업해야 합니다!!! 어깨너머로 대충 배운 것은 한계가 반드시 와서 , 조금만 어려운 공식이 필요하면 프로그래머에게 찾아가 사정하면서 배워야 합니다!! 저처럼 !!! ㅋㅋㅋㅋㅋ

그치만 그렇다고 대학을 다시 갈 수도 없고 ㅋㅋ 뭐 어쩔 수 없이 뽀록으로라도 배우셔야 한다면, 알려드릴 수 밖에 없지요.
미리 경고 드렸습니다. 이거 상당히 근본없는 방법입니다 ㅎㅎ

우선 맨 먼저 필요한 것은 C 가 맞습니다. 이건 뭐 클래스 정도까지는 필요가 없는 관계로, C++ 까지는 필요 없는 거지요.
이것을 공부하는 이유는, 아주 기초적인 프로그래밍 문법을 익히기 위해서 입니다. 뭐 맥스 스크립트를 짜시는 분은 필요 없을 수도 있습니다. 프로그래밍을 하면서 띄어쓰기는 무슨 의미인가, 줄바꿈은 무슨 의미인가, ; 이나 && || 을 비롯한 각종 용어들이 기본적으로 무엇을 의미하는지 알아야 하기 때문입니다. (대부분 여기서 포기합니다)

그 후 프로그래머 분들은 API를 주로 추천하십니다만, 저는 별로 추천하지 않습니다. 굳이 배울 필요까지 없어요… 몰라도 할 수 있습니다. 그것보다는 다이렉트 X 를 그 다음으로 꼭 공부해야 합니다. 주로 ‘용책’ 이라고 불리는 책으로 공부하시죠. 그 책 수준 정도면 일단 무리 없습니다. API를 공부하셨다면 조금 더 쉽게 하실 수 있겠지만, 어차피 쉐이더만 배울거라면 그 부분은 대충 넘어가도 되거든요.

대신 다이렉트 X 에서 배우는 것은 다이렉트 X 를 실제로 다루는 코딩 능력보다, 이론이 중요합니다. 어떻게 렌더러가 가동되고, 어떤 순서대로 그려지고, 알파는 어떤 문제가 있으며, 포그나 후처리, 각종 메트릭스, 깊이 버퍼 등의 중요한 이론들을 잔뜩 배우게 됩니다. 이건 정말로 중요합니다. 아참, 기초 수학도 배우셔야 합니다. 벡터의 합과 뺄셈하는 법이라던가… 메트릭스 연산, 쿼터니언, 싸인 공식 등…

그러면서 동시에 (그 후에 해도 상관없습니다만 질리겠죠) hlsl 언어를 공부하시는게 좋습니다. 그래픽 디자이너라면, 맥스의 쉐이더 기능을 이용해서 fx 쉐이더를 짜보시는게 좋습니다. 이 부분의 책은 거의 없기 때문에 처음에 시작하시기 힘드실 수 있기 때문에, 처음에는 김용준님의 해골책이나, 게임아카데미에서 나온 쉐이더 이론 책을 보시는게 쉽습니다. (혹은 제 블로그를 참고하셔도 됩니다 ㅎㅎ)

이제부터는 좋은 쉐이더를 보면서 계속 공부하시는 수 밖에 없습니다. 슬슬 GPG 같은 책도 눈에 들어오시겠지요. 그걸 공부하실 수준이면 이제 실무에 들어오셔도 충분할 수준입니다. (저도 아직 잘 못봐요. 참고만 좀 하지) 이론은 ‘리얼타임 렌더링’ 이라는 책으로 더 보강하시면 됩니다. 제가 그렇게 했거든요.
그 정도면 되면 수학과나 물리학과는 나오지 않았더라도, 폐를 끼치지 않을 정도의 실력은 되고, 무시당하지 않을 정도는 됩니다.
아참, 회사에 설명 잘하는 프로그래머를 스승으로 모시는 것도 중요합니다 ㅎㅎ 몇 안되지만, 그런 스승을 만나야 큰 도움이 되지요

저는 C 를 공부하려다 몇 번이나 포기하고 또 하고 하다가… 무작정 쉐이더부터 공부했습니다. 당근 왜 C를 배워야 하는지를 알게 되었죠. 이건 뭐 띄어쓰기를 언제 하면 되는지, 대괄호는 다음 칸에 써야 하는지 옆에 써도 되는지 , 어떤건 왜 ; 를 뒤에 안붙여도 되는지…

그걸 배우고 나니 혼자서는 공부에 한계가 있을 수 밖에 없다고 생각하고…. 대학원에서 C를 한 학기 배우고, DirectX를 한 학기 배웠습니다. 둘다 다행히 운좋게도 정말 좋은 교수님 만나서 재미있고 쉽게 배울 수 있었죠 :) 그동안 삽질하면서 공부해 둔것도 나름 쓸모가 있더군요. 실무에서 부딪히면서 배웠던 일들이 DirectX 를 배우면서 , 왜 그렇게 되었는지 이론을 알 수 있게 되었지요.

그렇게 졸업하고 나서 다시 처음부터 쉐이더를 공부한 것은 제 블로그에 잘 나와 있습니다. 맥스 쉐이더로 연습을 하고, 맥스 쉐이더가 한계가 있어서 렌더몽키로 툴을 교체했다가, 굉장히 재미가 없어서 다시 겜브리오로 바꾸었습니다. 지금은 유니티를 쓰고 있구요.
그동안 책으로 공부한 것들을 기반으로, 엔진 메뉴얼을 봐 가면서 제작하고 있구요. 아참, ShaderFX 같은 프로그램(노드 구조로 언리얼 메터리얼 에디터처럼 쉐이더를 비주얼로 짤 수 있게 해주는 플러그인. 무료입니다) 으로 출력한 쉐이더 코드들을 분석하는 것도 무척 도움이 됩니다.
겜브리오 때부터 실무 쉐이더를 보조로 짜기 시작했고, 유니티가 되면서 부터는 쉐이더를 전부 관리하고 제작하고 있습니다. 덕분에 그래픽과는 더 멀어진 … ㅋㅋ
뭐 이렇게 대충 배웠기 때문에, 사실 제대로 된 공식이나 복잡한 물리 공식을 만들어 내는데는 무리가 있을 수 밖에 없습니다 :) 그냥 근근히 폐나 끼치지 않게 살고 있는 거지요.

일단 간단하고 재미있게 하시려면, ShaderFX 같은 툴을 이용해서 가지고 노시면서 개념잡는게 재밌습니다.
하지만 직접 짜시려면 위에 설명한 것과 같이 꽤 긴 과정을 거쳐야 하지요.
그치만 또 모릅니다… 노드구조만으로도 사실 완벽하게 짤 수 있거든요. 일정 수준을 넘어가면 대단히 복잡해지고 관리하기 힘들어 지는게 문제지… ㅎㅎ

그러므로 본인이 목표하시는 수준을 잘 결정하시고, 그 수준에 맞는 방법을 선택하시면 되겠습니다.
독학도 가능하지만… 쉽지는 않더군요. 프로그래머 스승분을 친해 놓는게 제일 빠르리라고 생각합니다 ㅎㅎ

테크니컬 아티스트는 무엇을 합니까?

Fri, 29 Jul 2011 21:16:39 +0000

네, 질문글이 올라온 김에…. 원래는 메일로 보내드리겠다고 했는데 생각해 보니 간간히 받는 질문이기도 하고요, 뭐 비밀이라고 메일로 보낼것 까지야… -_-;; 라는 생각도 들어서 오픈으로 써 봅니다.

우선 말씀 드리자면, 저 실력 허접합니다. 이건 뭐 그래픽 디자이너도 아니고 프로그래머도 아닌 느낌으로, 요새 그래픽 디자이너들한테는 발리는 실력이 되어 버렸고 그렇다고 이전부터 수학과를 졸업하고 프로그래밍으로 살아온 친구들에게는 허접하게 느껴지는 수준이죠ㅎㅎ 테크니컬 아티스트라는 직종이 공식적으로 없었다면, 전 아마도 지금까지 난 뭐지? 라고 생각하면서 월급벌레라고 가슴을 치면서 살고 있었을지도 모릅니다.

우선 제가 하고 있는 일을 소개해 드립니다. 실력은 개떡같지만 조금 오래 되었고 형이라고, 쟁쟁한 ad들 한테서 매주 그래픽 팀 작업 내역화 현황을 보고받고 있고, 그래픽 리소스들이 제가 처음에 내린 기준 안에 해당되는지를 판단하고 있습니다. 요샌 그림 손놓은지 오래 되어서 그릴 수나 있을지 ㅎㅎ..

물론 이것 역시 미리 말씀 드리지만, 전 세계의 테크니컬 아티스트들은 전부 다른 일을 하고 있으며, 공식적으로 TA가 이래야 한다라는 메뉴얼이나 규칙도 없습니다. 즉 매우 주관적인 내용이며, 저희가 이렇게 해요.. 라는 내용일 뿐입니다.

저희 회사의 TA 들은 이렇게 일하고 있습니다.

일단 프로젝트 시작할때 기획 내용과 AD의 원하는 방향, PD의 원하는 방향과 프로그래머들의 의향을 종합해서 사용할 기술과 사용하지 않을 기술들을 시대의 유행과 회사의 역량등을 종합하여 고려해서 기준을 정합니다. 그리고 그래픽 디자이너들에게 사용가능한 폴리곤 배분과 각종 기술제한 사양등을 교육하고 지속적으로 체크합니다. 그래픽 디자이너들은 구체적인 기준이 있을때 그 한계까지 하려고 발버둥치거든요 ㅎㅎ 가장 싫어하는건 기준이 너무 없을 때입니다.

그리고 프로젝트가 시작되면 그래픽 리소스의 낭비나 삽질이 없도록 기획회의부터 참석해서 기술적 조언을 하고, 수시로 직원들에게 교육자료를 만들어 강의도 하고 시험도 보면서 그래픽 디자이너나 기획자들에게 효율과 제한이라는 조건을 생각하면서 어떻게하면 최고로원하는 것을 가깝게 만들 수 있을 것인가를 생각할 수 있게 만들고, 프로그래머들과 협동할때 무리가 없도록 제어해 줍니다.

또한 프로젝트가 초중반이 되면 초기 데이터들을 돌려보면서 의도된 사양에 맞게 제작되었나 체크를 하면서, 그래픽 디자이너들에게 흔히 생길 수 있는 반복 노가다 작업이 없나를 체크하고 해결해 줍니다. (최근엔 부사수가 맥스 스크립트와 캐릭터 쪽을 모두 맡아서 해줘서제가 편하네요) 저는 그래픽 디자이너들과 프로그래머들의 중간에서 쉐이더를 제작하고 관리하며, 시스템 효율과 퀄리티를 동시에 생각하면서 챙기고 있습니다. 최근 데이터가 제대로 하고 있는데 공개할 수 없어서 아쉽네요. 그리고 라이팅쪽과 각종 이펙트, 렌더링의 옵션등을 계속 고려합니다.

프로젝트가 중후반에 달하게 되면 슬슬 게임이 모양이 나오고, 각종 문제가 터지기 시작합니다. 어느 컴퓨터에서는 돌아가지 않는다던가,어느 맵은 이상하게 느리다던가, 캐릭터가 무거운 알파 블렌딩을 줄줄이 달고 다닌다던가… 이때는 해결할 시간입니다. 바쁘게 뛰어 다니면서 해결하는 수 밖에 없습니다.

그리고 소위 말하는 ‘테스트실’ 에서 각종 그래픽 카드와 하드웨어와의 호환성 테스트도 저희가 맡아서 하고 있습니다. 후반에 가까워 올수록 해야 하는 일로, 최소 사양과 권장사양등을 정하고 각종 노트북을 비롯한 특이 하드웨어에서도 문제가 없나 테스트를 합니다. 물론 나중에는 QA 분들에게 넘겨야 하지만, 알파도 되지 못한 상태에서는 너무나도 눈에 보이는 문제들이 많기 때문에 어딜 어떻게 고쳐야 하고 해결방법이 뭔지 알고 있는 TA 들이, 그래픽이 고쳐야 하는가, 프로그래밍이 고쳐야 하는가, 아니면 사양을 올리거나 기획을 바꿔야 하는지를 판단해서 알려줍니다.

그렇게 문제를 해결하고 기준을 정하고 각종 그래픽 옵션을 정하면서 오픈 직전까지 QA 팀과 함께 게임이 무사히 나올 수 있도록 제어해 줍니다.

머릿속은 차가운 프로그래머처럼, 가슴은 따뜻한 그래픽 디자이너처럼 일해야하는게 TA 들의 일이라고 할 수 있습니다.
물론TA에 따라서, 회사에 따라서 전혀 다른 일을 할 수 있다는 것도 잊으면 안됩니다.

S 프로젝트 내부테스트 최저사양. 최저옵션

Fri, 29 Jul 2011 17:33:37 +0000

전체적인 느낌.

“큰 펀치는 없어졌지만 잔펀치가 많아졌다”

최저사양은 P4 2.8에 지포스 FX6200
6200이라고 해서 6000 대라고 생각하면 안됩니다. 5500과 거의 동급인 녀석입니다.
메모리는 1G.

결론은.
길게 가다가 한 번에 튀는건 없어졌지만 여전히 튀며, 잦아지고 짧아진 느낌입니다.

시작이야 그렇다 쳐도

사람 많은 곳에선 어김없이 튑니다. Animation.addclip 이 녀석이 범인.
해결해주소 박부장님. 드로잉 쪽이라면 제가 잡겠지만 로직은 제가 못잡으니까요.

로딩. 리드 오브젝트도 튀긴 하네요

캐릭터가 많은 곳에서는, 안정적으로 무겁게 , NmMainFrameWork 께서 나오십니다.

물론 이유없이 튀는곳도 많구요.

훈련소에 들어가니 특히 더 무겁습니다. 특히 튀는 증상이 많이 나오는 것은 TsBundleService.update 쪽 그리고

역시 Animation.addclip쪽이 잘게 자주 튀었습니다.

최저에서는 캐릭터 에니메이션 업데이트 등이 좀 잘 안되도 좋으니 꾸준한 이동 프레임이 나왔으면 좋겠어요.

유니티 3.4 업그레이드 내역

Thu, 28 Jul 2011 14:52:44 +0000

QA 의 시간이다!

Mon, 25 Jul 2011 16:55:30 +0000

QA는 회사에 전문가분들이 계셔서 사실 진정한 QA라고는 할 수 없고, QA분들이 일하실 수 있는 기본 바탕 조사차원겸
‘말도 안되게 눈에 뻔히 보이는 퍼포먼스 저하요인’ 을 색출해 내기 위해서 오늘도 달립니다.

보유한 그래픽 카드 리스트 . 중복카드와 너무 저사양 카드는 제거. 최소 쉐이더 2.0 이상 지원 그래픽 카드만 집계했습니다.
그 아래로 괴이한 전설의 그래픽 카드도 다수 보유중 (부두라던가… 밀레니엄이라던가…)
벤치마킹 수치는 http://www.videocardbenchmark.net/low_end_gpus.html 을 참조.

그래서 이걸로 벤치마킹 수치별로 재정렬하고, 너무 낮거나 너무 높은 그래픽 카드를 제외하고, 나름 표준이 될만한 그래픽 카드만 남겨놔서 남은 것이 이정도.

아참. 저기에서 8400gs도 제거 . 너 꽤 뜬금없어…
자, 이걸로 cpu 별 그래픽카드별 상중하 옵션 테스트를 시작해 볼까나…
바쁘다 바뻐

쳇. agp 때문에 저사양 그래픽 카드는 다 리스트에 넣어야 짝이 맞잖아

대사창의 클릭해서 넘어가는 속도에 대해

Sun, 24 Jul 2011 18:34:57 +0000

그러니까… 대사창이 클릭하면 클릭하는대로 팍팍팍팍팍 넘어가지 않습니까?
물론 시원스럽고 빠릿빠릿 하지만… 너무 휘리릭 넘어가니까 수준도 떨어져 보이고 의도치 않게 대사를 너무 빨리 넘겨 버리게 되는 경향이 있게 되지 않나요? 제작이야 물론 아주 쉽긴 합니다만…

그렇다고 일정 시간동안 입력을 막아 놓으면 마우스 입력이 안들어가는 것 같고, 넘김 버튼을 잠시 후에 나오게 만든다면 그거 누르는 스트레스가 또 장난 아닙니다.

그래서 이 경우는 다른 게임에서는 보통 이렇게 해결하곤 하죠.

아예 대사를 천천히 나오게 한다.

글씨가 타이핑 되듯이 나오는 방식입니다. 좀 더 응용하면 타이밍에 맞게 잠깐 시간을 들여 굼뜨게 말하는 연출도 가능하지요. 미연시에서 많이 쓰는 방식인데, 대사가 다 나오기 전까지는 입력이 먹지 않으므로 대사를 좀 더 잘 보게 하면서, 대사가 순서대로 나오니 자연적으로 시선이 따라가게 하는 방식입니다.

대사 자체가 캐릭터성을 지니게 되어 유저의 시선 움직임을 유발시킬 수 있지만, 제작이 어렵고 귀찮다는 단점을 지니고 있습니다.

아, 아니 이건 예시니까 그, 그런 눈으로 바라보지 말라고…

대사가 나오고 약간 시간 후에, 넘김이 가능하다는 아이콘이 나오게 한다.

대사는 그냥 우리가 나오는대로 나오지만, ‘다음’ 을 나타내는 버튼이 약 1-2 초 후에 오른쪽 아래에 나오게 한다는 거지요.
마우스 클릭을 유발하는 모양이어도 됩니다. 뭔가 회전하는 보석 모양이기도 합니다.

제작하기 쉬운 편입니다만, 유저의 입력에 빠릿빠릿하게 반응하지 않아서 약간 답답해 할지도 모릅니다. 이거 시간 길면 진짜 짜증나요.

게다가 만약 오른쪽 아래의 저 책 버튼을 정확히 눌러야 한다면 짜증 * 100

3, 페이드 - 인 / 아웃을 이용한다.

대사가 지금처럼 빠르게 반응하긴 합니다만, 대사와 대사 사이가 팍! 하고 바뀌는게 아니라 약 0.5초 정도의 페이드 아웃과 페이드 인을 사용하는 거지요. 그러면 페이드 인 / 아웃 으로 약 1초간의 딜레이가 생기죠. 좀 더 고급스럽기도 한데다가, 마우스를 팍팍팍팍 눌렀을때 대사를 읽기전에 팍팍팍 넘어가 버리는 것도 막을 수 있습니다. 반응도 바로 하는 거니까 답답함도 덜 느끼고 말이죠.

삼품테스트 7/21

Thu, 21 Jul 2011 12:41:43 +0000

사양 펜4 2.8 싱글 1G
FX5800 128M (최저사양 예상 머신)

최저사양에서 로딩이 약 20-30초. 빨라졌다는 느낌은 들지 않음.
커스터마이징에서 18프레임.
마을에서 모였을때 약 16-18 프레임. 30명 정도 있었음 . 나쁘지 않음.
서있다 이동하자, 마을안의 캐릭터들이 모두 사라진 다음 다시 그려짐. (한 번만 그런 증상 발생)
UI 왜이렇게 안눌립니까 답답해 미치겠는줄 알았음.
옵션을 바꿔도 ‘최고사양’ 외에는 사실상 프레임 차이가 없었습니다. 문제 분석 들어갑니다.

최저에서의 일반적인 환경입니다.
렌더가 27% 정도, 캐릭터가 많이 나왔으니 어쩔 수 없이 스키닝이 26% 정도, 에니메이션 업데이트도 당연히 17%, 메인 프레임 워크가 17% 정도… 일반적으로는 매우 괜찮은 환경이라고 할 수 있겠습니다. 비율적으로도 괜찮아요.

최저 사양에서의 최저옵션으로는 나쁘지 않다고 볼 수 있습니다. 프레임은 그냥그냥 그렇고, 비율은 괜찮아요.
물론 튀는 부분 (스파이크) 은 있지만 그 부분은 나중에 또 얘기하겠습니다.

그래서 이번엔 그 최저사양에서, 그래픽 옵션을 ‘중’ 으로 올려 보았습니다.

결과는? … 프레임이 거의 차이가 없군요! 반쯤 떨어지길 원했는데.. 이유가 뭘까요? 여기서 유추해 볼 수 있는 것은 다음과 같습니다.

이미 그래픽 카드 FX5800 128M 가 중급 사양 이상의 성능을 가지고 있다. (하긴, FX5800 정도면 그렇게 못난 놈은 아니거든요)
그래픽 옵션을 바꾸면 드로잉 부담이 줄어드는데, 캐릭터가 많은 상태라 어쩔 수 없이 스키닝이 높고 메인 프레임워크의 부담이 심해서 드로잉의 영향이 매우 미미할 수 밖에 없다.

대충 이정도로 예상할 수 있겠네요. 이전에 테스트에서 128M로는 비디오 메모리가 너무 작은게 아니냐는 테스트도 있었습니다만 , 이번 테스트에서는 그런 증상은 볼 수 없었습니다.

위 유추를 할 수 있는 이유중 하나는 여전히 비율이 그대로라는 것입니다. 카메라 렌더 비율이 26.5% .
다음에는 그래픽 카드를 좀 더 낮춰서 테스트 해봐야 할 듯 합니다.
뭐 여러가지 경우가 있기 때문에 이걸로 결과를 내리기는 좀 성급하죠.

자, 이번엔 스파이크 문제입니다.
훈련소로 들어가자, 드로잉 비율은 더욱 떨어지면서 메인 프레임 워크 비율이 높아지기 시작하더군요.
특히 스파이크 현상이 눈에 많이 띄었습니다.

지금부터 그 증상들을 체크해 보지요.

가비지 콜렉터입니다! 사실상 어쩔 수 없다고 들은 것 중 하나. 그다지 많이 나오지는 않는 문제니까 일단 넘어갈 수 있다고 치지만, 어쨌건 순간적으로 90% , 394 ms 를 먹어버린다는걸 잊으면 안됩니다.

오히려 가장 많이 볼 수 있던 증상 ‘이유없는 메인 프레임 워크 스파이크 증상’ 입니다.
보시면 알겠지만 NmMainFrameWork.Update 에서, 함수명을 알 수 없는 이유로 82.7% 129.34ms 를 먹는 증상이 발견되었습니다. 그리고 보시면 알겠지만, 메인 프레임워크가 최하급의 그래픽 카드에서 ‘중’ 급 옵션으로 돌렸는데도 불구하고 훈련소 안에서는 약 35% 이상을 먹고 있다는 것을 알 수 있습니다. 이번 테스트의 결과만 봐서는, 이 부분을 잡아야 전체적인 프레임이 증가하겠다고 생각되네요.

그리고 최근 일어난 일련의 문제로 주목을 받아온 브라우저 문제를 살짝 봤습니다.
사파리에서 돌려 보고 프로파일링을 해 보았는데요.

일단 들었던대로 사파리에서는 상당히 프레임이 잘 나오네요. 심한 경우에는 익스8에 비해 두 배까지도 나옵니다.
하지만 꽤 불안한 모습도 보였습니다. 종료시 에러 난다던가, 첨에 시작할때 창 크기가 이상하다던가, 프레임이 들쑥날쑥 하다던가…

재미있는건 위에 보시면 알겠지만, 최저사양의 ‘하’ 옵션인데도 드로잉 부하가 절반 가깝게 차지한다는 겁니다. 익스8이랑은 전혀 다른 양상을 보이네요.

물론 스파이크가 없는건 아닙니다. 보는김에 사파리의 스파이크를 분석해 보면…

Animation.AddClip 이 순간적으로 88.6% 13.12ms 를 차지하였고, 3번이나 중복해서 튄 것을 보실 수 있을 것입니다.

또 하나는 CombineMeshes ! 65% 52.23ms 를 잡아먹네요. 이 두개가 스파이크의 주범으로 보입니다. 익스8 보다는 좀 확실하게 보이네요.

남은 하나는 한 번 나온 겁니다만, TsBundleService.Update 에서 73.9% 가 나왔습니다. 36.97ms.
이건 뭔가 번들을 로딩할때인건가요?

오늘의 테스트는 여기까지입니다. 아직 스파이크 현상은 꽤 있고, 이 현상이 꽤 기분나쁘게 느껴집니다.
이 부분을 집중적으로 분석해서 고쳐야 할 것으로 보입니다.

각 맵별 부하테스트 초벌테스트

Thu, 21 Jul 2011 10:57:59 +0000

예정되어 있는 ‘퍼포먼스 테스트 기획’ 은 다음과 같습니다.

완성되어 있는 맵들을 전부 돌아다녀 본 후, 프로파일링 하여 가벼운 맵과 무거운 맵, 평균이 되는 맵을 정하고 이걸 배경팀과 캐릭터팀, 기획팀에 공유하여 최적화할것인가 어쩔것인가를 결정하는 순서입니다. 여기서 맵이라고 하는 것은, 몬스터가 깔려 있는 상태를 의미하므로 ‘진정한 의미의 현재 상태’ 를 의미합니다. 물론 초반 맵은 좀 더 가볍게 돌아가야 하고, 나중맵은 좀 더 무거워도 되지만 여기서는 순수하게 체크합니다.

이게 되고 나면 가장 무거운 맵을 기준으로 하여, 각종 사양의 CPU와 그래픽 카드에서 프로파일링 하여 최저사양과 권장사양을 정하게 됩니다.
이렇게 정해지고 난 최저사양과 권장사양에 맞춰 세부 옵션을 다시 손보게 됩니다.
추가적으로 발견되는 특이한 사항에 대해 최적화를 더 실시할 것인지 그냥 놔둘 것인지를 결정하게 됩니다.

대충 이런 과정이 기획되어 있고, 이게 은근히 시간과 노가다가 들어갑니다 (…)
중간에 방해금지. 바빠요 바빠.

사양은 일단 가상의 최저사양으로
펜 4 싱글 2.8 , 메모리 1G , 그래픽 카드 Geforce FX 5700 128M 를 지정하였습니다.
윈 XP에서 익스8을 사용하였습니다.

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

전체적으로 이동시에는 NmMainFrameWork.Update가 부하가 가장 높음. 정지시에는 좋은 프레임 나옴.

커스터마이징
10프레임 아래.

… 반드시 최저사양에서는 이펙트들의 최적화가 필요.

계성

프레임 15-30
드로우콜 높은곳 170

렌더링에 특이사항 없음. 중심부에선 15프레임. 외각에선 30프레임이 나옴.
유저가 거의 없는 상태. 프레임 격차가 심함. 맵의 가운데 (시장?) 은 15프레임. 구석으로 갈수록 프레임 상승.

계성 훈련소
꾸준한 15프레임.
드로우콜 높은곳 300

캐릭터들이 몰려서 전투훈련중인 곳에는 드로우콜과 스키닝 수치가 높음. 프레임은 꾸준.
유저들이 몰릴 곳이기 때문에 최적화가 필요할듯. 옵션에 따라 오브젝트를 Hide 시키는 기능도 적극 고려할 것.

북평성
25프레임 내외
드로우콜 높은곳 150

캐릭터들이 별로 없어서 안정된듯.

월드맵
10-14프레임
드로우콜은 200 정도.

Device.present 가 프레임을 방해하고 있음. 전체 속도의 65% 정도를 혼자 먹는 중.
터레인의 Low 옵션이 제대로 안들어가 있는 상태라 그럴 수도 있어 보임. 계속 이렇게 된다면 디스턴스 컬링으로 짤라 버리는 등의 조치가 필요함.

대흥산 입구
12- 15프레임
드로우콜은 200 정도.

유저가 몰릴 곳이기 때문에 최적화가 필요할듯.

황건적의 본거지
10-15 프레임
드로우콜은 300 정도

한 명 지나가기도 벅찬 좁은 지역, 너무나도 좁은 길. 갈 수 있을것 같지만 못가는 길들. 꽤 비효율적 구성.
몹이 몰린 부분은 10프레임까지 떨어짐. 최적화 작업이 필요해 보임

계교 전투
꾸준한 15프레임.
드로우콜 185

최저사양 옵션이 잘못 들어가 있긴 하지만 프레임은 꽤 꾸준하게 나오는 편.

구성의 요새
10-15 프레임
300 정도

캐릭터가 있는 부분은 무겁긴 하지만 그런대로 버티는 모양새.
길과 맵이 너무 좁은 느낌이 있음.

유표군 본진/유표군 전초기지
15프레임 정도
드로우콜은 250 정도
몬스터가 몰려있지 않아서 덜 무거움. 구성의 요새와 동일.

대흥산 전투 / 위기의 청주성
약 15프레임 내외. 특이사항 없음. 이정도의 캐릭터는 버티네..
전투시, 특히 그리드 나올 때 반투명이 게임 속도의 1/3 을 가져가고 있다는 것 확인.

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

결론

익스플로러 8 에서는 가벼울때와 무거울 때의 프레임 차가 크지 않다는게 특징. 거의 동일하게 15프레임이 나오는 추세입니다.
심지어 옵션을 중으로 올려도 그 프레임 차가 크지 않습니다. OTL
브라우저의 프레임 제한 문제일 수도 있고, NmMainframework 에서 차지하는 부하 때문일 수도 있습니다.
그렇다고 그래픽 카드를 한 단계 내리면 너무 급격하게 프레임 저하가 일어납니다.
일단 옵션 손보기를 해야 하겠습니다. 5단계로 옵션을 조절을 다시 하고, 테스트를 해야 할 듯.

삼품 퍼포먼스 테스트 - 익스플로러 버전별 프레임 차이

Wed, 20 Jul 2011 22:07:02 +0000

대규모의 삼품 퍼포먼스 테스트를 준비하다가 들어온 의뢰로 테스트 해본 노트북에서의 퍼포먼스 테스트입니다.

우선 노트북의 사양을 보시면.

윈도우 비스타.
익스플로러 7
휴렛 팩커드 코어2 듀오 P8600 (점수 : 1617) 2.4G : i7보다 두 배 느리고, 펜티엄 D 보다 2배 빠릅니다.
메모리 4G
그래픽 카드 Geforce 9200M GS

그래픽 카드는 원래 M 이 붙으면 성능이 개구린걸로 유명합니다.
그렇다고 해도 이정도로 느린줄은 몰랐네요… 거의 Geforce 6600 급의 성능이었다니..
http://www.videocardbenchmark.net/mid_range_gpus.html

어쨌건 맵은 구성의 요새. NPC들이 싸우고 있는 연출이 계속 플레이 되고 있어서 프레임 테스트 하기 좋은 곳입니다.
맵 자체도 좀 무거운 편이라는 평을 받고 있어서 기준잡기 좋은 맵이었구요. 아마 수정되겠죠.

일단 여기는 구성의 요새. 일반적인 필드에서도, 몬스터가 별로 나오지 않은 상태에서도 프레임이 과히 좋지는 못합니다.
이 정도 사양이면, 일단 중급옵션에서는 더 나와줄 것으로 예상할 수 있는데요. 거의 30프레임 가까이 나와야 할텐데.. 17프레임 내외를 왔다갔다 합니다.

드로우콜도 별로 높지 않은 상태입니다만. 어쨌건 프레임은 별로 나오지 않습니다.
현재 카메라 Render 가 50% 를 차지하고 있고, 그중 불투명 오브젝트가 22.7% . 반투명 오브젝트가 16.2% 를 차지하고 있습니다.
그다음에 메인 프레임 워크 업데이트가 22% 를 차지하고 있지요.
이 배경은 반투명이 거의 보일 일이 없는 맵인데도 반투명 수치가 꽤 있는 것이 의심스럽습니다. 반투명 수치는 그래픽 카드가 나쁠수록 처리 부하가 올라가지요.
혹시 수맥 현상 (땅 아래에 물이 흐른다던가 …) 인 건가요? 확인해 보니 물이 넓고 한 오브젝트로 되어 있어서 조금만 보이면 물 전체를 블렌딩하는 것 외엔 약점이 안보이는데…

캐릭터가 많은 지역으로 가 봤습니다. 약 20 ~ 30여 마리 정도 보이네요.

이 상황에서 약 15 프레임. 그래픽 카드가 좀 떨어진다고는 해도 심하게 낮은 수치.

그래프도 이쁜 편입니다. 편중되지 않고… 프레임워크 업데이트가 가끔 스파이크를 보이지만, 이것은 CPU가 나쁘지 않으면 크게 잘 안보입니다. 역시나 드로잉에 잘 편중되어 있는 모습을 보입니다. 그렇지만 프레임은 15…

여기까지의 특징은 익스플로러 7이라는 겁니다.
그래서 이번엔 익스플로러를 8으로 업그레이드 해 보았습니다.
(그동안 업그레이드를 안해놔서 엄청 오래 걸림)

언제 되는거야 이거 … 업데이트가 105개야…
그동안 장비정리나 하고 있어야지.

에엣~ 결국 되었습니다. 익스 8 !!!!

프레임 자체는 큰 변화가 없었습니다. 15프레임 정도. 그렇지만 그래픽 카드의 성능을 미루어 볼 때 무리가 아닐지도 모릅니다.
프로파일링도 크게 변화가 없었습니다.
좀 다른 점이라면 이번엔 반투명 오브젝트가 약 24% 정도 먹고 있었다는 것 정도?
뭐 좋습니다. 익스 7하고 8은 그다지 큰 차이가 없군요.

그래서 이왕 하던거 끝까지 해보기로 했습니다. 익스 9로 업데이트!!!!
듣자니 익스 9에서는 35% 정도 성능향상이 되었다고 하던가!!!

뭐야 이건 서비스팩 2 부터 설치해야 하잖아.

… 업데이트는 밤이 깊어져도 끝날 줄을 모르고…
… 아 지겹다 오늘 이거 하나는 끝장을 보고 퇴근하려 했는데 오늘 안에 할 수 있을까 이거..
… 다시 테스트 장비 정리.

이렇게 해서 결국. 서비스팩 2를 설치하고 익스플로러9 설치.

그리고 익스플로러 9에서 돌린 대망의 결과..

… 안빨라졌네요…

다른 데서 테스트 한 건 거의 두 배 이상 빨라졌었는데, 이 그래픽 카드의 한계 때문인지 여기서는 전혀 안빨라졌네요.

프로파일링 그래프도 마찬가지로 이쁩니다.

이건 뭐 설명할 꺼리도 없어. 드로잉 좀 낮춰야 합니다. 캐릭터 이펙트에 없어도 될 검기가 붙어 있는 작업 줄이고, 지형 좀 개선하면 빨라지리라 예상할 수 있습니다. .. 그래도 어쨌건 안되는 그래픽 카드는 안되는 거군요.

결론

익스플로러 버전에 따라 프레임이 차이가 있음이 확인되었습니다. 가급적이면 익스9를 사용할 수 있도록 권장하는 것이 좋겠습니다.
그렇지만 반드시 효과가 있는 것은 아니란 것도 알아야 합니다.
캐릭터에 반투명 (알파 블렌드) 수치가 높은 편입니다. 현재 이 작업은 들어가 있습니다.
이 맵이 좀 무겁습니다. 높낮이가 있어 심한 경우에는 드로우콜이 1000을 넘어가는 경우가 있고, 드로우콜이 괜찮더라도 폴리곤등이 과다사용된 부분이 없지 않습니다. 현재 배경팀에서 이 맵을 최적화 준비중입니다.

불법 캐릭터 도용의 현장

Tue, 19 Jul 2011 21:47:34 +0000

마나님이 가죽공예 배우시길래
“앵그리버드 열쇠고리 만들어줘!!” 라고 했더니 만들어주심.
오오 불법 도용 돋네.

[Shader] 삼품 이펙트 쉐이더 추가 및 수정

Tue, 19 Jul 2011 10:46:03 +0000

쉐이더 추가

Distortion 쉐이더

뒤의 이미지를 굴절시킵니다. 단지 노말맵만 들어가고, 디스토션 수치만 조절할 수 있습니다. 초 심플.
최저사양에서도 사용할 수 있게 해 놓았습니다. 이펙트니까요 :)
이펙트는 무슨 경우에서건 특별취급 해야 하는 겁니다.

원래 쉐이더 3.0 전용으로 되어 있던걸 2.0에서도 돌아가게 만들어 놓은 보람이 있군요.
아참, 버텍스 알파로 투명도 조절할 수 있습니다.

DistortionTexture_Add/ Multi / Standard
이것은 그냥 텍스쳐만 디스토션 시켜 버리는 쉐이더입니다. 가볍기로는 오히려 위 쉐이더 보다 가볍지요.

아래와 같은 이미지가

이렇게 변합니다. 노말맵의 X,Y 좌표가 이미지를 구깁니다.

멀티도 준비되어 있고
스텐다드도 준비되어 있습니다.
입맛에 맞게 사용하시면 되겠습니다.
최저사양에서도 동작하게 만들어져 있습니다.

쉐이더 수정

Flow 쉐이더가 최저사양에서도 동작하게 변경되었습니다. 이걸 왜 막아놨던거지 나 … ㅋ

[Shader]삼품 캐릭터 쉐이더 대폭 업데이트!!!

Mon, 18 Jul 2011 23:18:21 +0000

삼품 캐릭터 쉐이더가 대폭 업데이트 되었습니다.
원래 이펙트 쉐이더도 오늘 해주려 했었는데 이거 하다가 시간이 다 가서 그렇게는 못했슈… 성원아 내일은 꼭 해줄께…
중간에 스페큘러 노말라이즈 문제로 헤매는 바람에…

어쨌건 변화된 캐릭터 쉐이더 기능은 다음과 같습니다.

알파 채널로 투명도를 제어할 수 있습니다. 알파 테스팅만 작동합니다! 찢어진 옷 등을 만들 수 있습니다!
염색 마스킹 채널은 독립된 텍스쳐로 옮겨갔습니다. 쓰고 싶으시지 않으시면 그냥 텍스쳐를 안 넣으시면 됩니다.
스페큘러가 들어갔습니다! 쓰기 싫으시면 블랙으로 넣으시면 됩니다. 스페큘러 마스킹은 염색용 텍스쳐의 R 채널을 이용합니다.

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

알파 테스팅이 작동합니다. 2-side는 적용하지 않았습니다.

스페큘러가 사용가능합니다!!! 색깔과 넓이, 강도를 조절할 수 있습니다.

추가된 텍스쳐의 A 채널은 Dye(염색) 이며, R 채널은 스페큘러 마스킹인 Gloss 채널로 사용됩니다.
Specular Color로 스페큘러의 색상을 조절할 수 있습니다. 기본은 블랙입니다.
Specular Power 는 스페큘러의 넓이를 제어합니다. 숫자가 작으면 넓어집니다.
Shiness는 스페큘러의 강도를 결정합니다. 숫자가 높으면 강해집니다.
Alpha cutoff는 알파 테스팅이 될 영역의 제한값 (트레쉬홀드) 를 결정합니다. 보통은 쓸 일이 없겠지요.

커밋되었습니다. 게임 업데이트는 조금 늦게 해야겠지요?

삼품 맵별 퍼포먼스 테스트

Mon, 18 Jul 2011 12:14:54 +0000

이번에는 맵별 퍼포먼스 테스트입니다. 게임이 어느 정도 만들어지고 내부 사람들에 의한 테스트가 이루어지고 있으므로, 게임이 실제로 돌아갔을 때의 느낌을 감안하여 테스트 해 보기 좋겠지요.

테스트 방법은 다음과 같습니다.

평균이 되는 맵 찾기

프레임은 그래픽 카드와 CPU와 렘의 절묘한 하모니에 의해 결정됩니다. 어느 것 하나라도 소홀히 할 수 없지요. 때문에 어느 것 하나 때문이라고 찾기 힘들며 , 사양 표준을 정하기도 쉽지 않습니다,

때문에 일단 최저사양으로 정해져 있는 펜4 싱글 2.4 (노스우드) : 315점 을 ‘예상최저사양’ 으로 놓고 , 거기에 어울리는 그래픽 카드로 ‘지포스 FX 6200 128MB’ 으로 잡았습니다. 이 그래픽 카드는 쉐이더 2.0 지원의 마지막 그래픽 카드로, 이 다음 옵션은 바로 6600 , 쉐이더 3.0으로 올라가게 되지요. 보통 펜4 2.8이나 2.4였을때 사람들이 많이 선택하던 그래픽 카드입니다.

이렇게 가상의 최저사양을 놓고, 각 맵별 퍼포먼스 테스트를 Fraps를 이용해서 합니다. 원격 프로파일링을 하지 않고 Fraps를 이용하는 이유는 원격 프로파일링의 부하를 피하기 위해서입니다. 그리고 이미 이전 프로파일링 테스트로 스파이크 현상의 원인을 찾았으니, 그걸 무시하고 테스트하면 되는 것이니까요.

평균이 되는 맵에서 최저사양을 유추하기

평균이 되는 맵 자체가 너무 무겁다면 최저사양을 올려야 할 것입니다. 최적화도 중요하지만 무조건 최적화에만 기대어서는 안되지요. 이미 최저사양 하드웨어가 한일 월드컵 할때의 수준이니, 좀 올려야 할지도 모르는 일입니다.

그리고 최저사양이 되는 맵에서 나중에 유저가 몰렸을때를 유추해서 평가해 봐야 할 것입니다. 그렇게 해서 최저사양을 다시 정합니다.

최적화를 해야 할 맵을 정리하기

그다음은 맵별로 최적화를 해야 할 곳을 정리합니다. 기준되는 맵을 바탕으로 하여, 더 무거운 맵은 더 줄일 수 있도록 하고, 너무 가벼운 맵은 좀 더 디테일을 추가할 수 있겠지요.

권장사양 체크하기

위 작업이 끝나면 권장사양 테스트로 넘어갑니다. 아아 하염없이 떠돌아다녀야 하는 인생 …

로고 로딩은 10초 내외
로딩화면 후 커스터마이징까지 약 1분 정도 . 살짝 지겹네영
캐릭터 선택 후 게임 진입 10초 내외.
유저 캐릭 4과 NPC2마리. 약 15프레임. 안정적.
역시 끊어지는 모습은 그대로. 프로파일링 결과 튀는건 모두 NmMainFramework.Update
계성
15프레임 이상 꾸준히 나옴. 유저와 NPC들이 6-7명 보임.

월드맵
10프레임 ..? 옵션이 적용이 안되어서 그렇게 된 것일지도. 만약 개선을 해도 계속 이렇다면 사양을 올려야 한다.

대흥산 입구
많은 몬스터 캐릭터가 보임. 약 10프레임 ~8 프레임으로 꾸준히 나옴.
Device.present와 NmMainframeWork.Update와 Camera.render 가 높게 영역을 1/3씩 나눠 차지하고 있는 느낌.
대흥산을 개량하지 않는다면 역시 최저사양으로는 어려울지도 모름. (사실 돌아가는건 할 수 있지만 나중에 몰리면 급격히 느려질 위험이 있음)

장비실에서 프로파일링중

Mon, 18 Jul 2011 10:56:49 +0000

이따위 장비까지 동원해 봤습니다.

두둥.

아 물론 이게 최저사양은 아님. 여기서 돌아가는걸 보여주느라고 테스트 하는거지.

가지고 있는 하드웨어 중에서 중복 빼고, 아직 조립하지 않은 것들 (약 10대 넘게 구석에 박혀 있 …) 빼면 대충 이정도가 나오네요

============================================================================
AMD 페넘2 4 945 (데네브) : 3,613점
AMD 에슬론642 4000+ (브리즈번) : 1,098점
AMD 에슬론64*2 3600+ (브리즈번) : 1,000점
PentiumD 945 (프레슬러) 3.4G : 928점 —————————————- 약 2005년 출시 제품
PentiumD 930 (프레슬러) 3.0G : 812점
Pentium4 540 (프레스캇) 3.2G : 524점
Pentium4 (노스우드) 3.2G : 415점
Pentium4 (노스우드) 2.4G : 315점 ——————————————– 약 2002 년 출시 제품
Celeron (윌러메트) 1.7 G : 측정불가 : 300점 정도로 추정됨. (아톰이 304 정도니)

여기에 귀찮아서 테스트 안한 저사양 + 3대 정도, 안돌아가서 일단 빼놓은거 2대 정도… 테스트 머신이 몇대인거냐 …

그래놓고 요따위꺼 테스트 하고 있지요

2011 차세대 게임 개발 경진대회

Sat, 16 Jul 2011 15:34:27 +0000

2011 차세대 게임 개발 경진대회

안드로이드

아띠 (그린나래)
포메이션 시스템의 구현이 핵심일듯 합니다. 그렇지만 포메이션이 조작버튼으로 간단하게 조작되는지, 수동으로 조작해야 하는지에 대한 것이 명확하게 이해되지 않습니다. 자동으로 된다면 협동이라는 기능이 부족할 것이고, 수동이라면 너무 어렵겠네요. 이 부분을 구현하는 것이 원하는 게임을 만들기 위해 가장 중요한 부분일 것 같습니다.

스타콘넥트 (팀 베텔기우스)
별을 소재로 한 매우 교육적인 게임으로 보입니다. 단지 게임성에 대해서는 조금 의문입니다. 어떤 점에서 재미와 연관시킬 것이냐에 대한 고민을 좀 더 해보면 좋을 것 같아 보이네요.

스파이스 팜 (석민규)
안정적인 기획이 눈에 띄는군요. 굉장히 독특한 발상은 아니지만, 재미있는 게임이 될 것 같습니다. 단지 혼자서 제작하기에 너무 큰 기획인 것이 우려스럽습니다. 반드시 한 부분부터 제작하세요. 모든 기획을 다 구현하려 하지 않는 것이 좋겠습니다.

꼬마 유령 판토마 (RegendBee)
복잡해 보이지만 구체적인 내용이 부족하다는 것이 아쉽습니다. 기획서만으로는, 화면에 다른 장애가 없이 NPC만 피해 아이템을 가지고 오면 되는 게임으로 보입니다만 , 추상적 미사여구들이 남발하여 게임을 이해하기 힘들게 하고 있습니다. 좀 더 구체적인 기획이 보고 싶네요. 기획은 광고전단이 아니니까요.

Real-Bang (이동근)
제작하기 힘들 것 같지만 굉장히 재미있을 것 같은 게임입니다. 이미 외국에서 만든 비슷한 게임이 있기는 하지만, 구현이 쉽지 않기 때문에 핵심 부분이 제대로 제작되기만 해도 좋을 것 같습니다. 단, 여러 가지 난관이 많을 것으로 예상되므로 핵심 부분 개발에만 주력하세요. 예를 들어, GPS의 오차가 클 때의 문제라던가…

쉘터 : 애프터매스 (전영민)
전자력을 이용한 기획이 매력적입니다. 배경컨셉도 독특한 편이고 그래픽도 무난할 것으로 예상됩니다. 게임성만 확실하게 살려준다면 좋은 완성품이 될 것으로 보입니다.

사랑과 전쟁 (전하영 & 정주현)
제작에 난이도가 적을 것으로 보여 제작이 용이할 것으로 보이나 핵심적인 게임성을 조금 더 강화해야 할 것으로 보입니다. 단순한 터치 조작은 금방 지루해질 가능성이 보입니다. 좀 더 핵심 재미에 대해 생각해 보는 것이 좋겠습니다.

방울방울 : 터뜨려라 빠샤 (정의호)
단순하고 핵심적인 게임요소가 돋보이며, 제작에도 난이도가 적을 것으로 보입니다. 그렇지만 혼자 제작하기에는 무리가 있을 듯 해 보이고, 그래픽을 전문적으로 담당할 사람이 필요할 것으로 보입니다.

내가 그린 그림이 움직인다! (Team L2)
그린 이미지를 물리로 연산하여 그것을 디펜스로 다시 이어지게 한다는 기획이 참신해 보입니다. 단지 그래픽 담당자를 제대로 보유해야 할 듯 하고, 보다 확실한 게임에 대한 규칙을 설정해 두는 것이 좋을 것 같습니다. 기획서만으로는 어떻게 게임이 진행될지 상상하기 쉽지 않습니다.

BADA

커피퀸 (김인애 강정화)
커피에 대한 전문적 지식을 게임으로 잘 만들어 내는 것 같은 느낌이 들어서, 재미 외에도 교육적인 역할을 할 수 있을 것으로 보입니다. 단지 조금 아쉬운 것은 기존 타이쿤 류와 차별되는 면이 별로 없다는 것인데, 작지만 독특한 차별성을 찾아서 만들면 좋은 결과가 나올 수 있을것 같습니다.

빌딩 슬레쉬 (빌딩 슬레셔)
스마트폰이라는 기기에 잘 어울리는 컨셉의 기획이며, 검증된 재미요소가 보인다고 할 수 있습니다. 발전성도 높아서 여러 장점이 있을 것 같습니다. 단지 실력좋은 그래픽 팀원을 확보하시기 바랍니다. 지금보다 그래픽 효과만 더 좋아진다면 게임이 훨씬 돋보일 것입니다.

더 라스트 사무라이(차현성)
후르츠 닌자와 같은 메카닉을 가진 게임으로, 스킨을 사무라이 스킨으로 재현하였네요. 만들기도 쉽고 재미도 보장된 게임이지만 조금 더 특색을 추가하면 어떨까 싶습니다. 단 , 너무 무리하거나 거창한 특색 말고 간단하면서도 다른 경험을 줄 수 있을 정도의 특색이어야 겠지요

게임오븐

마왕 vs 용사 (박재현, 고주곤, 임성환)
카드를 이용한 게임으로, 단순한 조작과 제작으로 심오한 게임성을 이끌어내기 좋은 게임입니다. 단 , 처음에 규칙을 모르는 사람들은 쉽게 접근하기 쉽지 않을 수 있기 때문에 이 점을 잊지말고 개선할 수 있도록 염두해 두어야 합니다.

Islet Break ( 벨루시아)
Islet 을 아일렛이라고 읽을 사람은 별로 없어 보입니다. ‘이슬렛’ 이라고 읽지… 오히려 오타로 보일 뿐이지 신비감을 느낄 사람은 없을겁니다. 방 탈출 퍼즐게임으로 제작이 용이하고 재미요소도 보장될 것으로 보입니다만, 장르의 특성상 그래픽의 중요성이 크기 때문에 그래픽에 투자를 높여야 할 것 같습니다.

기숙사 탈출하기 (뭘로하지?)
전통적인 어드벤쳐 게임으로, 제작시 어려움이 적을 것으로 예상되며, 이미 상당부분 진행된 것으로 보입니다. 그렇지만 보다 게임성을 올리기 위해 그래픽에 더 투자해야 할 것으로 보입니다. 더 좋은 그래픽으로 제작되면 좋은 결과가 있을 것으로 보입니다.

꿈의 색 (홍성희)
최근 인디게임등에서 많이 제작되고 있는 색을 이용한 퍼즐 액션 게임으로 보입니다. 그래픽도 무난하고 기획도 잘 되어 있습니다. 아마도 거의 제작된 것이 아닐까요. 이대로 잘 만들면 좋은 작품이 나올 수 있을 것으로 보입니다.

IPhone

격돌! 스트라윈드 (강민석)
아이폰에서 실행되는 액션게임이네요. 특이한 내용이 그다지 보이지 않는다는 것이 다소 아쉽지만, 기본기를 탄탄하게 만드는 것만으로도 매우 어려운게 액션게임이기 때문에 너무 욕심부리지 않고 게임을 만들기 바랍니다.

연금술사 (고현구)
원소를 합친다는 내용으로 교육적인 요소가 돋보이는 게임입니다. 단지 화려함이 덜하고 초보자들에게 다소 어렵게 느껴질 수도 있는 게임이기 때문에, 탄탄한 시나리오 모드나 튜터리얼로 초반 접근성을 쉽게 만드는 것이 중요하다고 생각합니다.

버뮤다 (나비효과)
스마트폰의 중력센서를 적절하게 이용한 훌륭한 기획입니다. 기획대로 구현만 된다면 아주 재미있는 게임이 될 것으로 보입니다. 단지 그래픽을 개선하고 다소 어려울 수도 있는 조작성을 잘 고려하면 좋을 것 같습니다.

Prediction (게임과학고등학교)
독특한 예측형 카드 게임입니다. 제작시 난이도도 적을 것으로 보이며, 멀티플레이가 지원될 수 있다면 더욱 재미있는 게임이 될 수 있을것 같습니다. 게임의 특성상 그래픽에 신경을 좀 더 많이 쓰면 훌륭한 게임이 될 수 있을것 같습니다.

프레딕 (eyewall)
“prairie” 입니다. 독창적인 형태의 디펜스류로 보입니다만 기획서만으로 정확히 어떤 모습의 게임이 될지 짐작하기 힘듭니다. 보다 게임 진행에 대한 구체적인 기획이 추가되어야 할 것으로 보이며, 현재 상태로 제작시 원래 기획에서 생각하지 못한 여러 문제들이 나타나게 되지 않을까 생각합니다.

디지디지 (아토즈)
특이하지 않을수도 있는 게임을, 동일한 여러 캐릭을 조작해야 한다는 개념으로 멋지게 새로운 경험을 줄 수 있도록 바뀌었습니다.
그래픽도 안정된 편이고, 이대로만 제작된다면 훌륭한 게임이 나올 것 같습니다.

축복과 저주(카쿠렘보)
독특하고 위험한 컨셉의 게임입니다. 하지만 그만큼 매력적이기도 합니다. 스마트폰의 개념을 잘 살린 특이한 게임이 될 뿐만 아니라 SNG로도의 발전이 기대되는 게임입니다. 미니게임보다는 게임의 주 목적을 강조하는 것이 좋겠습니다.

마리모 (폭풍의 눈)
스마트폰의 특성을 잘 이용한 게임으로 보입니다. 간단한 아이디어에 몇 가지 신선한 조작을 넣어 새로운 경험을 줄 수 있는 게임으로 만들어 질 것 같습니다. 그래픽 제작이 잘 되면 훨씬 효과가 좋을 것 같습니다.

닥터 젤피 (클로버)
복잡하지 않은 메카닉에 소아암이라고 하는 스킨으로 교육적 효과도 노릴 수 있는 게임이 되었습니다. 메카닉 자체는 굉장히 단순한 편이기 때문에, 게임까지 단순해지지 않도록 게임성을 계속 확인해 보는 과정이 필요할 것으로 보입니다.

zio ball (애니고)
자력이라고 하는 재미있는 소재로 재미있는 게임이 될 수 있을 것 같은 구상을 하였습니다. 이대로만 잘 제작된다면 훌륭한 결과물이 나올 것 같습니다.

Windows Phone 7

빙 (김범준 외 4명)
빙글빙글 돌린다는 디펜스형 게임은 무척 신선하고 독특합니다. 이대로만 잘 제작된다면 매우 좋은 게임으로 만들어질 수 있을 것 같습니다.

칼라 리듬 (아잉)
이미지를 기반으로 하여 음악을 만든다는 알고리즘이 무척 흥미롭습니다. 단지, 사용자가 이미지와 음악을 연관시켜 생각할 수 있다면 라이브러리만 많아진 음악과의 차이가 별로 느껴지지 않을지도 모른다는 것이 조금 걱정스럽군요. 어떻게 유저에게 이런 특징을 느끼게 할것인가가 궁금합니다.

길잃은 탐사원 (박민영 외 4명)
게임 의도는 좋아 보이나 게임의 정확한 느낌이나 플레이 방식을 알 수가 없습니다. 보다 확고하게 잘 그려진 스크린샷을 몇 장 가짜로 만들어 보세요. 만들고자 하는 게임의 모습이 확실해질 겁니다.

리틀 라이프 (신재하)
독특한 소재입니다. 게다가 매우 교육적이기까지 합니다. 아기를 처음 가지는 신참 엄마들은 보통 필요한 지식을 미리 얻지 못하여 혼란스러워 하는 경우가 많은데 그런 경우에 도움이 될 게임으로 보입니다. 그렇지만 게임이라기 보다는 시뮬레이터성이 많아서, 유저의 꾸준한 접근성을 유발시키기 위해서 무엇을 할 수 있을지를 고민해야 할 것 같습니다.

대포로 막아줘 (신지섭)
대포를 이용하여 몰려오는 적을 없애는 디펜스에, 벽돌깨기 등의 아이디어를 조합한 것이 돋보입니다. 기획 자체는 훌륭하기 때문에 그래픽을 비롯한 나머지 요소를 수준높게 제작할 수 있다면 좋은 결과가 나올 것 같습니다.

열혈!! 외줄 탄 사나이 (원종민 외 4명)
독특한 소재로 재미있는 게임을 만들 수 있을 것 같습니다. 단, 꽤 많은 기획이 한 게임에 들어가 있는 형태이므로 단순한 기능부터 완성해 나가는 방식으로 제작하면 좋을 것 같습니다.

선장의 여행 (권익수 외 4명)
단순하고 재미있는 게임 기획이지만, 너무 많은 부분을 기획하고 있는 것 같습니다. 일단은 핵심적인 게임성에 주력하여 제작하고, 추후 여러 가지 부가적인 옵션들을 추가하는 것이 좋을 것 같습니다.

렉션 (현승철)
캐릭터도 매력적이고 게임성도 충분할 것으로 보입니다. 현재의 기획을 안정적으로 제작하기만 한다면 좋은 결과가 나올 것으로 생각됩니다.

XNA

더 바벨 (김승환)
게임의 재미 뿐만 아니라 영어교육에도 도움이 될 것으로 보이는 좋은 기획입니다. 이 기획대로 제작되기만 한다면 좋은 결과가 나올 수 있을 것 같습니다.

블루윙 (송시현)
두 개의 게임을 제작하여 동시에 만드는 느낌입니다. 참신하고 좋은 시도로 보이지만, 두 게임의 게임성을 모두 신경써야 하기 때문에 무척 주의하면서 제작하여야 할 것입니다. 선택지에 따라 게임의 느낌이 바뀌는 시도를 좀 더 극적으로 표현하는 방법을 고민해 보면 좋을 것 같습니다.

Vibot (최경환)
단순하고 핵심적인 내용을 가지고 있어서 제작에 큰 어려움을 가지지는 않을 것으로 보입니다. 단지 단순하면서도 재미요소를 갖춘 게임을 만드는 것이 쉽지 않은 관계로, 독특하고 아름다운 비주얼을 비롯하여 재미있는 게임성에 대해 깊이 고려해 보시기 바랍니다.

현재 삼품 퍼포먼스의 문제는 무엇인가?

Fri, 15 Jul 2011 10:53:22 +0000

이번 테스트의 목적은
‘현재 게임이 돌아가고 있는 삼품의 퍼포먼스의 한계는 어디까지인가’ 와
‘그렇다면 현재 일반적으로 가장 병목현상이 되고 있는 부분은 어디인가’
였습니다.

이게 끝나서 ‘표준사양은 이 정도’ 라는 기준이 다시 확실히 정해지면, 이번엔 각 맵을 돌아다니면서
‘어떤 맵이 현재 가볍고 어떤 맵이 무거운가’ 라는 테스트를 해야 겠습니다.

이제 게임이 본격적으로 돌아가고 있으니, QA 팀에 본격적인 대규모 테스트를 넘기기 전에 기준안을 마련하고 기초적인 문제를 잡아야 하기 때문이지요.
나중에 QA 팀까지 합세하면 연출 무거운 것도 확인해 보고 싶고… 대규모 전투때 한계도 테스트 해 보고 싶고.. 하네요…

그래서 일단 첫 번째로, 보유하고 있는 각종 테스트장비들의 CPU 조사부터 시작하였습니다.
사실 보유하고 있는 머신은 이것보다 더 많지만, 아직 조립을 하지 않아서 가동할 수 있는 녀석들만 체크해 보았습니다. (어차피 그녀석들은 이것보다 사양이 더 높고)

보유하고 있는 녀석은 대충 이정도.
뒤의 점수는 벤치마크 점수로, CPU의 성능을 짐작할 수 있습니다.
참고로 AMD가 높은건, 저사양만으로 구성된 테스트 PC들을 구축할때 AMD 애들은 저사양을 구하기가 쉽지 않아서 이렇게…

============================================================================
AMD 페넘2 4 945 (데네브) : 3,613점
AMD 에슬론642 4000+ (브리즈번) : 1,098점
AMD 에슬론64*2 3600+ (브리즈번) : 1,000점
PentiumD 945 (프레슬러) 3.4G : 928점 —————————————- 약 2005년 출시 제품
PentiumD 930 (프레슬러) 3.0G : 812점
Pentium4 540 (프레스캇) 3.2G : 524점
Pentium4 (노스우드) 3.2G : 415점
Pentium4 (노스우드) 2.4G : 315점 ——————————————– 약 2002 년 출시 제품
Celeron (윌러메트) 1.7 G : 측정불가 : 300점 정도로 추정됨. (아톰이 304 정도니)

테스트 방법은, 그래픽 부하를 최대한 주지 않은 상태에서 순수한 CPU 부하를 테스트하기 위한 방법을 택했습니다.
그 방법은

그래픽 옵션을 최저로
그래픽 카드는 7600 이상 (AGP 최고로 보유하고 있는게 이거라서…)

대충 이정도 하면 그래픽 카드 부하는 거의 없을 것이고… 이상태라면 인터넷 익스플로어에서 꾸준히 제한프레임인 30프레임 이상 나오면 합격입니다.

일단 만만해 보이는 [AMD 에슬론64*2 3600+ (브리즈번) : 1,000점] 을 테스트 : 최저사양은 커녕 중간사양에서도 날라다닙니다. 단 프레임이 좋게 나오지만 간혹 튈때가 있습니다.
그다음에 테스트 한 것은 [Pentium4 540 (프레스캇) 3.2G : 524점] : 중간사양은 그럭저럭 나오지만 최저사양에선 꾸준히 30프레임 이상 나옵니다. .. 그렇지만 역시 튑니다… 어딘지는 확인했습니다만 어쨌건 사실 기본적으로 CPU가 받쳐주지 못하는 것은 아닌 것으로 보입니다만.

… 뭐 사실 캐릭터 한두마리 (NPC가 좀 있지만) 나오는 상태에선 사실 이정도는 쉽게 받쳐주는 가벼운 게임입니다. 삼품이란 게임은 말이죠.

그래서 미친 척 하고 벤치마크 테스트에도 나오지 않는 구시대의 유물인 셀러론 1.7을 꺼내어 돌려봤습니다.
물론 그래픽 부하는 거의 없애기 위해서 그래픽 카드는 7600을 물렸습죠.
참고로, 최저사양으로도 생각하지 않았던 CPU입니다.

두둥

결과는 어땠을까요? 외부섭 기준, 1G 메모리를 가진 셀러론 1.7 CPU에서는, 초반에 게임 진입할 때에는 굉장히 버벅댔습니다.
‘아 이거 안돌아가겠구나’ 라는 느낌으로.
하지만 네이버 띄우는 것만해도 5초 이상 걸리는 컴퓨터라는 점도 이해해야 함…
초반에 보안 인증서 경고가 뜹니다만… 민감한 유저들은 이거 가지고 뭐라 할지도 모르겠어요.

삼품 로고가 뜨고 기본 로딩은 약 10초 정도
로딩 화면이 뜨고 노란줄이 끝나고 커스터마이징 화면이 나올때까지 약 2분 (!!!!)
커스터마이징 화면에서는 최저옵션에서도 18-20 프레임 . 이펙트 오브젝트들이 많아서 그렇습니다.
캐릭터 만들고 게임으로 들어가는 로딩화면 약 10 몇 초.
게임 들어가서 컨트롤이 정상화가 될 때까지 약 10여초. 그전까진 느림.
게임에서는 20프레임 후반에서, 잘하면 30프레임까지 나옴

간혹 TsBundleService.Update() 에서 튑니다. 큰 음악을 로딩할때 생기는 부하일까요?
자주 보지는 못했습니다만, 가끔 봤습니다.

흔하게 보이는 ‘튀는 부분’ 은, NmMainFrameWork.Update() 였습니다. 자세히 보니 워낙 많은 부분이 연결되어 있어서 딱 이거때문이다라고 말하기 힘든 부분이네요.

그 후에도 계속 NmMainFrameWork.Update 가 튀는 것을 볼 수 있습니다.
캐릭터나 오브젝트가 로딩될 때마다 튀는 것 같은 느낌으로 튀네요. 이 부분은 최저사양이 아니더라도 나타나고 있고, 이 부분을 잡으면 안정된 프레임이 나올 것으로 예상됩니다.

이 테스트가 끝나서 최저기준 PC가 정해지면, 이번엔 각 맵을 돌아다니면서 퍼포먼스에 적합한지 테스트할 예정입니다.

이 테스트에서 알 수 있는 것들

일단 가동만 되면 CPU 가 낮아도 잘 돌아감. 단 저사양에서는 가동될때까지 시간이 좀 걸림
로직쪽에서 중간중간 튀기 때문에 게임이 툭툭 끊어지는 것으로 느껴짐
CPU 에 중간중간 부하를 주는 것은 로직쪽. NmMainFrameWork.Update 에서임.
이 부분만 해결하면, 최저사양에서 끊어지지 않고 부드럽게 게임 즐기기 쉬울듯.
하지만 아무것도 띄워놓지 않고 순수하게 게임만 돌린 상태라서, 여유를 가지고 게임 플레이하려면 사양이 좀 더 높아야 할 듯.

이 테스트에서 알 수 없는 것들

계성맵이 예전처럼 무거운 맵이 아니라서 기준맵이 될 수 없음. 기준맵을 다시 찾는 과정이 필요함
캐릭터가 여러 마리 나왔을때 다시 테스트가 필요함. 주인공이 40명 모였을때도 과연 그렇게 플레이할 수 있을까?

박실장님 DELL inspiron one 프로파일링 보고

Wed, 13 Jul 2011 18:06:08 +0000

아아 유니티 정말 좋네요. 빌드되어 돌아가는 게임도 에디터에서 프로파일링 할 수 있다니!
겜브리오때에는 꿈도 못꿨던 짓이지요. 용우님이 가르쳐 주셨습니다.

일단 DELL inspiron one 은 가정용 올인원 컴퓨터로, 크기를 줄이기 위해서 대부분의 부품을 노트북용을 사용한, 게임용이라기 보다 가정의 일반적인 사용을 위해 제작된 컴퓨터입니다.

기본적인 사양은 다음과 같습니다.

ATI Mobility Radeon HD 5470 1G DDR3: 벤치마킹에서는 일단 지포스 9000대보다도 떨어지는 정도로 나오더군요. 지포스로 따지면 8000~9000 대 사이라고 생각하면 될듯

인텔 i3-370
노트북용이지만 Core2 DUO 의 최상급에 가까운 성능을 자랑하는 , 꽤 좋은 CPU입니다.

메모리 4G

사실 이정도면 최상위 옵션이 돌아가야 합니다만… 결과부터 말씀드리자면 ‘최상위는 힘들더라’ 입니다.
다른건 괜찮았는데 그래픽 카드가 생각외로 스펙에 비해 성능을 발휘해 주지 못했습니다.

아무래도 그래픽 카드의 성능을 테스트해서 옵션을 정해주는 기능을 추가하던지 해야지, 비디오 메모리 숫자만으로는 한계가 너무 크네요.
테스트

테스트가 오래 걸릴 일은 없는데 그동안 테스트 장비와 시스템이 구축이 덜되어서 그거 구축하느라 시간이 좀 걸렸습니다.
테스트 방법에 대해서는 용우님의 도움으로 멋진 방법을 발견…

우선, 일단 몇 가지의 상황에서 프레임이 ‘튀는’ 증상이 발견되었으며, 이것이 게임을 하다가 끊어지는 느낌을 유발하는 것을 알 수 있었습니다. 장소는 계성으로 하였고, 최고 옵션으로 하였을 때 약 600이 좀 넘는 드로우콜이 나옵니다.

그리고 그 몇 가지의 상황은 다음과 같습니다.

메인 프레임워크 업데이트.
그야말로 업데이트에서의 튐 현상입니다. 이것은 기하 단계나 레스터라이징 단계가 아닌 로직 단계로써,
아마도 캐릭터 등이 등장할 때 CPU가 튀는 증상이 아닐까 합니다.

Mesh Create VBO Usage 부분의 점프현상
Mesh Create VBO 는 OPENGL 에서 메쉬를 처리하는 어쩌고… 단계인데, 쉽게 그냥 드로우콜이라고 생각해도 됩니다.
즉 현재 이 컴퓨터의 그래픽카드가 데이터를 다 처리하지 못해서 순간적으로 CPU에 발생한 병목현상입니다.
이 말은 그래픽 카드가 최상위 옵션을 커버하기에 무리가 있거나, I/O 를 담당하는 BUS가 문제가 있다는 건데…. 단정할수는 없습니다만 노트북용 부품을 사용하는 모델로써 둘 다 가능성이 있습니다. 어쨌건 그래픽 부하를 처리하지 못한다는 것을 알 수 있었습죠.
Shadow Rendering 부분의 점프현상
Shadow도 마찬가지로 갑자기 급 부하를 주곤 했습니다. 역시 마찬가지로 그래픽 카드 처리 부하로 인한 CPU병목현상…

4.Device.Present
또 하나 눈에 띄이는 부분은 대규모로 시스템 자원을 잡아먹는 부분은 Device.present로, 이 부분은 문의해본 결과 ‘게임에서 30프레임으로 제한해 주는 부분같다’ 라는 답변을 들었습니다. 이 부분도 튀는데 일조를 하는 것으로 보이나, 막상 그래프가 저 모양일 때에는 그다지 프레임 튐 현상이 안나타났다는걸로 보아 정말로 좋은 녀석일지도..

결론

결론적으로 다른 부품들은 우리 게임의 상 옵션을 커버할 수 있는 능력을 충분히 가지고 있지만, 그래픽 카드 ATI Mobility Radeon HD 5470 1G DDR3 은 그 멋진 이름에도 불구하고 우리 게임의 상위 옵션을 소화할만한 능력을 가지고 있지 않으며, ‘중상’ 정도의 옵션이라면 처리할 수 있을 것으로 보입니다. 혹은 해상도를 높이면 ‘중’ 정도겠지요. 캐릭터가 많아질 것도 계산하면 ‘중’ 정도가 맞을 것 같기도 하군요.

아래는 테스트로 ‘중’ 옵션으로 해보았을때입니다.
드로우콜이 200대로, 600대였었던 상 옵션의 1/3 입니다.
녹색의 드로잉 부분이 안정적으로 돌아가고 있는것을 알 수 있습니다.
(맨 끝에 점프한 부분은 게임화면에서 엔진으로 화면전환할때 생긴 겁니다 :) )

추가

계성을 중심으로 테스트 했기 때문에, 아직 다른 맵에서의 상황은 확실하지 않습니다.
- 메인프레임 업데이트시 튀는 부분은 손팀장님이 잡아주고 계십니다. 계속 푸시하겠습니다.
지속적으로 추가 테스트가 필요할 듯 합니다.
- “폴리곤 수 보다 드로우콜이다” 라는 명언이 생각납니다.

TKEffect_StandardRim 쉐이더 업데이트!

Tue, 12 Jul 2011 09:29:29 +0000

이펙트팀 요청, TKEffect_StandardRim 쉐이더가 완성되었습니다. 좀 더 빨리 만들면 좋았을 텐데, 예정보다 반나절이 느려져서 죄송!

기본 개념은 알파 블렌딩 - 스텐다드 - 쉐이더에, 림 라이팅이 추가되어 유령 캐릭터 등을 만들 수 있게 하는 쉐이더입니다.
기존에 존재하는 TKEffect_Standard 쉐이더를 그대로 사용했기 때문에, 거기서 사용 가능한 기능들이 여기서도 사용 가능합니다.
예를 들면 버텍스 칼라와 버텍스 알파가 적용되지요.

뿐만 아니라 이미지 자체의 알파 채널도 투명도에 같이 영향을 주게 만들어져 있습니다.

-Tint Color에서 색상과 알파를 조절할 수 있습니다. 알파는 그러니까 3가지 방법으로 제어 가능하다는 거죠. 버텍스 알파, 텍스쳐 알파, Tint 알파.

-텍스쳐 로테이션도 여전히 가능합니다.

-Rim Color는 위에 설명한 알파의 영향을 받지 않습니다. 단 버텍스가 너무 적으면 제대로 이쁘게 나오지 않기 때문에, 이쁘게 나오려면 버텍스가 좀 있어줘야 합니다.

-Rim Power로 림라이트의 두께를 조절할 수 있습니다. 높으면 얇고 선명해지고, 낮으면 두껍고 연해집니다.

그래서 중간 이상 옵션에서는 이렇게 나오게 됩니다.

그리고 Low 옵션에서는 이렇게 나오게 된답니다.

Low 옵션에서는 탄젠트 스페이스 계산을 하지 않게 만들기 위해서 림라이트를 구현하지 않았습니다.

현재 커밋되어 있습니당.

끝났다!

Tue, 12 Jul 2011 01:38:56 +0000

아 회사일은 죽어라 바쁩니다. 그거 말고.

나름대로 노후 (…) 라던가 취미 (…라고 하기엔 너무 깊이 들어간 감이 없지 않지만) 를 위해서

살짝 관계를 하고 있는 정부관련게임뭐시기 프로젝트를 끝냈습니다. 퇴근하고 집에 와서 개인적인 일좀 보고 애들좀 봐주고 안정되면 12시… 아효 좀 쉬어야지 하면서 잠깐 노닥대면 한두시…
그래서 하루에 프로젝트 참여할 시간이 한두시간밖에 없었는데, 어쨌건 기한 안에 끝내서 다행입니다.

뭐 하는지 밝힐수도 없는 거라 참 슬프기도 하고

하여간 큰 짐 하나 덜었습니다.

이제 중간 짐 두 개가 버티고 있긴 합니다.
겨울에는 다시 큰 짐 하나가…
나 왜 이렇게 사니 …

상중하 옵션작업 추가

Mon, 11 Jul 2011 14:19:56 +0000

현재 각 맵들이 번들화 작업 대기중입니다. 이번에 업되면 버그가 잡히고, 살짝 더 무거워지며, 퀄리티가 올라갑니다.
아직 번들이 완성되지 않았지만 곧 완성되어 전달됩니다.

지금 굉장히 바쁜 관계로 빨리 씁니다.
최고 옵션에서의 변화는 쉐이더 LOD가 500으로 올라갑니다. 이 의미는 쉐이더 변화폭을 크게 만들어, 중간 옵션이 생겨도 대응할 수 있게 만들기 위해서입니다.

중간 옵션에서의 변화는 일단 텍스쳐 해상도가 full로 올라갔습니다. 기존보다 텍스쳐가 또렷해 질겁니다.
쉐이더 LOD가 300으로 올랐습니다. 이것은 허옇게 되는 버그를 피하고자 취한 조치입니다.
겸해서 쉐이더 LOD를 쓰는 쉐이더들이 같이 업데이트 되어야 효과가 제대로 나옵니다.

최저옵션에서도 역시 텍스쳐의 해상도가 쿼터에서 하프로 한단계 상승하였습니다. 퀄리티가 더 올라갑니다.
쉐이더 LOD도 200이 최저값이 되도록 하였습니다. 약간 더 그래픽 카드에 부담은 되겠지만, 허옇게 되는 버그가 사라집니다.
최저옵션에서 지형 간략화 (픽셀 에러) 수치가 중간 옵션에서와 같은 수치로 바뀌었습니다. 이로써 최저옵션에서 지형이 깨지는 현상 - 파고드는 현상 - 등이 상당히 줄어들 겁니다. 단 약간 무거워지겠죠.

앞으로의 당면한 작업내용.

옵션 자동조정 기능이 추가됩니다 : 사양을 간략하게 체크해서, 상중하 옵션을 초반에 알아서 결정해 줍니다. 단, 지금 그 체크값으로 알아낼 수 없는 요인들이 발견되어, 추후 사태를 보면서 개량이 필요합니다. 현재 철홍스승님이 작업중입니다.

옵션 세부 컨트롤이 추가됩니다. : 세문씨 로딩중입니다.

옵션 5단계로 추가될 예정입니다 : 3단계로 버티려 했는데, 중/상 의 갭을 크게 느끼시는 컴퓨터들이 생기기 시작했습니다. 추가로 옵션을 넣어야 할 것으로 보입니다.

모바일 4 터레인 퍼포먼스

Sun, 10 Jul 2011 00:20:07 +0000

모바일 4 터레인 퍼포먼스

http://www.store.azert2k.fr/?page_id=556

편리하긴 하지만 4장을 쓰면 아이폰에서는 감당하기 힘든 프레임이 나온다.
편법을 쓰지 않으면 아이폰에서는 2장 이상 사용불가.

아틀란티카 S 테스트

Thu, 07 Jul 2011 17:34:06 +0000

아틀란티카 S 테스트를 하라는 군요. 사실 요새 좀 정신이 없습니다.
한참 정신 있었을 때에는 조낸 신랄한 리뷰를 재수없게 올리곤 했었는데, 요샌 제 코가 석자라 그러질 못했었군요.
이게 다 제 업보 …

아아아…

어쨌건 게임을 시작했습니다. 늘 해야지 해야지 하면서 못하고 있었네요. 요샌 게임할 시간도 계획을 내서 해야 하다니..
내 엑박과 키넥트는 썩고 있고..

사실은 이런 게임을 할 때 가장 무서운게 위 내용입니다.

… 말이 무섭잖아요….!!!!???!!
내가 없을때 정보에 접근한다지 않나, 문자도 맘대로 보낸데요!!! ㄷㄷㄷㄷㄷ 으악 내 정보!!!

아니 그건 그렇고 들어오자마자 어디서 많이 보던 닉네임이 친구등록을 하고 난리 ….
이건 그 친구가 의도를 가지고 보내는 건가요? 아니면 자동으로 보내는 건가요?

친구등록을 하고, 왜 창이 없어지지 않나 잠깐 멍하니 기다렸습니다. 왠지 자동으로 닫힐거라고 생각했지 뭐예요.
X 버튼을 누르니 창이 닫히고, 뒤에는 드디어 게임 화면같은 것이 나와 있었습니다.

보라색 인터페이스는 꽤 깔끔한 편이네요.

그렇지만 배경 이미지는 … AT1 초기에 썼던 이미지네요 … AT의 대표 이미지라고 하기에는 좀 무리가 있지 않나 싶습니다. 우리 마우스 패드에 멋진 이미지들 많은데 그 이미지를 안쓰고 지금은 대표 이미지로 쓰고 있지 않은 이미지를 굳이 쓸 필요가 있었을까요?

그렇게 난관같지도 않은 난관을 넘어 게임에 들어왔습니다.
전 스머프 빌리지 같은건 옆에서 많이 봤습니다만, 이런 게임을 직접 하는건 처음이거든요.

그렇게 게임에 들어온 것 까진 좋은데… 첫 화면에서 뭐지뭐지 하다가

이렇게 되어 있길래 그냥 마우스를 눌렀더니, 상점으로 들어가 버렸습니다.

그랬더니 이런 창이 떴어요.
음… 상점… 이군요. 네 그래요.. 음…. 뭐 첨부터 상점이 눈에 들어올 리는 없고 그런가보다 했습니다.
근데 미묘하게 위아래가 잘리는게 신경쓰이는군요. 제 노트북 해상도는 1600*900 입니다. 세로가 900이면 그렇게 작은건 아닌데…
여러 가지 툴바와 메뉴창들 때문에 실제로 보이는 영역은 900 쯤 되지 않을까 싶은데… 넷북에서는 당연하게도 스크롤 되겠군요? 넷북은 세로 600 밖에 안되니까요.
1280*1024 를 지원하는 데스크탑 기준으로 만든것 같아요. 물론 아래의 친구라던가 정보창은 안보여도 게임하기 큰 지장 없는 듯 하니까 괜찮을 것 같기도 하지만, 어쨌건 조금 짤리는건 눈에 들어오긴 하네요. (f11 누르면 됩니다만 그정도로 집중해서 하고 싶진 않고)

뭐 그런 생각을 가지고 보고 있긴 했는데…
문제는…
닫기 버튼이 없어!!!!!
아니, 어떻게 닫는거야 이거? ㄷㄷㄷ

잠깐 패닉 끝에 발견한 버튼은 이것. 아 이걸로 돌아갈 수 있는거군요.
‘닫기’ 의 개념이 아니라 ‘돌아가기’ 의 개념이네요.

아 그전에 하고 싶은 말, 이 버튼 애니메이션들 정말 마음에 듭니다.
아무래도 정적인 게임이라 버튼에 애니메이션을 넣었나 본데, 무척 보기 좋고 신선했습니다.
단 , 마을 버튼은 때때로 애니메이션이 안되더군요. 뭔가 버그인듯.

이건 사운드 옵션 버튼 같은데, 첨에는 아래 스피커 버튼을 눌렀는데 왜 음악이 안꺼질까 하고 혼동했었습니다.
뭐 익숙하면 별일 아니긴 한데, 보통 스피커 버튼이 전체 사운드를 의미하곤 하죠,.

초반에 약간 버벅이면서 여러 번 마을로 돌아간 끝에, 결국 어떻게 조작해야 하는지를 알게 되었습니다.
new라고 씌여져 있던 퀘스트 버튼도 이제야 눈에 들어오네요. new가 움직이거나 반짝이기라도 했다면 제일 먼저 눌렀을 텐데요.

이 게임의 핵심 컨트롤은 여기 있는 이 4개 (5개?) 의 버튼이네요.
초반에 튜터리얼까지는 말고도… 이 버튼을 제일 먼저 눌러 볼 수 있게끔 초반 한 10분 한정으로 이 버튼들 중 현재 권장하는 버튼이 반짝거린다 하면 더 좋지 않을까요? 굳이 구구절절히 튜터리얼을 넣을 필요는 없어 보입니다.

어쨌건 어찌어찌해서 퀘스트를 받았습니다.

아틀란티카를 해봤으니 전투하러 가는건 쉽게 알 수 있었지요. 단지 처음 하는 유저라면 사냥터로 갈 수 있게끔
사냥터 버튼을 반짝이게 해줬으면 좋았을텐데요.

그렇게 앗싸 전투하러 가자라고 딱 갔는데,
갑자기 경고창이 딱 -

아 용병을 배치 안했다고 딱 -

이런 알림 좋네요. 적절한 타이밍의 적절한 알림!

그래서 용병을 고용했습니다.

오오! 캐릭터가 휘리릭 번쩍번쩍하게 나타나!!! 매우 느낌이 좋네요!!! 멋지다 용병!!

좋았어 천공의 정령. 죽여주마…

엥?

아 이런, 전투배치를 안했군요. ㅋㅋㅋㅋ 다시 돌아가서 전투배치를 합니다.
게임 처음 하는 유저라면, 한 번 혼동할 수도 있겠습니다. “용병을 고용한다” 는 것을 “전투배치 한다” 라는 것과 다른 개념이란걸 알지 못하면 말이죠.

…그런데 마을 -> 용병관리로 갔었었는데
알고보니 아래에 버튼이 있었군요.

드디어 첫 전투가 시작되었군요.

… 잠깐… 용병이 좀…
다시 렌더링하던가 다시 캡쳐해서 좀 이쁘게 만들면 안될까 하네요.
배경도 신묘한 원화 디자이너의 손길을 거쳐 좀 고급스럽게 만들면 안될까요.
이 앞의 멋진 계백과 다르게 이 계백의 이미지는 좀 늙어 보입니다.

마치 현실은 이상과 다르다는 걸 가르쳐 주는 듯한…

이렇게 생각하고 있는데, 갑자기 자동으로 전투를 하기 시작합니다.
… 으음! 전투가 자동이로군!!!
자동 좋습니다. 이런거 좋아요. 별로 거부감 느끼지 않고, 전투도 적당한 박진감이 있습니다. 타격감도 나쁘지 않고.
나중에 마법쓰면 화려해 지겠죠? 이 프로젝트 AD 누구인가요? 재활용도 적당히 하면서 결과가 꽤 좋네요????

다시 한 번 칭찬 추가. 저 칭찬 인색한 편입니다.

아 근데, 전 분명히 앞에 배치했다고 생각했는데… 저기가 앞이 아니었어 ㅋㅋㅋ
여기선 오른쪽이 앞이군요! 분명히 전열이라고 씌여 있는데도 그냥 위가 앞이라고 생각해 버렸습니다.
첫 전투때 보니 총병을 앞에서 배치해 버렸었군요 !

그래서 이렇게 위치를 조정.

근데 드래그 이동이 생각만큼 착착 감기게 이동하지 않네요?
다른 컨트롤들의 감각이 좋아서 특히 이 감각이 눈에 띄고 있습니다.

어찌어찌 해서 전투를 잘 끝냈습니다.
피채우는데 돈이 드네요? 뭐 편해서 일단 좋습니다.
여기도 아이콘 애니메이션 너무 맘에 드네요!!! 누가 담당이예요 이거??!!! 최고임!

아참 회복되는 효과 이펙트는 좀 있었으면 좋겠습니다. 피만 조용히 차니까 안찬줄 알고 몇 번 눌렀어요.

정령에겐 좋지 않은 광석… 광석이 영 좋지 않은 곳을 지나간 모양이군요.

그렇게 이거저거 하다가.. 토벌이란걸 봤습니다.

.. 토벌…

얘기를 보니까 아마도 사냥터로 그냥 파견을 보내서 몇 시간동안 지가 알아서 돈벌고 전투해 오라는 기능?
스머프 빌리지에도 비슷한게 있었던 것 같기도 하고요.

그래서 보내봤더니

과연 그거네요. 호호호홍 이해하기 쉬웠어요.

이렇게 되고 나니, 전투진형 1,2 라는 것도 이해가 자연스럽게 되었어요. 아마도 다른 용병단을 만들어서 그건 전투시키고, 남는 애들은 토벌 보내고 그러는가 보지요?

결론적으로 사소한 문제들은 있어도 이해가 참 쉽게 잘 되어 있는 편이었습니다.
조금만 더 친절하고 세심하게 다듬는다면 무척 멋진 게임이 되지 않을까요?
예를 들면 전투시의 용병도 , 이왕 카드모양으로 만든거 굳이 캐릭터 전신을 넣을 필요 없이 일러스트로 해도 충분할 것 같고 말이죠. 버튼들의 애니메이션이 특히 맘에 들었습니다. 초반에 튜터리얼 대신에, 권장하는 버튼을 반짝거리게 해주는 것만으로도 충분히 가이드가 될 것 같고 말이죠.

마을이나 배경, 전투 캐릭터등이 UI에 비해 상대적으로 디자인 퀄리티가 떨어져 보이는 것만 개선하면 무척 고급스러운 게임이 될 수 있을 것 같았습니다.

이만 바빠서 총총. 할일 많슈.

삼품 상중하 옵션안 자동인식 기획

Thu, 07 Jul 2011 17:03:28 +0000

알 수 있는 정보 : 그래픽 카드 이름 / 그래픽 카드 메모리 양 / 쉐이더 지원여부 / CPU 코어수 / 물리 메모리

위 내용중 간략한 정보를 읽어내 자동으로 처리합니다. 물론 오차가 있을 수 있으므로 (인텔 칩 그래픽 카드 같은 경우)
여기에 추후 추가되는 if 문이 있을 것으로 예상할 수 있습니다. 그건 테스트하면서 추가할 수 밖에 없겠네요.. 변수가 많아서.

쉐이더 지원여부 : 최소 2.0 지원 / 3.0 지원 권장

그래픽 카드 메모리 양 : 128~ 256M미만 1점       256M~ 512M미만 2점       512M 이상 3점
CPU 코어 :                  1개일때 1점                   2개일때 2점            3개 이상으로 인식될때 3점
물리 메모리 :                1G 혹은 이하 일때 1점                  2G 이상일때 2점      3G 이상일때 3점

모든 점수를 합산했을때
최상옵션 : (쉐이더 3.0 지원) && (그래픽 카드 메모리 3점) && (CPU와 물리 메모리 5점 이상 )
중간옵션 : (쉐이더 3.0 지원) && (그래픽 카드 메모리 2점) && (CPU와 물리 메모리 3점 이상 5점 미만 )
최하옵션 : (쉐이더 2.0 지원) && (그래픽 카드 메모리 2점 || 1점) && (CPU와 물리 메모리 3점 || 그 이하 )

심플한 Vertexlight : 기본형

Tue, 05 Jul 2011 10:04:40 +0000

내장되어있는 버텍스 라이트 쉐이더는 이것저것 많이도 고려하길래 , 그냥 암 생각 없는 기초버전의 Vertexlight 쉐이더 기본형이 필요해서 제작해 봤음. 핵심은 Vertexshader에서 ShadeVertexLights 함수로 계산되는 부분인데, 이 부분을 UnityCG.cginc 에서 파고 들어가보니 아래와 같이 나온다.

float3 ShadeVertexLights (float4 vertex, float3 normal)
{
float3 viewpos = mul (UNITY_MATRIX_MV, vertex).xyz;
float3 viewN = mul ((float3x3)UNITY_MATRIX_IT_MV, normal);
float3 lightColor = UNITY_LIGHTMODEL_AMBIENT.xyz;
#if UNITY_HAS_LIGHT_PARAMETERS
for (int i = 0; i < 4; i++) {
  float3 toLight = glstate.light[i].position.xyz - viewpos.xyz * glstate.light[i].position.w;
  float lengthSq = dot(toLight, toLight);
  float atten = 1.0 / (1.0 + lengthSq * glstate.light[i].attenuation.z);
  float diff = max (0, dot (viewN, normalize(toLight)));
  lightColor += glstate.light[i].diffuse.rgb * (diff * atten);
}
#endif
return lightColor;
}

이것은 즉 버텍스 라이트를 4개까지만 계산하고 그 이상은 SH 라이트로 넘기는 그 부분 같은데 (넘기는 부분은 안나와서.. 그냥 무시하는걸지도..?) 어쨌건 건드리지 않고 일단 그냥 쓰기로 했음.

사실은 Diffuse를 프레그먼트 쉐이더로 짜고 싶었는데, Diffuse 라이팅 - 픽셀 단에서 계산하는 - 함수를 못찾겠다. 뭐 그냥 무식하게 계산하면 되긴 하는데, 그럼 자체적으로 가지고 있는 라이팅 최적화 함수들을 이용할 수가 없으니까… 뭐 사실 그냥 작게 봤을때 vertexlight와 pixellight 의 차이가 별로 없는 것도 있고. (스페큘러같은게 나오기라도 하면 또 몰라)

어쨌건 기본형을 만들어 놓으면 2pass 쉐이더를 짤때건 뭘할때건 유용하니까 만들어 놓자.

Shader “New Shader” {
Properties {
  _MainTex (“Base (RGB)”, 2D) = “white” {}
}
SubShader {

Pass
  {
  Tags { “RenderType”=“Opaque” “LightMode” = “Vertex”}
  LOD 100

   CGPROGRAM
   #pragma vertex vert
   #pragma fragment frag
   #pragma fragmentoption ARB_precision_hint_fastest
   #include “UnityCG.cginc”

sampler2D _MainTex;
float4 _MainTex_ST;

  struct v2f {
    float4 pos : SV_POSITION;
    float2 texcoord : TEXCOORD1;
    float4 diff : TEXCOORD0;
   };
   v2f vert (appdata_base v)
   {
    v2f o;
    o.pos = mul( UNITY_MATRIX_MVP, v.vertex );
    o.texcoord = TRANSFORM_TEX(v.texcoord,_MainTex);
     o.diff = float4(ShadeVertexLights(v.vertex, v.normal), 1.0f);
    return o;
   }

   half4 frag (v2f i) : COLOR
   {
    // texture
    float4 Finalcolor = tex2D(_MainTex, i.texcoord);
    Finalcolor *= i.diff;
    return float4(Finalcolor.rgb,1.0f);
   }
   ENDCG

  }
}
FallBack “Vertexlit”
}

잉츄

Wed, 29 Jun 2011 16:56:10 +0000

상중하 옵션 작업

Tue, 28 Jun 2011 17:52:02 +0000

지형의 정밀도가 크게 변합니다. 하 옵션에서 폴리곤을 대폭 줄이고자 처리한 내용입니다만, 덕분에 옵션이 낮아질수록 지형의 라이팅 부분에 딱 떨어지는 금이 생겨 버립니다. 빛을 조절해서 완화시킬 수 있으며, 이정림 파트장님께 전달된 상태입니다. 할 수 있는 정도로는 수정해 놓았습니다.
터레인 나무 (오브젝트 나무가 아닙니다) 인 경우 옵션에 따라 빌보드 설정등이 바뀝니다. 하 옵션에서는 터레인 나무와 풀이 모두 사라집니다.
텍스쳐 해상도가 변합니다. 최하는 1/8 사이즈입니다만, 그래픽 카드 메모리가 그정도로 낮지도 않고, 1/8로 하게 되면 NPC와 대화할때 NPC의 얼굴이 알아보기 힘들 정도로 깨지게 되기 때문에 최하는 1/4 로 해 놓았습니다.
물/얼음물/캐릭터 쉐이더의 쉐이더 LOD가 가동되었습니다. 물이나 얼음물은 하 상태에서 매우 질이 낮은 수준으로 떨어지며, 캐릭터 쉐이더는 하 옵션에서 Unlit 모드로 바뀌게 됩니다. 염색기능은 여전히 존재합니다. 필요에 따라서 물 계열은 중 옵션에서도 살짝 떨어지게 만들 수도 있겠습니다.
글로벌하게 뿌려대는 파티클 (비/꽃잎 등…) 은 최하옵션에서 나타나지 않도록 만들었습니다. 폭포의 물보라 파티클들도 최하옵션에서는 나타나지 않게 만들었습니다. 불 이펙트 등도 상대적으로 무거운 맵에서는 함께 날려버렸습니다.

아 신경쓸거 많음..

아름다운 얼음물

최저사양의 얼음물

최고 옵션에서의 물과 이펙트들

최하옵션에서의 물과 이펙트들. 불 이펙트들은 필요에 따라서 빠지기도 합니다.

IOS performance in Unity

Tue, 28 Jun 2011 11:05:35 +0000

iOS ===

If you want to optimize your content for iOS, then it is beneficial for you to learn more about iOS hardware devices.

Alpha-Testing

Contrary to the desktop, alpha-testing (or use of discard instruction in pixel shader) is very expensive on iOS. If you can replace your alpha-test shader with alpha-blend, do so. If you absolutely need to use alpha-testing, then you should keep areas of visible alpha-tested pixels to a minimum.: 알파 테스트는 죄악이다! 라고 할 정도로 더럽게 비싸다고 써 놨는데… 실제 테스트해 봐도 - 나무를 빽빽히 심어서 비교해 봐도- 둘의 차이를 느끼기 힘듭니다. 아직까지 증명이 안된 관계로 정말? 이라고 믿을 수 없는 상황.

Vertex Performance

Generally you should aim at 40K or less vertices visible per frame when targeting iPhone 3GS or newer devices. You should aim at 10K or less vertices visible per frame when targeting older devices equipped with MBX GPU, such as: iPhone, iPhone 3G, iPod Touch 1st and 2nd Generation.: 4만 폴리곤까지 쓸 수 있다라고 하는데… 구형 디바이스를 위해서는 만폴리곤으로 제한하라고 되어 있긴 한데… 실제로 테스트 해 보면 훨씬 더 쓸수 있단 말입니다.. 얼마였지…?

Lighting Performance

라이트 선택하고 나오는 렌더 모드에서 important 선택하면 픽셀라이트로 가동됩니다. 픽셀 라이트 사용하지 말라고 하는 얘기지요. 이건 확실합니다. 느려져요. 라이트는 위의 두 가지 ‘버텍스 퍼포먼스와 알파’ 보다 확실히 프레임에 밀접하게 영향을 끼칩니다.

Per-vertex dynamic lighting can add significant cost to vertex transformations. Avoid multiple lights affecting single objects. Bake lighting for static objects.

퍼 버텍스 라이트라 하더라도 어쨌건 IOS 에서는 여러 개 라이트는 금지. 버텍스 라이팅은 버텍스 트렌스포메이션에 코스트를 부여하지까요. 역시 언라이트 unlight 가 가장 빨라요.

Optimize Model Geometry

When optimizing the geometry of a model, there are two basic rules:

Don’t use excessive amount of faces if you don’t have to
Keep the number of UV mapping seams and hard edges as low as possible

하드 엣지가 뭐냐 했더니 멀티플 노말을 가진 버텍스로군요. 즉 폴리곤을 줄여라, 스무스 옵션을 꺼서 각진 오브젝트를 만들지 마라, uv 줄여라 하는 매우 고전적인 얘기.

Texture Compression

Use iOS native PVRT compression formats. They will not only decrease the size of your textures (resulting in faster load times and smaller memory footprint), but also can dramatically increase your rendering performance! Compressed texture requires only a fraction of memory bandwidth compared to full blown 32bit RGBA textures. For performance comparison check iOS Hardware Guide.

PVRT 포맷을 사용하란 말이군요. 단순히 사이즈만 줄이는게 아니라 메모리도 줄이고 로딩도 빠르고 킹왕짱이라는. 뭐 그래주죠. 알파 채널에서 압축되어서 깨지면 다른 툴로 극복해라…

Some images are prone to visual artifacts in alpha channels of PVRT compressed textures. In such case you might want to tweak PVRT compression parameters directly in your imaging software. You can do that by installing PVR export plugin or using PVRTexTool from Imagination Tech – creators of PVRT format. Resulting compressed image with .pvr extension will be imported by Unity Editor as is and manually specified compression parameters will be preserved.

If PVRT compression formats do not deliver enough visual quality and you need extra crisp imaging (for example UI textures), then you should consider using 16bit texture over full 32bit RGBA texture. At least you will reduce memory bandwidth by half.

Tips for writing well performing shaders

Although GPUs fully support pixel and vertex shaders since iPhone 3GS, do not expect to grab a desktop shader with complex per-pixel functionality and run it on iOS device at 30 frames per second. Most often shaders will have to be hand optimized, calculations and texture reads kept to a minimum in order to achieve good frame rates.

쉐이더에서 그랩 grap 텍스쳐는 기대하지 말아라 ㅋㅋㅋ 안기대해 ㅋㅋㅋ

Complex arithmetic operations

Do NOT try to roll your own normalize, dot, inversesqrt operations however. Always use built-in ones – this was driver will generate much better code for you.

Keep in mind that discard operation will make your fragments slower.

Floating-point operations

Always specify precision of the floating-point variables while writing custom shaders. It is crucial to pick smallest possible format in order to achieve best performance.

If shader is written in GLSL ES, then precision is specified as following:

highp - full 32bit floating-point format, well suitable for vertex transformations, slowest
mediump - medium precision 16bit floating-point format, well suitable for texture UV coordinates, x2 faster than highp
lowp - usually 12bit fixed-point format, well suitable for colors, lighting calculation and other high performant operations, x4 faster than highp

If shader is written in CG or it is a surface shader, then precision is specified as following:

float - analogous to highp in GLSL ES, slowest
half - analogous to mediump in GLSL ES, x2 faster than float
fixed - analogous to lowp in GLSL ES, x4 faster than float

Hardware documentation

Take your time to study Apple documentations on hardware and best practices for writing shaders. Note that we would suggest to be more aggressive with floating-point precision hints however.

Bake Lighting into Lightmaps

It is going to run a lot faster (2-3 times for eg. 2 pixel lights)
And look a lot better since you can bake global illumination and the lightmapper can smooth the results

If a number of objects being rendered by the same camera uses the same material, then Unity iOS will be able to employ a large variety of internal optimizations such as:

Avoiding setting various render states to OpenGL ES.
Avoiding calculation of different parameters required to setup vertex and pixel processing
Batching small moving objects to reduce draw calls
Batching both big and small objects with enabled “static” property to reduce draw calls

Simple Checklist to make Your Game Faster

Keep vertex count below:
- 40K per frame when targeting iPhone 3GS and newer devices (with SGX GPU) 4만 버텍스 아래로 !!!
- 10K per frame when targeting older devices (with MBX GPU)
Keep the number of different materials per scene low - share as many materials between different objects as possible.
Set Static property on a non-moving objects to allow internal optimizations.
Use PVRTC formats for textures when possible, otherwise choose 16bit textures over 32bit.
Use combiners or pixel shaders to mix several textures per fragment instead of multi-pass approach.
If writing custom shaders, always use smallest possible floating-point types:
- fixed / lowp – perfect for color, lighting information and normals,
- half / mediump – for texture UV coordinates,
- float / highp – avoid in pixel shaders, fine to use in vertex shader for vertex position calculations.
Minimize use of complex mathematical operations such as pow, sin, cos etc in pixel shaders.
Do not use Pixel Lights when it is not necessary – choose to have only a single (preferably directional) pixel light affecting your geometry.
Do not use dynamic lights when it is not necessary – choose baking lighting instead.
Choose to use less textures per fragment.
Avoid alpha-testing, choose alpha-blending instead. : 이건 동의하기 힘듬. 결과를 보여줘!
Do not use fog when it is not necessary.
Learn benefits of Occlusion culling and use it to reduce amount of visible geometry and draw-calls in case of complex static scenes with lots of occlusion. Plan your levels to benefit from Occlusion culling. 어클루젼 컬링을 이용하라.. 뭐… 좋지..
Use skyboxes to “fake” distant geometry.

가죽공예 시계

Sun, 26 Jun 2011 15:21:10 +0000

(제가 배우는건 아니지만) 한참 배우는 중이므로 나중엔 주문받고 판매할 수 있을지도…
아, 지금도 판매할 수는 있다는군요.
그렇지만 강탈했뜸.

상/중/하 옵션 기능 추가

Fri, 24 Jun 2011 17:44:34 +0000

현재까지는 게임에서 상/중/하 옵션들이 지금까지는 각자 분리되어 관리되고 있는 관계로 제어가 쉽지 않고, 필요에 따라 씬별 수정이 힘든 단점이 있었습니다.

그래서 이번에 장기프로젝트 (라고 해도 일주일…) 로 옵션들을 한번에 컨트롤 할 수 있는 기능이 TS 팀에서 완성되었고, 제가 기본 옵션을 정한 후 각 씬별로 적용까지 완료해서 현재 외부 어셋서버에 커밋되어 있는 상태입니다. 이걸 또 어떻게 전달한담…

하여간 이제 남은 일은 철홍스승님의 힘을 빌려 이 옵션값을 참조해 게임 클라이언트에서 돌아갈 수 있도록 연결해 주는 일입니다. 이건 제가 의뢰하면 될 듯 하고… 즉 아직 실제 게임에는 돌아가지 않는 단계입니다.

다음은 UI를 구상해야하겠군요. 옵션이 3단계로 정해졌으니, 세부 옵션들을 몇 개 넣어야겠습니다.

그리고 배경팀에서는 / 혹은 시네마틱 팀이라던가 / 이제부터 만드시는 모든 씬의 하이어라키에, 기존에 제작되어 있는 GameQualityController 오브젝트를 카피해 놓으시면 되겠습니다. 따로 건드리실 것은 없고, 간편하게 카피만 해 놓으시면 됩니다.

사용법도 간단합니다. 저 GameQualityController 오브젝트를 선택한 후, High, Medium, Low 를 선택하시기만 하면 어느 모드에서나 상/중/하 때의 모습을 보실 수 있으십니다. 즉 그래픽 작업하시면서 각 옵션별 모습을 수시로 변화시키면서 보실 수 있다는 말씀이지요 홍홍홍

아래에 상세 옵션을 조절할 수 있게 해 놓았기 때문에, 필요한 맵에 한해서는 저 옵션들을 바꿀 수도 있게 해 놓았습니다.
그렇지만 되도록이면 조절은 삼가해 주세용 - 그냥 저한테 말씀해 주세요. 제가 조절할께요. -

세부 설명 들어갑니다. 옵션은 기본으로 상/중/하 3단계로 되어 있습니다.
단계별 변화 모습은 아래와 같지요.

상입니다.

중 옵션입니다.

하 옵션입니다.

이 옵션들은 기존에 내장되어 있던 옵션들의 기능보다 강력합니다.
기존 내장 옵션에서 있던 기능을 모두 포함하고 있으며, 거기에 더해서 쉐이더 LOD , 이펙트 상중하 옵션을 더 가지고 있습니다. 물론 사용하기도 더 간편하고요.

예를 들어 아래와 같은 옵션별 기능은 기존의 방법대로는 하기 힘들었던 것입니다만, 지금은 아주 간편하게 할 수 있습니다.

각종 이펙트들이 사라졌습니다. 바닥에 흐르는 물과 비도 옵션에 따라 사라지게 할 수 있습니다.

다음에 할 일은 바로 이 이펙트의 상중하 옵션 작업으로, 해당 사양 컴에서 돌려보면서 이펙트의 출몰등을 결정하게 될 것입니다.
물론 나중에 이펙트 팀에서 재 수정하는 것도 환영 ♥ 그런걸로 신경 안씁니다. ㅋㅋ

모바일 퍼포먼스 테스트

Mon, 20 Jun 2011 16:52:51 +0000

간략하게 모바일 퍼포먼스 테스트를 진행해 보았습니다.
얻을 수 있는 데이터가 모바일에서는 꽤 적기 때문에 테스트에 한계가 있는데다가, 스크린샷을 찍어서 올리는 것도 각종 난관이…

일단 예전 PC 버전 테스트때와 동일하게, 모바일화 된 (혹은 모바일화될 것으로 예상되는) 캐릭터 40마리를 자동으로 스폰시켜서 이동하면서 프레임을 찍는 방법을 사용하였습니다.

40마리의 캐릭터는 같은 모양처럼 생겼지만, 사실은 파일 이름을 전부 다르게 만든거라 메쉬부터 애니메이션까지 모두 독립적으로 가지고 있는 다른 캐릭터입니다. 재철군이 수고해 주셨습니다.

결론적으로 테스트는 매우 싱겁게도 40마리 기준의 환경에서, 너무나도 평이하고 변화없는 테스트 결과를 보여주었습니다.

내정 맵을 제외하고 나머지의 맵에서 모두 18-19 프레임의 균일한 결과가 나왔으며, 프로파일링에서도 드로잉 20% , 스키닝 40% 라고 하는 지극히 정상적이고 변화없는 결과들이 나타났습니다.

지금까지의 반복된 테스트로 쌓인 경험으로 미루어 보아, IOS에서는 특정한 기술이나 행위가 프레임을 떨어뜨린다기 보다 전체의 한계 영역이 있고, 그 한계 영역 안에서는 안정스럽게 결과가 나오다가 그 한계를 넘는 순간 퍼포먼스가 뚝 떨어지는 것으로 보입니다. 즉 이후에 로직이 들어가고 각종 인터페이스 - 모바일이라서 인터페이스는 꽤 줄겠지만 - 들이 들어가게 되면 언제 한계에 걸릴지 모른다는게 좀 불안합니다.

어쨌건 현재까지의 데이터로 미루어 봐서 그래픽에서의 데이터들은 매우 안정적으로 보이지만, 지금처럼 지속적으로 데이터를 줄이면서 작업할 수 있도록 신경써야 할 것으로 보입니다. (프레임 괜찮다고 슬금슬금 올리면 떼찌 >_</ )

’
" 분홍색 문제는 반투명 스크립트 기능에서 쉐이더를 못찾는 기능으로 보입니다. 수정들어갑니다 "
" 파티클이 분홍색인건 다른 이유인것 같습니다. 아직 이펙트 팀이 모바일에 본격적으로 활동하지 않으므로, 곧 체크될 것으로 보입니다. "
" 캐릭터 분홍색은 신경쓰지 마세요. ㅋ"

모바일용 이펙트 쉐이더 수정

Wed, 15 Jun 2011 14:35:00 +0000

아무래도 이펙트팀에서 요구하는 기본적인 기능들이 사실 꼭 필요한 기능인 것들도 맞고,
그러자니 기존에 만든 이펙트 쉐이더가 그 기능들을 다 넣으면서 최적화가 다 된 것들이라… 결국에는 고심하다가 그냥 웹에서 쓰이는 이펙트 쉐이더를 그냥 모바일에도 넣었습니다.

즉 버텍스 알파 기능과 로테이션 기능 등, 웹용에서 사용하던 기능이 모바일에서도 동일하게 작동됩니다.
Mobile/TKEffect/TKEffect_ParticleAdd_mobile
Mobile/TKEffect/TKEffect_ParticleMulti_mobile
Mobile/TKEffect/TKEffect_ParticleStandard_mobile
3종입니다.

덕분에 좀 무거워졌습죠. 웹에서는 가볍지만 모바일에서는 무겁잖아유. 약 4g정도의 느낌.
이펙트팀에서는 사용하실때, 이펙트를 좀 심플하게 만들어 주시기 바라겠습니다. 너무 많이 중첩하지 말고…

모바일쪽 퍼포먼스 테스트 간단하게 해 보았습니다.
감 잡을때 사용해 주세요.

맥스의 주전자 기본형으로 , 오른쪽은 일반 파티클add 쉐이더이고 왼쪽은 Flow 쉐이더입니다.
주전자는 폴리곤이 꽤 많지요.
각각 16개, 12개의 주전자로 총 38개의 주전자를 표시해 보았습니다.
프레임 변화가 거의 안보입니다. 이 정도면 웬만한 이펙트 만들기로는 괜찮을것 같습니다.

그렇지만 다량으로 카피해서 약 200여개의 주전자 이펙트로 만들어 보았습니다.
프레임이 9프레임까지 떨어졌네요. 이렇게 하니까 다소 무거운 쉐이더임이 보입니다.

왜냐면 같은 주전자에 Unlit - 가장 가벼운 쉐이더 - 를 적용하였을 때는 기껏해야 1 프레임 정도 떨어졌었거든요.

대충 이 정도의 느낌이니 너무 남발해서 사용하지 마시고 최소로 사용해 주세요

Mobile 4 Terrain Test

Wed, 15 Jun 2011 01:54:42 +0000

모바일 4 터레인은 아시다시피 ‘모바일 기기에서도 완전 착하게 유니티의 터레인 - 텍스쳐 4장을 섞어 스플레팅으로 만들어 주는 기능 - 을 사용할 수 있게 해주자’ 에서부터 시작된 플러그인입니다. 가격도 싸고 사용법도 쉽습니다.

모바일 버전에서는 유니티에 포함된 터레인을 쓸 수 없기 때문에 보통 통짜 맵용 지형 텍스쳐를 그려야만 하고, 이것은 조금이라도 넓어진다면 심각한 해상도 문제를 겪기 때문에 사실상 쓰기 곤란한 방법입니다.
여러 조각으로 나눠서 각 2048 한 장씩 준다고요?

오 맨, 메모리를 걱정해 주세요. 애석하게도 우리 아이퐁에게는 그다지 메모리가 많지 않습니다.
배경에게 할당된 메모리가 30메가 정도인데, 안정되게 텍스쳐를 사용하려면 타일만 따져서 10메가 내외가 한계라고 볼 수 있습니다.

물론 미리미리 테스트하고 결과를 내고 싶었었지만 그동안 맥에서 아이팟으로 넘기기가 안됐었었 … OTL

이제야 장비가 전부 들어오고 아이팟 넘기기도 되고 제대로 프로젝트가 가동되기 시작했으니, 쉐이더 정리를 재빨리 하고 그 다음에 해야 할 일은 지금 이것이었겠지요.

우선, 지형을 그리기 위해서는 위에서 얘기했듯 크게 두 가지의 방법이 있습니다. (뭐 다른 방법도 좀 있지만 일반적으로는…)

스플레팅 방법 : 타일링된 텍스쳐를 여러 장 겹친 후, 마스킹 텍스쳐로 섞어주는 방법
통으로 그리기 : 그냥 통으로 그리기 ㅋㅋ 냅다 ㅋㅋㅋ

첫 번째 방법의 장점은, 스플레팅이라는 훌륭한 기능을 이용해서 타일을 제작하기 때문에 작은 사이즈의 타일들과 한 장의 마스크로 아주 넓은 지역을 해상도 저하없이 쉽게 조합해서 만들 수 있으며, 수정도 용이하다는 것입니다.

그렇지만 단점이 좀 치명적인데…. 그것은 모든 픽셀에서 여러 장의 이미지를 중첩해서 가지고 있게 된다는 겁니다. 모든 타일들과 마스크까지, 모든 픽셀에서 가지고 있는 식이 되는 거니까요. 즉 메모리는 절약할 수 있을 수 있겠지만 저사양의 모바일 기기에서는 CPU에 부하를 줄 위험이 있다는 겁니다.

두 번째 방법은 그 반대로, 그냥 통으로 그리다보니 그리기가 여간 까다로운게 아니고, 수정도 용이하지 못합니다. 그리고 해상도를 높게 만들면 이번엔 사용 메모리 제한에 넘어가 버려서, 그렇게 크게 그릴 수 없기 때문에 뿌옇게 배경이 만들어진다는 단점을 가지게 됩니다.

물론 장점도 있지요. 메모리에만 잘 올라간다면, 그냥 텍스쳐 한 장이 오브젝트에 입혀진 것이기 때문에 더 이상의 실시간 계산 부하는 없습니다. 훨씬 빠르죠.

때문에 월드맵과 같이 굉장히 큰 맵에서는 1번의 스플레팅 방법을 적당히 타협해서 쓰는 것이 좋고, 기타 던전, 마을, 전투맵과 같이 상대적으로 작은 맵들은 그냥 통으로 한다던가 하는 편이 좋을 수 있습니다.
물론 이런 장점과 단점은 상대적이며, 그래픽 결정하시는 분이 보고 마음에 드는 방법으로 결정해야만 하겠지요. 제가 AD가 아니니까용 ㅋ

어쨌건 그래서 , 드디어 테스트 해 볼수 있게 되었습니다.
느려도 얼마나 느린지 뭘 알려줄수 있어야 결정을 하지 원.

시험삼아 아이팟에 넘겨보니 잘 넘어갑니다. 이히히. 거진 한 달만에 넘겨보네.

그런데 미리 말씀드리자면, 아래 테스트할 때 실수가 하나 있었습니다.
아이폰에는 두 개의 해상도가 있습니다. 3gs용 저해상도, 4g용 고해상도.
3gs는 480*320 의 저해상도이고, 아이폰4는 960*640으로, 무려 4배나 차이가 납니다. 이것은 픽셀 처리 연산이 4배가 차이가 난다는 것으로, 우리는 480*320의 저해상도에 기준을 맞추어 제작하기로 되어 있었는데 아래 테스트는 960*480의 고해상도로 테스트했습니다.

대략 이 정도의 차이.

그러니까 우리게임은 이 정도의 차이. 위의 저해상도가 우리 게임 포맷입니다. 아래것은 고해상도로 올린것.
뭐 그치만 프레임 차이가 크거나 한 수준이 아니기 때문에 (아직까지는요) 일단 결과는 신용할 만 하겠습니다.

테스트결과입니다.

스플레팅 4장 : 각 256*256
마스킹 1장 : 256*256

총 5장의 이미지가 동시에 스플레팅 되고 있습니다. 애석하게도 프레임이 좋지 못합니다. 이 상태에서 8프레임이면 못쓸 물건이지요.

스플레팅 3장 : 각 256*256
마스킹 1장 : 256*256

그래서 이번엔 한 장을 줄여서 총 4장으로 해 봤습니다.
한 장만 빠졌는데도 프레임이 팍 올라가네요. 하지만 여전히 만족할 수 있는 프레임은 아닙니다.
지금처럼 훵 - 한 데에서는 30프레임쯤 나와 주고 막 이래야지요.

스플레팅 2장 : 각 256*256
마스킹 1장 : 256*256

한 장을 또 줄여서 2장만 스플레팅, 총 3장을 이용해 봤습니다. 빈 곳은 검게 보이네요.
21프레임… 약간 애석하긴 하지만 그래도 타협해 볼 만한… 프레임이 나옵니다.

마스킹 1장 : 256*256

이번엔 그냥 아예 한 장으로 만들어 봤습니다. 통맵이란 이런 것이겠지요.
놀랍습니다. 프레임이 풀로 나오는군요. 하긴 256 * 256 텍스쳐 한 장이니 처리가 가벼울 수 밖에 없겠죠.

이대로라면 스플레팅을 2장 (마스킹까지 포함 3장) 으로 하지 않으면 아주 위험하다는 결론이 나옵니다.
그렇다면…. 혹시 텍스쳐를 작게 쓰면 뭔가 달라지지 않을까요?
사실 텍스쳐를 작게 쓴다 하더라도 기존에 메모리를 오바하지 않았었다면 스플레팅에서는 별 차이가 없으리라고 예상됩니다만
한 번 해 보는것도 나쁘지 않겠죠. 혹시 압니까.

그래서 팍 낮춰봤습니다.
실험은 과감하지 않으면 결과가 안나오니까요.

스플레팅 4장 : 각 32*32
마스킹 1장 : 128*128

텍스쳐가 대폭 작아졌는데도 프레임에 변함이 없습니다. 역시 스플레팅은 CPU 부하입니다.

스플레팅 3장 : 각 32*32
마스킹 1장 : 128*128

3장도 비슷.

스플레팅 2장 : 각 32*32
마스킹 1장 : 128*128

2장일 경우 좀 빨라 보입니다만 오차범위 내입니다.

마스킹 1장 : 128*128

1장은 뭐 실험해보는 것도 의미가 별로 없습니다 ㅋㅋ

결론

결론적으로 , 스플레팅을 사용할 때는 한번에 2장 (마스킹 포함 3장) 을 스플레팅해서 사용해야만 의미있는 결과가 나옵니다.
(윤과장님 말씀으로는 아이패드2에서는 4장 다 돌려도 풀로 돌아간다지만…)
그러므로 스플레팅을 사용하실 때에는 2장만 블렌딩 한다는 것을 전제조건으로 생각하시고 계획해 주시는 것이 좋겠습니다.
한 번에 두 장이지, 블럭별로는 다른 2 장을 써도 되니까요, 적절히 응용해 보시면 되겠습니다.

그럼 끝.

BlendLate 쉐이더 업데이트!!!

Tue, 14 Jun 2011 18:11:07 +0000

기존의 BlendLate 쉐이더가 물과 Z 파이팅을 일으켜서 +1 처리가 된 쉐이더가 BlendLate 쉐이더입니다.
그리는 순서가 +1 된 것 외엔 일반 알파블렌딩 쉐이더와 별 차이가 없었지요.

그런데 물이 그 외의 이펙트들과도 파이팅을 꽤 일으켜서, 새로 만든 물에는 아예 -1 이 들어가 있습죠. :)
그래서 어떤 이펙트 쉐이더를 가져와도 물과 파이팅을 일으키지 않게 되어서 이제 BlendLate 쉐이더는 사실 필요가 없어졌습니다.

(단, “물보다 아래에 이펙트가 있으면” 그건 파이팅이 납니다. 그치만 우리게임에는 그런일이 없으므로 상관없죠)

또한 +1이 들어가 있는 BlendLate 쉐이더는 다른 알파 쉐이더랑 충돌이 나곤 합니다.
때문에 BlendLate 쉐이더는 원래대로 돌려놓기로 하겠습니다.

그러므로 사실 BlendLate 쉐이더는 이제 의미가 없습니다.

이제부터는 BlaendLate 쉐이더 사용을 자제해 주시고,

Particle/AlphaBlended 사용해 주십시오.

이미 BlendLate가 많이 사용되어 있으므로 쉐이더를 갑자기 삭제하진 않겠습니다.
즉 BlendLate 쉐이더를 쓰셔도 AlphaBlended 쉐이더와 완전 똑같습니다!! 자동으로 그렇게 됩니다.
그러므로 실수하셨다고 걱정할 필요 없습니다. BlendLate 쉐이더를 쓰셔도 되긴 합니다. 단 자제만 해주세요.

수정전. 알파 블렌딩 파이팅이 납니다.

수정후. 문제가 나지 않습니다.

모바일 쉐이더 일람

Mon, 13 Jun 2011 16:59:23 +0000

모바일에서 사용하는 쉐이더들에 대한 총 집합 설명입니다. 일종의 규약일 수도 있겠지요.

첨부터 잡고 갔으면 좀 더 편했을텐데 아시잖습니까 ;;; 그게 그렇게 할 수가 없었어요

어쨌거나 지금에서라도 잡고 갑니다.

참고로, 기존에 제작된 모든 씬에서 원터치로 일정 쉐이더를 일정한 쉐이더로 교체해주는 스크립트가 이미 만들어져 내장되어 있습니다. 기존에 작업하신 것들을 모두 다 다시 해야 하나..? 라는 걱정은 안하셔도 됩니다 :) 간편하게 바꿀 수 있어요.

쉐이더를 만들때마다 일일히 장비에 돌려서 퍼포먼스 테스트를 해보는 것은 역부족이었습니다. 때문에 감각적으로 (…) 모바일용으로 맞겠다 싶게 만들어 놓고 추후 수정하는 방법으로 하겠습니다. 즉 이제부터는 테스트가 진행될 예정입니다.
사용하실때 편의를 위해서, (Terrain쉐이더를 제외한 ) 모든 쉐이더를 Mobile 폴더로 모아 놓았습니다. 이제부터 이 안에 있는 쉐이더만 사용하시면 됩니다.
내일 뒤의 접미어 _ipad 를 전부 _mobile 로 바꿔 놓겠습니다.

==============================================================================================================
모바일 쉐이더 정리

일반적으로 사용하실 모바일 쉐이더는 아래와 같습니다. 다른 쉐이더가 필요하시면, 요구해 주세요. 옮겨드리거나 만들어 드립니다. (유료아이템으로 판매예정중 … )

위에서 블럭친 쉐이더들이 삼품 모바일에서 쓰이는 쉐이더들입니다. 몇몇 쉐이더는 기본내장되어 있는 관계로 건드리질 못했습니다. 깔끔하게 안보이게 하고 싶었는데…

하나하나 설명을 드리지요. 무거움 설명도 드립니다.
대부분 매우 가볍습니다만..

Mobile / Background

1g (매우 가벼움. g 는 제가 맘대로 만든 쉐이더의 무게 용어)
Z write 를 하지 않기 때문에 소팅이 엉망이 됩니다.
기본 내장되어 있는 쉐이더입니다.
라이팅 계산도 무시합니다. 즉 배경용으로만 사용되어야 할 쉐이더입니다. 스카이박스 같은..

Mobile / Bumped Specular
Mobile / Bumped Specular (1 directional light)

노말맵이 사용되는 쉐이더이지만, 현재 우리의 메인 라이트가 not important 모드 - 버텍스라이트 전용 모드 - 로 이루어져 있기 때문에, 사용해도 효과가 나오지 않습니다. 때문에 사용금지.

Particles

각종 이펙트를 위한 쉐이더가 있습니다만, 동일한 쉐이더를 따로 제작해서 드렸기 때문에 사용할 필요가 없습니다.

Skybox
6개의 텍스쳐를 넣어 스카이박스를 만드는 쉐이더입니다만, 역시 Background 쉐이더를 사용하면 되기 때문에 패스.

Mobile / TKBG_Mineral_ipad

실제 사용되는 쉐이더중 가장 무거운 쉐이더입니다. (쉐이더만으로는 심지어 캐릭터보다 더!) 약 5g 으로 쳐드리죠.
외각이 일정 색상으로 반짝반짝 빛나며 애니메이션도 됩니다. 투명은 인식 안하고, 알파 채널은 외각 빛나는 부분을 컨트롤할때 사용됩니다.
광산이나, 특별히 이뻐야 할 인상적인 오브젝트에 사용하시면 되겠습니다. 단 폴리곤이 좀 있어야 외각이 제대로 나옵니다.

Mobile / TKBG_Water_ipad

물용으로 제작된 쉐이더입니다.

꽤 가벼운 편이며, 약 2 g 정도로 쳐드릴 수 있습니다.
텍스쳐는 한 장사용하고, 흘러가는 기능은 그대로입니다.
투명도를 조절할 수 있는 알파 조절자가 있습니다.
추가로, 버텍스 칼라로 투명도를 추가로 조절할 수 있기 때문에 부드럽게 사라지는 물도 만들 수 있습니다. 버텍스 칼라를 검은색으로 칠하면 사라집니다.

TKEffect 폴더 ===========================================

Mobile/TkEffect/TkEffect_FlowAdd_ipad

모바일용 플로우 쉐이더입니다. 대부분의 기능이 동일하게 들어가 있어서, 현재 제작된 모바일 쉐이더중에서는 상대적으로 무거운 편입니다. 그래도 파티클을 쓰는 것 보다는 훨씬 낫지만 말이죠. 약 4g 정도로 볼 수 있겠습니다.
두 이미지를 합해서 밝게 만들어 줍니다. 두 이미지는 각각의 UV 를 가지고 있습니다.
Rotation 기능도 가지고 있고, 버텍스 알파에 의한 투명도 기능도 있습니다. 거기에 tint 칼라까지 있으니… web용과 거의 같은 기능을 가진 쉐이더입니다. 상대적으로야 무겁지만, 걱정하실 필요는 없겠습니다.

Mobile/TkEffect/TkEffect_FlowMulti_ipad

두 이미지를 합하여 어두운 색으로 만들어 줍니다.

Mobile/TkEffect/TkEffect_FlowStandard_ipad

두 이미지를 합하여 보통의 결과를 내어 놓습니다.

Mobile/TkEffect/TkEffect_ParticleAdd_ipad

이펙트용 기본 쉐이더로, 이펙트 쉐이더중 가장 가벼운 종류입니다. 2g 정도.
Add모드로, 밝아집니다.
알파가 아니라 색상으로 투명도를 조절하기 때문에 TintColor로 전체 투명도를 조절할 수 있습니다.

Mobile/TkEffect/TkEffect_ParticleMulti_ipad

위와 마찬가지지만, 어두워지는게 특징입니다.
역시 알파가 아닌 색상으로 조절합니다.

Mobile/TkEffect/TkEffect_ParticleStandard_ipad

위 두 개와 다른점은 알파채널로 투명도를 조절한다는 것입니다.
밝아지지도 않고 어두워지지도 않아서, 연기같은 간단한 이펙트를 만들때 주로 사용합니다.

Mobile/TkMobile_Char_ipad

캐릭터용이라 매우 무거워보이지만, 사실은 가장 가볍습니다. 1g .
빛에 영향을 받지 않는 Unlit 쉐이더로 만들어져서, 주변의 라이트에 영향을 받지 않고 단지 텍스쳐만 보여집니다.
이것은 어차피 라이트를 거의 쓰지 않는 모바일의 특성에 맞추기 위해서입니다. 캐릭터도 매우 작고 말이죠.
알파도 사용하지 않고, 빛도 받지 않는 초 간단한 쉐이더.

Mobile/Unlit_Alpha_ipad

역시 매우 가벼운 쉐이더입니다. 아이폰에서는 알파에 대한 부담이 그리 크지 않은가 보네요. 1g
Unlit 쉐이더는 라이트 계산을 전혀 하지 않아서, 매우 가볍습니다.
알파 블렌딩 쉐이더입니다.

Mobile/Unlit_Cutout_ipad

Cutout 은 Alpha Testing과 같은 말입니다. 칼같이 알파를 떨어뜨립니다.
역시 가볍습니다. Unlit 이므로 라이팅 계산도 하지 않구요.

Mobile/Unlit_ipad

라이팅 계산을 하지 않고 텍스쳐만 보여주는 쉐이더입니다.
가장 가벼우며, 사실상 지금은 캐릭터 쉐이더와 완전히 동일합니다.

Mobile/Vertexlit

버텍스 라이팅 쉐이더입니다. 라이트 계산이 들어가기 때문에 약간 무겁지만, 그렇게 심하진 않습니다. 2g
빛 받는 느낌을 주어야 하는 오브젝트에는 이걸 사용하시면 됩니다.
뒤에 _ipad 접미어가 붙지 않은 이유는, 제가 만든게 아니라 기본 내장되어 있는 쉐이더이기 때문입니다.
그래서 전 건드린게 없어용.

Mobile/Vertexlit_Alpha_ipad

모바일 쉐이더용 버텍스라이트에서 알파블렌딩이 지원됩니다.
emittance 가 있어서, 과하게 어두워지는 부분을 좀 밝게 한다던가 발광하게 할 수 있습니다.

Mobile/Vertexlit_Cutout_ipad

모바일 쉐이더용 버텍스라이트에서 알파테스팅이 지원됩니다.
emittance 가 있어서, 과하게 어두워지는 부분을 좀 밝게 한다던가 발광하게 할 수 있습니다.

즉 건물이나 오브젝트를 제작하실 때에는 주로 Mobile/Vertexlit 쉐이더를 메인으로 사용하십시오.
만약 건물이 좀 투명한 느낌이라 살짝 빛나게 하고 싶으시거나 어두운 영역을 없애고 싶으시다면
Mobile/Vertexlit_Alpha_ipad 나 Mobile/Vertexlit_Cutout_ipad 쉐이더를 사용하셔서 Emittance 값으로 조정하십시오.
깃발이나 나무 등에도 위 두 개의 쉐이더를 사용하시는게 좋습니다.

만약 완전히 빛 방향과의 영향을 없애고 텍스쳐만으로 보이고 싶으시다면 Unlit로 시작되는 쉐이더를 사용하십시오. 이 쉐이더들은 철저하게 빛과는 상관없이 텍스쳐의 색상을 보여줄 것입니다. 아마도 갈대같은 식물류에 주로 사용될 것입니다.

이펙트에 사용되는 가장 기본적인 쉐이더는 Mobile/TK_Effect/TkEffect_ParticleStandard_ipad 일 겁니다. 이미지의 알파를 이용해서 투명하게 배경과 합성되지요.
그렇지만 불이나 마법 같은 고급 이펙트를 만들기 위해서는 TkEffect_ParticleAdd_ipad 나 TkEffect_ParticleMulti_ipad 쉐이더를 이용해서 밝게 혹은 어둡게 만들어 주어야 할 것입니다. 이 두 쉐이더는 알파를 사용하지 않습니다.

2부

Sun, 12 Jun 2011 17:33:52 +0000

2부는 드디어 퀘스트를 수락하고, 전투에 나서게 됩니다.

월드맵으로 나갔습니다. 다그닥 다그닥.

어라 근데 최상위 옵션인데 실시간 그림자는 어디갔나요?
그리고 워낙 넓어서 텍스쳐가 저해상도인거 이해는 하겠지만
왠 극한의 컨트라스트? 후처리 너무 심하게 넣은 것 같은데? 어두운 부분은 완전 새까맣잖아요!
월드맵 좀 더 이쁘게 해도 된다고 했을텐데

블룸수치, 컨트라스트 인헨시드, 칼라 콜렉션 모두 마을에서와는 전혀 딴판의 모습이군요. 이런 정도로 할 필요는없지 않나요?

포그 수치도 이렇게 진하게 하다니… 퍼포먼스를 고려해 주신건 고마운데, 이런 ‘안이뻐지는 짓’ 은 제가 하고 욕먹을께요 ㅋㅋㅋ
느려지면 제가 저런짓을 저지르고 욕먹을 테니까, 여러분들은 그저 이쁘게만 만드는 것만 신경써 주세요.

말타면 이름표도 올라가야 하는 것 아님? 머리 먹지 마셈.

그리고 월드맵을 너무 경사를 심하게 만든 곳이 많아서 , 말의 발이 심하게 떠있네요. 마을이나 던전에 비해 퀄리티가 너무 떨어져요. 후처리 신경 좀 더 쓰고, 실시간 그림자 켜고, 포그 수치 조정하고, 라이팅도 너무 크지만 않게 한 화면에 2-3개 쯤 보이게 박아도 좋구요. (적. 적당하게..?)

구름 흘러가기는 TS 팀에서 연구하고 있지만 너무 큰 기대는 마세요. ㅋㅋㅋ 이번주내로 결과 알려준다고 했던 것 같은데 아니던가? 월요일날 물어봐야지 ㅋㅋㅋ

던전으로 자동이동 해놓고 보니까 저기로 오네요.

저 산적들은 뭐하는 겁니까.
제가 가니까 일어나서 소고기를 노려보고 있어요.
제가 빼앗아 먹을까봐 먼저 먹으려고 그랬나 봅니다. 매우 어색하네요.

전투맵은.

우엑.
카메라 왜이래.

FOV가 너무 심해서 이펙트 왜곡이 엄청나고 끊어져 보이네요

건물에 노이즈가 끼었다 했더니 격자가 건물에 왜있는건데.

저 카메라 뷰에 기울어지지도 않으니 꽤 답답해 보이는게 정상일 겁니다.
저 카메라 뷰를 유지하려면 이펙트 방식을 바꿔야 해요.
지금처럼 하늘 높은 것들은 모두 이따만해질겁니다. 저 화면의 이펙트 처럼 말이죠.

세로로 더 화면이 올라가다보니, 기존에 잘 보이던 화살표 -> 둥그런 화살표가 안보이게 되었습니다.
그리고 저 위의 숫자는 왜이리 찌그러진걸로 보일까요.

그리고 에너지바가 심하게 작네요. 이것도 카메라 조정한 것 때문이겠지요?
이거 누가 한거지 … (김상무님이 했다고 난 말못함)
의견주세요. 이게 더 좋은지. 전 별로.

일단 첫 화면이 구려요. 좋게 봐서 저 이펙트가 없다고 봐도 , 내 캐릭터의 머리를 꼭대기에서 보는건 캐릭터 구별에도 별로 좋은 생각이 아니라고 봐요.

특히나 카메라를 접근했을때 각도의 변화없이 그대로 전진만 하다보니, 이렇게 굉장히 안이쁜 샷이 찍히게 되지요. 카메라를 근접하는 이유는 캐릭터를 ‘이쁘게 보기’ 위해서이고, 가장 적절하고 이쁜 캐릭터의 뷰는 ‘약간 쿼터뷰로 기울었지만 수직 각도는 약 25도 정도’ 되는 샷이죠. 덕분에 더욱 더 답답해 보이구요.

이펙트는 딴 건 모르겠고, 적군의 공격 이펙트가 (기본 이펙트) 굉장히 큽니다.
제가 이펙트 크다고 한건 이거였어요. 기본 공격 이펙트.
특히 타이밍이 왔다갔다 하는게 정말 이상하더군요. 내가 공격하는데 적군의 이펙트가 뜬다던가.

이건 제가 회의를 참여해 봐서 아는데요.

지금 몬스터 기본 공격 이펙트를 전부 몬스터에 붙이는 방식으로 제작중입니다.
좀 큰일이지만 할만한 일이고, 무식한 방법이 가장 편할때가 많아요. 퍼포먼스만 주의시키면 됩니다.

여전히 결과창은 미완성. UI 는 완성하고 폴리싱을 언제 할꼬.
울 회사 게임에서 늘 부족한 부분이 감성이라 하는데, 그 감성이란 UX 이고, UX의 대부분은 UI가 가지고 있단 말입니다.

뭐 어쨌건 퀘스트를 끝내고 돌아옵니다.

오다보니 도움말에 단축키 N이면 투명지도가 있다네요. 오오…
근데 단축키 N 으로 투명지도를 열고 닫는것까진 좋은데 퀘스트 창에서까지 이렇게 보여도 되나… 버그는 산넘어 산.

글씨에 색깔이 들어간다!
기능 추가도 좋지만 버그개선도 좀…

여차저차해서 유비도 만났습니다.

유비를 만난 것 까진 좋은데 갑자기 퀘스트 창이 사라지면서 저 창이 뜨니까 좀 놀랐습니다. 게다가 실수로 클릭해보니 어느새 캐릭터가 이동해서 지금 저 자리.

그리고 알 수 없는 거부 문구가 뜹니다. 여긴 어디? 그리고 저 문구는 뭐?
컴퓨터를 하면서 가장 짜증나게 하는 것 중 하나가 “알 수 없는 오류” 인 거죠. 비슷한 느낌입니다.

그래도 저는 익숙하니까 다시 유비를 찾아왔습니다.

유비 영입창은… 유비랑 만나서 퀘스트를 하는 그 창에서 띄워져야 하는 것 아닌가요?

유비 무서움!
불건전함!

불건전하다고!

그리고…

동영상 나옵니다.
아무래도 초반에 제작된거라 동영상 호흡이 너무 길어서 지루하네요.
말도 너무 많은데 게다가 천천히 말해…. 다시 수정해야 하지 않을까…. 초반에 이렇게 지루하면 어째요…

근데 여기서 장비 영입 타이밍에 대한 문제.
이건 유비가

좋소 근처 주점으로 갑시다!

할때 뿅하고 장비 영입 창이 떠야 하는 것 아닌가요?
그런데 어째서 점소이랑 얘기할때 영입하는 겁니까!!!!

< 저 버릇없는 시스템 메시지는 또 눈을 가리고…>

난 점소이를 장수로 영입하는줄 알았단 말야.

사과해도 소용없다.

<거 봐 점소이를 영입한거 맞잖아. jpg>

또 하나 느낀점.

점소이랑 얘기할때 첫 번째는 말을 안하더니 두 번째부터 말을한다. 오오 입이 트이셨다…
기적이다..

퀘스트 완료 사운드가 왜 어색했냐면…
이거 참 설명하기가 그런데..
맞는지 모르지만 퀘스트는 보통

제목클릭 –> 앞대사 –> 수락! —> 진행대사 —-> 완료! —> 완료제목클릭 —> 완료대사 —-> 보상!

제가 본 건 아닙니다만 뭐 대충 이런 식으로 이루어 지는데요,
수락! 의 타이밍은 기가 막힙니다.
수락! 하면서 퀘스트 창이 닫히고, 캐릭터가 보이면서 캐릭터 머리 위에 이펙트와 함께 사운드가 확실하게 뜨기 때문이지요.

제목클릭 –> 앞대사 –> 수락! —> 진행대사 —-> 완료! —> 완료제목클릭 —> 완료대사 —-> 보상!
뾰로롱!!!

하지만 종료는 어떻게 할까요?

어디서 뾰로롱 떠야 할까요?

제목클릭 –> 앞대사 –> 수락! —> 진행대사 —-> 완료! —> 완료제목클릭 —> 완료대사 —-> 보상!
뾰로롱!

현재는 이 뾰로롱이 보상! 에서 뜨고 있습니다.
일견 문제 없어 보이지만,

문제는 이 보상이 그냥 단일퀘가 아니고 연퀘일때…
보상이 되면서 다음 퀘스트의 앞대사로 바로 연결된다는 것입니다.
이런경우에는 어떻게 되냐고요?

완료제목클릭 —> 완료대사 —-> 보상!과 함께 다음 퀘스트 앞대사 —> 수락
뾰로롱!!!

가 된다는 거지요. 자동으로 다음 퀘스트를 수락한것으로 나오니까요.
이론적으로야 맞지만 , 느낌으로는 하나를 끝냈다는 느낌이 정확히 나질 않습니다.

즉 유저들은 퀘스트가 하나 끝났다는 느낌보다 그냥 죽 스토리가 이어진다고 생각하고 있는데 대사 중간에 완료 뾰로롱이 뜬다는 겁니다. 덕분에 퀘스트가 끝났긴 끝난 것 같은데 어디서 끝났는지는 잘 모르겠는… 상태인거죠.

해결책은?

그냥 둔다 : 사실 뭐 엄청나게 심각한 일도 아니니 그냥 가는게 맞을 수도 있습니다. 모든 경우에 어색한 것도 아니고 말이죠.
‘완료’ 시에 뜬다. : 사냥때는 그럴듯한 느낌을 줄 수 있습니다. 마지막 한 마릴 잡을 때 주인공의 머리위에 이펙트가 뜨고 소리가 날테니 말이죠.
완료제목 클릭시에 뜬다 : 이것도 그럴듯 합니다. 완료제목을 클릭하는 순간, 끝났다는 느낌- 청량감- 을 줄 수 있기 때문이지요.
둘 다 대사 중간에 생뚱맞게 완료 사운드가 뜨는 것보다 낫습니다.
어떻게 하실지는 UI 담당자 맘대로…

오늘의 분노의 철없는 글질은 여기서 마칩니다. 다음에 또 할께요. 기대해 주세용용용용용요요
배려없이 험하게 글썼다고 너무들 실망하거나 화내지 마시고 ㄴㅇ

자 그럼
맘에 드신 분은

내놔.

삼품테스트 이번주 (1부)

Sun, 12 Jun 2011 17:12:27 +0000

일단 최적화 상황

: 현재 권장사양에서는 매우 훌륭한 프레임으로 플레이가 가능합니다. 오히려 권장사양을 좀 낮추어도 되지 않을까 싶을 정도로.: 그에 반해 최저사양은 매우 심하게 느립니다.. 일단 명근팀장이 옵션 메니져를 코딩중이므로, 이를 완성한 후 옵션별 최적화를 시키고 나서 다시 테스트 해보는 것이 필요할듯 하네요. 현재는 텍스쳐 저해상도와 후처리 효과, 라이트 계산등에서 저사양옵션이 가동되고 있습니다만 원거리 컬링, 일정 이상 캐릭터 심볼로 교체, 캐릭터 메쉬 lod, 저사양 쉐이더로 교체, 터레인 옵션 변화 등 아직도 최저사양을 위해 할 일이 많이 남아 있으므로 속단하기는 이르다고 보입니다.; 특히 최저사양에서는 로딩이 매우 심각하게 느렸습니다. 현재 박실장님 테스트중입니다. 단 , 테스트 컴퓨터의 하드웨어 문제일 수도 있으므로 조각 모음, OS 재설치 등 이후 다시 테스트 해보는 것이 필요하다고 보입니다.

주말 삼품 테스트 일기.

테스트도 매일 해서 잔소리를 늘어 놓으면, 듣는 사람도 지겹고 글도 읽고 싶어 지지도 않고

무엇보다 테스트 하는 사람이 어느새 익숙해져서 “원래 그런거지 뭐” 라는 느낌을 받을까봐 일주일에 한 번씩 정도 까칠하게 테스트 해 봅니다 :)

일단 버그 리포트도 아무 감흥없이 한 줄 씌여 있으면, 무슨 문제인지 제대로 전달 못하고 흐지부지 되는 경우를 많이 봐왔단 말이죠. 그래서 다소 귀찮지만 감성적으로 (라고 쓰고 감정적으로라고 읽는다) 써 봅니다.

대충 하는것 같아 보여도 할 때마다 큰맘먹고 하는 거예요. 쓴소리 하는 사람도 마냥 기분좋지만은 않음 . ㅋ
열심히 하시는거 다 알지만 그렇다고 좋은소리만 너무 해도 안좋아요.
감정있는거 아니니까 진짜 아우.

집에서의 컴퓨터로는 로딩시간이 10초 내외로 걸립니다. 전에 다운로드 받은게 있어서 그런건가요? 하여간 뭐 걱정없습니다.

오늘은 특별히 김좀비님의 요청도 있고 하니 사운드도 켜놓고 함께 봅니다.

크게 틀어놓지는 않습니다. 집에서 할 때나 PC방에서 할 때는 아무래도 주변 잡 사운드 / 질낮은 스피커 / 가족들에게 민폐 / 등의 이유로 크게 틀어놓지는 않겠지요. 싸구려 2.1 채널 스피커에서 들리는 음악은 꽤 괜찮은 사운드를 들려줍니다.
그렇지만 조금 아쉬운 점이라면 이정도…?

로그인 시의 음악은 짧게 듣더라도 자주 들으며, 몇 년 동안 듣기도 합니다. 때문에 시작할 때에 이미 유저의 마음을 원하는 느낌으로 만들, 좀 후킹스러운 음악이어야 한다고 봅니다. 함축적으로 게임 세계를 설명해주며, 누구나 길거리에서 스쳐 들어도 게임이 생각나는 그런 음악이어야 한다고 말이죠. 그것도 초반 몇 초 안되는 시간안에 말입니다 :)
개인적으로 그라나도 에스파다의 로그인 피아노 음악은 듣자마자 그대로 외워질만큼 강렬하고 신선했으며, 깔끔하게 게임의 이미지를 전달하고 있어서 무척 이상적인 로그인 음악이었다고 생각하고 있습니다. (실제로 인터넷을 돌다보면, 가끔 잔잔한 영상의 브금BGM 으로 사용되는 경우가 꽤 보이지요) 어려운 일이지만, 저는 이 음악이 게임의 인상을 결정하는 최고의 음악이고, 유저에게 강렬한 인상으로 남는 음악이었으면 합니다.
신선한 악기로 새로운 느낌을 준다던가 하는 방법은 어떨런지요?
동양적인 느낌의 음악을 어째서 배제하였는지는 저번에 들어서 잘 알고 있습니다만, 덕분에 다소 삼국지라는 이미지와는 동떨어지는 느낌이 된 것은 아닌가 싶습니다 그러니까 이런 경우는 동양 악기를 포인트로 사용해서 서양풍의 음악이지만 약간 독특한 느낌을 주게 한다던가? 예를 들어, 가야금인가 거문고로 연주한 캐논 변주곡 꽤나 멋지고 신선했던 것처럼 말입니다.

- 멋진 화면이긴 합니다만 확실히 예전에 만든 이미지라, 지금 수준에서 보면 좀 떨어져 보이는 것도 사실입니다. 게임은 만들수록 사람 눈이 높아지고 실력도 좋아지고 엔진 적응력도 좋아져서, 초반 작품보다는 후반 작품이 늘 퀄리티가 좋지요. 지금 워낙 바빠서 어쩔 수 없는 것 알고 있습니다만, 나중에 조금 여유를 부릴 수 있으면 한 번 바꿔 주는 것도 좋을 것 같습니다. 사람 눈이란 간사한 거지요.

군주생성 해보려고 캐릭터 지웠더니 다시 안만들어 지네요. 산아야! 디비 매일 날리는거 아니었냐!!! ㄷㄷㄷ
내 개발자 J 를 돌려줘 OTL
할 수 없이 서브케인 개팔자J 로 들어갑니다. 여전히 캐릭터 생성할때 글씨는 한 템포 늦게 써집니다. 완성형인듯. 코딩 프로그램에서도 저렇게 되지요. 저거 누가 신경 쓰고는 있는 건가요? 나중에 고칠 수 있는 건가요?

그리고 인터페이스가 … 이 부분에 한해서는 꽤 퀄리티가 떨어지네요. 내용 의미없는건 그전에 말했고…
이 부분의 디자인은 눈이 높아져 그런지 좀 불만이네요.

또 저 공지사항 메세지 여전히 너무 중간부터 시작되는 느낌이 없지 않습니다. 좀 위로 올려야 겠다고 생각..

-사실 처음에 볼때는 웹게임인데 이정도면 대단하지. 라는 느낌으로 바라봤던게 사실입니다. 그렇지만 게임을 만들다 보니 웹게임이라고 퀄리티가 안나오는게 아니더란 말이죠.
캐릭터 변신할때 오색찬란한 파티클도 좀 더 심플하게 만들면 어떨까라는 생각이 듭니다.

일단 저랑 가장 비슷하게 생긴 녀석을 찾다보니 이녀석을 선택하게 되었습니다 (…자폭…)
어쩐지 이녀석 얼굴에 비친 조명은 굉장히 분위기가 잘맞는다고 할까, 다른 캐릭터보다 훨씬 입체적으로 보이는데, 뭔가 폴리곤이 많다던가..?

그렇게 해서 세컨캐인 개팔자J 가 완성되었습니다.
개팔자J 캐릭터도 못만들면 어떻게 하나고요? 그 다음은 상팔자J 랍니다 :)

- 이렇게 캐릭터를 간단하게 만들고, 게임에 들어갔습니다. 테스트 때에는 저기에 캐릭터가 약 20명 정도 모여 있었지요. 권장사양에서는 좋은 프레임을 보였었습니다. 적어도 50명 정도 모인걸 보고 싶네요.

저 미니맵 참 보기 싫네요. 언제 제대로 되나요?
어쨌건 게임에 들어갔을때, 뭘 해야 할지도 모르기 때문에 저렇게 눈앞에 “누르고 싶게 생긴 것"이 있는 것은 매우 중요합니다 .

그렇지만 말이죠. 걱정되는게 없지는 않아요. 다행히 npc 근처에 접근할 수는 없지만 지금 말풍선이 대단히 크게 제작되고 있던데요, 이 말풍선이 npc 를 가려버리게 되지 않을까요? 가로 사이즈 제한도 없던데, 지금은 생겼나요? 테스트해볼걸 그랬네요.
(테스트 해봤더니 이거 뭐 무한정 길게 써지네요… 계속 이렇게 크게 할 것인지? 줄바꿈은 안만들 것인지? 제한은 없는지?)

최고로 접근한 스샷입니다. 이름이 절반쯤 잘리는데, 별로 보기 좋지 않아 보입니다만. 이름표를 내리던가 카메라 각도를 바꿔야겠지요.

-여기서 생각해야 할 것이 저 캐릭터 이름의 사이즈입니다. 일부 게임은 어떤 뷰가 되더라도 캐릭터 이름표가 동일한 사이즈로 나오게 되어 있는 게임이 있고, 어떤 게임은 지금 우리 게임처럼 접근하면 커지고 멀어지면 작아집니다. 둘다 장단점이 있기 때문에 어떤게 좋다고 말하긴 힘든데요, 어쨌건 우리는 지금 근접하면 커지는 이름표를 채택하고 있습니다.

그런데 NPC는 또 특이하게도 , 멀리 있으면 커지는 이름표네요. 나쁘지 않군요. 캐릭터도 그렇나요? 캐릭터도 그렇게 하면 , 최고로 카메라를 근접시켰을때 작아질 것 같네요.

- 또하나 , 보통 카메라를 최고 줌아웃 했을 때 가장 넓게 혹은 멀리 보이는 것이 상식입니다만 우리 게임의 카메라뷰는 현재 중간 정도로 했을 때 가장 넓게 보입니다. 어째서 이 정도 뷰를 가장 줌아웃했을때로 하지 않았는지 궁금하네요 임ad ?

이 정도가 가장 줌아웃했을 때지요. 원래 제가 잡았던 최고 줌아웃보다 좀 더 가깝게 변해있습니다.
원래 목표는
‘줌인하면 다이나믹한 뷰로, 그렇지만 너무 넓게 보이진 않고 캐릭터가 크게 보이게 - 캐릭터가 이쁘게 보일 수 있도록’
‘줌아웃하면 공간감각이 조금 좋지 못한 여자들도 쉽게 위치를 인지하고 주변 상황을 파악할 수 있는 , 안정적인 아이소메트릭 스타일의 뷰로’

였습니다만 지금은 의도가 약간 애매해 보이네요. 뭐 ad의 권한이니 느려지지만 않으면 저야 상관 없습니다만 ㅋㅋ

그리고 여전히 카메라를 돌리다가 마우스가 저 채팅창 쪽으로 가면 마우스 컨트롤을 잃어 버립니다.
채팅에 신경쓰지 않을때에는 채팅의 백그라운드를 투명하게 한다던가 하는 등의 UI 컨트롤도 필요합니다만 전혀 되어 있지 않군요.
단언하건데 지금 게임에서 가장 늦은 부분은 UI라고 할 수 있습니다.

마을 음악은 개인적으로 꽤 마음에 드네요. 약간 디즈니 영화 음악같은 느낌? 역시 동양 악기 (똥그랑 땡땡 소리나는 ㅋㅋ ) 좀 포인트로 섞어주면 어떨까라는 생각이..

위에 새로운 인터페이스가 뭔가 생겼네요. 버튼이 세개군요. 뭔가요저거? 말풍선도 없고…

첫 번째 것은 자동이동 명령버튼입니까?
두 번째 것은 무엇?
세 번째 것은 퀘스트 리스트입니까?

작동되는 것은 두 번째 버튼 뿐입니다. 퀘스트 정보네요.
근데… 두 번째 버튼을 다시 한 번 누르면 닫혀야 한다고 몸이 말하고 있는데, 닫히질 않네요. 이런 작은 배려가 아쉽습니다.

그담에 또하나 인터페이스의 문제점을 보죠. 현재 ‘진행중인 퀘스트’ ‘진행 가능한 퀘스트’ ‘완료된 퀘스트’ 세 개의 버튼이 있는데, 어떤게 눌린 버튼인지 알아보실 수 있나요?

이 문제는 채팅창에도 동일하게 나타납니다. 현재 무슨 버튼이 눌린건지 맞추신 분에게
제주도 2박 3일 노숙 이용권을 드립니다. 단, 우천시에만 사용 가능합니다.

아잉 그러지 말고.

UI 디자인 말고 기능도 제대로 동작하지 않는 것들이 꽤 보입니다. 예를 들어 게임종료 버튼은 전혀 동작하지 않습니다.

캐릭터를 새로 만들고 싶어서 게임을 종료하려 했는데 말입니다. 결국 익스플로어의 X 버튼으로 눌러 게임을 껐습 …
아니 잠깐, X 버튼을 누르면 바로 꺼지게 할겁니까? 정말로? 괜찮습니까? 물론 웹게임이라 할말은 없습니다만,
실수로 X 버튼을 눌렀을때 일언반구의 물어봄도 없이 게임을 꺼도 괜찮은 건가요? 한 번 물어보기라고 해야 하는 것 아닌가요?
기술적으로 불가능한가?

뭔가 갑자기 꺼지니까 이런 느낌.

로딩창 후처리는 조금 생각해 보심이 ㅋㅋㅋ 무서워요.

두 번째 캐릭터는 아까 말씀드렸듯이 상팔자 J 입니다. 이거마저 막히면 뭐하지..

근데 이 캐릭터가 말입니다. 서서 있을때는 이렇게 도를 들고 있다가…

이동할때는 팔을 들어 도를 어깨에 걸칩니다. 이동할때마다 번잡스럽게 팔을 들었다 놨다 하니까 좀 이상하네요. 보통 이럴땐 처음부터 어깨 위에 올려놓거나,이동시에도 내리고 다니는게 좋지 않을까요.

걷는 것 상당히 귀엽 …

첫 퀘스트를 받는 곳까지 왔습니다. 여전히 저 마크는 이해불가이며, 첫 번째에 기능메뉴가 있는 것도 마음에 들지 않습니다.
좌우가 너무 넓어 비는 것도 마음에 들지 않구요.

이젠 결국 “외워서” 아래 있는 메뉴를 먼저 선택해야 한다는 것을 압니다.
의용병 모집이 늘 쓰이는 메뉴가 아니라면, 그냥 의용병 대장한테 가서 때가 되면 자동으로 이벤트 창 열리고 만명 주면 안되는 건가요? 굳이 메뉴를 독립시킨 것은 제작의 편의성 그 이상도 아닌 것으로 보입니다.

묘하게 줄이 안맞는 것도 신경쓰임.
그리고 인터페이스 사운드가 주로 책을 넘기는 사운드인데, 저 장면에 책장을 넘기는 소리는 전혀 맞지 않네요.

오늘 저 좀 묘하게 까칠해요. 이해해 주세요

일일히 이런데 성질내면 안되는데… 오래 못사는데…
아니 그러니까 까칠한 유저 빙의모드라니깐요…

그러니까 위에서 말한, 시스템 안내 메시지가 너무 낮다는 얘기는 이런 거예요.
지금 ‘의용병을 모집하기” 라는 안내 메시지가 불투명 메시지인데, 지금 화면에 보이는 저 자리가 두 번째 자리입니다. 즉 첫번째 나타날 때는 더 아래 있었단 얘기. 글씨나 캐릭터가 백그라운드에 나타났을때 너무 적나라하게 가리는 자리입니다.

UI 쪽 안된게 많은데 이거 한 달 안에 가능해…? 라고 묻고 싶달까요.

퀘스트를 받을때 도움말 같은 것이 뜨네요. 저런거 좋아요.
근데 선도 거칠고 창도 안이쁘고… (꼭 파워포인트로 만든것 같네요)

퀘스트 창은 디자인도 미완성이고 내용도 전혀 쓸모없이 연결되어 있네요. 이건 뭐 아직 안만든거라고 생각하겠습니다.

퀘스트 완료 소리. 들어갔네요.
퀘스트 받는 소리도 들어갔군요! 퀘스트 받는 소리는 퀘스트 이펙트와 함께 뜨니까 공감백배!!! 잘 어울립니다.

그런데 완료는… 으음… 뭔가 좀 안어울리는 느낌이네요.
왜 그럴까요? 사운드도 조금 부족하지만 그것보다…

아아 알겠습니다. 타이밍 문제입니다.. !!!
이유는 알겠는데 해결책이 좀… 거시기 하네요. 쓰기도 뭐하고. .

퀘스트를 계속 받습니다. 저 노랑 라인이랑 말풍선은 투박하지만, 눈에는 일단 잘띄네요.
조금 있다 단축키 I를 누르라고 하지만, 우리 단축키는 전부 한글 모드에서 안됩니다. 치명적이네요 알고 계시겠지요?

뭐 인터페이스 창들의 소팅도 아직 문제가 많고…

UI라는게 보통 잔손이 많이 가고 귀찮고 꼼꼼해야 하는 것이 아니예요.
정말 짜증날정도로 할일이 많은데, 그것 모두가 물흐르듯 스무스하게 넘어가지 않으면 또 안된단 말이죠.
인터페이스에 손을 많이 대는데, 인터페이스가 없는 듯 느끼도록 만들어야 하니

드릴 말씀이라고는

이것밖에..

내가 해봐서 아는데, UI는 정말 게임을 통채로 이해하고 관리하고 있지 않으면 잘 만들기 힘듭니다 진짜.

어쨌거나 인터페이스에 대한 불만글질은 계속됩니다.
퀘스트가 끝난게 언젠데 (뒤에서 번쩍 하더군요 . 퀘스트가 끝나면 저 창은 닫아주던가..)
안내 도움말은 여전히 떠있습니다.

난 네 글이 삐뚤어진 모양새가 안갖춰진것 같애.

역시 퀘스트 정보창은 쓸모없이 넓기만 하고.

좀 있다가 열어봐도 그대로. 헐헐.

1부 결론 : UI 에 시간이 많이 들어갈 것 같습니다. 이 속도면 곤란할 것 같은데요. 훨씬 더 빨리 하지 않으면 큰일나겠습니다.

AutoTexFind_ChangeShader 스크립트

Fri, 10 Jun 2011 16:55:28 +0000

만들어서 테스트까지 끝내놨는데 어셋서버랑 6층 무선랜 문제로 오늘 하루종일 제대로 뭔가 할 수가 없었다능..

모바일 같은 경우는 과도기인 관계로, 제작할때 뭔가 뒤엎어야 할 일이 가끔 생기기도 합니다. 그럴 경우에 쓸모있는 스크립트인데요,

기능은 ‘선택한 녀석의 A라는 쉐이더를 B라는 쉐이더로 자동으로 바꿔준다’ 라는 기능입니다. 하위구조까지 돌면서 전부 다요.

자주 사용될 녀석이 아니고, 거의 한 두번 특별한 관리자에 의해 사용될 기능이므로 하드코딩으로 해 놓았습니다.

실행방법은 간단합니다.

현재는 Legacy Shaders/Diffuse Fast 쉐이더를 자동으로 Mobile/VertexLit 쉐이더로 바꿔주도록 되어 있는데요.

이렇게 Diffuse Fast 로 되어 있는 녀석이 있습니다.

맵 전부를 체크해서 저 쉐이더를 모바일버전 vertexLit쉐이더로 바꿀 예정이므로 Ctrl+A로 전부 선택해 줍니다.

Auto TexFinder_ChangShader 스크립트를 찾습니다.

아래 버튼은 건드리면 안됩니다. 큰일나요.
윗쪽 버튼이 삼품 전용 버튼입니다.

누르면… 잠시 후

이렇게 쉐이더가 바뀌어 있음을 알 수 있습니다.

아직 커밋 안됐습니다. 서버에 문제가 있어서.. 서버에 올린 후 팀장님하고 말해서 처리하도록 하지요.

AutoTexFind_ChangeShader 스크립트

Thu, 09 Jun 2011 17:53:54 +0000

두 개의 기능이 동시에 들어가 있는 스크립트이지만, 하나는 삼품용이라 AT2용 - 성환파트장 전용-
스크립트만 설명하겠습니다.

이 스크립트는 자동으로 모델의 텍스쳐를 찾아주는 스크립트입니다.

일단 스크립트를 실행시키시면

이런 창이 열립니다. 안이쁘다고 뭐라 하지 말기.

위 버튼은 누르면 안됩니다. 삼품 모바일 용이예요

아래 버튼만 사용해야 합니다.

그리고 이런 캐릭터가 있습니다.
자동으로 텍스쳐를 찾아주지 못한. 그리고 쉐이더도 맘대로인…

그리고 이 FBX 파일 (또는 맥스 파일도 상관없습니다 ) 가 있는 폴더에, 텍스쳐를 넣어두세요.

이렇게요.

주의할 사항. 파일 이름은 하이어라키 이름과 같은 텍스쳐이어야 하고, tga 파일이어야 합니다.
위에 얘기했듯 같은 경로에 있어야 하구요.

그 다음은 간단합니다. 캐릭터를 선택하세요.

그다음 Find Texture 버튼을 누르면, 자동으로 하위구조까지 돌면서,
캐릭터 쉐이더를 찾아 적용해 주고 텍스쳐까지 찾아줍니다.

짠.

손하고 두건은 네이밍이 틀려서 적용되지 않은겁니다.
이렇게 안된 것이 있을 때에는, 콘솔창에 메시지를 띄워주게 되어 있습니다.

이렇게요.

커밋되었습니다.

삼품테스트 6월7일자

Tue, 07 Jun 2011 18:13:23 +0000

전체적으로 조금 느려짐.
무기 바꿀때 무기의 기본형이 저 멀리에서 잠깐 나타났다 나옴
탐욕형 걸을때 - 서있을때 블렌딩이 너무 느리며, 손은 앞으로 가는데 무기는 뒤로 간다! - 도-
프레임은 좋다.
캐릭터 나올때 멈칫한다. - 새로운 캐릭터를 로드할 때로 보임.
테스트 하는데 과자도 안준다
전투로딩시에 첫 화면에 물이 보인다 .
카메라 시점을 마지막 전투했던 시점으로 바꾸자. 맨날 그것만 한다.
첨부터 너무 화려하고 큰 이펙트.
이름 쉐이더에 레이어나 테그 만들자
점소이좀 영입하지마 -_-;;
한글 모드에서 이동 안됨.

삼품 테스트

Mon, 06 Jun 2011 16:14:53 +0000

오늘도 역시 집에서 ,
까칠하고 예의없고 세상에 불만 가득한 유저를 빙의해서 게임을 플레이 해 봤습니다.

앞 부분을 주로 하는 이유는 전에도 말했지만 첫째로 제가 끈기가 없으며 -_-;;
둘째로 대부분의 유저들이 초반 10분을 버티지 못하고 빠져나가기 때문입니다.
초반 10분에서 중요한 것은

유저에게 짜증을 내게 하지 않는 것
과
게임의 핵심 재미를 느끼가 하는 것
입니다.

거시적 게임성은 많은 분들이 보고 계시니까
전 제가 좋아하는 초반 게임성에 대해서…

일단 로그인 부분은 이제 무난하게 잘 넘어 가는군요. 그렇게 오래 걸리지도 않고 말이죠. 역시나 이번에도 기존에 만든 캐릭터는 사라져 있군요. 뭐 괜찮습니다. 계속 처음부터 할 생각이었으니까.

여전히 글씨는 한 글자를 다 쓰고 다음 글자를 써야만 나타나네요. 참으로 불편불편.

직업 선택에서 5가지 무기가 있는 듯 한데… 솔직히 5가지 무기가 뭐가 다른지 모르겠습니다. 설명에는 그냥 ‘그 무기를 써서 잘싸워라!’ 라고 씌여져 있고, 그 옆의 표는 도대체 뭘 의미하는 겁니까? 예를 들어 정치력이 높아지면 뭐가 좋나요? 지력은 마법에 관련되어 있나요? 그럼 도가 지력이 최고인 이유가 뭔가요? 무력은 왜 또 두개인 겁니까?

전 도라고 그래서 한쪽 날이 있는 칼을 의미하는줄 알았더니 창에 가까운 무기네요. -_-; 그래서 아무 생각 없이 골랐다가 창 무기 캐릭터인줄 알았어요. 창과 도는 뭘로 구별해야 할지 모르겠어서요.

다른 종류의 캐릭터로 바꿀때 나오는 오색 파티클은 묘하게 퀄리티가 동떨어지네요.

그리고 이 아저씨 목소리는 상당히 안어울리는군요. 뛰는것도 좀 사뿐사뿐 느낌이고.

이제 게임에 들어 왔습니다. 분명 게임이 시작되면 이 화면에 수백명이 (혹은 수십명이) 같은 자리에서 바글대고 있겠네요.
어떤 게임은 한 자리에 겹쳐서 리젠되는걸 피하고자 약간씩 좌표를 렌덤으로 하던 경우도 있었습니다.
그 쪽이 좀 더 나아보이긴 하네요.

미니맵은 수정하고 있는 중인가 보지요? 설마 저건 아니겠지.
이름은 회색인 특별한 이유가 있나요? 이름이 잘 안보이네요. 그게 목표였다면 또 모르겠지만…
행동력인 겁니까? 뭘까요 저거..

게임에 들어와서 바로 앞에 있는 NPC를 클릭했습니다. 과도한 동작은 사라졌구요.

그렇지만 여전히 저 UI는 알아보기 힘듭니다. 어떤게 퀘스트인지 알 수가 없어요. 익숙해지면 나아지겠지만, 어쨌건 첨부터 의용병 모집부터 만명 해놓고 퀘스트를 진행해서 엉키는 상황이 많이 발생할 겁니다.

그런 얘기 한 적 없는데요. 전 여기 처음 왔어요. 제가 혼자 싸우는거 아니었나요?

거 봐 역시 혼자 싸우는 게임이지 (라고 생각했습니다)

커서 끝에는 뭔가 화살표나 반짝거리는 것이 있어서 클릭을 유도했으면 좋겠네요.
그냥 바탕을 누르면 된다고 하는데, 눌러야 할 것이 안보여서 대화 종료를 누르는 사람이 많을겁니다.
저도 대화 종료를 눌러서 게임 드라마를 2번씩 보곤 했었죠.

도와준다고? 뭔소리야?

그래놓고 괘씸하게 퀘스트가 생겼습니다. 아 놔 어떻게 하라는거야!!! 어떻게 도와준다고 말을 해야 할 거 아냐!!!!

결론은 의용병 대장을 한 번 더 클릭해야 한다는 건데, 이렇게 나왔다가 다시 가는건 자칫 흐름이 끊어질 위험성이 있습니다.
게다가 의용병 대장을 클릭해야 하는걸 의식하지 못할지도 모르고.

뭐 어쨌건 의용병대장을 클릭했더니

10000 명을 받았습니다.

… 어이……

무슨 광고카피도 아니고 “10억을 받았습니다” 라는 것처럼 비현실적인 숫자 “만명을 받았습니다”
여기서 정말 ‘아 병사를 만 명 받았다고 생각할 사람이 어디 있을까요? '

우리 회사 특징중 하나가 ‘디테일과 감성이 부족하다’ 라는건데, 여기서도 여실히 부족한 감성이 나타납니다.
어느 정도냐면요.

아래 게임을 보시죠
아이폰 게임에서도 한 캐릭터에게 음악을 만들어라 시키면
‘음악이 80이 되었습니다’ 라고 한 번에 나오는게 아니라

저렇게 뿅뿅뿅 하면서 수치가 올라가고, 그것도 컨디션에 따라서 수치가 렌덤이지요.

게임쇼에 제품을 출품할때도 마찬가지입니다. 어떻게 사람이 딱 만명이 옵니까. 그건 사람이 아니고 기계입니다

끝나고 나면 비서가 몇 명 왔다고 알려주면서 어쩌구 하지요.
딱 만 명 오지 않습니다.

그러니 사실 의용군 모집도 여기에 비교해 보면 굉장히 어설픕니다.
게임 드라마는 그렇게 섬세하게 만들면서, 의용군 모집은 여전히 군주때의 모습에서 벗어나지 못하고 있다니요.

그렇다면, 사실 이런 식으로 만들어야 하는 것 아닌가요
뭐 이렇게 선택하게 하면

다음 화면에서 격문앞에 웅성거리며 보고 있는 사람들.
그리고 의용군 지원병 숫자가 점점 올라가면서

8000~9000 명 정도에서 렌덤으로 멈춤.

그럼 뭐 이런 식으로.
8,495 명이 모였소! 이들이 당신과 함께 하고자 결심한 의용군이요!
그들의 결심을 헛되이 하지 않도록 하시오!

뭐 이런 식으로..

운 좋으면 9500명 모일 수도 있겠죠.
나중에 어떻게 될지 모르지만 또 병사를 모을때 돈을 지불하게 한다던가 하는 식으로 응용할 여지도 충분히 있잖아요?

뭐 어쨌건 보이지도 않고 느껴지지도 않지만 만 명이 있답니다. 그런줄 알아야죠 뭐.

이번엔 병사대기소를 열어 보랍니다. 가져다대면 말풍선이라도 나오면 좋을텐데요… 모르는 사람은 상단 메뉴가 있다는 것도 모를 테니까요.
이미 만들고 있는 것 같아 보이긴 합니다만…

병사 대기소도 지극히 무미건조.

아이템 사용은 오른쪽 클릭하면 되니까
‘몰라도 금방 알게되는’ 인터페이스였습니다.

그렇지만 - 아직 인터페이스 디자인 문제가 확실하겠지만 - 장비 창으로 창이 바뀌었는데도 거의 알아보기가 힘들어서, 저는 상자가 없어진줄로만 알았지 뭐예유…

저는 지금까지 제가 검인줄 알고 있었습니다. 쓸데 없는 아이템이 나와도 괜찮을까요?

퀘스트 도움말이 기획되고 있을거라는 증거. 하여간 너무 창도 크고, 보기 힘들어요.

전투화면입니다.

사정거리가 안되더라도, 적군을 클릭했으면 일단 최대한 가까운데로라도 이동했으면 좋겠네요.
지금은 클릭해도 반응이 없습니다.

역시나 또 10000명 얘기입니다만….
삼국지를 봐도 병사들이 있으면 그 병사를 숫자로 보여주지 않습니까?
나중에 알고보니 병사가 주인공과 함께 500여명이던것 같군요.
그렇다면 500이라도 작게 표시를 해 주는 것이 당연하지 않을까요.

지금은 500명의 병사라는게 HP 물약 취급이군요. (현자의 돌이냐)

자동으로 편성되는 창도, 아직 안만들어진게 확실해 보입니다만
맨 위에 남은 병사들의 그림과 숫자가 보이고… 그게 또르르르르 하고 줄어가면서

장수들에게 또르르르.. 하면서 채워져야 정상이겠지요?
이건 꼭 필요한 인터페이스라고 생각합니다. 안그러면 어떻게 진행되는지 알 수가 없어요

이번에 카메라 FOV와 각도를 바꾸면서 그림자 문제가 생겼습니다 줄무늬 문제는 늘 골치아픈데요. 카메라를 조금 바꾸면 이 문제를 케이스 바이 케이스로 잡아나가야 합니다. 배경팀에 말해야 겠네요

그리고 카메라를 최대로 당겼을때 너무 멀리 보이는군요. 그 때 보여줬을때는 잘 인지하지 못했었는데, 지금 보니 굉장합니다.
퍼포먼스에 많은 영향을 끼칠 듯 하니 당장 거리 컬링 기능을 넣도록 해야겠네요.

그리고 전에도 말씀드렸지만 영웅형 장수 머리쪽에 줄갑니다.

점소이를 만났을 뿐인데, 장수 영입 창이 뜨네요. 이건 뭐임? 점소이를 영입하는 거임?

드라마를 안보고 넘기면 퀘스트 내용을 알 수가 없습니다. 물론 넘기면 안좋은거 알지만 적어도 안봐도 게임 진행이 가능하게는 해야지 않나요.

술 한잔을 사용하래서 버릇처럼 더블클릭을 했더니 마을을 뱅글뱅글 돌아다니는 주인공.
수정해야 할 것으로 보입니다.

나름 턴제 전략 게임인데, 뒤에서 공격하면 !! 마크가 뜨면서 크리티컬이 된다던가, 반격을 못한다던가 하는 기능이 있음 좋을 것 같습니다.

얼굴이 좀 어두운듯. 카메라쪽에 라이트를 박아야 하나… 고민됩니다.

NPC랑 얘기할 때, 이벤트가 발생했을때 저렇게 메세지가 나오는데
처음에 나오는 부분이 거의 NPC의 눈을 가리거나 이마 한 가운데입니다. 위치를 좀 수정하는게 어떨까요?

얘기를 하면서 보니까 유비도 나오고 장비도 나오고 막 막 나오는군요.
왼쪽 칸이 비는데, 거기에 대사하는 사람의 멋진 일러스트가 나오면 얼마나 좋을까요?

마우스를 저기다 가져다 댔는데 턴넘기기가 나오네요. 이거 왔다갔다 합니다. 저기는 사실 스페이스바로 다음 유저로라는 기능일텐데요.

ndc2011 전역 조명의 기본 이론

Wed, 01 Jun 2011 10:58:49 +0000

이건 사진을 찍었어야 하는 자료인데… 사진을 찍어도 되는지 몰라 안찍었습니다.
덕분에 글만 보고는 알아보기 힘든 내용이 되었지요.

저만 아는 (용우나 박부장님도 아시겠지만) 내용이 되었어유 ㅋㅋ

PT내놓으세요…
ㅋ

* 사진은 오즈라엘님 블로그에서 보세요 캭캭
http://ozlael.egloos.com/3662138

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

김혁 (넥슨)
넥슨 어니언팀

내용은 주로 기본적인 이론들에 대한 내용입니다.
대상은 글픽 프로그래머입니다.
궁극적으로 말하고 싶은건 연구하자라는 내용이지요

전역 조명(글로벌 일루미네이션)이란?

직접조명 + 간접조명을 의미함. = 글로벌 일루미네이션
게임에서는 간접조명을 쓰기 매우 어렵지요
-간접조명이란 주변 벽 등에 의해 영향받는 색상을 의미합니다. 현재 실시간으로 하기 힘들죠 . 보통은 그냥 엠비언트 칼라만 사용합니다.
일단 PRT 라는 방법으로 구현을 한번 해봤습니다.. 게임에서는 사용하기 힘들지요

그럼 어떻게 그동안 해결했었는가?

-레이트레이싱 . 좋기는 하지만 근래에 사용하기는 힘들지 않을까.
-레이트레이싱 . 눈에서 광선이 나간다고 생각해 보는 겁니다. 일반적인 것과는 반대로.
이것만으로는 전반사 외에 간접조명 구현이 힘듭니다.

-그래서 좀 더 사실적으로…하려면
일단 물체에 빛이 닿으면
흡수, 반사, 투과가 됩니다.

-흡수는 열 에너지가 되어 사라지죠
여기서는 반사만 보죠

-빛이 들어가면 여러 방향으로 흩어지는게 기본이죠. 비율은 물체마다 다릅니다.
반대도 마찬가지죠. 여러 방향에서 온 빛들은 모아져서 한 방향으로 들어옵니다.

-물체의 특성 . : 거울은 전반사만 되지요
-글로시는 전반사 비스무리하게.
-렘버트 디퓨즈는 사방에 균일하게 반사를 뿌리는데, 사실은 글로시와 중간 정도로 나가게 됩니다. 약간 전반사 스타일로 말이죠

BRDF
물체의 반사 속성을 수학적으로 정의한 함수

게임에서 주로 사용하는 함수는 퐁 모델
Modified Blinn - Phong모델

렌더링 공식
-들어오는 빛을 다 적분하면 나가는 빛이 된다. 이것이 렌더링 공식을 이용한 광선추적법
-고전적 레이트래이싱에서는 하나만 전반사만 계산하는데
렌더링 공식을 이용하면 빛을적분해서 난반사를 계산할 수 있다
-글로시에 유리하고, 디퓨즈에는 불리한 단점이 있다. 노이즈가 좀 나오지요. 광선추적법만으로는 이런 단점이 있게 됩니다.

두번째로.. 레디오시티

-모든 면은 렘버트 디퓨즈 이고 : 모든 방향으로 반사합니다.
폼 펙터로 , 다른 면에 몇 % 영향을 주는가를 먼저 계산하는것이지요.

-베틀필드에서 구현이 되었지요
(주: 맥스의 레디오 시티가 바로 이거죠)

세번째 포톤 메핑

포톤 = 빛 알갱이
빛 알갱이 입자가 사방으로 쏘고, 레이트레이싱 처럼 확률에 의해 표면에 붙게 되는 방식입니다.

포톤 뿌리기- 광선 추적법 렌더링-포톤 모으기 :주변의 포톤들을 모아서 렌더링함.
(맥스에도 이런 렌더러가 있죠. 뭐였지? 맥스웰이던가?)
광선 추적법의 장점을 이용 가능합니다.

정리
고전 광선추적법 : 전반사만 가능
렌더링 공식 : 디퓨즈 는 오래 걸림, 글로시는 잘됨
레디오 시티 : 디퓨즈만 가능
포톤 매핑 : 디퓨즈와 글로시 둘다 잘됨

위에까지는 오프라인 렌더링 기법이었고.. 이제부턴
실시간 렌더링 기법
을 봅니다

-라이트맵

레디오시티와 포톤맵핑 (일부) 를 라이트맵을 사용.
많은 게임에서 사용
정적인 물체. 정적인 라이트.
긴 전처리 시간
글로시 표현안됨. - 노말을 나오게 하려면 스페큘러와 글로시를 따로 가동시켜 사용해야만 함
즉 디퓨즈만 된다는 단점이.

라이트맵을 넘어서…
정적 조명 - 정적 물체 -정적 물체 –라이트맵 , sh 라이트

모든것이 동적이면 참 좋겠지만..
각 방식마다 장단점이 있습니다.

Spherical Harmonics Irradience and Ambient Cube

Irradience :
3차원 공간의 어떤 점이건, 주변에 환경맵이 있다고 가정할 수 있음
환경 맵을 반사 맵으로 쓸 경우
환경 맵을 디퓨즈로 쓸 경우 : 반구적분
간접조명만 계산한다면 좋음

Irradience 볼륨 :
격자를 하나하나 만들고 미리 환경맵을 베이킹으로 다 만들어 놓고. 그걸 인터폴레이션으로 사용

Ambient Cube
이라디언스 맵 대신 큐브맵만 달랑 계산 . 6개의 색만 계산합니다. 하프라이프2에서 사용
가장 가까운것 하나 가져와서 주인공한테 박았음
공간 보간이 아닌 시간 보간. 엠비언트 부스트 적용
엠비언트 큐브는 이라디언스보다 매우 적은 메모리 사용. 퀄리티는 좀 차이.

구면조화함수(Spherical Harmonics):

내일 최지현님 발표를 들어보세요. (어헝헝 나 내일 못듣는 다고요. 알고싶어 어려워 알고싶어 어려워 못들어 )

(으아…. 상대적으로 매우 가볍고 좋은 결과라고..
수학 공식만 간단하게 소개… 좀더 자세히 알려줘요…ㅠㅠ 개념적으로 쉽게..)

구면조화 함수를 이용한 이라디언스로 계산을 단순화
적분에 비하면 계산이 매우 적음
버텍스 쉐이더 안에서 계산해 버림
퀄리티는 이라디언스와 구별하기 힘들 정도.

(대충 이해가 갈듯 말듯. 그래픽 출신에게는 힘들어요. )

헤일로 3에서의 활용 사례

-포톤을 뿌려 SH( 구면조화함수) 라이트맵 생성
-렌더팜을 이용해 텍스쳐 생성

이걸 이용하니 범프맵이 없어도 범프맵 디테일을 살림.
라이트맵은 디퓨즈에만 영향을 준다. 스페쿨러와 범프를 같이 쓰지 않으면 효과가 없다. : 어떤 색으로 나가는지 저장
SH 라이트맵은 전역 조명으로 모두 영향을 주기 때문에 스페큘러와 범프를같이 쓸 필요가 없다. : 어떤 색으로 들어오는지 저장
(우왕 엄마 나 저거 사줘)

그래서? 우리도 연구를 하자. 양인들이 하는거만 바라보고 있지 말고.

우리도 겜브리오에 이걸 붙여서 개발중입니다.
-레이트레이서와 GI 엔진 코어, SH 엔진을 테스트 완료만 했습니다. 쓸지는 모르겠습니다. 아직 공개할 레벨이 아니예요
물론, 쉽게 사용할 수 있는 기능은 없습니다. 모두 장점이 있는가 하면, 그만큼의 단점이 있는 법이지요. 공짜 점심은 없는 법입니다

ndc2011 게임 프로젝트의 컨텐츠 관리툴 제안

Wed, 01 Jun 2011 10:57:54 +0000

언리얼 이펙트 툴 강연에서 이어지는 강연입니다. 역시 30분짜리라 좀 짧습니다.

컨텐츠 관리툴에 어떤 기능이 필요하고 어떤 기능을 만들었는지 사례를 소개하는 내용이었습니다.

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

목차
1 .게임 개발에서의 컨텐츠
2 .관리툴의 필요성
3 .컨텐츠 브라우저님 소개
4. 컨텐츠 브라우저님 시연

게임 개발에서의 컨텐츠
컨텐츠란 ?
배경 캐릭터 애니메이션 사운드 효과 등등을 의미합니다

맥스나 포샵들을 이용해서 컨텐츠를 만드시지요
그리고 그걸 그냥 쓰지 않고 가공하시지요

-매일매일 만드시지요
덕분에 엄청 커지고 복잡해지지요
찾고 관리하기 버겁구요
병목현상이 발생합니다.

-이미 만든 컨텐츠도 자주 변경과 업데이트 되지요
계속 백업과 히스토리 트래킹이 필요하게 됩니다

컨텐츠 관리툴의 필요성

-우리는 게임 개발 내내 컨텐츠 관리와 싸우게 됩니다

-시간 내내 싸워야 하지요
컨텐츠 관리가 망하면 지옥 아니면 야근으로 가게 됩니다
그래서 컨텐츠 관리툴이 필요하게 되는 것입니다.

컨텐츠 브라우저님 소개

-소스 컨텐츠를 게임용으로 임포트 하는 툴 제공
-종류별 전용툴로 자동 연결 제공
-자주 바뀌는 컨텐츠를 위해 쉬운 유지와 버전 관리
-컨텐츠를 빨리 찾기 위한 도움을 손길
-와우는 140만개의 어셋이 있다더라
-협업과 컨텐츠 버그를 미라 찾는 영험하신 기능

컨텐츠 브라우저의 시연

(시연을 보니 , 우와 유니티 컨텐츠 브라우저가 굉장히 직관적이고 좋은 툴이구나… 언리얼에 전혀 떨어지지 않는데…
대부분의 기능은 언리얼과 동등한 수준으로 가지고 있다는 것을 알게 되었습니다.
물론 좀 더 언리얼이 세부적인 기능을 추가적으로 가지고 있네요.
예를 들어 어셋 서버에서 디비관리 측면은 언리얼이 훨씬 더 멋진 기능을 가지고 있군요.)

테그 기능.
(테그 기능은 제작자가 신경쓰지 않으면 무용지물인 기능입니다. 하지만 좋군요. 큰 프로젝트에서는 꼭 필요하죠 )
리임포트 기능
그래도 만족 못하시길래
개인 컬렉션 기능 폴더를 넣었습니다.
자기가 원하는 컨텐츠를 자기 컬렉션에 집어 넣으면, 다른 사람에 영향 안받고 작업할 수 있는 폴더가 생기는 것이지요. 수많은 컨텐츠 브라우저 사이에서 자기가 만들던 것을 일일히 찾을 필요가 없습니다.
반대로 공유 컬렉션 폴더는, 같이 작업할때 쓰는 폴더입니다.
여러 어셋을 같이 나눠 작업할 때 쓰지요.
선 조치 기능
간단한 에셋의 버그를 컨텐츠 서버에서 자동으로 잡는 기능입니다.
예를 들어 라이트맵 uv를 누군가 안만들고 넣었다면,
그럼 서버가 밤에 2시에 자동으로 검색해서 찾아서 다음날 아침 디자이너에게 경고하고 선조치 시켜줍니다. 이거 문제 있다고 말이죠.

(뭐랄까 좋은 엔진을 선택하기 위한 체크리스트를 본 느낌이었습니다.ㅎㅎ)

ndc2011 수요일 세션 . 언리얼엔진 캐스케이드로 알아보는 착한 이펙트 툴이 갖추어야 할 삼강오륜

Wed, 01 Jun 2011 10:01:36 +0000

오늘은 오전에만 강연듣고 오후에는 회사로 리턴입니다. 오늘 테스트 있슈 OTL

사진촬영 해 놨는데 촬영 금지라네요. 그래서 올릴 수 없습니다.
근데 어떤 강연이 사진촬영 가능이고 금지인지 알 수가 없잖아요. 그래서 오늘은 아예 전부 안찍고 필기해 버렸습니다.
사진 편집 안하니 편하긴 하군요 (…)

언제나처럼 에픽게임즈 코리아 강성구 TA님.

이펙트 툴에는 어떤 것이 필요할지 알고 싶어서 들어와 봤습니다.
언제나 이펙트 지원은 늘 부족하게 느끼거든요. 쉐이더 지원은 어느정도 할 수 있지만…
이펙트 디자이너들이 필요한데도 미처 만들지 못하고 있는 것이라던가, 아니면 생각하지 못하고 있는 것은 아닐까 라는 마음에 들어와 봤습니다.

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

대상은 : 이펙트 아티스트, 툴 프로그래머 - 자체 개발이나 상용엔진 수정하시는 분

말하면 입 아픈
(주: 꼭 있어야 하는 기능입니다. 없으면 큰일나는)

맵툴/ 애니메이션 툴 /시네마틱 툴에서 배치및 실시간 프리뷰
(없으면 정말 안되는 기능이군요)
파티클 세트화
블렌딩 방식 설정
스프라이트 / UV 에니메이션
복사 / 붙여넣기
파티클별 / 기능별 끄고 켜기
메쉬 파티클
(유니티에서는 잘 되는 기능이군요. 기본적인건 잘 되지만 종합해서 컨트롤 하는 기능이 좀 약하긴 하지만 말예요. 그런대로 기본은 되어 있다고 볼 수 있겠군요)

있어야 하는
(주위 사람들이 그거 꼭 있어야 해? 라고 자꾸 물어보면 어? 없어도 되는거던가? 라고 착각하게 되는 기능이라고 하십니다)

키프레임 형식의 에디터
(그래프만 프리셋으로 주고 땡인 기능을 만드시면 안돼요. 이펙터는 키프레임이 꼭 필요합니다.)
변화의 조건 설정 : 월드 기준? 로컬 기준?
(변화를 하는데… 무슨 기준으로 변화할건지 선택 가능해야 합니다. 시간순이냐 거리순이냐 하는 것 말이죠)
커스텀 쉐이더 지원 / 쉐이더 상수 설정
(하이 퀄리티를 만들려면 커스텀 쉐이더 지원이 무조건, 반드시 필요합니다.)
LOD 설정

있으면 좋은

모듈 방식의 기능 추가
(지금 쓰고 있는 기능이 뭔지 한눈에 볼 수 있게 정리해 주는 툴 같은 것 말이지요. 이펙트는 워낙 여러 기능을 섞어 쓰니까요.
유니티는 컴포넌트 방식이라 이건 아예 기본으로 되어 있는 듯.)
-볼륨 파티클 등
(…. 이거 구현하고 싶…)

인간이 갖출
-감각
-하드웨어와 쉐이더에 대한 지식
-모르는것 틀리는걸 부끄러워도 숨기지 않는대인배의 마음가짐

광고 : 이펙트 툴이 부족할 때는 무료인 유디케이를 사용해서 만든다음 프로그래머에게 보여주세요 ~

(주: 다소 일반적인 내용의 정리라는게 조금 아쉬웠습니다만,
기본적인 내용을 정리한다는 입장에서는 명료하고 괜찮은 느낌의 강연이었습니다.광고도 적고 ㅋㅋ)

ndc2011 이비 제작 포스트모템

Tue, 31 May 2011 18:33:51 +0000

동영상 컨버팅은 귀찮아서 안올렸는데 오즈라엘님이 올렸뜸 ㅋㅋㅋㅋ
http://ozlael.egloos.com/3662497

그래픽 디자이너신 것 같은데 여러 분야에 참여하시는게 인상적 이네요
역시 사람은 자기 닮게 만듭니다. (퍽) 귀여우신 인상인듯

기본적으로는 애니메이터이신가..? 선임연구원이시라는데 … 이펙트와 애니메이션, 스킬 기획, PM까지 몽땅 하셨더군요.

물론 전부 그런건 아니고 이비는 특별했답니다. 특별해서 특별하게 제작공정을 특별하게.

이정도면 확실히 특이하죠.

두 가지 큰 특징은, 아주 구체적인 비전 명시와 빠른 프로토타이핑이었습니다.

구체적 비전 제시는 매우 구체적으로

그냥 추상적으로 말하면 아줌마파마가 나오거등요

두 번째는 스크립트 기반이라, 그래픽 디자이너가 코딩 도움없이 바로 프로토 타이핑을 해볼수 있었다는 말입니다 .
즉 엔진에 걍 돌려보고 테스트 할 수 있었다는 말.

위 2가지가 이비 개발할때 어떻게 적용되었냐면요.

이비 캐릭터 구축할때는요.

액션 요소는 최고였지만 , 액션 유저만 제한적으로 잡는다는 단점이 있었고 보다 넓은 유저층이 필요했어요

이런 성격의 캐릭터가 필요했죠

그래서 젤 나중 일정이었던 이비가 앞으로 튀어나오게 되었어요

동작 포지셔닝은 이렇게요.

이미지 포지션은 이정도로 뒀죠
섹슈얼은 아니고 귀여운건데.
어떤 귀여움이냐면

딱 집어 구체적으로 소녀시대 .

방향이 너무 구체적이어서 제한되더라도 그쪽이 낫습니다.
완전히 한 사람으로 정해 버리면 모션 구상 쉬워지거든요.

예를 들어 디즈니의 알라딘의 재스민은 : 똘똘한 외국인 교환학생이 이미지였고
이를 기반으로 모든 동작과 반응 형태가 정해졌답니다.

근데 애니메이션을 공용으로 사용하려니까 너무 아닌거라.
할 수 없이 이비의 애니메이션은 모두 다 다시 제작.

페이셜

사람은 본능적으로 얼굴에 집중
30개 이상의 표정을 지을 수 있다.이비는 …

배틀사이드란
2차무기를 말합니다. 이 무기를 들면 액션이 바뀝니다. 근접 캐릭터로.

(주: -글씨는 좀 커야겠네요. 안보여요)

이비의 특징이 유저의 바램과 충돌했기 때문이지요.

거기에 디렉터의 의견도 무시할 수 없고…
그래서 어쨌건 절충한 것으로 결정.

이렇게.

그래서 영상을 직접 만들어 담당 프로그래머에게 전달.

꾸꾸준한 프로토타이핑
상상과 실제는 다르지요.
맥스에서는 완벽해도 올려보면 조작감이 다른 거예요.
그래서 계속 해보기 전에는 모르지요

비용을 아끼기 위해서 러프한모션을 만들어 썼습니다.
이렇게 아예 설명이 포함된 동영상을 구체적으로 만들어 프로그래머에게 공유했지요.

이것 저것 동시에 다 하기 힘들길래
같은 음악을 한 곡만 10시간 들으면서 리듬을 바꾸는 요령을 썼습니다.

그래도 문제는 남아있고 배틀사이드로 막는건 한계가 있었습니다.

이걸 다 고치려면 캐릭터 근간부터 고쳐야..
그래도 지금 아니면 평생 못한다는 생각으로 뜯어고쳤습니다.

대개편

컨셉 키워드 :다양함
퀵슬롯을 많이 주던가 아예 필요 없게 바꾸자라는 것이었습니다. . 근간을 바꿈

차지(집중) : 기능 테스트

힐링 : 불편을 없애는 방향
한번 출항에 한 번이라도 힐링한 유저는 6-7% 였습니다. 너무 어려웠던 거죠.
그래서 설치형으로 변경하였습니다.

마나 앰버 : 생존기
…물리 엔진이라 각종 문제가 발생하고 말았습니다만.

어쨌건 액션을 위한 프로토타입으로 개선하였고, 여기에 스크립트를 적극 이용하여 프로토타입을 적극적으로 만들었습니다.

결과적으로 넉넉한 퀵슬롯. 업데이트도 쉬워지고…
다양한 마법도 업데이트 가능하게 되었지요.

결론을 내리면 정리하자면

1 구체적으로 비전을 명시했다는 것과
2. 꾸준한 프로토타이핑을 해서 문제를 해결해 나갔다는 것입니다.

어머나 용기와 열정 ㅎㅎ

넵 끝입니다.

(주: 중간에 동영상을 많이 보여주셨는데, 프로토타입으로 돌려보면서 이건 아닌것 같아서 이렇게 바꿔봤다.. 라는 과정이었습니다. 쉬운 프로토타이핑이 가능한 스크립트 구조는 확실히 액션게임에서 매우 중요한 것 같았습니다. )

삼품 테스트 후기

Tue, 31 May 2011 16:15:15 +0000

개인적으로 친한 삼품팀 사람들이지만
“친한 친구일수록 열라 까대라” 라는 고자의 가르침을 바탕으로 좀 까보자면.

권장사양 테스트는 내일 할 예정이므로 오늘은 그냥 게임 진행에 대한 이야기입니다. 하면서 느낀점을 요약해 볼께요. 역시나 매정하게. 아주 매정하게.

-첫 로딩은 38초.
꽤 좋은 컴퓨터지만 아무런 데이터도 미리 받은적이 없다는 (심지어 처음 접속해봄 이 컴퓨터에선) 점에서는 납득할 수준.
-위 글 두 줄을 쓰는 동안 커스터마이징 화면으로 진입.

음악
노트북 스피커로 이용

스피커 탓인지 사운드가 좀 가볍게 느껴짐.
음악은 워크래프트? 좀 더 동양적일거라고 생각했는데 의외로 서양 환타지같네요.
사람들 나와서 합창하는 스타일 정말 멋지긴 해요

커스터마이징 화면
커스터마이징 화면을 너무 봐와서 그런지 이젠 좀 식상하다는.

군주 처음에 나올때 큰 캐릭터 잠깐 나오는건 아무리 좋은 컴퓨터라도 다 보이네요. 이거 없애지 못하나요
휠을 당기면 한 번에 휙 당겨오네요. 의도한 바인가요? 안될건 없지만 좀 싼티나요. 2단계로 하는 것 까지는 좋지만, 스무스 인 - 아웃의 동작이라던가, 좀 더 고급화할 여력이 있을텐데요. 아니면 여러 단계로 한다던가.
캐릭터 회전은 마우스 오른쪽 버튼에 한정되어 있네요. 이유가 있나요? 왼쪽 버튼 드래그로도 돌리면 될 것 같은데?
캐릭터 형을 바꿀때 나오는 이펙트는 다른 이펙트들에 비해 퀄리티가 떨어지네요. 갑자기 캐릭터가 팍 나오는 것도 좀 별로고.
인터페이스 디자인이 구리지만 아직 안바뀐 거라고 알고 있겠습니다.
영웅형 / 야만 전사의 머리 /야수의 얼굴 조합에서는 이마에 줄이 보입니다. 머리와 얼굴 연결 문제인듯.
직업 설명 뭡니까…? 검 : 방패로 공격을 막아내며… 어쩌란 거임 -_- ;;;
그리고 저거 무력이나 공격범위, 정치력 같은거 의미 있는 건가요? 캐릭터를 고를때 참고가 하나도 되지 못하는데요? 정치력이 좋으면 뭐가 좋은지 알아야 참고하지요. 서, 설마 그림인 것임?

각 신별 림라이트 개별 컨트롤러 업데이트 되었습니다.

Tue, 31 May 2011 13:06:54 +0000

현재 제작된 림라이트가 A 지역에서는 어울리는데 B 지역에서는 이상하십니까?

밝은 낮에서는 아주 잘 어울리는데 어두운 밤에서는 림라이트가 광기어린 불빛처럼 반짝인다고 생각하십니까?

그렇다고 전체적으로 림라이트를 죽이는 짓은 하고 싶지 않으십니까?

그렇다면 걱정하지 마십시오! 새로 제작되어 커밋된 TsRimLightChanger 스크립트가 여러분의 걱정을 덜어드릴 것입니다!!!

특정 지역에서는 괜찮던 림라이트가 다른 지역에서는 눈에 거슬리게 반짝입니까?

이 기능은 일단 2개의 스크립트와 1개의 프리팹으로 이루어져 있습니다.
스크립트 폴더에서 찾으시면 되지요.

우선 림라이트 컨트롤을 원하시는 캐릭터를 선택하셔서, TsEditRimlight 스크립트를 적용시키세요.
캐릭터에게는 이것만 해 놓으면 끝입니다. 모든 캐릭터에 해 놓으셔도 됩니다. 단지 이것만 넣는 것이라면, 아무 문제도 일으키지 않으니까요.

이제 중요한 겁니다. 림라이트를 조정하기 원하는 신의 Hierachy 에, TsEnvRimLightChanger 프리팹을 끌어나 놓으십시오!

‘이 맵에서는 림라이트가 조정될 필요가 없어’ 라고 생각하신다면 그냥 하지 않으시면 됩니다!

마찬가지로, ‘이 캐릭터는 림라이트가 어떤 환경에서건 내가 정한 값으로 늘 나왔으면 좋겠어’ 라고 생각하신다면
위에서 설명한 TsEditRimlight 스크립트를 캐릭터에 적용하지 않으시기만 하면 됩니다!!!

어쨌건 여기까지 읽으셨다는 말은, 림라이트를 조절하고 싶으시겠다는 것이겠지요?

그렇다면 더 배울 것이 없습니다! 여러분은 단지 한 개의 스크립트를 캐릭터에 적용하고 한 개의 프리펩을 신에 적용한 것 만으로 모든 준비가 끝나있기 때문이지요!

이제 시작해 봅시다.

방금 설치한 TsEnvRimLightChanger 를 Hierachy 창에서 선택합시다.

그럼 Inspector 창에 림 라이트 칼라를 조절할 수 있는 기능이 생깁니다.
기본값은 검은 색이지요? 이대로 실행시킨다면 림 라이트는 나오지 않습니다!

이제 이 색을 원하는 색으로 바꿔봅시다.
음… 정부시책에 맞추어 환경을 생각하는 녹색으로 만들어 봤으면 하는군요.
그린 서울 아닙니까.

이렇게 적용시키고 플레이 버튼을 누르면,

아주 맑고 명랑한 녹색 림라이트가 나오게 되었습니다!!!

이 림라이트는 철저히 이 신에서만 해당되는 값이므로, 캐릭터의 기본값에는 영향을 끼치지 않고 다른 씬에서도 영향을 끼치지 않습니다.

물론, 연출에서도 쓸 수있지요! 마음놓고 사용해 주시면 감사하겠습니다. 커밋되었습니다.

ps 스페셜 땡스 투 조명근 스승님.
카피롸잇트 엔도어즈 코퍼레이숑

NDC 2011 기조강연 / 키노트

Mon, 30 May 2011 11:58:05 +0000

NDC 2011 갔다 왔습니다.

어느새 NDC가 이렇게 발전했군요. 어쩌니 KGC.
그나마 다행인 것은 아직은 제한적인 인원만 참여가능하다는 것.

대단합니다. 질도 양도. 이게 우리 회사라니 크헝헝

이날을 위해 준비한 “삼국지를 품다” 일러스트 대 공개. 원래 계획은 저거 하나씩 길게 천으로 뽑아서 늘이는 거였는데… 규격을 맞춰야 한데서 아쉽게 이렇게 만들었습니다.

하지만 언젠간 꼭 하고말테야.

서민 대표님의 인사말은 퀴즈로 대신

상품은 덕후들의 아이템. 레알포쓰.

네 정답은. 지식은 나눌수록 커진다는 것

이어서 김동건 본부장님의 키노트 시작.

내가 가장 잘 만들 수 있는 게임은 : 나를 위한 게임이다.
74년생 공대 출신 개발자를 위한 게임
하지만 이런거 만들면 짤리겠지.

즉 타겟은 이게 아니라.
타겟 연령은 10대

10대만 게임하나요? 미국 게이머 평균나이는 32세
맞지만 많은 게임 회사의 타겟은 10대

진입연령 확보의 중요성 : 한 두해 만들게 아니라서..
게이머는 늙어간다.

좋은 시나리오
매년 더 시작하는 사람들이 생긴다.

(주: 그렇지만 10대들만 저런 사이클을 가진다는 얘기는 좀… 어른들도 마찬가지로 늙어 죽지만 새로 어른이 됩니다. 그렇다면 결국 어른들의 게임도 만들어도 충분히 시장이 된다는 얘긴데, 굳이 어린이들만 노린다는게 이해가 되지 않는군요)

스타워즈의 선택 - 새로운 유저를 확보해 키워 나가기 위해
가면라이더 - 매년 새로운 내용으로 방송. 연령대를 높이지 않는다.
게임의 라이브에서도 가능 - 충성고객도 중요하지만 신규고객이 꼭 필요

슈퍼마리오도 엔터 에이지 지향 게임이다.

아닌 케이스도 물론 있음.

즉 신세대를 위한 게임만들기에 대해 고민하는 PT…

10년 뒤에도 게임 만들기 위해

(주: 제 생각은 오히려 아닌 케이스야말로 매력적인 시장인것 같은데 말입니다. 나를 위한 게임을 만들면 해결되는거니까! 그렇지만 여기서는 이런 생각은 마이너로 빼는군요…)

한 살씩 내려가보면 할만한데 …
어린애들은 모르겠네요. 즉 조카랑 놀아줄수 있을까.
그것도 어린애들과 100시간 놀아주기 … 사실 굉장히 어려운데 생각보다 많이 잘하고 있다고 다들 착각하는게 : 게임 개발자의 착각입니다.

이것이 우리의 착각입니다.
난 신세대를 잘 알아요: 왜냐구요? 아직 게임도 하고 장난감 사고 놀고 있거든요 .
하지만 아닙니다.

우리의 타겟층들은 : 이미 완성된 게임을 시작한 세대거든요.
한 세대는 약 30년이라고 한다면

게임회사의 1세대는 약 3년 이라고 볼 수 있습니다.
왜냐면, 게임에 대한 강렬한 자극이 게임화되는 주기가 대략 3년이기 때문입니다.
영화든 뭐든 강렬한 체험을 하고 그걸 게임으로 만들기까지는 3년 걸린다는 겁니다.

20년 차이라면 5세대 정도의 차이 :즉 같은 컨텐츠가 5번쯤 재창조 되는 시기라는 겁니다. - 예를 들면 젤다의 전설
즉 신세대들은 5세대 게임을 주로 했다는 거지요.

여기에는 젤다의 전설, 바이오 하자드, 비트매니아 등이 있습니다.

(주: 비트메니아 시리즈와 바이오하자드의 세대변화는 잘 동의하기 힘듭니다. 바이오하자드 5세대가 핵심만 남긴 아름다운 게임이라니요. 오히려 변화를 시도하다 다른걸 만든 느낌인데요. 비트메니아 시리즈는 핵심만 남기지 않고 계속 변이중이고… )

즉 지금의 유저들은 5세대 게임부터 경험한다는 것입니다.
우리가 알고 있는 게임과 그들이 알고 있는 게임은 달라요. 착각하면 안됩니다.

구세대 개발자는 그래서 , 이런 함정이 빠지지 말아야 하죠.

우리는 이런게 없으면 큰일나는줄 알았어요.
하지만 없어도 됩니다. 요즘 게임은 점점 없어요. 그래도 재미만 있거든요.

뭐 이런거 말이죠. 틀에 갇히면 안됩니다.

(주: 제가 이걸 강렬하게 느낀건 불멸이었습니다. ‘게임이 오토면 재미 없을줄 알았어요!’)

라이프 자동으로 채워주면 안되는줄 알았어요
FPS에서 자동조준스냅하면 안되는 줄 알았어요
RPG에서 목적지로 워프하면 안되는줄 알았어요

그러므로 substractive 디자인 : 뺄 수 있는건 빼라

그러므로 메카닉의 창조에 너무 집착하지 맙시다.
오히려 새로운 체험의 창조에 포커스를 맞추자.

반복된 메카닉을 모두가 진부하다고 생각하지 맙시다.
반복되어지는건 이유가 있습니다.

(주: 그러니까 신세대에 맞추지 않고 구식으로 만들어도 상관 없지 않냐는 … 오히려 신세대에 맞추려고 발버둥 치는 것이 이런 게임을 만드는 것이 아닐까요? 우리가 재밌고 하고 싶어하는 걸 만들면 자연히 뒤를 돌아보지 않는지요. )

누적된 재창조로 갈라파고스 현상
재창조만 반복되면 시장이 줄어듭니다.
세계의 명작 배틀 ㅋㅋㅋㅋ

초기 개발자들이 아는걸 다 안다고 접근하지 맙시다.
틀 안에 갇혀있지 말고 새로운 변화 모색합시다.

일반인들이 못알아듣는 덕후짓좀 하지 말고..


4. 플레이어와의 승부욕
과거의 게임은 컴퓨터와 승부하는데서 출발했습니다.
그땐 지면 끝없이 도전했지요 . 할 게임이 많이 없어서: 그러던 사람이다 보니까 고객을 이기려 합니다.

몬스터 죽는거 슬퍼하는 AI 프로그래머가 되지 마세요;;;

우리는 도전 욕구를 자극하는 게임들이 많았지요. 그건 주로 아케이드랑 패키지 였습니다.

개발자가 이겨야할 사람은 플레이어가 아니라 해커입니다

버려야 할 것은 이런거입니다. 그럼 배워야 할 것은 ?

신세대 플레이어에 대해 공부 합시다.
게임 신세대의 특징은?

영상 세대
글로 봤을때 보다 전체적으로 본다. 그래서 빠르다.
약점 : 상상을 즐기는데는 약함
보는 것에 익숙해서 ..
게임 회로 기본 내장
게임이란 말을 설명할 필요가 없다
평범한 엔터테인먼트
기초를 다 알고 있지.

게임 친구가 주변에 있다.
게임의 전파가 매우 빠르다.

익숙한 게임 메카닉을 다른 분야에도 적용 가능

경험치와 레벨업 운동기구
등수를 매기는 소셜 서비스
십자키로 조종하는 중장비
게임패드로 조작하는 로보트

과잉공급
할 게임이 널려있다.

000가 하고 싶다 / 보다 ‘뭐가 재밌냐?’

게임을 고르는 것도 피곤합니다.
1등 게임에 집중 하게 되지요
커뮤니티를 통한 확산

돈 쓰기 싫다.

게임을 구입한다라는 것은 옛날 이야기입니다.
게임 이용료를 낸다는 개념도 약화 되고 있습니다.
아이템도.
쇼핑 그 자체를 즐기는 세대입니다.

가상도 상관없다
나에게 충분한 효용을 준다면 현실이 아니어도 좋습니다.

리얼 버라이어티쇼 / 레슬링 / 립싱크 라도 상관없다는 거죠

가상 아이템 구매가 어색하지 않습니다.
꼭 진짜여야 한다는 강박이 사라집니다.

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

그럼 우리같은 구세대 개발자가 신세대를 위한게임을 만드려면?

네 이게 정답.

뭐 결론은 뻔합니다.

체험이 중요

게임의 규칙보다 체험이 더 중요합니다.
대충 어떻게 돌아가는지 알겠다 X
이런 점이 재미있구나 O

그렇다고 우리 세대의 재미가 통하지 않는건 아닙니다. 그걸 다음 세대에 맞는 세련된 표현법으로 전달하는 것이 중요하지요.

게임은 체험을 전달하는 미디어 이고, 우리세대는 게임의 혁명을 많이 겪었던 세대 입니다.
그걸 신세대에게 잘 전달합시다.

(주: 좋은 강연이었습니다. 갈망의 아궁이 보다는 조금 반대되는 입장의 내용이 꽤 있었습니다만… 그것은 아마도 게임에 대한 추구하는 방향이 다르기 때문이겠지요. 저는 일단 10대를 위한 게임을 만들고 싶지는 않아서요. 언젠가 가요와 TV에 무심하게 된게 아이돌과 댄스 일색의 후킹가요때문이었는데요. 할 수 있다면 다양한 세대의 사람들이 다양한 게임을 하는 모습을 보고 싶네요)

저사양용 물쉐이더 작성

Fri, 27 May 2011 14:25:38 +0000

전에 제작되었던 물쉐이더를 저사양에서 돌렸을 때 표현될 물 쉐이더를 제작하였습니다.따로 제작했단 얘기가 아니고, 기존의 물 쉐이더에 추가하였다는 말입니다. 유니티에서는 이렇게 한 쉐이더에 고급 쉐이더와 저급 쉐이더를 따로 두면, 옵션에 따라 선택할 수 있게 되어 있습니다.
고사양용 물 쉐이더에 비해 최대한 이질감이 적으면서 가볍게 만들어 보았습니다.

노말맵 안씁니다.
당연하게도 노말맵 흘러가기도 안되기 때문에 UV를 하나만 씁니다.
Main 텍스쳐는 잘 흘러갑니다. (스크롤 수치가 잘 작동됩니다)
투명도는 0.7 (70%) 가 고정되어 있고, 여기에 버텍스 칼라 green 채널에 의해 더 투명하게 됩니다.
즉 기존에 만들었던, 육지 근처에서 투명하게 되는 기능이 그대로 살아 있습니다.
물결 텍스쳐 잘 작동합니다.
Base Texture Overlay 는 작동하지 않습니다. (의미도 없어요)
Edge Texture Overlay는 잘 작동합니다.
따로 지정된 Alpha 수치는 작동하지 않습니다.
카메라에서 멀리 떨어진 물에 물결 텍스쳐가 보이지 않도록 만든 기능이 사라졌습니다. 때문에 _Frensnel Power가 의미없습니다.
EdgeTexColor 는 잘 작동합니다 .
TintColor는 잘 작동합니다.
Specular나 굴절, 반사등은 모두 작동하지 않습니다. 이미지로 보시면 다음과 같습니다.

고사양

저사양

고사양

저사양

고사양

저사양

고사양

저사양.

Global Light 제어 스크립트

Thu, 26 May 2011 13:57:17 +0000

정확히 얘기하면 “Global Fake Light Control Script” 쯤 되려나요.
쉐이더에서 사용하는 각종 조합을 위한 색상값들을 유동적으로 조절할 수 있는 스크립트입니다.

사실은 삼품에서 사용하려고 만들었는데 …. 명조가 Self illumination 값을 0.5로 바꿨어 ㅋㅋㅋㅋㅋㅋㅋㅋㅋ
ㅋㅋㅋㅋㅋㅋㅋ 1이었잖아 ㅋㅋㅋㅋㅋㅋ 1일때에는 주변 라이트의 색상값 영향이 너무 적어서 캐릭터 혼자 튀는 경우가 생기기 때문에, 1을 유지할 생각이었으면 그 상태에서 맵에다가 색상값을 지정해 illumination에 저장해 주자라고 생각하고 있었는데 0.5로 바꾸니까 별 필요가 없게 되었습니다.
하지만 모르지요. 글로벌 라이트는 언젠가 쓰일 수 있는 녀석이기 때문에 만들어 두는게 좋습니다.
특히 AT2 의 캐릭터 쉐이더를 위해서는 꼭 만들어져야 하는 스크립트입니다.

개념은 이런 개념이지요.
따로 설명하기 보다 이걸 보는게 편리하겠네요.

테라에서 사용된 환경광 기법.

여기서는 IBL (이미지 기반 라이팅) 기법을 사용했습니다만, 저희는 그것보다 좀 더 심플한 Hemosphere Light (반구조명) 기법을 이용했습죠. 덕분에 각 맵마다 필요한 값은 상/하 2개의 색상. 물론 우리도 수작업은 필수입니다.

즉 이 스크립트가 없었을 때에는, 캐릭터 제작할때 셋팅해 놓은 반구조명 색상이 그대로 적용되었기 때문에, 어떤 배경에 가더라도 같은 느낌의 색상만 난다는 문제가 있었습니다.

예를 들어 이런거나

이런 것처럼

파란 하늘도 아닌데 파란 하늘이 느껴지는 라이팅 설정들이 생긴다는 거지요. 처음 설정이 푸르샤프라 지방에서 맞춰놓은 설정이라서 말이지요.

그래서 두 개의 스크립트가 제작되었습니다.

하나는 _GameManager 안에 컴포넌트로 넣어져 있으며, 이름은 Ts Scene Ambient Color 입니다.
이건 맵마다의 글로벌 라이트 설정을 제어하는 메니져이지요.

그리고 또하나는 Ts Global Light Color 스크립트로, 이것은 캐릭터를 넣으실 때 각 파츠마다 컴포넌트로 삽입시켜 주셔야 합니다. 이것은 Ts Scene Ambient Color 에서 지정한 색상을 , 여기 있는 쉐이더의 색상에 대입시켜주도록 연결시켜주는 스크립트입니다. Ts Scene Ambient Color 는 이미 들어가 있으므로, 캐릭터를 제작하실때 Ts Global Light Color 스크립트만 넣어주시면 됩니다.

(혹은 글로벌 라이트 효과로부터 독립해서 만들고 싶으시면 이 스크립트를 안 넣으시면 됩니다)

이렇게 만들어 놓고 플레이를 누르면,

미리 설정해놓았던 쉐이더의 칼라값은 무시되고 ,맵의 루트에 있는 게임 메니져의 Ts Scene Ambient Color에 의해 칼라값이 제어받게 됩니다.

즉 처음 실행하면 초기값이 검은색/ 검은색 이기 때문에 이렇게 됩니다.
여기서 맵에 알맞은 색상을 등록해 놓으면

맵별로 어울리는 칼라로 셋팅해 놓으면, 연결된 쉐이더들의 색상이 자동으로 바뀌므로 맵에 어울리는 칼라로 자동으로 변하게 됩니다.
물론 필요하면 삼품에서도 사용할 수 있으며, 현재 AT2에 커밋되어 있습니다.
일단 맵별로 대충 칼라는 제가 다 잡아놨구요. 빼먹은거나 새로 제작되는 맵에는 만들어 주시면 되겠습니다.

글만 보고는 조금 어려우므로 자세한 사용법은 문의!

ps. 현재는 작업의 편의성을 위해 실시간 수정을 열어놓았는데요, 나중에는 최적화를 위해 실시간 수정을 막겠습니다.
스페셜 땡스 투 조명근 스승님

gdc 2011 슬라이드들

Thu, 26 May 2011 09:49:36 +0000

GDC 2011 슬라이드들

GDC 2011의 슬라이드들이 올라와 있었군요.
사실 슬라이드들이 워낙 자세하게 잘 만들어져 있어서, 왠만한 것들은 강연 안듣고도 슬라이드만 봐도 대충 알 수 있을 정도입니다. 그래도 백문이 불여일견이라
ㅋㅋㅋ

유니티 스크립트 기초 4

Tue, 24 May 2011 16:32:30 +0000

사실 API 만 알면 정말 뭣도 아닌 수준의 스크립트네요. 설명하는 선생님이 잘 설명해 주셔서 된듯. 정리한 후에 이걸 가지고 실무데이터로 만들고 컨펌받아봐야겠습니다.

앞서 얘기한대로, 이걸 받아와서 쉐이더의 일정 색상을 변화시켜 보겠습니다.
잘 되면 나중에 텍스쳐도 받아와서 하도록 해야겠네요 :)

그럼 먼저 이 코드에서부터 시작합니다.

계속 업데이트에서 놀겁니다.

일단 아까 만든, 신에 붙어 있는 색상 출력하는 스크립트에서 칼라값을 받아와야겠지요.

그럼 그걸 찾아가는 명령이 GameObject 입니다 .

그러므로 이렇게 찾아갑니다.

GameObject.Find("_GameManager");

게임 메니져라고 하는 오브젝트를 찾아갑니다. 거기 안에 아까 만든 스크립트가 있거든요.

그리고 이걸 다시 Object 형식의 변수에 집어 넣었습니다. 쓰기 편하게 하려구요.

오브젝트라고 하는 단위가 존재하는게 신기하네요. ㅎㅎ

GameObject GM = GameObject.Find("_GameManager");

그리고 다음 행동을 하기 전에, 여기 값이 제대로 들어왔나를 검색하는 코드를 만듭니다.
만약 값이 제대로 들어오지 않았다면 디버그 메시지를 출력합니다.

if (GM != null)
  {

  }
  else
  {
   Debug.Log(“GM is empty”);
  }

이제 제대로 들어왔을때 어떻게 할 것인가를 처리합니다.
GM 오브젝트가 오브젝트를 잘 찾아 물고 들어왔으니, 이 오브젝트에 들어있는 하위정보를 가져오면 되겠지요.
그리고 그 하위정보중에서도 아까 만든 스크립트인 TsSceneAmbientColor 라고 하는 컴포넌트를 찾아서 거기 값을 받아오면 될겁니다. 뭐 이거 부르기만 하면 칼라가 호출되게 되어 있으므로 문제없겠죠.

그러므로 ,

if (GM != null)
  {

   GM.GetComponent(“TsSceneAmbientColor”);


  }
  else
  {
   Debug.Log(“GM is empty”);
  }

라고 추가해줍니다. GM.GenComponent 라고 하는 명령으로 말이죠.
이걸 접근하면, 칼라값이 리턴됩니다.

그러므로
Color FinalColor = GM.GetComponent(“TsSceneAmbientColor”);

이런 식으로 칼라값을 받아와야겠지요.
그렇지만 왼쪽은 Color고, 오른쪽은 Object입니다. 형식이 다르죠.

그래서 ‘형 변환’ 이 필요합니다. 형 변환에는 여러 형식이 있지만.

Color FinalColor = GM.GetComponent(“TsSceneAmbientColor”) as Color;

그래서 이렇게 받아오면 될 것 같지만, 하지만 이렇게는 안됩니다.
형 변환을 하려면 부모자식간의 관계여야지, 이렇게 Color 같은 동떨어진 녀석으로 바로 갈 수가 없기 때문이지요.
때문에 Object인 GM의 자식 클래스인, TsSceneAmbientColor 로 형변환 해야지 난데없이 Color로 넘어올 수는 없는 거지요.

즉

TsSceneAmbientColor FinalColor = GM.GetComponent(“TsSceneAmbientColor”)as TsSceneAmbientColor

이렇게 되어야 정상입니다.

그리고나서, 다시 업데이트의 맨 처음에다가 칼라 변수를 하나 선언해 줍니다.

Color Acolor = new Color();

C# 특징인 객채 생성이지요.
그리고 이걸 이용해서 , 칼라값을 받아옵니다.

대충 이 정도가 되겠네요.

void Update () {

Color Acolor = new Color();
GameObject GM = GameObject.Find("_GameManager");
  if (GM != null)
  {

   TsSceneAmbientColor FinalColor = GM.GetComponent(“TsSceneAmbientColor”)as TsSceneAmbientColor;
   Acolor = FinalColor.SceneColor;

  }
  else
  {
   Debug.Log(“GM is empty”);
  }

이제 여기서 나온 Acolor 를 맨 마지막 출력에 대입시켜주면 끝입니다.
renderer.material.SetColor("_UpperGlobalLight",Acolor);

이렇게 하면 완성.

// Update is called once per frame
void Update () {

Color Acolor = new Color();
GameObject GM = GameObject.Find("_GameManager");

  if (GM != null)
  {
   TsSceneAmbientColor FinalColor = GM.GetComponent(“TsSceneAmbientColor”)as TsSceneAmbientColor;
   Acolor = FinalColor.SceneColor;
  }
  else
  {
   Debug.Log(“GM is empty”);
  }

renderer.material.SetColor("_UpperGlobalLight",Acolor);

}

여기에 FinalColor 가 들어왔는지 안들어왔는지 검사하는 if문 하나 더 넣어주면 끝나겠지요 :)

풀버전 코드는 다음과 같습니다.

using UnityEngine;
using System.Collections;

public class TsEnvLightColor : MonoBehaviour
{
public Color MainAmbient ;

// Use this for initialization
void Start () {

}

// Update is called once per frame
void Update () {
  Color Acolor = new Color();

  GameObject GM = GameObject.Find("_GameManager");

  if (GM != null)
  {

   //TsSceneAmbientColor SA = GM.GetComponent(“TsSceneAmbientColor”) as TsSceneAmbientColor;
   TsSceneAmbientColor SA = GM.GetComponent();

   if (SA != null)
   {
    //Acolor = SA.GetAmbinetColor();
    Acolor = SA.SceneColor;
   }

  }

  else
  Debug.Log(“Not Found GM!!! “);



  if(renderer.material.HasProperty(”_UpperGlobalLight”) == true )
   renderer.material.SetColor("_UpperGlobalLight",Acolor);
  else
   Debug.Log(“Not Found UpperGlobalLight property !!! “);

}
}

잘 되네요.

실시간으로 게임 메니져에서 색상을 바꾸니 바뀌어서 넘어옵니다. 굿.

유니티 스크립트 기초3

Tue, 24 May 2011 15:14:49 +0000

이제 스크립트를 새로 만들어 봅니다. 이번 스크립트는 더 간단.
뭐냐면 씬 메인에 붙어서 칼라를 가지고 있는 스크립트입니다.
즉 씬별로 칼라 설정을 해주는 이 스크립트를 만들어 놓고,

아까 만든 스크립트는 지금 만들 이 스크립트로부터 색을 받아오는 기능이지요.

그리고 씬의 루트에 있는 게임메니져에 이 값을 넣어줬습니다. 이로써 디자이너는 이 씬에 해당하는 GI 칼라를 설정해 놓을 수 있게 되겠지요.

이걸 만들어 놓았으니 (사실 이걸 먼저 만들어야 할 것 같긴 합니다만, 공부하는 중이라 순서가 이랭요)
이제 이 칼라를 아까 그 스크립트에서 받아와서 처리해야 합니다.

유니티 스크립트 기초2부

Tue, 24 May 2011 15:00:37 +0000

영어로 썼다 한글로 썼다.. 에라 몰라.

빨리 실무에 응용하고 싶어서 되는대로 해버립니다. 최적화는 기술지원팀에서 해주겠지 뭐 (우리팀이잖아. 퍽)

스크립트를 만들고 칼라를 받아오는 인터페이스까지 만들었으므로, 이제 이걸 내가 원하는 쉐이더 칼라 부분에 적용하는 일을 해야 합니다.

원하는 타겟은 캐릭터 쉐이더의 UpperGlobalLight.
그렇습니다. fake GI 구현을 위한 시도입니다. 유치한 시도지요.

이 부분을 찾아들어가 바꿔보겠습니다.

최적화따위는 개무시하고, 매 프레임 업데이트할 때마다 찾아서 들어가도록 해 보지요.

// Update is called once per frame
void Update () {

renderer.material.SetColor("_UpperGlobalLight",JPtestColor);

}

이거 한 줄이면 끝.
renderer에서 material로 들어가서 setcolor 처리한 다음에 들어갈 쉐이더의 칼라 값을 지정해 주면 끝. 초 간단.
API를 몰라서 그렇지 API만 알면 이보다 간단한건 없겠네요.

플레이를 누르자, 잘 적용되었습니다. 잇힝.

Unity Script 기초 1부

Tue, 24 May 2011 11:18:41 +0000

문법 기본은 당연히 C#.
자바스크립트로 짤 수도 있습니다만 (그리고 그게 더 빠릅니다만) 편한건 C#.
쉐이더 말고 C# 작업은, 그리고 스크립트 작업은 한 번도 해본 적이 없어서 이번이 처음입니다.

때문에 하나하나 되짚어 가면서 백업해 놓지 않으면 기억할수가 없엉 ㅋ
쉐이더도 이랬었죠.
무식하게 해보는 것이 역시 짱.
그나마 그때보다는 조금 나은게… 그때는 C도 몰랐을 때니까요.
지금은 그래도 쉐이더도 좀 해봤고 하니 좀 낫겠죠.

원하는 스크립트는 다음과 같은 기능을 요구합니다.

Scene 에 연결이 되어서, 각 캐릭터의 메터리얼에 접근, 쉐이더의 일정 값의 색상을 Scene에 연결된 색상으로 바꿔주는 기능.
즉 지형별 엠비언트 칼라 조절 기능입니다.

그럼 어쨌건 시작.

우선 빈 스크립트를 제작합니다. C# 스크립트를 제작하지요.
그리고 이름을 바꿔둡니다.

using UnityEngine;
using System.Collections;

public class NewBehaviourScript : MonoBehaviour {

// Use this for initialization
void Start () {

}

// Update is called once per frame
void Update () {

}
}

코드를 열어보면 이렇게 되어 있습니다.

여기서 일단 바꿔야 할 부분은 NewBehaviourScript .
이 부분을 스크립트 이름으로 바꿔야 합니다.

그래서 일단 완성.

using UnityEngine; // 이건 뭐 당연히 넣어야 하는거.
using System.Collections; // 어디에 저장할 것인가…

public class JPTestColorChange : MonoBehaviour {

// Use this for initialization. 초기화에 해당되는 부분. 지금은 비어있다.
void Start () {

}

// Update is called once per frame 매 프레임 업데이트해야 할 부분. 지금은 비어있다.
void Update () {

}
}

그리고 방금 만든 스크립트를, 적용하고자 하는 오브젝트에 적용해 줍니다.

적용되었습니다.

이제 스크립트를 열고,
클래스 부분에 한 줄 추가해 줍니다.
public Color JPtestColor ;
이렇게요.

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

using UnityEngine;
using System.Collections;

public class JPTestColorChange : MonoBehaviour {

public Color JPtestColor ;

// Use this for initialization
void Start () {

}

// Update is called once per frame
void Update () {

}
}

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

이것만으로 간단히 칼라 추가. 인터페이스 설정없이 변수만 추가하니까 메뉴가 생기다니 오마이갓.

이런식으로 int 와 float과 bool 추가해봄. 오오 bool 이 된다

삼품 초딩마인드 테스트

Mon, 23 May 2011 14:17:28 +0000

모바일 작업하다가… 작업 불가능한 상태가 되어서 글씁니다. (에헤라 디야 오늘도 날려먹는건가)
빨리 맥 장비가 왔으면 좋겠어요. 혼자서 뭔가 할 수가 없네요.

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

삼품 초딩마인드 테스트입니다. 게임 처음 시작하면서부터 느끼는 바를, 굉장히 짜증 잘 내고 쉽게 질려하는 유저에 빙의하여 써놓았습니다. 오해없으시길.

늘 게임 만들때마다 부정기적으로 하는 짓입니다 :)

어떤 마인드냐 하면…
이런 마인드로 빙의해서 테스트합니다.

다시 한 번 말씀드리지만 오해하지 마세요 ;_; 이정도 빙의해야 잘잡혀요.
중간에 짜증내는 것 같아도 사실 짜증 안난겁니다. 빙의라니깐.

권장사양에서의 삼품테스트입니다. 이젠 편하게 할 수 있게 되어 좋네요.

로딩입니다. 많이 걸린다던데… 뭔가 고쳤나요? 그렇게 심하게 느리다는 느낌은 아니었습니다.
물론 휙휙 넘어가지는 않았지요. 여기서 로딩화면 뜰 때까지 약 15-20초, 다시 커스터마이징 화면 뜰 때까지 15초 정도… 30초 정도면 참을만 합니다.

테스트 전에 그 전에 있는 군주를 삭제해 보았습니다. 캐릭터를 선택하고 삭제.
군주를 삭제하겠습니까? 라길래 확인을 눌렀습니다. 이럴땐 ‘삭제’ 라고 씌여 있어야 하는거 아닌가? 라고 투덜댔습니다…

그런데 군주를 삭제하고 난 후 저 창이 그대로 있더군요. 약간 당황한 채, 다시 ‘확인’ 버튼을 두 세번 클릭했습니다. 보통 확인이라 함은 많은 프로그램에서 어떤 행위를 진행한 후 창이 사라지는 것이 일반적이었다고 몸이 기억하고 있는 것입니다.

잠시 약 2초간 고민하고 난 후, x 버튼을 눌러야 저 창이 사라진다는 것을 깨달았습니다.

… 귀찮잖아….

네에 , 커스터마이징 창이 나왔습니다.
참고로 오디오 안나옵니다 … 프로그램 잘못이 아니고 컴이 그렇습니다. 테스트용 컴에 많은것을 바라면 안돼요…
그럼에도 불구하고 번쩍번쩍 이미지들이 제법 괜찮습니다. 이펙트등이 풀버전으로 나오고 있는데 프레임도 상당히 잘 나오고 있구요.

근데 군주 생성하려고 캐릭터를 선택하니 빨강 라인처럼 캐릭터가 T포즈로 번쩍 하고 나타났다 지금의 캐릭터로 나옵니다.
은근슬쩍 거슬리네요 이거.

그리고 캐릭터 텍스쳐가 묘하게 떨어져 보입니다. 이것은 아마도 GOOD옵션에서의 half 텍스쳐 해상도 때문인 것 같은데, 확인해 봐야겠습니다. (이건 내 책임이잖아 ㅋㅋㅋ)

아이디는 언제나 이 더런 세상 ~
이편한 세상의 패러디죠. 그냥 암 이유없이 쓰고 있습니다.

글씨 폰트는 묘하게 좀 깨지는 느낌. 깔끔하지가 않네요. 그리고 처음이 반드시 영어로 되어 있어, 한 번씩 실수하고 지운다음 다시 한영키를 눌러서 바꿔줘야 합니다.

그리고 한글 입력은… 이거 완성형인가요? 글씨를 치면 바로 안나오고 다음 글자로 넘어가야 나옵니다 .
즉 ‘이더런세상’ 을 치면 ‘이더런세’ 까지만 보입니다. ‘상’ 을 보려고 스페이스바를 한 번 더 누르게 되는데요,
그럼 중복 확인 때에 “특수 문자 및 공백이 들어간 이름은 사용할 수 없습니다” 라고 나옵니다.

그리고 그 ‘특수문자… 사용할 수 없습니다’ 글씨가 한 칸씩 위로 올라가는게 왠지 약올리는 느낌.

이래저래 캐릭터 3개를 만들어 보았습니다. 역시 권장사양에서 이상없음. 최저사양에서는 어떨지 궁금하네요.

자 게임을 시작해 봅니다.

뭔가 첫 화면이 묘하게 기분나쁜 뷰네요.
NPC가 목잘린것이 묘하게 거슬려.

마미 돋네.jpg

예상했던 뷰는 이 정도.
배경이 꽤 밝아서인지 캐릭터와 아이콘이 잘 구별 안갑니다.
나중에 유저 바글바글하고 말풍선 가득할때는 더 안보일듯.
프레임은 여전히 잘 나오는 편입니다. 나중에 캐릭 많아지면 곤란하겠지만.

NPC랑 얘기를 해 보았습니다. 보통 게임할때는 다 그러잖아요.

어이 부담스럽게 얼굴들이밀지 말라고.

뭔가 두 개의 메뉴가 있습니다. 두 개 다 읽어봐도 뭐가 차이인지 모르겠습니다. 뭐가 퀘스트인지도 모르겠고.
첫 번째가 퀘스트 같군요. 보통 모르면 첫 번째를 선택하는게 인지상정 .

읭?

만 명이랍니다.
눈에 보이지도 않는데 만 명.

사람 목숨을 험하게 다루는 의용병 대장이로군요.
액션도 없이 가만히 서서 너 만명 가졌다 하니까 도무지 믿기지 않습니다.

못 믿겠다니까.
최소한 뭔가 멋진 삽화라도 뜨던가.

아니 그것보다는, 퀘스트는? 뭘 하라는 거냐?
나 뭐한거야?
다시 말을 걸어 봅니다.

부담스럽게 쳐다보지 마 2 .
저 팔 어깨에 안쪽 뚫린건 말했으니 해결될테고.

아무래도 아래 것이 퀘스트인가 봅니다.
알아볼 수가 없넹.

말 많어.

보통 3줄이면 읽을만 한데, 이건 글씨가 상대적으로 작다 보니까 갑자기 집중해서 읽어야 되는 사이즈가 되네요.
읽기 싫어집니다.
글씨 좀 크게 해야 할 듯

돈은 10 준다는 것 같고, 깃발? 저건 뭡니까?

어쨌건 모집했으니 바로 깨지는 것 같은데… 뭔가 깬 것 같지가 없습니다. ‘퀘스트 완료 타격감’ 같은게 없달까요.

여기부터도 할 말이 많습니다만 휘리릭 쓰려면 일단 여기서 종료하겠습니다.
다음 2부에서는 유비 동영상만 3번 본 얘기를 해야겠군요. 후후후

모바일용 캐릭터 쉐이더 Mobile/TK_Mobile_Char

Fri, 20 May 2011 16:54:40 +0000

모바일용 캐릭터 쉐이더입니다.
self-illumination 쉐이더에서 힌트를 얻어, 전혀 다른 방향으로 무식하게 접근해 보았습니다. 마치 A=B B=C 면 A=C 라는 방식의 삼단논법 접근법이랄까… ㅋㅋ

Seif- illumination을 사용하는 이유는 빛으로 인한 음영을 부드럽게 (혹은 거의 없애게) 하여 캐릭터의 본 모습을 강조하고자 할 때 사용하는 의도입니다.
때문에 이 의도를 더 강조하여 , 아예 빛으로 인한 음영 자체가 나오지 않게 Unlit 쉐이더로 만들었습니다.

현재 이 쉐이더는 Unlit 쉐이더와 완전히 동일하지만, 추후 요청사항 (좀 더 밝게 혹은 어둡게라던가, 염색이라던가…) 등이 들어올 때 대응할 수 있도록 프레그먼트 쉐이더를 숨겨놓았습니다. 즉 앞으로 응용가능하게 만들어 놓았다는 말씀.

모바일용 캐릭터 쉐이더는 이것을 사용하시면 되겠습니다. 메인 텍스쳐 외엔 아무것도 건드릴 필요 없습니다.

커밋되었지유

모바일용 캐릭터 쉐이더 연구

Wed, 18 May 2011 18:15:06 +0000

모바일에서 사용하는 캐릭터 쉐이더 연구입니다.

모바일 캐릭터는 일단 폴리곤이 적고, 크기가 작으며, 텍스쳐가 복잡하고 섬세하게 그려져 있는 편이라 사실 빛에 의한 음영이 그다지 잘 나오지도 않고 중요하지도 않습니다. 때문에 모바일에서는 오히려 라이트를 이용한 쉐이딩이 그렇게 매력적이지 않지요.

그런 이유로, 웹에서 캐릭터용으로 사용되었던 Self-illumination 계열의 쉐이더와, 쉐이더중 가장 가벼운 Unlight 쉐이더를 비교해 보도록 하겠습니다.

Unlit 쉐이더는 라이트를 전혀 사용하지 않고 라이트에 전혀 영향받지 않는 쉐이더이며, 단지 텍스쳐에 100% 의존하는, 존재하는 쉐이더중 가장 가벼운 쉐이더입니다.

그 점이 사실 Self-illumination 과 상통하는 면이 있다는 것에서 힌트를 얻어 테스트 해 보았습니다.

Self-Illumination vs Unlit 쉐이더.

Self-Illumination쉐이더의 이미지는 다음과 같습니다.

현재 캐릭터는 모바일용 캐릭터가 아닙니다. 모바일용은 더 가볍고 폴리곤도 적습니다.

이 상태에서 아이폰으로 옮겨보면 다음과 같습니다.

아이폰에서의 화면입니다. 현재 illumination 이 100% 들어간 상태라 많이 밝습니다. 만일 이걸 사용해야 한다면 조절해야겠지요.

프레임은 9프레임 정도 나옵니다. 40마리가 출력되어 있습니다.

이번엔 Unlit 쉐이더입니다. 라이트를 전혀 사용하지 않는 쉐이더라고 말씀드렸습니다.

순수하게 텍스쳐만 보입니다. 좀 안 튀는 것이 아니냐는 느낌도 있습니다만…이 쉐이더 기반으로 좀 더 밝게 물론 가능합니다.

10.28 프레임이 나오네요. 약 1프레임 조금 못되게 상승하는군요. 엄청난 효과는 나지 않지만, 어쨌건 효과가 있네요.

보너스. 이건 모바일용 Vertexlit 쉐이더입니다. 대충 이정도 느낌이면 될듯

결론적으로 Unlit 쉐이더를 기반으로 해서, 밝기조절이 어느 정도 가능한 쉐이더를 만들면 되겠습니다.

때문에 현재 모바일용 캐릭터 쉐이더가 제작되어 있습니다. 이름은
Mobile/TK_Mobile_Char

입니다. 현재는 Unlit와 완전히 같은 쉐이더로 제작되어 있습니다만, 추후 밝기 조절이나 염색등이 필요하다고 요청될때 프레그먼트 쉐이더로 변신할 수 있도록 준비해 놓았습니다. 캐릭터를 만드실 때 이 쉐이더를 사용하시면 되겠습니다.

모바일용 (배경용) 쉐이더 퍼포먼스 비교

Wed, 18 May 2011 15:25:43 +0000

모바일용이라는게 워낙 베일에 가려진게 많아서리…
어떤 쉐이더를 어떻게 어디까지 써야 하는가가 정확히 알려진게 하나도 없습니다.

일단 아이폰의 쉐이딩 특징으로 그동안 조사되었던 것은

아이폰의 그래픽칩은 Tiled 디퍼드 렌더러를 사용하므로, 알파 테스팅은 상당히 엄청나게 느리고 알파 블렌딩이 빠르다.
하지만 라이팅은 쥐약이므로, 가능한한 계산하지 말아야 한다. (디퍼드라면서… 라이팅이 제약이 있다고…?)
버텍스 연산이 매우 취약하므로 , 버텍스 연산보다는 픽셀연산으로 몰아야 한다.

대충 이정도로 알고 있었는데, 이번에 본격적으로 프로젝트를 시작함에 따라 확실한 테스트로 결과를 뽑아 보았습니다.
(참고로, 예전에 했던 테스트에서는 위의 특징이 모두 맞지 않은 것으로 나왔었습니다)

결론부터 얘기하자면,

예, 저 위의 아이폰 쉐이딩 특징은 현재 하나도 맞지 않습니다…. (이렇게 말하면서도 불안하긴 해요. 정말?)

믿고 싶진 않지만, 테스팅 결론이 그렇게 나와 버렸으니까요…
배경용 기본 쉐이더
DiffuseFast 사용

사실 말씀 드리면, Diffusefast 란 쉐이더는 사실 없습니다. 들어가서 보면 이 쉐이더는 이미 코드가 없어졌고, (옛날 유니티에선 있었지요) 지금은 이 쉐이더를 적용시키면 자동으로 Vertexlit 쉐이더로 넘어가게 되어 있습니다. 즉 DiffuseFast = Vertexlit 쉐이더입니다. 둘 중 어떤걸 적용하셔도 상관 없습니다. 사실 DiffuseFast는 껍데기 뿐이므로 모두 Vertexlit으로 제작하세요! 라고 하는게 정상입니다만 , 이미 익숙해 지신 상태니 그냥 가기로 하겠습니다 :) (하지만 유니티 4.0 에서는 사라질지도 몰라요)

어쨌건 DiffuseFast 와 Diffuse 쉐이더의 싸움입니다. 버텍스 라이팅과 픽셀라이팅의 싸움이지요.
PC에서는 압도적으로 버텍스 라이트가 빠릅니다만…

아이폰에서의 결과는 다음과 같습니다.

Diffuse

Diffuse Fast (Vertexlit)

Diffuse와 DiffuseTest의 차이는 사실상 거의 없습니다. 둘 다 단순히 빛을 dot 연산하여 텍스쳐를 섞어주는 것 외엔 아무 일도 하지 않습니다. 단지, Diffuse는 빛 계산을 픽셀로 하고 DiffuseTest는 버텍스로 한다는 차이 뿐입니다.

테스트 결과 거의 의미없는 수준의 차이가 나왔습니다. 9프레임까지 떨어질 정도로 부하를 올려 봤는데 0.2 프레임 정도 차이라면 오차범위도 되지 않을 레벨이지요.

즉 별 차이가 없는 관걔로 어떤걸 써도 상관없습니다만, 픽셀 라이팅을 사용하는 Diffuse는 해상도에 영향을 받을 수 있는 관계로 해상도와 별 상관이 없는 (버텍스는 해상도에 상관없이 똑같으니까…) DiffuseFast 를 쓰는 쪽이 조금더 안정적이라 생각되어 DiffuseFast 를 메인 쉐이더로 사용하도록 하겠습니다.

각종 오브젝트를 비롯한 기본 프랍들의 쉐이더는 DiffuseFast 입니다.

(단, 나중에 라이트맵이 들어간다면 얘기는 달라지게 됩니다! 이건 그 때 다시…)

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

배경용 알파 채널 사용 쉐이더.

알파 테스팅과 알파 블렌딩의 차이비교

Transparent / Cutout / Diffuse

Transparent / Diffuse

둘다 사용 가능

알파 테스팅은 유니티에서는 Cutout(컷아웃) 이라고 불립니다. 알파 소팅의 문제점을 피하기 위해 텍셀의 블렌딩을 하지 않고, 단순하게 각 픽셀별 알파값을 0과 1로 저장하므로 블렌딩이 없이 칼같은 이미지가 나오게 됩니다. PC에서는 당연하게도 말도 안되게 빠르고 안정스럽습니다

그렇지만 아이폰에서는 렌더러 자체가 블럭으로 렌더링하는 방식이라, 이 방식 자체가 오히려 역효과를 일으킨다고 합니다. 하도 협박들을 많이 하길래 진짜로 어떤가 테스트 해 봤습니다. 즉 아이폰에서는 블렌딩 방식이 더 빠르다는 것이 문서들의 얘기.

테스트 결과는 다음과 같습니다.

알파테스팅 (컷아웃) 사용. 나무들의 잎 경계면이 선명합니다.

알파블렌딩. 나무들의 잎 경계면이 부드럽습니다.

차이는… 0.3 프레임 정도.

차이는 개뿔

두 경우 모두 3프레임까지 떨어질 정도로 데이터를 사용해서 비교해 봤습니다만, 역시 두 방식의 차이가 극히 미미한 관계로 두 방식에서 어느 방식을 사용하는지 제한하지 않도록 하겠습니다. 왠지 문서랑 비교했을때와 달라서 솔직히 찜찜하긴 한데, 결과가 이렇게 나왔으니 믿을 수 밖에 없지요.

주로 그래픽팀은 컷아웃 쉐이더를 사용하시는게 익숙하실테고 또 그렇게 사용하셨을 겁니다. 그렇게 사용하시던대로 사용하시면 되겠습니다. 역시 라이트맵이 들어가면 다르게 생각해야 하지만 말입니다.

라이트맵은 라이트 대신에 맵을 사용하는 것이므로, 다른 쉐이더를 사용해야 합니다.

다음은 캐릭터용 기본 쉐이더와 이펙트용 쉐이더를 올리도록 하겠습니다.

삼품테스트 권장사양 테스트

Tue, 17 May 2011 15:01:22 +0000

캐릭터가 1마리라서 성능이 좋게 나와야 함.

블룸이 들어가 있습니다. 실제 Good 옵션에서는 빼기로 했던 옵션입니다.

DOF와 Contrast Enhance를 GOOD 옵션에서 빼야 할지도 모르겠습니다. 그래픽카드에 부담을 확실히 주네요.

Color Collection 은 효과에 비해 부담을 적게 줘서 유지.

던전 _ 캐슬포인트

무거운 부분이 700 드로우콜을 넘어가면서, 더 무거운 맵이 되어 버렸습니다. 이전보다 상당히 무거워진 듯? 이유를 찾아봐야 할듯 합니다

던전 _ 필드워

후처리 효과들을 제거하니 제 속도가 나옴.

던전_필드워 002

상동

던전 _ 포트

초기지역에서 드로우콜 700 정도 올라감.

만일 무겁다면 디스턴스 컬링을 고려해 봐야 할듯 . 캐릭터가 안모인다면 뭐..

던전_강족_1

드로우콜이 600 가량 나오는 곳이 있음 순간적 부하량 외엔 괜찮음.

던전_강족2

지역에 따라 드로우콜이 1000 에 달하는 곳도 있어서 디스턴스 컬링 기능이 필요할 것으로 보임.

그렇지만 길이 좁아서 타 캐릭터가 많이 안보일 것 같기도 하다

계성

상당히 상대적으로 가벼워짐 그렇지만 절대적으로는 여전히 무거움. 파티클까지 덧붙여져서 …. 게임 초반 시작 맵이면 재고요망

파티클 부하량은 적다.

던전_강족4

간혹 500 가량의 드로우콜을 보이는 곳도 있지만 상대적으로 매우 안정적인 맵

던전_게이트웨이

일부 구간이 500 가량의 드로우콜을 보이므로 약간 주의요망.

던전_게이트웨이 베틀

안정적

던전_계교전투

최대 500대의 드로우콜.

임페리얼 팔레스

문제없음.

던전_마운틴_001 섹션

원거리에서 700-800 까지 올라가는 경우가 있음 디스턴스 컬링과 지형 LOD를 체크해 봐야 할듯.

던젼_마운틴-002 섹션

잠깐 500이상 올라가기도 하지만 전반적으로는 좋은 디자인에 가벼움.

던전_m포인트_001

언제나 안정적 400 정도

던전_남화001

200대로 아주 가벼움. 좀 더 써도 되지 않을까.

던전_남만_001 섹션 1

파티클의 영향이 좀 보임. 오브젝트도 많아 800 이상으로 드로우콜이 올라가는 경우가 많음. 밀도가 높으니 최적화를 좀 고려해 보는 것도 좋을듯. 테스트 한 것 중 느린 편

최적화가 필요할듯

던전_남만_001_섹션1

위 보다 좀 가벼움.

약간씩 끊어지는 느낌이 있지만 이건 파티클인듯

던넌 남만 001 섹션2

가끔 700까지 올라가는 경우 있음. 조심할것. 일반적으로는 큰 무리없음,

던전 남만 001 섹션3

오브젝트가 많아 프레임 저하가 우려됨. 작은 오브젝트는 숨기거나 날리는 것이 필요

던전 남만 001 섹션4

높은 지역에서 원거리 볼때 순간적으로 1000 넘는 경우 발생

원거리 컬링 등의 기법 필요

던전 남만 001 섹션5

원거리가 보이는데도 DP콜이 높지 않음.

가볍고 이상적임

던전 남만 001 섹션6

500 - 600 정도로 , 적절하고 안정적.

던전_리버포트 _ 001

400 정도로 안정적.

프레임이 약간 생각보다 낮다

던전_로얄가든

물과 파티클이 많이 사용된 것 처럼 보이는데도, 무척 가볍고 (200 이하. )빠름. 훌륭

던전_태평

콜수는 안정적인 편인데 생각보다 프레임이 잘 안나옴.

삼품 중간테스트입니다. 한 달에 한번씩은 권장사양과 최저사양에서 러프하게 테스트해 볼 예정에 있습니다.

테스트 이유는 갑자기 크게 무거워지거나 뭔가 변한게 있는가 체크하는 단계입니다.

테스트 방식은 때문에 이전보다 훨씬 러프하며, 해결책까지 찾아서 올리는 글은 아닙니다.

제작하실때 참고하시라는 느낌의 게시물이라고 할 수 있습니다.

테스트 방법은 보다 간편하게 테스트했습니다. 이전 데이터와 비교해서 체크하시면 되겠습니다.

<이전 데이터>

제한 사항들

-월드맵은 여전히 가벼워서 테스트에서 제외시켰습니다.

새로 생긴 던전들이 더 추가되었습니다.
캐릭터는 1마리로 테스트 되었습니다.
이전 테스트(*위 표 참고)는 캐릭터 30마리와 같이 테스트한 것이기 때문에, 위 표에서 드로우콜을 약 200-300 정도 줄여서 생각하시면 맞습니다
이전에는 없던 후처리 효과들이 추가되었습니다. 때문에 그래픽카드 후처리 부하가 유발되어서, 실제보다 더 느리게 나왔습니다. 블룸은 빼기로 하였던 옵션이고, 추가로 DOF와 Contrast Enhance를 Good 옵션에서는 삭제해야 할 듯 합니다
테스트 PC 는 권장사양 (3.2 듀얼, 1G, GF6600GT) 에서 테스트 되었습니다. (6600과6600GT는 다릅니다)

테스트 총평

테스트 결과 이전과 비슷한 결과가 일반적으로 도출되었으나, 평균적으로 약간씩 더 무거워져 있는 상태로 보입니다. 그전 테스트에서도 아슬아슬한 상황인 경우인 맵이 많았는데 그대로네요 :) 사실 전체적으로 조금씩 더 가볍게 해주셔야 정해놓은 권장사양에 맞출 수 있습니다. 그게 아니라면, 그래픽 카드만 7000대로 올리는 것도 한 방법이지요. 이것도 고려중입니다.

이슈사항

특이사항이 있는 맵들은 대충 다음과 같습니다 .

던전_캐슬포인트

그전 테스트와 다르게, 상당히 무거워졌습니다. 이유를 찾아야 할 것 같습니다. 배경만 평균 700에 육박하는 드로우콜을 가지고 있습니다. 이전보다 약 200-300 드로우콜이 올랐네요.

던전_포트

던전_강족2

던전_남만 001 섹션 4

원거리가 보일때 드로우콜이 증가합니다. 다른 캐릭터나 몬스터가 별로 보이지 않는 곳이라면 괜찮겠습니다만, 필요시 디스턴스 컬링을 가동시켜야 할지도 모르겠습니다.

계성

예전보다 확실히 가벼워졌습니다. 거의 1/2 이 되었네요. 그래도 그렇게 가벼운 편은 아닙니다.

던전_남만 시리즈

섹션 5,6 을 제외하고 다소 묵직합니다. 프레임이 널뛰기도 하네요. 약간 최적화가 필요할 듯 합니다.

던전_남화001

던전 남만 001 섹션5

특이하게, 퀄리티가 떨어지지 않으면서도 다른 맵에 비해 압도적으로 가볍고 빠릅니다. 훌륭하네요.

Unity Mobile Shader

Mon, 16 May 2011 16:59:26 +0000

유니티의 모바일 쉐이더가 새로 생겼지만, 애석하게도 도움말이 없습니다. (혹시 제가 못 찾은 겁니까?)

그래서 아티스트 분들을 위해 제가 간단하게 정리해 보았습니다.

Built-in mobile shader

Mobile / Background 쉐이더

라이팅 영향도 받지 않고 단지 텍스쳐만 출력하는 초 간단한 쉐이더입니다.

재미있게도 Zwrite도 하지 않습니다. 즉 이것은 말그대로 원거리 배경용 쉐이더. 스카이박스는 아니고 멀리 보이는 원경 한 장짜리 이미지 같은 경우에 쓸 수 있는 쉐이더입니다. 0.5g

Mobile / Bumped Specular

보이는 그대로, 모바일용으로 만든 스페큘러가 포함된 노말맵 사용 쉐이더입니다.

좀 더 간략화 된 특징을 가지고 있는데,

메인 칼라나 스페큘러 칼라를 지정할 수 없습니다.
스페큘러에서 사용하는 라이트 방향은 버텍스에서 대충 받아서 옵니다.
노말맵의 타일링이나 옵셋은 베이스 텍스쳐의 설정값을 따릅니다.
디퍼드 라이팅을 지원하지 않습니다. 라이트맵도 지원하지 않습니다.
디렉셔널 라이트 1개만 지원되고, 나머지 라이트들은 버텍스 라이트나 구면조화 라이트로 작동합니다.

일반적인 범프/스페큘러보다는 좀 가볍게 되어 있긴 합니다만, 그래도 노말맵 연산이 되므로 모바일에서 함부로 사용해서는 곤란합니다. 3g

Mobile / Bumped Specular (1 Directional Light)

위의 범프 스페큘러 쉐이더와 동일하지만, 단 한가지만 다릅니다.

디렉셔널 라이트 1개만 지원되고, 나머지 라이트는 무시됩니다.

즉 위의 쉐이더보다 아주 약간 가볍다고 할 수 있습니다. 2.7g

Mobile / Particles / Additive

이전에 사용하던 일반적인 Add 쉐이더와 거의 같으며, 다른점은 다음과 같습니다.

Tint Color가 없습니다.
스무스 파티클 옵션이 없습니다.
알파테스트가 없습니다 (전에는 있었나?)
칼라마스크가 없습니다.

사실상 그 외는 동일하게 제작되어 있습니다. 좀 더 가벼워진 버전이라고 할 수 있습니다. 1.5g

Mobile / Particles / Alpha Blended

이전에 사용하던 알파 블렌딩 쉐이더와 동일하며, 다른점은 위의 Add 쉐이더와 같습니다.

Mobile / Particles / Multiply

이전에 사용하던 멀티 쉐이더와 동일하며, 다른점은 아래와 같습니다.

스무스 파티클 옵션이 없습니다.
알파테스트가 없습니다
칼라마스크가 없습니다.

역시 이전에 사용하던 쉐이더와 동일하되 약간씩 가볍게 제작된 것 외에 차이가 없습니다 .

Mobile / Particles / VertexLit Blended

이전에 사용하던 버텍스라이트 블렌디드 쉐이더와 동일하며, 다른점은 아래와 같습니다.

알파테스트가 없습니다.
칼라마스크가 없습니다.

이하 상동

Mobile / Skybox

이전에 사용하던 스카이박스 쉐이더처럼 6면의 텍스쳐를 집어 넣습니다. 그렇지만 단지 Tint Color 만이 제거되어 있습니다.

사실상 거의 같지만 아주 살짝 가벼운 정도입니다. 대부분, 기능들을 꼭 제거할만큼 효과가 커 보이지 않습니다.

Mobile / VertexLit

기본적인 버텍스 칼라 쉐이더에서 일부 기능이 삭제된 쉐이더입니다.

per material 칼라가 삭제되어 있습니다.
스페큘러가 없습니다.
emission이 없습니다.

그 외는 동일합니다.

사실상 모바일 쉐이더라고 해서 특별하게 만들어 진 것은 없으며, 단지 기능이 몇 개씩 삭제된 정도입니다. 즉 일반 게임용 쉐이더도 ‘가벼운 쉐이더 라면’ 모바일에서도 대부분 똑같이 돌아가며, 사용에 제약이 없습니다.

이펙트 쉐이더들도 모바일용으로 컨버팅해 놓도록 해야겠네요…

Deferred Lighting Rendering Path Detail

Mon, 16 May 2011 11:59:54 +0000

Deferred Lighting Rendering Path Details

This page describes details of Deferred Lighting rendering path. For a technical overview of what Deferred Lighting is, see Deferred Lighting Approaches article.

Deferred Lighting is rendering path with the most lighting and shadow fidelity:
디퍼드 라이트는 라이트와 그림자에 적합한 렌더링 패스입니다. (특화된)

There’s no limit how many lights can affect any object.
얼마나 많은 라이트가 오브젝트에 영향을 끼치는지 상관이 없습니다.
All lights are evaluated per-pixel. Which means that they all interact properly with normal maps etc.
모든 라이트가 퍼 픽셀로 계산되며,이것은 그것들이 노말맵 등등과도 인터렉티브하게 작동된다는 것을 의미합니다.
All lights can have Cookies.
모든 라이트는 쿠키를 가질 수 있습니다.
All lights can have Shadows.
모든 라이트는 그림자를 가질 수 있습니다.

Deferred Lighting’s advantages:
디퍼드 라이팅의 장점:

Lighting cost is proportional to light size on screen. Does not matter how many objects it shines on. Small lights = cheap!
Consistency. All lighting for all lights is computed per-pixel; there are no lighting computations that break down on large triangles etc.
라이팅 비용은 화면에서의 라이트 사이즈에 영향받습니다. 이것은 얼마나 많은 오브젝트가 빛나냐의 문제가 이닙니다. 작은 라이트는 = 쌉니다! 확실히 . 모든 라이트는 퍼 픽셀로 계산됩니다 ; 이것은 큰 삼각형 등등을 깨뜨리느냐에 대한 라이팅계산이 아닙니다.

Disadvantages:
단점:

No real anti-aliasing support.
리얼 안티알리아싱이 지원되지 않습니다.
Deferred Lighting can’t handle semi-transparent objects. Those are rendered using Forward Rendering.
반투명 오브젝트는 제어할 수 없습니다.
Limited lighting model support (Blinn-Phong). All lighting is computed the same way; you can’t have drastically different lighting models on different objects.
제한된 라이트 모델 지원 (블린-퐁). 모든 라이트는 같은 방법으로 계산되어 버립니다. ; 당신은 각각의 오브젝트를 드라마틱한 다른 라이팅 모델로 계산시킬 수 없습니다.
No support for “receive shadows” flag and limited support light Culling Masks.
“리시브 쉐도우” 플레그를 지원하지 않고 라이트 컬링 마스크를 제한적으로 지원합니다.

Requirements for Deferred Lighting 디퍼드 렌더링의 요구사항

Requires Unity Pro.
유니티 프로가 먼저 필요하고요
Graphics card with Shader Model 3.0 (or later), support for Depth render textures and two-sided stencil buffer. Most graphics cards made after 2004 support it: GeForce FX and later, Radeon X1300 and later, Intel 965 / GMA X3100 and later.
그래픽 카드는 쉐이더 3.0 이상, 깊이 렌더 텍스쳐와 2사이드 스텐실 버퍼가 지원되어야 함. 2004년 이후 그래픽 카드는 대부분 지원함 ; 지포스 FX와 그 이후버전, 라데온 X1300과 이후버전, 인텔 965/GMA X3100과 그 이후버전.
Currently does not work on mobile platforms.

Performance Considerations 퍼포먼스의 주의사항

Cost of realtime lights in Deferred Lighting is proportional to number of pixels the light shines on; and not dependent on scene complexity. So small point or spot lights are very cheap to render. Point or spot lights that are fully or partially occluded by some scene objects get their pixels skipped on the GPU, so they are even cheaper.
디퍼드 렌더링에서 리얼타임 렌더링의 비용은 라이트가 현재 빛나는 , 화면의 픽셀 수에 비례합니다 ; 그리고 신의 복잡도 같은건 신경 꺼도 됩니다. 그래서 매우 작은 포인트나 스팟 라이트 같은 경우는 매우 렌더링 하기 빠릅니다. 전체 혹은 부분적으로 다른 오브젝트에게 가려진 포인트나 스팟 라이트는 GPU에서 계산이 스킵됩니다. 그래서 그들 또한 빠릅니다.

Of course, lights with shadows are much more expensive than lights without shadows. In Deferred Lighting, shadow casters still need to be rendered once or more for each shadow-casting light. And the lighting shader that applies shadows is also more expensive than one without shadows.
물론, 라이트와 그림자는 라이트와 그림자가 없을때보다 많이 무겁습니다. 디퍼드 라이팅에서, 그림자 캐스팅은 여전히 한 번 또는 한 번 이상 , 각각 그림자 캐스팅 라이트에 의해 렌더링됩니다. 그리고 그림자가 적용되는 쉐이더는 그림자가 없는 쉐이더보다 역시 많이 무겁습니다.

Implementation Details

When Deferred Lighting is used, rendering process in Unity happens like this:

Base Pass: objects are rendered, producing screen-space buffers with depth, normals, and specular power.
Lighting pass: lighting is computed using the previous buffers. Lighting is computed into another screen-space buffer.
Final pass: objects are rendered again. They fetch computed lighting, combine it with color textures and add any ambient/emissive lighting.

Objects with shaders that can’t handle Deferred Lighting are rendered after this process is done, using RenderTech-ForwardRendering path.

Base Pass

Base pass renders each object once. View space normals and specular power are rendered into single ARGB32 Render Texture (normals in RGB channels, specular power in A). If platform & hardware supports reading Z buffer as a texture, then depth is not explicitly rendered. If Z buffer can’t be accessed as a texture, then depth is rendered in additional rendering pass, using shader replacement.

Result of the base pass is Z buffer filled with scene contents and Render Texture with normals & specular power.

Lighting Pass

Lighting pass computes lighting based on depth, normals and specular power. Lighting is computed in screen space, so it’s independent of scene complexity. Lighting buffer is single ARGB32 Render Texture, with diffuse lighting in RGB channels and monochrome specular lighting in A channel. Lighting values are encoded using logarithmic encoding to provide extended dynamic range than usually possible with ARGB32 texture.

Lighting model is fixed to Blinn-Phong.

Point and Spot lights that do not cross camera’s near plane are rendered as 3D shapes, with Z buffer test against scene enabled. This makes partially or fully occluded Point and Spot lights very cheap to render. Directional lights and Point/Spot lights that cross the near plane are rendered as fullscreen quads.

If a light has shadows enabled, they are rendered and applies in this pass as well. Note that shadows are not “free”; shadow casters need to be rendered and a more complex light shader needs to be applied.

Final Pass

Final pass produces final rendered image. Here all objects are rendered again; with shaders that fetch the lighting, combine it with textures and add any emissive lighting.

Lightmaps are also applied in the final pass. Close to the camera, realtime lighting is used, and only baked indirect lighting is added. This crossfades into fully baked lighting further away from the camera

AT2맵별 테스트

Thu, 12 May 2011 11:16:13 +0000

역시 제대로, 풀버전으로 분석하고 문제거리가 있으면 역추적하고… 하려면 거의 한 달이 걸리는 짓이긴 합니다만, 짧은 시간안에 하느라 그렇게 하지는 못했습니다. 그저 작업하실때 염두해 두시고 체크하시면서 작업해 주시면 되겠습니다.
Babylon_field04
바빌론 필드_04

프레임이 잘 나오고 드로우콜도 낮습니다. 추후 모래바람 이펙트가 추가된다던가 하면 얘기가 달라질 수도 있습니다…
드로우콜이 낮은데 비해 프레임이 상대적으로 잘 나오지는 않는 것 같습니다. 가끔 튀는 영역이 있는 것으로 보이는데 이 부분의 확인이 추후 필요할 듯 합니다. 어쨌건 데이터는 굉장히 가벼운 상태입니다.

바빌론 Sp_gate
Babylon_sp_gate

프레임이 살짝 낮습니다만 약간의 최적화를 통해 프레임이 올라갈 가능성이 큰 맵이며, 데이터 자체는 현재로도 안정적인 용량을 보여주고 있습니다. 단지 배경이 좀 비어보여서 추후 오브젝트 장식물들이 추가된다면 좀 느려질지도 모르겠습니다. 주의 부탁드립니다.
프레임이 튀고 있는 증상이 보이는데, 오브젝트의 처리가 불안할때 저런 증상이 나타납니다. 나중에 원인을 찾으면 프레임이 약간 올라갈 수도 있습니다.

브라소프_브란 캐슬 가든
brso_brancastle_garden04

아기자기하고 이쁜 맵이지만 크기가 작아 가벼운 편에 속합니다. 프레임도 잘 나오고, 맵도 이쁘고 데이터도 가볍습니다. 나중에 컬링이 적용될때 적극 참고가 될만한 좋은 맵입니다. 이 정도의 용량만 한 번에 보여지면 좋을 것 같습니다. (특히 로마가 참고하면 좋겠네요)
순간적으로 이미지 이펙트 스크립트가 뭔가 튀는 증상을 볼 수 있습니다. 뭔가 고질적인데, 이것만 잡아도 안정적 프레임이 나올 수 있을 것 같습니다.

브라소프 _ 필드
brasov_ fild

나무가 많아 batch가 적극적으로 작동하고 있습니다.
하늘이 어둡네요 :)

오브젝트가 많아 프레임이 잘 안나오고 있습니다. LOD나 컬링을 손봐야 할 것 같습니다. 깊이 텍스쳐를 업데이트 할때 간혹 튀긴 하는데 지금은 이유를 잘 모르겠네요.

브라소프 _ 박쥐동굴
brasov_batcave

물이 약 22%의 부하를 먹고 있습니다. 새로 생긴 물 무척 무겁네요. 조정이 필요할 것 같습니다. 옵션이 많아졌으니 가능하겠지요.
그럼에도 불구하고 프레임이 괜찮게 나오는 편이니, 물만 개선하면 프레임이 좋을 것 같습니다.

브리타이나 칼 섬?
br_carlisle
…혹시 castle 이 아닌건가요?

어쨌건 드로우콜이 높은데도 프레임이 잘 나오고 있습니다. 나무들의 영향이 크겠지요. 나무들은 드로우콜을 높이지만, 현재 batch가 560으로 매우 높기 때문에 프레임 저하가 작은 것입니다. 폴리곤도 많은데 말이지요. 이렇게 batch 가 높으면 프레임에 좋은 영향을 줍니다.
중간중간 가비지콜렉터(GC)가 튀고 있습니다. GC는 일종의 쓰레기통으로, 메모리에서 필요없는 부분을 정리해 버리는 기능입니다. 이 부분이 튄다는 것은 뭔가 이상한 오브젝트가 대량으로 생성/삭제를 반복하고 있다던가, 프로그램적으로 메모리 관리를 이상하게 하고 있다던가, GC 자체가 에러가 있다던가…

브리타니아 _노팅엄 마을
br_notinum

맨 처음 제작된 맵이고 맨 처음 퍼포먼스 테스트가 되어, 합격점을 받았던 맵이기도 합니다. 그때와 지금이 어떻게 달라졌는지 비교해 볼까요? 프레임은 25프레임 정도로, 컬링이 되어 있지 않은 상태에서 이정도면 (넓은 맵이기도 하고) 괜찮은 편이라고 할 수 있습니다. 역시 드로우콜도 매우 적고 안정적이면서도 이미지가 비어 보이지 않습니다. 여전히 이상적이네요.
중간중간 튀는 부분이 있습니다만 부정기적이라 잡기 힘드네요.

노팅엄_배틀맵3
br_notium_battle

캐릭터가 많이 나오고 인터페이스가 나오는 맵이라는데 의의가 있는 데이터입니다.
데이터가 높지는 않지만 프레임도 무척 나오지 않네요.
약간 튀는 구간이 있지만 기본적으로 캐릭터들이 무거운 상태 - LOD도 되어 있지 않은 상태라 많이 무거워짐을 알 수 있습니다.
캐릭터 최적화가 필요하다는 것을 알 수 있습니다.

팬드래건 여관
br_pan_inn

작은 건물 안입니다. 가볍겠죠.
데이터는 가볍습니다만 프레임은 생각만큼 높게 나오진 않습니다.
15% 정도를 이미지 이펙트가 잡아먹고 있네요. 그 외에도 뭔가 높이 잡아먹는 요소가 오브젝트에 있는 듯 한데.. 잘 모르겠습니다.
나중에 잘 찾아봐야 할 것 같습니다.

팬드래건
br_pandragon

팬드래건입니다. 이런 이미지가 보통 무겁죠.. 어디 볼까요.

과연 무겁습니다. 이렇게 광활한 이미지는 무거울 수 밖에 없지요. 건물 LOD 라던가의 방법을 강구해야 할 것 같습니다.

한슨집 Fx
br_hanson_FX
FX가 추가되어 있는 집을 보았습니다. 집 자체가 가벼운 편이라 Xㅏ 들어가도 그다지 부담이 없네요.
단, 이런 실내들이 공통적으로 그림자를 끄니까 선 샤프트 같은 이미지 이펙트들이 캐릭터들한테 적용이 되면서 부하가 유발됩니다. 추후 정리하면 더 나아질듯 합니다.

동굴_배틀맵
cave_battle 맵입니다. (이건 이미지가 노팅엄 전투맵 같은 느낌이네요)

역시 캐릭터가 많습니다.
위의 노팅엄 전투맵보다는 프레임이 잘 나옵니다. 이유가 확실히 분석되진 않았습니다.

ione_house
아이온 하우스?

이건 볼 것도 없이 가장 가볍고 가장 빠릅니다. 신기한건, 데이터가 가장 적은건 아니라는 것입니다. 굉장히 압도적으로 좋은 프레임이 나오는데요, 원인을 연구하면 좋은 힌트가 될 수 있을것 같습니다.

히살리스크_컬버트던전
dungeon_culvert
딱 봐도 힘이 들어간 무거운 던전입니다. 그런데 특이하게 드로우콜은 높지 않습니다. 폴리곤도 많지 않습니다. 그렇지만 프레임은 거기에 걸맞게 잘 나오지는 않습니다… 이유가 뭘까요? 라이트? 디퍼드에서 라이트의 추가는 그렇게 큰 영향을 주지 않습니다.

이미지 이펙트와 피직스가 30% 정도를 먹고 있는데요. 이 부분을 찾아보면 힌트가 될지도 모르겠습니다.
나중에 본격적으로 테스트할 때..

히살리스크
Hisarlik

프레임이 꽤 안나오는 지역중 하나입니다. 버텍스도 꽤 많은 편이고, 드로우콜도 높습니다.
거기에 순간적으로 워터가 75%의 부하를 잡아먹으며 펄쩍펄쩍 뛰고 있습니다.
추후 최적화를 좀 고려해봐야 할 것 같은 곳입니다.

트로이 _시타델
troycitadel

가장 무거운 맵중 하나입니다. 보이는 것도 꽤 많습니다.
적극적인 컬링과 LOD가 요구됩니다.
특이사항은 없습니다. 잘 줄여 주세요. 장과장님 화이팅. :)

콜로세움
Colosseum_battle

데이터가 가볍긴 합니다. 그렇지만 그렇게 프레임이 좋지는 않네요. 역시 그림자를 끄니까 이미지 이펙트 . 특히 선 샤프트가 30% 를 먹어가고 있습니다. 나중에 조정이 필요하겠네요.

로마 시내
rome_city

최강으로 무겁습니다만, 최고로 느리진 않습니다. 역시 최적화에 따라서 개선될 여지가 꽤 있다는 말이겠지요.
미리부터 적극적인 최적화를 고려해서 디자인 되어 있는 것으로 알고 있습니다. 이제 그걸 적용해서 실행할 단계지요.
역시나 숨겨져 있는 워터의 무게가 22%를 차지하고 있습니다.

왕의계곡 동쪽
vellyofking_East
프레임이 굉장히 잘나옵니다. 드로우콜도 굉장히 낮습니다. 하지만 드로우콜 비율 프레임이 가장 잘 나오는 맵 같습니다.
특별히 튀는 영역도 없고, 무척 이상적이고 안정적으로 나오고 있습니다.
좋은 모범이 되는 맵입니다.

왕의계곡 서쪽.
Vellyofking_West

물이 있어서 어떨까 싶었는데, 과연 물이 16%를 차지하고 있네요. 그리고 동쪽보다 데이터가 무거워서 프레임이 잘 안나옵니다. 여기는 건물이 빽빽히 있는 지형이 아니라, 거리 컬링만 적용해도 굉장히 효과가 좋을 것 같습니다.

왕의계곡 전투맵
Vellyofkingbattle

메쉬 스키닝 수치가 높게 나와서 프레임을 저하시키고 있습니다. 이것 역시 캐릭터의 최적화가 필요할듯 합니다.
배경 데이터로만 따지면 가벼운데 말입니다.

AT2 맵 퍼포먼스 테스트

Wed, 11 May 2011 17:56:07 +0000

AT2 의 맵들이 제작되고 있습니다. 예전에 초기테스트 이후에 요즘 제작된 맵의 테스트가 전혀 이루어지지 않고 있어서, 나중에 본격적인 AT2 가 시작하게 되기 전에 일단 초벌로 (…) 테스트 데이터를 뽑아 보았습니다.

퍼포먼스 데이터를 정식으로 뽑으려면 일단 시간이 아주 많이 걸립니다. 때문에 중간에 이렇게 한 번 테스트 해 놓으면 나중에 좀 편하지요. 작업하시는 분도 작업중간에 참고하면서 작업하면 좋으니까요.

곧 삼품 모바일 작업으로 한동안 신경 못 쓸 것 같아서 재빨리 테스트 하는게 중요했으므로 세부 분석/ 원인 점검 및 해결 까지는 하지 못했습니다.
본격적인 세부 테스트는 다음 기회에.

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

테스트 제반 사항은 아래와 같습니다.

해상도는 1280*1024로 했습니다. 그렇지만 유니티 인터페이스가 일부를 잡아먹는 문제로 1075*860 테스트가 되어 버렸습니다.
사양은 권장사양으로 예정되어 있던
    듀얼 3.2GHz
    메모리 2G
    그래픽카드 GF7600GS (사실 원래 권장은 GT였었습니다만…)
    를 사용했습니다.
옵션은 Good 옵션으로, 후처리 효과는 모두 들어가 있고, 실시간 그림자와 Anisotropic, AA 와 SSAO 등의 고급옵션은 모두 제거된 상태입니다.
Good 옵션이지만 렌더러는 디퍼드 렌더러로 가동중입니다.
최적화가 제대로 고려되지 않은 데이터들이기 때문에 (기본적으로는 고려해서 제작중이시지만) 다소의 최적화 가능성이 있습니다. 평균적으로 약 30% 정도의 최적화가 가능할 것으로 보입니다.
캐릭터가 여러 마리 나오는 것을 생각해야 합니다.
여기서 30프레임 이상 나와주면 권장사양에 잘 맞게 제작되어 있다고 생각하시면 됩니다.
전체 맵 중 가장 무거운 부분에서 테스트한 데이터이기 때문에 결과는 평균보다 무거울 수 있습니다.

결과는 다음과 같습니다.

이름은 확인해보지 않고 막 썼습니다 -_-;;;

위 데이터에서 주목할 데이터는 다음과 같습니다.

대충 감 잡고 계셨스리라 생각합니다만, 전반적으로 권장사양보다 많이 무거운 상태입니다. 최적화 기능이 제대로 동작하지 않는 상태이지만, 프로그램적인 최적화로는 많아봤자 30% 정도의 성능향상을 기대할 수 있기 때문에 그래픽쪽에서 신경써 주셔야 합니다. 장문영 과장님이 대충 짐작하시는 바로 그대로 입니다 :)

목표는 전부 30프레임 이상으로 올리는 것! (그래야 캐릭터/이펙트/ 인터페이스들이 나와도 10~15프레임 정도를 유지하지요)

사실 프레임과 드로우콜은 정 반대로 가야 하는게 정상입니다. 이전에 기준으로 잡았던 부트캠프에서 배경의 드로우콜을 약 1000 에 맞추는 것이 좋겠다라고 말씀드렸듯, 현재 1500을 넘어가는 맵들 (특히 로마시내) 들은 적극적인 컬링을 염두해 두시고 작업해 주시기 바랍니다. (뭐 이미 얘기는 다 되었습니다만)

그리고 현재 프레임과 드로우콜이 정 반대가 아닌 맵들 - 드로우콜은 작은데 프레임은 안나온다 - 에서는 몇몇 프로그램적 이상이 발견된 맵들이라고 보시면 됩니다. 미리 말씀드리자면, 가비지 콜렉터 (GC) 부분에 문제가 있고, 후처리 효과가 튀는 맵들이 좀 있고, 새로 나온 Water를 사용하면 무척 무거워 지는 맵들이 있습니다. 이런 경우입니다. 나중에 수정할 수 있으리라 보여집니다.

뭐 사실 그래도 대부분은 얼추 맞습니다.

버텍스와 폴리곤 데이터들입니다. 사실 무척 정직한 데이터를 보여주고 있는데요, 무거운 맵은 그냥 폴리곤과 버텍스가 많습니다 :) 다시 말씀드리지만 적극적인 컬링 계획 꼭 필요합니다. 잘 고려해 주세요 :) 로마 같은 경우는 컬링을 대대적으로 계획하고 계신 것으로 알고 있습니다.

그리고 버텍스 데이터가 조금 높은 맵들이 있네요. 버텍스 공유가 잘 안된다는 얘기인데요. 맵 장수를 적극적으로 합쳐주시기 바랍니다

결론적으로 지금 상태에서는 권장사양을 8800 으로 올리는 것도 고려하고 있습니다. 그래픽 수준이 아이온보다 높은, 마영전 정도의 밀도를 보여주고 있기 때문에 그래픽 카드 사양만 올리면 현재 상태로도 꽤 잘 돌아가는 것을 볼 수 있었습니다. 요즘 시대라면 그것도 괜찮겠지요.

하지만 삼품의 예를 봤을 때 지금의 데이터들은 사양보다는 다운로드 데이터의 양이 걱정됩니다. 아무래도 웹게임이다보니 다운로드 데이터의 양을 무시할 수 없는데, 지금은 이전에 만들던 스텐드 얼론 방식의 온라인 게임과 같은 퀄리티라서 말이죠. 텍스쳐 사이즈도 줄여야 할지도 모르겠구요…- 물론 텍스쳐 사이즈를 줄인다고 하더라도 일단 제작할때는 현재처럼 크게 제작해 놔야 하는 것이 정석입니다 - 정확한 내용은 직접 전달 드리겠습니다. 아무래도 초벌 테스트다 보니 적극적인 제안을 드리기는 힘듭니다. 현재 상황을 보고드리는 정도라고 받아보시면 되겠습니다 :)

난생처음 캠핑카 여행기 3부

Tue, 10 May 2011 12:54:50 +0000

낼부터 출근해야 하니 오늘 다 써버릴랍니다 … 원래 성격이 붙잡으면 바로 다 해버려야 하는 성격이라…

무사히 다음 날 아침이 밝았습니다.

어라? 저 풍력발전기 돌아가 있다?
바람 방향에 따라 머리가 도는군요 오오오

풍력발전한 전기로 저 머리 돌리는데 다 쓰고 막 이래

아침 환기 시간입니다. 열 수 있는거 다 열고 팬을 켭시다.

아 진짜 이리저리 신경쓸게 많아서 이번 여행은 사진이 정말 적네요.
평소라면 1박 2일에 5-600장은 찍는데 이번엔 겨우 241장.

창문고리는 자세히 보면 이렇게 생겨 있습니다.

그냥 열면 될 거 같죠? 캠핑카는 전부 고정식이라고 말씀드렸습니다.

저 버튼 누르기 전까지는 안열립니다. 캠핑카니까요. 이리저리 흔들거려야 하는 캠핑카니까요

요렇게 살짝만 열어서 걸어 놓으면 주행중 환기버전. 잇힝

위에서 아래로 내리면 모기장.

찰칵.

그걸 또 위로 올리면 블라인드.

뭐 다 이런 식입니다.

침대도 테이블로 다시 변신시켜야 겠지요.
메트를 치워둡니다.

테이블 아래에 있는 레버를 잡고 젖혀서

올려주기만 하면

찰칵. 고정됩니다.

동영상에서 봤던 것 보다 더 편한 버전이네요.

마지막으로 등받이와 안전벨트를 원위치 시켜주고, 컵꽂이를 붙여주면 완성.

금방입니다.

환기와 함께 아침 밥 준비중입니다.

아침밥은 전통적인 라면.

여유있을때 읽으려고 가져갔던 헤드퍼스트 C#은 훌륭한 냄비받침으로. ㅋㅋㅋ

여유는 개뿔 크흑

캠핑장 모습입니다. 비온다더니 날만 맑습니다.

라면은 보글보글

아침라면은 콩나물을 넣어야 제맛.

숙주도 좋았던 기억이 …

이렇게 다시 일상모드로 변신 완료. 씻을 사람은 씻고, 화장실 갔다올 사람들은 갔다옵니다.

오늘은 동해안을 따라서 강릉까지 가서 복귀할 예정이기 때문에 긴 여행이 될거예요

이제 설치해 놨던 장비들 다 복귀시키고, 출발합니다.

다시 기억해야 할 것 두 가지.

나는 화물차다 나는 화물차다 나는 화물차다 나는 화물차다 나는 화물차다 나는 화물차다 나는 화물차다
브레이크는 가슴부터 밟는다.

내려가기 전에 둘러보니 왠 비행기 전시장이 있네요. 뭔 상관일까.

뭐 일상적인 수준의 구식 비행기들.

비행기 자물쇠를 저걸로 달아 놓으니까 초큼 웃키네요

구식 제공호: 프리덤 파이터는 별 관심 없고

오히려 관심있던건 F4 팬텀의 조종석.

오오오오 쏴밀어 좌석! 사출좌석을 순수한 한국말로 옮겨 놓으니 무척 북한삘 나는군요.

갑자기 살펴본 캠핑카 열쇠.
각각 기능이 다 다릅니다.

맨 오른쪽은 외부 사물함. 그다음은 대문 열쇠 . 그다음 두 개는 안써서 모르겠슈. 맨 왼쪽은 화장실 외부 열쇠 같은데.

하루 써 봤다고 요령이 좀 늘었습니다.
돌아올때의 시트 베리에이션은 이렇게.

누워서 잘 사람은 누울 수 있고, 앉아서 갈 사람은 앉아서 가게 만들어 놓았습니다. 결론은 대만족. 아이들도 편하고 어른들도 좋아하네요.

출발입니다. 정동진으로.

가는 도중의 망양휴게소.
역시나 여기서도 내부를 구경하고자 하는 관람객이 …

돈 받고 보여줄걸 그랬나

시간이 여유롭지 않은게 좀 문제였습니다. 무엇보다 운전자가 피곤한 장거리 운전이었습죠. 뭐 전 장거리 운전에는 익숙하니까 괜찮습니다만, 정동진에 가서도 여유롭게 산책하고 돌아다니다가 오지는 못했다는게 아쉽습니다. 너무 멀리 갔어요 ㅋㅋ

4시간 30분을 달려 정동진에 도착.

시간이 여유롭지 않은 관계로, 식사만 하고 출발하기로 했습니다.
원래는 영덕에 간 기념으로 영덕 대게라도 먹고 가려 했습니다만, 역시 시간의 압박으로 포기했습죠.
일정을 바꿀 걸 그랬나… 아닙니다. 바다는 보고 싶었어요. 저야 운전하느라 잘 못봤지만 승객들은 바닷가를 캠핑카로 달렸으니 좋아했습니다.

이 때 부터는 드디어 비가 쏟아지기 시작하더군요 ㅎㅎ 놀 거 다 놀고 비가 쏟아져 다행입니다. 덕분에 유리창의 벌레들이 모두 씻겨나갈수 있었네요.

저녁 8시까지 반납인데, 정확히 7시 정각에 반납완료. 5시간 걸렸네요.
이틀동안 운전한 시간이 약 15시간 반, 거리는 약 700km . 기름값은 22만원 …. ㄷㄷㄷ

다소 바쁘게 돌았다는 것 빼놓고는 모두 만족스러운 여행이었습니다. 가족들도 모두 다음에 또 가고 싶다고 했고…
다음에 갈때는 조금 여유를 두고 가면 재미있을 것 같네요 :)

특히 미오코리아와 굿타임 캠핑카 담당자분들께서 너무 친절하게 준비해주셔서 감사의 말씀을 안 드릴 수 없겠네요.
주변에 적극 홍보해야겠습니다.

자 그럼, 모처럼의 연휴에 가족들과 함께 즐거운 여행이었습니다. 끝 !

난생처음 캠핑카 여행기 2부

Tue, 10 May 2011 11:56:22 +0000

자 탈 박물관을 뒤로 하고 출발합니다.
두 번째 목적지는 영덕 해맞이 캠핑장.

캠핑카 숙박이 되는 곳입니다. 산 위라 경치도 좋고 바다도 보이고… 우결에 나왔다던가 뭐라던가 하던데 TV 안봐서 모릅니다.

이것이 또 3시간 40분 정도. 도착하니 거의 6시 가량 되었습죠.

캠핑카가 좋은 점 중 하나는 이렇게 가다가 먹을거리를 사서 갈 수 있다는 것.
지방에는 역시 하나로마트가 갑입니다.
농협 주유소도 봤고 농협 장례식장도 봤어요. 지방은 농협이 꽉잡고 있구만…

캠핑장 근처에는 마트가 없다니깐 미리 사가지고 가야 합니다.

캠핑장 도착. 오오 여기 멋지군요.

아 물론 여긴 캠핑장이 아닙니다. 여기서 차로 10분 정도 더 산꼭대기로 올라가야 캠핑장이지요.

가는 길은 공사중이라 오프로드 (…)

승객 여러분, 모두 꽉 잡으세요

캠핑장은 이렇게 생겼습니다. 캠핑카 2대가 주차가능.

처음에 가 보고서… 어라… 테이블이 없어….?

분명히 홈페이지에서는

이렇게 테이블이 있어서 대여 안해왔는데…????!?!??

관리사무소에 문의해보니, 많은 분들이 테이블을 가져오셔서 그냥 치워버렸답니다.
… 아니 그럼 공지사항에 올려 놓으시던가…

다행히 관리사무소 분이 매점용 테이블과 의자를 빌려주셔서 쓸 수 있었습니다.

캠핑장은 저렇게 생겼습니다. 저 아래 허연 것이 우리 캠핑카.

(사진찍은 시간이 멋대로인건 이해해주세요. 사진찍을 여유가 없었다니까요)

풍력 발전기 바로 밑입니다!

풍력 발전기에서는…

휭휭휭~~ 하면서 무서운 귀신소리가 납니다 !

전망 좋습니다. 바다가 보여야 하는데 안개가… ㅠㅠ

차에서 내렸지만 여전히 바쁩니다. 하수 시설과 외부 전기를 연결해야 하기 때문이지요. 목장갑 하나 가져올걸…

저기가 하수/상수 시설입니다.
관은 직접 준비해 와야 합니다.

전기 시설은 저기에.

산이라서, 모든 화기의 외부 사용을 금지하고 있습니다. 덕분에 숯불구이 바베큐 파티나 불꽃놀이는 곱게 접어 하늘위로.

전기시설 훌륭하네요. 비올때 등을 고려해서 아래에 구멍이 뚫려 있는 것도 마음에 들고.

수도시설은 저렇게 되어 있습니다. 녹색 튜브에서 물이 나오고… 저 관이 아마 하수관인가 봅니다.

캠핑카 하수관 위치를 맞춰 댑니다 .

후후 호스류는 여기에 있지요.

하수관은 직접 가져와야 한데서 캠핑카 사장님께 부탁했더니 하수관을 자작해서 만들어 주셨습니다! 짱 좋네요!

하수를 버릴 수 없는 환경에서는 저 마개를 닫고, 레버를 밀어줍니다. (하지만 용량이 작지요)

혹시모를 냄새방지를 한답시고 S자로 휘어 설치하는 부질없는 짓을 해 보았습니다. ..제대로 하려면 한 번은 거꾸로 휘어야지…
하지만 귀찮슈…

상수는 연결해 보려고 보니 직접 연결할 방법이 없네요.
그래서 그냥 수시로 물통으로 채워 옮기기로 했습니다.

물통도 차에 구비되어 있습니다.

평소엔 화장실에 있는 저 물통으로

저 취수구를 열고 물을 부어주면 됩니다. 약 100리터 정도 들어간다고 하던데, 100리터는 세수 두어 번 하고 설겆이 한 번 하면 끝나는 양이라서 제대로 쓰려면 수시로 채워줘야 합니다

그리고 여기서 릴선을 꺼내서 전기를 연결

신발장에 있던 전기선과 연결하여 외부 전기를 연결합니다.

릴선은 비올때나 이슬등을 대비하기 위해 차 아래에다가 집어 넣었습니다.

전기선 코드는 옛날 맥도날드에서 일할때 쓰던 코드와 같은 3구식이네요.
이제 전기와 물이 연결되었으므로 물을 펑펑 쓰고 전기를 자유롭게 써도 됩니다.

하지만 화장실은 다릅니다. 변기용 물은 완전히 분리되어 있어요.

저 버튼 두 개를 동시에 누르면 열립니다.

이것이 화장실용 상하수

화장실용 물은 여기에 따로 채워 넣어야 합니다.

이것이 변기통. 아래의 레버를 누르고 빼내면 빠집니다.

직접 가져다 버리면 됩니다.

음…

안되겠다 이건 사용금지. ㅋㅋㅋㅋ
화장실은 캠핑장 화장실을 사용합니다

급할 때 외엔 사용금지 잇힝

화장실 설명을 안했군요. 기본적으로 치약과 비누, 휴지는 구비되어 있습니다. 수건은 없으니 가져와야 해요

세면대에 샤워기로 물 받아서 사용하는 구조입니다.

온수를 쓰려면 컨트롤 판넬을 주의해서 봐야 합니다.

왼쪽부터 보일러 (히터) : 차 연료를 이용합니다. 한 칸 이상만 되어 있으면 겨울에도 충분하다고 합니다.
물용량 : 가득 채웠는데 3/4 까지밖에 게이지가 안올라 가더군요.
전기온수기 : 외부 전원을 연결했을때만 사용가능합니다. 특이하게 대부분의 스위치는 아래로 내리는 것이 켜짐.
배터리 : 외부 전원이 연결되니 14가 나옵니다. 그냥 시동으로 켰을땐 12쯤 나오고 , 11 아래로 떨어지면 시동을 걸어 충전시켜야 합니다. 10 아래로 떨어지면 배터리 보호모드 발동.
펌프 : 물 펌프입니다. 물 쓰려면 꼭 켜야 합니다.
메인스위치 : 말그대로.

세면대는 물을 받아서 쓰는 방식이고, 물을 다 쓰고 난 후 그냥 덮으면 물이 내려가는 방식입니다.
그래도 살살 덮어야 하더군요 ㅋ 팍 덮으면 다 샙니다.

아래는 사용금지인 변기

위의 레버가 중간벨브 (통이 차단됩니다. 냄새나 역류를 방지) 아래 스위치가 물 내려가는 스위치입니다.
급하게 사용하려면 일단 중간밸브를 열고 사용해야 합니다.

차가 흔들거려서 승객이 불편해 하길래 지지대를 내렸습니다. 저것도 잊어먹고 출발하면 큰일나는 것 중 하나지요.
확실히 흔들거림이 줄어드네요.

전기만 연결했는데 바로 고기를 구워버리는 성급한 식구들 ㅋㅋㅋ 차양막이라도 좀 펴자.

저 창문은 혹시 고기기름연기가 차안으로 들어갈까 두려워 닫았습니다.

차 안에 비치된 도구로 저 차양막에 연결해 돌리면 차양막이 열립니다.

지지대를 늘여놓으면 차양막 완성.

바람이 많이 불면 사용불가능 하겠군요. 신기하게도 캠핑장에는 바람이 거의 불지 않았습니다. 산꼭대기였는데도.
아 물론 잘때는 바람이 많이 불었지요. 잘때는 접어놔야 합니다. 잘못하면 꺾여요.

차양막이 꽤 넓어서, 꽤 넓게 펼칠 수 있습니다.

제가 전기와 수도를 연결하고 설정하는 동안 식구들은 식사준비를 합니다.
차 옆을 열면 저렇게 훌륭한 간이탁자가 됩니다.

화기는 사용금지라고 해서 전기구이팬을 가져왔습니다. 훌륭하네요.

날이 어두워지려고 해서 외부 등을 켰습니다. LED로 개조하셨네요. 전기도 적게 먹고 밝지요.
좀 더 큰 모델은 내부에 전자렌지가 있어서 편리할 것 같습니다. 전자렌지 그거 뭐 필요 있겠나 싶었더니
햇반을 데워 보니까 절실히 필요하더군요.

만약 다음에 빌린다면 꼭 전자렌지 있는 버전을.

캠핑장 모습입니다. 캡슐하우스가 보이네요.

식사후 식구들은 들어가고, 외부 정리 중 한 컷. 차양막은 잘 때는 접어야 합니다.
물통은 물을 가득 담아서 준비해서, 조수석에 올려놓습니다.

밤이 되자 풍력발전기 소리가 더욱 크게 들립니다.

2층 침대는 평소 이렇게 되어 있던 것이

펼치면 훌륭한 취침공간이 됩니다. 어른 3명은 여유롭게 잘 수 있습니다. 단 170 이상은 좀 ㅋㅋㅋ

아이들이 좋아할 줄 알았는데, 흔들거려서 무서워 하는군요. 아래층에서 조금만 움직여도 2층은 어쩔 수 없이 흔들립니다.
지지대를 내렸는데도 말이죠.

혹시 몰라 메뉴얼을 한 번 훑어 보았습니다만 다 알고 있는 내용이라…
아니 발판을 못 올리면 사고를 방지할 수 있다니요.. 이러지 마세요… ㅎㅎ

나 진짜 저런 거 보면 막 해보고 싶어진단 말야

아래도 침대모드로 변신시켜놓고 어른들은 아이폰 삼매경.

날이 춥지도 덥지도 않아서 보일러도 틀 필요 없이 2층 창문만 살짝 열어놓고 자는데도 충분히 쾌적했습니다.

수다떨다가 맥주먹다가 과자먹다가 TV보다 하면서 뒹굴뒹굴.

부엌 불켜놓고 한 컷

이렇게 캠핑초보의 첫날밤은 저물어갑니다.

난생처음 캠핑카 여행기 1부

Tue, 10 May 2011 10:44:21 +0000

넹 벼르고 벼르던 캠핑카 여행을 드디어 갔다 왔습니다.

왠 캠핑카 여행인가 하시는 분은 …

작년 12월에 아이폰용 GPS Car Kit를 리뷰한 적이 있었죠.

http://chulin28ho.egloos.com/5445694
http://chulin28ho.egloos.com/5449863

여기 리뷰 1등 부상이 캠핑카 1박 2일 대여권이었습니다.

리뷰가 끝나고 나서는 엄청 추운 겨울이었고, 2월이 되어서도 추위가 풀리지 않아서 거의 잊다시피 하면서 기다리다가 2월쯤에선가 미오코리아에 전화를 했더니 잊지 않고 기다리셨다면서 챙겨주셨습니다. 그렇지만 그때도 엄청 추웠던 관계로 …
결국 5월까지 미뤄졌었던 거죠. 거의 6개월이라는 기간을 잊지않고 챙겨주신 미오코리아 담당자분께 감사의 말씀 드리는 바입니다 :)

어쨌거나 캠핑카라…
제 게으른 성격으로는 사실 절대 이용할 일이 없었을 것 같은 물건이긴 합니다.
숙박할 수 있는 곳도 한정되어 있고, 같은 가격이면 팬션 빌려서 화장실과 숙박 모두 편하게 이용할 수 있는데 굳이 캠핑카를 이끌고 불편하게 여행갈 이유가 없다고 생각했던거죠.
편한 정도는 팬션 »» 캠핑카 »» 텐트 딱 이정도 느낌.

그치만 또 신기한 기계를 좋아하는 저로써는 한 번쯤 해보고 싶다는 마음이 없던것도 아니었고 말입니다. 아마도 다른 분들도 마찬가지실듯…

어쨌거나 출발합니다. 1부로 끝날지는 잘 모르겠습니다만 우후후

연락을 받은 업체는 굿타임캠핑카.
캠핑카쪽은 전혀 몰라서 조사해보니 상당히 평이 좋은 업체였습니다.
http://www.goodcampingcar.com/

자체 카페도 운영하고 계시고, 직접 사장님이 캠핑카 여행을 좋아하시는 분이신듯.

하남시에 있는 차고지 (인수받을 수 있는 곳은 여러 군데가 있습니다만, 하남시 감북동이 타고온 차를 주차해 놓을 수 있어서 제일 편하더군요) 에 가서 30분 정도 교육을 받고, 9시경 출발했습니다.

이것저것 꼼꼼히 하루 전부터 전화로 챙겨주셔서 일단 인상이 좋았습니다. 설명도 간략하게 잘 해주시네요. 너무 자세하게 설명하면 듣는 사람들이 쉽게 잊어버리죠. 중요한 것만 요약해 주셔서 , 미리 각종 여행기와 홈페이지의 설명 동영상을 숙지해 간 지식과 더하니 금방 이해가 되었습니다.

뭐 어쨌건 출발. 첨에는 차에 익숙해지느라 정신이 없어서 사진이 없습니다.
ㄷㄷㄷ 뭐야 이차.

주인아저씨가 ‘높은거 주의하세요, 그리고 브레이크 엄청 밀려요’ 라고 하셨는데…

이건 브레이크가 밀리는 레벨이 아닙니다

브레이크를 밟을 때에는 아랫배에 힘을 빡 주고 단전에서 온 기를 뿜어 올려 오른발에 집중해서 몸의 진정한 힘을 이끌어 낸 채 브레이크를 강하게 밟아줘야 겨우 차의 속도가 줄어듭니다.

…. 뭐야.. 몰라… 무서워 이거…

급정거는 당연히 무리. ㄷㄷㄷ 과속방지턱 넘을때는 완전히 정지하다시피 하고 넘으세요. 잘못하면 뒤에 탄 사람들이 호수의 물고기들처럼 펄쩍하고 튀어 올라오는 묘기를 부리게 됩니다.

고속도로 휴게소에 와서야 이제 차에 익숙해지고 여유가 생기더군요.

이 캠핑카는 캠핑카중 가장 작은 일반형 , 아톰 모델입니다. 바람이라고 불리더군요.
현대 리베로 (!) 를 기반으로 개조한 차이며, 7인승이라고 되어 있습니다.

현대 리베로라니 언제쩍 차여… 게다가 디젤이다… 우와… 디젤엔진이니까 진동이 심하겠네…
높이가 3미터나 되기 때문에 늘 신경써서 운전해야 합니다.

근데.. ㄷㄷㄷㄷ 이 오래된 단종차량의 정비/ 청소상태가 장난이 아닙니다.
실내 번쩍거리는거 보이시는지요.
저도 나름 차 깨끗하게 쓴다는 사람인데, 이건 뭐… 경악할 정도.

내부 왁스칠과 청소가 완벽하게 되어 있어서 미끄러질 지경입니다. (실제로 저 아래 발판에서는 몇 번 미끄러질 뻔…)
오래된 차라서 사실 별로 기대하지 않았는데 말이죠. 아우 눈부셔.

14만이라. 많이 달리긴 했지만 차량 상태가 이정도라면 훌륭합니다. 엔진상태도 좋고, 디젤이라 저속 토크도 훌륭합니다.
고속도로에서 오버드라이브 끄면 120까지 충분히 속도가 올라갑니다만 (3톤이 넘는 차가…) 그 정도 속도는 진동이 심해져서 곤란.

어시장 트럭 모는 느낌이긴 해요 ㅋㅋㅋ 넓고 높아서 좋네요.

우와 라디오다 ㅋㅋㅋ 저거 켜면 안테나가 자동으로 주욱 올라와요. 세피아때 보고 얼마만이야 ㅋㅋㅋ
센터페시아 아래쪽은 열면 커다란 함이 나옵니다.
차량 등록증 같은건 차에 없는듯.

X로드가 달려있습니다. 아마 폐업했죠 저기. 그래서 만도 맵피가셔서 업그레이드 해오셨답니다.
그래서 맵은 맵피. 오랜만에 맵피 써보니 많이 달라졌네요.

근데 … 네비게이션이 소리가 안나 OTL
사운드 설정을 다 찾아 들어가 봤습니다만 아마 뭔가 하드웨어적 문제가 있었던 것 같습니다.
근데 뭐 잘 보이는 위치인데다가 카메라 같은게 있으면 뻘건 불이 번쩍번쩍 해줘서 크게 문제는 없었습니다 .

옆의 저 모니터는 후방카메라 전용모니터네요. 후진기어를 넣으면 들어옵니다.
그 뒤에 하이패스도 장착. 근데 전 뭐 하이패스 안쓰니까.

창문열고 달렸더니 먼지가 앉았습니다. 아우 아까워라. 깨끗한 찬데.

이것이 후방카메라. 그 옆은 아마도 주방 후드용 배출기인듯 싶습니다.

운전석 뒤에는 리모콘 함과 차량 메뉴얼. (어차피 다 숙지하고 있어서 안봤지만요 ) 소화기, 삼각대 등이 있었고
조수석 뒤에는 자작하신듯한 휴지통 거치대에 휴지통이 있었고, 그 아래 공구함이 있습니다. 역시나 구석까지 먼지 하나 없어 ㄷㄷㄷ 뭐야 몰라 무서워 이거… ㄷㄷㄷㄷ

온열 시트도 있고(!)
본네트와 연료주입구 여는 곳은 저기에 있습니다.

아무리 후방카메라가 달려 있다고 해도 아래는 볼 수 있지만 위는 볼 수 없습니다.
차고가 3미터라는걸 잊으면 안돼요. 지하주차장은 근처도 가지 말아야 합니다.

운전하면서 이거 신경쓴건 처음이네요.

고속도로 톨게이트 갈때도 일반 톨게이트는 3미터 제한봉이 달려 있어서 못가고, 화물차 칸으로 가 줘야 합니다.

운전할 때마다 수시로 읊조렸습니다. 2시간마다 한 번씩 .

“나는 화물차다 나는 화물차다 나는 화물차다

나는 화물차다 나는 화물차다 나는 화물차다 "

코너 돌때도 크게 돌아야 합니다. 낮은 간판 주의해야 합니다. 후진할때는 반드시 조수석에서 한 사람이 뒤의 윗편을 봐줘야 합니다. 차가 높아서 휘청대므로 조심해야 합니다. 바람의 영향도 많이 받습니다 …..

실내가 너무 번쩍대니 사진에 안나올 지경.

조수석 자리에서 뒤를 보면 저렇게 되어 있습니다.

백미러는 아무 소용이 없으므로 TV를 볼 때 사용합니 (…) 아니 이건 한 번 장난쳐본겁니다. 용서해 주세요

차가 커서 버스 자리에 세워놓는게 좋습니다. 멀리서도 확연히 보이는 3미터의 위엄.

조금 작은 휴게소에 가면 한 분 정도는 꼭 실내를 구경해도 되냐고 물으신다는걸 주의하세요 ㅎㅎ

아 이쁘다 바람이. 신경쓸게 한 두 가지가 아닙니다만, 어쨌건 텐트보다는 편해유…

문을 열어보면, 저렇게 되어 있습니다. 실내에서는 신발 벗고 다녀야 해요. 저기가 신발장. 여기서 신발 벗고, 신발을 신발장에 넣고 들어갑니다. 신발장 위에 빗자루와 쓰레받이, 전기선이 보이네요.

문은 이렇게 생겼습니다. 어머 이국적이야.
미드에서 본 것 같은 문.

맨 위는 잠금장치, 중간은 여닫이장치, 아래는 모기장 문 찰탁 레버.
모기장만 닫아놓을 수 있게 되어 있는 것 같은데, 이상하게 모기장만은 고정이 안되더군요. 뭐 상관없슈.

문은 열어놓고 고정시킵니다. 기본적으로 캠핑카는 ‘모든것을 고정하게’ 되어 있습니다. 아무래도 흔들거리니까요 . 비행기와 닮았습니다 .

발판이 나옵니다. 운행시엔 잊지말고 원위치.

입구에서 보면 이렇게 생겼습니다. 왼쪽에 후드와 주방이 보이네요.
아래는 찬장과 미니냉장고.

정면에 보이는 물은 화장실 / 세면실입니다.

주방을 다시 보면 이렇게… 이건 작은 차라 2구짜리 버너가 달려 있습니다.

버너 아래의 스위치는 가스 밸브와 물 펌프 드레인 단자.

찬장은 이렇게 생겼습니다.
기본적인 식기와 수저들은 5인용이 구비되어 있습니다. 냄비 등은 없으므로 코펠 하나 가져오셔야 할듯.

아래는 부탄가스가 연결되어 있습니다. 총 5개까지 연결가능한 듯 하네요.
저희는 2개도 다 못썼지만.
주방세제와 수세미도 있습니다.

냉장고 용량은 대충 이 정도.

그렇게 올라가 보면 안에는 저런 모양입니다. 위에는 벙커베드. 변신해서 3인용 침대가 됩니다. 위에 에어컨도 보이네요.

아래는 테이블과 의자가 보입니다. 저기도 나중에 변신하지요. 제법 넓습니다.

거기서 뒤를 돌면 문 위가 보이고, 중앙 컨트롤 패널과 종이컵 홀더가 보입니다.
오른쪽에 저건 거미줄은 아닌데 뭐지. 빛 반사된 것인듯.

천장의 모습. 왼쪽의 선루프의 블라인드는 좀 낡았군요. 가운데는 등. 오른쪽은 팬입니다. 입/출력이 다 되는 양방향 팬이죠.
선풍기로도 환풍기로도 사용가능합니다.

역시 문 옆에는 작은 테이블이 있고, 외부 입/출력 단자와 전기코드가 있습니다. 12볼트 시거잭에 핸드폰 충전단자 기본 구비되어 있지요.

전기코드는 위의 것과 아래 것이 다른데, 위의 것은 차량전기를 인버터로 220 v 로 변환시켜 사용하는 전기코드입니다. 빨간 버튼이 인버터 버튼. 물론 큰 용량은 사용 불가능.

아래 것은 외부 전력이 연결되었을때만 사용가능한 코드입니다. (이 사진은 연결되어 있을때 사진입니다. 평소에는 사용 안돼요)

시거잭 코드가 하나 남는걸 보고 벨킨용 아이폰 충전기를 차에서 잽싸게 빼와서 연결했습니다 :)

외부 입출력이 되니까 미디어 장비 가져오셔서 연결하셔도 좋을듯.

자 기본적인 설명은 이정도로 하고 , 이제 또 출발하죠.
첫 목적지는 안동 탈 박물관입니다.

아이들과 오기로 예전부터 약속했던 곳.
평균시속 88km로 2시간 반이 걸렸군요.

오오 하회장터.

이 몸은 버스이자 화물차이므로, 일반 차량과 같이 주차하면 위험합니다.
지나가는 사람들이 모두 쳐다본다는 것도 감수해야 하는 차량입니다.

역시 상점이 제일 먼저 우리를 반깁니다.

근데 물건들이… 조금 괜찮은 것 들이 있긴 하네요

하회탈을 갈아넣은 초콜릿 (…?)

아니 이건 말고

꼭두각시 인형들의 퀄리티가 제법입니다.

아.. 병 이쁘다… 안동소주라던데

술 좋아하면 한두개 사가고 싶네요

간고등어의 가격.
비싼건가유

하회마을과 붙어있습니다만 시간이 없어 하회마을은 못갔고요. 탈 박물관만 갔습니다.

탈 박물관 입구 .

한국의 탈만 있는게 아니군요

이런 곳입니다.

하회탈이당

사자입니다.

오오 말뚝이다.

오오

해외의 탈도 있습니다. 이건 태국이었던가

중국의 탈

이것도 중국의 탈.

이렇게 탈 박물관 관람을 끝마치고 다시 출발.

일정이 조금 빡빡한 것 같다는 느낌이 슬슬 드는군요. 좀 더 여유롭게 잡을걸.
아니 뭐 운전하는 사람만 고생하면 되긴 합니다. 뒤에 탄 사람들은 편하다네요.

Rendering Statistics Window

Mon, 02 May 2011 11:14:05 +0000

Rendering Statistics Window

The Game View has a Stats button top right. When this Stats button is pressed, an overlay window is displayed with realtime rendering statistics. This is very useful for helping to optimize your game. The statistics displayed vary depending on your build target.
오른쪽 위 버튼 누르면 통계 나와요. 최적화할때 유용하지요. 이 통계표는 빌드 타겟에 영향받아요.

Rendering Statistics Window.

Statistics window contains the following information:


Time per frame and FPS	How much time it takes to process and render one game frame (and resulting FPS). Note that this number only includes frame update and rendering of the game view; and does not include time taken in the editor to draw the scene view, inspector and other editor-only processing.
Draw Calls	How many objects are drawn in total. This accumulates objects that are drawn multiple times as well, for example some object that is affected by pixel lights will add several draw calls.
Batched (Draw Calls)	Number of draw calls that where batched together. Batching means that engine will be able to combine rendering of multiple objects into one draw-call which leads to lower CPU overhead. To ensure good batching you should share as many materials between different objects as possible.
Tris and Verts	Number of triangles and vertices drawn. This is mostly important when optimizing for low-end hardware
Used Textures	Count and memory size of textures used when drawing this frame.
Render Textures	Count and memory size of Render Textures that are created. Also displays how many times active Render Texture was switched during this frame.
Screen	Size, anti-aliasing level and memory taken by the screen itself.
VRAM usage	Approximate bounds of current video memory (VRAM) usage. Also shows how much video memory your graphics card has.
VBO total	Number of unique meshes (vertex buffers) that are uploaded to the graphics card. Each different model will cause new VBO to be created. In some cases scaled objects will cause additional VBOs to be created. In case of a static batching however number of objects can share same VBO. 그래픽 카드에 올라가는 독립된 메쉬의 수 (버텍스 버퍼). 각각의 다른 모델은 새로운 VBO가 생기는데 원인이 된다. 어떤 케이스에서는 스케일된 오브젝트가 VBO증가에 이유가 되기도 한다. 스테틱 배치의 케이스에서는 어쨌거나 오브젝트의 개수는 같은 VBO를 공유한다.
Visible Skinned Meshes	How many skinned meshes are rendered.
Animations	How many animations are playing.

5층 워크샵 조별미션 사진

Sat, 30 Apr 2011 18:00:28 +0000

으아… 새벽 6시까지 타뷸라의 늑대와 달무티로 지새운 열혈워크샵.
무사히 잘 갔다왔습니다. 조별 미션사진도 완성.

다 좋았는데 야외 테스트를 안해서 OHP 필름 반사를 고려 안한게 아쉽.

검이 레알이라는게 특징.

팀원들과 장비를 나눠 착용후 테스트샷

머리 위에 이름표도 달았으면 좋았을텐데.

저 손은 제 손입니다. 잇힝

왼쪽 아래 식칼에 유의. 지금도 제 트렁크에 들어 있습니다 ㄷㄷㄷ

다른 조도 장난 아니었는데 찍은게 없음 ㅋㅋ

하지만 어쨌건 수많은 게임과 경쟁을 거쳐 최종으로 우리 조가 1등.

야호. 상장과 부상.

누구냐 저 글씨쓴게.

5층 워크샵 참가준비

Wed, 27 Apr 2011 22:21:17 +0000

우허허 어쩌다보니 3주 연속 주말마다 워크샵을 떠나게 되었습니다. 첫 주는 6층 프로젝트팀 워크샵, 저번주는 외부 단체 워크샵, 이번주는 5층 프로젝트팀 워크샵. TA들은 특별히 양쪽 팀에 밀접하게 연관이 되어 있고, 사람들과 친밀도를 올리는게 무엇보다 중요하기 때문에 이런 일에는 적극적으로 참여해야만 하지요.

그리고 조별 미션이 주어졌다는데… 같은 계열 자회사의 게임인 서든어택을, 포토샵 후보정을 거치지 말고 즉석에서 사진으로 표현하라더군요. 우후후후후…. 쪼오아. TA의 잔머리를 보여주지… 절대 평범하게 할 수 없다…

몰래 해도 되지만 다른 조들을 불지르기(?) ㅋㅋㅋ 이왕 할거면 재밌게 해야지요.
일단 뭐 총은 이미 준비해 놨고, 나머지야 뭐 대충 되겠고. 진짜 대충 하려면 총만들고 대에 - 충 찍으면 되겠지만 우후후
이상한 짓 시작해 봅니다. 바로 서든어택의 UI 를 아날로그로 구현!!!!

일단 적절한 서든어택 스크린샷 물색. 나 저녁에 이게 뭐하는거냐 이게 ㅋㅋㅋㅋ

인터페이스만 잘 따내서 이미지를 만듭니다.

수많은 테스트와 삽질의 흔적중. 좋아좋아. 가능성이 보여.

일단 A4 지로 테스트 해 봅니다.

굉장히 가까이에 있기 때문에 조리개를 최대로 조여서 포커싱 레인지를 크게 만들어야 합니다. 최대가 22밖에 안되는게 초큼 서운. 아 역시 SLR을 사야 돼. 하이브리드로는 한계가…
찍는날 날이라도 흐리면 어떡하지… 에이 몰라. 일기예보는 괜찮군요.

여러 번의 테스트 끝에 사이즈 Fix.

이제 본격적으로 OHP 필름에 프린트 !!!!!
3장 사왔는데 한 장만에 성공!!!

투명도가 조금 떨어지니까 정말 밝은 야외에서만 찍어야겠군요.

잘 나왔습니다.

미리 정해놓은 가이드 라인에 맞춰서 테이프로 잘 붙여줍니다.

테스트샷. 오케이.

완성!!! 어두운 밤 방안에서 이정도 나왔으니, 밝은 야외에서 찍으면 제대로 겠지요!!
카메라 후드에 테이프로 고정해 놨으니, 이제 후드만 조심히 모셔가면 됩니다 으핫핫핫핫

손에 든 건 타블렛이 아니라 칼입니다 칼. 휙휙.

Bumped_FakeSpecular

Wed, 27 Apr 2011 15:47:49 +0000

배경에는 캐릭터처럼 복잡한 쉐이더를 만들기 힘듭니다.
터레인이나 나무, 라이트맵등을 비롯한 워낙 많은 어셋들이 연관되어 있고, 하나 설정을 바꾸면 나머지도 다 어울리게 바꿔줘야 하는지라 관리가 엉망이 되거나 엄청난 부하를 유발시키기 쉽지요. 그리고 복잡한 쉐이더로 섬세하게 사용하기에는 너무 작은 오브젝트가 많은 관계로 , 단품의 독립적인 퀄리티업을 해도 되는 캐릭터와는 달리 배경용은 그다지 심하게 복잡한 쉐이더는 사용하지 않는 것이 별로입니다.

그래도 최소한의 것들은 있어야 하기 때문에 몇 가지 쉐이더들이 제작되었습니다만..
그래도 아직 부족한 것이… 어두울때 노말이 잘 안보인다는 것입니다. 캐릭터라면 IBL이나 뭐다 해서 해결하겠지만 배경에 그렇게 복잡하게 하는건 별로이고… 다이나믹 라이트도 있으니까 말이지요.

그래서 간단하고 가볍지만 , 이런 문제를 해결할 수 있는 쉐이더인 Bumped_FakeSpecular 쉐이더입니다.

목표는 초 간단. 보통 쉐이더에, 이렇게 그늘진 부분에 노말이 나타날 수 있도록 해 주는 목적입니다. 위 그림에서와 같이, 어두운 부분의 벽면에 있는 노말맵이 잘 나타나지 않습니다.
밝은 부분에는 잘 나타나는데 말이죠.

그래서 추가한 기능, Fake Specular 입니다. 이름에서 말하듯, 진짜 라이트를 이용하여 계산하는 방식이 아닌 가짜 스페큘러 추가입니다. 강하게 하면 보시다시피 ‘금’ 같은 느낌이 나지요.

원리는 마치 카메라 방향에 조명이 하나 더 있는 듯, 바라보는 방향에 직각이 되는 면에 스페큘러가 나타나는 방식입니다.
세상의 모든 것에는 어느 정도나마 스페큘러가 있고, 이를 필요한 곳에만 보여주는 방식입니다. 물론 이렇게 강하게 하면 안되겠지요.

이렇게 좀 퍼뜨려 주고, 조금 둔탁하게 해 줍니다. 그러면 노말도 보이고, 살짝 살짝 움직일때마다 입체적인 질감도 나타나게 됩니다. 벽과 기둥을 보세요

스페큘러의 칼라와 넓이를 조절할 수 있게 되어 있습니다.

근데 문제가, 이렇게 보이는 부분에 스페큘러를 추가시키면 이미 밝은 부분에도 추가되어 하얗게 타버리게 됩니다.

그래서, 밝은 부분은 효과가 안나오게 만들었습니다 :)
빛을 받는 각도에서는 자동으로 이 효과가 없어져 버리브로, 밝은 부분은 이전과 동일하게 나옵니다.

이걸 사용하면 이런 것들이 가능한데요.

브라소프 정원(이던가) 에서 빛이 닿지 않는 부분을 보면 저렇게 보입니다. 노말의 영향이 거의 안보이지요.

이 쉐이더를 쓰면 위와 같이 저런 이미지를 만들 수 있습니다. 노말맵이 강조됩니다.

덤으로 이런 이미지도….

위와같이 됩니다. 저 멀리 있는 둥근 탑의 디테일을 보세요. 세로로 하이라이트가 맺혀져 있습니다.

Main Charactor shader 제작완료

Mon, 25 Apr 2011 12:13:54 +0000

대단한 기술은 쓰지 않았습니다. 어디까지나 기본에 출신. 웹게임이니까요 ㅋㅋ
용량을 줄이기 위해 노력했고, 가능한한 적은 용량으로 좋은 결과물이 나오도록 했습니다.

쉐이더 계산은 용량이라기 보다 GPU 연산에 달려 있으니까요. 아무래도 그쪽에 의지하게 되었죠.

일단 완성된 쉐이더.

우선 기존의 쉐이더를 보겠습니다.
기본으로 들어있는 쉐이더인 Bumped Diffuse.
말그대로 노말맵과 Base Texture만 있는 기본쉐이더.

일단, 기본쉐이더는 너무 어두워서 쓸 수가 없습니다. Main Color를 가장 밝게 한 것임에도 불구하고.
그래서 기본 쉐이더를 쓰려면 어쩔 수 없이 Self illumination 쉐이더를 사용해야지요.

Self - illumination 쉐이더중 Bumped specular 입니다. 좀 밝아졌고, (여기서 더 올리면 타버립니다) 노말맵도 허벅지나 스카프 등에서 좀 보입니다만 여전히 너무 어둡고 배경과 이질감이 납니다.

아마 쉐이더 관리자가 없는 회사라면, 여기서 끝나는게 정상일 겁니다.
그렇지만 우린 아니지요.
그럼 이제 본격적 분석 들어갑니다.

이 쉐이더에서 텍스쳐만 없애본 상태입니다. (그냥 없애기만 하면 하얗게 날라가기 때문에 약간 main color를 낮췄습니다)
이런 기본 쉐이더들의 문제는 열심히 만든 노말맵이, 빛이 닿지 않은곳에 가면 전부 다 날라간다는 것입니다.
어두운 부분을 보시면 전부 회색으로 되어 있지요.

이런 부분을 극복하는 것은 커스텀 쉐이더를 제작할때 가장 기본적으로 고려되어야 하는 부분입니다.
다른 게임도 마찬가지 문제를 극복하도록 노력했죠.

테라에서는 IBL (Image Based Light) 기법으로, 큐브맵을 만들어서 환경광을 추가해 노말맵이 보일 수 있도록 만들었고,

미국 GDC에서 봤던 스타워즈 온라인에서는 팀 포트리스2 에서 사용한 것과 같은, 칼라 그라디언트를 이용한 텍스쳐 와핑 (Texture Warping) 을 사용해서 극복하려 했습니다.
크흑 미국 갔다온 보람이 있어

그런데 둘 다 텍스쳐를 (작지만) 사용하는 녀석이라, 지역마다 이 텍스쳐를 관리해 줘야 하고 수동으로 만들어 줘야만 합니다.
뭐 만드는건 크게 어렵지는 않습니다만 나름 귀찮아지는 데다가 텍스쳐 개수가 많아져서 I/O와 전송량을 조금이라도 차지한다는게 문제… 우리는 웹게임이므로 이것마저도 줄여보기로 결심했습니다.

그래서 사용한 것은 아주 기본적인 글로벌 라이팅 원리인 hemisphere lighting (반구조명) 방식입니다.

이 방식은 너무나도 간단한 원리로,

Color = a · SkyColor + (1 - a) · GroundColor

라는 공식을 이용하며
2개의 색을 정해놓고 하나는 하늘색 (천반구) 하나는 땅 색 (지반구) 로 결정한 다음,
Normal 방향이 어느 쪽을 바라보느냐에 따라 두 색을 적절한 각도에 맞는 색으로 보여주는 방식입니다.

텍스쳐는 전혀 사용 안하며, 어차피 노말맵을 사용하므로 있는 노말맵을 이용해서 2개의 색만 정해주면 끝납니다.
물론 큐브맵을 사용하는 IBL이나 Warping보다 조금 덜 복잡한 색이 나오게 됩니다만, 경험상 그렇게 큰 구분이 나오지도 않기 때문에 지금은 한물 간지 오래 된 이 구식 방식으로도 충분히 결과물이 나올 것이라 생각했습니다.

정말 쉽죠?

그렇게 해서 제작해 보았습니다.

새로 만든 쉐이더. Specular도 없이 그냥 Diffuse 상태입니다. 노말맵만 적용된. 이번엔 라이팅도 특별하게 제작하지 않고, 기본 라이팅을 사용하였습니다. (그래야 호환성이 좋아요)

여기에 위에서 말한 천반구 조명을 추가해 보겠습니다.
여기의 하늘은… 약간 녹색끼가 추가된 파랑색이로군요. 그리고 사막 지형이라 공기가 맑고, 강하게 내리쬘 겁니다. 이런 경우에는 보통 천반구의 색 영향이 강하게 들어오지요. 좀 강하게 넣어 보겠습니다.

영향을 좀 더 잘 보이게 하기 위해 그늘로 자리를 옮겼습니다.
그리고 천반구(하늘) 색을 넣어 보았습니다.
음영진 부분이어서 노말이 전혀 보이지 않던 부분까지도 노말이 보이기 시작합니다.

이번엔 반대로 지반구(땅 색깔) 을 추가!
특히 햇살이 강하게 내리쬐는 이런 사막 환경에서는, 땅 색깔이 강하게 반사되어 쳐 올라오곤 합니다.

물론 이 색상값들은 유동적으므로, 기후변화나 위치변화에 따라 얼마든지 바뀔 수 있습니다.
이렇게해서 GI 효과가 심플하게 완성되었습니다. 이전보다 화사하고 노말도 잘 보이고 따뜻합니다.

그다음 스페큘러 효과 추가.
위 그림에

이 스페큘라를 더하면

이렇게 됩니다.

그리고 거기에 다시 2차 스페큘러 추가.
원래 니시카와 젠지씨가 쓴 소닉 게임 기술에서 봤던 기법인데, 요즘 게임들은 너나할것 없이 쓰고 있더라고요 ㅋ
이 계산법도 꽤나 간단한 법입니다. 기존에 스페큘러 계산했던 공식을 재응용하여 카메라 방향에서 가짜 조명을 하나 더 쏘고 있는 것처럼 보이게 해서 입체감을 살리게 하는 방법인데요, 실제 방송에서도 자주 볼 수 있는 기법이기도 합니다.

물론 테라에서도 사용했더라고요. 역시 세상에 나만 아는 지식따윈 없어!

하지만 우린 그냥 심심하게 스페큘러를 단색으로 사용한 것이 아니라, 여기에 다시 Hemisphere lighting 색상을 곱해, 반구조명에서 나오는 은은한 색상임을 강조하였습니다. AD나 파트장이나 과도한 오바 색감보다 은은한 색감을 좋아하니, 튀는 느낌을 자꾸 주면 좋지 않겠지요.

즉 이렇게 말입니다. 반구조명 색상의 영향을 받고, 거기에 다시 스페큘러 색상이 곱해집니다. 흰색으로 하게되면 위와 같이 되겠지요.

이렇게 된 결과물을 다시 더하면,

좀 더 복잡미묘한 결과물이 됩니다.
노말맵도 좀 더 확실히 보이구요.

여기에 다시 외각을 강조하는 림라이트 추가. 이전의 림라이트가 너무 색상이 강해서 글로우 같은 느낌이었다면, 여기서는 다시 Hemisphere light 값을 곱해서 부드럽게 만들어 주었습니다.

테라에서 사용된 림라이트도 IBL과 각종 텍스쳐 색상, 마스킹에 따른 반응을 하게 되어 있습니다만 스페큘러 패스라서 반짝반짝 빛나는 느낌의 림라이트입니다. (때문에 라이트 디렉션 부분에서만 더 강하게 나타나게 되어 있는 방식이지요)
하지만 우리는 그것보다는 이미지를 좀 더 차분하게 만들어주면서 배경과 분리할 수 있도록 하였습니다.

이렇게요.

이걸 다시 더하면.

(디렉셔널 라이트 * 반구조명) + 스페큘러 + 가짜 스페큘러 + 림라이트

이제 여기에 텍스쳐를 곱해줍니다.

(텍스쳐 * 디렉셔널 라이트 * 반구조명) + 스페큘러 + 가짜 스페큘러 + 림라이트

여기에 마지막으로 리플렉션!!!

리플렉션을 하기 전에 주의해야할 사항이 몇 개 있는데요.

일단 우리는 노말맵이 다릅니다. 주의하세요 캐릭터팀.
일단 노말맵 색상 자체가 다릅니다.
이렇게 생겼어요
파랑색이 빠져 있습니다! 이유는 노말맵이 만들어 지고나서 R과 G는 그냥 사용하지만, B 채널은 사실 거의 1값이기 때문에 계산에 큰 영향을 끼치지 않기 때문인데요, 때문에 공식 자체가 R과 G를 계산하지만 B는 그냥 1이라고 강제로 넣어버리는 방식으로 되어 있습니다.
o.Normal = float3(NormalTex.r,NormalTex.g,1);

때문에 노말맵의 파랑색은, 스페큘러 마스킹으로 사용하게 됩니다! 그냥 놔두면 전체에 스페큘러가 먹어 버리기 때문에 반드시 blue는 검은색으로 처리해 주시구요, 스페큘러가 필요한 부분에만 흰색으로 칠해주시면 되겠습니다.

이렇게 해서 채널 하나를 절약할 수 있게 되는 거지요..

하지만 이 때문에 정말 중요한 한 가지가 있습니다!
우리 노말맵은 노말맵이 아니라 텍스쳐라는 것입니다!

유니티 이녀석이, 텍스쳐 타입을 노말맵으로 하면…
자기 멋대로 노말맵 계산 공식을 내부에서 만들어 버려서, blue 값을 다른데 사용할 수가 없게 만들어 버립니다. 마구 뒤섞더군요.
때문에 저희는 노말맵 계산 공식으로 유니티 것을 사용한게 아니라 자체적으로 만들어 썼기 때문에 유니티에게는 노말맵이라고 가르쳐 줘서는 안됩니다. 노말맵이라고 가르쳐 주는 순간, 얘네는 자기네 포맷으로 이미지를 재정렬 시켜버려서 엉망이됩니다. (이거 찾느라 고생을 좀…)
그러므로 반드시 텍스쳐로 설정해 주셔야 합니다. (원래 노말맵 자리에 일반 텍스쳐를 넣으면 워닝이 뜨게 되어 있습니다만, 이름을 바꿔서 피해갔습니다)

그리고 노말맵의 알파 채널은, 리플렉션 마스크로 사용됩니다.

이것때문에 조금 불편한게 생겼는데요.
아래 그림을 보시죠.
어깨와 가슴을 리플렉션을 주기 위해 마스킹 설정을 한 것을 알 수 있는데요,
이것은 특이하게도 스페큘러 마스킹때와는 반대로 흰색 바탕에 검은 색을 칠해주어야 효과가 납니다!!!!

이렇게 만든 이유는, 리플렉션이 필요 없을 때에는 아예 알파 채널을 만들어 주지 않으면 되는데, 아예 만들어 지지 않으면 알파 채널이 ‘흰색’ 으로 채워진 것으로 자동으로 인식하기 때문입니다. 즉. 알파 채널을 만들어 주지 않으면 전체가 리플렉션이 먹어 버리는 현상이 일어나게 되지요.

이것은 모든 텍스쳐를 만들때마다 검은색으로 알파를 일일히 넣어줘야 하고, 일부 버전의 포토샵에서는 그렇게 저장하면 저장이 안되는 문제도 간간히 생기기 때문에 매우 귀찮게 됩니다.
때문에 리플렉션에 한해서는 (노말의 알파를 이용하는 녀석) 흰 색 바탕에 검은색으로 표시해 줘야 효과가 나오게 만들어 놓았습니다. 이렇게 하면 리플렉션이 필요 없으면 ‘그냥 알파 채널을 만들지 않기만 하면’ 되는 것이니까요. 오히려 혼동이 적습니다.

좀 더 심플하게 만들고 싶었는데, 일단 이게 가장 그나마 실수를 줄일 수 있는 방법이라 생각했습니다.

어쨌건 리플렉션 마스킹 추가.
금속이 반짝반짝.
기본 텍스쳐와 곱해집니다.
이건 움직여야 이뻐요 ㅋ

이렇게 리플렉션까지 연산되어 나온 최종 결과물.

밝은 빛 아래에서. 좀 타긴 합니다. 블룸값 수정을 해야 할지도.

그늘로 들어가도 라이팅 디테일이 잘 보입니다.

등짝을 보자.

멀리서 봐도 잘 보입니다.

SSAO 까지 추가된 최상급 버전의 이미지.

알파 테스팅 버전과 노 알파 버전이 커밋되어 있습니다. 한번 사용해 보세요.

이제 기본은 되었고… 이어서 남은 작업은 다음과 같습니다.

SSS 추가 : 피부 색감보정을 위해서 작업이 추가될 것 같습니다. 어쩔 수 없이 마스킹 때문에 텍스쳐 한 장이 추가될지도… 크흐흑. (아니, 아직 일러! 알파 없는 쉐이더의 메인 텍스쳐의 알파 채널을 이용하자!)
염색 추가 : 염색이 추가될 부분의 기획을 다시 봐서 추가해야겠습니다. 텍스쳐를 안쓰려면 버텍스 칼라로 해야 하나…? 안되겠네요. 이건 추가 해야겠네.
알파 블렌딩 쉐이더 추가 : 어렵지는 않을것 같은데 해봐야 알겠어요. 주인공은 안쓰겠지만 몬스터 같은 녀석들을 위한 좀 더 가벼운 버전의 쉐이더를 만들어야겠지요.
기존에 만든 건물과 이펙트 쉐이더 재조정 : 으아아아아아아아아.

ATI Radeon programming guide

Sun, 24 Apr 2011 15:59:09 +0000

오즈라엘님 블로그에서 트랙백.
언젠가 쓸모가 있겠징
ㅋㅋㅋ ATI Radeon programming guide


		Advanced DX9 Capabilities for ATI Radeon Cards - whitepaper (July 2009)
Illustrates:	This white paper gives implementation details on some of the advanced capabilities exposed by Radeon graphic drivers under the DirectX 9 API. Those capabilities target a feature level not directly exposed by DirectX 9, and therefore require an additional programming interface to take advantage of them.


		ATI Radeon HD 2000 Programming Guide (June 2007)
Illustrates:	This paper discusses general optimization hints and best practices for programming the latest ATI Radeon HD 2000 series hardware. It covers topics such as shaders, texturing, z optimizations, D3D10 optimizations etc.


		Depth In-depth (June 2007)
Illustrates:	This paper goes through the Z optimizations in current and earlier hardware. It explains the technical details behind techniques such as Hierarchical-Z and Early-Z and discusses the how to best utilizing these hardware optimizations.


		R2VB Programming (March 2006)
Illustrates:	This technology paper describes how to use the Render to Vertex Buffer technique to accelerate animation.


		Radeon X1x00 Programming Guide (March 2006)
Illustrates:	Radeon X1x00 Programming Guide

page :

http://developer.amd.com/gpu/radeon/pages/radeonsdksamplesdocuments.aspx

AT2/Char/Main

Fri, 22 Apr 2011 16:58:35 +0000

구시대 쉐이더. 버린것. 백업.

Shader “AT2/Char/Main” {

    Properties {
_Color (“Main Color”, Color) = (1,1,1,1)
_SpecColor (“Main Specular Color”, Color) = (0.5, 0.5, 0.5, 1)
_Shininess (“Main Shininess (Normal.b)”, Range (0.01, 1)) = 0.078125
_SpecColor1 (“View Direct SpecColor (Only Forward)”, Color) = (0.5, 0.5, 0.5, 1)
_Shininess1 (“View Direct Shininess (Normal.b)”, Range (0.01, 1)) = 0.078125
_RimColor (“Rim Color”, Color) = (0.26,0.19,0.16,0.0)
_RimPower (“Rim Power”, Range(0.5,8.0)) = 3.0
    _MainTex (“Texture”, 2D) = “white” {}
_BumpMap2 (“Normal Texture(RG)”, 2D) = “grey” {}
_Cutoff (“Alpha cutoff”, Range (0,1)) = 0.0
_GiLight_Top (“GiLight Top”, Color) = (0.5,0.5,0.5,0.0)
_GiLight_Bottom (“GiLight Bottom”, Color) = (0.5,0.5,0.5,0.0)
_WorldLightDir(“WorldLightDir”, Vector) = (0,-1,0,1)
_DyeColor (“DyeColor (Normal.a)”, Color) = (0.5,0.5,0.5,0.0)

_RimColor2 (“Rim Color2”, Color) = (0.26,0.19,0.16,0.0)
_RimPower2 (“Rim Power2”, Range(0.5,8.0)) = 3.0
    }

    SubShader {

    Tags {
  //~ “RenderType” = “Opaque”
  “RenderType”=“TransparentCutout”
  //~ “Queue”=“Geometry”
  //~ “Queue”=“Transparent” //활성시 디퍼드 라이팅 동작 꺼짐
  “IgnoreProjector”=“True”
  }
LOD 600

    Cull Back
ZWrite On



// Start CGPROGRAM /////////////////////////////////////////////////////////////////////////////////////////
    CGPROGRAM

uniform float4 _Color;
//~ uniform float4 _SpecColor; //이미 정의되어 있어서 굳이 할 필요 없단다.
uniform float4 _SpecColor1;
uniform float _Shininess;
uniform float _Shininess1;
uniform float4 _RimColor;
uniform float _RimPower;
uniform float _Cutoff;

uniform sampler2D _MainTex;
uniform sampler2D _BumpMap2;

uniform float4 _GiLight_Top;
uniform float4 _GiLight_Bottom;
uniform float4 _WorldLightDir;
uniform float4 _DyeColor;

uniform float4 _RimColor2;
uniform float _RimPower2;

#pragma surface surf SimpleLambertJP
#include “UnityCG.cginc”
#pragma target 3.0 // it’s for prevent “arithmetic instruction limit” -JP-

//Forward rendering light term ——————————————————————
inline half4 LightingSimpleLambertJP (SurfaceOutput s, half3 lightDir, half3 viewDir, half atten)
   {
  half4 c;

  // rim factor———————————————————————————————–
  //~ float rim = pow(1- dot(s.Normal, viewDir),_RimPower);
  //~ half3 rimlight = rim* _RimColor.rgb;

  // Rambert factor——————————————————————————————
  half NdotL = saturate(dot (s.Normal, lightDir));

  // Specular factor——————————————————————————————
  half3 h = normalize( lightDir + viewDir );
  float nh = saturate( dot( h, s.Normal ) );
  float spec = pow( nh, s.Specular ) * s.Gloss;

  // View Direction Specular factor——————————————————————————————
  float nh1 = saturate( dot( viewDir, s.Normal ) );
  float spec1 = pow( nh1, _Shininess1*128 ) * s.Gloss;

  //fake light———————————————————————————————–
  //~ half3 GlTerm = saturate(CalculateGiLight(L1, s.Normal, _GiLight_Top)) ;
  half GlTerm =dot(s.Normal, _WorldLightDir.xyz)*5+1;// It’s for negative light. Don’t use saturate
  half3 GIColor = lerp (_GiLight_Bottom,_GiLight_Top,GlTerm)- half3(0.5,0.5,0.5);

  // Final Calculation ——————————————————————————————
  c.rgb = s.Albedo *_Color* _LightColor0.rgb * ((NdotL * atten * 2) + GIColor) ;
  c.rgb += _SpecColor.rgb * spec;
  c.rgb += _SpecColor1.rgb * spec1;
  //~ c.rgb += rimlight;
        c.a = s.Alpha;
        return c;
      }


//Deferred rendering light term ——————————————————————
/- inline half4 LightingSimpleLambertJP_PrePass (SurfaceOutput s, half4 light)
{
  half4 c;

  half3 spec = pow( light.a ,_Shininess + 0.4) *_SpecColor.rgb * s.Gloss ;
  //fake light———————————————————————————————–
  //~ half3 GlTerm = saturate(CalculateGiLight(L1, s.Normal, _GiLight_Top)) ;
  half GlTerm =dot(s.Normal, _WorldLightDir.xyz)*2+1;// It’s for negative light. Don’t use saturate
  half3 GIColor = lerp (_GiLight_Bottom,_GiLight_Top,GlTerm)- half3(0.5,0.5,0.5);

  c.rgb = (s.Albedo*_Color * light.rgb )+ GIColor;
  c.rgb += spec;
  c.a = s.Alpha + Luminance(spec);
  return c;
}
*-


      struct Input {
        float2 uv_MainTex;
        float2 uv_BumpMap2;
  float3 viewDir;
      };

      void surf (Input IN, inout SurfaceOutput o) {

  half4 MainTex = tex2D (_MainTex, IN.uv_MainTex);
  clip(MainTex.a - _Cutoff);
  //—————————————————————-
  //Normal1 method : NormalMap, Traditional method
  //—————————————————————-
  //~ half4 NormalTex = tex2D (_BumpMap, IN.uv_BumpMap);
  //~ half3 UPNormal =UnpackNormal(NormalTex);
   //~ o.Normal = UPNormal;

  //—————————————————————-
  //Normal2 method : Texture , Old (Gamebryo) method
  //—————————————————————-
  half4 NormalTex2 = tex2D (_BumpMap2, IN.uv_BumpMap2);

  /- if ( 1.0 == sign(IN.uv_BumpMap2.x-1.0f) )
{
  o.Normal = (half3(NormalTex2.r,NormalTex2.g,1)*2.0f-1.0f);
  o.Normal = normalize(half3(-o.Normal.r,o.Normal.g,o.Normal.b));

}
else
{ *-
  o.Normal = normalize(half3(NormalTex2.r,NormalTex2.g,1)*2.0f-1.0f);
//~ }
  //—————————————————————-

  // Rim ————————————————
  float Fresnel= 1.0 - dot( normalize( float4(IN.viewDir, 1.0).xyz), o.Normal ) ;
  float rim = pow(Fresnel,_RimPower);
  half3 rimlight = rim* _RimColor.rgb;

  // Rim2——————————————————————
  float rim2 = pow(Fresnel+0.1,_RimPower2);
  half3 rimlight2 = rim2* _RimColor2.rgb;

  //DyeColor —————————————————–
  half3 Albedo;
  half3 Dye = (1.0f - ((1.0f - _DyeColor) * (1.0f - MainTex.rgb)))*2-1;
  Albedo = lerp (Dye,MainTex.rgb,NormalTex2.a);

  o.Gloss = NormalTex2.b;
  o.Specular = _Shininess * 128;
        o.Albedo = Albedo ;
  //~ o.Emission = rimlight;
  //~ o.Emission = lerp (rimlight,rimlight2,rim2);
        //~ o.Albedo = half3(1,0,0);
  //~ o.Alpha = MainTex.a;
  o.Alpha =1;

      }

      ENDCG
// End CGPROGRAM /////////////////////////////////////////////////////////////////////////////////////////

    }

Fallback “Diffuse”
}

꽃놀이 갔다왔슈

Thu, 21 Apr 2011 08:29:21 +0000

어느새 회사 전통이 되어 버린 봄 꽃놀이.
올해는 이런저런 사유로 좀 늦었네유. 저번주에 갔으면 좋았을텐데

아아 이 불규칙한 성비율이란…

꽃이 많이 졌어유

비가 와서인듯

레어 아이템 발견

날씨는 참 좋군요 바람도 산들산들

좀 더 많이 피었을때 왔으면 좋았을 것을

저녁 모임은 팀원들과 비비큐 본사 카페 (!) 에서 닭과 맥주.
유명한 치킨명소라더니, 과연 육질이 다르군요.

끗.

꽃놀이_ 프로그램 2팀

Thu, 21 Apr 2011 07:43:50 +0000

이제는 어느새 회사의 전통이 되어 버린 꽃놀이..
저번주에 갔어야 했는데 좀 늦었죠.

돌아가는 버스같은건 없습니다.

꽃이 많이 졌슈

레어 아이템 발견

줌렌즈 사주세요 ()

아 날씨 좋다.

주의————————–

경고했음 ———————————

넌 특별히 두 장.
얼굴빨개지지 마

여기서부터는 인증샷

BBQ 본사. 치킨명소로 유명한 곳.

인증샷1

반대로. 총 9명. 명근팀장이 계산.

끗.

Unity Direction : UnityCG.cginc

Wed, 20 Apr 2011 11:22:26 +0000

이것뿐?

// Computes world space light direction
inline float3 WorldSpaceLightDir( in float4 v )
{
float3 worldPos = mul(_Object2World, v).xyz;
#ifndef USING_LIGHT_MULTI_COMPILE
  return _WorldSpaceLightPos0.xyz - worldPos * _WorldSpaceLightPos0.w;
#else
  #ifndef USING_DIRECTIONAL_LIGHT
  return _WorldSpaceLightPos0.xyz - worldPos;
  #else
  return _WorldSpaceLightPos0.xyz;
  #endif
#endif
}

// Computes object space light direction
inline float3 ObjSpaceLightDir( in float4 v )
{
float3 objSpaceLightPos = mul(_World2Object, _WorldSpaceLightPos0).xyz;
#ifndef USING_LIGHT_MULTI_COMPILE
  return objSpaceLightPos.xyz - v.xyz * _WorldSpaceLightPos0.w;
#else
  #ifndef USING_DIRECTIONAL_LIGHT
  return objSpaceLightPos.xyz * unity_Scale.w - v.xyz;
  #else
  return objSpaceLightPos.xyz;
  #endif
#endif
}

// Computes world space view direction
inline float3 WorldSpaceViewDir( in float4 v )
{
return _WorldSpaceCameraPos.xyz - mul(_Object2World, v).xyz;
}

// Computes object space view direction
inline float3 ObjSpaceViewDir( in float4 v )
{
float3 objSpaceCameraPos = mul(_World2Object, float4(_WorldSpaceCameraPos.xyz, 1)).xyz * unity_Scale.w;
return objSpaceCameraPos - v.xyz;
}

World normal calculate in Unity Shader

Wed, 20 Apr 2011 11:19:57 +0000

유니티에서 월드 노말 구하기
정말 이 방법 뿐인가? 이녀석들은 노말맵을 자기들이 다 알아서 관리해서…

struct v2f
   {
    float4 color : COLOR;
    float4 vertex : POSITION;
    float4 uvgrab : TEXCOORD0;
    float2 uvmain : TEXCOORD1;
    float3 TtoW0 : TEXCOORD2;
    float3 TtoW1 : TEXCOORD3;
    float3 TtoW2 : TEXCOORD4;
    float3 viewDirWorld : TEXCOORD5;
    float2 uvbump : TEXCOORD6;
   }; // 어차피 appdata_full 썼으니까 이건 필요 없지않남.

v2f vert (appdata_full v)
   {
    v2f o;
    o.vertex = mul(UNITY_MATRIX_MVP, v.vertex);

    TANGENT_SPACE_ROTATION;
    o.TtoW0 = mul(rotation, _Object2World[0].xyz * unity_Scale.w);
    o.TtoW1 = mul(rotation, _Object2World[1].xyz * unity_Scale.w);
    o.TtoW2 = mul(rotation, _Object2World[2].xyz * unity_Scale.w);

    return o;
   }

float4 frag( v2f i ) : COLOR
   {
    // calculate world normal
    float3 worldNormal;
    worldNormal.x = dot(i.TtoW0, bump.xyz);
    worldNormal.y = dot(i.TtoW1, bump.xyz);
    worldNormal.z = dot(i.TtoW2, bump.xyz);
    worldNormal = normalize(worldNormal);

   }

Built-in state variables in shader programs

Wed, 20 Apr 2011 11:09:57 +0000

Built-in state variables in shader programs

Often in shader programs you need to access some global state, for example, the current model*view*projection matrix, the current ambient color, and so on. There’s no need to declare these variables for the built-in state, you can just use them in shader programs.

Built-in matrices

Matrices (float4x4) supported:

UNITY_MATRIX_MVP: Current model*view*projection matrix
UNITY_MATRIX_MV: Current model*view matrix
UNITY_MATRIX_P: Current projection matrix
UNITY_MATRIX_T_MV: Transpose of model*view matrix
UNITY_MATRIX_IT_MV: Inverse transpose of model*view matrix
UNITY_MATRIX_TEXTURE0 to UNITY_MATRIX_TEXTURE3: Texture transformation matrices

Built-in vectors

Vectors (float4) supported:

UNITY_LIGHTMODEL_AMBIENT: Current ambient color.; 으응… 월드 메트릭스로 변환하는건 없는건가…

Unity Shader Tag

Wed, 20 Apr 2011 10:59:44 +0000

Shader replacement tags in built-in Unity shaders

All built-in Unity shaders have a “RenderType” tag set that can be used when rendering with replaced shaders. Tag values are the following:

Opaque: most of the shaders (Normal, Self Illuminated, Reflective, terrain shaders).
Transparent: most semitransparent shaders (Transparent, Particle, Font, terrain additive pass shaders).
TransparentCutout: masked transparency shaders (Transparent Cutout, two pass vegetation shaders).
Background: Skybox shaders.
Overlay: GUITexture, Halo, Flare shaders.
TreeOpaque: terrain engine tree bark.
TreeTransparentCutout: terrain engine tree leaves.
TreeBillboard: terrain engine billboarded trees.
Grass: terrain engine grass.
GrassBillboard: terrain engine billboarded grass.

Unity blending option

Mon, 18 Apr 2011 16:28:55 +0000

AlphaTest GEqual [_Cutoff]
Blend SrcAlpha OneMinusSrcAlpha     // Alpha blending
Blend One One                       // Additive
Blend One OneMinusDstColor          // Soft Additive
Blend DstColor Zero                 // Multiplicative
Blend DstColor SrcColor             // 2x Multiplicative

올해의 양복데이

Mon, 18 Apr 2011 00:57:02 +0000

정말 간만의, (전통의) 팀 양복데이.
일반직장인 코스프레 버전 No3 죠
양복이 정말로 없어서 안 입은 한 명이 있는 것 같지만 신경쓰지 맙시다.

이걸로 3기 버전이 아래 사진들 옆에 전시되겠군요.
여기에 연속으로 얼굴 나온 사람은 나랑 명근이 뿐인가…
어라 석민은 2기 사진에만 없군요. ㅋㅋㅋㅋㅋ 리턴사원의 비애 ㅋㅋㅋ

2기때 사진 http://chulin28ho.egloos.com/tb/4871102

새식구 단비

Sat, 16 Apr 2011 20:54:03 +0000

트윗질 하다보니 블로그에 영 신경을 안써버렸구만요…

사실 블로그에는 꾸준히 글을 올리고 있긴 합니다만 전부 비공개 …

프로젝트 오픈하면 그때 풀라구요.

그래서 기껏 올린다는게 새식구 단비사진과 동영상입니다 :) 말티즈 5개월. 숫놈.

대소변도 잘가리고 애교도 많고 건강하고 번잡스럽지 않고 사고도 별로 안치고 똑똑하고…

이제 말하기랑 한글만 가르치면 완벽할 것 같아요 ㅋㅋㅋ

핸폰사진과 동영상

[#VIDEO|20110416200400012951631701.jpg|pds/201104/16/03/|mid|640|360|pds18#]

[#VIDEO|20110416200400012952271701.jpg|pds/201104/16/03/|mid|640|360|pds19#]동영상은 어떻게 돌린댜.
[#VIDEO|20110416200400012952591701.jpg|pds/201104/16/03/|mid|640|360|pds19#]

연출 퍼포먼스 테스트

Tue, 12 Apr 2011 16:44:54 +0000

연출 퍼포먼스 테스트 보고입니다.
현재 제작되고 있는 연출 장면들의 중간과정을 최저사양에서 퍼포먼스 체크하여, 기존 게임에 비해 과도하게 무겁거나 곤란하지 않을지 체크하여, 제작하시는 연출장면에 대한 기준을 마련하기 위해 테스트되었습니다.

테스트 환경은 일단 정해놓은 최저사양인

싱글 CPU 2.4 GHz
메모리 512M
WinXP sp3
그래픽카드 Geforce FX5700 128M 에서 테스트되었습니다.

테스트 조건 및 전제사항.

클라이언트 요소로만 테스트 된 관계로, 네트웍이나 로직 등의 요인은 고려되지 않았음을 밝힙니다.
아직 제작이 덜 된 신이 많은 관계로, 추후에 이 데이터는 바뀔 가능성이 있습니다.
옵션은 게임의 최저옵션으로 해 놓고 Bone 의 웨이팅 값만 4로 올려놓고 테스트했습니다. 크게 눈에 띄는 부분은 텍스쳐 해상도가 절반으로 줄어드는 것입니다.
추후 제작될 때에는 글로벌 옵션이 어떻게 정해지더라도, 연출씬의 Bone의 웨이트 값은 언제나 강제로 4로 고정되게끔 공현구 파트장이 작업해 주실 예정이므로 걱정 안하셔도 됩니다.
기본 제공되는 statistics 의 프레임이 부정확하게 나와서 Fraps를 같이 사용하였습니다.
——————————————–각 씬별 테스트 요약

101- 평균 20프레임 정도. 별 문제 없이 쾌적한 레벨이지만 배경 데이터가 몰려서 보일때 급격한 프레임 저하가 있습니다.
안 보이는 배경만 지워주고, 자질구레한 프랍들도 지워서 단순화 시키면 용량도 작아지고 문제없을듯 합니다. 이 부분에 대해선 아래에 따로 정리를…

201 - 평균 15프레임 정도. 배경을 줄여야 합니다. 50% 정도의 드로잉 부하가 있습니다. 24% 정도의 사운드 관련 부하도 보입니다.
301 - 평균 15프레임 정도. 프레임에서 큰 문제는 없지만, GUI Repaint 가 매우 높은 수치로 나오고 있습니다. 하단 자막과 연관된 부분으로 보이는데, 이 씬에서만 비정상적으로 높아서 확인할 필요가 있어 보입니다.

401- 평균 15프레임 정도.
전체적으로 계성에서 필요없는 프랍들을 삭제한다면 등장 인물의 부하는 큰 편이 아니므로 문제 없을듯 합니다.
혹은 디스턴스 컬링 처리하는 것도 한 방법이라고 보입니다.

501 - 특이사항 없음. 프레임도 잘 나옵니다. 제작이 덜 되어서인지 깨지는 샷이 많이 보입니다.
카메라 각도에 따라 드로우콜이 들쑥날쑥한 것을 볼 수 있습니다. (내가 이래서 게임 카메라를 쿼터로 고정…)

701- 카메라가 없어서 테스트 불가능

801- 렌더링 수치가 높지만 13-15 프레임이 평균적으로 나옵니다.
먼 배경의 데이터만 지워주면 급 상승하는 것이 발견되었습니다. 역시 대부분 드로잉 항목입니다.

1001- 프레임 좋음. 단 역시 GUI Repaint가 좀 높습니다.
몇몇 씬에서 GUI Repaint 수치가 높은 것이 발견되어서 공현구 파트장이 확인중입니다.

2201- 프레임 최고. 볼 것도 없습니다. 근데 배경이 많이 짤리는군요.

2401 - 감찰관 독우.
주로 높은 것은 렌더링 / GUI / 이벤트 트리거이며. 전체적으로 프레임이 좋습니다.
하지만 데이터가 아직 덜 제작된 것이 많아서 추후 변화가 있을 듯 합니다.
어머 독우 성우 누구삼 ♥

2501 - 묶인 감찰관 독우
멀리 보이는 배경 데이터가 많아 프레임이 10프레임 내외로 떨어집니다.
배경 프랍들만 대규모로 지워줘도 15프레임까지 상승하는 것이 확인되었습니다. 이럴땐 적당하게 가려주는 것으로 처리하는 센스.

2601 - 등장인물이 꽤 많은데도 불구하고 배경이 가벼워서 프레임이 좋습니다. 아래 캡쳐된 것은 캡쳐되는 순간 부하로 프레임이 안좋아 보입니다.

2701 - 오버헤드 이상하게 높습니다. 오버헤드는 방법이 없는지라 따로 체크 요망합니다. 현재 8프레임 내외로 나오고 있습니다.

2801 -20프레임 이상 잘 나오고 있습니다. 프레임 및 데이터 좋습니다.

3001 - 영제 후임.
15프레임 꾸준히 나오고 있습니다. 캐릭터가 많아서 메쉬 스키닝수치가 좀 높지만. 어쩔수 없어보입니다.

3201 - 대규모 인원이 투입되었습니다. 메쉬 스키닝이 80% 육박하고 있고, 프레임이 5프레임 정도밖에 나오지 않습니다. 이건 좀 곤란합니다. 뭔가 기획차원에서부터 수정이 좀 필요할 듯 합니다.

3301 - 배경 프랍이 많습니다. 덕분에 8프레임 정도로 나오고 있습니다.
캐릭터가 많이 보이는데 스키닝이 안된것인지요? 스키닝 수치가 별로 높지 않습니다.
현재 데이터로는 배경이 많아서 그런 것으로 보이며. 배경을 최적화할 방법을 찾아야 합니다. 물론 캐릭터도 좀 많습니다만.

3401 - 데이터도 적은 아주 가벼운 씬입니다. 꾸준히 20프레임 이상 잘 나옵니다. 이런건 데이터를 더 추가해도 좋을듯 합니다.

3501- 동탁 식사
가벼워서 30프레임의 속도가 나오지만 영상이 끝나고 나서 이벤트 트리거 수치가 급격히 높아지는데 별 문제 없는지 모르겠네요.

3601 - 하진 사망

캐릭터가 많은 것 치고 20여 프레임의 원활한 프레임이 나옵니다. 별 문제 없어 보입니다.

————————————————-결론

라이트의 영향을 별로 받지 않는 캐릭터 쉐이더와, 라이트가 많아져도 2개까지만 제대로 연산하도록 제한된 (최저옵션에서는 하나도 제대로 연산하지 않습니다) 지금 상태에서 라이트의 개수는 그다지 퍼포먼스에 큰 영향을 끼치지 않는 것으로 보입니다. 라이트는 분위기를 위해 지금 정도로 사용해도 괜찮을 것 같습니다.

단 배경 데이터는 현재 전혀 컬링 시스템이 작동하지 않고 있는 관계로, 카메라 뷰에 따라서 급격히 느려지는 뷰가 나오기도 합니다. 이 부분은 일종의 딜레마인데, 게임에서 쓰는 배경을 그대로 사용하면 데이터를 절약할 수 있지만 퍼포먼스에 문제가 생기게 되고, 연출용으로 쓸 수 있도록 가볍게 배경 데이터를 수정하면 모양도 이쁘고 속도도 좋지만 용량의 압박이 생기게 됩니다.
이건 뭐 기계적으로 정하기 어려운 문제라… 일단 은아씨에게 결정하도록 전달해 놓았습니다. 추후 개선이 안되면, 프로그램쪽에서 강제로 디스턴스 컬링을 만들어 넣겠습니다.

캐릭터는 현재 5-6 마리 정도 나오는 씬이라면, 배경만 가볍다면 최저사양에서 4link로 , 각종 더미 포함해서 괜찮은 속도로 돌릴 수 있어 보입니다. 단 몇십마리가 한 번에 나오는 씬은 처리하기 힘듭니다. 되도록 10마리 안쪽이 어떨까… 라는 생각이 드는군요. 다소 주관적인 느낌입니다만.

[Shader] Hidden/Diffuse_FadeOut Shader. 건물반투명용

Wed, 06 Apr 2011 17:55:13 +0000

Diffuse Shader 를 대치할 수 있는 건물 반투명용 쉐이더입니다. 건물반투명용 쉐이더란 캐릭터가 어떤 건물 아래를 지날때
Ray 체크로 건물을 투명하게 만드는 기능을 위한 쉐이더입니다. 인자값은 _Alpha 로 , 1부터 0.2 까지의 범위를 가지고 있습니다.

Hidden 폴더로 넣었기 때문에 그래픽 디자이너가 임의대로 사용할 수 없게 숨겨져 있습니다.

이건 그냥 Diffuse 입니다. 비교해보시라고 올렸습니다.

이건 Diffuse_Fadeout 쉐이더입니다. 뭐가 바뀌었을까요? 바로 그림자가 없어졌습니다 :)
반투명 쉐이더가 되었기 때문에 그림자가 사라집니다. 크게 이상하거나 그러지는 않지요?
그전에 사용하던 Transparancy 쉐이더는 교체 순간 밝게 반짝 하면서 바뀌는 현상이 보이지만, 이건 그림자만 사라질 뿐 그런 현상이 없습니다. (꼼수를 좀 썼…)

0.2까지 내리면 이렇게 됩니다. 0까지 완전히 내리면 너무 투명해서 이상하더라고요. 이정도로 최소값을 잡으려고 합니다.

림라이트를 넣어보긴 했는데… 예상대로 박스형태라 노말이 너무 없어서 개이상하게 나옵니다. 켈켈켈 그래서 림라이트는 삭제했슴다.

커밋했고 부호 전달 완료. 부호 작업중. 금방 될겁니다. 이상.

[Shader] 물 쉐이더 투명도 기능 수정 TKBG_Water

Wed, 06 Apr 2011 14:14:36 +0000

수진씨 요청. 물 쉐이더의 투명도 추가입니다. 이것은 물과 지형이 맞닿는 부분에 투명도를 주기 위한 기능으로, 쉐이더 2.0 에서
작동하기 위해 수동으로 버텍스 칼라를 적용하면 작동하도록 만들었습니다.

수진씨가 안보여서 그냥 올립니다. 커밋도 되어 있습니다.

작업방식은 간단합니다. 맥스에서 물을 만들 때 투명도를 주고 싶은 부분을 선택해서 버텍스 칼라를 빨강으로 만들어 주면 됩니다.

근데 솔직히 말하자면, 사실은 파랑이어도 됩니다. 꼭 빨강일 필요 없습니다.

원래 빨강임을 검출하기 위해서는, 간편하게 하려면 전체 버텍스 칼라를 검정으로 칠하고 나서 저 부분만 빨강으로 칠하는 작업을 해야 하는데, 간단하지만 꽤 귀찮은 작업이라서 그냥 빨강색만 칠하면 되게끔 만들고 싶었습니다.

그러다보니 빨강만 있는 부분을 검출하기 위해서 녹색과 파랑이 없는지를 검색해야 했었습니다. (흰색은 빨강 녹색 노랑이 모두 100% 씩 들어가 있기 때문에 빨강만 검출할 수가 없습니다)

그런데 웃기게도 그렇게 공식을 만들었더니, 쉐이더 2.0에서 처리할 수 있는 수식의 제한을 넘어가 버렸지 뭡니까. - 외부 코드로 빼서 include 시키면 되겠지만 그럼 또 무거워지고 관리도 힘들고… 이 작업에서 가장 어려운 부분이었습니다 -

그래서 이리저리 궁리 끝에, 공식으로 처리 안하고 단순히 ‘녹색이 있는가 없는가’ 만 검출하면 제한에 걸리지 않는다는 것을 알고 그렇게 만들었습니다. 뭐 덕분에 파랑색으로 해도 동일한 효과가 나오게 됩니다. 물론 나중에 파랑까지 쓰게 된다면 크게 뜯어야만 합니다. (그치만 더 효과 주문 안하겠죠? 안할거야…) 더 하면 곤란해요 후후후

또 한 가지, 보통 물의 투명도 (알파) 를 설정하려면 버텍스 알파를 쓰는 것이 일반적입니다만, 애석하게도 이미 버텍스 알파는 2번째 텍스쳐인 포말 텍스쳐에 사용하고 있었습니다. 이때 버텍스 알파를 쓰는게 아니라 칼라를 쓸 걸 그랬어… 꺼이꺼이….
그래서 할 수 없이 투명도에 Red 칼라를 사용하게 되었습니다. 이제와서 바꿀 수 없잖아요 … 흑흑흑…
나중에 혼동하지 마시길.

쿼 그렇게 만들었습니다.

이렇게 투명도가 먹게 됩니다.

단, 스페큘러는 남아있게 일단 만들어 놓았습니다. 물이 지면과 거의 닿아 투명해 지더라도, 스페큘러는 남아 있는것이 더 자연스럽지 않을까 해서요. 요청이 있다면 없앨 수 있습니다. 이상입니다.

모바일 삼품을 위한 그래픽 프로세스에 대한 보고

Mon, 04 Apr 2011 18:05:52 +0000

역시 중간발표입니다. 일주일 좀 안되게 매달린것 같은데 진도가 참 안나가네요.
역시 다른 플렛폼 개발은 여러모로 힘든점이…

그럼 모바일 삼품에 대해 지금까지 조사된 점에 대한 중간보고를 공유차원에서 정리하자면…

우선, 모바일 버전도 PC 버전과 데이터를 최대한 같게 가고 싶긴 하지만,
사실상 근본적으로 다르기 때문에 “미리 정하고 진행해야 하는 것"은 미리 해야만 합니다. ‘삽질할거면 빨리 해라’ 라는 거지요.
폴리곤을 줄인다던가, 텍스쳐 사이즈를 줄인다던가 하는 일은 사실 나중에 해도 큰 문제가 없는 것이지만, ‘캐릭터 옷을 갈아 입힐 것인가’ ’ 파츠 베리에이션을 할 것인가’ 등등은 미리 정해놓고 가지 않으면 안되는 일입니다.

그렇지만 사실 여러 가지 경험부족으로, 모든 상황과 모든 규칙에 대해 일일히 실험해 보며 돌다리를 두드려 보다 보면 아예 일이 진행되지 않는지라… 다소 미심적인 데이터가 있다 하더라도 다른 프로젝트에서 제작한 선례를 최대한 따라 가는 방식으로 만들기로 하였습니다.

그럼 정리 시작. ===========================================================================

캐릭터

-캐릭터는 갑옷을 갈아입지 않습니다. .(파츠가 없습니다. 캐릭터는 무조건 1 DPcall을 요구합니다.
캐릭터의 갑옷을 갈아입는 것은 인벤토리에서의 아이콘으로만이며, 진짜 캐릭터 외형은 변하지 않습니다.
기본적으로 플레이시에 캐릭터가 작게 보이는 데다가

텍스쳐 교체는 가능합니다. 텍스쳐 교체비용을 추산해 봐야 하겠지만, 이론적으로는 가능할 듯 합니다.
이를 이용해서 형태는 변하지 않더라도 텍스쳐만 변하게 해서 캐릭터의 외형을 변하게 할 수 있긴 합니다 .(갑옷을 갈아입은 것처럼 보일 수 있습니다. 물론 형태는 변하지 않지만)
캐릭터는 갑옷을 갈아입지 않는 형태를 취한다고 봤을 때, 4가지 형태의 체형과 5가지 무기, 2가지의 탑승형태를 가지고 있습니다. 이 형태를 유지한 채 조합한다면, 캐릭터는 최대 3개의 파츠로 나눠진 캐릭터가 되게 됩니다.
염색은 지원 가능합니다. 사용할지 여부는 기획팀 답변을 기다리겠습니다. (준경부팀장…)
외각 선택 지원 가능합니다. (쉐이더로 처리하는 것이 아닌 아이폰 기능으로 처리합니다. 쉐이더로도 처리 가능하긴 합니다만, 가능한한 안썼으면 합니다 )
라이트는 사용하지 않겠습니다.
캐릭터에 한해서 라이트를 사용할 수 있습니다만, 캐릭터가 워낙 작게 표현되고 라이트 효과의 의미가 상당히 작기 때문에 - PC 버전에서도 self illumination을 100% 사용합니다- 라이트를 사용하는 것이 큰 의미가 있다고 보여지진 않습니다.
캐릭터 쉐이더는 Unlit 쉐이더로 만들도록 하겠습니다.
당연하게도 그림자 따위는 없습니다. 동그란 그림자는 가능합니다만, 이것까지 줄여버릴까라는 생각을 호시탐탐 하고 있습니다. (1 call 이 준다… 뭐 캐릭터 텍스쳐에 포함시켜 놓으면 또 모르겠지만.)

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

배경

모바일에서는 내장된 터레인이 돌아가지 않습니다.
때문에 메쉬로 컨버팅 해서 대치하는 방식의 작업을 하고 있습니다.
그 후 각 오브젝트들은 각각 모바일 버전에 상응되도록 수정되어, 원본 오브젝트와 교체되는 제작방식을 취하고 있습니다.
이 문제의 단점은 크게 3가지를 예상할 수 있습니다 .

   1. 최적화에 불리함.
       단일 오브젝트를 줄이는 것만으로는 부족한 경우가 꽤 있습니다. 필요에 의해서는 건물 3-4채, 오브젝트 몇 개를 하나의 오브젝트로 합쳐야 되는 경우가 있습니다만, 오브젝트를 별개로 불러와 모바일 형태로 전환한 후 교체하는 지금 방식에서는 과감한 Attach가 힘든 면이 있습니다.

2. 나무는 방법이 없다.
대표적인 자연물인 나무는 배경을 풍성하게 해주는데 큰 도움이 됩니다. 그렇지만 이 나무는 터레인에 소속된 나무로, 독립적인 오브젝트로 취급받지 못하는 것입니다. 이것은 풀도 마찬가지이지만, 풀은 보통 충돌체크가 되어 있지 않기 때문에 문제가 덜합니다. 그렇지만 나무는 심각합니다. 현재 방식에서는 나무의 위치를 PC버전과 모바일 버전 모두에 완벽히 매치되도록 만들 수 없습니다.

3. 조명 문제
많은 스마트폰 게임의 제작과정에서 줄기차게 얘기하는 것은 ‘배경에서는 절대로 조명을 사용하지 말라’ 라는 것이었습니다. 조명의 사용은 게임을 느려지게 만든다고 합니다. - 테스트를 해보고 싶지만, 그럴 여유가.. - 때문에 보통 라이트맵을 사용합니다만, 애석하게도 PC 버전에서 사용하는 비스트를 이용하면, 모바일에서는 원활하게 사용하기 쉽지 않습니다. - 모바일 쉐이더로 바꾸면, 프리팹 등의 경우에 라이트맵이 마구 깨집니다 -

물론, 위의 단점이 모두 치명적이냐라고 물으신다면 그렇다고도, 아니라고도 말할 수 있습니다. 자세한 것은 좀 더 테스트 해봐야 알겠지만, 1. 최적화 문제는 데이터만 줄이는 지금의 방식으로도 충분히 빠르다면야 굳이 손대지 않아도 되며, 3. 조명 문제 도 무시하고 그냥 가신다면야 그냥 갈 수 있습니다. (그림자가 없으셔도 되신다면야)
2. 나무 문제는 조금 문제지만, 현재 황 TA가 나무의 xml 데이터를 불러와서 맥스에 표시하는 방법을 연구중이니, 터레인을 맥스에서 메쉬로 만드는 작업을 할 때 나무도 같이 박아서 넘기면 가능할 듯 합니다.

그러므로 위 문제는 AD와 상의하여 결정할 문제이며, 위 3가지를 모두 개선한다면 그래픽 프로세스에 큰 변화를 주어야만 합니다.
위 문제를 개선하기 위한 배경 프로세스는 다음과 같습니다.

터레인을 비롯하여, 맵의 모든 메쉬 데이터를 맥스로 불러온다
간단히 얘기해서 맥스에서 모든 배경 작업을 한다는 말입니다. AT2같은 경우는 힘들겠지만, 삼품 데이터라면 좀 넓더라도 맥스로 불러오면 커버할 수 있으리라고 보여집니다.
맥스에서 오브젝트의 Attach, 또는 과감한 교체를 한다.
맥스에 모든 데이터가 있으므로, 점유하고 있는 충돌 OX 값 (이 값도 맥스로 넘길 수 있다면…) 을 유지하도록 신경쓰면서 과감하게 Attach 시켜서 한 오브젝트로 만들거나 데이터를 교체할 수 있습니다.
나무의 데이터는 Xml 데이터를 읽어 박스로 표시
맥스에서 박스로 표시된 부분에 제작된 나무로 교체하면 나무의 충돌영역 인식도 끝.
맥스에서 라이트맵 제작
맥스에서 라이트맵을 RTT로 제작하여 소스를 만듭니다. 폴리곤이 적으니 Baking 시간도 적게 걸립니다. 라이트맵에 리터칭을 할 수도 있습니다 .
게임으로 넘김
이렇게 모두 제작하여 게임으로 넘깁니다.

이 방식으로 제작하면 퀄리티가 올라가는 장점이 있지만, 제작 품이 더 든다는 단점이 있습니다. 어느 것을 선택할지는 AD와 상의해야 할 듯…

현재 여기까지 연구되어 있으며, 실제 테스트를 더 거친 후 최종 결정을 내리도록 하겠습니다.

카메라 수정이슈

Wed, 30 Mar 2011 17:46:49 +0000

기존의 카메라가 다소 답답하다라고 느끼시는 분들 (이라고 쓰고 XXX 이라고 읽…)
이 계셔서 연구를 좀 해 보았습니다.

뭐 사실 카메라에 대해서는 개인차가 크고, 취향에 따른 편차가 다양하기 때문에 딱히 이게 정답이다라고는 할 수 없습니다만,
누군가는 어쨌건 어떤 이유를 들어 책임지고 밀고 나가야 주변의 의견도 듣고 불만도 접수하고 영향도 받는 거니까요.
일단 무작정 진행해 봤습니다.

아참 기본적으로 전 HMM 시리즈를 좋아하는 전략 마니아이고, FPS 의 멀미에 무척 민감한 체질을 지니고 있습니다.
제가 쓴 FPS 멀미론은 여기에 http://chulin28ho.egloos.com/5130369

기본적으로 게임의 시점은 여러 가지가 있지만, 어쨌거나 사람에게 ‘웅장하게 보이느냐’ ‘미니어처처럼 보이느냐’ 에 대한 개념은 게임 시점과 상관없이 동일합니다.

그냥 결론부터 얘기하면,

원근감이 높아지는 - 가까운 것이 커지고 먼 것이 작아지는 - 시점일 경우에는 웅장함을 강조하게 되며,
이는 카메라 렌즈로 따지면 광각렌즈에 해당되게 됩니다.

이것은 주로 1인칭 시점의 게임에서, 환경을 가능한한 웅장하게 보일 수 있도록 사용하는 방식이며,
이것이 극도로 심해지면 어안렌즈가 됩니다 . 이것은 시각의 왜곡이 심해지므로,
이 상태로 움직이면 사람에게 어지러움을 유발시킬 수 있습니다. (사람이 인식하는 형태와 다르므로)

http://www.camera.co.uk/why-buy-a-fisheye-lens-for-your-dslr/

반대로 줌렌즈는 이런 현상이 반대로 일어나게 됩니다.
이미지의 원근감이 줄어듭니다.(덕분에 평평해집니다) .
아래 그림에서 보면 멀리 있는 사람과 가까이 있는 사람의 거리차가 거의 느껴지지 않습니다.
심하면 미니어처처럼 보이기도 합니다. 웅장함보다는 아기자기해 보입니다.

스타크래프트같은 다캐릭터 등장의 시뮬레이션 게임에서 많이 사용하며,
사용자에게 혼란을 적게, 안정적인 느낌을 주지만
재미가 좀 덜한 화면이 되는 단점이 있습니다.

http://saylala.wordpress.com/2011/03/

여기에 초점거리에 의한 심도까지 얘기하면 너무 길어지니까 (조리개와의 관계까지 얘기하면서 DOF 얘기도 해야 하고…)
서론은 그만 쓰고
제작한 결과물은 다음과 같습니다.

원래의 이미지입니다. 이대로도 이쁩니다.

바꾼 데이터입니다. 아래쪽 나무 디테일이 좀 더 잘 보입니다. 아래쪽에 보이는 영역이 넓어지고 안정적이 됩니다.

던전에서 높은 오브젝트가 있으면 화면을 막아 버려 답답해 보입니다. 이게 기존 카메라입니다.
그리고 높은 오브젝트는 원근감 때문에 커져서 저해상도 텍스쳐가 너무 눈에 띕니다.

바꾼 카메라입니다. 관문이 작게 느껴집니다. 주위 환경을 알아보기 쉽습니다.
텍스쳐도 너무 커지지 않습니다.

여기가 어디더라..
어쨌건 보시면 옆의 NPC들이 누워 있습니다.
길이 넓게 보입니다. 미니맵과 비교했을때 쉽게 매치가 잘 안됩니다.

좀 더 미니맵과 비슷한 모양이 되었습니다. NPC들도 일어났네요.

광각카메라는 불규칙한 대각선들이 많이 생겨서 좀 불안한 느낌의 이미지를 만들게 됩니다.

재미는 좀 덜할 수 있지만 바뀐 카메라는 좀 더 정형적인 느낌이 되어서 안정적으로 보입니다.

특히 이런 뷰에서 그 힘을 많이 발휘합니다.
지붕이 커지면서 캐릭터가 상대적으로 작아보이며, 화면의 하단이 확대되어 답답해 보입니다.
그리고 사람들이 가려고 하는 먼 거리 부분은 줄어들어 좁게 느껴져 답답합니다.

보이는 거리는 비슷합니다만 먼 거리의 길이 그렇게 좁아지지 않았기 때문에 덜 답답하게 느껴집니다.
또한 화면 아래 부분은 지붕이 그렇게 위압적이 되지 않아서 캐릭터에게 시선이 더 들어옵니다. 아래쪽 디테일들도 더 많이 보이게 되어서 답답함을 줄입니다.

이 방식의 단점.

장점만 존재하는건 아니죠. 모든 것은 양면성이 있습니다.
이렇게 카메라를 바꾸게 되면 2가지 정도의 단점이 존재하게 됩니다.

Z 파이팅이 조금 심해집니다.
카메라 거리가 멀어지면 아무래도 Z 파이팅이 증가할 확률이 커집니다. 즉 그전에는 괜찮은 정도였던 맞닿은 오브젝트가 깜빡거린다던가 하는 현상이 일어날 수가 있지요. 마찬가지로 그림자도 줄무늬 날 확률이 조금 올라갑니다. 크게 우려할 정도는 아닌 것으로 보고 수치를 잡았습니다만, 넣어 봐야 확실하게 알 수 있겠습니다.
fog 값들의 수정이 필요합니다.
fog값이 카메라로부터의 거리로 설정되어 있는데, 카메라가 뒤로 상당히 멀어지게 되면서 오차가 생깁니다. (포그가 진해지는 현상이 일어납니다 ) 가까이 있을때와 멀리 있을때의 포그 값이 유동적으로 변한다던가 하는 설정을 추가해야 할 것으로 보입니다.

구인광고 2차

Wed, 30 Mar 2011 13:41:25 +0000

인력충원합니다~

산도네 블로그에서 트랙백합니다.
이쪽 ‘도’ 관련작업 하고 있습니다 ㅎㅎㅎㅎ
TA들은 프로젝트에 상관없이 모두 소속되어서, 수시로 옮겨다니고 있지요.
관심있으신 분들 많은 지원 바랍니다. (저희 회사 구인하는거 그리 흔하지 않아요….)

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

캐릭터 컨셉디자이너
배경 컨셉디자이너
배경 3D디자이너

구인중입니다.
엔도어즈 신작 프로젝트입니다.

오랜만에 올리는게 그림이 아니고 구인글이라서 죄송하네요~

좋은 분 계시면 연락주세요~ 경력자든 신입이든 상관없습니다.

superboltkbh@naver.com 으로 메일주시면 감사하겠습니다.

제가 작업한 이미지는 아니지만, 이런느낌의 게임입니다~

게임테크 2011 참관기 (이어서)

Wed, 30 Mar 2011 02:38:35 +0000

아래에 이어서. 사진이 너무 많으니 이글루가 처리를 못하네요

세번째는 테라에 사용된 렌더링 테크닉
피부 쉐이딩을 위해서 어떤 기술을 썼는지 궁금해서 들어왔습니다. 저희쪽과 어떻게 다른지도 궁금하고…

…. 굉장히 천천히 말하시네요. 이대로라면 시간안에 끝내기 힘들텐데
원고를 써와서 글을 읽으시는 분위기. ㅎㅎ 아우 약간 오글… ㅎㅎ
따로 정리할 만한 내용은 지금까지 없습니다. PT자료가 전부 다이군요.

미루어 짐작할 수 있는 것은 제안서를 통해 작업이 반드시 진행된다는 것. 개수를 셀 수 있다는 말은 문서화나 구체적인 지시서가 있었다는 말이니까요. 제안서가 반드시 작성되는 듯 하였음

TA 작업이 조금 다른 분위기… 툴이나 기술지원보다는 커뮤니케이션과 일정관리에 집중. 물론 중요하죠
굉장히 기본적인 내용이긴 하지만… 상당히 엄숙하게 말하시니 분위기 급 다운..

네 뭐 여태까지는 사실 구인광고였습니다. (역시 게임테크는 광고강연…)
잠깐 솔깃했지만…
(근데 엄숙한 강연스타일과는 다르게 PT는 왜 귀여운 겁니까)
(바로 옆에서 마누라가 조용히 말하길 : 게임회사는 집에 안보내….)

캐릭터 렌더링

이제 진짜네요.
퍼 라이트 라이팅이라는건 뭡니까? 퍼 픽셀 라이팅이랑 다른점이 뭘까요?
그리고 디퍼드 라이팅을 안쓴 이유는..? 너무 일찍 시작했기 때문일듯.

텍스쳐 장수 빨로 밀어 붙이는 방식이지요. 채널을 꽉꽉 눌러 담아야 하는…

DOT 공식의 수정 (하프 렘버트의 역공식) 이 아닐까 합니다.

일종의 엠비언트 큐브 같은 방식인데… 응용해 볼까요…

우하하 이거구나 나도 만들었던거.
힌트는 혹시 니시카와 젠지씨의 글 아닌가요. 소닉…

으응? SSS를 에미시브에 그냥? ??? 일정 영역에다 넣는건 어렵지 않았을텐데.. 채널도 많았으니 마스킹도 가능했을테고. 뭐 그냥 그렇다는 것입니다.

생각보다 평이해서 놀랐습니다. 심플하게 만들도록 노력한 것 같군요.

[#VIDEO|20110330020300012684431701.jpg|pds/201103/30/03/|mid|600|338|pds20#]

[#VIDEO|20110330020300012684111701.jpg|pds/201103/30/03/|mid|600|338|pds22#]
이것도 우리가 시도했던 방법과 비슷했습니다. 우리는 이거에서 한 가지 크게 다른 점이 있지만요.
하지만 지금은 버렸….

흐음. 이것 역시. 기술적으로 대단한건 없다는게 오히려 놀라웠습니다.
전역 라이팅이라던가

네번째는 차세대 게임의 그래픽 : 사마리아인 데모를 리얼타임으로 구현하는 언리얼엔진3와 다이렉트 X 11
현재 기술

그래픽 카드 3개 연결 !!
적어도 현재의 기술은 아니라는 거네요 ㄷㄷㄷ

발표되어 놀라움을 줬던 사마리아인의 제작과정 발표입니다.
이건 도움이 되네요.

영화 제작 스토리 보드. 사실적으로 클로즈업 되어야 하고 옥외 환경도 사실적이어야 하고..

테슬레이션. 좋은 아웃풋

(짧은 머리. 아직 롱 헤어는 실시간으로 무리인 것인가 ?? )

(DX11 에서 쓰는 쉐이더 파이프라인입니다. 헐쉐이더와 도메인 쉐이더라. 지오메트리 쉐이더를 이렇게 부르나요? DX11 의 세상도 언젠가는 올테니 공부해 놔야겠네요 )

(테슬레이션은 이미 몇 년 전부터 계속 나오는 얘기. 언제쯤이면 편하게 쓸 수있을까요.
딱 테슬레이션 강조할 수 있는 예제네요 )

(자, 잠깐. 저 연기가 지금 와이어 프레임이라고? ㄷㄷㄷㄷ 미쳤구나 ㄷㄷㄷㄷ )

디스플레이스먼트를 할 때 연결 부분에 크랙이 생길 수 있겠군요. 그걸 해결하는 방법을 만들었다네요.

(머리카락도 실시간으로 플렌 생성. 이미 폴리곤의 양 따윈 저 멀리 던져버린지 오래입니다)

머리는 알파 테스팅으로 만들어서 AA를 집어넣는 방식이네요. 이것 좀 찾아봐야할듯.

(흠 언리얼에 디퍼드 들어간게 별로 오래 안되었나 보네요.
이건 뭐 일반적인 디퍼드 이야기)

반사 얘깁니다.

이미지 베이스드 라이팅을 사용했습니다.

먼 거리는 큐브맵을 씁니다. 그리고 평면반사는 뭐 그럭저럭 쓸만하지만… 부족하죠.
그래서 만든게 빌보드 리플렉션입니다. 리플렉션 될 영역을 빌보드로 지정해 줄 수 있는 장점이 있지요

단순한 반사 말고, 블러링을 세로 혹은 가로로 주는 에니소트로픽 리플렉션을 만들 수 있었죠.

이걸 여러장 쓸 수 있었습니다.

포인트 라이트는 실제 사진을 보니 세로로 길죽해 지더군요 (왜?)
그래서 세로로 늘어나는 포인트 라이트 반사를 만들었습니다.

이번엔 DOF 이야기

DOF 의 보케 모양에 대해서죠
(주: 사진에서는 조리개의 모양에 따라 , 촛점이 맞지 않는 부분의 픽셀이 조리개 모양대로 생깁니다. 그래서 오각형이나 원 모양이 되는거지요. 이것을 보케라고 합니다)

… 이봐… 보케를 이쁘게 하려고 먼 거리 픽셀들을 각 픽셀당 하나씩 플렌을 생성시켜 보케 이미지로 만들었다고??? ㄷㄷㄷㄷ

ㄷㄷㄷ 지오메트리 쉐이더 단계에서 보케용 폴리곤을 생성하는군요.
지오메트리 쉐이더로는 도대체 어디까지 할 수 있는걸까요.

해상도 줄여서 최적화 했다.. 라는.

그외 반투명 들의 보케 문제들.

다이나믹 시스템 소개입니다.
딱 문제 안생길 디자인으로 만들긴 했어요.
후후후

[#VIDEO|20110330020300012683791701.jpg|pds/201103/30/03/|mid|600|338|pds19#]

마지막 시간은 테라의 환경 변화 시스템.
일단 자료를 봐서는 저희가 예전에 구현했던 방법과 거의 비슷한데 … 일단 들어봐야 하겠습니다.
프로그래밍 강연이라 ..선 샤프트 같은건 별로 관심없긴 한데 ㅎㅎㅎ 우리는 이미 만들어 진거라

이건 편하게 듣도록 하겠습니다.

사실 여기까지는 이전에 했던 TAD 분의 강연과 내용이 거의 같았습니다. 때문에 크게 건질건 없는 내용
프로그래밍 강연이라고 해서 코드가 남발할 줄 알았는데 거의 TA용 강연이신데요.

파티클의 개수를 절약하기 위해서 화면 밖에 짤린 파티클은 이쪽 화면에 표현해 준다라… ㅎㅎ 재밌는 아이디어입니다. 좋네요.

하늘과 기후의 지역 블렌딩에 대한 얘기입니다. 예전에 저희가 만든 기능이랑 거의 동일했습니다만, 아무래도 좀 더 고민이 되어 있네요.

유일하게 좀 프로그래밍 강연 같았던 선 샤프트 기능 얘기입니다.
엔진에 기본으로 없나요? 만드셨다는데..

샘플링이 부족한걸 레디알 블러로 해결하셨다..라는 심플한 결론.
작지만 효과적인 방법이죠.

쉐이더 코드도 상당히 간단. 이걸로 우리도 좀 가볍게 만들어 볼 수 있을지도.

넵. 여기까지. 경품추첨은 역시나 꽝.
그것도 경품 자체가 너무 양도 적고 저렴했다는…

1회때보다는 분명 나아졌습니다만, 여전히 가격이 비싸다고 느껴지는 강연입니다. 반쯤은 엔진광고인데, (1회때는 100% 광고였죠) 왜 이걸 이 큰돈을 내고 와서 들어야 하나라는 생각이 들었다는 거지요. 물론 주최하는 쪽에서도 고민이 있었겠지만, 좀 더 알차다고 느끼려면 어떻게 해야하는지에 대해 고민해 봐야 할거라고 생각했습니다.

게임테크 2011 참관기

Tue, 29 Mar 2011 09:37:23 +0000

실시간으로 얼마나 할 수 있을지 모르지만 시도해 봅니다.
물론 지금 쓰는건 초벌이므로 나중에 몰아서 정리할께요.
키보드가 구려서 오타나도 일단 그냥 갑니다.

첫 시간은 키노트1
what the west must learn from korean game development.
red5 스튜디오의 ceo께서 한국 칭찬을 하러 오셨나 봅니다. 과연 어떨지.

파이어폴 제작중이시라는.
예전에 와우 제작에도 참여하셨다는군요

블리자드에서도 레드5에서도 한국을 관심있게 보고 있다. 결국 스타의 영향
[#VIDEO|20110330020300012682511701.jpg|pds/201103/30/03/|mid|640|360|pds18#]

파이어폴
슈팅 + mmo( 어라 어디서 많이 들어본..)

한국에서 많이 배웠다.

원래 정액으로 만드려고 했는데
한국의 마케팅 방식에서 배웠다.
한국은 이 분야의 베스트

부분유료화의 짱입니다.
서양도 2-3년 후에는 한국처럼 될거다

모바일이 옛날 게임회사를 먹어버려요

왜 그랬을까?

경쟁이 심해져서 큰 회사만 남았다.
월마트 같은 대형매장도 여러개 회사랑 거래하기 싫었다.
리스크를 떠안을 정도의 규모가 필요했다.

작은 게임회사들이 농노와 같이 되었다. 로열티도 작고. 작은 회사는 돈을 못번다
유통채널에 파워가 집중된다.

게임 가격은 그대로인에 게임 개발 가격은 많이 늘어남
마켓이 4배 열었지만 개발비는 12배가 늘었다.

퍼블리셔들은 리스크를 줄이려 하고 마케팅 예산은 늘고…
큰 회사들은 혁신을 일으키지 못한다.

모두에게 이것은 악영향.
혁신이 안되어서 정체.
비용은 늘지만 게임할수 있는 시간은 줄여듬
유통채널이 없으면 게임을 만들수 없음

해적판과 중고 시장도 문제
엄청난 금액. 아시아는 온라인이 많아서 별로 문제가 없는데 미국은 문제

게임스탑 : 게임유통업체
게임이 블럭버스터와 같은 운명 아니냐 - 비디오 임대 회사 망한것 처럼
그러나 혁명 오기 전에 파산

게이머는 바뀌고 있다.
새로운 게이머가 생기고 있다.

집중할 수 있는시간도 경쟁이 생기고 있다.
첨엔 TV와만 경쟁했지만 지금은 페이스북 트위터와도 경쟁해야한다.

이제는바꿔야할 시간이라고 보입니다.
벽돌에 머리를 부딫히기 전에 스탑

박스를 버리고. 아시아에서 배워라.
한국이나 스팀을 배워라. 유통을 버려라.

디지털만 있으면 다운로드로 돈을 벌 수 있다. 마인크래프트를 봐라 스팀을 봐라 한국을 봐라.
아이디어와 컨텐츠로 경쟁해야지 유통으로 경쟁해선 안된다.

굳이 온라인이 아니라고 해도 . 예를 들어 싱글게임이라고 해도 클라우드로 할 수 있지 않을까?
그럼 웹베이스로 가야 하는데, 해적판도 사라지고 저장도 가능하고… 다른데 가서도 똑같이 할 수도 있고
게임도 작아지고 억세스도 가능하고 여러가지 모바일 플렛폼에서도 가능하다.

클라우드로 하면 어떤게 더 가능할까 고민해 볼수 있다.

그럼 무료 게임을 만든다는 것인데 거기에는 아이템 게임이라는 방법이 있다. 박스로는 할 수 없는.
한국에서는 잘 아는데 서구 사람들은 모른다. 아시아의 비밀?
첫 3개월에 끝나버리는 매출이 아닌 오래 진행되는 매출 방식으로 만들고 있다. 우리가 그렇게 하고 있다.

한국에서는 익숙하다. 늘 하고 있는거다.
그렇다면 서구의 미래를 여러분은 보고 있는거다.

배울것들

돈벌기
APB 같은 경우는 맨 처음 박스를 사야 하는데 추가 게임을 위해 돈을 계속 내야하고 아이템도 사야하고 … 뭐하는거냐 이게
미국은 이렇게 잘 모른다. 애매한 마케팅 정책을 취하곤 했다. 한국에서는 잘 하고 이해하고 있는데 말이지.

스토어솔루션의 문제. 작은 회사들은 대규모로 안해봤다. 이벤트 베이스 아이템 판매 같은거 개념없다.
그런 통찰력이 없다. 한국이 가르칠 수 있다. 수출이나 이전한다면 굉장히 변할듯.

안티 해킹 전문가도 찾아용 연락주세용. 그것도 한국이 짱임

한국은 업데이트 빠르고 작고 이벤트 기반. 서양은 느리다.
서구는 업데이트가 얼마나 중요한지 잘 모른다. 아이템 기반에는 이게 굉장히 중요한데.

마케팅 전략도 바뀌어야 한다.
박스는 앞에다 모든 마케팅 금액을 부어야 하는데 프리게임은 나중을 생각해서 금액을 투자 해야한다.

지속적인 마케팅이그래서 필요하다. 판촉과 ..
게이머와 직접 공략.
패키지는 담당 회사가 있지만 . 유저와 곧장 만나야 한다.
한국은 마케팅을 잘 알고 있다.

지금보다 좋은 기회는 없습니다.
아이템 기반의 시장이 서구에서 열리고 있다.
한국은 통찰력과 경험을 가지고 있다.
모바일이나 웹게임도 있다.

한국은 서구의 미래다.

결론 “한국의 마케팅이나 시장은 짱이니 한국의 아이템 판매 기술을 우리한테 가르쳐 주세요 굽신굽신”

두번째 시간은 클라우드 광고이므로 패스
하지만 광고라고 보기엔 꽤나 관심있는 토픽이 좀 있었어요.
우리회사 프로젝트에 도움이 될 지도… 알아보도록 ‘시켜야’ 겠습니다. ㅋㅋㅋㅋ

하지만 이런 광고가 기조연설에 올라오는건 좀 문제잖아… 여전히 게임테크는 광고테크로구나

세번째 시간은… 오오 인피니티 블레이드 GDC 강연이잖아 ..

OTL…. PT도 같아… 오전엔 좀 놀 시간이 있겠군요 (어이)
이건 뭐 이미 들었으므로 굳이 들을 필요 없겠지만 한 번 더 가볍게 듣기만 하겠습니다. 정리는 안하고…
안하려고 했는데 조금 할께요

-한국 사람이 비율당 우리 게임 보스를 가장 많이 죽였어요!!! 한국 게이머가 짱이예요!!
(내용 자체는 GDC에서 들은것과 같습니다. 한국에 맞게 조금 더 추가된 정도? )

-아이패드2에는 엑박 한바퀴(360)랑 성능이 맞먹을 정도예요!!
-모두가 액박을 가지고 다니는 거예요!!

-예쁘고 멋있게 만들면 돈도 벌수 있것지
-캐릭터를 클로즈업하게 해서 노말맵이나 디테일을 보게 하자
-시네마처럼 보이게 ..
-글로 쓰지 않게. 월드에 들어가 있게

-재밌게 만들기
-두 개의 엄지 손가락 쓰는건 안만들어야지. 그럼 다 가라잖아.
-그래서 한 손가락으로 다 하도록

-언제 게임하냐고? 버스 출근 TV 화장실에서!!
-화장실에서도 재밌게 할 수 있는 게임
-그래서 각 세션이 2분 5분. 그안에 재밌어야 함

(들었던거라…적어도 내가 영어로 들었던게 잘못들은게 아니구낭. )
(이후는 이전 내용과 동일해서 패스)

(아이패드 2 얘기가 추가되어 있네요)
-몇 가지 옵션을 더 켤 수 있었다.
플렛폼들이 늘어난다…
시장이 커진다.. 고객이 많아진다.

게임을 만들면서 돈을 받는다니 !!
5년안에 20억개의 콘솔-엑스박스나 PS3- 을 주머니에 넣고 다닐 겁니다!!!

온라인 게임개발을 위한 크라이엔진 3의 캐릭터 애니메이션 파이프라인

원래는 워페이스 프로젝트를 가지고 나오려 했는데 퍼블리셔의 강력한 저지로 데이터를 하나도 못가져왔다고 하시는군요.
과연. 비싼 돈내고 강연와도 별 소용이 없습니다….. 아무리봐도 게임테크는 그 가치에 비해 금액이 너무 비싼듯.
강연자분이 뭔 죄가 있겠습니까..

워페이스 에서도 사용하고 있는 파이프라인
마지막 것은 지금도 수정중

요구사항.
리얼한 애니메이션 시스템을 만들어보자…
너무나 많은 사항이 생겨서 대처하기 힘들었다.
실제로 사용하는 툴과 같은 시스템을 만들자.

로코모션 그룹

블렌딩 시스템. 어떤 상황에서도 원하는 모션을 만들때.
이동하는 방향으로 어떻게 회전할 것인가. 어떻게 해결할 것인가. 그냥 하면 너무 어색하잖아.

실제로 구현한것. 특징은 에니메이션 여러개를 그룹으로 묶어 표현
여러 개를 섞어 사용하기 유리.

시연-

풋스템 마크업 기능이 먼저 되어야 한다.
실제 캐릭터가 어느 발이 어느 타이밍에 닿는가를 마크업
이러면 속도가 다른 애니메이션을 블렌딩 해주기 좋다.

레이어드 에니메이션
로코모션으로 하는건 뭐 좋았는데
무기 바꾸면 대응 불가. ㄷㄷㄷ
그래서 상체 부분만 바꿔서 레이어로 재 구현

에디티브 에니메이션
에니메이터들은 이렇게 저렇게 다양하게 하고 싶은데 리소스를 제작하기 힘들고
뛰다가 장애물이 있다. 자기 키 정도.
그럼 고개 숙여 피하면 된다.
그치만 종류가 많고 높이가 다르다면?

맥스의 바이패드 레이어와 거의 비슷한 기능

-시연-
레이어 에니메이션과는 다르게 다리를 제외한 모든 걸 바꿀 수 있다.
그리고 맥스에서 만든걸 스크립트로 출력할 수 있다.

ik

림 IK
크기가 다른 물건을 집어 나르려면?
대상의 크기를 고정한다음에 하겠지?그렇지만 다양한 형태의 물체를 들어올린다면…
원리는 에니메이션을 출력한다음에 직접 에디터에서 에니메이션을 제어하는것.

확실히 시연은 좀 지겨움. 집중도 하기 힘들고 -

세 가지가 지원됩니다.
리타겟팅 - 유동적인 ik 기능 구현.
일정 본에 따라붙어 이동하는 ik 기능.

피직스

세컨드리 에니메이션이 귀찮…
셋팅도 까다롭고 테스트도 오래 걸리고 비효율적
그래서 개선

-시연-

(기능이 있습니다. 만들었습니다. 성능 좋습니다… 라는 단순한 결론 )

라이브 싱크

맥스랑 왜 다른가.
툴에서 바로 엔진을 볼 수 있게 해주는 기능.
좋은 기능이네/

이렇게 오전은 끝
점심은… 에또..
졸려..

모바일을 위한 언리얼 엔진3
에픽게임스 엔지니어분과 TA 님 강연입니다.

일단 엔진 광고로 시작. 네에 게임테크는 엔진광고입니다.
그점이 사실 좀 마음에 안들지만…. 돈내고 들으러 오는 세미나에 엔진광고는 좀…. 엔진사에서 지원금 받아서 누가 다 먹는걸까요.

-게임데모. 시연-
에니메이션이 좀 이상하지만 게임은 멋지네요. 맥워리어 생각난다.

언리얼 3와 udk 모바일
뭐 일단 그냥 PT 자료 읽기. 따로 정리할만한게 없네요. 유니티랑도 똑같아요.

핸드 옵티마이즈 쉐이더라…
프리컴퓨티드 쉐이더란 뭘 말하는걸까… DX에서 말하는 프레그먼트 쉐이더를 말하는 걸까? 그런 것 같은데…
그거는 게임 시작전 미리 만들어야 하니까요.
뭐 지원되지 않는 기능들은 이해가는 것들…

아항 seek 타임 문제는 없겠군

안드로이드는… 문제예요 ㅎㅎ
역시 안드로이드는 종류별로 따로 지원해야 함

-시연-
시연은 뭐 그다지… 어떻게 작업하는건지 보여주고 있다.
툴 시연…은 강연에서 안좋다고 생각. 지루해 지걸랑.
(정말 유니티가 좋은 엔진이긴 하구나. 몇몇 개념은 언리얼보다 편하고 직관적이다. )
시연은 이미 예제로 있던 탑뷰 게임을 쿼터뷰 게임으로 다시 만드는 과정을 설명

남만 던전 섹션 4 퍼포먼스 테스트

Mon, 28 Mar 2011 16:03:19 +0000

수진씨 요청 들어온 남만 던전 섹션 4 퍼포먼스 테스트 결과보고입니다.

결론부터 얘기하면, ‘이상 없으며 매우 이상적으로 제작되어 있습니다’ 라고 말할 수 있겠습니다.

물론 최저사양에서의 얘기는 다를 수 있으며, 최저사양(지금 한창 테스트중입니다) 에서는 약간 우려되는 효과들이 있어서 조정해야 할 수도 있을지도 모르겠습니다.

테스트 사양은 권장사양에서 테스트 되었습니다.

이전까지 테스트한 지형들의 평균과 비교해 보면, 평균과 거의 다를 바가 없다는 것을 알 수 있습니다.

드로우콜과 tri / vert 등의 수치가 몇백씩 다른데, 이것은 이전에 새로 제작한 캐릭터 쉐이더의 영향일 확률이 큽니다. (새로 제작한 캐릭터 쉐이더에서는 그전에 비해 드로우콜이 300이 줄어듭니다. 추가로 tri와 vert 수치도 줄어듭니다)

이를 감안하면 이 던전은 평균치와 거의 유사또는 약간 상회하는 정도이나, 큰 문제를 가지고 있지는 않음을 알 수 있습니다.

프로파일러의 수치도 걱정스러운 부분은 따로 없으며, 우려했던 반투명 (Transparant) 수치도 2.98ms , 5.9% 를 차지하고 있습니다. 약간 높지만 전혀 우려할 정도가 아닌 것으로 보입니다. (저사양에서는 모릅니다만…)

그런 관계로, 지금까지 연구된 기준에 매우 부합하는 적당한 퍼포먼스를 보이는 던전이라고 말할 수 있겠습니다.

물 쉐이더 소규모 수정

Wed, 23 Mar 2011 15:07:54 +0000

쉐이더가 마이너하게 수정되었습니다.

원래는 이런것.

여기에 두가지 기능이 추가되었습니다.

하나는 포말 텍스쳐에 프레넬 공식을 넣어서 , 카메라에서 기울어지면 보이지 않게 하는 기능 추가입니다.

또하나는 포말 텍스쳐에다가만 색상을 조절할 수 있도록 하는 옵션을 추가했습니다.
이 색상은 멀티로 연산되므로, 더 어두워는 질수 있지만 더 밝아지지는 못합니다.

삼국지를 품다 캐릭터 쉐이더

Wed, 23 Mar 2011 11:02:47 +0000

* 비밀글 해제.

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

이 작업의 목적은 퍼포먼스 향상입니다. 뭐냐면 일단 우리 프로젝트의 라이트 구조에 대해 또 얘기해야만 합니다.
우리 프로젝트의 라이트구조는 아주 노멀한 포워드 렌더링 구조입니다. 저사양과 옛날 기기에 어울리는 방식이긴 하지만, 실시간 라이트 (특히 포인트 라이트) 를 추가하면 하나 추가할 때마다 전체를 다시 한 번 그려야 하므로 고급 옵션으로 가면 갈수록 기하급수적으로 느려지는 단점을 가진 렌더링 구조였습니다.

그래서 눈물을 머금고 라이팅 개수를 제한해야 했고, (픽셀라이트 2개) 그렇게 해야 겨우 권장사양에서도 프레임을 유지할 수 있었습니다. 하지만 이것도 안정되었다고 말하기는 힘든게, 앞으로 무슨 변수가 어떻게 생길지 모르고, 또 가능한한 더 빠르게 만들 수 있으면 금상첨화인 것이었지요. 참고로 픽셀라이트 2개라는 것은, 총 3번 그린다는 말입니다. (버텍스라이트 + 픽셀라이트 + 픽셀라이트) 그러므로 일반적으로 드로우콜이 5개인 캐릭터는 픽셀라이트 2개 허용상태에서는 드로우콜이 15개가 된다는 말이지요.

뭐 캐릭터가 한두마리 있으면 별 상관 없습니다만, 만일 캐릭터가 많아지게 되면? 30마리만 되어도 원래 30*5 = 150 드로우콜이었던 것이 150*3= 450 드로우콜까지 상승하게 됩니다. 순수하게 캐릭터만 300 드로우콜을 추가로 잡아먹게 되는거지요. (드로우콜이 프레임에 언제나 최고로 강력한 영향을 끼친다고는 할 수 없지만 어쨌거나 크건 적건 효과가 있는건 확실합니다)

그런데 우리 게임은 캐릭터의 크기가 작고, (상대적으로) 배경보다 버텍스가 뭉쳐 있으며, 제작 스타일도 일루미네이션 기능을 사용함으로써 라이트의 영향을 줄여버리는 작업 스타일을 보이고 있으므로, 사실 정밀한 픽셀라이트까지는 별 필요가 없었습니다. 약간 간략화 되어 있는 버텍스 라이트를 써도 퀄리티는 충분히 보장된다는 생각에서 시작한 작업이었죠.

그러므로 목적은 간단했습니다.
캐릭터는 현재 픽셀라이트 옵션이 몇 개가 되건 상관없이 무조건 버텍스 라이팅으로만 연산되게 하자!

아시다시피 버텍스 라이팅은 분명히 픽셀보다 작습니다. 그렇지만 늘 그렇지는 않은게… 캐릭터가 작게 보여서 몇 픽셀 안될 때에는 오히려 픽셀 계산이 빠르단 말이죠…. 하지만 또 삼품 캐릭터는 버텍스도 그만큼 적습니다. LOD라도 들어가게 되면 더할테고… 어쨌건 라이트 개수에 따라 패스가 안도는 것만 해도 분명 퍼포먼스의 향상은 일어날 겁니다. 뭐 블라블라… 어쨌건 하는 겁니다.

그치만 아쉽게도 림라이트 같은 픽셀 쉐이더 연산의 기능을 제공하면서 라이팅만 버텍스로 도는 방법은 기본으로 지원해 주지 않았습니다. 덕분에 이틀동안 고생하면서… 결국 순호스승님의 도움을 받아 완성했습니다. 라이트는 버텍스로 계산되고, 림라이트 같은 효과는 픽셀에서 계산되는 특이한 라이트 구조를 가진 (겜브리오 등이라면 별로 안특이합니다만 유니티에서는 특이한) 캐릭터 쉐이더를 말이죠.

뭐 말이 어렵다 하시는 분은 이렇게 생각하시면 됩니다.

저렴한 라이트로 바꿔서 여러 마리 캐릭터 나올때의 쉐이더 부하가 감소되었습니다.
그럼에도 예전 쉐이더랑 모양차이는 거의 없습니다.

결과물은 다음과 같습니다.

이게 기존에 사용하던 캐릭터 쉐이더입니다. 군주 가슴에 염색 되어 있고, 원래 있던 라이트에 추가해서 강한 두 개의 포인트 라이트를 추가로 첨가했습니다. 하나는 분홍색 하나는 연두색. 빛을 받고… 림라이트도 나오고 … 뭐 잘 됩니다.

이게 바꾼 버텍스 라이트 쉐이더입니다. 옵션이나 기능은 모두 동일합니다만, 사실 라이트 적용되는게 살짝 밋밋해집니다. 그치만 따로 보면 잘 모르고, 비교해 봐야 알 수 있습니다.

이게 원래의 픽셀라이트를 이용한 쉐이더입니다. 드로우콜이 291이 되어 있는걸 보실 수 있으십니다.

이게 버텍스 라이팅을 바꾼 쉐이더입니다. 드로우콜이 10이 줄었습니다.

퀄리티는 차이를 느끼기 힘들 정도입니다.

다시 옛날 쉐이더때의 비교입니다. 캐릭터 30마리일때 드로우콜이 847이고, 프레임은… 약 23-24 프레임이었습니다. (캡쳐 프로그램 가동때문에 저기는 느리게 나왔스빈다 )

새로 바뀐 쉐이더입니다. 기능이나 이미지는 동일하면서, 드로우콜은 무려 542로 300이 줄었습니다. 프레임은 약 3-4 프레임이 상승해서 26~27 정도가 나왔습니다. 예상보다는 엄청난 효과가 나오지 않아 다소 실망스럽습니다만, (아마도 캐릭터 크기가 작아 픽셀연산의 단점이 상당히 상쇄되었을 겁니다 ) 어쨌건 향상은 분명히 있었습니다. 그리고 이 테스트 이후에 월드 노말 연산을 버텍스로 옮겼기 때문에, 조금 더 향상이 있었을 겁니다.

테스트 후기

Tue, 22 Mar 2011 17:18:18 +0000

로그인될때 버튼을 누른후 반응이 없어서 여러 번 누르게 됨.
캐릭터 커스터마이징 시 무기가 초기화 되는 장면이 보여서 거슬림
중복… 이라고 하기보단 중복검사가 좋지 않나
돌아가거나 확대축소는 안되나 부다.

설정완료하자 접속이 끊어졌습니다…

그러자 방법이 없다. 재접속이 있는 것도 아니고 완전히 종료시켜야 함

들어갔음. 이름이 너무 커!!
키보드 이동이 없다니!!
마우스 휠 카메라 스크롤이 너무 빠름.
게다가 너무 단위가 큼

아티스트 충원합니다.

Tue, 22 Mar 2011 11:19:25 +0000

★★★★★아티스트 대량 충원[2차]

JJ 가 올린 글 트랙백. 저도 여기 TA로 작업 참여하고 있습니다 잇힝.
특히 배경 컨셉 아티스트를 급구한다는군요

★★★★★아티스트 대량 충원[2차]

저희 프로젝트에서 개발인원을 대량으로 충원합니다.
클로즈베타를 대비해서 컨텐츠 확보를 위한 개발인력 T.O가 생겼습니다.
-또한 현 프로젝트가 올해 안에 상용화를 목표로 하고 있기 때문에
차기작도 함께 그려 갈수 있는 인력을 구상하고 있습니다.

캐릭터 컨셉아티스트
배경 컨셉아티스트
캐릭터 모델러
배경모델러
애니메이터

주변에 잘하시는 분들 소개 부탁드립니다.
yadz01@naver.com

기타 코드

Sun, 20 Mar 2011 23:22:15 +0000

Tangled - When will my life begin?

Sun, 20 Mar 2011 23:20:54 +0000

Tangled - When will my life begin?

Sun, 20 Mar 2011 22:51:43 +0000

요새 하루 종일 듣고 있는 라푼젤 ost
외워버릴 계획중.
기타 꺼내서 쳐보는 중.
으으 기타 녹슬었어. 넥 휘었어.. 다시 사야 돼..

When will my life begin?

performed by Mandy Moore as “Rapunzel”
Music by Alan Menken and Lyrics by Glenn Slater

Bsus4 E/B Bsus4 E/B

Seven A.M., the usual morning line- up
Start on the chores, and sweep ’til the floor’s all clean
Polish and wax, do laundry and mop and shine up
Sweep again
And by then
It’s, like,seven- fifteen
And so I’ll read a book
Or maybe two or three
I’ll add a few new paintings
To my gallery
I’ll play guitar and knit and cook
And basic’ly
Just wonder, when will my life begin?

Then, after lunch, it’s puzzles, and darts and baking
papier mâché ( 프랑스어 : 종이공예) , a bit of ballet, and chess
Pottery and ventriloquy(복화술) , candle - making
Then I’ll stretch
Maybe sketch
Take a climb
Sew a dress

And I’ll re-read the books
If I have time to spare
I’ll paint the wall some more
I’m sure there’s room somewhere
And then I’ll brush, and brush
And brush, and brush my hair
Stuck in the same place I’ve always been
And I’ll keep won’dring
And won’dring
And won’dring
And won’dring
When will my life begin?

Tommorow night
The light will appear
Just like they do on my birthday each year
What is it like
Our there where they glow?
Now that I’m older
Mother might just let me go…

유니티의 3가지 쉐이더 제작 방법

Wed, 16 Mar 2011 17:51:26 +0000

기본적으로 유니티는 3가지의 쉐이더 제작 방법을 지원한다고 볼 수 있습니다.
그걸 다시 크게 두 개로 나누면

Script로 제작하는 방법
CG로 제작하는 방법

이라고 볼 수 있겠는데요

Script로 제작하는 방법

가장 심플하고 호환성이 높은 방법이라고 할 수 있겠습니다.
방식은 기존의 hlsl 같은 렝귀지와 전혀 다른 방식으로 제작되어 지며, 자체적 언어로 제작됩니다.
아마도 각종 플렛폼에 공용으로 사용 가능하게끔 엔진단계에서 컴파일 해 주기 위해 그런 것 같습니다만.

방식은 대략 이런 방식으로 제작됩니다.

Shader “쉐이더 이름” {
Properties {
_Color (“Main Color”, Color) = (1,1,1,1)
_MainTex (“Base (RGB)”, 2D) = “white” {}
}

SubShader {
    Pass {
    Tags {“Queue”=“Transparent” “IgnoreProjector”=“True” “RenderType”=“Transparent”}
        Material { }
  Blend SrcAlpha OneMinusSrcAlpha
        Lighting Off
        Zwrite on
        Fog { Mode Off }
        SetTexture [_MainTex] {
   constantColor [_Color]
            Combine texture* constant , texture
        }
    }
}
}

이 방식은 호환성이 높고 굉장히 간단해서 상대적으로 제작하기 쉽지만,
채널당 이미지를 다루기도 쉽지 않고 아주 기본적인 것 외에 조금 복잡한 수준의 연산을 불가능하다는 단점이 있습니다.
라이팅도 건드릴 수 없구요.

CG로 제작하는 방법

스크립트로 제작하는 방식이 기능적 제한이 너무 많다보니, 결국 CG로 제작하는 방법이 사용됩니다. CG는 hlsl과 유사한 언어이며, 엔비댜에서 제작되었습니다. (맞던가?)

유니티에서는 이 CG로 짜는 쉐이더가 2개로 다시 갈라질 수 있는데요.

fragment (hlsl에서는 픽셀쉐이더) 로 짜는 방법
surface 로 짜는 방법
으로 갈라질 수 있습니다.

이 방법들은 스크립트로 짜는 쉐이더보다 훨씬 무궁무진한 기법을 만들 수 있다는 장점이 있습니다만, 동시에 제약도 가지고 있습니다.

2.1. fragment로 짜는 법

대략 아래와 같은 방식으로 이루어집니다. 기존의 스크립트 쉐이더와 같은 구조에, pass 안에 CGPROGRAM을 선언하고
vertex와 fragment 가 들어 있는 함수명을 선언한 후 vertex쉐이더와 fragment 쉐이더를 CG로 만들어 Color로 출력하는 방식입니다. 당연히 기존 존재하는 라이팅이나 커스텀 라이팅을 만들 수도 있긴 합니다

방식은 아래와 같습니다.

Shader “쉐이더 이름” {
Properties {
  _Color (“Main Color”, Color) = (1,1,1,1)
_MainTex (“Base (RGB)”, 2D) = “white” {}
               }
SubShader
  {
    Pass
       {
            CGPROGRAM

#pragma vertex vert_full
#pragma fragment frag_full

struct v2f {
float4 vertex : POSITION;
}

v2f vert_full (appdata_full v){
v2f_aniOnly o;
o.vertex = mul(UNITY_MATRIX_MVP, v.vertex);

return o;
}

half4 frag_full (v2f i) : COLOR{
return half4(0,0,0,1);
}
          ENDCG
           }
      }
}

이렇게 제작하면 2pass로도 제작할 수 있고, CG의 여러 가지 기능을 짜서 커스터마이징을 할 수도 있습니다.

그렇지만 치명적인 단점으로, 이렇게 짜면 디퍼드 렌더링을 사용하지 못합니다 ;ㅅ;
디퍼드 렌더링은 완성되지 않은 데이터를 받아서 최종 픽셀을 결정하는건데 이 방법은 아예 최종 픽셀을 결정해 버리는 방식이라서 말이죠. (라고 스승님이 말씀)

2.2. surface 로 짜는 법

fragment로 짜는 법과 비슷하지만, surface로 짜는 방식은 약간의 차이가 있습니다. 일단 pass가 없습니다. 그리고 최종 결과물이 color로 나오는 것이 아니라 구조체로 나옵니다. 아래와 같은..

void surf (Input IN, inout SurfaceOutput o)
{
o.Albedo;
o.Normal;
o.Emission;
o.Gloss;
o.Specular;
o.Alpha;
}

때문에 이런 구조가 됩니다.
Shader “쉐이더 이름” {
Properties {
  _Color (“Main Color”, Color) = (1,1,1,1)
_MainTex (“Base (RGB)”, 2D) = “white” {}
               }
SubShader
{
        CGPROGRAM

#pragma surface surf BlinnPhong
#include “UnityCG.cginc”

struct Input {
}

void surf (Input IN, inout SurfaceOutput o)
{
o.Albedo;
o.Normal;
o.Emission;
o.Gloss;
o.Specular;
o.Alpha;
}
ENDCG
}
}

이 구조에서는 #pragma surface surf BlinnPhong 대신에 커스텀 라이팅 구조를 만들어서 넣을 수도 있기 때문에 다양한 빛처리가 가능해 집니다. 또한 디퍼드 렌더러일때의 빛처리와 포워드 렌더러일때의 빛처리를 다르게 할 수도 있지요.
기능상으로 가장 강력하고 만들기도 편한 방법이긴 합니다만, 애석하게도 자체적으로 pass를 만들어 쓰기 때문에 2pass 쉐이더 제작을 할 수 없는 단점을 가지고 있습니다.

* 최근에 유니티 코리아 분과 함께 이 쪽 연구를 잠깐 해봤는데, 서피스에서도 2pass를 하는 법이 있긴 하다고 합니다. 힌트는 #debug .. 이 쪽 좀 더 연구해 봐야겠어요

* 4.x때부터 공식적으로 서피스 쉐이더에서 2pass가 가능해 졌습니다. CG쪽을 그냥 두 번 쓰면 됩니다.

결론

때문에 아이패드나 다양한 기기의 호환, 빠른 속도를 위해서는 1번의 스크립트 방식으로,

2pass 이상 연산을 요하는 PC 전용의 반투명 (이펙트 등. 반투명은 어차피 디퍼드로 돌아가지 않기 때문에 ) , 그리고 포워드 렌더러 전문 쉐이더는 2.1번 방식으로 (디퍼드 렌더러로도 짤 수 있음. 단 귀찮음)
(2015년 수정합니다 :빠릅니다. 각종 기법을 사용할 수 있는 정통 방법입니다. 단 모든게 수동으로 제작되기 때문에 모든 경우의 수를 다 작성해 줘야 합니다 )

2pass는 할 수 없지만 (할 수 있음) 디퍼드 렌더러를 포함하여 가장 고급스러운 효과를 내기 위한 PC (혹은 고사양 게임기) 용 쉐이더(캐릭터 쉐이더등) 에서는 2.2 방식으로 쉐이더를 작성하는 것이 적합할 것으로 보입니다.
(2015년 수정합니다 : 편하게 짤 때 좋습니다. 굴절 같이 배경의 이미지를 캡쳐해서 다시 연산한다던가 깊이값 받아오는등의 고급 기법이 힘듭니다. )

삼품 퍼포먼스 테스트 결과보고 3부

Wed, 16 Mar 2011 14:49:47 +0000

결론 Conclusion

권장사양으로 삼고있는 듀얼코어 , 1G, 6600 에서 보통 20프레임대 이상이 꾸준히 나와줘야 유저가 느리다는 느낌을 받지 않기 때문에, 이 사양에 맞춰 기본적인 맵을 테스트 해 봐서 옵션 내역을 정하고, 그 옵션에 맞춰 이번에는 각 맵을 세부테스트 하여 확실하게 기준을 수립하는 작업을 하였습니다.
카메라의 각도에 대한 확고한 기준을 아직 아무도 결정하지 못하여, 제가 임의대로 최대 줌아웃 상태가 가장 부하가 크다라는 전제로 작업하였습니다. (만약 백뷰까지 가능하게 된다면 얘기가 좀 많이 달라집니다. 그리고 변수도 크고요. 그래서 백뷰는 고려하지 않았습니다. 제작 단계시에도 백뷰나 숄더뷰는 고려하지 않고 배경이 제작되었기도 하고요. 일단 저는 백뷰까지 보이는 것은 안된다고 결정해 두었습니다. 이후에도 의견이 모아지지 않으면 진우씨에게 얘기해서 카메라를 고정해 버릴 생각입니다.)

이 테스트 결과에 따르면, 현재까지 알아내서 정할 수 있는 제작 기준안은 다음과 같다고 할 수 있겠습니다.

기준인 GOOD 옵션 (픽셀라이트 2개, 그림자 끔) 에서는 배경팀에 할당된 드로우콜이 약 300-400 정도라고 볼 수 있겠습니다. 물론 캐릭터가 별로 안나오는 맵이라던가 연출 맵 같은 경우는 그보다 더 쓰셔도 됩니다만, 일반적으로 캐릭터가 20-30 마리 정도 출몰할 곳이라면 배경팀에서 제작할때 최대 줌아웃시 드로우콜을 저 안쪽으로 맞춰주시도록 해주시면 감사하겠습니다. 지금 제작된 배경들의 대부분이 저 기준에 잘 맞아 있습니다 ) 배경 제작에서 퍼포먼스 테스트 할 때는 저 정도 기준을 체크하시면서 하시면 편하겠습니다.
캐릭터는 30-40 마리까지 출현이 한계 . 현재로써는 캐릭터가 30마리 정도가 권장사양에서 한계입니다. 한계를 넘어가는 캐릭터는 어떻게 처리할 것인지에 대한 구체적인 계획이 필요합니다. 제가 결정할까요?
물론 캐릭터는 추가적인 이슈가 있습니다만 그건 좀 아래에.
텍스쳐 사이즈는 좀 더 커도 됩니다. 다운로드 밴드위스에 문제만 없다면, 좀 더 큰 텍스쳐를 사용해도 됩니다. 자체적으로 텍스쳐 크기를 줄이는 기능이 있는데, 현재 최대 사이즈로 올린다 하더라도 그래픽 카드 메모리 사용량이 100메가를 넘어가지 않습니다.
모델링은 적합하지만, 드로우콜을 좀 더 줄이면 퍼포먼스에 유리할 수 있습니다. 텍스쳐를 좀 더 써도 되니, 지금보다는 좀 더 과감하게 한 장에 합쳐 버린다던가 하는 식으로 제작하게 되면 조금 더 유리할 수도 있습니다. (특히 모바일용으로는 추후 과감하게 합쳐야 할 것으로 예상됩니다 )
라이트 효과에 맞춰 면 분할 . 모두 하나의 오브젝트로 만들면 퍼포먼스에 이익이 되는 것과 반대로, 너무 크거나 길게 만들게 되면 컬링이 동작하지 않고 라이트도 섬세하게 적용되지 않는 문제가 있습니다.
크기로 굳이 따지면 한 화면에 온전히 보일만큼의 단위로 잘라주면 좋을 것으로 보이니다.
이펙트는 이번에도 경우에 따라 간혹 무거운 결과가 나올 수 있습니다. 이건 뭐 경우에 따라 다 달라서.. 이펙트 팀에는 퍼포먼스 체크 방법을 따로 알려 드리겠습니다.
고로 전체 퍼포먼스의 약 30~40% 정도를 배경에 배분한다고 쳤을 때,순수하게 배경에 허용될 것으로 예상되는 퍼포먼스는 약 10ms 정도입니다. (캐릭터에 10 ms, 인터페이스를 비롯한 기타에 13ms 배분…)

앞으로의 예상가능한 변수들

위 데이터는 지금까지 나온 결과만으로 만든 내용으로, 앞으로 더 프로젝트가 진행되면 좀 더 다른 결과가 추가될 가능성도 있습니다. 앞으로 변수가 될 내용은 아래와 같습니다.

긍정적인 변수

캐릭터 라이팅을 버텍스라이트로 고정하면 , 30마리일때 각각 10개씩, 즉 300 드로우콜을 절약할 수 있는 아이디어가 있습니다. 캐릭터에 한해 버텍스 라이트 쉐이더로 바꾼다면 속도가 향상될 가능성이 있습니다.
캐릭터 메쉬 LOD 를 적용하면 스키닝 부분의 퍼포먼스가 증가하면서 대폭 프레임이 증가한다는 보고가 올라와 있습니다. 본 LOD도 3ms 정도의 효과가 있습니다만, 이건 정말 한 프레임이라도 아까울때 하면 좋겠고, 일단 메쉬 LOD만 적용하면 성능향상이 있을 수 있습니다.
라이팅을 1개만 더 줄여도 1/3 의 드로우콜이 날라갑니다. 퍼포먼스가 안난다면 이 한방으로 올리는 법도 있습니다.

부정적인 변수

인터페이스의 퍼포먼스가 어떻게 될지 모릅니다. 지금 프로그램팀 모두가 이 문제를 해결하기 위해 집중하고 있습니다.
현재는 로직이 들어가 있지 않은 상태라, 나중에 AI등 여러 로직이 들어가게 되면 CPU의 부하가 좀 더 있게 될 예정입니다.
기타 알지 못하는 변수가 어디서 튀어나올지 알수 없습니다.

삼품 퍼포먼스 테스트 결과보고 2부

Tue, 15 Mar 2011 18:32:50 +0000

2부

월드맵

월드맵의 퍼포먼스 테스트 결과입니다. (글씨가 작아서 안보이려나요…)
월드맵은 일단 좀 썰렁하게 생긴건 사실이긴 합니다만, 드로우콜이 약 200밖에 되지 않는 이상한 결과가 나왔습니다. 위에 설명드린대로 캐릭터 30마리가 450 드로우콜을 먹는데 전체가 200이라는…

그 이유는 조명 때문인데, 여기에는 가장 빠르고 싼 라이트인 Directlight 가 2개 들어가 있는 것 외엔 다른 라이트가 들어가 있지 않습니다. 덕분에 옵션에서 정하고 있는 조명제한보다 낮은 조명으로 동작하고 있어서 드로우콜이 대폭 줄 수 있게 되었습니다.
그래서 폴리곤과 트라이앵글 수치도 가장 적게 나옵니다.

하지만 낮은 드로우콜에 비해 생각보다 프레임이 잘 나오지 않습니다.
이유는 좀 더 테스트해 봐야 하겠지만 퍼포먼스 체크툴에서 오디오존 스크립트가 22%의 퍼포먼스를 차지하고 있는 것이 보입니다. 이 스크립트는 다른 맵에서 발견되지 않는 것으로, 뭔가 사운드 관련되어 아직 완성되지 않은 스크립트가 들어가 프레임을 저하시키고 있는 것일지도 모릅니다. 관련자와 함께 좀 더 체크해 봐야 하겠습니다
텍스쳐 사이즈는 테스트한 맵 중 가장 크지만, 그다지 걱정할 레벨은 아닌 것으로 보입니다.

던전 _캐슬포인트 (영어쓰기 귀찮..) 003 섹션 95

던전 캐슬포인트의 테스트 결과입니다. 꽤나 평범한 결과를 보여주고 있으며, 크게 특이할만한 사항이 없는 것이 특징입니다.
프로파일링의 결과치의 배분이 꽤나 이상적인 모습을 가지고 있는 것이 특징입니다.
(가장 높은 것이 Opaque 드로잉으로, 일반 오브젝트 드로잉을 말합니다. Transparant geometry(반투명 오브젝트) 의 비율도 매우 적고 , 오브젝트 드로잉 다음이 메쉬 스키닝 업데이트와 애니메이션 업데이트로, 매우 이상적인 분포를 자랑하고 있습니다)
라이트는 기본 디렉셔널 라이트 2개 외에 포인트 라이트가 하나 들어 있어서, 제한사항에 딱 맞는 범위입니다.

던전_필드워 002 섹션 90

드로우콜이 좀 높아서 프레임이 잘 나오지 않습니다. 라이트도 꽤 많이 사용되어서 라이트 제한을 풀면 급격히 느려질 맵입니다.
물론 가장 무거운 부분의 데이터이고, 이 정도면 못 버틸 느낌은 아니긴 합니다만 드로우콜을 좀 더 줄이면 효과가 좋을것 같습니다.
약간 드로우콜을 줄이는 작업이 가능해 보이는 오브젝트가 좀 보입니다.

그 외 구성은 이상적이며, 특별히 곤란한 낭비도 보이지 않습니다.

던전_포트 001 섹션 86

사실 각종 값들은 그다지 나쁘지 않지만, 이상하게 프레임이 안나오는 맵이었습니다.
드로우콜도 꽤 낮은 편이고, 버텍스나 트라이앵글은 이미 그래픽 카드 허용치를 근처에도 가지 못하고 있습니다.
라이트도 포인트 라이트 2개를 사용했지만, 옵션에서 제한되어 있는 상태기 때문에 큰 문제는 없습니다.

그런데 프로파일링 데이터 분석 결과, Render.Transparent Geometry의 수치가 33.6% 라고 하는 비정상적인 수치였습니다. 이는 어딘가에서 반투명 오브젝트가 과다하게 사용되고 있다는 것을 의미하며,
속도를 올리기 위해 반투명 렌더링 부하를 유발하는 오브젝트나 쉐이더를 찾는 것이 필요할 듯 합니다.
(수진씨가 벌써 하나 찾았뜸)
(솥에 사용하는 버블 에미터가 부하를 일으키고 있었네요. 이펙트쪽에서 수정하면 될듯 : 원인 찾았습니다.)

던전_강족_001 섹션 4 테스트

프레임이나 드로우콜 모두 큰 문제 없는 수준으로, 따로 특이하게 얘기할 필요없는 맵입니다. 석상에서 살짝 Z 파이팅이 보이긴 하는데 뭐… 비어 보이지도 않고 속도도 괜찮고 전반적으로 매우 적절하게 잘 만든 맵으로 보이네요.
라이트를 꽤 많이 사용했기 때문에 라이트 제한을 하지 않았으면 느려졌을 맵인데, 라이트 제한 한 상태에 잘 어울리는 퍼포먼스를 보이고 있는 맵입니다.

던전_게이트웨이 섹션 89

역시 마찬가지로 잘 만들어진 맵입니다. 메쉬 스키닝 수치가 드로잉 수치보다 높은데, 메쉬 스키닝은 캐릭터의 스키닝 값이고 드로잉은 말그대로 드로잉 수치니… 캐릭터의 스키닝 수치는 고정되어 있는 수치이고, 그보다 드로잉이 낮다는 말은 배경이 꽤 부하가 적다는 말입니다.

던전 계_007 _섹션 01

압도적인 드로우콜을 자랑하는 맵입니다. 드로우콜이 굉장히 높기 때문에 프레임이 잘 안나오는 전형적인 스타일입니다.
오브젝트를 정리하거나 합쳐서 드로우콜을 줄여주는 것이 필요합니다.
다른 맵에서는 렌더링이 최대 20 ms정도를 차지하는데 비해, 여기서는 30 ms 를 차지하고 있습니다. 이것이 어느 정도냐면, 33ms 라면 1/30초의 의미이므로 단지 화면에 그림을 찍어주는 것만으로 30프레임 속도를 잡아먹고 있다는 의미입니다.

던전 _ 임금님궁전 ㅋㅋ _ 섹션 87

드로우콜도 낮은 편이고 맵 자체도 작습니다.
덕분에 크게 걱정할 일은 없습니다. 보시면 알겠지만 메쉬 스키닝 수치가 40% 나 차지할 정도로 상대적으로 가벼운 배경입니다. 나머지 구성도 그다지 무리스러운건 없습니다만…

그렇지만 이 맵 구조가 라이트를 7개쯤 활성화 시켜야 원하시던 빛 느낌이 제대로 나는 구조라서, 2개로 제약해 버리면 원래 제작한 의도가 거의 사라지는 단점이 있습니다.

때문에 사양에는 여유가 있으니, 라이트 구역별로 맞추어 오브젝트를 분할해서 라이트 영향을 더 많이 표현할 수 있도록 하는게 어떨까 하는 생각이 드네요.

던전_마운틴 _001_섹션 85

드로우콜이 계성을 제외하고는 가장 높습니다. 그럼에도 불구하고 프레임은 버틸만 한 정도구요. 사실 이것은 가장 높은 지역을 체크한 것이라, 드로우콜은 일시적으로 높은 지역이 생겼을 뿐이며 전체적으로는 사실 큰 무리가 있는 맵은 아닙니다. 단지 목책 등의 드로우콜을 조금 줄여주면 더 좋은 퍼포먼스가 나올 것 같네요.

던전_m포인트 _001_섹션 77

드로우콜이 상대적으로 낮은편인데도 불구하고 프레임은 던전 포트를 제외하고 그 다음으로 나쁩니다. 이것은 모든 구역에서 그런건 아니고, 맵 중심에서 파티클로 이루어진 불이 12개가 모여있는 지역 때문인 것으로 보입니다. 이 부분은 캐릭터가 많이 나온다면 좀 이펙트를 간략화 시키는 것이 좋겠고, 캐릭터가 별로 안 모일 곳이라면 버텨도 될 것으로 보이긴 합니다.
파티클 이펙트 수치가 다른 지역보다 다소 높은 것을 알 수 있지요. 다행히 유니티의 파티클은 꽤 빠른 편이긴 합니다만, 그래도 처음 로딩할때 렉을 느끼게 하는 단점이 있고 화면에 파티클이 크게 잡힐 때 순간적인 퍼포먼스 저하를 유발하기도 합니다.

만약 가능하다면, flow 쉐이더를 응용해서 만들어보는건 어떨까라는 생각이 드네요 (광고) ㅋㅋ

던전_남만_001_섹션_6

라이트는 4개가 사용되었고, 픽셀라이트 2개 정도면 큰 무리없이 쓸 수 있는 배경입니다. 하지만 이전에 말씀드렸듯, 라이트가 내는 느낌이 매우 큰 맵이기 때문에 픽셀라이트를 1개 이하로 줄여버리면 다리 부분이 빛을 못받게 되고 그 부분이 튀게 되는 단점이 있으니 미리 잘라놓는 것이 좋을 것 같습니다.

역시나 드로우콜도 좋고, 프레임도 꽤 잘나오는 맵입니다. 반투명 수치가 약간 높지만, 그건 많은 파티클 때문인 것으로 보이고 큰 문제가 되지는 않으니 괜찮을 것 같습니다.

던전_노말웨이_004_섹션_94

정말 아무것도 없는 맵이네요! ㅎㅎ
말할 것도 없이 캐릭터 메쉬 스키닝 수치가 50% 에 달할 정도로 높습니다. (배경이 그만큼 가볍다는 뜻이겠지요)
뭔가 굉장히 가벼운 맵이네요 :) 캐릭터까지 없으면 날라다니겠는걸요

삼품 퍼포먼스 테스트 결과보고

Tue, 15 Mar 2011 18:27:51 +0000

꽤 긴 시간이 걸렸습니다. 빨리 하려 했는데 중간에 일주일 바다도 건너 갔다 오고 (…)

게다가 중간에 이래저래 새로운 기법들이 발견되어서 수정에 수정을 거치다보니 이제야 완성되었군요.

미리 말씀드리지만 저도 사람인지라, 최대한 정확하게 하려 노력했지만 실수는 있을 수 있습니다.
실수를 막을 방법은 역시 꾸준한 테스트 뿐이겠지요.

맵은 크게 월드맵과 던전으로 나뉘고, 또 다른 맵으로는 이벤트맵과 배틀필드, 시나리오 맵 등이 존재합니다만 여기서는 월드맵과 던전만 전수조사로 테스트하였습니다. 이후 이벤트맵이나 배틀필드, 시나리오 맵 등은 체크하도록 하겠지만 굳이 세부비교까지는 하고 있지 않다가 문제가 발견되는 맵만 세부 테스트 하겠습니다.

즉 이 결과가 일단 기준이 되는 테스트 결과입니다. 이제 세부 테스트 하는 데이터들은 이 데이터를 기반으로 상대비교하면서 테스트하면 용이하겠지요.

테스트 방법 / 조건

테스트 방법은 지형에 캐릭터 30마리를 로드한 채, (각각의 캐릭터는 복제된 캐릭터가 아닙니다. 데이터가 독립된 30마리입니다. ) 각 지형에서 가장 무겁다고 여겨지는 자리를 찾아가 퍼포먼스를 테스트하는 방법을 사용했습니다.
해상도는 웹의 기준인 1024*600 이고, 옵션은 이전에 올렸던 기준의 GOOD 옵션을 사용했습니다.
이 옵션은 그림자를 사용하지 않고, 픽셀라이트를 2개까지 사용하며 텍스쳐는 최고 해상도, 블렌드 웨이트는 2개까지 사용하는 특징을 가지고 있습니다.
컴퓨터는 권장사양으로 결정되어 있는 듀얼코어 3.2 / 1G/GF 6600 을 사용하였습니다.
카메라는 가장 줌아웃된 상태 - 일명 디아블로 상태를 사용했습니다. 줌 인되어서 1인칭이 된다면 매우 변수가 많아지게 되어 측정이 곤란합니다. 지형 제작시에 고려되는 기술도 달라져야 하고요.

테스트 결과

테스트는 기본적으로 1번, 필요시 2번으로 진행되었습니다.
전제조건으로 알아두어야 할 중요한 사항은 드로우콜과 픽셀라이팅 개수의 관계인데, 픽셀라이팅이 0에서 시작해서 1개씩 추가될때 마다 전체의 드로우콜이 *2가 됩니다. 즉 픽셀라이트를 2 개까지 허용했으므로, 실제 오브젝트의 드로우콜에서 *3의 상태라고 보시면 됩니다. 단, 지형에 정말로 라이트가 2개 이하로 박혀 있을 경우에는 옵션에서 라이트가 허용되어 있더라도 드로우콜이 급감하게 됩니다.

그러므로 캐릭터가 차지하는 드로우콜은 마리당 5 * 30마리 = 150 이며, 이것을 픽셀라이트 2개 허용했으므로 사실상 캐릭터가 차지하는 드로우콜은 150*3 = 450 이라고 생각하시면 됩니다. 즉 위 드로우콜 수치에서 약 450 정도를 빼시면 배경에 해당되는 드로우콜입니다. (캐릭터가 차지하는 버텍스와 트라이앵글은 각각 190k 정도 됩니다)

어려운 설명 빼 놓고 분석결과를 쉽게 설명해 드려 보겠습니다….

위 데이터는 각 맵의 평균프레임입니다. 사실상 게임을 플레이 할 때 약 20프레임 이상이 꾸준히 나와줘야 게임이 무겁다는 느낌을 받지 않을 수 있습니다. 그런 의미에서 위의 수치들에서 살짝 부족한 맵 들이 보입니다.

드로우콜은 CPU가 그래픽 카드에 오브젝트를 그리도록 명령하는 횟수로, 일반적인 게임에서 가장 프레임에 민감한 영향을 주는 요소들 중 하나입니다. (모바일쪽에서는 드로우콜의 중요성이 훨씬 더 강조됩니다) 이 수치들은 명확한 기준을 만들기가 쉽지 않지만, 이번 테스트로 어느 정도의 기준을 만들 수 있을 것으로 보입니다.

이제 각 맵별로 수치를 보면서 새부 분석해 보도록 하겠습니다.

월드맵

던전 _캐슬포인트 (영어쓰기 귀찮..) 003 섹션 95

던전_필드워 002 섹션 90

드로우콜이 좀 높아서 프레임이 잘 나오지 않습니다. 라이트도 꽤 많이 사용되어서 라이트 제한을 풀면 급격히 느려질 맵입니다.
물론 가장 무거운 부분의 데이터이고, 이 정도면 못 버틸 느낌은 아니긴 합니다만 드로우콜을 좀 더 줄이면 효과가 좋을것 같습니다. (드로우콜을 줄이는 것은 오브젝트를 줄이는 것과 다릅니다. 예를 들어, 여러 개가 하나의 그룹으로 되어 있는 방패들을, 근처에 있는 방패들끼리 5개씩 묶어서 Attach 시키면 드로우콜이 4*3 = 12 가 줄어들 것입니다. )

약간 드로우콜을 줄이는 작업이 가능해 보이는 오브젝트가 좀 보입니다.

그 외 구성은 이상적이며, 특별히 곤란한 낭비도 보이지 않습니다.

던전_포트 001 섹션 86

던전_강족_001 섹션 4 테스트

던전_게이트웨이 섹션 89

역시 마찬가지로 잘 만들어진 맵입니다. 메쉬 스키닝 수치가 드로잉 수치보다 높은데, 메쉬 스키닝은 캐릭터의 스키닝 값이고 드로잉은 말그대로 드로잉 수치니… 캐릭터의 스키닝 수치는 고정되어 있는 수치이고, 그보다 드로잉이 낮다는 말은 배경이 꽤 부하가 적다는 말입니다.
단지 전체적으로 드로우콜을 줄일 여지가 있는 오브젝트들이 역시 좀 보입니다. 이것들은 수진씨와 따로 협의하도록 하지요.

던전 계_007 _섹션 01

던전 _ 임금님궁전 ㅋㅋ _ 섹션 87

삼성에서 주최한 3D TV 비교 시연회를 갔다 왔습니다.

Mon, 14 Mar 2011 10:23:21 +0000

사실은 ‘삼성 스마트 TV 간담회’ 였습니다. 시연회던가.
여하간 갑자기 초청이 오더라고요

그래서 흠 3D TV랑 다른게 뭐가 나온건가? 드디어 아이패드에 반격을???
이러면서 가 봤었죠. 토요일 자유시간을 쪼개서.

그랬더니…

삼성에 친밀한 파워 블로거 모아서 LG 대반격을 요청하는 자리였습죠.
저도 초청받아서 갔다 왔습니다. 예전 삼성 3D TV 리뷰때 2등했던 기록이 남아서인지… 하지만 전 친밀하지 않은데.. 후후후
일단 뭐 저번의 비교는 불공정했다느니 하면서 자체적인 테스트룸에서 LG와 삼성 TV를 비교해 주고 있더군요.
(제 리뷰를 읽어 보시려면 이 블로그 리뷰좀 찌그린거 메뉴에서 검색을 해보시면 바로 나옵니다….)

자세한 리뷰를 쓰자니 지금 더 먼저 쓸 글들이 넘쳐 있는 관계로 핵심만 말하자면…

삼성은 최신기술이고 분명 전체적인 기술수준은 높았다고 보여지고요
기술수준은 LG가 분명 조금 전 세대의 기술을 쓰고 있긴 합니다. 네 그건 인정합니다.
그런데도 불구하고 LG가 자신들의 TV가 더 좋다고 하고, 품평회도 이기니까 적어도 하드웨어 기술력에서는 세계 최고라고 자부하는 삼성 입장에서는 발끈한거지요.

발표회장에 나오신 기술팀장님 한 마디가 삼성의 모든 것을 대변해 주고 있었습니다
“엔지니어로써 말도 안된다고 생각합니다!”
네 삼성은 엔지니어의 회사입니다.

그런데 문제는 삼성의 최신기술은 완성도가 아직 아쉬워서, 생긴 단점들이 다소 치명적이라는 거지요.
LG는 삼성과 비교하면 기술적으로 떨어진다고 확실히 느낄 수 있겠지만, LG만 놓고 보면 치명적으로 느껴지지는 않는 정도의 차이였구요.
그렇지만 삼성은 삼성 단품으로만 놓고봐도 단점이 보이는 ‘최신기술’ 이라는게 문제였습니다.
최신기술이라는게 다 아시듯 아직 덜 영글어 있을 확률이 크니까요…

그래서 일반 유저들이 품평회를 했을 때 그런 결과가 나온 것이 충분히 이해가 되었습니다.
삼성에서 LG TV의 단점이라고 말한 시야각 문제는, 그 안경을쓰고 굳이 일어서서 돌아다니면서 보지만 않는다면(누가 그 안경쓰고 일어나 돌아다닙니까…) 별 문제 없는 수준이더군요.
제가 그 안경 쓰고 기어도 봤고 돌아도 다녀 봤습니다. 삼성에서 위에서 말하는 정도는 절대 아니더군요…

그리고 옆으로 누우면 3D가 엉망이 되고 어지러워서 못본다고 하는 것도, 3D 뎁스가 깊을때만 어지럽고 얕을때는 별 문제 없는데다가 , 약 25도나 30도 정도까지는 그냥그냥 괜찮습니다. 아이러니컬하게도 LG의 3D 기술이 삼성보다 좀 ‘못하기’ 때문에 깊이값이 좀 깨져도 그냥그냥 넘어갈 만 합니다 ㅋㅋㅋ

그렇지만 삼성 3D TV의 단점이라고 불리는 것들은 좀 치명적이죠. 고개를 90도 돌리면 완전 까매집니다. 이것은 즉 30도 돌리면 1/3만큼 어두워진다는 거지요. 이건 좀 문제입니다. 살짝 삐딱하게 고개 기울여 볼수도 없다는 얘기…

그래놓고 ‘3D TV는 수평으로 보는거다! 누가 그걸 옆으로 보냐!’ 라고 권고안 등을 꺼내면서 부르짖는 거더군요. 아 물론 정자세로 봤을때 화질과 입체감은 삼성이 더 뛰어납니다. 하지만 문제는 그 허용범위가 좁다는 거죠.

안경의 무게도 아무리 가볍게 했다지만 좀 지나면 답답해질 정도고…(이걸 인정했으니 새로운 디자인으로 계속 개선하고 있는 거지요)
3D 오래 잘보는 제 친구가 말하길, 셔터 글래스 방식은 1년쯤 쓰다보니 내장 배터리가 슬슬 짧아져서 3시간 짜리 영화를 끝까지 못본다더군요.
흠 이건 좀 …

그렇다고 보다가 중간에 충전하고 다시 볼 수도 없고… 게다가 하나에 10만원에 달하는 가격은 좀 … 누군가가 ‘요새 가족은 핵가족이라 괜찮다’ 라고 하던데 그건 왜 TV가 커다랗고 거실 중간에 있는지에 대해 정면으로 반박하는, 이해 안되는 항변이었습니다. 여러 사람 모여서 보려고 만든 기계에 인원제한 요소를 만드려 하다니요 … (게다가 테스트 하다가 하나 깨뜨렸을때의 그 좌절감이란!! 내 10만원!!! )

삼성은 여전히 아이폰이나 아이패드에 배운 것이 없어보입니다. 사용자들이 모공 숫자 비교하면서 TV를 사길 기대한다고 생각하고 있는건지… 여전히 ‘최신기술’ 과 ‘수치’ 만 강조하면 팔릴거라고 생각하는 것인지…

사용자는 엔지니어가 아닙니다. 사용자는 사람 얼굴을 바라볼때 모공 숫자를 세고 싶어하지 않습니다. 왜 아이폰보다 14가지 이상 기술적 장점을 지닌 옴니아가 옴레기 소리를 들으면서 삼성의 이미지를 깎아먹었었는지에 대한 이해가 아직도 부족하네요.
스마트 TV라면 사용자에게 얼마나 새로운 경험을 주는지를 고민해야 하는 기기이지, 성능과 숫자 올린 괴물은 아닙니다.

제가 좀 삐딱한지는 모르겠지만 , 하도 궁금해서 아래 질문을 좀 해봤습니다.

“스마트 TV라면서 불러놓고 왜 3D만 얘기하느냐. 삼성에서는 스마트= 3D냐? 지금 보여주는 스마트 허브도 아이패드같은 것이 훨씬 편하고 거기 다 있는 건데, 스마트 TV만의 차별점은 뭐냐” 라고 질문했습니다. 답변은?

“…TV 에서 실행된다는 점이 차별점이겠지요”

ㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎㅎ

" 컴퓨터를 잘 모르는 부모님 같은 분들은 TV에 나오는게 더 자연스럽.."
… 우리 어머님은 아직도 TV의 외부입력 버튼을 이해하시지 못하십니다만, 아이폰이나 아이패드는 편하게 잘 쓰십니다 …
어째서 TV에 넣으면 무조건 편리하다라는 고정관념을 가진 사람이 저기서 스마트 TV를 설명하고 있는 것입니까?

“그럼 또 한가지. 내가 1년전 체험단하면서 리뷰에다가 강하게 써놓은 리모콘 단점이 있다. 리모콘의 상하좌우키 바로 옆에 종료 버튼이 있는 바보같은 디자인이었다. 게임을 십자키 누르며 하다가 , 실수로 종료버튼을 누르면 물어보지도 않고 게임이 종료되더라. 새로 나왔다고 자랑하던 리모콘도 마찬가지였다. 그럴거면서 게임 어플은 왜 넣어 놓은거냐?”

거기에 대한 답변은
“아… 거기까지는 몰랐습니다 "

몰랐습니다라니 OTL
게임 어플 3분만 해보면 바로 알 수 있는 단점을 OTL
정말로 게임하다가 저 십자키 우하단 버튼을 누르면 완전 물어보지도 않고 바로 종료됩니다 OTL
간단하게 소프트웨어적으로 게임할때는 저 키를 비활성화 시켜놓던가, 적어도 Pause 정도로 하면서 나가실건가요? 라고 물어볼 줄 알았습니다.

이래놓고 지금 스마트한 생활을 위한 스마트 TV라고 대문짝만하게 붙여놓은거냐…

“어플은 구색맞추기입니다. TV에서 게임같은걸 왜 해요? 저희도 해본 적 없습니다” 라는 답변을 들은 기분이었습니다.
즉 아직도 삼성은 스마트 TV가 뭔지 모르고 , 스마트 TV를 만들 계획도 없다는 뜻입니다.

헉 핵심만 말하려 했는데 갑자기 길어졌습니다 쓰다보니…
나중에 기회봐서 확실하고 자세하게 비교 내용을 말씀드리겠습니다 :) (아니 뭐 기대해주신다면 말이죠 헷헷)

싱가폴 항공 : 크리스 월드와 함께 공부하기

Sat, 12 Mar 2011 05:53:55 +0000

이번에 미국갈때 탄 비행기는 SQ016 , 015 모두 싱가폴 항공이었습니다.
이코노미 좌석중 가장 좋은 시설에 가장 넓은 자리에… 뭐 그래도 이코노미였지만 어쨌거나 이코노미의 최고 좋은 비행기였죠.
아기들 빽빽대는 것만 빼면 말이죠… (그래도 올때는 괜찮았다능)

장비는 정말 훌륭합니다. 국내 비행기보다 좋아요. 국내 비행기에도 거의 같은 비행기 있는건 봤는데 이건 RCA단자에 랜포트까지 구비.

그리고 거기서 만든 크리스 월드. 비행기용 OS 이름인가 봅니다.
이걸로 가는 동안에는 여자사람과 함께 보면 남자가 오징어가 된다는 아저씨를 봤고.. 중간중간 비행기 정보도 볼 수 있고, 허접한 게임도 할 수 있는 그런 창입니다. 터치는 안되더라고요. 한국껀 되었었는데.

뭐 어쨌건 돌아올때도 13시간의 비행시간이 지겨워 이것저것 만져보고 있었습니다.

호오 교육이라. 그러고보니 이건 안봤네요.

오 언어를 공부시켜 줍니다. 어디 한 번 해볼까요.

이것만 배우면 나도 글로벌 언어를 구사하는 인재!!!

핸드셋을 잡으랍니다. 가로로.

그래서 잡았죠. 두근두근.

어디보자… 아 위의 것은 나의 언어이고, 아래의 것은 배우고 싶은 언어로군요.

와우 다양한 나라의 말이 구비되어 있네요. 대단한데 크리스월드.

일본어까지.

이탈리아 사람도 공부할 수 있다.

하국의 사람도 열심히 공부할 수 있군요.

…………응?

하국어?????????????????

아니 그것보다

표랑스어????????????????????????????????????????????????

뭐지 이 표범과 호랑이를 묘하게 합성해 놓은 것 같은 언어는…

분명 표랑스라고 하는 언어가 있을겁니다. 하국어는 뭐.. 받침 하나 빼먹는게 대수입니까. 그럴 수도 있죠. 외국 비행기인데.
아래쪽에 씌여진 승입 / 도우 / 마츠는 눈에 들어오지도 않습니다.

그래서 다른 언어를 선택해 보았습니다.

독익어 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ ㅋㅋㅋㅋㅋ
뭔가 독들어 간 것 같은 물고기 이름이야 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

신경쓰지 않습니다.

그럼 다음.

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ익본어 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 아 슬슬 뒤집어지려 한다.

페르토칼어 ㅋㅋㅋㅋㅋㅋㅋㅋㅋ 아니 이건 좀 덜웃기잖아

나왔다 !!!! 터졌다!!! 스팔ㅣ어 !!!!!! 뭘까 이건!!!

대나무 나라에 사는 인신매매 집단의 포주만이 쓸 수 있는 비전의 언어도 내장되어 있습니다.
뭔가 흠좀무.

이젠 맞는건지 틀린건지도 모르겠어….

아 이건 이제 짐작도 안가 ㅋㅋㅋㅋ 어디야 이건 ㅋㅋㅋㅋㅋ

갑자기 러시아어와 그리스어로 저를 실망시키는군요. 왜이래 크리스월드. 나를 실망시키지 마!!!

이미 이건 고전개그…

슬슬 약빨이 다했나 봅니다. 흠 역시 그냥 사소한 실수인가…

아닙니다. 역시 세계는 넓습니다. 자일리톨의 고향은 핀란드. 후시딘의 고향은 후디인 것이 확실합니다.

탈국어 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 아 슬슬 다시 열반에 들려 한다

말레가 쓰는 말레의 어 ㅋㅋㅋㅋㅋㅋㅋㅋㅋ

으악 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ ㅣ도네시아 ㅋㅋㅋㅋㅋㅋㅋ

아 이젠 진짜 모르겠다 어느게 맞는건지…

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 여태까지 ‘어’ 였다가 왜 갑자기 ‘말’ 이야 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

이젠 슬슬 웃다가 지치려고 합니다.

IT 업계 종사자들의 전문언어인 태크어도 있습니다. 아 유 컴파일 나우?

이것도 맞는건지 틀린건지 모르겠는..

녹색사각형마컬어라고 하는 신조어도 있습니다.
정말 다양하군요.

열라고 지시합니다 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 안열수가 없잖아 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

그래서 열었습니다.

오 숫자와 단위 등을 배우고 간단한 대화등도 배우는 군요.

다 좋은데 저 오크어는 뭐냐 “씨음택 석타~!!!” 오크족의 외침이 들려옵니다.

저쇼(점수) 도우말(도움말) 마츠(마침) 따위는 신경도 안갑니다.

다은 티음쥐는 어디사는 쥐냐고 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

이미 숫자 게임따위는 신경쓰지 않습니다. ㅋㅋㅋㅋ

다음 게임을 해봤습니다. 음 날짜를 배우는 군요. 요일을 배우나 보네요. 뒤의 그림이 뭔가 이상하지만 넘어갑니다.

1위의
ㅣ 워 향 쇼 목 금 터

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

뭐야 이거 진짜 난 누군가 여긴어딘가
이건 한국어가 아닙니다. 하국업니다. 당황하면 안됩니다.

의외로 하국어의 도움말은 한국어와 비슷한 점이 많군요.
다은만 빼놓고.

아무래도 음재 티음쥐는 뭔가 하국의 고유명사인가 봅니다.

설마 다른 언어도 저런건가라고 궁금해서 들어가 봤습니다.

표랑스어나 익본어같은건 제가 모르기 때문에, 평범하게 잉글리쉬.

어라 평범합니다 . 에이 실망.

발음도 충실 한 월 요 일

저 위가 1월이 맞는 거였군요.

아무래도 이 하국이란 나라말만 뭔가 이상한듯 합니다.
익본어 (일본어) 를 선택했는데

0이 제로라고 읽힌데요. 익본에서 말이죠.

1은 평범하게 이치 …. 어라 잠깐……………………….

나 분명 하국어 골랐잖아…………….

그럼 왜 “ichi” 인거야????!?!?!??? “이치” 가 아니고 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

아아 크리스 월드는 하국어를 아는 사람이면 평범하게 영어 정도는 할 수 있다고 생각한 거였군요 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

귀국하는 비행기 안에서 평범하게 하국어로 다양한 나라말을 공부해 보는 즐거운 시간이었습니다.
뭔가 이거 항의해야 하나 잠깐 생각해 봤지만 스튜어디스에게 항의해 봤자 … 게다가 이런걸로 피곤한 비행을 까칠하게 하고 싶지는 않았습니다. 그리고 혹시 압니까? 정말로 평범하게 영어는 읽어주는 하국이란 나라가 있었는 걸지도 ㅋㅋㅋㅋㅋ

즐거웠어요 또 만나요 크리스월드

노트북 연결해서 못봤던 무한도전 보기.

GDC 강연 참관기 : 금요일 강연내용

Fri, 11 Mar 2011 01:11:53 +0000

슬슬 강연듣기 지쳐가는중.

금요일 아침부터 들은 강연은

Faster, Better, Cheaper: Pushing the Artistic Bar in Portable Game Development

Nathan Phail-Liff (Ready At Dawn Studios)

대충 봤을때 갓오브워 모바일 버전을 만든 얘기더라고요.
진짜 이번엔 너무 대충가서 어리버리했는데, 담에는 좀 더 조사해 가야겠다는 생각을 가졌습니다.

왜냐면 PSP 버전 얘기였거든요.
모바일이라고 해서 난 또 아이폰인줄 알았지.
콘솔게임과 안친한 증거가 여기서 까발려집니다.

오 출신성분들 봐라. 횽님들!!!

하지만 뭐 어쨌거나 모바일에서의 데이터 최적화는 일맥상통하는 바가 있으니까요.
psp 도 spu를 쓰는 방식인건가요?

제가 가장 좋아하는 하드웨어 제약사항과 아트 팀의 요구사항!!! 으하하 이건 내꺼야 내꺼 아무도 못줘 (…)

호오 그래픽팀에서는 멋진 배경과 특수효과들을 요구했군요. 하지만 툴은 개발할수도 없고 파티클도 못쓰고 소프트웨어 렌더링도 전무한 상태(…) 네 도전의식이 불탑니다.

거친 바다에서 싸우는 크레도스의 모습을 보여주고는, 바로 씬을 까발려줍니다. 저 툴은 마야 기반의 자체 제작 툴인듯. 해외는 정말 마야가 갑이네.

보니까 전체적으로 버텍스 칼라를 많이 사용했습니다. 스페큘러 같은거 사용하기 힘드니까 버텍스 칼라로 군데군데 칠해서 텍스쳐를 다양하게 하는 방법을 많이 이용했네요.

어라 생각보다 그래도 많이 썼습니다. AO 까지 쓰다니. 어라 근데 얘네는 멀티패스 버텍스 라이팅이 되나요?
우리도 되던가?

버텍스 칼라를 이용한 페이크 AO 냐 ….

뭐 좋습니다. 텍스쳐 아끼기에는 버텍스 칼라만한게 없지요.

이것도 콘솔이라고 메모리는 상당히 작은 모양이네요. 배경에 쓰인 텍스쳐는 작은 텍스쳐 8장이 전부 다라고 하니.

버텍스 칼라와 알파를 주야장천 써댑니다. 이것이 PSP에서의 최적화 비결인가.

배경은 이렇게. 역동적인 배경을 위해 진짜 배경을 (배를 .. 이던가) 회전.
왠지 어제 나루토에서 들었던 내용인데 (…)

배경의 저 멋진 포그는

근성과 버텍스 칼라의 산물.

타일링으로 깔아놓고 버텍스 칼라로 타일링 숨기기 기법.
뭐 흔한 기법이긴 합니다.

아주 타일링과 버텍스 칼라를 안쓴데가 없군요.

번개는 역시 텍스쳐를 만들고 UV 조작질로 번쩍이게 하는 방법.

번개 근처에 빛나는 것까지 메쉬로 제작 ㅋㅋㅋ
다소 처절하지만 유쾌 ㅋㅋㅋ
아 이런 근성 좋아요

옆의 저건 마야의 UV 애니툴인가요? 저걸로 렌덤한 번쩍임을 제어하던데요

멋지게 흘러가는 바다도 UV , 독특한 물파장 부분만 따로 메쉬로 제작. 역시 텍스쳐 UV 애니

뭐 이런거

군데군데 버텍스 칼라로 칠해주는 것도 잊으면 안돼요 아잉

물결이요? 그냥 본 3개 정도로 스키닝걸고 상하움직임 했어요.

대충 폴리곤 배열은 이정도. 나중에 폴리곤 숫자 들었는데 잊었네요 7만이던가

비요? 당연히 UV 스크롤에 버텍스 칼라 + 알파지요 뭘 당연할걸

텍스쳐는 작게써야 제맛. 타일링이야말로 신.

갑판에 떨어지는 비요? 꼭 설명을 해야 돼요?

후후후후후

바닥에 동그랗게 퍼지는 텍스쳐도 아까워서 1/4로 나눠서 만들었어요 오른쪽 삼각형이 그거임.

벽 타고 흘러내리는 물이요? 그것도 정말 말해야 해요?

이젠 알겠죠?

이래도 모르면 바보.

파티클따윈 안씁니다.

어라 캐릭터는 얘기도 안하네요. 배경만 얘기하고 바로 정리인가

요점은 이거입니다. 이거 3줄. 반복과 인스턴싱. 그리고 디지털 자아를 찾기위한 여행 피하기 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
프로그래머들이 저 여행을 많이 떠나곤 하죠. 그래픽으로 따지면 다 그린 그림을 죽어라 파다가 망치는 느낌?

그외 잡다구리한 팁 들입니다. 작업 속도 높이려고 빌드는 부분만 한다던가 UI는 셀프 빌드 등등.. 표준화에 대한 얘기..

반복해서 쓰는거 좋죠. 그래야 템프로 만들어 놔서 로딩시간도 빨라질 테니까.
아예 컨텐츠를 거기에 맞췄다는게 중요.

어이 이봐 마지막에 강연질 떨어뜨리지 말라고 (…)

별로 어려운 얘기나 심도깊은 얘기도 아니었고, 강의도 들을만한 수준이었습니다. 그냥 쟤네는 저렇게 했네 정도 레벨.

그 다음 시간엔 정말 딱히 들을게 없더군요.

Introduction to 3ds Max Customization and Plug-in Development

Kevin Vandecar (Autodesk)

이거나 들어가서 맥스 플러그인 만드는 기초나 배워볼까라고 들어갔더니

청중이 100명도 없어 ㅋㅋㅋㅋㅋㅋㅋ 메가 텍스쳐 강연에 낚인듯 ㅋㅋㅋㅋㅋ 마지막날이라 그런건가…ㅋㅋㅋㅋ
그리고 강연내용이…
커스터마이징 메뉴에서 쿼드메뉴나 탭의 버튼을 만들 수 있습니다…. (야….)
아 프로젝트가 짤려서 안보이네요. 그냥 믿으세요 (야….) (나중에 고치긴 했지만)
스크립트 말입니다. F11 나오는 리스너 정말 좋아요 ……(야….!!!!!!!!!!!!)

이런 얘기로 15분을 잡아먹다니 상식이 있는거냐 없는거냐.

그래서 처음으로 GDC 강연장을 뛰어나와

Implementation and Application of the Real-Time Procedural Helper-Joint System

Ju Bok Kim (Nexon) and Choong-Hyo Kim (Nexon)

충효씨가 들어오지 말라던 바로 그 강연으로 직행 ㅋㅋㅋㅋ
내용은 뭐 많이 있으므로 요약하지 않겠습니다. (들어도 몰라)
충효씨 파이팅!!! 떨지마!! 얼굴이 굳었 (…) 매운맛나리 실장님 만세!! 실장님 영어도 시크해 (…)

그다음 강연은 이겁니다.

Iterating Realistic Human Rendering: Boxers in FIGHT NIGHT CHAMPION

Vicki Ferguson (Electronic Arts)

흠. 반쯤 프로그래밍 세션일지도 모르겠네. 에라 못알아들으면 말고.
저 권투 게임이 그래픽이 꽤 좋았던걸로 어렴풋이 알고 있긴 한데 자세히는 몰랐습니다.
결론부터 말하자면 조명의 종결자는 베틀필드였고, 사람피부의 종결자는 파이트 나이트였음 ㄷㄷㄷㄷ

사실 내용이 너무 많고 , 강연하는 아가씨가 마이크를 살짝 뗀체로 속사포로 쏟아놓는 데다가 사진찍기 좋으라고 자리잡은 프로젝터 옆자리에서는 프로젝터 팬소리가 너무 크게 들려서 듣다가 포기한 세션입니다 -_-;;; 이건 한시간 분량의 강연이 아녀..

응? 1에서 2편으로 만드는데 오히려 프레임을 떨어뜨렸다고???
’ 이 하드웨어에서는 한계예요!!!!'

ㄷㄷㄷ 퀄리티에 목숨건 사람들을 보고 계십니다. 여기서부터 슬슬 무서웠음.

인체 피부 분석부터 할 때 알아봤다니깐요

진짜 실사처럼 하려면, 일단 가장 중요하고 큰것부터 잡아나가야 한답니다.
그게 칼라와 휴.

그담이 이거.

뭐 그렇죠. 에니메이션을 하게되면 일단 여러 문제가 생기니 .. 정지상태에서 실사처럼 만드는건 차라리 쉽죠.

캐릭터 2명이 중심이니까 아주 목숨을 걸고 분석하네요

‘파고 들어갑니다’ 극한까지.

무려 156개의 조명과 모델을 이용한 실사 피부 분석 ㄷㄷㄷ 뭐야 몰라 무서워 얘들 뭐야 ㄷㄷㄷㄷㄷ

실사에서 스페큘러 분리해 내기 ㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷ

그리고 그 실사를 게임과 비교하기.
여기서 발견한거 : 뭐야 디퓨즈에 목숨걸면 안되잖아!!!!! 우리 게임은 디퓨즈에 너무 목숨걸었어!!! 실사를 보니까 디퓨즈는 아주 썰렁해!!!

진짜 중요한건 스페큘러였다고!!!!!!!!!!!!!!!!!!

ㄷㄷㄷㄷ 다시 분리 분석.

딴게임은 어떻게 하지? 에이 위대하신 딴 게임도 별거 없네. ….

ㄷㄷㄷㄷ

SSS 는 … 아 그림이 잘 안보인다… 따로 SSS 마스킹 영역 만들어 입히는 방식입니다. 생각할 수 있는 방식이긴 한데 단점도 존재..

텍스쳐 블러링 SSS는 요새 정석인듯.

헐 여러 캐릭터를 위해 스크린 스페이스에서 계산했구낭.

SSAO에 칼라넣기 :)

ㄷㄷㄷ 라이트에 무슨짓을 한거냐

아… 업셈플링시의 아티펙트까지 … ㄷㄷㄷ

퐁 쉐이딩도 표면따라 다르게 합니다

슈릭 프레넬좀 찾아봐야겠는데요. 어쨌건 이놈으로 스페큘러 조합. 실사소스와 근접하게 인버스.

눈이나 머리카락도 그냥 대충 할 순 없당.

상처 연구를 위한 분장 ㄷㄷㄷㄷ

ㄷㄷㄷㄷ

모션블러는 꼼수를 좀 썼군요. 주인공 캐릭터에 퍼포먼스가 집중되는 방식.

이렇게 작업해서 훌륭한 결과물을 만드시고 당당히 12개의 스탭을 발표합니다.
디즈니의 애니메이션 12대 원리를 의식한 것인가.

텍스쳐 체크하세요. 디퓨즈는 색상이 중요. 스페큘러와 노말의 모공 데이터가 일치하는지?

모공 데이터는 스페큘러에서 나오는거지 디퓨즈에 그리지 마셈.

각 레벨당 디테일을 철저하게

라이팅은 실제와 비교하셈

디퓨즈 노말 블러링과 스페큘러 노말의 선명함으로 살덩어리 표현을 강화하셈

복잡하게 쓰지마셈. 잔재주 피워봐야 안씀.

스페큘러 조작질하기
KSK 스페큘러는 뭘까

아티스트들이 빨리 일할수 있게 하기 . 아티스트들은 삽질을 먹고 자란다.
큐브맵 필터링 체크. seam주의
다른거 잊지 마셈. 헤븐리 스워드 처럼 멋진 스킨에 열라 구린 머리카락 얹는 바보짓 하지 마셈. (디스다!!!)
에니메이션 주의

업샘플링 할때 생기는 아티팩트(이거 뭐라고 하나… 찌꺼기? ) 잘 숨기기

존내 삽질하셈!
그리고 내년에 봅시다!!(내년에도 뽑아달라는 얘기가..)
… 아무래도 일부러 12개로 맞춘 것 같은 스멜이…

좋은 강연이었습니다. 무엇보다 결과물이 훌륭하니까 할 말이 없네요 ㄷㄷㄷ
역시 게임개발자는 결과물로 승부해야 합니다.

그담에 들어간 강연은

How Art Was Used to Create a Unique Cinematic Experience in HEAVY RAIN

Christophe Brusseaux (Quantic Dream)

아아 드디어 마지막인가 ㄷㄷㄷ 힘들었어유
마지막날 되니까 강연이 들리는 것 같고 막 이래 ㅋㅋㅋㅋㅋ

보자… 헤비레인…
이름은 익히 알고 있었지만 역시 콘솔게임은 잘 안해서리….
어라 프랑스 회사야…? 오오 장비랑 인원자랑한다.

이 말을 다시 요약하자면 , “진짜 영화 만들기”
카메라 충돌등의 문제 때문에 길을 넓게 만들고 (실사같지 않게) 하는 짓을 하고 싶지 않았더는군요. 역시 돈이 있어서 그런가 꿈이 야무지구나.

일단 시나리오부터 읽고 시작합시다. 별로 안돼요 2000 페이지밖에.
하긴 울회사도 기획자들은 시나리오 시험을 주기적으로 보긴 하지 ;;

아 엽서스러운 깔끔쟁이 배경따위는 만들고 싶지 않았어요.

그래서 갔다왔어요. 필라델피아에.
부럽.

중간에 촬영하고 다니니까 깡패들이 시비건 얘기도 있었는데 잘 못알아 듣겠음 ;;

간단하게 말해서 목표는 ‘진짜같은 영화만들기’

어이 디자인 팀에 건축가가 왜 들어가 …

작업절차. 그야말로 ‘이상적’ 이라고밖에…

비하인드냐!!

으헉;; 건축가를 고용해서 진짜로 도면을 만들고 있어 ;;;
그 건축가가 전기 배선같은 짓까지 다 하려고 해서 말렸다고 하는군요.

그럼 도면 보고 무드 보드 - 컨셉이죠.
플레이스 홀더 - 위치 지정 컨셉?

얘네도 갈데까지 가는구나…

완벽한 외주를 위한 문서로다

컨셉 아트 완성.

이렇게 준비 끝났으면 만들어야죠. 의외로 이 팀은 적네요.

절차는 이렇습니다. 프로세스도 딱 뭐 스텐다드.

이렇게 대충 위치 잡아 주면

외주!!! 그렇지 외주를 돌려야지!!

그래도 마지막 수정은 역시 자체 아트팀에서 해줘야 하는게 맞죠.
외주에 무조건 맡기는건 올바른 AD의 자세가 아님.

모션캡쳐를 위한 가상세트 구성이네요. 올려놓을수 있는 곳은 파랑. 부딪히는 곳은 빨강.

이렇게.

캐릭터는…
응?

액터 캐스팅…?.. 패션 디자이너…? 정말 영화찍네.

헐 정말 캐스팅했어 ㄷㄷㄷ
마지막 아저씨는 배우가 아니라는듯.

예이 의상 디자이너 …

프로세스는 이렇습니다. 어이 이건 일반 게임회사 프로세스가 아니잖아…

ㄷㄷㄷ 3D 스캐너의 위엄.
회사에 가지고 있다니

물론 스캔한걸로 다시 만들긴 해야지만요

오오

이건 뭐 말이 별로 필요없는듯

표정. 전부 본이라고??!?? 내가 잘못들은건가??? 기억이 가물대는건가???

툴 지원도 빼놓을 수 없죠.

비주얼 쉐이더 툴 제작입니다.
마야에서 실시간으로 조합해 볼 수 있는..

실시간 뷰어입니다.

후처리 효과툴. 포토샵 레이어 디자인.

오 엠비언트 관련 툴이 따로 있군요

지, 진짜 표정이 본이었어??? 그걸 모션캡쳐를 받았다고???????????

70명의 배우와 10명의 스턴트맨? 128일동안의 촬영??? ㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷㄷ
장비와 공간이 있는 회사니까 할 수 있는 짓..

5번째 메인 캐릭터 : 비 (정지훈 말고)

비가 오는 상황에서의 빛과 그림자, 조명과 반사, 하늘과 환경 등으로 나눠서 조사를 하고 이미지 보드를 수립합니다.
이런건 정말 양인들이 훌륭하게 하는 것 같아요

비 효과는 그냥 파티클만 대충 조합해서 만들어지는게 아냐!!!!

비는 주변의 사물들과 영향을 끼치지.

그거 말고도 물 효과는 중요했다고

샤워할때 물 튀기는 것 같은거 말야.

이런걸 썼지.
충돌 파티클, 2차 충돌, 유리창에 튀기기, 벽에 흐르기, 거품생기기… ㄷㄷㄷㄷ

우린 불도 대충 하지 않았다고

일단 불은 UV 에니메이션이야 (의외네)
연기랑 파티클도 생각해야 하고 굴절도 있어야 하고, 절반 해상도로 연기를 더 추가했지. 퍼포먼스 주의해야 하고 카메라에서 360도로 보여야 했어

했뜸.

결론은

우리는 죽이는 품질 데이터랑 많은 기법으로 만들었지롱.
그리고 대화는 중요해. 보다 사람들을 생산적이고 창의롭게 만들어!! (나도 알어!!!)

뭐랄까. 생각해보면 엄청난 짓들을 옆집 마실 갔다 왔다는 스타일로 설렁설렁 대면서 이까짓껏 스타일로 설명하는게 인상적인 강연이었습니다.

아 힘들다…. 이걸로 강의 정리는 끝이고… 나중에 순수 여행기 한번 정리하죠.

GDC 강연 참관기 : 목요일 강연내용

Fri, 11 Mar 2011 01:10:41 +0000

첫시간은 라이팅의 종결자. DICE 형님들의 베틀필드 3 라이팅 강연

Lighting You Up in BATTLEFIELD 3

Kenny Magnusson (EA DICE)

이건 뭐 디스이즈게임에서 워낙 잘 리뷰했으므로 거기서 보시는걸 추천
http://www.thisisgame.com/board/view.php?id=603902&board=0&category=8101&subcategory=&page=1&best=&searchmode=&search=&orderby=&token=

유니티 형님들 인라이튼 넣어주세요 엉엉
라이트맵으로 구워져 있는것 처럼 생긴 건물이 실시간으로 부서지는걸 보고 뭐야 몰라 무서워 ㄷㄷㄷ
사실 강연 내용을 봐도 이해안되는 부분이 상당히 많은 내용이었습니다. 어쨌건 결과물은 엄청 충격.

핵심은 이거랄까나.

CPU로 라디오시티 패스를 계산해서 라이트 프랍에 박아 넣습니다.
그담에 이 라이팅을 G버퍼로 나눠놓고
최종 라이팅 계산을 하는거지요.

그 외에도 유리창이냐 큰 오브젝트냐 작은 오브젝트냐에 따라 다른 계산을 해야 하는것도 있고.. 하여간 잔뜩 있습니다.

그리고 둘째 시간은 나루토!!!

PS3 & Xbox360 NARUTO SHIPPUDEN: ULTIMATE NINJA STORM 2 Exploring the ‘Other Side’ of Super Anime-like…

Hiroshi Matsuyama (Cyber Connect 2) and Isao Takeshita (Cyberconnect)

만화적 기법을 어떻게 게임으로 구현했느냐에 대한 내용입니다.
결론적으로 쉽고 재밌었습니다만, 사진촬영금지 OTL

그랬어요.

사실 내용은 뭐 그렇게 엄청난 기술이 들어간게 아닌, 그야말로 게임은 근성으로 만드는거야! 라는 내용이었습죠.

‘맞을때 타격감을 높이기 위해 타격점이 찢어지는 듯한 효과는 어떻게 만들었을까요?’
’ 그냥 그려서 빌보드로 붙였습니다’

’ 역동적인 배경 에니메이션을 어떻게 구현했을까요’
’ 그냥 배경을 돌렸습니다 '

’ 열혈의 거친 얼굴선은 어떻게 구현했을까요’
’ 그냥 모두 모델링했습니다’

‘만화적 폭발이나 물 기둥 폭발은 어떻게 구현했을까요’
’ 그냥 그려서 빌보드로 붙였습니다’

멋진 추격씬 - 마크로스의 미사일 씬 같은 - 은 어떻게 구현했을까요
‘그냥 일일히 패스 따라 갔어요’

불도 그냥 그려서 표현했구요. 손으로 그린것 같은 배경은 정말로 손으로 그린거구요 ,

어쨌건 제페니메이션은 세계 최고예요.

사진이 필요 없슴다. 위 내용이 강연 내용 전부임다.
아 날로 먹는 것 같아서 기분좋다.

그 다음 시간은 가장 기다렸던 시간.
기본적으로 , 우리는 영혼을 팔았지롱 : 인피니티 블레이드!!!!

Basically, We Sold Our Souls: The Art Implementation of INFINITY BLADE

Geremy Mustard (Chair Entertainment) and Donald Mustard (ChAIR Entertainment Group)

제가 지금 하고 있는 일과도 연관이 깊고 해서 상당히 관심이 갔었던 강연입니다. 역시 팬심이 있어야 강연이 잘들리고 재밌어요.
이 강연도 아주 잘 들린 강연중 하나.

강연시작입니다. 아 두근두근해.

핸폰 시장은 말이죠 . 끊임없이 성장하고 있어요. 엄청 많이. 하드웨어도 엄청 좋아지고 있다고요.

이렇게요

이미 전세대 콘솔 성능은 나오는걸요. 아마 3년안에 지금 콘솔도 따라잡을껄요. 메모리 열라 많아요. 터치스크린이라고요.

랄라 이쁘게 만들자. 가까이 봐도 이쁘고 영화같고…

한 손으로 게임을 많이 한다고? 그래서 게임을 그렇게 만드셨어요?
글쎄요 게임은 한손으로 할 레벨인데 모양은 폼잡고 앉아서 할 게임이었는데요.

오오 나온다 나온다. 아이폰에서 돌아가기 위한 스팩.
내가 생각한 것과 얼마나 비슷할까 두근댔어요.

퍼 버텍스 쉐이더는 구려 (맞아요!)
디퓨즈 맵 채널의 평균 (멍청하게 명도 구하는 방식) 으로 스페큘러를 만들어서 메모리를 아꼈다.. 전부 반짝이는 갑옷이라 가능한가
버텍스 는 3000개로 작게 텍스쳐는 2048로 거대하게@!!! 이게 그 퀄리티의 비밀이었음.
본 적게. 웨이트도 적게.
원 드로우 콜!!! (내 생각과 똑같다!! 드로우 콜이야말로 스마트폰 퍼포먼스의 종결자)
대부분이 맞았는데, 텍스쳐 2048은 조금 충격이었어요
메모리가 많으니 텍스쳐를 많이 쓰자. 용량이 커지지만 사람들은 다운받을 것이다…

폴리곤 줄이고 맵을 크게 쓰고 노말맵을 쓰는게 퀄리티가 더 좋다는 것을 알았데요.
폴리곤 더 줄였어도 될 거 같은데…

핵심은 배경.
캐릭터야 딸랑 두 마리가 나오거든요.
캐릭터 본은 30개씩 2마리 총 60개. 흠 좋은 숫자.
하지만 배경이야말로 퍼포먼스를 줄이는 기법을 총동원해야겠지요.

역시 드로우콜을 줄이기 위해 최대한 노력했네요. (하지만 카메라 각도도 안변하는 주제에)
적극적으로 컬링을 하고…. DOF는 그냥 밉맵을 이용한 가짜. (어라 다 기억난다)
포그는 아이폰에서 못쓰거든요. 그래서 라이트맵에 그냥 칼라를 입혔어요 (ㅋㅋㅋㅋ)
안보이는 폴리곤은 아주 적극적으로 지워주세요.

배경은 아주 적극적인 빌보드짓을 했더군요. 대놓고 ㄷㄷㄷ
그게 퍼포먼스의 진실이었다능.

자 우리의 배경을 보세요. 텍스쳐는 크지만 돌들을 다 합쳐서 드로우콜을 줄였어요

저 돌길도 다 원콜.

배경은 말이죠 라이트를 못써요. 라이트맵으로 다 구워야 해요 (뭐야 우리랑 똑같잖아. 하긴 언리얼이라고 별수 있냐)
그래서 저 라이팅 기법을 전부 라이트맵으로 구웠어요 (우하하 노말까지. 그건 내가 테스트해서 인트라넷에 올린 내용하고 같다)
응? 커스텀 페인티드 디테일?

여기서 재미있는 꼼수가 나옵니다. 어려운건 아니지만 좋은 아이디어예요. 적극적으로 이용해 볼 예정입니다.

라이트맵만 구으면 이렇게 나오지요.

그런데 노말까지 적용해서 라이트맵을 구우면 이렇게 나옵니다. 뭐 이건 예상할 수 있었던 수순.
그런데 여기서 끝내지 않고

으하하 디테일 맵을 라이트맵에 그려버렸어 ㅋㅋㅋ
하긴 그렇네요. 타일링을 할 수 없는 라이트맵은 디테일맵을 그리기에 매우 좋은 맵이지요. 메인 텍스쳐는 타일링을 해야 할 일도 있고, 그렇다면 역시 라이트맵이 짱이지요.
여기서는 라이트맵을 적용한 채 텍스쳐링을 할 수 있는 툴을 개발했다고 하더군요.

그러니까 그냥 라이트맵만 적용하면 이런데

라이트맵에 노말 넣으면 이렇구요.

ㅎㅎㅎ 과연. 디테일까지 넣은 라이트맵을 넣으니 좋군요.

그 외의 팁들도 있었습죠. 미리 컴파일 시켜놓거나 미리 계산해 놓는 식을 쓴다던가. 파티클 시스템 피해라.. 시퀀스 에니메이션은 당근 피해야죠. 다른 디바이스로 갈때는 화면 해상도 주의 . 메모리가 변하니… 퍼픽셀 라이팅 퍼포먼스 체크하는거 잊지말것이라는 내용이었습니다.

어려운 내용은 역시 아니었습니다만, 혼자서 연구하던 내용이 맞는지 확인할 길이 없던차에 좋은 도움이 되었습니다.
언리얼이라고 아이폰을 뭔가 엄청난 기기로 변신시킨건 아니었더구만요 (당연하지)
이대로라면 유니티에서도 충분히 구현가능할듯!!

삼품에서 실시간 라이트 여러개 사용하기 : 라이트맵 안만들기

Thu, 10 Mar 2011 20:50:02 +0000

삼품에서 퍼포먼스 저하 없이 실시간 라이트를 여러개 사용하기에 대한 연구
study of using dynamic lights with maintain performance in Three Kingdom project.

프로그램 2팀 테크니컬 아트디렉터 정종필

서론

이전의 디퍼드 렌더링에 대한 이야기는 기억하고 계실 겁니다.
잘 모르시면 아래 링크를 한번 읽어주세요 :)

http://intra.ndoors.com/center/board/view.asp?list_seq=210811&board_seq=313&readchk_flag=N

위 글의 요지는 디퍼드 렌더러를 강제 사용하고 있었고, 디퍼드 렌더러는 라이트의 계산을 빠르게 해 주는 장점이 있었으나 초당 수십번의 타겟 렌더 이미지 생성으로 , 기본사양 자체가 저사양에서 돌리기는 힘들정도로 올라간다는 얘기였습니다.

위키페이지:
http://en.wikipedia.org/wiki/Deferred_shading

<좌로부터 칼라 G 버퍼, Z 버퍼, 노말 G 버퍼. 이런 버퍼들이 조합되어 나중에 조명계산을 한번에 처리하기 때문에 지연렌더링 (deferred rendering) 이라고 불린다. >

<지연렌더링의 결과물>

그래서 삼품과 같은 저사양 목표 게임에서는 디퍼드 렌더러를 사용해서는 곤란하며, 포워드 렌더러로 가동시켜야 한다는 얘기였었습니다만, 전통적인 포워드 렌더러에는 치명적인 약점이 있었으니, 그것은 ‘라이트를 추가하면 추가할수록 기하급수적으로 느려진다’ 라는 것이었습니다.

본론

라이트 체계의 약점과 극복 방법

이 약점은 생각보다 큰 것이라, 컴퓨터 사양이 일정 이상이 되더라도 기하급수적으로 불어나는 라이팅 부하 때문에, 일정 수준 이상의 퀄리티를 보이는 게임을 만들기 위해서는 어쩔 수 없이 초기 기본 사양을 잡아먹는 한이 있더라도 라이트 연산의 부하는 더이상 증가하지 않는 디퍼드 렌더러를 선택할 수 밖에 없었습니다. 하지만 우린 아니지요. 저사양 목표라면 쓰면 안됩니다.

어쨌건 포워드 렌더러를 써야 하는 우리 게임의 상황에서, 다이나믹 라이트의 추가는 무척 힘든 일이었습니다. 사양을 낮추려고 폴리곤을 줄이고 텍스쳐를 줄였습니다만 라이트를 하나 추가할수록 엄청난 수치의 Draw call이 증가하면서 사양이 기하급수적으로 늘어나게 되어 버리므로 어쩔 수 없이 라이트 하나만을 사용 (다이렉트 라이트. 실제로 이렇게 라이트를 하나만 사용하는 방법은 많은 포워드 렌더링 게임에서의 오랜 숙명이었습니다) 할 수 밖에 없었습니다.

그래서 추가적 라이트 효과로 멋진 배경을 만드려면 어쩔 수 없이 라이트가 아닌 ‘맵핑’ 으로 라이트 효과를 내야 했었으며, 이것이 라이트맵입니다. 라이트맵은 맵핑이기 때문에 조명연산이 전혀 되지 않는다는 장점이 있지만, 텍스쳐 장수가 늘어나고 무엇보다 라이트맵을 굽는 (Baking) 작업 자체가 힘든 작업이며, 수정도 용이하지 않다는 단점이 있었습니다. 그나마 유니티의 라이트맵은 굉장히 편하지만 말이지요.

하지만 라이트맵이 만들기 힘들다고 안쓸 수 없는게… 위에서 말했듯 실시간 라이트를 하나 이상 추가하면 대단히 느려지고 (간단하게 2배 느려진다고 생각하셔도 무방할 정도) …

그래서 포기하고 있었는데..

그래서 이래저래 방법을 찾으며 옵션별 세부사항 정하다가 포워드 렌더링의 세부 문서를 발견하고 번역해 보게 됩니다.

http://intra.ndoors.com/center/board/view.asp?list_seq=213443&board_seq=313&page=1&search_option=&search_letter=&readchk_flag=I

그러자, 유니티의 포워드 렌더링에서는 라이트를 일반적 상식과 조금 다르게 처리한다는 것을 알 수 있었습니다. 라이트가 추가될 때 마다 무조건 한 pass (렌더링 한 사이클) 를 돌아야 했던 겜브리오와는 다르게, 라이트마다 조금씩 다르게 설정을 하는 것을 알 수 있었지요.

즉 라이트가 있을때 마다 pass가 무조건 도는게 아니라, pass를 돌 일정 개수의 라이트를 옵션에서 정할 수 있게 해 놓았다는 것입니다.

이것인 즉 Pixel Light Count .( 픽셀 라이트 카운트는 한 픽셀마다 라이트의 밝기를 계산하는 매우 정밀한, 그러면서 일반적인 라이트이며, 일반적으로 말하는 ‘조명 영향’은 이것을 의미합니다.) 옵션에서 지정한 만큼의 라이트만 픽셀 라이트로 계산하도록 하겠다라는 것이며, 지정된 그 수치를 벗어나는 라이트는 다시 2단계의 저급 라이트 - 가벼운 - 로 자동 변환해서 계산하게 됩니다.
즉 여기서는 지정된 수치 이상의 라이트가 추가되더라도 무조건 픽셀 라이트로 다 계산하지 않고, 일단 저렴한 버텍스 라이트로 4개까지는 더 버텨보다가 싸구려인 SH(구면조화함수) 라이트로 나머지는 전부 처리해 버린다고 합니다. 그러므로 실시간 라이트의 개수를 옵션에서 능동적으로 제어할 수 있다는 말인거죠. 물론 퀄리티는 좀 떨어지겠지만.

이거라면 …? 잘하면 라이트맵을 쓰지 않아도 현재 그래픽 디자이너 분들이 사용하는 다이나믹 라이트를 다 사용할 수 있을지도 모릅니다. 물론 어떤 단점도 분명 존재하긴 하겠지만 말입니다. 라이트맵 굽지 않고 그냥 라이트를 쓸 수 있다면 그게 어디입니까.

실험.

그래서 이 이론을 그대로 실험해 보는 작업을 시작했습니다. 테스트할 맵은 현재 다이나믹 라이트가 10개 박혀있는 남만의 섹션1 던전. 크기는 크지 않지만 두 개의 디렉셔널 라이트와 함께 여러 개의 포인트 라이트가 박혀 있습니다.
이걸 그대로 사용하면, 즉 모두 픽셀라이트로 계산하도록 처리하면,

그림자도 없는 상태에서 드로우콜만 1300이 넘어갑니다 . 물론 이렇게 쓸 일은 없겠지요.

그래서 극단적으로 픽셀 라이트 카운트를 0로 떨어뜨려봤습니다. 라이트의 품질차이는… 살짝 느껴집니다만 스샷으로는 잘 모를 정도입니다. 이론대로라면 지금 상태는 픽셀라이트가 하나도 없고 버텍스 라이트 4개와 SH 라이트 6개로 바뀌어 있는 거겠죠.

그 증거는 드로우콜에서 나타납니다. 무려 273 !
이게 어느 정도냐고요?

픽셀라이트 10개로 풀어놓았던 상태에서, “라이트를 모두 지웠을때” 와 같은 퍼포먼스입니다.
즉 옵션만 낮춤으로써, 라이트를 모두 지운것과 같은 퍼포먼스를 얻을 수 있다는 얘기입니다.
정밀도가 좀 떨어지는게 보입니다만, 거의 상대비교를 해야 보일 수 있을 정도이므로 퀄리티에서 큰 걱정은 안해도 됩니다.

결론적으로 옵션에서 픽셀라이트 개수만 조절하면 라이트를 모두 없앤 것 정도까지의 퍼포먼스를 자유자재로 제어할 수 있다는 얘기입니다. 물론 그렇다고 해서 라이트가 마구 박아도 된다는 얘긴 아닙니다 :) 버텍스 라이트나 SH 라이트는 픽셀라이트에 비할바 없이 가볍지만 꼭 장점만 있는건 아니거든요.

단점.

일단 라이트맵과 비교해서의 단점은 : 그림자가 없습니다.
그림자를 켜면 되지 않겠냐고 하시겠지만… 픽셀라이트를 제거할 정도까지 옵션을 낮춘다는 말은 이미 그림자도 없앴다는 말입니다…. 그러므로 이걸 사용하게 되면 그림자는 없다고 보시면 됩니다.

그 다음의 단점은 : 배경 구성할때 좀 주의해야 합니다.

무슨 말이냐면,
이런 겁니다.

예를 들어 이 맵. 이런 맵 말이죠. 실내이고 어두워서 라이트의 맛을 한껏 낸 맵입니다. 아마도 라이트 효과가 안보이셔서 픽셀라이트 카운트를 7로 올려놓으셨는가 보군요.

이런 맵은 픽셀라이트 카운트를 0로 해버리면 무척 ‘플렛’ 하게 되어 버립니다. 아까 봤던 야외 배경처럼 라이트의 영향이 그렇게 강렬하지 않은 맵은 상관없는데, 이렇게 강렬하면 라이트의 갯수 제한이 이미지에 영향을 끼칩니다.

뭐 라이트를 1개나 2개 정도로 타협할 수도 있지만, 7개만큼의 효과는 나오지 않습니다.

그 이유는 " 한 오브젝트에 몇 개까지의 빛이 효과를 미칠거냐" (여기서의 빛은 정밀한 픽셀라이트를 의미합니다) 를 제한하는 이 옵션의 근본적 문제입니다.
좀더 극단적인 예를 볼까요.

예를 들어 이런 스타일. 굉장히 분위기있고 멋집니다. 분명 라이팅이 아니었으면 이렇게 멋진 장면을 나타낼 수 없었겠지요.
현재 라이트는 4개쯤 보이고 있습니다.

그런데 여기서 권장인 1개 정도로 제한해 버리면,
이런 현상이 나타날 수 있습니다. 이것은 왜 일어난 것일까요?

이것은 모델링된 오브젝트의 형태 때문입니다. 자 잘 보시면 저 길은 한 덩어리입니다. 물론 드로우콜을 위해서 매우 이상적인 작업물입니다! 훌륭합니다!

그렇지만 라이팅의 측면에서 보면 조금 다릅니다. 라이팅에서 영향을 끼치는 범위는 ‘오브젝트에 얼마나 영향을 끼치느냐’ 인데, 이 오브젝트의 중심축은 먼 쪽 1번 라이트에 근접해 있습니다. 즉 이 오브젝트는 아래에 있는 2번 라이트보다 위에 있는 1번 라이트에 더 영향을 받는다고 생각하고 있는 것입니다.

그런 상황에서 ‘조명 1개에만 영향받아라’ 라고 명령을 내렸으니, 멀리 있는 (사실은 거리보다는 밝기를 인식합니다만, 그냥 넘어가겠습니다. 그 원리까지 설명하면 길어지니…) 2번 라이트의 영향은 상콤하게 무시해 줘 버린 것입니다. 재미있게도 이것은 픽셀라이트를 0 로 해도 마찬가지입니다. 저렴한 버텍스 라이트가 가동되어도 역시 이 라이트는 ‘너무 멀다’ 라고 인식하는 것입니다.

이런 경우 해결책은 없을까요? 물론 있습니다!

그것은 라이트를 어떻게 박을 것이냐를 미리 계획하여 오브젝트를 분리해 버리면 됩니다.
즉 한 오브젝트당 한 라이트를 받으므로, 여기서는 오브젝트를 분리해 버려서 두 개로 만들어 버리면 되는 것입니다.

물론 저 부분에 조명 경계선이 나올 것이 걱정되기도 합니다. 하지만 지금 케이스같은 경우에서는 그런 걱정은 전혀 할 필요 없이 효과가 좋았습니다. 사실 이런 정도로 굉장히 눈에 잘 띄게 영향을 주는 라이트는 보통 1개 정도가 대부분이기 때문에, 라이트의 경계가 끝나는 부분에서 끊어지면 그다지 눈에 안띄게 됩니다.

Conclusion (결론)

일단 실시간 라이트를 유지하면서 퍼포먼스를 떨어뜨리지 않고 작업을 할 수 있는 방법에 대해 연구해 보았습니다.

라이트맵이 물론 퀄리티도 좋고 그림자도 나오지만, 작업량이 만만치 않고 수정하기가 대단히 어려운 단점이 있어서 겁내고 있었습니다만 거기에 대한 대안이 나와서 기쁘게 연구해 보았습니다.

일단 이 방식의 장점은

라이트맵 베이킹에 대한 부담이 줄어든다
옵션에 따라 퀄리티와 퍼포먼스 제어가 용이하다
작업의 수정이 매우 간편하다

그리고 단점도 물론 존재합니다

그림자 안나옴
라이트 정밀도 떨어짐
배경 디자인 할 때 라이트의 영향에 따라 오브젝트를 분리해 줘야 좋은 효과가 나옴. 덕분에 약간의 드로우콜 상승유발.
보통 픽셀라이팅 제한을 1로 해두므로 (2로 할까….) 한 오브젝트에 여러 색의 국지적인 강렬한 효과를 주기에는 무리가 있습니다.

하지만 결론적으로 단점보다는 장점이 매우 커서 말이죠… 사용에서 고려만 잘 한다면 이쪽 장점이 더 클 것으로 보이므로 사용 추천입니다 :)

쉽잖아요.

GDC 강연 참관기 : 수요일 강연내용

Thu, 10 Mar 2011 08:56:47 +0000

그다음 강연은

Beyond Horror: Art Directing DEAD SPACE 2

Ian Milham (Electronic Arts Redwood Shores)

아… 명작 데드 스페이스였습니다만, 전 이런 호러물을 못하는지라 ㄷㄷㄷ 바이오 하자드도 하다가 포기했어유…
특히다 데드 스페이스는 데모만 잠깐 하기만 해도 동공확대에 심장떨림에 …

일단 수위도 높구요

싫으신분은 저 강의 들으러 가시래요 ㅋㅋㅋ “43살의 여자를 위한 게임 디자인하기 강의실은 저기입니다”

일단 데드 스페이스 (이하DS) 1 복습을 하고, 2에서 어떻게 개선했느냐에 대한 내용이었습니다.

이게 강연주제. 1편에서는 좀 뭐랄까 너무 공포위주에 단편적이었달까…
그래서 2편에는 공포영화에서 우주액션로망판타스틱 영화로 바뀌었답니다.

왼쪽의 게임이 1이라면 2는 오른쪽 느낌으로 . 13일의 금요일 느낌에서 스타워즈나 터미네이터 느낌으로 말이죠.

건물 모티브 얻은 장면들입니다. 2 얘기겠죠? 1인가요 이거? 중간중간 이게 1얘긴지 2얘긴지 헷갈립니다.
게임을 해봤다면 단박에 이해했을텐데 말이죠.

1편의 반성들. 심부름꾼 소년 같이 느꼈다 ㅋㅋㅋ
전체적으로 좀 단조로웠지 않냐.. 라는 겁니다. 뭐 전 1편을 안해본지라.

호러를 넘어가자!! 좀 더 다양하게!!! 좀 거시기 .. 좋게.. 좋은데… 말로 하기가 그렇네…

다양하게 하기 위해 한 작업 리스트들.

일단 칼라 가이드. 챕터별 칼라 가이드를 만들어 점점 고조되다가 차갑게 변하는 색으로 유도하였습니다.

칼라 가이드에 맞춘 원화

나중엔 퍼래지죠? 전체적으로..

배경 얘기

병원을 예로 들면, 의도적으로 모호하게 디자인했다던가… 디테일 살리기라던가.. 몇몇 의도가 있었슴다.

칼라 가이드는 이렇구요.

화이트와 블루와 그린, 그리고 노랑 포인트. 저거 의미하는거 들었는데 잊었네요.

다른 배경의 케이스 스터디 : 퍼블릭 에리어.

이제 난 어딨는지 알겠다! … 이 월드에 대해 유저가 이해하게 만든다던가, 스케일 크게 만들기.. 등등의 목표

확실히 역사를 설명해 주는 듯 하군요.

주인공 사진도 나오고 한다는데 1편을 안해봐서 주인공이 무슨 취급을 당하고 있는지는 잘…

호오 사이비 종교 교회 디자인이라… 플레이어가 포위당해있다는 느낌을 만들었다..?

교회의 핵심문양입니다. 꼬인 손이 기본 모티브로군요

그리고 이 디자인은 이렇게 쓰였습니다.

몬스터 디자인입니다. 일단 생긴게 제가 싫어하는 모양이라 그런지 귀에도 안들림 (..)

플레이어 캐릭터 각종 시안작업들입니다.

으악 디자인 의도 들었는데 잊었다 .. 역시 사진만으로 기억을 되살리는건 무리데스.

그나마 기억나는 부분이군요. 엔진에 맞춘 디자인을 했단 얘기죠. 작은 라이트들로 상태를 바꾸고, 면의 중간에 폴리곤이 뭉치는 것을 방지하고 외각에다가 폴리곤을 집중해서 디테일을 강조했다는 얘기.
그리고 팀에 맞춘 디자인을 했다는 얘기죠.
다른 팀들은 라이팅 담당자가 없는 경우도 있는데 우린 6명이나 있었지요.
그리고 특수효과 툴이 킹왕짱 좋았어요.
그래서 우리는 아이유 위주로 환경 위주로 가기로 했지요.

ㅋㅋㅋㅋ 와우! 둥근 오브젝트예요! 오브젝트가 각지면 사람들은 폴리곤이 적고 디테일이 적다고 느끼죠. 그래서 동그란걸 많이 넣었어요 !!!

인터페이스를 왜 숨겼냐면. 그래야 무섭거등요 .

그리고 중요한 얘기. 평론가들은 무의식중에 그 그림에 보이는 숫자들을 인식해서 점수를 주더군요. 앞의 007은 00이 세로로 세워져 있는 그림을 보고 8이 연상되어서 84점을

오른쪽 007은 7이 있어서 71점을.

그래서 우리는 곳곳에 90을 넣었어요! 그랬더니 90점을 받았죠!!! 아아 이것은 진리.

사실 게임을 잘 모르고 듣다보니 중간에 뭘 말하는거여? 라고 넘어가는 부분이 너무 많았다는 것이 단점인 강연이었습니다 ㄷㄷㄷ
역시 이런건 팬심으로 들어갔어야 하는건데.
그래도 거의 유일하고 제대로 된 Art 전문 세션이었어요.

그다음 세션은 수요일 마지막 세션.

Punching Above Your Weight: Small Art Teams, Big Games

Tim Appleby (SplashDamage) and Paul Greveson (Splash Damage)

흠… 작은 팀으로 큰 게임 만들기라?
개인적으로 무척 많은 관심을 가진 주제라서 이유없이 선택했습니다. 제가 진정으로 지향하고 있는 팀의 모습이기도 하구요.
메니지먼트라던가 그런 말을 하려나?

… 결론은 아니었습죠.

결국 그래픽 리소스 얘기였습니다.

스플레쉬 데미지는 MOD 팀으로 시작한 역사가 꽤 되는 회사였군요. 주로 FPS류의 게임을 만들었습니다 .

프로젝트에서의 목표는 캐릭터 커스터마이징하고 무기 커스터마이징을 중심으로 각종 아이템들을…

팀에서는 원하는 의도를 제대로 만들면서 스케줄을 맞출 수 있도록. 제가 좋아하는 영역입니다.

뭐 실수를 빨리 해서 한계를 빨리 하자는 좋은 말씀입니다.
아무래도 캐릭터 커스터마이징이 좀 큰일이라 그게 좀 위험…

일단 캐릭터 체형만 해도 6종이란 말이죠. 옷만 해도 6개씩 만들어야 한다는 거예요
전 또 이걸 자동화 시켰다는줄 알았더니 “진짜 그냥 만들기” 내용이었더군요. 하긴 뭐 온라인 게임도 아니니.

일단 체형 변경은 마야의 블렌드 쉐이프 기능으로 바꿨답니다. 흠 그렇게 하면 보통 어느 정도 한계가 있지 않던가?

한계는 개뿔. 실력으로 극복합니다 ㄷㄷㄷㄷ

텍스쳐는 레이어 베이킹 ! 저걸 하려면 텍스쳐의 위치가 정확히 고정되어 있어야 하죠. 언제나 효율성은 고정됨에서 나오는 법입니다.

이렇게 고정되어 있었다는 거죠. 과연, 좋은 방법입니다. 나중에 한 번 해볼까…
문제는 온라인 게임은 저걸 다 따로 조합하는 경우가 많아서 곤란하죠.

무서운 인간들. 텍스쳐만드로 낸 퀄리티인데도 훌륭 ㄷㄷㄷ

이렇게 옷도 필요합니다. 그것도 아주 많이. 개노가다가 필요합니다

자동으로 한 번에 처리해주길 원한거죠

뭐 예를 들어 지브러쉬 만들고 그걸 마야로 로폴리 만들면, 자동으로 팔만 떼어서 1인칭 시점때 보이는 팔을 생성시켜 준다던가

이 툴을 이용하면 스키닝도 버튼 하나로 끝내줍니다.

게다가 체형별 옷도 자동생성!!

역시 툴이 짱이셈.
개노가다를 원클릭으로.

옷끼리 맞닿는 부분을 런타임으로 처리했다는지 베이킹으로 처리했다는지는 잘 못들었습니다. 어쨌건 가이드를 만들어 붙였다능. 작업하는 스타일 봐서는 런타임보다는 구웠지 않았을까.

어쨌거나 이렇게 옷에다 문신에다가 아이템들을 조합해서 멋지구리한 조합이 가능하게 되었습니다.

이건 기능보다 실력문제인거 같아…

요리요리조리조리 색상조합툴.

이제 준비는 끝@!

자 이제 연구를 끝냈으니까 문서를 만들고 스케줄을 확립해야죵.

이제 그래픽 스타일을 결정할 때입죠. 스타일은 약간 미래형하고 세기말 디자인 두 종족으로 가기로 했슴다

이제 얼굴 베리를 생각할 때였죠. 사람들이 왜 얼굴이 그리 기냐고 묻더군요

목표도 잡았습니다. 표정도 변화했으면 좋겠고 영상버전과 로우폴 버전도 만들었으면 좋겠고 등등…

방식은 지브러쉬에서 섭디비전 2로 넘겨서 시네마틱과 인게임 소스 만들기.

시네마틱용은 섭디비전 2단계 넘긴걸로 했지용
본입니다 본.

머리 베리에이션 경계는 저기

요렇게

그래서 이렇게 다양하게
뭐야 진짜 실시간 조합이 아니라 일일히 다 만든거야? 하긴 뭐 온라인 게임도 아니니까…

턱은 저기.

데이터는? “외주줬습니다”

넹 외주사 ㄳ

결과는 킹왕짱. 뭐야 얘네.

헐퀴 양키센스.

무기 커스터마이징도 해야죠. 할일이 열라 많았슴다.

문서화와 심플화 프로토타입. 뭐 기본이지만 중요한 것들

다양한 조합들입죠. 센스 참…

작은팀으로 큰 그래픽 처리하는건

테스트 많이 해 두시고
확실한 문서화
그리고 외주사를 믿으세요 (ㅎㅎ)

넵 뭐 좋은 내용으로 끝맺음.

단지 그래픽 데이터를 얼마나 많이 뽑아낼수 있느냐라는 내용이었습니다만, 결과물 자체가 굉장히 훌륭해서 뭐라 할 말이 없었습니다. 역시 좋은 게임을 내놓으면 뭐라고 말해도 굽신굽신.

GDC 강연 참관기 : 수요일 강연내용

Thu, 10 Mar 2011 01:47:56 +0000

은혜로우신 회사의 하늘과 같으신 은총덕분에 (…)

난생처음 GDC에 참가하게 되었습니다. 프로젝트도 한참 바쁜때라 사실 거의 준비도 못하고 조사도 못하고 영어공부도 못하고 (어차피 해봤자 소용없고) 무작정 룰루랄라. 일단 회사일에 구멍만 나지 않게 만들고 출발하는 것이 급했습니다.
전자여권에다가 ESTA 인가 하는 전자 입국 신고서 제출에, 자잘한 준비만 해도 꽤 신경쓰이더군요.

처음 참가하는 거라 사실 어리버리했습니다. 주변에 누가 갔다온 사람이 있어서 요령을 알려준 것도 아니고, 미쿡이란 곳도 가본지 거의 10년이나 된 곳이라, 뭘 어떻게 들어야 할지, 일정은 어떻게 될지 완전 무경험의 상태니 스트레스가 장난이 아니더군요. 게다가 정신없어서 홈페이지도 제대로 둘러보지 못하고, 강연계획도 제대로 못짰고, 샌프란시스코가 어디 붙어 있는거여…

그래서 가능한한 개기지말고 (평소와는 다르게 말입니다) 회사에서 만들어준 코스대로 순순히 따라서 조용히 다니자… 가 이번 GDC의 목표였습니다.

패스는 All Access Pass가 아닌 메인 컨퍼런스용 패스였기 때문에 수요일부터 참관 가능했으므로, 첫날(월)에는 17시간의 시차를 이끌고 어딘가 왔다갔다, 둘째날(화)에는 어떤 디자인 회사 방문과 역시 시차적응 여행으로 보내고, 셋째날 키노트부터 참석하였습니다. 참고로 구글의 선물공세는 첫날과 둘째날 뿐이었다는 사실 . 쳇.

셋째날 첫 시간 키노트는

Video Games Turn 25: A Historical Perspective and Vision for the Future
Satoru Iwata (Nintendo Co., Ltd.)

(일단 지금와서 생각해보니, 강연 내용을 적었어야 했었나 봅니다. 사진찍는데 더 우선을 하다 보니 정작 강연내용이 많이 기억 안나네요. 만약 다음에 또 간다면 사진은 뭔가 자동으로 찍게끔 만들어 놓고 강연 내용 정리를 우선해야겠습니다. )

어쨌건 첫 세션은 닌텐도 사장 아저씨의 닌텐도 3DS 광고 세션.

키노트 세션을 돈주고 사셨다는 소문도 들리고 (… 뭐 어느 관계자분께 들은 소문이긴 하지만),

컨텐츠가 정말 중요하고 짱이네. 머스트 해브 아이템을 만들어야만 하네 라고 하면서 3DS 를 광고하셨습니다만

요즘 게임이 게임이냐… 라고 까는 부분에서는 아이폰에 대한 열등감이 살짝 내비치다가 결국 3DS 소개에서 그 짐작이 확실해 집니다.

뭐 얼굴 사진을 이용한 Mii 생성기나 그런 얼굴인식 게임들은 그렇다 쳐도…

네트워크로 3D 무비 트레일러도 다운받고 길에서도 네트웍을 할 수 있어서 어쩌구…

그래서 회사에서도 회사 사람들 끼리 네트웍으로 게임하고 어쩌구 있다고… 스마트폰 안써보셨어요?

닌텐도 e 샵? 지울 수 없는 앱스토어 따라잡기의 스멜이…

뭐 일단 3DS 에서는 마리오가 3D로 점프한다니까요

젤다도 준비중이라고 하고. 닌텐도는 아이폰에게 밀린 게임시장을 자신들의 전통적인 컨텐츠로 이슈를 불러 일으키며 만회를 하려 하는 모양입니다.

불가능한걸 가능하게 하라… 그 불가능한 것이 네트웍 되는 구형 렌티큘러 방식의 3DS는 아닌 것 같습니다만.

좋은 얘기로 끝내긴 했습니다만, 키노트라고 불리기엔 너무 광고 성향이 짙은데다가 왠지 아이폰에 잠식당하고 있는 닌텐도 시장에 위기감을 느끼고 조바심내고 있다는 것을 애써 숨기는 듯한 강연이었습니다.

실제로 전시장에서도 3DS의 인기는 시들한 편이었으며, 조작해 본 느낌도 인상적이라기 보다는 좀 조잡한 느낌이었습니다.
MUST - HAVE 하고 싶지는 않더군요.

오히려 진정한 MUST - HAVE는 강연장 바로 몇백미터 옆에서 발표대기중이었습니다. 내가 잡스형이랑 가까이 있다니!!! 내가 잡스형이랑 가까이 있다니!!! 내가 잡스형이랑 가까이 있다니!!!

셋째날 두 번째 강연은

Making Game Trailers: Cost-effective Results for All Budgets

Tim Roe (Sony Computer Entertainment Europe)

게임 트레일러를 어떻게 싸고 효율적으로 만들 수 있을 것이냐… 라는 강연이었습니다…. 만
이번엔 강연을 전부 동영상으로 찍어 봤더니, 정작 나중에 확인해 보니 파일 옮길때 동영상이 모두 겹쳐져 버려서 데이터 유실. 우왕굿. 첫 GDC 참여의 어리버리함이 낳은 결과입니다.

그래서 일주일이나 지난 기억을 겨우 되살려 보면, 게임 트레일러 (광고영상) 만들때 계약서 쓰는 법이라던가, 제한사항 정하는 거라던가, 금액은 첨에 반 주고 중간 컨펌 되면 25% 주고 하는 식으로 해라, 영상 컨펌 단계에서는 이런 정도에서 컨펌하도록 해라.
그리고 큰 방송용 영상 전문 제작 업체에 맡길때의 장단점부터 소규모 업체, 프리랜서, 자체 제작 할 때의 장단점 비교등의 내용이었습니다.

보통 이런 영상 외주 줄때 ‘다른 회사는 어떻게 하고 있지?’ 라는 생각이 많이 들었었는데 그 부분을 볼 수 있었던건 도움이 꽤 되었네요. (그렇지만 자료따위는 없어요 으아아악)

셋째날 세 번째 강연은

Cinematic Character Lighting in STAR WARS: THE OLD REPUBLIC

Ben Cloward (Bioware) and Aaron Otstott (Bioware)

바이오웨어!!! 나중에 들어서 안 얘기지만 강연을 고를 때에는 강연 내용도 중요하지만 강연자가 누구이냐도 잘 정해야 합니다. 유명한 네임드거나 강연을 많이 해본 사람일수록 강연이 알차고 좋고, 누군지도 모르는 듣보잡일 경우에는 강연의 질이 나쁠 확률이 큽니다. 여기 벤 아저씨는 TA 계에서 네임드라고 하는군요.

스타워즈 : 구 공화국 의 시네마틱 라이팅입니다. 시네마틱이라고 해서 영화와 같은 화면을 말하나? 라고 생각했었습니다만 알고보니 이벤트 영상용 화면을 말하는 것 같더군요. 라이팅 얘기니 안들을 수 없지요.

스타워즈 : 구 공화국 게임 (…안해봤습니다) 에서는 각 행성별 조명 설정을 위해 라이팅용 와핑 텍스쳐 (Warping texture) 를 사용하였습니다. 팀포에서도 사용한, 흔한 방법이지요. 한 개의 라이트로 다양한 라이트 느낌을 낼 수 있는…
여기서는 그라디언트 라이트라고 불리더군요. 뭐 이름은 짓기 나름이니까.

그래서 이렇게 칙칙한 조명이

요렇게 바뀌었습니다.

다 죽어가는 진흙인형이

생기있게 되었구요.

뭐 이 라이팅은 간단하고 널리 알려진 방식입니다. 어려운 얘기는 아니네요.

이제 림라이트에 대해 설명합니다. TA 답게 기술적인것 말고, 림 라이트 같은 조명의 존재의의와 표현 의도를 설명합니다.

근데 그냥 림라이트를 쓴게 아니라는군요. 좋게 보이기 위해, 아트 디렉터가 제어할 수 있도록, 원래 버전은 별로라서…
혁신을 좀 했답니다.

림라이트 없는 상태

몇몇 림라이트들의 비교. Velvely ????

강도조정은 스페큘러 마스킹에 맞췄다는군요.

흠 뭐 그것 괜찮죠. 특히 이런 갑옷 많이 나오는 게임이라면.

흰색 림라이트는 구리고, 칼라 림라이트도 구리답니다. 조금 후에 오른쪽 그림도 X 되었습니다.

재미있게도 림라이트 칼라를 앞에 설명한 Warp 칼라와 연동시켰습니다. 호오 재밌군요 이거. 어렵지도 복잡하지도 않은 작은 꼼수인데 결과가 그럴듯 할 것 같습니다.

그걸 다시 림라이트 마스크와 조합. 너네 채널 몇 개 쓴거냐?

뭐 그래서 이렇던 녀석이

림라이트로 이렇게 되었습니다.

라이트 방향 조정입니다.

캐릭터한테 너무 기울어져 있어서 고쳤다는군요

즉 시네마틱 영상에서 조명이 너무 가파른 각도로 비추길래

조명 각도를 바꿨답니다. 배경 조명은 그대로인걸 주의.

연출영상에서 그냥 배경에 있는 조명을 가져다 쓰면 너무 참 빈곤해 보여서 , 카메라와 연동되는 ‘수작업의’ 조명 각도가 있어야 좀 볼륨있어 보이고 그런다는건데..

다시말해 이 장면은

조명각도가 저기로 비치는데 카메라는 저렇게 보는거여.

그러니 이렇게 나올 수 밖에.

그래서 카메라 쪽에 맞게 조명을 회전.

그랬더니 이렇게 해피.

이런 거랍니다.

근데 라이트가 언제나 왼쪽 위에서 비치니까 그것도 나름대로 이상한거라.

그래서 우리 신에서는 진짜 라이트가 왼쪽이냐 오른쪽이냐에 따라 그거에 맞춰서 움직이게 해뒀다능.

스카이 스페큘러.

슬쩍 보기엔 큐브맵을 이용한 엠비언트 큐브에 가까운듯.

맞네. 거기에 스페큘러 파워 공식 +

즉 좀 이렇게 플렛한 이미지였는데

좀 더 입체감이… 기계류 많은 케이스일 때는 좋겠네요

어두침침하던 가슴이

빛나주고

어둡게 묻히던 캐릭터와 배경이

밝아졌어요.

흔히 알고 있는 DOF 입니다.

시네마틱하게 보이려면 중요하답니다.

뭐 그렇긴 하죠

다렉트 9 에서도 잘나오고, 반투명도 정확히 나오고, 조절도 정확히 할 수 있게 만들기를 원했죠

퍼포먼스라던가 … 유지하면서 자동으로 잘 처리되길 원했구요.

반투명을 DOF 할 때는 이놈이 Z 버퍼를 안쓰니까 골치아파요

그래서 해결책이… 반투명인 놈들은 무조건 블러주기.
Z 버퍼로 해결하지 않기.

문제가.. 뒤의 난간 부분인데, 난간과 이펙트가 만나는 부분이 자연스럽게 흐려지지 않고 경계선이 선명해 져요

이걸 이렇게 해결했다는 말씀.

즉 멀리 있는 반투명 오브젝트는 그냥 일반 오브젝트와 같이 찍되 블러를 주고, 가까이에 있는 이펙트만 따로 나중에 찍는다는 방식.

이렇게 하면 가까운데 이펙트는 선명하고 멀리 이펙트는 블러가 잘됩니다.

즉 보통 DOF가 카메라 촛점거리에 따라 저렇게 보이는데

반투명은 선명한 가까운 반투명과, 먼 블러된 반투명 두 종류로 만들어 거리에 따라 적절히 섞어줬다는 겁니다 .

덕분에 해피.

컨트롤도 쉬웠다. 정확하게 잘 나오더라.

잘 합치기.

원화에서 요구한 약간 반쯤 만화적인 표현을 잘 표현해 냈다. 왼쪽이 원화, 오른쪽이 3D

그렇게 원화가 요구한걸 구현했고, 캐릭터를 배경과 분리했다.

해보니 괜 찮더란 말이지.

이렇게 말이지

조합이 중요하다.

누가 쉐이더를 짜는가? 그래픽이 아님 프로그래머가?
우리가 배운 바로는 테크니컬 아티스트가 프로그래머와 함께 일할때 젤 잘되더라
팀웍이 짱이삼.

어려운 내용은 아니었는데 쉽고 재미있고 좋은 내용이었습니다. 설명하는 아저씨도 발음도 킹왕짱 좋고 차근차근 말해서 정말 첨부터 끝까지 제대로 알아들은 몇 안되는 강연이었다능 +_+

Forward Rendering Path Details

Wed, 09 Mar 2011 17:22:53 +0000

Forward Rendering Path Details

포워드 렌더링 패스 디테일

This page describes details of Forward rendering path.

Forward Rendering path renders each object in one or more passes, depending on lights that affect the object. Lights themselves are also treated differently by Forward Rendering, depending on their settings and intensity.
이 페이지는 포워드 렌더링에 대한 자세한 서술 페이지예요.
하나 혹은 여러개의 패스의 각 포워드 렌더링 패스는 오브젝트에 영향을 끼치는 라이트에 달려 있어요. 라이트들은 포워드 렌더링에서 또한 다르게 취급되구요, 그들의 셋팅과 강도에 따라 좌우되지요.

Implementation Details

세부 진행

In Forward Rendering, some number of brightest lights that affect each object are rendered in fully per-pixel lit mode. Then, up to 4 point lights are calculated per-vertex. The other lights are computed as Spherical Harmonics (SH), which is much faster but is only an approximation. Whether a light will be per-pixel light or not is dependent on this:
포워드 렌더링에서, 각 오브젝트에 적용되는 가장 밝은 라이트들은 퍼 픽셀 라이트 모드로 온전하게 렌더링되어요, 그리고, 4개 까지의 라이트들은 퍼 버텍스 라이트로 계산되지요. 다른 라이트들은 Spherical Harmonics (SH) 로 계산되어요. 이것은 많이 빠르지만 대충 계산해요. 퍼 픽셀로 계산될지 아닐지는 아래에 따르지요 :

Lights that have their Render Mode set to Not Important are always per-vertex or SH.
렌더 모드에서 중요하지 않게 셋팅된 라이트들은 언제나 퍼 버텍스나 SH 로 계산돼요
Brightest directional light is always per-pixel.
최고로 밝은 디렉셔널 라이트는 언제나 퍼픽셀 라이트로 계산되어요.
Lights that have their Render Mode set to Important are always per-pixel.
렌더 모드에서 중요하게 셋팅된 라이트들은 언제나 퍼 픽셀 라이트로 계산되어요
If the above results in less lights than current Pixel Light Count Quality Setting, then more lights are rendered per-pixel, in order of decreasing brightness.
만약 위의 결과가 현재의 픽셀 라이트 카운트 퀄리티세팅보다 라이트수가 적으면 픽셀마다 더 많은 라이트가 렌더 됩니다. 밝기가 어두워 지는 순서로…

Rendering of each object happens as follows:
각 오브젝트의 렌더링은 다음과 같이 일어납니다 :

Base Pass applies one per-pixel directional light and all per-vertex/SH lights.
베이스 패스는 적용됩니다. 하나의 퍼 픽셀 디렉션 라이트와 모든 퍼 버텍스 / SH 라이트로.
Other per-pixel lights are rendered in additional passes, one pass for each light.
다른 퍼 픽셀 라이트는 추가의 패스로 렌더링 됩니다. 한 라이트당 한 패스로.

For example, if there is some object that’s affected by a number of lights (a circle in a picture below, affected by lights A to H): 예를 들어, 만약 어떤 오브젝트가 여러 개의 라이트에 영향을 받는다면 (아래 그림의 공이 A에서 H 까지의 라이트 영향을 받으면)

Let’s assume lights A to H have the same color & intensity, all all of them have Auto rendering mode, so they would be sorted in exactly this order for this object. The brightest lights will be rendered in per-pixel lit mode (A to D), then up to 4 lights in per-vertex lit mode (D to G), and finally the rest of lights in SH (G to H):
A 부터 H 까지의 각 라이트는 같은 색과 강도를 가지고 있다고 칩시다. 이 모두들은 자동 렌더링 모드라고 치고요, 그래서 이들은 이 오브젝트를 위한 오더에 확실히 정렬될겁니다. 가장 밝은 라이트들은 퍼 픽셀 라이트 모드로 렌더링 됩니다. (A에서 D) 그리고
4개까지 퍼 버텍스 라이트 모드가 됩니다 (D에서 G) , 그리고 최종적으로 나머지는 SH가 됩니다. (G에서 H 까지)

Note that light groups overlap; for example last per-pixel light blends into per-vertex lit mode so there are less “light popping” as objects and lights move around.
라이트 그룹이 오버렙 되는걸 주의하세요 ; 예를 들어 마지막 퍼 픽셀 라이트가 퍼 버텍스 라이트 모드와 블렌딩되고 그래서 그들은 라이트가 돌아다니면서 라이트 팝핑이 적은 오브젝트가 된다.

Base Pass

베이스 패스
Base pass renders object with one per-pixel directional light and all SH lights. This pass also adds any lightmaps, ambient and emissive lighting from the shader. Directional light rendered in this pass can have Shadows. Note that Lightmapped objects do not get illumination from SH lights.
베이스 패스는 오브젝트를 렌더합니다. 하나의 퍼 픽셀 디렉셔널 라이트와 모든 SH 라이트로. 이 패스는 또한 어떠한 라이트맵도 포함합니다. 엠비언트와 에미시브 라이트를 쉐이더를 통해서 더하기도 합니다. 디렉셔널 라이트는 이 패스에서 그림자를 그릴 수 있습니다. 라이트맵된 오브젝트는 SH 라이트를 통해서 빛날 수 없다는 점을 주의하세요.

Additional Passes

추가 패스

Additional passes are rendered for each additional per-pixel light that affect this object. Lights in these passes can’t have shadows (so in result, Forward Rendering supports one directional light with shadows).
추가 패스는 각 퍼 픽셀라이트가 오브젝트에 영향을 끼칠 때마다 렌더링 됩니다. 이 패스의 라이트는 그림자를 가지지 못합니다 .(그래서 결과적으로, 포워드 렌더링에서는 하나의 다이렉트 라이트로만 그림자가 만들어집니다)

Performance Considerations

퍼포먼스에서의 주의사항.

Spherical Harmonics lights are very fast to render. They have a tiny cost on the CPU, and are actually free for the GPU to apply (that is, base pass always computes SH lighting; but due to the way SH lights work, the cost is exactly the same no matter how many SH lights are there).

The downsides of SH lights are:
SH(구면조화함수) 라이트는 아주 빠릅니다. 이것은 CPU에 아주 작은 영향만 주며, GPU에는 완전 공짜입니다. ( 이것은, 베이스 패스는 언제나 SH 라이팅을 계산한다는 것입니다 : 그러나 SH 라이팅 작업 때문에, 그 부하는 SH 라이트가 얼마나 있냐에 상관없이 똑같습니다 ) SH 라이팅의 두 얼굴은 다음과 같습죠 :

They are computed at object’s vertices, not pixels. This means they do not support light Cookies or normal maps.
이것은 오브젝트의 버텍스를 계산합니다. 픽셀이 아닙죠. 이것은 라이트 쿠키나 노말맵을 절대 쓰지 못한다는 말입니다.
SH lighting is very low frequency. You can’t have sharp lighting transitions with SH lights. They are also only affecting the diffuse lighting (too low frequency for specular highlights).
SH 라이트는 굉장히 낮은 정밀도를 자랑합니다. 당신은 선명한 라이트 전환을 기대해서는 안됩니다. 이들은 또한 디퓨즈 라이트에만 영향을 끼칩니다 ( 스페큘러 표현하기에는 너무 낮은 정밀도를 가지고 있습니다)
SH lighting is is not local; point or spot SH lights close to some surface will “look wrong”.
SH 라이팅은 로컬(지역적인 라이트) 이 아닙니다 ; 포인트나 스팟 SH라이트는 어떤 가까운 면에서 “이상하게” 보일겁니다.

In summary, SH lights are often good enough for small dynamic objects.
요약하자면, SH 라이트는 작은 동적 오브젝트에는 보통 괜찮습니다.

퍼포먼스를 올리고 싶습니까? : 기획자를 위한 3D 그래픽스

Wed, 09 Mar 2011 11:46:24 +0000

게임의 퍼포먼스에 영향을 끼치는 인자들은 많이 있습니다. 버텍스라던가, 텍스쳐라던가, 애니메이션이라던가…
그렇지만 게임을 만들면서 프레임이 안 나올때, 어디가 문제인지 찾는 일은 보통 고역이 아닙니다.

삼품 물 쉐이더

Tue, 08 Mar 2011 10:15:36 +0000

삼국지에 들어가는 물 쉐이더입니다. 지금까지 만들어진 쉐이더중 가장 무거운 쉐이더로, (무려 3패스나 하니까요) 추후 퍼포먼스 테스트 이후에 옵션에 따라 조정될 수 있을 수도 있습니다. 무게로 따진다면 한 10g ?

그전의 물 쉐이더는 디퍼드 렌더링 상태에서만 출력되는 문제가 있었습니다. 때문에 이번 물 쉐이더는, 기존의 물과 거의 같은 퀄리티 (…와 편리한 사용까지 ..) 를 유지하면서 쉐이더 2.0 버전에서도 돌아갈 수 있도록 만들었습니다.

쉐이더 1.0 상태에서는 분홍색이 날겁니다. 그때 버전은 만약 필요하면 테스트하면서 그때 만드려구요.
당연하게도 모바일용으로 이걸 썼다간 난리날 겁니다 유후. ~
뭐 일단 물을 보면 이렇게 생겼습니다 잇힝.

옵션은 기존 물에서 별로 사용되지 않거나 느낌안좋은것들은 삭제하고, 효과 좋은것들만 축약해서 눌러놓았습니다.
여담이지만, 새로나온 물 스크립트 (연구해 봐야겠지만) 보다 떨어지지 않는다고 자부한다능…

알파를 없앨려고 했었습니다. (지금 아래 물 투명도가 사실은 투명도가 아니라서…)
근데 불투명한 물이 필요하긴 할 것 같아 이 옵션을 실제 투명도가 아닌, 굴절 이미지를 날려 버리는 기능과 연동해서 알파처럼 보이게 만들었습니다. 줄이면 검게 됩니다. 다른 색으로 가게 만들 수도 있긴 한데 공식이 지저분해져서…

덕분에 아래 tint color와 조합하면, 이렇게 묵직한 피바다 (!!!!) 느낌도 낼 수 있습니다. 후후후 이걸 노렸었습니다. 잘 나오는군요.

베이스 텍스쳐는 수치를 올리면 물 텍스쳐 느낌이 진하게 납니다. 맑고 얕은 물을 표현할때는 내리면 좋겠다능…

아참, 먼저 이실직고할 일이 있습니다. 저 굴절 효과를 잘 구현하긴 했습니다만, 물 속에 들어가 있지 않은 부분도 굴절효과가 나타나는 문제가 있습니다. 캐릭터 렌더링 순서 문제고, 좀 귀찮지만 고칠 수 있는 문제이기도 한데 (그래픽 작업이 필요…) 일단 냅둬 보기로 했습니다. 크게 느껴지지 않을 것 같아서 말이죠.

또하나, 지형이나 사물의 외각을 인식해서 물 포말이 나오는 기능이 없어졌습니다. 이 기능이 디퍼드 아니면 동작하질 않더라고요…

그래서 이전에 얼음물에 사용했던 버텍스 알파를 이용해서,

여기서는 버텍스 알파를 준 부분이 포말 텍스쳐가 나타나게 해 놓았습니다 >_<
일일히 지형과 맞닿는 부분에 수작업으로 색칠해 줘야 한다는 단점이 있지만, 덕분에 가볍고, 포워드 렌더러 상태에서도 잘 나타납니다.

단, 여기서는 UV 개수를 줄이기 위해서 UV좌표를 main texture와 맞춰버렸습니다. 즉 포말(egde) 텍스쳐는 따로 UV를 줄 수도 없고, 타일링이나 옵셋도 줄 수가 없이 그냥 메인 텍스쳐의 UV를 따라가게 됩니다.
싫으시면 말씀해 주시길.

역시 수치를 내리면 없어지구요.

단 노말맵은, UV2 를 사용하기 때문에 UV가 달라도 되고 타일링이 달라도 됩니다.

여기에 중요한 꼼수가 있는데, 메인 텍스쳐와 범프맵의 타일링 수치를 다르게 해 놓으면 흘러가는 속도도 달라지게 됩니다!!! 속도는 UV에 제어되기 때문이지요. 그렇게 되면 뭔가 2층 레이어로 흐르는 듯한 느낌을 만들 수도 있습니다.

반사 텍스쳐는 큐브맵이 아닙니다. 그냥 텍스쳐를 넣으세요. 쬐끔 더 가볍습니다. 반사도를 조절하면 반사 이미지의 강도를 조절할 수 있습니다.

굴절률을 올리면 많이 구겨지겠죠. 내리면 반대고.

스페큘러 칼라와 색상은 생각하시는 그대로입니다.

여기는 샌프란시스코

Wed, 02 Mar 2011 17:56:03 +0000

모스코니 센터.
아니 그냥 심심해서 와 봤더니 GDC가 열리고 있지 뭡니까.
레알.
지금은 새벽 1시. 잡니다.

정말 좋은 그래픽에 대해 생각해 보자.

Sun, 27 Feb 2011 12:27:52 +0000

Game Dev Story

정말 좋은 그래픽이란 무엇일까?

글 쓰신 주인장분에게 특별히 반감을 가지고 있거나 디스하려는 의도는 전혀 아니지만 (…)
비록 박쥐인생을 살고 있어도 그래픽에 뿌리를 둔 입장이라, 예전부터 많이 생각해 왔었던 부분이기도 하지요.
또한 많은 게임 지망생들이나 인터넷 커뮤니티에서도 회자되곤 하는 내용이곤 하고 말이지요.

보통, 게임에는 그래픽이 매우 중요하다! 라고 하는 파와 게임성과 그래픽은 상관없다!! 그래픽은 장식일 뿐이야! 높은 사람들은 그걸 몰라요… (… 어이 … 뭔가…전혀 상관없는 말이 들어갔잖아)
라는 이분법적인 의견으로 갈리면서 갑론을박을 펼치는 경우가 많았습니다만. 그 전에
‘좋은 그래픽’ 이란 정의는 무엇일까요?

사실 이런 갑론을박이 펼쳐지는 배경에는 좋은 그래픽의 정의가 서로 다른 경우가 많습니다.
그래픽은 게임과 별 상관없다라고 하시는 분들이 주로 드는 예로는 ‘낮은 그래픽의 게임도 충분히 재미있다’ 라는 것인데요.
여기서 낮다라고 하는 기준은 주로 기술적인 기준일 가능성이 큽니다. 즉 도트 그래픽은 나쁜 그래픽, 3D 기술을 사용한 그래픽은 좋은 그래픽이라고 하는 분류기준이지요. 그렇다면 입체영상이야말로 궁극의 그래픽?

그렇지만 그래픽과 게임이 상관있다라고 하시는 분들이 주장하는 부분은 (주장하는 분들도 못느끼고 계신 경우가 많지만 ) 그래픽이란 게임환경에 충분히 몰입할 수 있도록 하는 ‘전달자’ 라는 것입니다. 뭐 저야 당연히 이 분류에 속하지요. 예를 들어, 옛날에 즐겁게 했던 너구리 말입니다. 예 그 너구리. 뾰로뾰로뾰로 꼬리를 흔들면서 가시를 점프하고 항아리를 먹는…
굉장히 간단했지만 매우 재미있었던 게임이지요.

만일 이 게임이 다이렉트 11의 테셀레이트 기법과 각종 SSS 기법을 동원하고, 너구리의 털을 리얼하게 Fur로 제작했다면 게임이 더 재미있었을까요? (아아 상상만 해도 무섭군요. 그럼 가시에 찔리면 데드스페이스처럼 내장이 튀어나와야 하는 것인가…)
아닐겁니다. :) 사실 그래서 ‘거봐! 그래픽과 게임성은 상관없잖아! ’ 라고 주장하시는 분들이 생긴 것인데, 사실 이 논란은 초점이 잘못되어 있습니다.

정말 좋은 그래픽은 게임성에 어울리는 그래픽이지, 최신 기술을 도입한 그래픽이 아닙니다. 예를 들어 너구리과 같은 2차원적인 게임성을 가진 게임이라면, 굳이 풀 3D로 만들 이유는 당연히 없지만 ‘기술을 위한 비주얼을 정하는 것이 아니라 비주얼을 위한 기술을 정해야’ 하는 것입니다. 예를 들어 요즘같은 시대면 좀비vs플랜츠 같은 그래픽으로 너구리를 만들겠지요?
여기서 다시 질문하면, 좀비vs플랜츠 가 과연 “나쁜” 그래픽입니까??? (추가로 얘기하면, 괴혼이 ‘나쁜’ 그래픽이라고 말할 수 있나요?)

제가 생각하기에 좀비vs플랜츠는 정말 ‘좋은’ 그래픽입니다. 좋은 그래픽이란 게임에서 요구하는 분위기와 어울리며 (심의와도 어울려야 하고…) 플레이어의 상상력을 적당히 자극하면서 게임을 플레이할때 ‘즐거움을 더할 수 있는’ 그래픽이어야 합니다. 결코 디퍼드 렌더러를 이용해 멀티 라이트를 이용하고 이방성 필터링으로 텍스쳐를 처리하는게 아니라 말이지요.
TV가 나오고 입체영상이 나오는 이 세상에도 여전히 라디오는 인기있고 재미있으며, 디지털 입체영상이 예술로 인정받는 이 시대에도 여전히 먹으로 그리는 동양화도 아름다운 예술인 것입니다.

물론 여기에서 다소 ‘시대에 뒤떨어진’ 의 분류는 할 수 있겠지요. 예를 들어 마인크래프트 같은 경우 말입니다. 분명 게임성도 좋으며 사실 그 레고같은 그래픽으로 사람들의 상상력을 충분히 자극하는 ‘좋은’ 그래픽의 일종이라고 할 수 있습니다. 하지만 이 게임을 하시는 많은 분들이 ‘처음에는 이 그래픽에 당황스러웠다’ 라고 하시더군요. 무슨 얘기냐면, 게임을 시작하는 사람들의 상상력과 기대치에 맞지 않을때 사람들이 당황하며 진입장벽을 느낀다는 것입니다. 마인크래프트에 대한 기대는 , 아무런 정보없이 게임에 진입했을때 FPS와 같은 화면을 보여줍니다. 그러면서 사람들은 카스같은 FPS를 떠올리게 되지요. 그리고 생각합니다. ‘어? 이거 그래픽이 왜 이래?’

네에. 이것이 ‘사람들의 기대에 어긋나는 그래픽’ 의 예입니다. 분명 이것은 진입장벽이 되고, 사람들이 초기에 많이 떨어져 나가게 하는 요소가 되지요. 물론 적응하면 ‘새로운 기준’ 이 생겨 버리기 때문에 폐인처럼 마인크래프트에 빠져드는 사람들이 생기게 되는 것이니까, 그 이후엔 상관없지요. 하지만 초기 진입에는 사람들의 ‘기대’ 라는 것에 얼마나 부응할 것인지도 고려하지 않으면 안됩니다.

만약 ‘테라’ 처럼 몇백억을 들여서 MMORPG게임을 만들었는데, 막상 해보니 그래픽은 ‘뮤’ 정도의 수준이었다면 사람들은 어떻게 생각할까요? 게임은 정말로 재미있게 만들어서, 몇백억을 오직 ‘재미’ 에만 투자했다면 말입니다.

그럴 경우에는 분명 처음의 유저몰이에는 실패합니다. 사람들이 처음 MMO에 기대하고 오는 이유는 ‘새롭고 신기한 세계’ 에 대한 갈망도 그 이유니까요. 그럼 실패할까요? 아닙니다. 그 때부터 그래픽이 게임에 영향을 끼치는 것은, ‘게임의 세계와 얼마나 어울리게 만들어 놓았느냐’ 니까요. 이제부터는 진짜 게임성이 되고, 그 게임성에 그래픽이 한 부분으로 참여하게 됩니다. 더이상 얼굴마담이 아닌 게임의 한 ‘일부’ 로 말이죠. 이제부터가 길지만 진짜인 싸움이 되는 것입니다. 다들 아실 겁니다. 와우의 그래픽을 처음 보고 다소 실망했다가, 실제로 세계를 탐험해 보니 “폴리곤도 적고 텍스쳐도깨지고 별 것 아닌 것 같은데 아름다워!! 편안해!! " 라는걸 말이지요.

게임 그래픽은 게임성에 어울리게 존재해야 합니다. ‘좋은 코딩’ 이란 것이 ‘긴 코딩’ 의 의미가 아니듯, ‘좋은 그래픽’ 이 ‘기술적으로 높은’ 그래픽 이란 뜻은 아닙니다. 그런 의미에서 전 이 게임을 ‘좋은 그래픽’ 이라고 생각합니다. 아름답고 귀여운 그래픽의 한 장르인 ‘도트’ 그래픽을 훌륭하게 그려냈으며, 불타올라 다다다다 손을 저으며 일하는 것도 웃음짓게 합니다. 뿐만 아니라 이 작은 화면에 전체의 사무실을 이렇게 보기 편하며 아름답게 표현하는 방법은 이 방법 이상의 방법이 생각나지 않는군요. 저도 다시 도트가 찍어보고 싶어졌습니다 :)

이펙트용 기본 쉐이더 Additive/Multi/Standard 추가

Fri, 25 Feb 2011 18:03:41 +0000

이펙트 디자인에서 가장 쉽고 범용적으로 사용할 수 있는 쉐이더로, Particle 항목 아래에 들어 있는 쉐이더를 대치할 수 있는 쉐이더입니다. 퍼포먼스 테스트중, 머리식힐겸 간간히 만들었습니다 ㅎ

무게를 비롯하여 기본적인 것은 모두 같지만, 우리 이펙트 디자이너들에 맞게 개량되어 있습니다. 즉 가볍다는 말이죠 :)

다른점은 아래와 같습니다.

회전값이 있습니다.
0도에서 360도까지 , UV의 중심좌표를 기준으로 회전시킬 수 있는 것이 특징입니다.
멀티 쉐이더는 우리 식의 방법입니다.
기존에 들어 있는 쉐이더의 멀티는 뭔가 이상하더군요.우리 이펙트 디자이너들이 쓰는 방식으로 만들었습니다.
스텐다드 쉐이더는 알파 조절값이 있습니다.
역시 플로우 쉐이더와 마찬가지로, 다른 쉐이더는 Tint 값을 조정해서 투명도를 컨트롤 할 수 있는데 반해 스텐다드는 그게 안됩니다. 그래서 알파를 따로 만들었습니다.
좀 더 이미지가 부드럽습니다.
기존에 들어있던 파티클 이펙트 쉐이더는, 강하게 보이도록 *2 가 되어 있었습니다. 이펙트 디자이너분들은 이걸 싫어했구요.
여기선 그런 코드가 없기 때문에 이펙트가 부드럽습니다.

TKBG_IceWater Shader 업데이트

Fri, 25 Feb 2011 14:47:44 +0000

TKBG_IceWater 일명 얼음물 쉐이더가 업데이트 되었습니다!!!
원래는 쉐이더 작업이 중지된 상태였으나 퍼포먼스 테스트를 위한 프로젝트 업데이트 시간을 짬내서 제작하였습니다!!!
어셋 서버에는 물론 올라가 있고!!!

이제 당신도 디퍼드 렌더러 지원상태가 아닌 일반 포워드 렌더링 상태에서도 얼음물을 볼 수 있습니다!!!

물론 면을 추가하고 버텍스 알파를 추가해야 하는 수고스러움은 생겼지만… 나오는 결과물은 이전의 결과물과 동일한 퀄리티가 가능합니다!!! 그것도 무려 쉐이더 2.0 상태에서도!!! 아, 물론 외각을 자동으로 인식하던 기존의 기능보다 정밀도는 좀 떨어질 수 밖에 없지만 말입니다.

어쨌건 이 작업 덕분에 쉐이더 다이어트도 가능해 졌습니다! 더 이상 필요없는 셈플러와 Texcoord 들을 사용하지 않기 때문에, 약 0.5g 의 다이어트가 성공하여 이제는 Bumped specular 정도 되는 무게의 쉐이더가 되었습니다!!

하지만 먼저 작업이 필요합니다!! 물 외각 모양으로 폴리곤을 따 내는 귀찮은 작업이 존재하게 되었죠!!! 그리고 원하는 구역에 버텍스 알파를 0으로 떨어뜨리면 됩니다!!!

폴리곤을 좁게 만들면 칼같이 끊어지는 면이 나오고 넓게 만들면 부드러운 그라디에이션이 나오겠지요!!!

그대로 넣으면 투명도가 반영됩니다!!! 나머지는 지금까지 쓰던것과 완전 동일합니다!!!

Fade Color로 색상을 조절할 수 있는 것도 동일합니다!!!
또한 투명도를 넣어보니 생각했던 것 보다 별로 마음에 들지 않아서 투명도를 조절하기 위해 다시 맥스로 왔다갔다 하는 불편함을 줄이기 위해 Edge Fade 값을 투명도 조절자로 만들었습니다!!! 기본값은 0, 완전 투명이고 오른쪽으로 올리면 불투명이 됩니다!!! 즉 맥스에서는 완전 투명으로 만들었다가 이 조절자로 은근히 불투명으로 바꾸시면 되겠습니다!!!!!!!

삼품 퍼포먼스 테스트 중간보고 이야기

Thu, 24 Feb 2011 18:37:45 +0000

결론이 나기에는 너무 이르기 때문에 ‘이야기’ 입니다.

일단, 가장 큰 부하 유발을 일으켰던 디퍼드 렌더러를 포워드 렌더러로 바꾸고 나서 테스트가 정상적으로 진행될 수 있는 상황이 되었습니다. 디퍼드 렌더러때는 무슨 짓을 해도 프레임이 안올라가더군요 (…)

사실 테스트가 끝나고 깔끔한 표로 만드는 것이 결정적 결과보고가 되겠지만, 그게 그렇게 쉽게 끝나는게 아니라서 말이죠 (…) 설치만 해도 대당 몇 시간이 걸리고, 가지고 있는 테스트 장비를 전수조사하면 한두달은 그것만 매달려야 한단 말입니다.
그렇다고 이사님이 보고 있는데 아무 보고도 없이 놀 수도 없고

그래서 중간보고 올립니다
현재 이것땜에 쉐이더 제작도 중지하고 있어요. 기준이 있어야 쉐이더도 한계를 정해서 제작할 수 있을 테니까.

제작된 맵을 전부 테스트 해 보는 것이 좋겠지만, 일단 기본적으로 어느 정도가 ‘권장사양’ 인지 알 수 없는 상태여서, 지금 있는 맵들 중 무거운 것을 대상으로 테스트를 해 보았습니다. 이것들을 바탕으로 대충의 사양을 결정해 보려고 말입니다.

결정된 것은 역시 가장 넓은 맵을 자랑하는 월드맵,
그리고 던전으로는 오브젝트가 가장 많은 계양.
그리고 “이상하게 엄청나게 느리다” 라고 하신 캐릭터 커스터마이징 맵 (선택창)

그리고 “대략의 초벌 테스트 결과” 를 뽑아내기 위해, 월드맵과 캐릭터 선택창을 테스트 해 보았습니다.
초벌 결과가 나온 다음에야 모든 사양별 Full Test 가 가능하니까요.

일단 PC는 테스트실 장비중 11번 컴퓨터,

3.2 G 듀얼에 메모리 2기가, 그래픽카드 지포스 7300LE.

목표는 권장사양 찾아내기.

CPU나 메모리는 권장사양으로는 아주 충분한 사양을 골랐습니다. 테스트가 너무 짜증나면 느려지니까.
대신 그래픽 카드는 7600GT를 원했는데 이미 대여가 된 상태라 (…)
Geforce 7300LE 를 선택했습니다. 이 그래픽 카드는 메모리 256M로,
7000대의 그래픽 카드이지만 LE(라이트 에디션) 즉 기능이 상당히 축약되어 6600GT 정도의 성능밖에 안나온다는, 7000대의 애물단지 같은 녀석입니다.

사양은 전체적으로 약간 높은 상태인거죠. 이 정도면 아틀란티카의 권장사양을 약간 상회하는 정도입니다. (그래픽 카드 빼고)

와우의 권장사양과 비슷하며, CPU는 살짝 높고 그래픽 카드는 살짝 낮은 상태입니다.
아이온의 권장사양보다는 조금 낮은 상태입니다. 사실, 메모리만 빼면 (2G) 아이온의 권장사양은 와우의 권장사양과 동일합니다.

그러므로 이 정도면 사실 권장사양이라고 말할 수 있는 법한 녀석이라고 말할 수 있습니다.
많은 게임회사에서 와우를 기준으로 삼는지라 (…)

옵션은 일단, ‘지금 있는 화면이 유저에게 보여지기를 권장한다’ 라는 전제로 시작하였습니다.
아, 물론 라이트는 곤란해유… 라이트는 권장사양에서도 수정되어야만 했어유…

그럼 심플한 결과테스트를 보시죠.

일단 캐릭터 선택창입니다. 라이트가 있는 상태죠. 위의 것이 빌드해서 익스플로어로 돌린 것이고, 아래가 툴 상의 결과물입니다.
위의 이미지가 밝은건 번개칠때 찍혀서 그런거니 신경쓰지 마세용.

프레임은 둘다 약 37프레임 내외. 나쁘지 않습니다.
드로우콜은 143 …. 폴리곤과 텍스쳐야 워낙 작은 상태라 사실 드로우콜이 가장 큰 부하유발자입니다.
근데 143 드로우콜에 37프레임은 사실 조금 낮아 보이긴 합니다. 살짝 프로파일러를 뒤져봤을땐 반투명 오브젝트가 많아서 그 부분이 가장 큰 부하를 먹더군요.

( 반투명 오브젝트는 들어가기만 하면 느려집니다. 이유를 알고 싶으시면 네이버에서 ’ 개악마 알파 블렌딩 ’ 을 검색 (…) )

무엇보다, 현재 보이는 것에 비해 드로우콜이 너무 높아 보입니다. 그래서 라이트를 날려봤습니다.
포워드 렌더러에서 라이트 하나 추가는 각오하고 해야 하는거라서요

거의 60프레임 나오는군요. 사실 더 나올 수 있을걸로 보입니다. Statistics를 보시면 103 프레임까지 올라갔거든요. 하지만 출력은 60프레임 제한이 걸려 있는 것으로 보입니다. 드로우콜도 65개 ! 엄청 떨어졌습니다.
라이트 4개만 삭제했는데 엄청난 속도가 나왔지요. 역시. 속도를 올리기 위해서는 라이트 설계를 다시 하면 될 것 같습니다.

이번엔 월드맵 테스트입니다. 라이트는 다이렉트 라이트 2개와 fake 라이트 1개가 있는데, 뭐 사실 감안할 만한 정도의 라이트 개수이긴 합니다. 그냥 해 보니… 경우에 따라 다르지만 약 30~40 프레임 정도가 나옵니다.
드로우콜은 약 200 내외. 나무가 웹으로 컨버팅하면 라이팅이 달라지는데 나중에 이유를 찾아봐야겠군요.

일단 급박하게 결론정리.

지금으로의 테스트만 보면 와우와 권장사양이 비슷한 것으로 보입니다.
현재의 데이터를 살짝 분석해 보면… 가장 큰 영향을 끼치는 것은 역시 라이트. 라이트쪽 최적화를 해 주면 프레임이 올라갈 겁니다. 그 다음은 반투명이라고 나오는군요. 그 외의 것들은 다소 미미합니다.

권장 시스템의 하드웨어 능력에서 가장 큰 로딩은 역시 드로우콜입니다. 이건 불변의 진리. 현재의 병목은 드로우콜이예요. 그담이 반투명.
그 외의 텍스쳐나 폴리곤은 굉장히 작습니다. 텍스쳐만 봐도 16.5 메가를 사용하고 있으니까요. 256MB의 메모리를 가진 그래픽 카드한테는 너무 껌이죠.

그 외의 보이지 않은 위험요소는 또 있습니다.
바로 UI와 캐릭터!

UI는 MMORPG에서의 가장 무서운 퍼포먼스의 적입니다. 열리는 창이 많고, 반응하는 버튼이 많고, 글씨는 왜 이리 많은가요…
그냥 편하게 생각하시면 하나하나 전부 DPcall(드로우콜)이라고 생각하시면 됩니다. 잘못하면 Dpcall의 절반을 UI혼자 잡아먹어 버리는 결과까지 볼 수도 있습니다. ㄷㄷㄷㄷ 지속적으로 관리해야죠.

또하나는 캐릭터! 그중 스키닝! (본 업데이트)
캐릭터가 많아지면 일단 드로우콜이 늘어나죠 (캐릭터 한 마리당 커스터마이징 땜에 3개의 덩어리로 나눠져 있고 무기 따로 있고 말 타고 있다면 캐릭터 한마리에 기본적으로 드로우콜이 5개입니다 . 그게 20마리면 드로우콜이 100 … 헉….)
거기다가 본이 업데이트 될 때의 부하도 아주 큽니다. 유니티는 하드웨어 스키닝 (그래픽카드가 해줘요) 가 아닌 소프트웨어 스키닝 (CPU가 해줘요) 이기 때문에, 노는 그래픽 카드의 파워를 쓸 수가 없습니다. 고스란히 CPU부하를 유발하지요.
캐릭터의 본 개수가 많을수록 이 업데이트는 비약적으로 증가하게 되고, 당당히 3위 안에 드는 부하유발자가 되곤 합니다.

그 다음은 이펙트 … 정도?

위의 부하를 테스트 해 보고 있지만, 어디까지나 임시적 테스트이고, 덕분에 감각적으로 결정해야 하는 일이 대부분입니다. 이게 어려운 점이죠.

뭐, 지금까지 테스트한 내용을 대충 풀어보면 위와 같습니다.

단 지금 테스트는 한두대의 컴퓨터에서, XP 상태로 돌린 것이기 때문에 완전히 신용하기에는 아직 이릅니다.
OS별, 하드웨어 특성별 테스트로 한 5-6 대쯤 돌려봐야 대충 각이 나오곤 하죠. 그건 시간이 꽤 걸리는게 문제입니다. (더 무서운건 테스트 중간에 패치나가서 완전히 바뀌어 버리는 것…) 게다가 아이패드쪽은 언제 해 … OTL

담주는 안되겠고, 다다음주 중에 또 한 번의 조금 더 섬세한 초벌테스트를 해 보면 대충 윤곽이 잡힐 것이라고 보입니다. 더 빨리 해드리고 싶지만 체력이 한계가 오네요 ㅎㅎ

[Shader] TKBG_IceWater Shder commited

Tue, 22 Feb 2011 14:13:51 +0000

수진씨 요청. 배경용 얼음물 쉐이더입니다. 얼음 쉐이더들은 굳이 무게로 따지자면 7-8g 은 될듯한 무거운 쉐이더들입니다.
일단 요청에 맞도록 만들어 놓고, 현재 진행중인 퍼포먼스 테스트 결과가 나오는 대로 거기에 맞춰 재조정될 예정입니다.

asset server 적용은 완료 되어 있는 상태입니다.

얼음 오브젝트와는 다르게, 평면에 주로 사용될 것이기 때문에 평면에 맞추어 필요없는 기능을 삭제하고, 필요한 기능을 추가하였습니다.

얼음 오브젝트용 쉐이더인 ice 쉐이더보다 무조건 아래에 찍힙니다. 즉 이 얼음판 아래에 얼음 오브젝트 쉐이더를 사용한 오브젝트를 넣지 마세요.
Ambient 칼라는 삭제했습니다. 평면용에는 필요 없어서요.
굴절도 삭제되어 있습니다. pass를 아껴서 가볍게 만들려고요.
물처럼 ‘지면 또는 오브젝트와의 충돌’ 인식 코드가 들어 있습니다. 외각의 투명도를 결정합니다.
아이폰에는 테스트도 안해봤습니다 잇힝. 안될게 너무 뻔해서.

자세한 사용방법입니다.

기본적으로 이렇게 생긴 쉐이더입니다. 얼음물 표현에 특화되어 있습니다.

Base Texture overlay 는 베이스맵을 보이게 할 것인지 안보이게 할 것인지를 정합니다. 아예 안보이는게 좋다면야 그렇게 하셔도 좋겠지만, 아예 안보이도록 늘 사용하실거라면 아예 베이스 텍스쳐를 빼달라고 주문해 주시는게 좋습니다. 텍스쳐는 한 장이라도 아끼는게 좋으니까요.

최고로 올리면 이렇게 나오구요. Tint Color 도 물론 동일하게 영향을 받습니다.

리플렉션 텍스쳐도 준비되어 있습니다. 프레넬 공식같은건 없습니다. 활성화 시키면 그냥 반사가 전부 이뤄집니다.
강도를 조절할 수 있는 옵션도 준비되어 있습니당

여기 가장 중요한 옵션입니다. 외각을 자동으로 인식해서, 투명하게 해 줍니다. 투명하게 해줄 뿐더러 아래 이미지와 섞여서 좀 ‘어둡게’ 나오도록 되어 있습니다.

이 옵션은 왼쪽으로 옮기면 투명한 영역이 넓어집니다. 굴절 같은건 이루어지지 않지만, 그다지 신경스이지 않습니다.

이번엔 그 아래 있는 Edge Line 옵션입니다. 이 옵션은 외각에 다시 한 번 라인이 나타나게 해 줍니다. 여기에 나타나는 라인은 Base Texture 입니다.

힌트는 수진씨가 주신 아래 이미지에서 얻었습니다. 외각으로 가서 얇아지면 분명 투명하지만 빛이 들어가지 않아서 어두워 집니다. 그렇지만 완전 외각으로 가면 확실하게 흰 경계선이 다시 생기게 됩니다. 이 이미지를 흉내낸 것입니다.

이 외각 인식 기능 때문에 좀 무거운 쉐이더가 되어 버렸습니다만, 퍼포먼스 테스트 후 수정하기로 했습니다. 괜찮으면냅두고…

이전에 만든 얼음덩이 쉐이더와도 싸우지 않고 잘 지내는 것을 알 수 있습니다.

얼음물 셰이더

Mon, 21 Feb 2011 11:57:23 +0000

삼품용 얼음 쉐이더,

기존의 물 쉐이더는 쓸데 없는 코드들로 인해, 원하는 느낌은 잘 안나면서도 무척 무거운 결과가 나오곤 했었습니다.
특히 쉐이더 3.0을 기반으로 제작되어 있던 관계로, 쉐이더 2.0 에서는 결과물이 안 나오거나 이상하게 나오곤 했었지요.

그 쉐이더를 개량해서 (다시 제작할건 다시 하고) 제작한 얼음 전용 쉐이더입니다.
물에는 필요하지만 얼음에는 필요 없는 코드들을 대폭 삭제하고, 쉐이더 2.0에서도 가동하게끔 경량화 시켰습니다.

그렇다고 해도 기본적으로 2pass 를 사용하는데다가, 알파 블렌딩을 사용하므로 디퍼드 렌더러도 가동되지 않는, 꽤나 중량감이 넘치는 쉐이더입니다. (많이…) 하지만 뭐 어차피 우린 포워드 렌더러잖아..
기존의 쉐이더 사용 현황을 봤을때 가급적 사용을 자제시키고 싶은 쉐이더이긴 합니다만, 자세한건 제작된 것을 테스트 하고 나서나 말씀드릴 수 있을 것 같습니다.

우선 기본은 이렇게 생겼습니다.

Base 텍스쳐는, 말그대로 ‘겹쳐’ 집니다. 멀티플라이 방식이랄까요. 저 옵션을 최하로 내리면, Base 텍스쳐는 아무런 영향을 끼치지 않습니다. base맵이 필요 없다면, 저 부분을 비워 놓으시켜나 아주 작은 검은색 (또는 흰색) 텍스쳐를 넣어 두시면 됩니다.
단 저 옵션을 최고로 두시면, (현재 그림처럼) 텍스쳐 이미지가 강하게 나오게 됩니다.

다음은 Ambient 의 설명입니다. 이 쉐이더는 기존의 라이트의 영향을 받지 않습니다… 사실 거의 ‘이펙트’ 라고 불려도 좋을 쉐이더입니다. 실제로도 이펙트 디자이너분들이 사용하셔도 상관 없는 쉐이더이기도 합니다.

어쨌건 Ambient는 색으로 지정되지 않습니다. 슬라이드바를 최하로 내려 놓으면 빛이 닿지 않는 곳은 검게 나오지만,

최고로 올려 놓으면 빛의 방향을 알아볼 수 없을 정도로 자기발광 (Self - illumination) 하게 됩니다. Specular가 없다면 빛의 방향을 알아챌 수도 없지요.

이번엔 Refractivity (굴절) 입니다. 수치를 최하로 내리면 관우아자씨가 그냥 잘 보입니다만… (이 느낌은 수정구를 통해 보는 뭔가의 장면 같은 느낌이군요)

굴절 수치를 올리면 관우아자씨가 찌그러집니다. 물론 배경도 다 찌그러집니다.
이 찌그러지는 건 노말맵의 영향을 받습니다.

외각의 파란 라인은 굴절이 아닌 반사로, 이건 언제나 노말의 영향을 받아 찌그러져 있다는 것을 주의하십시오.
지금의 옵션은 오직 굴절에만 영향을 주는 옵션입니다.

Shiness 는 Specular의 쨍함을 조절합니다.

이렇게요.

물론 Specualr의 색도 조절할 수 있습니다.

이번엔 Reflection (반사) 얘기입니다 잘 들으세요.
이건 먼저 Reflect Power 얘기부터 해야겠군요.
이건 반사의 “두께” 라고 생각하시면 편합니다.
이 옵션을 최하로 해 놓으면, 반사가 두꺼워져서 오브젝트가 반사만 가득차게 됩니다.

반대로 이 수치를 올리면, ‘반사’ 의 두께가 얇아지게 됩니다. 어디로? 외각으로 얇아지게 됩니다.

좋습니다. 얇아지고 두꺼워지는건 이해가 됩니다만, 반드시 외각으로 얇아져야 할까요?

이걸 반대로 만드는 것이 Reflect Inverse 입니다.
기본적으로 이 수치가 왼쪽 (0) 에 붙어 있으면 있을수록 외각쪽으로 두께가 조정되지만,

이 수치를 오른쪽으로 옮기면 반사가 “외각으로 얇아지는” 게 아니라 “내부로 얇아” 집니다. 즉 반사와 굴절의 위치를 뒤바꿔 버립니다. 물론 Reflect Power와 같이 사용해야 그 효과를 볼 수 있겠지요.

마지막으로 WorldLightDirection 수치는, 라이트의 방향을 나타내는 벡터입니다.
아까 말씀드렸다시피 이 쉐이더는 월드에 있는 조명의 영향을 받지 않고 독립적으로 라이트 방향을 가지고 있는 (내부적으로 가지고 있을 뿐, 빛을 추가로 생성할 필요는 없습니다 ) 쉐이더이므로 빛 방향을 벡터수치로 바꿀 수 있습니다

기본은 0,1,0 으로, 머리 위에서 아래로 똑바로 떨어지는 빛입니다.
이 벡터 수치들을 조정해서 원하는 위치에 라이트가 떨어지게 독자적으로 움직일 수 있습니다만, 벡텨 원리를 감각적으로 알고 계시는 분 아니면 그다지 추천하지 않습니다.

되도록 기본값으로 놔 주세요.

아이폰에서 테스트는….

일단 돌아는 가더군요… 오우 대단해…

… 하지만……

0.43 FPS

아하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하하

뭐야 저 감격스러운 퍼포먼스는

아이폰에서는 확실히 PC보다 쉐이더에 민감합니다.
아이폰용은 완전히 따로 만들어야겠군요.

[Shader] Flow Shader 시리즈

Fri, 18 Feb 2011 12:22:44 +0000

많은 이펙트 고객분들에게 대 인기인 범용쉐이더 Flow 쉐이더가 삼품 버전으로 나왔습니다!!!

Flow 쉐이더는 원래 흘러가는 불 이미지를 만들기 위해 제작된 쉐이더로, UV 스크롤 제어 속도 조절자가 붙어 있어서 Flow라는 이름이 붙었었습니다만, 유니티에서는 UV 제어를 따로 할 수 있는 관계로 그 기능은 삭제되었습니다.

즉 Flow라고 부르는 것 보단 사실 2Texture Blending 에 가까운 쉐이더가 되어 버렸습니다만… (으음…)
이미 익숙해지신 Flow 쉐이더의 이름을 그대로 가지고 가기로 하였습니다.

아시다시피 plan 한 장 (2polygon) 으로 만들어질 수 있는 이펙트라서, 매우 싸며 사용할 곳이 많습니다.

텍스쳐 두 장은 UV를 따로 가져갈 수있습니다 (!!!!)

Asset Server 업데이트 완료되었습니다.

사실 그전에 쓰던 이펙트 연산을 다 뜯어 고치느라고 좀 늦었습니다. 덕분에 이번엔 매우 낭비없는 쉐이더로 탈바꿈을…

텍스쳐 두 장을 블렌딩만 하면 2g 정도 느낌의 쉐이더입니다만, UV를 두 개 가져가는 덕분에 좀 더 무거워져서 2.5g 정도의 느낌입니다.

뭐 아시다시피 빌보드 스크립트를 연결해서 사용하셔야 합니다. 플랜은 종잇장입니다. 소프트 파티클 같은 기능은 사치입니다 고갱님.

Standard 버전도 물론 만들어져 있습니다 고갱님.
Standard 버전은 다른 버전과 다르게 알파가 Tint Color로 조절 안되기 때문에, 알파를 따로 만들어 놓았습니다.
버텍스 알파를 에니메이션해서 사용하면 되지 않느냐! 라고 꾸짖으실 분도 계시겠지만 고갱님의 불편을 최소화 시켜드리려는 노력으로 인정해 주시기 바랍니다.

Multi 는 이전에 사용했듯, 블렌딩을 인버트 시켜 버립니다.
이펙트 디자이너분들에게 최적화된 서비스!

말씀드렸듯, 버텍스 알파도 충실히 동작합니다.
버텍스 칼라는 아무 행동도 하지 않으므로 숙지부탁드립니다.

아이폰에서의 사용은 기본입니다 고갱님.

고갱 여러분들의 만족을 위해, 쉐이더 만들때마다 넘겨서 테스트하고 있습니다.

이전에 쓰던 파티클 불은 정말 이쁘지만, 화면에 클로즈업 되었을때 급격한 프레임 저하를 유발하는 단점이 있었습니다.

하지만 이 쉐이더를 이용하면, 어떻게 하든 거의 부하를 주지 않습니다. 아이폰에서는 알파 블렌딩이 더 빠르기 때문에, PC에서보다도 매우 유리합니다.

불이 안이쁜건 그냥 제가 못그려서입니다. 잇힝.

TKMobile_Char_Diffuse_dye (작성중)

Thu, 17 Feb 2011 12:07:44 +0000

“모바일용 염색 쉐이더” 라고 생각하시면 편합니다.

Asset server에 업로드 되어 있습니다.

모바일을 위한 캐릭터 쉐이더입니다. 단, 일반 캐릭터는 Diffuse 쉐이더를 사용해 주십시오. 염색이 필요한 캐릭터에만 사용해 주세요.

그 이유는 반사를 쓰려면 역시 폴리곤이 좀 되거나 노말맵이라도 들어간 상태에서 봐야 반사벡터가 정확하게 계산되어 나와서 제대로 나오는데, 지금처럼 폴리곤이 적으면 노말 값의 샘플링이 빈약하여 반사벡터의 정확도가 많이 떨어지게 되어서, 큐브맵 반사의 장점이 거의 묻히게 됩니다.

때문에 제작하기도 쉽고 살짝 가벼운 일반 텍스쳐를 샘플링하는 방식으로 제작되었습니다. (큐브맵보다 제작하기쉽고, 동일한 해상도라면 1/6 사이즈인데다가, 샘플링도 조금 가볍죠)

또한 이 쉐이더에서는 염색이 제거되었습니다. 림라이트는 있지만요. 이유는 현재 리플렉션 때문에 2장의 텍스쳐를 사용하고 있는 상태인데,염색 마스킹 채널에 리플렉션 마스킹 채널까지 넣는다면 채널이 부족해서 결국 텍스쳐를 한 장 더 사용하게 될 수 밖에 없기 때문입니다.

-그러므로 이 반사 텍스쳐에는 염색이 지원되지 않으며, 염색 마스킹이 리플렉션 마스킹으로 사용됩니다.

-이 쉐이더의 부하는 약 3g 급이며, 게임에서는 되도록이면 연출영상등의 근접장면에서 사용하시길 추천합니다.

리플렉션 칼라로 반사되는 이미지의 색상과 밝기 (리플렉션 되는 정도) 를 조절할 수 있습니다.
리플렉션 텍스쳐는 일반 텍스쳐를 사용해 주세요. 지금은 대충 넣었지만, 멋진 배경 이미지 등을 넣으면 좋을 것입니다.

대마왕이었습니다.

캬오

[Shader]TK_Char_Diffuse_rim_Reflect Shader

Thu, 17 Feb 2011 10:52:20 +0000

Reflection 이 가미된 캐릭터 전용 쉐이더입니다.
요청해 주신대로 제작되었습니다.

Asset server에 업로드 되어 있습니다.

리플렉션 텍스쳐를 이용해 반짝반짝반짝 하는 쉐이더입니다. 반짝반짝반짝.
정지상태일때는 느낌이 잘 안오시겠지만, 돌리거나 움직일때 이쁩니다. 반짝반짝반짝반짝.

리플렉션은 원래 큐브맵을 사용하는게 정석이긴 하겠지만, 여기서는 일반 텍스쳐로 제작되었습니다.

-그러므로 이 반사 텍스쳐에는 염색이 지원되지 않으며, 염색 마스킹이 리플렉션 마스킹으로 사용됩니다.

-이 쉐이더의 부하는 약 3g 급이며, 게임에서는 되도록이면 연출영상등의 근접장면에서 사용하시길 추천합니다.

1. 리플렉션 칼라로 반사되는 이미지의 색상과 밝기 (리플렉션 되는 정도) 를 조절할 수 있습니다.
2. 리플렉션 텍스쳐는 일반 텍스쳐를 사용해 주세요. 지금은 대충 넣었지만, 멋진 배경 이미지 등을 넣으면 좋을 것입니다.

대마왕이었습니다.
캬오

[Shader] TKchar_Diffuse_rim_dye 쉐이더 커밋되었습니다.

Wed, 16 Feb 2011 18:16:23 +0000

인트라넷에 사진 올리다가 무한루프에 빠져서 글 3번째 날리고 다시 씁니다.
MBC에서 전원을 내렸을때의 PC방에 있던 기분이군요…
인트라넷 사진 올리다가 버튼 하나 잘못 누르면 글 다 날라가는건 정말 고쳐야 한다고 생각합니다.
때문에 전 블로그에 먼저 올리고 그걸 긁어서 인트라에 올리지요… (이번엔 안했다가 피본..)

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

Asset Server에 커밋되었습니다.
강효식 팀장님께 전달 완료
쉐이더 위치는 TK_Project\Assets\00 Common Assets\Shaders 으로 하기로 박차장님 통해서 결정되었습니다.

이전 게시물인 Diffuse fast 쉐이더, Diffuse 보다 정말 빠른가? 에서 나온 연구결과를 바탕으로 제작된 쉐이더입니다.
http://intra.ndoors.com/center/board/view.asp?list_seq=209220&board_seq=313&readchk_flag=N
픽셀 라이트가 저렇게 빠르다면, 굳이 다루기도 힘들고 효과내기도 힘든 버텍스 라이트를 이용할 이유가 없지요.

그래서 제작된 캐릭터용 쉐이더입니다.

특징 / 사용법은 다음과 같습니당.

텍스쳐는 한 장만 사용합니다.

이전 Illumination 을 위해 제작했던 텍스쳐는 관리나 제작이 그래픽 디자이너들에게 까다로웠던게 사실입니다.
게다가 아까운 셈플러를 잡아먹고 있기도 하고 말이죠.
그래서 그 기능을 Illumintion 슬라이드바로 만들어 적용했습니다.
적용 원리는 좀 다르지만 효과는 거의 동일합니다.

비교해 보면 다음과 같습니다.

이전 사용하던 쉐이더입니다.

새로 제작된 쉐이더입니다. 텍스쳐가 한 장이고 여러 조절자가 생겼습니다.
이미지 차이는 거의 없습니다.

Illumination 조절자를 조절하면 음영을 조절할 수 있습니다. 최대 밝게 하면 위와 같습니다. 기본은 0.8로 일단 해 놓았습니다.

Rim light가 생겼습니다.

림라이트는 외각에 역광 라이트를 추가해 주는 듯한 효과로, 만들기 간편하면서 쉐이더 개발자에게는 뭔가 했다는 뿌듯함을 느끼게 해주는 좋은 기능입니다.

애석하게도 현재 데이터의 폴리곤이 적어서, Vertex Normal을 사용하는 림 라이트의 정밀도가 떨어집니다. 노말맵이라도 썼다면 정밀도가 올라가겠지만..
그래도 보면 나쁘지 않습니다.

약간 과장해 보았습니다. Rim Color와 Power를 이용해 넓이와 색상을 조절할 수 있습니다.

캐릭터 선택 (혹은 마우스 오버) 등에도, 색상과 Power를 조절해서 표현할 수 있습니다. (이건 프로그래밍에서 런타임으로 제어해 주시면 됩니다 )

사실은 림 라이트를 일반 / 마우스 오버 상태 2개로 중첩되도록 제작했었는데, 정밀도가 떨어지다보니 둘을 동시에 나타나게 해도 하나는 묻혀서 의미가 없었습니다. 그래서 굳이 2개로 만들기 보다는 1개로 만들어서 옵션만 교체해서 계산량을 줄이도록 제작했습니다. 요건 프로그램팀에 작업 부탁해야 합니당.

염색 기능 있습니다.

그전에 데칼이라고 불리던 기능입니다. 데칼보다는 염색이 맞겠지용 :) Main texture의 알파를 마스킹 채널로 이용합니다.
즉 알파 채널 없이 그냥 텍스쳐를 제작하시면 염색은 적용되지 않습니다.
기본값은 염색 칼라는 회색입니다. 회색으로 하면 염색이 보이지 않습니다.
그렇지만 Base 텍스쳐에 알파 채널이 없으면, 염색 칼라를 무슨 칼라로 하더라도 염색은 적용되지 않습니다.

염색은 다음과 같이 제작하면 됩니다. 그라디에이션 먹습니다. 50% 만 적용도 된다는 말씀.

이런 알파 채널을 가진 이미지가 된다는 거겠죠. 염색이 필요 없으면 알파 채널 자체를 안만들어도 됩니다.
(그렇게 하기 위해서 염색이 필요한 부분만 검은 색으로 칠하도록 되어 있습니다. 일반적인 경우와 반대지만요)

이제 어두운 색을 설정하면 어둡게 들어갑니다.

밝은 색으로 화사하고 엘레강스한 갑옷을 만들 수도 있습니다 고갱님.
물론 팀칼라로 사용하셔도 됩니다.
필요 없으면 알파 채널만 안만들면 되므로 채널 절약도 할 수 있습니다 고갱님.

무슨 색이건 회색만 아니면 나옵니다. 단 회색일때(128,128,128)는 안나옵니다.

이 기능들은 아이폰에서도 동일하게 동작합니다.
림라이트가 작동되고 있는걸 보실 수 있으십니다. 또한, 녹색으로 염색한 것도 작동하고 있습니다.
프레임이 좀 떨어졌지만, DPcall이 권장된 제한사양인 30개를 2배 이상 넘어가고 있는 상태라는 걸 감안해 주시기 바랍니다.

부하가 없다고는 할 수 없습니다만, 치명적인 부하를 유발하지는 않는 것으로 보입니다. 이 정도면 쓸 수 있달까.
하지만 일단 가볍게 하기 위해 아이폰 버전 (Mobile_TKchar_Diffuse_dye가 되겠죠) 에서는 림라이트 기능을 일단 제거해서 만들겠습니다. 필요시 언제나 추가 가능합니다.

Unity 내장 shader는 계속 변하는 중

Wed, 16 Feb 2011 09:31:21 +0000

Built-in shaders라고 해서, Unity 홈페이지 가면 내장된 쉐이더들의 코드를 받아볼 수 있지요.
이걸 이용하면 평소에는 막혀져 있어서 볼 수 없는 내장 쉐이더들의 코드를 볼 수 있는데,
그 동안 계속 보다 보니까… 이게 계속 변하더라고요. 다운로드 받을때마다 변해있다능.
아무래도 한참 발전하는 엔진이다보니 그럴 수 있겠죠.

근데 최근의 추세를 보니 내장된 스크립트를 이용한 쉐이더들이, 전부 CG를 이용한 surface 쉐이더로 바뀌는 중.

예를 들어 Diffuse만 봐도 이렇습니다.

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

// Upgrade NOTE: replaced ‘PositionFog()’ with multiply of UNITY_MATRIX_MVP by position
// Upgrade NOTE: replaced ‘V2F_POS_FOG’ with ‘float4 pos : SV_POSITION’

Shader “Diffuse” {
Properties {
_Color (“Main Color”, Color) = (1,1,1,1)
_MainTex (“Base (RGB)”, 2D) = “white” {}
}

Category {
Tags { “RenderType”=“Opaque” }
LOD 200
/* Upgrade NOTE: commented out, possibly part of old style per-pixel lighting: Blend AppSrcAdd AppDstAdd */
Fog { Color [_AddFog] }

// ——————————————————————
// ARB fragment program

#warning Upgrade NOTE: SubShader commented out; uses Unity 2.x per-pixel lighting. You should rewrite shader into a Surface Shader.
/*SubShader {
  // Ambient pass
  Pass {
   Name “BASE”
   Tags {“LightMode” = “Always” /* Upgrade NOTE: changed from PixelOrNone to Always */}
   Color [_PPLAmbient]
   SetTexture [_MainTex] {constantColor [_Color] Combine texture * primary DOUBLE, texture * constant}
  }
  // Vertex lights
  Pass {
   Name “BASE”
   Tags {“LightMode” = “Vertex”}
   Lighting On
   Material {
    Diffuse [_Color]
    Emission [_PPLAmbient]
   }
   SetTexture [_MainTex] { constantColor [_Color] Combine texture * primary DOUBLE, texture * constant}
  }
  // Pixel lights
  Pass {
   Name “PPL”
   Tags { “LightMode” = “Pixel” }
CGPROGRAM
// Upgrade NOTE: excluded shader from Xbox360; has structs without semantics (struct v2f members uv,normal,lightDir)
#pragma exclude_renderers xbox360
#pragma vertex vert
#pragma fragment frag
#pragma multi_compile_builtin
#pragma fragmentoption ARB_fog_exp2
#pragma fragmentoption ARB_precision_hint_fastest
#include “UnityCG.cginc”
#include “AutoLight.cginc”

struct v2f {
float4 pos : SV_POSITION;
LIGHTING_COORDS
float2 uv;
float3 normal;
float3 lightDir;
};

uniform float4 _MainTex_ST;

v2f vert (appdata_base v)
{
v2f o;
o.pos = mul (UNITY_MATRIX_MVP, v.vertex);
o.normal = v.normal;
o.uv = TRANSFORM_TEX(v.texcoord, _MainTex);
o.lightDir = ObjSpaceLightDir( v.vertex );
TRANSFER_VERTEX_TO_FRAGMENT(o);
return o;
}

uniform sampler2D _MainTex;

float4 frag (v2f i) : COLOR
{
// The eternal tradeoff: do we normalize the normal?
//float3 normal = normalize(i.normal);
float3 normal = i.normal;

half4 texcol = tex2D( _MainTex, i.uv );

return DiffuseLight( i.lightDir, normal, texcol, LIGHT_ATTENUATION(i) );
}
ENDCG
  }
}*/

  // ——————————————————————
// Radeon 9000

#warning Upgrade NOTE: SubShader commented out because of manual shader assembly
/*SubShader {
  // Ambient pass
  Pass {
   Name “BASE”
   Tags {“LightMode” = “Always” /* Upgrade NOTE: changed from PixelOrNone to Always */}
   Color [_PPLAmbient]
   SetTexture [_MainTex] {constantColor [_Color] Combine texture * primary DOUBLE, texture * constant}
  }
  // Vertex lights
  Pass {
   Name “BASE”
   Tags {“LightMode” = “Vertex”}
   Lighting On
   Material {
    Diffuse [_Color]
    Emission [_PPLAmbient]
   }
   SetTexture [_MainTex] { constantColor [_Color] Combine texture * primary DOUBLE, texture * constant}
  }

  // Pixel lights with 0 light textures
  Pass {
   Name “PPL”
   Tags {
    “LightMode” = “Pixel”
    “LightTexCount” = “0”
   }

CGPROGRAM
// Upgrade NOTE: excluded shader from OpenGL ES 2.0 because it does not contain a surface program or both vertex and fragment programs.
#pragma exclude_renderers gles
#pragma vertex vert
#include “UnityCG.cginc”

struct v2f {
float4 pos : SV_POSITION;
float2 uv : TEXCOORD0;
float3 normal : TEXCOORD1;
float3 lightDir : TEXCOORD2;
};

uniform float4 _MainTex_ST;

v2f vert(appdata_base v)
{
v2f o;
o.pos = mul (UNITY_MATRIX_MVP, v.vertex);
o.normal = v.normal;
o.uv = TRANSFORM_TEX(v.texcoord, _MainTex);
o.lightDir = ObjSpaceLightDir( v.vertex );
return o;
}
ENDCG
   Program "" {
    SubProgram {
     Local 0, [_ModelLightColor0]
     Local 1, (0,0,0,0)

“!!ATIfs1.0
StartConstants;
CONSTANT c0 = program.local[0];
CONSTANT c1 = program.local[1];
EndConstants;

StartOutputPass;
SampleMap r0, t0.str;   # main texture
SampleMap r1, t2.str;   # normalized light dir
PassTexCoord r2, t1.str;  # normal

DOT3 r5.sat, r2, r1.2x.bias; # R5 = diffuse (N.L)

MUL r0, r0, r5;
MUL r0.rgb.2x, r0, c0;
MOV r0.a, c1;
EndPass;
"
    }
   }
   SetTexture[_MainTex] {combine texture}
   SetTexture[_CubeNormalize] {combine texture}
  }

  // Pixel lights with 1 light texture
  Pass {
   Name “PPL”
   Tags {
    “LightMode” = “Pixel”
    “LightTexCount” = “1”
   }

uniform float4 _MainTex_ST;
uniform float4x4 _SpotlightProjectionMatrix0;

struct v2f {
float4 pos : SV_POSITION;
float2 uv : TEXCOORD0;
float3 normal : TEXCOORD1;
float3 lightDir : TEXCOORD2;
float4 LightCoord0 : TEXCOORD3;
};

v2f vert(appdata_tan v)
{
v2f o;
o.pos = mul (UNITY_MATRIX_MVP, v.vertex);
o.normal = v.normal;
o.uv = TRANSFORM_TEX(v.texcoord, _MainTex);
o.lightDir = ObjSpaceLightDir( v.vertex );

o.LightCoord0 = mul(_SpotlightProjectionMatrix0, v.vertex);

return o;
}
ENDCG
   Program "” {
    SubProgram {
     Local 0, [_ModelLightColor0]
     Local 1, (0,0,0,0)

“!!ATIfs1.0
StartConstants;
CONSTANT c0 = program.local[0];
CONSTANT c1 = program.local[1];
EndConstants;

StartOutputPass;
SampleMap r0, t0.str;   # main texture
SampleMap r1, t2.str;   # normalized light dir
PassTexCoord r4, t1.str;  # normal
SampleMap r2, t3.str;   # a = attenuation

DOT3 r5.sat, r4, r1.2x.bias; # R5 = diffuse (N.L)

MUL r0, r0, r5;
MUL r0.rgb.2x, r0, c0;
MUL r0.rgb, r0, r2.a;   # attenuate
MOV r0.a, c1;
EndPass;
"
    }
   }
   SetTexture[_MainTex] {combine texture}
   SetTexture[_CubeNormalize] {combine texture}
   SetTexture[_LightTexture0] {combine texture}
  }

  // Pixel lights with 2 light textures
  Pass {
   Name “PPL”
   Tags {
    “LightMode” = “Pixel”
    “LightTexCount” = “2”
   }
CGPROGRAM
// Upgrade NOTE: excluded shader from OpenGL ES 2.0 because it does not contain a surface program or both vertex and fragment programs.
#pragma exclude_renderers gles
#pragma vertex vert
#include “UnityCG.cginc”

uniform float4 _MainTex_ST;
uniform float4x4 _SpotlightProjectionMatrix0;
uniform float4x4 _SpotlightProjectionMatrixB0;

struct v2f {
float4 pos : SV_POSITION;
float2 uv : TEXCOORD0;
float3 normal : TEXCOORD1;
float3 lightDir : TEXCOORD2;
float4 LightCoord0 : TEXCOORD3;
float4 LightCoordB0 : TEXCOORD4;
};

v2f vert(appdata_tan v)
{
v2f o;
o.pos = mul (UNITY_MATRIX_MVP, v.vertex);
o.normal = v.normal;
o.uv = TRANSFORM_TEX(v.texcoord, _MainTex);
o.lightDir = ObjSpaceLightDir( v.vertex );

o.LightCoord0 = mul(_SpotlightProjectionMatrix0, v.vertex);
o.LightCoordB0 = mul(_SpotlightProjectionMatrixB0, v.vertex);

return o;
}
ENDCG
   Program "” {
    SubProgram {
     Local 0, [_ModelLightColor0]
     Local 1, (0,0,0,0)

“!!ATIfs1.0
StartConstants;
CONSTANT c0 = program.local[0];
CONSTANT c1 = program.local[1];
EndConstants;

StartOutputPass;
SampleMap r0, t0.str;   # main texture
SampleMap r1, t2.str;   # normalized light dir
PassTexCoord r4, t1.str;  # normal
SampleMap r2, t3.stq_dq;  # a = attenuation 1
SampleMap r3, t4.stq_dq;  # a = attenuation 2

DOT3 r5.sat, r4, r1.2x.bias; # R5 = diffuse (N.L)

MUL r0, r0, r5;
MUL r0.rgb.2x, r0, c0;
MUL r0.rgb, r0, r2.a;   # attenuate
MUL r0.rgb, r0, r3.a;
MOV r0.a, c1;
EndPass;
"
    }
   }
   SetTexture[_MainTex] {combine texture}
   SetTexture[_CubeNormalize] {combine texture}
   SetTexture[_LightTexture0] {combine texture}
   SetTexture[_LightTextureB0] {combine texture}
  }
}*/

// ——————————————————————
// Radeon 7000

Category {
  Material {
   Diffuse [_Color]
   Emission [_PPLAmbient]
  }
  Lighting On
  #warning Upgrade NOTE: SubShader commented out; uses Unity 2.x style fixed function per-pixel lighting. Per-pixel lighting is not supported without shaders anymore.
/*SubShader {
   // Ambient pass
   Pass {
    Name “BASE”
    Tags {“LightMode” = “Always” /* Upgrade NOTE: changed from PixelOrNone to Always */}
    Color [_PPLAmbient]
    Lighting Off
    SetTexture [_MainTex] {Combine texture * primary DOUBLE, primary * texture}
   }
   // Vertex lights
   Pass {
    Name “BASE”
    Tags {“LightMode” = “Vertex”}
    Lighting On
    Material {
     Diffuse [_Color]
     Emission [_PPLAmbient]
    }
    SetTexture [_MainTex] {Combine texture * primary DOUBLE, primary * texture}
   }
   // Pixel lights with 2 light textures
   Pass {
    Name “PPL”
    Tags {
     “LightMode” = “Pixel”
     “LightTexCount” = “2”
    }
    ColorMask RGB
    SetTexture [_LightTexture0] { combine previous * texture alpha, previous }
    SetTexture [_LightTextureB0] { combine previous * texture alpha, previous }
    SetTexture [_MainTex] { combine previous * texture DOUBLE }
   }
   // Pixel lights with 1 light texture
   Pass {
    Name “PPL”
    Tags {
     “LightMode” = “Pixel”
     “LightTexCount” = “1”
    }
    ColorMask RGB
    SetTexture [_LightTexture0] { combine previous * texture alpha, previous }
    SetTexture [_MainTex] { combine previous * texture DOUBLE }
   }
   // Pixel lights with 0 light textures
   Pass {
    Name “PPL”
    Tags {
     “LightMode” = “Pixel”
     “LightTexCount” = “0”
    }
    ColorMask RGB
    SetTexture[_MainTex] { combine previous * texture DOUBLE }
   }
  }*/
}
}

Fallback “VertexLit”, 2

}

이게 옛날에 받은 Diffuse.

이게 요즘에는 Surface 쉐이더로 바뀌었더군요.

===============================================================================
Shader “Diffuse” {
Properties {
_Color (“Main Color”, Color) = (1,1,1,1)
_MainTex (“Base (RGB)”, 2D) = “white” {}
}
SubShader {
Tags { “RenderType”=“Opaque” }
LOD 200

CGPROGRAM
#pragma surface surf Lambert

sampler2D _MainTex;
float4 _Color;

struct Input {
float2 uv_MainTex;
};

void surf (Input IN, inout SurfaceOutput o) {
half4 c = tex2D(_MainTex, IN.uv_MainTex) * _Color;
o.Albedo = c.rgb;
o.Alpha = c.a;
}
ENDCG
}

Fallback “VertexLit”
}

그리고 이게 아이폰에서 더 빠르더군요.
여기서 생각할 수 있는 이전 게시물에 이은 망상 : Diffuse Fast 가 Diffuse 보다 빠르다는건 옛날 쉐이더 기준으로 써 놓은게 아니었을까. 서피스 쉐이더로 바뀌기 전에는 당근 더 무거웠을 듯. 그리고 지금은 오히려 서피스 쉐이더로 짜는게 최적화를 더 잘하게 되어 있어서 대부분의 쉐이더를 서피스 쉐이더로 바꾸는게 아닐까. 하긴 뭐 더 짜기도 쉽고.

Diffuse fast 쉐이더, Diffuse 보다 정말 빠른가?

Tue, 15 Feb 2011 16:43:16 +0000

첫 질문은 단순한 질문에서 시작하였습니다. 가장 권장할만 하고, 가장 추천해야 할 쉐이더는 무엇인가?
어떤 쉐이더를 사용해야 PC에서도, 아이폰에서도 만족할 만한 속도와 품질과 편리함을 가지고 있는 쉐이더인가?

물론 라이팅은 하나도 안 하고 텍스쳐만 딸랑 출력하는 Unlit 쉐이더가 가장 빠르겠지만, 라이트가 적용되는 최고 속도의 쉐이더는 알려진 바와 같이 정말 Diffuse Fast 인가? 라고 하는 것입니다. 즉 이 쉐이더가 결정되면, 모든 쉐이더를 어떤 방식으로 쉐이더를 작성해야 하는지에 대한 기초적인 기반이 정립되게 되는 것입니다. 덕분에 영향받는게 꽤 있지요.

물론 PC에서 이론적으로는 Diffuse Fast가 가장 빠른 것이 사실입니다. 라이팅 연산을 할 때 버텍스로 연산하는 것이, 픽셀별로 라이팅 하는 것보다 느릴리 없겠죠.

그리고 다른 얘긴데 사실,
Diffuse Fast 쉐이더를 열어보면

// Does not do anything in 3.x
Shader “Legacy Shaders/Diffuse Fast” {
Properties {
_Color (“Main Color”, Color) = (1,1,1,1)
_MainTex (“Base (RGB)”, 2D) = “white” {}
}
Fallback “VertexLit”
}

… 야

우스운게, 자체적 쉐이더가 있는게 아니라 vertexlit 쉐이더로 값만 대충 넘기는 방식을 사용하고 있습니다.
이거 완전 사기잖아. 뭐 그건 그렇다 치고..

그래서 무식하게 테스트부터 시작해 보았습니다. 텍스쳐 입힌 Sphere 64개 !!!
간단하게 생각해도 DP call만 64개를 사용하는 (아이폰에서 권장하는 DPcall은 30개 정도) 오브젝트입니다.
굉장히 무거운 상태죠.

이 데이터를 그대로 아이폰 3GS 로 빌드해서 프레임을 테스트 해 보았습니다.

Diffuse fast (Vertexlit) : 17 프레임

Diffuse : 29.75 프레임

….읭?

자, 잠깐. 지금 DP call 한계를 2배나 벗어났다고! 30프레임 가까이 나오면 어떡하자는거야!!!

하도 이상해서 simple verex light shader를 직접 제작해서 넣어 봤습니다.
버텍스 라이팅에서 이보다 빠른 쉐이더는 만들 수 없습니다.

http://www.unifycommunity.com/wiki/index.php?title=Simply_Lit

Shader “Simply Lit” {

Properties {
_Color (“Color”, Color) = (1,1,1)
_MainTex (“Texture”, 2D) = ""
}

SubShader {
Lighting On
Material {
Ambient [_Color]
Diffuse [_Color]
}

Pass {
SetTexture [_MainTex] {Combine texture * primary Double}
}
}

}

그래도 15프레임….

의읭????????????????

뭔가 헷갈립니다. 분명히 버텍스 라이팅이 라이팅 연산에서 빠르다는 것이 일반적 상식인데, 그 상식이 통용되지 않습니다.
어째서 픽셀 라이팅이 버텍스 라이팅보다 두 배나 빠른거야???????

간단하게 끝났어야 할 실험이 미궁으로 빠져듭니다. 이대로라면 캐릭터 쉐이더도 다르게 짜는 것이 좋고.. (사실 픽셀 라이팅 방식은 서피스 쉐이더 방식이라, 여러 가지 효과를 줄 때 편합니다… )
그래서 각종 가정을 해 보았습니다.

엔진이 미쳤다.
사실 아이폰은 픽셀쉐이더가 빠르다.
알파 테스팅이 더 느리다고 하는 아이폰이니 그럴 수도 있다.

그렇게 원인을 찾아 떠돌다가 찾은 문서.
http://developer.apple.com/library/ios/#documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/OpenGLESPlatforms/OpenGLESPlatforms.html

Another advantage of deferred rendering is that it allows the GPU to perform hidden surface removal before fragments are processed. Pixels that are not visible are discarded without sampling textures or performing fragment processing,
디퍼드 렌더러의 장기는 픽셀 처리 하기 전에 안보이는 면 날려버리는 건데유, 안보이는 픽셀은 과감히 내쳐서 텍스쳐 셈플링도 안하고 픽셀 쉐이더 처리도 안해유.

… 오호라.

아이폰에 들어가 있는 PowerVR SGX Platform 은 Tile-Based Deferred Rendering 라고 하는 ‘지연 렌더링 방식’을 사용하고 있는데요.

디퍼드 렌더러(지연 렌더러)란 라이트 연산을 위해 모든 오브젝트를 버퍼에 렌더링 해 놓고 몰아서 한 번에 라이팅 처리해 버리는 방식이라, 특성상 버텍스 라이팅을 강제로 사용하면 포워드 렌더링 처럼 돌아가니까… 덕분에 숨겨진 버텍스를 처리 못하는게 아닌가… 라는 가정이 생기게 되었습니다.

즉 그렇게 되면 저 예제들처럼 ‘가려진 면이 많은 경우’ 에서는 버텍스 라이팅이 픽셀라이팅보다 더 안좋은 퍼포먼스를 낼 수 밖에 없다는 것이지요.

물론 전 그래픽 디자이너 출신인데다가 아이폰에서 돌아가는 Tile-Based Deferred Rendering 에 대해서 더 깊이 파지 않은 상태에서 한 생각이기 때문에 어디까지나 ‘가정’ 이지만 말이죠. (예를 들어, ‘그럼 왜 여러 개 라이팅을 다이나믹으로 쓰는건 안되는거야? ’ 라고 질문하면 할말이 없지요 켈켈켈 )

어쨌건 그 원인을 찾는건 모바일 팀에서 찾을 일이고(윤과장님에게 패스), 저야 여기까지 조사해서 현실적 결론을 내리면 거기까지가 임무인지라 - 시간도 없는데 한도 끝도 없이 팔 수도 없고. 이미 반나절이 넘게 지났다고요. - 어쨌건 위의 가정대로라면 ‘가려진 면이 없으면 Diffuse Fast (Vertexlit) 이 조금이라도 더 빠르지 않느냐 라는 생각이 또 떠올라서 간략하게 테스트 해 보았습니다.

이미 이것때문에 시간을 많이 써버린 상태라 더 복잡하게는 못하고, 간락하게 조건을 살짝 바꿔서 테스트 해 본 결과,

공을 커다랗게 하나만 만들어 테스트 (버텍스 쉐이더 부담은 줄이고 픽셀쉐이더에게만 부담주기죠)

Diffuse Fast : 30.03 프레임

Diffuse : 29.46 프레임

뭐 일단 오차범위. 별 차이는 없군요. 가려진 면이 여전히 많아서 그런 걸까요?

한번 더 테스트

Diffuse Fast : 24.43

Diffuse : 26.95 프레임(오차범위)

여기서도 큰 차이를 발견할 수는 없었습니다. 약 10% 내외는 오차범위로 왔다갔다 하기 때문에 2-3 프레임씩의 차이는 확실한 차이라고 보기 힘듭니다. 여기서도 Diffuse 쉐이더는 전혀 느리지 않았습니다.

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

물론 여기에도 이슈는 있습니다. 윤과장님 테스트에 의하면 지형에 한해서는 Diffuse Fast가 약간 더 빠르게 나왔다는 테스트 보고도 있고, 3.2 에서는 Diffuse Fast가 사라지고 대신 Mobile 카테고리가 생기면서 거기 Vertexlit 쉐이더가 생겼습니다. (그래봤자 위에서 쓴 simple light랑 똑같을거라고 생각합니다만) 때문에 뭔가 조금 더 처리가 생기지 않았을까 하는 희박한 희망사항을 생각해 봅니다.

어쨌거나 결론적으로 정리하자면 다음과 같겠네요,

픽셀 라이팅 연산을 하는 Diffuse 쉐이더는 그렇게 무섭게 느린 쉐이더가 아닙니다.

캐릭터 처럼 겹치는 vertex가 많은 상태에서는 오히려 Diffuse Fast(Vertexlit) 보다 빠를 수도 있으며, 일반적인 경우에서도 대단한 차이가 나지 않습니다.

그러므로 모바일에서도 캐릭터에는 Diffuse 쉐이더를 써도 괜찮을 것 같습니다. (배경은 여전히 Diffuse Fast를 쓰세요. 사실 더 권장하는건 Unlit 쉐이더입니다만)

삼품 협의할내용

Mon, 14 Feb 2011 17:13:37 +0000

목표 사양 정하기.

아래 사양을 기준으로 플레이 해 본 후 세부결정.
브라우저별 테스트 해봐야 함.

현재의 데이터.

정확한 테스트는 아직 하는중
AT2와 거의 같은 정도의 무게로 보임. Shader 2.x 을 지원하는 의미가 없을지도 모른다.
Bone이나 Shader들이 무거움
최적화 작업은 어떤걸로? Umbra 사용중?

사양별 옵션 결정

디퍼드 렌더러는 사용 불가
실시간 그림자는 사용할 것인가? SS 옵션은 끈다. Lightmap은?
텍스쳐 해상도와 Anisotropic
후처리 효과 : Bloom / Sun Shafts / Color Correction / SSAO / DOF

기본적인 사양의 철학과 목표
가벼운 프로젝트인가?

기본 사양을 정하자.

넷북에서 돌아가기 위한 목표

넷북의 가장 위험한 점은 쉐이더 2.0 을 완벽히 지원 불가능하다는 것이다. 기존의 쉐이더를 모두 1.0 대응으로 돌아갈 수 있도록 만들어야 한다. 그 중에서 여러 장의 텍스쳐를 블렌딩하는 지형이 특히 문제이다.

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

아이폰에서도 사용해야 함. 아이폰의 퍼포먼스 기준을 최소 기준으로 잡아야 함.
버텍스는 한 화면에 1만개 정도
DP call은 30개 정도
라이팅을 주의하라. 포워드 렌더링에서 실시간 라이팅은 Drawcall을 증가시킨다.

사용 쉐이더 전파.

PC용과 아이폰용의 쉐이더는 다르게 간다.
아이폰에서는 알파 블렌딩 사용
아이폰에서는 Diffuse fast 보다 Diffuse가 더 빠르다.

큐슈 / 후쿠오카 - 운젠 여행기 7 (마지막)

Sat, 12 Feb 2011 19:27:54 +0000

산책중에 본 귀여운 버스. 특히 코가 귀여워요 코가!

다시 낮에 옛날 장난감 박물관에 들렀습니다.

추억속의 장난감이 많네요. 조잡함까지 그대로

오오오오 저 칼 ! 스프링으로 되어 있어서 찌르면 칼날이 들어가는 스프링 칼!

아… 사진이 흔들렸네요. 저게 뭐더라? 선더버드?

그렇게 산책하다가 ,
이틀 정도 커피를 못 마셨더니 금단증상이 생겨서 들어간 작은 카페 / 수제빵집 카세야.
겉 모습은 그냥 깔끔한 시골 찻집처럼 생겼지만, 들어가보니 제법 훌륭한 제빵장비까지 갖추고 있는 빵집이더군요.

아주머니 두 분이서만 계신 작은 찻집인데 직접 빵을 구워서 만드시나 봅니다. 게다가 가족탕도 대여? 음?
이 동네는 집마다 온천 목욕탕이 하나씩 있는 모양이네요. ㅋ

빵의 퀄리티는 역시나 훌륭했습니다. 가짓수가 많은 것은 아니지만
앉아서 커피마시는 동안에도 계속 손님이 와서 몇 봉지씩 빵을 사가더군요.

뭔가 발랐는지 반질반질한 소세지 빵이 맛있었었유.
오른쪽 위 빵은 안먹어 봤고, 왼쪽 빵은 감자를 으깨서 마요네즈 버무린 것 같은게 들어 있었는데 담백하고 아주 맛있었지요.

아참, 커피 얘기를 하지 않을 뻔 했네요. 커피야말로 정말 부드럽고 진했습니다. 보통 이정도 진하면 쓴맛이 느껴지기도 할텐데,
이렇게 진하면서도 부드러운 커피는 처음 마셔 봤달까요 :) 일본에서 먹은 빵과 커피는 정말 인상적이었습니다.

이건 핫 코코아. 별로 달지 않고, 오히려 약간 짠 듯한 맛이 느껴지는 코코아 있지요? 그 맛입니다.

잠시 몸을 녹인 후, 다시 동네 산책을 합니다. 동네 묘지가 여기에 있군요.
집 근처에 묘지가 있는 경우가 많은데, 일본 사람들은 창문 열면 묘지가 보이는 것에 대해 어떻게 생각하는지 궁금하군요.
(그러고 보니 10년전 영국 갔을때 호텔 창문을 여니 바로 묘지여서 깜짝 놀랐던 기억이…)

운젠 메모리얼 홀 이라는 곳이 있어서 가 봤습니다만, 어찌된 일인지 잠겨 있었습니다.

이런 곳이라면 뭔가 박물관 하나쯤은 있었으면 좋았을 텐데요

색 바랜 간판을 내건 일본 요리집. 가족이 오지만 않았으면 이런데 가서 모험해 보는 것도 새로운 맛인데 아쉽군요.

여기도 신사는 있습니다. 신사는 동네마다 하나씩 있는듯.

역시나 구조는 다른 신사와 동일합니다.

근데 궁금한게, 신사는 토착신앙 기반인것 같은데 정확히 어떤 신을 모시는 거지요? 불교는 아닐테고, 그냥 지방신들을 통틀어 섬기는 걸까요?

신사에서는 다시 지옥온천으로 이어지게 됩니다. 온천수가 지나가는 수 많은 파이프들.

우리가 묵었던 료칸 호텔 후키야. 꼭대기층 (5층)의 좌측에서 4번째인가 5번째 유리창입니다. 525호

이쪽은 처음에 돌았던 지옥온천 순례코스와 이어지는 코스입니다. 이제 진정으로 마을을 한 바퀴 다 돌았군요.

가는 길 도중에 보면 땅 속에서 올라오는 관이 있고, 그걸 저렇게 돌로 막아놓은 구멍이 간혹 보입니다.
그런 구멍을 보면 조심해야 합니다. 잠깐 손 한번 댔다가 데이는줄 알았습니다.
우와 땅 깊이에 있는 온천물은 120도까지 올라간다는 것이 거짓말은 아니군요. (근데 물이 100도 이상 가능한가요? 기화된 상태로 존재한다는 걸까?)

이런 구멍 말입니다. 저 위에 주전자 등을 놓고 온천달걀을 삶는게 진짜였군요. ㅎㅎ
막상 보니 신기합니다.

길 건너 반대편, 즉 마을의 진짜 중심부에는 예전에는 온천수가 나왔지만 지금은 나오지 않아 버려진 곳이 있습니다.

이 쪽 산길로 올라가면 운젠의 절 만묘지가 나오게 되지요.

가는 길 곳곳에 세워진 불상들.

그리고 그 위엔 꼭 돈이 놓여져 있더군요.

그나저나 손에 들고 있는 저 똥은 뭘까나 .. .

여기도 돈.

여기도 돈. 어라 불상 표정이 개성있다.

생긴것도, 표정도 다양한 불상들이 주욱 나열되어 있는 모습이 독특하네요.

이 산길만 지나면 절입니다.

읭? 산 꼭대기에 왠 돌 미끄럼틀이?

절은 기대한 것과는 다르게 왠지 가정집스러운 분위기였습니다.

역시 불상마다 올려진 돈과… 어라 저 우롱차는 뭐야…

사실상 불상외에 별로 볼 것이 없었기 때문에 내려왔습니다.
내려오는 길에 가정집 사이를 지나게 되었는데, 가정집 구석에도 저런 관이 박혀 있고 저기서 연기가 나오네요. 과연 온천의 마을.
어디서나 땅만 파면 온천이 나오는 건가요?

이제 돌아오는 버스를 탔습니다. 이제 집에 가네요.

어라 ? 갈때보다 버스가 무척 작습니다. 흐음. 하긴 손님도 좀 적지만…

올 때 들른 휴게소에서 파는 아이스크림.
100% 우유랍니다. 맛은…

저야 뭐 우유를 좋아하지 않아서 잘 모르겠습니다만 확실히 진짜 우유맛이 난달까요? 고급스럽긴 하더군요. 하긴 가격이 얼만데…
환율 따지면 4000원 가량이잖아…

오는 길은 가는 길과는 다른 경로였습니다. 정말로 4시간을 넘게 육로로만 이동.

해안도로 가는게 멋졌을 것 같습니다만 그땐 자느라고 사진이 없어요 ㅋㅋ

당연하게도 제펜에그는 휴게소에서도 켜질줄 모릅니다. 대도시 아니면 쓸모가 없네요.
아 이놈의 인터넷 금단증 ㄷㄷㄷ

그렇게 몇 시간을 달려

하카타역에 18시 도착했습니다.
비행기는 21시이므로 시간은 많지 않지만 대충 저녁먹을 시간 정도는 되는 시간.

다시 지하철로 2정거장 지나 후쿠오카 공항에 도착했습니다.

아놔 ㅋㅋ 건담 ㅋㅋ 타고싶어 저 비행기 ㅋㅋㅋ

나가는 길 찾기는 쉽습니다. 셔틀버스 안내가 있는 쪽으로 나가면 되니까요.

그냥 올때랑 완전히 반대로 가면 되는 겁니다.

아주 쉽죠?

공항은 뭐 그렇게 크지 않습니다. 김포공항만 할까요.

면세점 저 한글 폰트 참 재밌어요. 어디서 만든 폰트일까요? 동남아에서도 가끔 보이던데요. (북한 폰트인가 ㄷㄷㄷ)

면세점도 작고, 전체적으로 자그마한 공항이지만 어쨌건 저펜애그가 가동되는 지역이라 인터넷이 되니 무조건 좋습니다 ㅎㅎ

돌아가는 비행기는 .. 오! 이거 오랫만에 타보네요. 북경갈때 타봤던 A380 기종, 뉴 이코노미 좌석이네요.
앞뒤 간격도 넓고, 터치스크린 개인 모니터에, 2단으로 접히고 당겨지는 식탁에, 옷걸이와 USB 충전포트가 인상적인 기종입니다. 특히나 좌석 간격이 이코노미석인데도 불구하고 넓어서 좋아요.

거기다 이륙하기 전에 보여주는 전방카메라 뷰가 특히 인상적이었습니다. 낮이라면 더 좋았을텐데요.

요건 탑승기념 아이들 선물

역시나 거리가 짧아서 가볍지만 특별한, 아이들 전용 기내식입니다.

어른들은 이거구요,

아이들은 이겁니다 :)

가운데 과자는 고래밥이구요. 오른쪽 호빵맨 주스는 베지밀에 가까웠습니다.

예약 후에 항공사 홈페이지에서 주문할 수 있어요 :) 할 수 있으면 꼭 하는게 좋습니다. 저 쪽에 앉은 아이도 굉장히 부러워 하더군요.

이렇게 약 1시간 30분의 짧은 비행시간 후에

밤 10시 도착. 쇼 저펜애그 반납을 잊으면 안되겠지요. (잊으면 계속 사용료 나간다구요 ㄷㄷㄷ)

반납 후 주차 대행 차량 인도장에서 차를 되찾아 복귀했습니다.
아아 그런대로 괜찮은 첫 가족 해외여행이었습니다. 단지 조금 빡빡하게 일정을 잡았다는 느낌이 나긴 하더군요.
한번 더 한다면 아예 온천에서 2박하는 일정이었으면 어땠을까 하는 생각이 들었습니다.

이제 여행기 끝~~~~

큐슈 / 후쿠오카 - 운젠 여행기 6

Sat, 12 Feb 2011 12:07:05 +0000

아침에 간단하게 온천을 즐긴 후, 아침밥을 먹습니다. 아침밥도 포함되어 있는지라…
체크인은 11시, 하카타역으로 데려다줄 송영버스는 2시 도착이니 체크아웃하고 산책 좀 하면 되겠지요.

어제 저녁보다는 조금 간략하지만 역시나 매우 멋져보이는 음식들이네요.

근데 그래도 내 입맛엔 안맞겠지… ;ㅅ;
서양음식은 전부 다 맞는데 일본음식은 안맞는군요

가운데 있는 저 컵은 죽이 들어 있고, 그 주위는 해초와 어묵들.
오른쪽 은박지에 올라가 있는 것은 생선이네요.

그리고 왼쪽 저 계란은, 왼쪽의 저 뚜껑을 열어서…

이렇게 하는 거랍니다. 햄 두 장이 펼쳐져 있네요.

은박지 안에 있는건 생선. 너무 달아!!! 음식이 전반적으로 너무 달아요…

밥과 미소된장.

나무젓가락으로 밥먹는거 불편하지 않나요? 나무 젓가락에 밥풀묻어서 떼어내려면 기분나쁘던데.

다른 테이블에도 다른 투숙객들 아침이 준비되어 있습니다.

식사 후 방으로 복귀.

전반적으로 ‘어제 저녁보다는 좀 더 입에 맞더라’ 라는 분위기였습니다.
뭐 저도 그렇긴 했지만 오십보 백보.. .

식사 후 마지막으로 간략하게 온천에 몸담그고 짐 정리하고 11시에 맞춰 체크아웃했습니다.
호텔에서는 알아서 버스올때까지 짐을 맡아주시네요. 2시까지 자유시간입니다. 이제 관광하면 되겠군요.

호텔 앞 거리부터 시작해서 주변을 걷습니다. 온천에서 푹 쉬었던 덕분에 피로는 풀려 있어 그런지, 모두들 발걸음이 가볍네요

일단 어제 밤에 갔던 바로 그 곳으로 갔습니다.

[#VIDEO|20110212120200011985231701.jpg|pds/201102/12/03/|mid|480|400|pds20#]낮에 보니 사뭇 신기한 전쟁터 (…) 분위기네요.

구글맵에서 본 위치는 아래와 같습니다.

http://maps.google.co.kr/?ie=UTF8&ll=32.740789,130.261819&spn=0.003822,0.004281&t=h&z=18

잘 보면 땅에 파이프가 박혀져 있는데, 아마도 깊은 원수를 뽑아내서 각 호텔에 공급하는 관인 듯 싶습니다.

나와 있는 온천수들은 연기는 나지만 그렇게 뜨겁진 않고, 약 40도 정도 되는 온도 느낌이었어요.

이 길이 운젠지옥온천 산책코스입니다.
공짜라는 점이 최고 장점.

천천히 돌아도 한시간도 안걸릴 코스이긴 합니다 :)

온천달갈을 파는 가게도 중간중간 있지유.

가면서 길가의 뽀골뽀골 올라오는 온천수들을 보는 것도 신기한 경험입니다.

[#VIDEO|20110212140200011988751701.jpg|pds/201102/12/03/|mid|480|400|pds21#]

유황들로 인해, 돌이 변색되어 있습니다 (라기보단 뭔가 겉에 쌓여진 느낌)

중간쯤 가다보면 산 위에 십자가가 세워져 있는데요. 이곳은 예전에 천주교 신자들을 박해하면서
배교하지 않는 신자들을 끓는 물에 집어던져 죽였다는 순교지이도 합니다.

하긴 제대로 나오는 온천수는 120도라니까요 …

운젠온천 안내지를 보면 꼭 나오는 사진입니다. :)

뭔가 아쉬워서 조잡하게 파노라마로 만들어 본 사진입니다.

아마 블로그에서는 스킨설정에 따라 짤릴지도 모르는데, 누르시면 댑따시 커집니다

여기는 아비규환 지옥.

지옥온천에는 구역마다 이름을 붙여놓았었는데, 가장 인상깊던 곳은 여기입니다.

분출해 나오는 수증기가 가장 맹렬하고 그 소리가 굉장히 커서, 지옥에서 울부짖는 소리 같다고 해서 아비규환 지옥입니다.

소리가 뭐랄까. 깜짝 놀라서 도망치고 싶을 정도는 아니지만 매우 맹렬해서 정말로 화산 터지는 것 아닐까라고 생각되게 만드는 곳이랄까요. 운이 좋으면 물이 솟구치는 것도 볼 수 있다고 씌여 있었습니다만 애석하게 보지는 못했네요.

[#VIDEO|20110212160200011993871701.jpg|pds/201102/12/03/|mid|480|400|pds22#]

가벼운 마음으로 산책하기 좋은 코스라고 보여지네요.

신기한 느낌도 받으실 수 있으니까 한번 가 보시는걸 추천합니다.
혹시 압니까 언젠가 화산이 터져서 (남쪽으로 200km 내려가면 터졌다는데.) 못가게 될지도요.

일본사람들은 뭔가 성적인 표현에서 대단히 관대한 것으로 보입니다. 다른 것들은 상당히 예의바르고 금욕적인데 말입니다.

운젠 비드로 미술관이 볼만한 곳이라고 해서 가는 길입니다.

가는 길에 본 개집스러운 이글루 (…)

미술관이라고 해서 뭔가 했더니 수제 유리작품 판매점에 가깝습니다.
수제이므로 손맛이 나긴 하지만 왠지 사고 싶은 건 없는…

그리고 미술관에 들어가면 역시 온천 - 대중목욕탕이라고 읽으면 됩니다 - 이 이어져 있습니다.
미술관 + 온천이랄까요.

여기서 뭔가 입으로 불어서 유리만드는걸 해볼수 있다고 들었는데.. 오늘은 가동 안하나 보더군요

귀여운 경찰서입니다. 저번에 본 현상범들의 포스터가 여기도 붙어있…

한 바퀴 돌고 호텔방향으로 다시 돌아오는중. 말씀드렸다시피 작은 마을이라 뭐 금방금방 도네요

일 년 내내 유황이 섞인 수증기가 뿜어져 나와서 그런지, 나무로 만든 길은 썩어서 보강한 부분이 꽤 보입니다.

운젠의 명물 (이라고 하기에는 뭔가.. 이지만) 인 운젠 전병을 만드는 가게입니다. 바로 앞에서 볼 수도 있고 끄트머리 탄 부분을 안 뗀, 바로 나온 녀석도 살 수 있네요 :) 방금 나와서 그렇겠지만 별 것 아니지만 맛있습니다.

계속 버스탈때까지의 산책은 이어집니다.

빌트-인 쉐이더들의 호환성과 그 무게표 (PC편)

Fri, 11 Feb 2011 18:17:29 +0000

쉐이더들은 일반적으로 높은 기술을 사용할수록 호환성이 떨어지고, 더 느리게 됩니다.
때로는 치명적인 기술이 사용된 쉐이더를 사용하게 되면 퍼포먼스에 심각한 영향을 끼칠 수 있게 되는데요.

쉐이더를 알뜰하게 쇼핑(?) 하는 것도 중요한 기술입니다.
꼭 필요한 기능만 들어 있는 걸로, 같은 기능이면 최대한 저렴한 놈으로 골라서 쓰는 거지요.

하지만 수많은 쉐이더가 있고, 어떤 것이 어느 정도 무거운지 그래픽 디자이너가 알기가 힘든 것이 사실입니다.
그래서 일단 그래픽 디자이너 입장에서 보기 편하게끔 정리를 해 보았습니다.

일단 삼품은 쉐이더 2.0 기반인데다가 폴리곤도 상당히 적게 쓰기 때문에 고급의 픽셀 라이팅을 쓰는것은 그다지 효율적이지 않습니다 버텍스 라이팅을 쓰는 쪽이 훨씬 퍼포먼스에 좋고, 픽셀라이팅을 써도 그렇게 효과가 좋아지지 않지요.
(사실 2.0 이하도 지원할 수 있을 것 같다고 생각하고 있습니다만… 지형 쉐이더 때문에 곤란할 듯 합니다.지형 멀티 블렌딩 문제가…)

* 이 쉐이더들은 2011년 2월 14일 올라온 빌트-인 쉐이더를 기반으로 하고 있습니다. 계속 바뀌고 있는 관계로 이전의 쉐이더나 이후의 쉐이더와는 약간씩 다를 수도 있음을 밝힙니다.

1g 짜리 쉐이더들 : 아주 가볍고 호환성 높은 쉐이더. 되도록이면 마음껏 사용해 주세요.

Diffuse Fast : 분명 가벼운 쉐이더라고 나와 있긴 합니다만.. 막상 소스를 보니 유니티 3.x 대에서는 아무 일도 하지 않고 , 그냥 VertexLit로 쉐이더 설정값을 넘겨주는 역할만 합니다! 하지만 분명 가장 가벼운 쉐이더임에는 틀림 없습니다.
버텍스 라이팅으로 작동하는 것이 특징입니다. 알파가 없는 일반 오브젝트에 사용하세요.

Diffuse : 그 다음으로 가벼운 쉐이더. 픽셀라이팅으로 Diffuse Fast 보다 더 정밀한 라이팅을 보여줍니다. 알파 없는, 일반 오브젝트에 사용하세요

Transparent/Cutout/Diffuse : Diffuse 만큼 가볍습니다만, 알파 테스팅을 사용할 수 있다는게 다릅니다. 알파 채널이 필요한 일반 오브젝트에 사용해 주세요.

VertexLit : 버텍스 라이트로 가벼우며, Specular와 Emissive 칼라까지 표현가능한 다재다능한 쉐이더입니다. 알파는 사용할 수 없습니다.

Transparent/Cutout/VertexLit : 버텍스 라이트를 사용하여 가벼우며, 알파 테스팅 연산이 가능합니다. 알파가 있으면 이걸 사용하시기 바랍니다.

2g 짤 쉐이더들 : 1g 쉐이더들만큼 가벼운 쉐이더는 아닙니다만, 2g 대까지의 쉐이더는 사실 굉장히 가볍기 때문에 사용하는데 그다지 부담을 크게 가지지 않으셔도 됩니다. 1g은 ‘가벼운’ 쉐이더고 2g은 ‘가볍지만 일반적인’ 쉐이더의 느낌.

Diffuse Detail : Diffuse 와 기본적으로 같지만, 또 한장의 detail 텍스쳐를 diffuse 텍스쳐에 ‘곱해’ 줍니다. 포토샵으로 말하면 멀티플라이 옵션을 적용시킨 것과 같달까요. 원래 디테일 부분에 노이즈 텍스쳐를 주고 타일링을 잔뜩 줘서, 가까이 카메라가 접근했을때 디테일 텍스쳐가 뿌옇게 보이는 것을 방지하고자 만든 쉐이더입니다만, 좋으실대로 사용해도 됩니다. 알파 지원 안됩니다.

Specular : 스페큘러가 지원되는 가장 가벼운 쉐이더입니다. 반짝반짝대는 물체가 필요하실때 사용하세요. 디퓨즈맵의 알파 채널이 스페큘러 마스크로 사용되므로, 알파는 사용할 수 없습니다.

Self-Illumin/VertexLit : Self-Illumin/Diffuse 와 같게 적동하지만, 라이팅이 버텍스 라이팅을 사용하므로 더 가볍습니다. Emission (Lightmapper) 명령은 라이트맵 연산시에 사용되는 듯 하고, 평소에는 어떤 작용도 하지 않습니다.
Self-Illumin/Diffuse : 기본적으로 Diffuse와 같지만, 또 한장의 Illumination 텍스쳐를 사용할 수 있다는 점이 다릅니다. 이 쉐이더는 이상하게도 Illumination 텍스쳐의 ‘알파 채널만’ 사용하고 나머지는 아예 사용하지 않으며, 이 채널에 따라 Diffuse의 밝기가 결정됩니다. Emission (Lightmapper) 명령은 라이트맵 연산시에 사용되는 듯 하고, 평소에는 어떤 작용도 하지 않습니다. 특별하게 사용할 때 외에는 비추입니다 .

Reflective/VertexLit : 큐브맵으로 반사가 사용되지만 버텍스 라이팅을 사용하기 때문에 가볍습니다.
Reflective/Bumped VertexLit : 큐브맵으로 반사가 사용되지만 버텍스 라이팅을 사용하기 때문에 가볍습니다. 노말맵을 사용하지만 버텍스 라이트 계산이라 정확도가 좀 떨어지긴 합니다.

Transparent/Cutout/Specular : Specular Diffuse 쉐이더에서 알파 테스팅이 추가된 쉐이더입니다.

RenderFX/Skybox Cubed : 스카이박스를 위한 큐브맵 쉐이더입니다. 호환성이 최고로 좋다고는 할 수 없지만, 어쨌건 가볍습니다.

3g 짤 쉐이더들 : 3g 부터는 살짝 묵직해진다고 할 수 있습니다. 물론 여전히 사용하셔도 되긴 하지만 ‘일반적인 오브젝트’ 한테까지 사용하는건 좀 반대입니다. :) 일부는 모바일에서도 표현 되며, 일부는 되지 않습니다.

Decal : 데칼 쉐이더는 기본적으로 Diffuse와 같지만, 또 한장의 decal 텍스쳐를 사용할 수 있다는 점이 다릅니다. 그리고 데칼 텍스쳐의 ‘알파 채널’에 따라 diffuse 텍스쳐가 나올 것인지 decal 텍스쳐가 나올 것인지 결정됩니다. 알파는 사용할 수 없습니다. 데칼 텍스쳐의 특이한 기능을 사용하지 않으려면 비추입니다.

Particles/VertexLit Blended : 이펙트에 사용가능한 알파 블렌딩 전용 쉐이더. 라이트 영향을 받고, 2side 이며, Z write를 하지 않습니다. 이펙트에서는 가장 가벼운 쉐이더로, 추천드리는 바입니다. 이펙트 쉐이더는 가장 가벼운게 3g …. (밝거나 어둡게 합성되기를 원하신다면 요청주세요)

Bumped Diffuse : Diffuse 와 기본적으로 같지만, 추가로 노말맵이 사용됩니다. 사실 노말맵이라는게 이 상태로 사용되면 잘 보이지도 않기 때문에 그다지 추천하는 쉐이더는 아닙니다만, 어쨌건 노말맵을 사용하셔야 한다면 그중 가장 가벼운 쉐이더임에는 틀림 없습니다. 알파 지원 안됩니다.

Transparent/Cutout/Bumped Diffuse : Bumped Diffuse 쉐이더에서 알파 테스팅이 추가된 쉐이더입니다.
Transparent/Cutout/Soft Edge Unlit : 알파 테스팅으로 보이지만 사실 알파 블렌딩도 같이 사용하고 있습니다. 풀이나 나무 등을 위해 만들어진 쉐이더로, 테두리가 부드럽게 보이도록 만들어 졌습니다. 라이트를 사용하지 않는 특징이 있습니다.

Reflective/Bumped Unlit : 큐브맵을 사용하는 반사 맵중 가장 가볍습니다. 라이트를 사용하지 않습니다.
Reflective/Bumped VertexLit : 큐브맵으로 반사가 사용되지만 버텍스 라이팅을 사용하기 때문에 가볍습니다.
Reflective/Diffuse : Diffuse 맵과 같지만, 큐브맵을 이용해서 반사를 표현하는 쉐이더입니다.
Reflective/Specular : Reflective/Diffuse 에 Specular 가 추가된 쉐이더입니다.

Self-Illumin/Specular : Self-Illumin/Diffuse 에 Specular 가 추가된 쉐이더입니다.

4g 짤 쉐이더들 : 여기서부터는 한 번씩 생각하시고 쓰셔야 하는 쉐이더입니다. 필요한 경우엔 물론 사용하셔도 되지만, 되도록 사용을 주의해 주시고 화면에 많이 나오지 않도록 해주시기 바랍니다.그리고 이 부분부터는 모바일에서 똑같이 표현되기 불가능하다고 생각하시면 됩니다.주로 노말맵을 사용하는 쉐이더들입니다.

Transparent/VertexLit : 알파 블렌딩과 스페큘러가 사용되지만 라이팅이 버텍스 라이팅인 쉐이더입니다. 알파 블렌딩과 스페큘러를 사용하는 쉐이더 중에서는 가장 가벼울 것입니다. 폴리곤이 비교적 많으면서, 고급 질감이 필요한 오브젝트에 사용하시기 바랍니다 .
Transparent/Diffuse : Diffuse 만큼 가볍습니다만, 알파 블렌딩을 사용할 수 있다는게 다릅니다.(알파 블렌딩은 언제가 무겁습니다 : 모바일 제외) 알파 블렌딩이 필요한 부분에 사용해 주세요. … 아마 이펙트가 될 것 같습니다만… 일반 오브젝트에 꼭 필요한 경우 외에는 비추입니다.

Self-Illumin/Bumped Diffuse : Self-Illumin/Diffuse 에 노말맵이 추가된 쉐이더입니다.
Self-Illumin/Bumped Specular : Self-Illumin/Bumped Diffuse 에 Specular가 추가된 쉐이더입니다.

Reflective/Bumped Diffuse: Reflective/Diffuse 쉐이더에 노말맵이 추가된 쉐이더입니다.
Reflective/Bumped Specular: Reflective/Bumped Diffuse 쉐이더에 Specular가 추가된 쉐이더입니다.

{
Particles/Blend : 이펙트용 쉐이더로, 기본적으로는 심하게 무거운 편이 아니지만 Soft Particle 기능이 켜지면 지형과 맞닿는 부분을 인식하는 코드가 들어있는 관계로 그 때에는 무거워집니다.즉, 무게가 가변적입니다. (아래의 모든 Particle 쉐이더가 마찬가지입니다)
Particles/Alpha Blended Premultiply : 이펙트용 쉐이더로, 뒤 이미지와 겹쳐서 조금 어두워집니다.
Particles/Additive : 이펙트용 쉐이더입니다. 밝아집니다.
Particles/Additive (Soft) : 이펙트용 쉐이더입니다. 조금 덜 밝아집니다.
Particles/Multiply : 이펙트용 쉐이더입니다. 겹쳐서 어두워집니다.
Particles/Multiply (Double) : 이펙트용 쉐이더입니다. 겹쳐서 조금 덜 어두워집니다.
Particles/Alpha Blended : 이펙트용 쉐이더입니다. 그냥 겹칩니다.
Particles/~Additive-Multiply : 이펙트용 쉐이더입니다. 알파에 의해 밝아지거나 어두워집니다.
}

5g 짤 쉐이더들 : 중요한 캐릭터나 인상적인 배경에 사용하는게 좋은 쉐이더입니다. 이 쉐이더부터는 슬슬 관리가 필요하며, 사용시에 부하를 고민해 줘야 하는 쉐이더입니다.

Transparent/Bumped Diffuse : Transparent/Diffuse 쉐이더에 노말맵 지원이 들어갔다고 생각하시면 됩니다. 더 설명이 필요한가요? :)
Transparent/Specular : Specular 쉐이더에 알파 블렌딩이 추가된 쉐이더입니다.
Transparent/Bumped Specular : Transparent/Bumped Diffuse 에 Specular 가 추가된 쉐이더입니다.
Transparent/Cutout/Bumped Specular : Transparent/Bumped Specular 에 알파 테스팅이 들어간 쉐이더입니다.

6g 쉐이더들 : 아주 묵직한 쉐이더입니다. 정말로 꼭 필요한지 한 번 생각해 보시고 사용하시기 바라며, 팀장님과 상의해 보시기 바라겠습니다. 특정 그래픽 카드에서는 작동하지 않거나, 내장된 저사양 옵션 쉐이더로 바뀌어서 돌아가게 됩니다. 사실 Parallax 는 쓰지 않으시길 추천합니다. (Parallax가 들어간건 쓰지 않으면 된다라고 보시면 됩니다)

FX/Water / FX/Water (simple) / FX/Water GrabPass : 복잡한 굴절과 여러 텍스쳐를 사용하는 쉐이더로, 일반적인 쉐이더들보다 고급 기법이 들어가 있는 쉐이더들입니다. 낮은 사양의 그래픽 카드에서는 제대로 표현되지 않습니다. 빌트 - 인 쉐이더가 아니지만 비교삼아 넣어 보았습니다.

Parallax Diffuse : 노말맵보다 발전된 시차보정맵핑이 추가로 사용되는 쉐이더입니다. 고급사양의 게임에서 주로 사용되는 기능입니다.
Parallax Specular
Self-Illumin/Parallax Diffuse
Self-Illumin/Parallax Specular
Transparent/Parallax Diffuse
Transparent/Parallax Specular
Reflective/Parallax Diffuse
Reflective/Parallax Specular

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

그러므로 쉽게 쉐이더를 구별할 수 있는 일반적인 방법은 다음과 같다고 볼 수 있겠습니다.
쉐이더 이름에서 아래 이름이 들어갔다면, 가볍거나 무거운 것이라고 짐작할 수 있습니다.

라이트
Unlit : 라이트를 사용하지 않습니다. 라이트의 영향을 받지 않아 그냥 밝습니다.매우 가볍습니다.
VertexLit : 버텍스 라이트를 사용해서 라이트의 정밀도가 떨어집니다. 버텍스가 많아질수록 좋아집니다.그러나 가볍습니다.
Diffuse : 일반적인 픽셀라이트로, 일반적인 무게입니다.
Specular : 스페큘러 계산이 들어갑니다. 그냥 Diffuse 보다 조금 더 무겁고, 스페큘러가 반짝입니다.

맵핑
Reflective : 큐브맵을 이용한 반사가 들어갑니다.좀 무겁습니다.
Bump : 노말맵이 사용됨을 의미합니다. 텍스쳐 한 장이 더 들어가고 노말맵 계산이 이루어지므로 많이 무겁습니다.
Parallax : 노말맵에 시차보정 맵까지 들어갑니다. 엄청 무겁습니다.

알파
Cutout : 알파 테스팅으로 알파를 처리하는 쉐이더는Transparent / Cutout 이라는 메뉴에 있습니다. 알파를 처리하기에 가장 가벼운 방법입니다.
Transparent : 알파 블렌딩이 들어가는 쉐이더는 Transparent 아래 메뉴에 있습니다. PC에서는 알파 블렌딩이 매우 무겁습니다. (모바일에서는 반대입니다)

http://intra.ndoors.com/center/board/view.asp?list_seq=208548&board_seq=313&readchk_flag=N 참고

Performance Tips when Writing Shaders in Unity

Fri, 11 Feb 2011 14:44:04 +0000

Performance Tips when Writing Shaders

Use Common sense ;)

Compute only things that you need; anything that is not actually needed can be eliminated. For example, supporting per-material color is nice to make a shader more flexible, but if you always leave that color set to white then it’s useless computations performed for each vertex or pixel rendered on screen.

Another thing to keep in mind is frequency of computations. Usually there are many more pixels rendered (hence their pixel shaders executed) than there are vertices (vertex shader executions); and more vertices than objects being rendered. So generally if you can, move computations out of pixel shader into the vertex shader; or out of shaders completely and set the values once from a script.

당신이 원하는 것만 계산하세요 ; 원하지 않는것은 제거될 수 있습니다. 예를 들어서 per 메터리얼 칼라는 쉐이더를 유연하게 만들어 줄때 좋습니다. 그렇지만 당신이 그걸 그냥 언제나 흰색으로 놔둔다면 그것은 렌더링 될때 쓸데없는 계산을 낭비하게 되는 것입니다.
마음에 둘 또하나의 내용은, 계산의 반복여부입니다. 보통 많은 픽셀들이 버텍스(버텍스 쉐이더가 돌고)보다도 많게 렌더링되고 (그래서 픽셀쉐이더들도 따라서 돌고) ; 그리고 오브젝트보다 많은 개수의 버텍스들이 렌더링됩니다. 그러므로 가능하다면 계산을 픽셀 쉐이더보다 버텍스로 이동시키세요 (주: 버텍스 쉐이더를 많이 쓰세요) ; 혹은 쉐이더의 복잡도를 줄이고 스크립트에서 값을 한 번만 셋팅하세요.

Less Generic Surface Shaders

Surface Shaders are great for writing shaders that interact with lighting. However, their default options are tuned for “general case”. In many cases, you can tweak them to make shaders run faster or at least be smaller:

가벼운 서피스 쉐이더

서피스 쉐이더는 라이팅과 연산하는데 무척 훌륭합니다.(주: 멋진 결과물을 냅니다) 그럼에도 불구하고, 그들의 기본적인 옵션들은 ‘일반적인 케이스’에 맞게 튜닝되어 있습니다. 많은 경우에서, 당신은 쉐이더를 더 빠르거나 적어도 비슷하게 조정할 수 있습니다.

approxview directive for shaders that use view direction (i.e. Specular) will make view direction be normalized per-vertex instead of per-pixel. This is approximate, but often good enough.* approxview 뷰 디렉션을 직접 사용하는 쉐이더는 (스페큘러 같이 말이죠) 뷰 디렉션을 픽셀보다 버텍스에서 노말라이즈 하세요. 이건 뭐 대충인건 사실이지만 충분히 괜찮은 결과가 나옵니다.* halfasview for Specular shader types is even faster. Half-vector (halfway between lighting direction and view vector) will be computed and normalized per vertex, and lighting function will already receive half-vector as a parameter instead of view vector.* halfasview 이 방식은 스페큘러쉐이더 타입 계산에서 빠릅니다. 하프벡터(라이트 디렉션과 뷰 벡터 사이의 중간값) 는 버텍스별로 계산하고 노말라이즈 합니다. 그리고 라이트 펑션은 언제나 하프 벡터를 뷰 벡터 대신에 받습니다. 그리고 라이팅 펑션을 사용하면 이미 뷰 벡터 대신에 하프 벡터를 받아오게 됩니다.
noforwardadd will make a shader fully support only one directional light in Forward rendering. The rest of the lights can still have an effect as per-vertex lights or spherical harmonics. This is great to make shader smaller and make sure it always renders in one pass, even with multiple lights present.* noforwardadd 이것은 포워드 렌더링에서 다이렉트 라이트를 풀버전으로 서포트 합니다. 결과값은 라이트가 여전히 버텍스 단위의 효과를 나타내거나 공 모양의 하모닉스를 씁니다. 이것은 쉐이더를 작게 하거나 언제나 한 패스만 돌게 합니다. 심지어 여러 라이트가 있는 상황에서도 말입니다.* noambient will disable ambient lighting and spherical harmonics lights on a shader. This can be slightly faster.
- noambient 는 엠비언트 라이트를 끄고 공 모양의 하모닉스라이트를 쓰는 쉐이더입니다. 이것은 쬐끔 빠릅니다.

Precision of computations

When writing shaders in Cg/HLSL, there are three basic number types: float, half and fixed (as well as vector & matrix variants of them, e.g. half3 and float4x4):

계산 정밀도
CG나 HLSL 쉐이더를 쓸 때에는 3개의 넘버 타입이 있습니다. : float과 half와 fixed (벡터와 메트릭스 등에서도 말입니다. 예를들어 half3나 float4*4 같은)

float: high precision floating point. Generally 32 bits, just like float type in regular programming languages.* float : 높은 정밀도의 플로팅 포인트입니다. 보통 32비트입니다. 이것은 일반적 프로그래밍 언어의 플로트 타입 같은겁니다.* half: medium precision floating point. Generally 16 bits, with a range of -60000 to +60000 and 3.3 decimal digits of precision.* half : 중간 정도의 정밀도의 플로팅 포인트로, 보통 16비트입니다. 이것은 -60000 에서 +60000 의 범위를 가지고 있고 3.3 소수의 정밀도를 가지고 있습니다.* fixed: low precision fixed point. Generally 11 bits, with a range of -2.0 to +2.0 and 1/256th precision. * fixed : 낮은 정밀도의 고정된 포인트입니다. 보통 11비트죠. -2 에서 +2 의 범위를 가지고 있고 1/256th 정밀도를 가지고 있습니다.

Use lowest precision that is possible; this is especially important on mobile platforms like iOS and Android. Good rules of thumb are:
낮은 정밀도를 사용하는 것은 가능합니다 ; 이것은 특별히 모바일이나 안드로이드 플렛폼에서 말입니다. 열라 좋은 최고의 규칙은 ;

For colors and unit length vectors, use fixed.* 칼라나 유닛의 길이 벡터는 fixed를 사용하세요.* For others, use half if range and precision is fine; otherwise use float.
- 다른것은, 범위가 괜찮으면 half를 사용하세요 ; 아님 float 쓰시덩가.

On mobile platforms, the key is to ensure as much as possible stays in low precision in the fragment shader. On most mobile GPUs, applying swizzles to low precision (fixed/lowp) types is costly; converting between fixed/lowp and higher precision types is quite costly as well.
모바일 플렛폼에서 열쇠는 프레그먼트 쉐이더에서 가능한한 낮은 정밀도를 유지시키는 것입니다. 많은 모바일 플렛폼의 GPU에서, 낮은 정밀도의 타입(fixed / lowp)을 섞는 것은 비쌉니다; fixed/lowp 타입을 높은 정밀도 타입으로 컨버팅하는건 열라 비쌉니다.

Alpha Testing

Fixed function AlphaTest or it’s programmable equivalent, clip(), has different performance characteristics on different platforms:

알파 테스팅
고정함수인 알파 테스트나 그에 상응하는 계산인 clip() 은 플렛폼에 따라 다른 퍼포먼스를 내놓습니다.

Generally it’s a small advantage to use it to cull out totally transparent pixels on most platforms.* 보통 이것은 일반적 플렛폼에서 투명도로 물체를 잘라낼때 약간의 장점을 가집니다.* However, on PowerVR GPUs found in iOS and some Android devices, alpha testing is expensive. Do not try to use it as “performance optimization” there, it will be slower.
- 그럼에도 불구하고, PowerVR GPUs 를 사용하는 IOS나 안드로이드 디바이스에서는 알파 테스팅이 비쌉니다. ‘퍼포먼스의 절감’ 을 위해서 사용하지 마세요. 이것들은 더 느리게 될겁니다.

Color Mask

칼라 마스크

On some platforms (mostly mobile GPUs found in iOS and Android devices), using ColorMask to leave out some channels (e.g. ColorMask RGB) can be expensive, so only use it if really necessary.

어떤 플렛폼에서 (iOS나 안드로이드 디바이스에서 찾을 수 있는 대부분의 모바일 GPU에서는) 는 칼라 마스크를 써서 몇몇 채널을 남겨 놓는 것이 더 비쌉니다. 그러므로 이건 꼭 필요할때만 사용하세요.

General shader performance in Unity

Fri, 11 Feb 2011 14:43:40 +0000

Performance of Unity shaders

There are a number of factors that can affect the overall performance of your game. This page will talk specifically about the performance considerations for Built-in Shaders. Performance of a shader mostly depends on two things: shader itself and which Rendering Path is used by the project or specific camera. For performance tips when writing your own shaders, see ShaderLab Shader Performance page.
여기의 내용은 당신의 게임의 전체적인 퍼포먼스에 영향을 끼치는 펙터들입니다. 이 페이지는 특히 빌트인 쉐이더 (제작된 쉐이더가 아닌 내장된 쉐이더) 의 퍼포먼스에 대해 다룹니다. 쉐이더 퍼포먼스는 크게 두 가지의 영향을 받지요 : 쉐이더 그 자체와 프로젝트 혹은 특정 카메라에 의해 사용되는 렌더 패스 말이빈다.
직접 제작하는 쉐이더의 퍼포먼스를 위해서 쉐이더랩 쉐이더 퍼포먼스 페이지를 보십시오.

Rendering Paths and shader performance

From the rendering paths Unity supports, Deferred Lighting and Vertex Lit paths have the most predictable performance. In Deferred lighting, each object is generally drawn twice, no matter what lights are affecting it. Similarly, in Vertex Lit each object is generally drawn once. So then, the performance differences in shaders mostly depend on how many textures they use and what calculations they do.

렌더 패스와 쉐이더 퍼포먼스
유니티에서 지원하는 렌더 패스인 디퍼드 라이팅이나 버텍스 라이트 패스는 굉장히 당연한 퍼포먼스를 가집니다. 디퍼드 라이팅에서는, 모든 오브젝트는 두 번 그려지고 , 라이팅이 얼마나 먹는지에는 영향을 받지 않습니다.
마찬가지로, 버텍스 라이팅은 각 오브젝트가 한 번만 그려집니다.
그래서, 쉐이더의 퍼포먼스에 영향을 끼치는 대부분의 것들은 얼마나 많은 텍스쳐가 사용되냐와 무슨 계산이 이루어지냐입니다.

Shader Performance in Forward rendering path

In Forward rendering path, performance of a shader depends on both the shader itself and the lights in the scene. The following section explains the details. There are two basic categories of shaders from a performance perspective, Vertex-Lit, and Pixel-Lit.

포워드 패스에서, 쉐이더의 퍼포먼스에 영향을 끼치는 것은 쉐이더 자체와 신에 있는 라이팅입니다. 자세한건 뒤의 섹션에 소개해 놓았습니다. 거기에는 두개의 기본적인 퍼포먼스 측면에서의 쉐이더 카테고리가 있는데, 버텍스 라이팅과 픽셀 라이팅에 대해서입니다.

Vertex-Lit shaders in Forward rendering path are always cheaper than Pixel-Lit shaders. These shaders work by calculating lighting based on the mesh vertices, using all lights at once. Because of this, no matter how many lights are shining on the object, it will only have to be drawn once.

버텍스 라이트 쉐이더는 포워드 렌더링 구조에서 언제나 픽셀라이팅 구조보다 저렴합니다. 이 쉐이더는 버텍스 기반으로 계산되고, 모든 라이팅은 한 번만 계산됩니다. 그 때문에, 얼마나 많은 라이트가 오브젝트에 비치건 말건, 한 번만 그리게 될겁니다.

Pixel-Lit shaders calculate final lighting at each pixel that is drawn. Because of this, the object has to be drawn once to get the ambient & main directional light, and once for each additional light that is shining on it. Thus the formula is N rendering passes, where N is the final number of pixel lights shining on the object. This increases the load on the CPU to process and send off commands to the graphics card, and on the graphics card to process the vertices and draw the pixels. The size of the Pixel-lit object on the screen will also affect the speed at which it is drawn. The larger the object, the slower it will be drawn.
픽셀 라이트 쉐이더는 매 픽셀이 그려질때 최종 라이팅을 계산합니다. 때문에, 오브젝트는 엠비언트와 메인 다이렉트 라이트에 의해 한 번 그려집니다. 그리고 매 라이트가 추가되어 비칠 때마다 한 번씩 그려집니다. 이것은 CPU 부하를 초래하고 그래픽 카드에 가는 명령을 차단합니다. 그리고 그래픽 카드는 버텍스와 픽셀을 그리는 프로세스를 진행합니다. 픽셀 라이팅이 적용된 오브젝트가화면에 크게 보일수록 그리는 속도에 영향을 끼칩니다. 오브젝트가 크면, 그릴때 느려질 겁니다.

So pixel lit shaders come at performance cost, but that cost allows for some spectacular effects: shadows, normal-mapping, good looking specular highlights and light cookies, just to name a few.

Remember that lights can be forced into a pixel (“important”) or vertex/SH (“not important”) mode. Any vertex lights shining on a Pixel-Lit shader will be calculated based on the object’s vertices or whole object, and will not add to the rendering cost or visual effects that are associated with pixel lights.
그래서 픽셀라이트 쉐이더는 퍼포먼스 코스트를 요구합니다. 그렇지만 이 코스트는 특별한 효과를 가능하게 합니다 :몇 가지 예를 들자면, 그림자나 노말맵, 퀄리티 좋은 스페큘러나 라이트 쿠키 등 말입니다.
라이트는 픽셀 모드(중요함)와 버텍스 모드(덜 중요함)에 영향을 받는다는 것을 기억하세요. 픽셀 라이팅 기반으로 빛나는 버텍스 라이트들은 오브젝트의 버텍스나 전체 오브젝트를 기반으로 결정됩니다. 그리고 이것은 픽셀 라이팅과 관련된 렌더링 코스트나 특수효과들을 더하지 못합니다. (주: 버텍스 라이트들이기 때문에 특수효과를 못낸다는 말)

General shader performance

Out of Built-in Shaders, they come roughly in this order of increasing complexity:
빌트인 쉐이더 외에, 그들은 대충 아래와 같은 순위로 복잡도가 상승합니다.

Unlit. This is just a texture, not affected by any lighting.* 언라이트. 이것은 단지 텍스쳐입니다. 라이팅의 영향받지 않습니다.* VertexLit.* 버텍스라이트.* Diffuse.* 디퓨즈.* Normal mapped. This is a bit more expensive than Diffuse: it adds one more texture (normal map), and a couple of shader instructions.* 노말맵. 이것은 디퓨즈보다 조금 더 무겁습니다. : 이것은 한 개의 텍스쳐를 더 추가하고, 몇몇개의 쉐이더 명령을 추가합니다.* Specular. This adds specular highlight calculation.* 스페큘러. 이것은 스페큘러 하이라이팅을 추가합니다.* Normal Mapped Specular. Again, this is a bit more expensive than Specular.* 노말맵 스페큘러, 다시 이것은 스페큘러보다 조금더 비쌉니다.* Parallax Normal mapped. This adds parallax normal-mapping calculation.* 패럴랙스노말맵 : 이것은 패럴렉스 노말맵 (주: 시차 매핑으로, 노말맵보다 좀 더 무겁다) 을 추가합니다.* Parallax Normal Mapped Specular. This adds both parallax normal-mapping and specular highlight calculation. * 패럴랙스 노말맵 스페큘러 : 이것은 패럴랙스 노말맵과 스페큘러 계산을 추가합니다.

Additionally, Unity has several simplified shaders targeted at mobile platforms, under “Mobile” category. These shaders work on other platforms as well, so if you can live with their simplifications (e.g. approximate specular, no per-material color support etc.), try using them!

추가적으로, 유니티는 모바일 카테고리에 몇 개의 추가적인 간단한 쉐이더를 가지고 있습니다. 이 쉐이더는 다른 플렛폼에서도 잘 돌고, 그리고 만일 당신이 이 단순한걸 써도 되는 분위기라면 이걸 쓰십시오!! (예로. 대충 계산하는 스페큘러, per 메터리얼 칼라 서포트라던가.)

큐슈 / 후쿠오카 - 운젠 여행기 5

Fri, 11 Feb 2011 02:00:43 +0000

어느덧 저녁식사 시간이 되었습니다.

일정이 애매해서 점심식사를 걸렀더니 (여행가면 이것저것 주워먹어서 한 끼 정도 넘기는건 다반사입니다)
저녁에 나온다던 가이세키 요리가 기대되더군요.

6시에 예약을 해 놓았으므로, 6시에 1층에 있는 식당으로 내려갔습니다.

카이비테이 ..?

입구에는 만화에서 많이 보던 그 히메 인형세트… 인가 하는 것들이.

짠.

오오오오오오오

아니 맛은 일단 둘째 치고라도 모양이 죽여줍니다. 이뻐요

대충 이게 1인분.

은박지에 쌓인건 얇게 썬 돼지고기와 옥수수를 된장으로 조미해 놓은 것입니다. 식사 시작하면 불을 붙여주죠.
그 옆에는 역시 불을 붙여주는 나베가 있습니다.

그리고 각종 회와 해초류 무침들이 가득합니다.

애석하게도 해초류들은 거의 먹지 못하는 입맛이라 감상만 하는 데에서 끝난게 대부분…

회입니다. 일반적으로 먹을 수 있는 레벨이어서 그런대로 즐겁게…

특이하던데 제가 알 같은건 잘 못 먹어서리…

문어와 어묵종류 들입니다.

먹는 법이라는데

… 영어로 된 걸 주세요…

아아 식전 술 한잔을 마시고 하라는건 알겠네요.

후식은 이겁니다. 요거트 같은 맛.
이것 하나는 무척 맛있네요.

식사를 끝마치고 방으로 돌아와 보니, 이불이 깔려 있습니다!!
료칸에서는 식사하는 동안 이불을 깔아 준다더니 정말이군요!!

차가운 다다미 방의 기운을 막기 위해 이불은 2겹으로 깔립니다. 하나는 메트리스에 가까운 것, 하나는 두터운 이불.

여기서 자보고 싶었지만 밀려나서 침대에서 잤습죠 (…) 애들은 왕이니까요…

아직 자기에는 좀 이릅니다. 온천도 또 갔다와야죠. 밤중 온천의 맛이 있으니까.

창밖의 모습은 이렇게 변했습니다 .이미 완전한 밤. 일본의 마지막 밤이 저물고 있습니다.

잠시 답답해서 밤 산책을 나가 봤습니다. 온천에서 생긴 땀도 식힐겸.

하지만 좀 춥더군요 (…)
여기는 산이라는걸 잊으면 안됩니다.

아아 미러리스 카메라의 알흠다운 저광량 노이즈 (…)

길가에서도 온천의 수증기가 뿜어져 나옵니다.

오오 가까이 보니 이거 장관이군요.

부글부글 끓는 소리까지 생생하게 들립니다.

[#VIDEO|20110211010200011961231701.jpg|pds/201102/11/03/|mid|480|400|pds20#]무슨 재난영화에 나오는 한 장면 속에 들어온 것 같습니다. 앞이 안보일 정도네요.

하지만 따뜻하군요.

땅 속으로 관을 박아서 수증기를 뽑아내고 있습니다. 다음날 낮에 한 번 손 대 봤다가 데이는 줄 알았습니다 ㄷㄷㄷ
괜히 이걸로 물 끓이고 계란 삶는게 아니군요.

누가봐도 재난장면으로 인식할만한 느낌입니다.

이번엔 반대로 내려와서 마을 한가운데쪽으로 가 봅니다.

한국은 설이라서 연휴지만, 양력을 쓰는 일본에는 그냥 평일일 뿐입니다.
게다가 한국 관광객도 거의 없어서 한적하고 좋았달까요.

가장 가까이 보이는 가게에 들어가니 운젠의 명물들이 다 있습니다.

운젠 레모네이드. 맛이야 뭐 일반 레모네이드랑 크게 다를 바가 없습니다만 온천수로 만들어 진다 하고,
무엇보다 고풍스러운 병이 인상깊습니다.

운젠은 또 유리공예가 전통있다나요?

여기서 운젠 센베를 만듭니다. 낮에 가면 볼 수 있습니다.

좀 더 마을 쪽으로 들어가봅니다.
곧 눈꽃축제인가 해서 음악도 잔잔히 틀어놓고, 불도 밝혀 놓았네요.

다른 료칸 앞에 무료 족탕이 있습니다.

물이 딱 저렇게 탁한게 온천의 특징입니다.

좀 더 내려가다가 장난감 가게 / 옛날 장난감 박물관을 발견했습니다.

다양한 추억속의 장난감을 구입할 수 있고, 2층으로 올라가면 장난감 박물관을 관람할 수 있습니다. 200엔.

대충 이런 분위기. 저 어렸을적 가지고 놀던 것도 많이 있습니다.

손으로 돌려 날리는 프로펠러 구입 :) 추억의 물건이네요.

밤 산책을 마치고 복귀합니다. 워낙 작은 마을이라 금방 돌수가 있어요. 방금 돈 것만 해도 1/4은 돈듯.

그 후로는 계속 온천 온천 온천입니다.

쾌활한 일본인 중년 아저씨를 탕에서 만나서 즐겁게 얘기도 하고, 여하튼 다들 친절하고 재미있는 사람들만 만나서 좋았습죠.

부지런하게도 새벽에 일어나서 다시 또 온천가러 준비.

새벽과 밤 온천은 정말 좋군요.

체크아웃이 11시이므로 시간은 꽤 있습니다.

큐슈 / 후쿠오카 - 운젠 여행기 4

Fri, 11 Feb 2011 01:01:05 +0000

얏호 커다란 페리다.

사람도 별로 없는데다가 배도 아주 커서 쾌적합니다.

100엔 넣고 하는 안마의자에 눈이 번뜩. +_+

과연, 출발한지 얼마 안되어서 새우깡이 굶주린 갈매기들이 덤벼듭니다.

일본 갈매기들은 한국 갈매기들보다 수줍음이 없는건지, 아니면 더 배고픈건지 과감하게 달려드네요.

덕분에 꽤 괜찮은 갈매기 사진이 좀 찍혔습니다.

아 이럴땐 커다란 DSLR 이 있어야 하는데…

미러리스 중에서 가장 빠른 GF1이지만 이런 경우엔 불만족스럽습니다.

아래쪽 새 두마리는 포토샵에서 복사한 거 아님.

아유 이쁜것들

생각지도 않았던 배 여행을 해 보네요.

잘 나온 사진이 많지만 여기까지만 봅니다.

배에서 본 튀김 자판기. 배만 안불렀어도 하나 먹어보는건데…

이제 도착했습니다. 다시 버스로 올라타서 갈 준비를 합니다.
아직 목적지는 멀었습니다. 그래도 중간에 재미있는 이벤트를 봤네요

그 후로 몇 시간인가 산길을 달립니다. 나중에 GPS 경로를 봤더니 산을 하나 넘었더군요.

그렇게 말그대로 산넘고 물건너 바다건너서

드디어 시바마라에 있는 운젠 온천에 도착.

예상보다 빠른 시간인 오후 1시에 도착했습니다. 에에 체크인은 오후 3시부터인데….

버스가 친절하게 탑승한 인원들의 료칸을 하나하나 찾아다니면서 내려줍니다. 작은 온천마을이네요.
여기가 우리가 묵을 후키야 료칸. 여행박사 직원분이 전망이 좋다고 추천한 곳입니다.

입구에 있는 앵그리버드 부엉이와 료칸 (여관. 전통식 호텔) 의 트위터 주소.

료칸의 로비입니다. 넓직하고 한가롭군요. 저 창문을 통해서는 이따가 보여드릴 것이 보입니다 후후후.

체크인 시간이 3시인데, 1시에 도착한 우리 가족을 위해 1시부터 입실 가능하게 수속해 주셨습니다.
역시 영어도 잘 못하는 직원분들 … 이지만 그래도 뭐 뜻은 대충 다 통하니까요.

기다리는 동안 과자와 차를 내주시더군요.

아아 그윽한 일본 전통차 ….

… 를 기대했습니다만 우우아아아아악머나어ㅣ라 니마ㅓ시ㅓ닝리낭리ㅓ

뭐야 이맛은

이것은 마치 소금기 가득한 바닷물에 미원을 섞은 것 같은 이상한 찝찌름한 맛.

잠시 날 죽이려 하는 줄 알았지 뭐예요.

다행히 떡과 팥 고명이 들어간 부드러운 쿠키로 분노는 진정되었습니다.

아아 큰일날 뻔 했다. 쿠키 맛있네 얌냠.

시간이 남아 로비를 둘러봅니다. 로비 창밖으로 보이는 것은…

펄펄 끓는 온천의 수증기입니다.

그러고보니 약간 매캐한 유황냄새가 납니다.

크게 신경쓸 정도는 아니지만, 제법 인상적으로 이 마을에서는 자주 유황냄새를 맡을 수 있습니다 .

잠시 대기 후 안내받은 방입니다.

이게 료칸이로구나아아아아아아아아아아아아.

체크인보다 훨씬 이른 시간임에도 고맙게도 들여보내주셔서 감사.

여기가 다다미방이고,

방에서 나오면

침대방입니다. 이렇게 해서 5인실. 화실(전통 다다미방)과 양실이 동시에 있다고 해서 화양실이라고 부르는가 봅니다.

침대를 바라보다가 살짝 돌리면 화장대와 화장실과 소파. 화장실은 뭐 일본답게 아주 작습니다.

방에는 차 끓이는 도구와

뒤져보니 반짇고리와 일본어 성경도 있구요.

저는 재빨리 전자기기 충전 베이스캠프를 구축 (잇힝)

저 쪽 장에는 이불세트가.

이쪽 장에는 금고라던가

유카타 (일본식 잠옷. 료칸에서는 이걸 입고 돌아다녀도 된다는군요. ) 와 그 위에 걸치는 겉옷(탄젠). 수건, 샤워캡, 양말 등등이 구비되어 있습니다.

창 밖으로는 운젠 지옥온천이 보이는군요. 오오 전망좋아요.

…그리고 나중에 알았지만 지금 오른쪽 아래 살짝 각지게 보이는 검은 그림자는 여탕쪽 노천탕이었다는 사실 (…게다가 보임…)

아아아아아

훌륭한 전망으로 잡아주신 여행사 관계자 여러분께 깊은 감사의 말씀 드리는 바입니다.
(애석하게도 젊은 손님이 거의 우리밖에 없다시피 했지만)

자아. 어쨌건 녹차나 한잔 우아하게 즐기면서 일정을 짜 봅니다.

워낙 작은 마을인데다가 돌아다닐 곳도 별로 없고, 종일 온천만 할 예정이었기 때문에 사실 별로 준비하지 않았습니다.

호텔 (관광센터에서도 동일한 것을 나눠줍니다) 에서 나눠주는 한국어 지도가 매우 잘 되어 있군요.
여행사에서 온 지도도, 다른 사이트에서도 구할 수 없는 퀄리티의 지도이기 때문에 큰 버전으로 올려 놓았습니다.
위 사진을 누르면 커집니다.

다소 뻔한 얘기일 수도 있겠지만 뒷면도 꽤 내용이 잘 되어 있어서 역시 큰 사진으로 올려봅니다.
운젠 가시는 분들은 위 지도를 보고 계획 잡아 보심이 좋을 듯.

저 신발 (뭐라고 하죠 저거? 발가락 신발.게다(나막신) 은 아닌데… ) 을 신기위한 양말도 있습니다.
처음 신어보니 무척 어색하군요.

어머님과 발가락 꼬집기 전투중 (…)

왠지 인력거를 끌어야 할 것 같습니다.

온천에 왔으니 온천에 가야지요.

2층으로 가도 연결되어 있고, 1층에서 밖으로 나가서 들어갈 수도 있습니다.

팻말만 쫓아가면 어렵지 않게 갈 수 있습니다.

이 앞은 따로 예약한 가족탕 (4-5인용인듯) 이 있는 곳이고, 계단을 내려가면 대욕탕이 있습니다.

여담이지만 새벽에는 여탕이 청소하느라 새벽에 온 손님은 가족탕으로 보냈었다는군요. 좋았겠다…

저깁니다. 뭐 다른 온천에는 시간대별로 여탕과 남탕이 바뀐다던데 여긴 그런거 없습니다.

이용시간은 새벽 5시부터 24시까지…

10시와 11시는 청소라도 하는 걸까요.

아참. 그리고 목욕탕은 이거 하나입니다. 팜플렛에 탕이 여러 개 있는 것 처럼 씌여졌지만,
이 탕 안에 여러 개의 탕이 들어 있다는 얘기입니다.

100엔 넣고 할 수 있는 발 맛사지기.

한 층 올라가면 사람이 해주는 발 맛사지 서비스를 받을 수 있다는 광고문이 있습니다.

… 저 발 맛사지 죽입니다. 중 이상으로 한번 안해봤으면 말을 마세요…. 이놈이 나 죽이는 줄 알았음.

대욕탕 앞 자판기.

배가 좀 고팠어야 이걸 먹어봤을텐데 크흑.

아참. 그건 그렇고

보통 남자 화장실은 아주머니가 청소하지 않습니까?
네 뭐 그건 외국에서도 마찬가지. 한국에서도 당연한 일.

그런데 일본에서는.

목욕탕 남탕 탈의실도 아줌마가 청소하더군요.

이건 뭐 숨길수도 숨을 수도 없어 (…)

그리고 온천하는 요령도 좀 다르더군요.

너무 오래동안 흠씬 불려서 목욕하는 우리 방식이 아닌, 약을 바른다는 느낌으로
너무 오래 있지 말고 잠깐씩 자주 목욕하고, 탕에 들어가서 나온 후 샤워를 하지 말고 그대로 말리던가 살짝 물기만 닦아주는 식으로 이용하라고 하더군요.

흐음. 물은 굉장히 한국 온천과 다르고, 정말 좋았습니다!!
PH가 무려 2.6의 강산성에 우윳빛의 유황냄새 가득한 온천물! 위액에 들어온 줄 알았어
피부가 확실히 달라집니다. 꼭 한번 가보세요.

그렇게 첫날은 아무 일정도 없이 수시로 온천을 들락거리며 쉬는 것으로 소일했습니다. 아아 이제 좀 휴가같다…

꼐속.

아이폰용 쉐이더 테스트

Thu, 10 Feb 2011 12:49:59 +0000

아이폰에서의 쉐이더 사용은 극히 제한적이며, 일부의 쉐이더는 퍼포먼스를 급격히 떨어뜨리기 까지 합니다.

아이폰/아이패드 용으로 사용하기 위한 제한사항들을 먼저 참고하는게 좋습니다.

Simple Checklist to make Your Game Faster

Keep the vertex count below 10K per frame.* 한 프레임당 10,000 버텍스를 넘지 않도록 유지할것* Keep the number of different materials per scene low - share as many materials between different objects as possible.* 여러 메터리얼이 한 씬에 나오게 유지되면 느려짐 - 가능하면 다른 오브젝트간에 메터리얼을 공유할 것* Set Static property on a non-moving objects to allow internal optimizations.* 움직이지 않는 오브젝트는 Static 속성을 넣어서 자체적으로 옵티마이즈 할 수 있게 만들것* Use PVRTC texture compression where possible, otherwise choose 16bit textures over 32bit.* 가능하면 PVRTC 텍스쳐 속성을 사용하도록, 아니면 16비트 텍스쳐를 사용하도록* Use combiners or pixel shaders to mix several textures per fragment instead of multi-pass approach.* 쉐이더에서 멀티 패스를 사용하기보단 콤바이너나 픽셀쉐이더를 사용해서 여러 개의 텍스쳐를 섞도록. * Choose to use less textures per fragment.* 한 프레그먼트(쉐이더) 에서 가능한 적은 텍스쳐를 쓰도록. * Do not use dynamic lights when it is not necessary – choose baking lighting instead.* 필요없으면 동적 라이트를 쓰지 말도록 – 대신 라이트를 베이킹하도록. * Avoid alpha-testing, choose alpha-blending instead.* 알파 테스팅을 사용하지 말고, 대신 알파 블렌딩을 사용할 것.* Avoid fog (especially on newer than iPhone 3GS devices).* 포그를 피할것 (특히 아이폰 3GS 이후 모델들에서)* Learn benefits of Occlusion culling and use it to reduce amount of visible geometry and draw-calls in case of complex static scenes with lots of occlusion. Plan your levels to benefit from Occlusion culling.* 오클루젼 컬링의 이득을 배우시고 복잡한 고정물의 충돌물이 있는 씬에서 낮은 드로우콜과 적은 오브젝트를 위해 사용하라. 레벨디자인을 할 때 오클루젼 컬링에 맞게 계획하라* Use skyboxes to “fake” distant geometry. * 스카이박스를 ‘가짜의’ 원경으로 사용해라

http://unity3d.com/support/documentation/Manual/Optimizing%20Graphics%20Performance.html#iPhoneOptimizingGraphicsPerformance

아이폰에서의 권장사항은 일단 텍스쳐 장수를 줄이고, (여러 개의 복합적 텍스쳐 사용은 버텍스를 복사해서 늘이는 기능도 합니다)
최대한 조명 계산을 자제하라는 것입니다.
또한 일반적인 상식과는 다르게 알파 테스팅보다는 알파 블렌딩을 권장하고, 포그를 사용하지 말라고 되어 있습니다.

이 내용을 기반으로, 아이폰에서 사용가능한 쉐이더 리스트를 정리해 보겠습니다.
테스트 방법은, 쉐이더를 적용한 공 32개를 나열해 놓고, 쉐이더를 바꿔가면서 테스트하였습니다.

테스트 결과는 그래픽 디자이너들이 사용하기 쉽게 분류해 보았습니다.

일단 가장 가벼운 쉐이더로 계산했을 때 22프레임 내외 .. 24 프레임?

큐슈 / 후쿠오카 - 운젠 여행기 3

Thu, 10 Feb 2011 00:53:20 +0000

캐널시티에서 가장 기대했던 볼거리가 없어진데다가
꽤 오래 돌아다녀서 피곤한 관계로 저녁식사를 하기로 했습죠.

역시나 캐널시티의 명물 또하나는 라면 스타디움!!!

전국의 명물 라맨들이 모여서 그 맛을 경쟁한다는 진정한 요리사들의 피의 전쟁터!!!!

두둥. (여기서부터는 사진 먼저, 글을 아래에 적는 옛날 스타일로 복귀 ㅋㅋ)

저 위가 라면 스타디움입니다. 올라가 봅시다!!!!!

공사중 ——–

야………..

오늘 나한테 왜이러는건데.

뭐 그래서 할 수 없이 평범한 회전초밥집에 갔습니다.

정말 평범한 맛이더군요. 평범한 가격에.

한국 온 줄 알았지 뭐예요.

… 아니 그래도 이 맥주만큼은 평범하지 않아요 추릅.

일본 와서 맥주를 안먹는다는 것은 죄를 짓는 거라고 단언하는 바입니다

그 후 몇 개의 가게를 더 구경했지만, 오늘의 일정 자체가 뷰 포인트보다 쇼핑 위주의 관광으로만 짜여졌으므로 사실 큰 흥미를 끌기는 힘들었습니다.

슬슬 체력의 한계도 오고.. 날은 어두워 지고…
아무래도 이런 상태면 밤중의 나카스는 못 돌아볼 것 같습니다. 노약자 데리고 너무 걸었어요

마지막으로 일정에 없던 시장골목을 발견, 가 보기로 합니다.

쿠시다 신사 후문으로 나와서 캐널시티 입구로 들어가기 전에 바로 보이는 시장 입구인데, 이 쪽이 훨씬 재미있어 보였어요.

… 뭔가 재미는 있네요.

…언제 입는걸까 이런 옷은

오오 레이싱용 타이어를 장착한 자전거 발견. 비오는 날엔 못타겠군요.

돌아오는 길은 강가를 따라 호텔로 왔습니다.

지금보니 꽤 운치있군요. 더 여유가 있었다면 한가롭게 돌아다녔을텐데.

주유소에서 본 손세차 종결자. 얼마나 꼼꼼하게 닦는지 제 차도 맡기고 싶더군요.

호텔로 컴백했습니다. 도저히 밤에 나카스에 나갈 체력은 안되겠고, 다음 날 아침 일찍 일어나야만 해유…
TV는 별로 볼 것이 없을 것을 대비해서 노트북에 무한도전을 넣어 왔습니다. 매우 유용하더군요.

이렇게 첫 날은 지쳐 잠들었습니다.

아참. 화장실에 구비되어 있는건 이렇습니다. 샴푸, 컨디셔너, 린스, 칫솔과 치약, 면도기.
Face soap는 더블룸에는 있고 세미더블룸에는 없더군요. 흠 뭐지 빼먹은건가.

뭐 그렇게 첫날밤이 밝았습니다. 뭐야 2박 3일도 굉장히 빡빡하잖아.

두 번째 날 아침. 7시에 일어나 짐을 싸고 아침먹으러 나옵니다.

이건 호텔 조식권.

하나는 따로 구입해서 색이 달라유.

치산 하카타 호텔의 조식은 비지니스 호텔 치고 매우 괜찮아서 인기가 높습니다.

그래서인지 몰라도 아침에는 늘 줄을 선다고 하는군요.

쿠폰은 저 바구니에 넣습니다. 감시하는 사람같은건 없습니다.

비지니스 호텔의 조식은 일반적으로 아주 간단한 주먹밥과 간단한 빵 정도만 주곤 하던데,
여기는 그래도 그것보다 꽤 괜찮긴 합니다.

제법 양식과 동양식의 식단을 꽤 충실히 가지고 있어서, 만족하게 먹을 수 있습니다.

뭐 그래도 전 양식이지만…

식사를 하는 곳은 호텔 1층의 식당입지요.

낮이나 저녁에는 일반적인 식당으로 변신합니다.

그렇게 체크아웃을 하고, 하카타역 반대편의 로손 편의점 앞으로 갑니다.

온천가는 버스를 9시까지 타야 하니까요. 한 대밖에 없는데다가 예약까지 해 놓아서 놓치면 끝장입니다.

하카타역

하카타의 명물은 명란젓입니다.

온천에서 하루 묵고 돌아오는 곳도 여기이기 때문에, 선물은 돌아올때 사야겠습니다.

하카타역에서 본 ‘자전거용 무빙워크(?)’ 자전거만 저기에 실어서 올라오는 겁니다.

그렇게 하카타역을 통과해서 반대편으로 가면…

로손 편의점 (후쿠오카에서의 편의점은 로손이 꽉 잡았더군요 )
앞에 운젠으로 가는 안내 깃발이 있고, 우리를 기다리고 있는 안내 아가씨가 있습니다.

저기 보이는 버스가 타고 갈 버스.

이 아가씨도 ‘과다할 정도의 친절’ 스타일의 아가씨였습죠 (나쁘다는 말은 아니구요)
영어는 거의 못하면서도 활기차게 웃으며 가족들이랑 여행가느냐, 즐거운 시간을 보내라, 버스를 타고 얼마동안 가면 된다, 정말 웰컴이다 등등… 아주 말이 많은 아가씨더군요 ㅎㅎ

이것이 미리 예약해놓은 운젠가는 송영버스 (전세버스라는 의미 같이 쓰이는 듯 합니다만….)
티켓입니다. 사실 원래 여행사에 지불하는 비용에는 빠져있는 여행비이기도 합니다.

거리가 꽤 길기 때문에 4시간 동안 버스를 타고 가야 하고, 1인당 편도 1000엔씩이기 때문에 왕복 2000엔의 추가 지출이 들어가게 됩니다.

운젠이라는 곳 자체가 그렇게 한국 사람들에게 널리 알려져 있지 않은 곳이라 그런지, 손님도 매우 적고 여유있더군요. (하긴 유후인이 유명하지 운젠은 저도 처음 들어보긴 했어요)

이렇게 장장 편도 4시간이 넘는 버스여행길에 올랐습니다.

[#VIDEO|20110210230200011959631701.jpg|pds/201102/10/03/|mid|480|400|pds19#]

어제 돌아다닌데다가 아침에 일찍 일어나서 피곤한 기분에, 온가족은 잠이 들고 말았습니다.

몇 시간 자고 일어나 보니 여전히 달리는 중.

제펜애그는 이제 소용이 없습니다. 도심에서만 쓸모있지 도심을 벗어나면 무용지물.

신호가 잡히지 않습니다.

아 인터넷 금단현상 쩌네요 안절부절안절부절

어머나 고등학교 동창생의 사진이 걸려있네.

… 공부 열심히 해봐야 아무 쓸모없다는 교훈을 남겨준 친구랄까… (ㅋㅋㅋ)

그렇게 몇 시간을 달리고 나니, 웬 항구에 세워줍니다. 그리고 30분 이후에 차로 오라네요.

먹지 말라면서 새우깡을 나눠줍니다. 음? 이건 갈매기 먹이란 건데 그럼?

부둣가에 갈매기가 있나? 싶었지만 갈매기는 없습니다… 뭐지 이건? 분명 여행사에서는 버스타고 4~5시간 이랬는데?

일본어로 뭐라고 말을 하시는 기사양반이었지만 일본어는 하나도 몰라유.

뭐 설마 납치하기야 하겠어 라면서 휴게소에 들러 봅니다.

호오 현상범 사진이다. 저 위의 3명은 무슨 사건이길래 200만엔의 현상금이 붙어 있는 걸까요.

그렇게 돌아다니다 지도를 보니 으음???? 바다 앞이다!!!

이제 모든 것이 명확해 졌습니다. 이 버스는 바다를 건너갑니다.

그래서 새우깡도 나눠준 것이구요. 여행사에서는 전혀 언질도 안했던 사건이 일어났습니다.

마음이 편해졌으니 기념품을 둘러봅니다.

역시 선물 포장하나는 기가막히게 잘 해 놓는 일본 사람들.

오오 사카모토 료마상 아니신가.

배가 도착하고, 차는 드디어 페리 안으로 들어갑니다.

[#VIDEO|20110210230200011959951701.jpg|pds/201102/10/03/|mid|480|400|pds19#]

큐슈 / 후쿠오카 - 운젠 여행기 2

Tue, 08 Feb 2011 23:27:11 +0000

어느 새 지하철 한 정거장 만큼 걸었으므로, 후지사키 역에서 지하철 탑승했어유

생각보다 꽤 추워서, 어차피 일정에서 삭제했었던 모모치 해변은 갈 엄두도 나지 않더라고요

그래서 “힘들때의 경우의 수” 인 2,3번 패스 후 텐진의 지하상가를 목표로 고고싱.

지하철에는 겔럭시 탭이 있고

카라가 지배하고 있었습니다 (?)

아 이것이 한류?

텐진역에 하차. 좌우로 길게 지하상가가 만들어져 있습니다.

그리고 중간중간 백화점과 이어지는 통로가 만들어져 있고요. 지상은 백화점 가득이라는 말.

패션과 쇼핑에 관심이 있는 사람이라면 모를까… 가난한 여행객에게는 사치일 뿐이라고요.
랭킹랭퀸도 없어졌다고 하고, 뭐 사실 목적지 없이 떠돌고 있습니다.

그러다가 어머님이 좋아하신다는 명란젓을 좀 보자고 해서 들른 텐진의 가게.

뭐라고 읽냐 저거…

우왕 근데 외국인 손님이 가서 그랬는지 몰라도

영어는 잘 안통하지만 초 친절한 대접에, 원래 뭔가 쿠폰을 가져가야 할 수 있었던 것 같던 다트 게임을 해보라고 하더군요. 뭔가 기념품을 주는 것인듯.

… 어라?

200점짜리 가운데에 들어갔네요…
… 아니 뭐 그건 그렇다고 쳐도 왜 아주머니들이 더 뛸듯이 기뻐하는건데….

호들갑 스러워하는 점원분들이 뭔가 기념품 같은 것을 끊임없이 내 오더군요. 콩과자에 명란젓 시식에 오차에 김밥 (나중에 알았지만 그날이 절분이었다는 ) ..

그 외에도 아이들용 가면에 사탕까지 바리바리 챙겨주셔서, 정작 산건 명란젓맛 센베 과자 하나인데 (…)
얻은 것은 비닐 봉지 한 가득.

뭐 장사속인지 아닌지를 떠나서 이렇게 친절하게 맞아주는 직원들을 보니까 정말 부럽더군요. 우리나라에서는 보기 힘든 친절함이랄까.

겉이고 속이고를 떠나서 즐거웠습니다.
뭐 속으로는 안 친절하다라고 하는 분들도 계신데…
장사하는 분이 속으로는 친절하고 겉으로는 불친절해서 뭐하나요?
겉으로 친절하게 해 주셔야 손님은 당연히 기분좋은거지요

어쨌건 정말 친절하게 해주셔서 너무 기분 좋았어요 :) 고맙습니다.

참고로 절분이란 이런 것이더군요.
뭔가 무슨 방향으로 저 김밥을 한입에 먹고 어쩌고 하는 행사날이네요.

세쓰분(節分, せつぶん, または, せちぶん)은 일본에서 입춘 전날을 가리킨다. 해에 따라 다르지만, 대부분 2월 3일 전후이다. 이 날 밤에는 가정에서 ‘마메마키(豆まき)’라 하여 콩을 뿌리고, ‘귀신은 밖으로 복은 안으로’(鬼は外, 福は內)라는 말을 외치며 집안에 뿌린 콩을 자신의 나이만큼 주워 먹는 행사를 한다.

원래 절분(節分)은 계절의 시작을 가리키는 입춘,입하,입추,입동의 전날을 가리키나, 일본에서는 입춘 전날만을 명절로 쇤다.

출처 위키백과 http://ko.wikipedia.org/wiki/%EC%84%B8%EC%93%B0%EB%B6%84 -

지하를 돌아다니다 보니 슬슬 답답하기도 하고, 다리도 아프기 시작해서 지상에 올라왔습죠.

오오 이것이 텐진의 백화점 거리.

어마어마한 백화점들이 벽을 이루고 세워져 있네요

괜히 백화점 거리가 아니구나.

다이마루 백화점에 잠깐 들어가서 물건구경. 아 물론 구입하진 않았습니다.

쇼핑이 중심이 되는 시내 구경은 사실 금방 질리고 지쳐요. 그렇다고 뷰 포인트를 찾아다니기엔 좀 멀어서 노약자를 이끌고 가기 힘들고…

다이마루 백화점에 있던 뭔가 플라스틱 뚜껑으로 만들어 진듯한 곰돌이.

환경 관련해서 뭔가 행사하고 있던 것이었을까요?

어쨌건 여기까지 왔으니 드디어 100엔 버스의 영역까지 왔습니다.

날씨도 생각보다 좀 춥고 다리도 아파서 슬슬 호텔로 돌아가고 싶었지요.

어렵지 않게 100엔이라고 쓰인 정류장을 찾아 버스 탑승.

뒤로 탑승하는 일본 버스는 들어갈때 저렇게 정리권이라고 하는 표를 뽑아야 해유. 그럼 거기에 번호가 씌여져 있지유

그럼 저 앞의 전광판에 그 번호인 사람이 지금 내리면 얼마라는 것이 나오는데, 100엔 버스는 언제나 1번에 언제나 100엔이기 때문에 부담없이 탈 수 있다는 장점이 있지유. 아 내릴때는 앞으로 내리면 되요.

내리기 전에 벨 누르는건 기본.

확실히 버스여행이 재미있습니다.

야자수를 보아하니 남쪽에 왔다는 느낌도 들고…

오후 3시 체크인 시간에 맞춰 호텔에 도착.

맡겨 놓았던 짐을 찾고 체크인 해서 들어갑니다.

우핫. 역시 도쿄도 그렇고 여기도 그렇고. 일본 비즈니스 호텔은 정말 작아요. 이게 더블.

이게 조금 더 작은 세미더블

방은 정말로 침대가 4/5 입니다. 나머지 공간은 거의 없다시피 해요.

침대에서 돌아보면 바로 저게 보입니다

오밀조밀하게 있을건 다 있다는 느낌.

제펜에그 때문에 사용은 안했지만 인터넷 포트가 있네유. 역시 비지니스 호텔.

… 그치만 비지니스 호텔 직원이 영어를 거의 못한다는건 좀 문제가 있잖아..

호텔에서 간단하게 짐을 풀고 복장을 다시 재 정비한 다음 출발합니다.
목적지는 5번 쿠시다 신사.

쿠시다 신사의 뒷문으로 나오면 저 사진에 보이는 구름다리를 통해 캐널시티로 연결되어 있습니다.

그러니까 먼저 쿠시다 신사로 가야겠지요.

쿠시다 신사는 먼저 알아본 바에 의하면 명성황후를 시해한 칼이 보관되어 있다는 곳이라 합니다.

뭐 애국자는 아니라고 해도 좋게 보일 수는 없겠지요. 그냥 가서 세전함에 돈 넣는 행위 같은거 안하는 걸로 - 그냥 구경만 하는 걸로 - 소소하게 반항해 봅니당

쿠시다 신사 입구네요. 어라?

절분이라고 특이하게 해 놓았나 봅니다.

오늘은 기모노 입은 사람도 많이 돌아다니고 아저씨들도 옛날 옷 같은걸 입고 다니시는 분들이 많네요.

어쨌건 입으로 들어가 봅니다.

뭔가 사람이 많군요.

저기 있는 세전함에 돈을 넣고 삐걱대는 소리가 나는 줄을 잡아 당겨 기도를 하는 모양인데, 아까 얘기한대로 쌩까기.

점을 보고 점괘가 마음에 들지 않으면 액막이로 걸어 놓고 나온다는군요. 한국어나 영어도 지원하는 글로벌 점이네요.

삐그덕 삐그덕

[#VIDEO|20110209230200011950031701.jpg|pds/201102/09/03/|mid|480|400|pds18#]

이건 마쯔리때 들고 돌아다니는 가마인것 같군요.
여태까지 일반적으로 본 것보다 상당히 높습니다.

뭔가 연극을 하는 곳도 준비되어 있는 듯 합니다. 물론 기다려서 본다던가 하지는 않았지요.

한 번 휙 둘러보고 - 좀 더 세세하게 보고 싶었지만 갈 곳도 많고 배도 고프고 노약자들도 있어서… -

후문쪽으로 나옵니다.

그럼 바로 캐널시티로 갈 수 있는 구름다리가 나오지요.

캐널시티 입구에서 본 쿠시다 신사입니다.

캐널시티로 가는 구름다리를 건너가면 캐널시티로 바로 들어가게 됩니다.

우왕 원피스다

가족들이 와르르 오지만 않았다면 들어가서 하나하나 봤을텐데 말이죠 :)

캐널시티는 무엇보다 쇼핑몰 가운데를 가로지르는 운하와, 그 운하에서 시간마다 벌어지는 분수쇼를 보는게 제맛입니다.

자 분수쇼를 보시죠.

내가 오는 날 공사같은거 하지마 …

네 그렇습니다. 잔뜩 기대하고 갔던 분수쇼는 무슨… 여기도 그냥 그런 쇼핑센터로 전락하는 순간이었습죠. 쳇.

허탈한 마음을 안고 3부로 이어집니다,

Shader 제작 방법에 대한 정리

Tue, 08 Feb 2011 18:21:18 +0000

기본적으로 유니티는 3가지의 쉐이더 제작 방법을 지원한다고 볼 수 있습니다.
그걸 다시 크게 두 개로 나누면

Script로 제작하는 방법
CG로 제작하는 방법

이라고 볼 수 있겠는데요

Script로 제작하는 방법

방식은 대략 이런 방식으로 제작됩니다.

Shader “쉐이더 이름” {
Properties {
_Color (“Main Color”, Color) = (1,1,1,1)
_MainTex (“Base (RGB)”, 2D) = “white” {}
}

CG로 제작하는 방법

유니티에서는 이 CG로 짜는 쉐이더가 2개로 다시 갈라질 수 있는데요.

fragment (hlsl에서는 픽셀쉐이더) 로 짜는 방법
surface 로 짜는 방법
으로 갈라질 수 있습니다.

이 방법들은 스크립트로 짜는 쉐이더보다 훨씬 무궁무진한 기법을 만들 수 있다는 장점이 있습니다만, 동시에 제약도 가지고 있습니다.

2.1. fragment로 짜는 법

방식은 아래와 같습니다.

#pragma vertex vert_full
#pragma fragment frag_full

struct v2f {
float4 vertex : POSITION;
}

v2f vert_full (appdata_full v){
v2f_aniOnly o;
o.vertex = mul(UNITY_MATRIX_MVP, v.vertex);

return o;
}

half4 frag_full (v2f i) : COLOR{
return half4(0,0,0,1);
}
          ENDCG
           }
      }
}

이렇게 제작하면 2pass로도 제작할 수 있고, CG의 여러 가지 기능을 짜서 커스터마이징을 할 수도 있습니다.

2.2. surface 로 짜는 법

void surf (Input IN, inout SurfaceOutput o)
{
o.Albedo;
o.Normal;
o.Emission;
o.Gloss;
o.Specular;
o.Alpha;
}

#pragma surface surf BlinnPhong
#include “UnityCG.cginc”

struct Input {
}

void surf (Input IN, inout SurfaceOutput o)
{
o.Albedo;
o.Normal;
o.Emission;
o.Gloss;
o.Specular;
o.Alpha;
}
ENDCG
}
}

결론

때문에 아이패드나 다양한 기기의 호환, 빠른 속도를 위해서는 1번의 스크립트 방식으로,

2pass 이상 연산을 요하는 PC 전용의 반투명 (이펙트 등. 반투명은 어차피 디퍼드로 돌아가지 않기 때문에 ) 쉐이더는 2.1번 방식으로 - 엑박 등에도 가능할 걸로 보이지만 잘 모르겠..-

2pass는 할 수 없지만 가장 고급스러운 효과를 내기 위한 PC (혹은 고사양 게임기) 용 쉐이더(캐릭터 쉐이더등) 에서는 2.2 방식으로 쉐이더를 작성하는 것이 적합할 것으로 보입니다.

아이폰에서 게임을 빠르게 하기 위한 체크리스트

Tue, 08 Feb 2011 11:29:17 +0000

Simple Checklist to make Your Game Faster

Keep the vertex count below 10K per frame.* 한 프레임당 10,000 버텍스를 넘지 않도록 유지할것* Keep the number of different materials per scene low - share as many materials between different objects as possible.* 여러 메터리얼이 한 씬에 나오게 유지되면 느려짐 - 가능하면 다른 오브젝트간에 메터리얼을 공유할 것* Set Static property on a non-moving objects to allow internal optimizations.* 움직이지 않는 오브젝트는 Static 속성을 넣어서 자체적으로 옵티마이즈 할 수 있게 만들것* Use PVRTC texture compression where possible, otherwise choose 16bit textures over 32bit.* 가능하면 PVRTC 텍스쳐 속성을 사용하도록, 아니면 16비트 텍스쳐를 사용하도록* Use combiners or pixel shaders to mix several textures per fragment instead of multi-pass approach.* 쉐이더에서 멀티 패스를 사용하기보단 콤바이너나 픽셀쉐이더를 사용해서 여러 개의 텍스쳐를 섞도록. * Choose to use less textures per fragment.* 한 프레그먼트(쉐이더) 에서 가능한 적은 텍스쳐를 쓰도록. * Do not use dynamic lights when it is not necessary – choose baking lighting instead.* 필요없으면 동적 라이트를 쓰지 말도록 – 대신 라이트를 베이킹하도록. * Avoid alpha-testing, choose alpha-blending instead.* 알파 테스팅을 사용하지 말고, 대신 알파 블렌딩을 사용할 것.* Avoid fog (especially on newer than iPhone 3GS devices).* 포그를 피할것 (특히 아이폰 3GS 이후 모델들에서)* Learn benefits of Occlusion culling and use it to reduce amount of visible geometry and draw-calls in case of complex static scenes with lots of occlusion. Plan your levels to benefit from Occlusion culling.* 오클루젼 컬링의 이득을 배우시고 복잡한 고정물의 충돌물이 있는 씬에서 낮은 드로우콜과 적은 오브젝트를 위해 사용하라. 레벨디자인을 할 때 오클루젼 컬링에 맞게 계획하라* Use skyboxes to “fake” distant geometry. * 스카이박스를 ‘가짜의’ 원경으로 사용해라

http://unity3d.com/support/documentation/Manual/Optimizing%20Graphics%20Performance.html#iPhoneOptimizingGraphicsPerformance

AT2_Char_MainMetal 쉐이더 2.0 버전

Mon, 07 Feb 2011 15:53:50 +0000

AT2_Char_MainMetal 쉐이더는 이전의 쉐이더에서의 갈라짐 (seam) 현상을 해결하다가 나온 쉐이더입니다.

유니티 엔진의 노말맵에서의 갈라짐 (seam) 현상은 해결이 불가능한 것으로 보입니다. 지금까지 여러 문서를 뒤져보았고 각종 방법의 테스트를 해 보았지만 해결되지 않았습니다. (스승님도 포기)

테스트로 들어있는 프로젝트인 부트캠프에서도 마찬가지 현상이 나타났으며, 부트캠프에서는 이 문제를 교묘하게 안보이는 부분으로 배치하여 숨기고 있었습니다.
일단 이 문제는 노말을 넘길 때 월드 노말을 넘기지 않고, 탄젠트 노말을 넘겨주면 유니티에서 알아서 변환해서 노말맵을 만들어 준다는데 있었습니다. 탄젠트 노말을 넘겨주는 것 외엔 접근을 할 수가 없기 때문에, 따로 뭔가 건드릴 수 있는게 없었다는 거죠.

다리 안쪽이라던가 말이죠.

그치만 이 작업을 하다가 반사 쉐이더에서의 문제점이 발견되었습니다. 반사 쉐이더에서는 노말맵에서와 다른 메카니즘으로 동작하다보니 (노말맵은 로컬 노말을 넣어야 하는데 리플렉션은 월드 노말을 넣어야 하는…)

반사 쉐이더는 기존의 겜브리오처럼 계산을 하게 되어서 같은 문제점이 나왔습니다.
그것은 즉 좌우 대칭일때 나오는 문제.

이렇게 나오는 문제입니다. 첨엔 그냥 노말맵의 seam 현상 때문에 저렇게 보이나 했더니 알고보니까 반사의 위아래가 뒤집혀 있더군요. 웃긴건 좌우대칭 문제인데 결과물의 문제는 위아래 (Y축) 이 나온다는 것. 이 원인을 찾으려니 시간이 별로 없어서 그냥 결과주의로 가긔 ㅋㅋㅋ

스승님 말씀에 따르면 어떤 프로그래머는 버텍스 자체에 - 값을 넣어서 이 문제를 해결한다던가 한다는데 저는 그냥 쿨하게 UV 값을 인식해서 문제 해결. 지난번에 처리한 방법과 같지요. 그래픽 디자이너의 의도대로 만들 수 있다는 장점도 있고.

즉 이렇게 배치하기만 하면

이렇게 해결되도록 제작되었스빈다. seam은 여전히 있지만 눈에 덜 띄게 되었죠.

큐슈 / 후쿠오카 - 운젠 여행기 1

Mon, 07 Feb 2011 00:36:22 +0000

이틀 전부터 미리 싸둔 짐.
뭐 가까운 데니까 5인 가족 짐이라고 해도 가방 하나.

필요한거 있으면 간김에 사도 되고…

아침입니다. 아니 아침은 아니군요. 새벽 4시에 일어나서 5시에 출발했으니까.

6시까지 공항에 가야 해유. 힘내라 뉴카렌스.
아니 힘내야 하는건 밟아야 하는 나인 것인가

일단 한 15분 일찍 출발했으므로 늦어도 뭐 대충 되것다 싶었죠.
네비는 한 시간이면 간다고 하는군요.

아하하하 근데 실제 걸린 시간은 한 시간이 안걸렸슈

도착하고나서 주차대행에 차 맡기니 5시 반이야.
뭐 일찍 가서 등록하면 되것다 싶었는데

라운지가 6시 10분에 오픈해 OTL

8시 비행기라고 해도 6시 이후에 도착하세요 여러분.
5시 반에 가봤자 아무데도 열지 않습니다.
쳇

6시가 넘으니 게이트들이 하나 둘씩 열리고

2번 입국장 게이트 옆 로밍센터에서 예약해놓았던 인터넷 에그 수령

작년까지는 하루에 5천원으로 할인해줬다는데 올해는 하루에 만원.
요금은 나중에 핸드폰 요금에 포함됩니다.

내부에는 100볼트 코드랑 본체, USB 충전 케이블이 들어 있어유.
SSD 랑 비번이 적혀있는 스티커가 붙어있구요

슬슬 시간이 되니까 공항이 활기차지는군요. 면세점도 열기 시작하고.

탑승시간이 되었습니다. 비행기 사진따윈 안찍어유 이젠 ㅋ
뭐 한 두번 나가는 것도 아니고 (엣헴)

비행시간은 한 시간 반이 채 되지 않기 때문에 뜨자마자 기내식 받고 입국신고서 쓰면 시간이 다 갑니다.

아이들 기내식은 미리 신청해 놓았던 아동식. 이쁘다!

아동식은 이렇게 구성되어 있네요.
어차피 아침밥이라서 간단합니다만, 어른들 기내식보다 오히려 양이 많아 보입니다

어른들 기내식이 더 적슈 ㅋㅋㅋ
아침밥이니까 뭐 간단.

내륙을 통과하는 비행기라 그런지 산이 보이네요. 눈이 아직 안녹은 산들이.
아 이쁘다.

근데 아유 시간이 없어… 5명분 입국신고서랑 세관신고서랑 쓰고 기내식 먹자마자 내려간데…
국어능력 인증시험 보던때 기억나네요 ㄷㄷㄷ

어쨌건 도착했습니다. 후쿠오카 국제공항에 내려서, 국내공항으로 가는 셔틀버스를 타고 일단 국내선 공항으로 갑니다.

아아 일정과 한 치 어긋남이 없는 이 일정 (…어긋날게 뭐 있냐)
셔틀버스를 탄 순간부터 왼쪽으로 통행하는 차량에 어색함이 느껴지기 시작합니다.
우회전인데 왜 신호를 기다리는거야 … ㅋㅋㅋ

버스에서 내리면 저 앞에 지하철 입구가 보입니다. 뭐 지하철은 똑같으니까…
하카타역까지 두 정거장입죠

지하철 표는 이렇게 생겼습니다. 수이카 카드같은 교통카드를 이용할 수도 있지만 몇 번 타지도 않을거라…

개찰구를 한 번 통과하면 구멍이 뚫리네요
사실은 아이들 (소인) 표를 끊어도 됩니다. 모양도 거의 똑같고 (아래쪽에 소인이라고 씌여있는거 외엔)
지키고 있는 사람도 없어서 그냥 그렇게 가도 됩니다.
아래 표를 보시면 알겠지만 소아요금은 130엔으로 훨씬 싸거든요.

그 대신

개찰구 통과할때 삐약삐약 소리가 납니다 (ㅋㅋㅋㅋ)

하카타역에 도착해서 호텔로 가기 위한 방향으로.

하카타역의 명물이라는 크로와상집 포르(…노?) 델 미농
묘한 이름이로구만요.

뭐 먹어보지는 않았습니다. 별로 대단해 보이지 않아서..

거대한 하카타역입니다.
공사중이라는 포스팅을 몇 년 전에 본 것 같은데 아직도 공사중이네요…

오오 버스다 버스

전 100엔 버스 (관광객용 100엔 고정 순환버스) 만 저렇게 생긴 줄 알았더니
모든 버스가 저렇게 생겼구만요!!!!
100엔 버스를 탈때는 잘 봐야 합니다. 100엔이라고 씌여 있어야 해요

출근시간의 일본 아침은 생각만큼 따뜻하지는 않습니다.
한국하고 큰 차이가 없네요. 제주도 위치라서 더 따뜻하리라고 생각했는데.

어쨌던 대충 저 정도 걸어서

치산 하카타 호텔 도착. 하카타 역에서 한 5분쯤 걸리는 거리입니다.

체크인은 오후 3시. 지금은 아침 10시. 너무 이른 시간이죠.
다행히 호텔 바우처를 보여주면 짐을 맡아줍니다. 번호표를 주는데 잘 챙겨야죠.

짐을 맡기고 첫 목적지인 ‘니시진 시장’ 으로 출발.

다시 지하철을 타야 하므로 기온역으로 갑니다.

우왕 제펜에그 좋네요. 속도도 좋고 잘 잡힙니다. 도심을 벗어나면 어떻게 될 지 모르지만…
다른건 둘째치고 지도보면서 다니니 안심되유.

대신 공항에서 한국사람들이 웅성대더군요
“우와 일본 공항인데 쇼(Show) 가 잡혀! 연결해봐 연결해봐”
ㅋㅋㅋ

죄송합니다. 동시에 5명 접속은 가능하지만 비번은 못 가르쳐 드립니다.

니시진 역에 내려서 주위를 두리번 거려봅니다.
구글맵이 있으니 무섭지 않아유.

니시진 시장!
뭐 사실 큰 기대를 하고 가면 안된다고 하지요. 우리나라 시장을 기대하고 가면 안된다고.

우리나라 시장만큼 큰 재래시장이 아닙니다. 그냥 가게들 모여있는 곳 느낌.

가장 번화한 곳이 이 정도.
그래도 100엔 샵이나 잡화들을 구경할 수 있는 좋은 점이 있습니다.

빠징코 샵이 가장 많고 가장 화려했다는게 좀 문제…

한국에는 가든파이브 일본에는 니시진 파이브

자전거의 나라답게 자전거도 많고 특이한 악세사리도 많습니다.
그중에 인상깊은 2명 아기 탑승용 악세사리. 이건 뭐 유모차네요.

와 베스킨이다.

하지만 추워유…

유일하게 재래시장 같았던 생선가게입니다.

대충 둘러봐도 그다지 땡기는 건 없네유.

게다가 추워! 생각보다 추워! 누가 일본은 따뜻하댔어! (나)

돌아갈까 생각중 만난 모스버거.
아래 노랑색 길이 니시진 시장이고, 모스버거는 후지사키역 근처에 있습니다.

오오 모스버거다 모스버거.
드디어 벼르던 모스버거를 먹게 되는군요 야아아아

샐러드도 있고 스프도 있고, 메뉴는 롯데리아에 필적하게 많군요.

주문한건 세트 두 개에 샐러드와 스프.

다행히 영어를 조금 할 줄 아는 친절한 (그러나 험악한) 남직원 분이 계셔서 편하게 주문할 수 있었어유.

이건 샐러드와 토마토 스프. 뭐 괜찮네요.
단지 메뉴 하나마다 물 한잔이 나오는건 좀 웃기네요. ㅎㅎ

제가 선택한 음료수는 메론소다.
불량식품 맛이야!!!

주문한 버거는 스텐다드한, 직원이 추천해준 일반 햄버거와 피쉬버거.

맛은… 음…

오오오오오오오오

이래서 다들 모스버거 모스버거 했구나…!
패티나 야채의 맛도 물론 좋지만 무엇보다 빵이 다르네요 !
폭신폭신하고 부드러운 식감은 마치 갓 나온 크리스피 크림같은 질감이었습니다.
과연, 이거에 비하면 다른 햄버거들은 빵이 너무 뻑뻑해서 다른 재료를 죽이는 맛이었던 거네요.

두 번째 코스는 모모치 해번이나 야후돔을 패스하고 (춥고 다리아퍼요)
곧장 텐진 지하상가로 지하철을 타고 갔슴다.
아래의 표로 보면 1번 -> 4번으로 간거죠.

2부에 꼐속

설 맞이 후쿠오카 가족여행 (예고편)

Mon, 07 Feb 2011 00:34:14 +0000

이제 겨우 사진정리가 끝나가고 있네요. RAW로 찍어놓은 사진을 편집해서 익스포트 하는 도중에 0부 작성하기.

이번 여행은 첫 가족 해외여행 (온가족이 가는건 처음) 이었지유.
일단 노약자들이 많이 포함되어 있는지라 일정을 유동적으로 짜야만 했습니다.

비행기도 멀리 가는건 할머니때문에 좀 무리고, 그렇다고 국내는 싫고…
만만한건 역시 일본 후쿠오카… 아이와 어른과 노인이 모두 좋아하려면 온천이 포함된 자유여행…
그렇다고 가이드 따라가는건 죽기보다 싫기 때문에 자유여행으로…

그러자니까 역시 일본 자유여행은 저번 도쿄여행때 아주 좋은 인상을 받았던 여행박사로 선택했습니다.

뭐 섬세하게 선택할 상황이 아니었어요.

두 달 전에 미리 대기타고 기다린 끝에 예약완료.
그리고 떠나기 전날 가족들 앞에서 브리핑 완료하였습죠.

이 일정을 기본으로 하되 노약자들의 상태를 봐서 중간중간 삭제한다… 라는 방식이었습니다.
결론부터 얘기하면 “예상대로 되었습죠”

동국대 BCI 감수보고서

Mon, 31 Jan 2011 23:09:19 +0000

프로세스의 정렬

현재 BCI 게임 탬플릿 저작 도구와 BCI 기반 응용 코드 생성기 두 부분으로 나뉘어, 저작도구는 인지 뉴로피드백 전문가가, 코드 생성기는 저작도구 사용 게임 기획자가 담당하도록 이원화 되어 있습니다. 이는 뉴로피드백 전문가의 독립성과 권한을 대폭적으로 강화해 주는 기능을 가지게 되는 특성이 있는 반면, 일방적인 한 방향의 프로세스로 인해 프로젝트가 완료될때까지 초기 설계자의 중간 피드백이 불가능하다는 단점이 존재하며, 게임 기획자의 역할이 제한되거나 모호해지는 상황이 도출될 수 있게 됩니다.

또한 뉴로피드백 전문가에게 적합한 템플릿과 게임 기획자에게 적합한 템플릿은 서로 구분되어야 함이 당연함에도 불구하고 사실상 같은 템플릿을 공유하게 함으로써 뉴로피드백 전문가가 게임 개발자의 수준까지의 지식을 가지고 있어야 하는 결과가 나오게 됩니다.

그러므로 이 해결책은 크게 두 가지로 볼 수 있는데, 첫째는 뉴로 피드백 전문가가 인지할 수 있는 수준의 1차 탬플릿을 독립적으로 설계하며, 이를 참조하여 게임 기획자가 게임으로 만들어 질 수 있는 게임요소 탬플릿을 첨삭하여 게임을 만들 수 있게 하는 것입니다. 또는 하나의 저작도구를 가지고 저작도구 사용 게임 기획자와 유로피드백 전문가가 지속적으로 공유하면서 동시에 작업 가능하게끔 툴을 개선하는 것도 좋은 방법입니다.

중간 확인 / 점검도구 필요

현재의 저작도구는 게임이 개발되는 최초 시점인 뉴로피드백 전문가의 의견취합으로부터 시작하여 게임 완성 시점까지 중간 검수 혹은 테스트 도구가 전혀 존재하지 않습니다. 게임을 만들기 위해서는 빠른 초기 결과물 도출과 즉각적인 수정/반영이 이루어져야 하고, 이를 꾸준히 반복하여 초기버전이 완성되었을 때 이를 게임으로 제작하기 시작하여야 합니다.
그러므로 이 툴에서는 게임 기획자의 레벨에서 아주 간략한 수준의 작동을 점검할 수 있는 플레이 버전 빌드가 가능하도록 수정되어야 합니다.

PT의 방법 개선

엔지니어 기반의 현재 PT 방법으로는, 각 단계 (저작도구 - 코드생성 - 게임 제작) 의 관계가 전혀 연관성 있게 보이지 않으며, 이해하기도 힘든 상황이라고 볼 수 있을 것입니다. PT에서는 이 3단계를 각 단계별 담당자의 시각으로 바라볼 수 있도록 이야기를 만들어 가는 것이 필요하며, 추상적인 코드와 저작도구를 먼저 보여주는 것 보다 구체적인 결과물인 게임을 먼저 보여주고 나서 추상적인 메세지들을 보여주는 방식으로 PT를 이끌어 간다면 - 물론 최종적으로 다시 구체적인 결과물을 보여주어야 합니다 - 보다 각 단계별 연관성이 명확해 보일 것입니다.

모바일용 쉐이더 정리

Mon, 31 Jan 2011 17:28:10 +0000

Mobile/Background

테그의 큐가 배경으로 되어 있어서, 오브젝트들보다 무조건 먼저 찍혀서 다른 오브젝트들에 가려집니다.
Z 값을 쓰지 않고, 오직 텍스쳐 한 장만 딸랑 쓰게 됩니다.
배경용에 적합하며, 매우 가볍습니다.
빛 연산은 되지 않습니다. 알파채널도 사용 불가합니다.

Mobile/Diffuse Detail

빛의 영향을 받습니다.
알파채널은 사용할 수 없습니다.
디퓨즈맵과 디테일맵 두 장의 텍스쳐가 곱셈 연산되며, 두 번째 텍스쳐인 디테일 텍스쳐는 두 배 강하게 연산됩니다.
빛 연산이 들어가고 텍스쳐가 두 장이 들어간 만큼 모바일용으로는 조금 무겁습니다.

Mobile/Legacy/Lightmap/Lightmap AlphaTest

빛의 영향을 받을 수 없습니다. 라이트맵용이니까요.
알파채널은 알파 테스트로 사용할 수 있습니다. ( 아이폰에서는 알파 테스트가 더 느리다던데?)
일반 텍스쳐와 라이트맵용 텍스쳐 두 장을 넣어야 합니다. 두 장이 곱셈 연산이 됩니다.

Mobile/Legacy/Lightmap/Lightmap Only

빛의 영향을 받을 수 없습니다. 라이트맵용이니까요.
알파채널은 사용할 수 없습니다.
일반 텍스쳐와 라이트맵용 텍스쳐 두 장을 넣어야 합니다. 두 장이 곱셈 연산이 됩니다.

Mobile/Legacy/Lightmap/Reflective

빛의 영향을 받을 수 없습니다. 라이트맵용이니까요.
알파채널은 사용할 수 없습니다. 대신 알파채널은 반사 마스크로 사용됩니다.
2 Pass 를 사용해서 제작이 되기 때문에 다소 무겁습니다.
반사되는 이미지는 큐브맵이 아닌, 일반 이미지입니다.

Mobile/Particles/Additive Culled

이펙트를 위한 쉐이더입니다.
2side가 아닙니다.
Screen 으로 연산이 됩니다. (SrcAlpha One)
라이트 연산은 당연히 없고 Z 값도 쓰지 않습니다.
알파 블렌딩으로 동작합니다.
이 쉐이더는 또한 두 개로 제작되어 있어서, 성능이 보장되는 그래픽 카드일 때에는 Tint Color로 칼라를 조절할 수 있고, 낮은 성능의 그래픽 카드일때에는 그냥 텍스쳐만 screen으로 나오게 됩니다. (낮은 성능의 그래픽 카드일때에는 파티클 칼라의 영향을 받지 못합니다.
)

Mobile/Particles/Multiply Culled

이펙트를 위한 쉐이더입니다.
2side가 아닙니다.
Multiply 으로 연산이 됩니다. (Zero SrcColor)
낮은 성능의 그래픽 카드일때에는 파티클 칼라의 영향을 받지 못합니다.
기본적으로 Mobile/Particles/Additive Culled 와 비슷합니다.

Mobile/Transparent/Vertex Color

라이팅의 영향을 받습니다.(제가 가지고 있던 쉐이더에는 꺼져 있던데, 뭔가 잘못되었던듯. 꺼지면 의미가 없습니다)
버텍스 단위의 스페큘러가 생깁니다.
알파 블렌딩을 사용합니다.
Main Color의 알파 채널 조정으로 알파를 조절할 수 있습니다.
스페큘러 마스킹은 알파 채널입니다.
빛 계산으로는 좀 무거운 편의 쉐이더입니다.

Mobile/Vertex Colored

라이팅의 영향을 받습니다.(제가 가지고 있던 쉐이더에는 꺼져 있던데, 뭔가 잘못되었던듯. 꺼지면 의미가 없습니다)
알파를 사용하지 않습니다.
뭔가 좀 이상한 쉐이더네요. 스페큘러 계산이 없는데 스페큘러 색상 메뉴가 있습니다.
Main Color나 Emmisive Color는 잘 작동합니다.

여러 제약 사항은 있지만 그래도 기본적으로 될 건 다 되네요.
테스트는 여기까지. 아무래도 테스트 장비가 있어야 할 듯 합니다.
된다고는 하는데 진짜 되는지 테스트를 할 수가 없어서..

SimpleReflection Shader

Mon, 31 Jan 2011 11:10:02 +0000

실제로 이 그래픽 카드에서는 작동 안됨.

// Upgrade NOTE: replaced ‘glstate.matrix.mvp’ with ‘UNITY_MATRIX_MVP’

Shader “SimpleReflection Shader” {
Properties {
  _NormalMap (“Normal Map”, 2D) = “white” {}
  _BumpScale (“Bump Scale”, Range(0.01,10.0)) = 1
  _SkyCube (“Sky Cubemap”, Cube) = “_Skybox” { TexGen CubeReflect }
}
#warning Upgrade NOTE: SubShader commented out; uses Unity 2.x style fixed function per-pixel lighting. Per-pixel lighting is not supported without shaders anymore.
/*SubShader
{
  // Pixel lights
  Pass
  {
   Name “BASE”
   Tags { “LightMode” = “Pixel” }
   Lighting On
   Cull Off

   CGPROGRAM
   #pragma vertex vert
   #pragma fragment frag
   #pragma fragmentoption ARB_fog_exp2
   #pragma fragmentoption ARB_precision_hint_fastest

   #include “UnityCG.cginc”
   //#include “AutoLight.cginc”

   uniform samplerCube _SkyCube;

   uniform sampler2D _NormalMap;
   uniform float4 _NormalMap_ST;

   uniform float _BumpScale;

   struct v2f
   {
    float4 position : POSITION;
    float4 uv : TEXCOORD0;

    float3 viewDirWS : TEXCOORD2;
    float3 normalWS : TEXCOORD4;
    float3 tangentWS : TEXCOORD5;
    float3 binormalWS : TEXCOORD6;
   };

   v2f vert ( appdata_tan i )
   {
    v2f o;

    o.position = mul( UNITY_MATRIX_MVP, i.vertex);
    o.uv.xy = TRANSFORM_TEX( i.texcoord, _NormalMap );

    // ObjSpaceViewDir give us the viewDir in ObjSpace
    // so we transform it to world space
    o.viewDirWS = mul( _Object2World, float4( ObjSpaceViewDir( i.vertex ), 0) ).xyz;

    // we transform the normal and tangent in world space as well
    o.normalWS = mul( _Object2World, float4(i.normal,0) ).xyz;
    o.tangentWS = mul( _Object2World, float4(i.tangent.xyz,0) ).xyz;

    // we cross product directly from world space vectors so we save one transform
    float3 binormalWS = cross( o.normalWS, o.tangentWS ) * i.tangent.w;
    o.binormalWS = binormalWS;

    return o;
   }

   float4 frag( v2f i ) : COLOR
   {
    // get the normal from our Normal Map
    float3 normal = tex2D( _NormalMap, i.uv.xy ).rgb;
    normal = normal.rgb * 2 - 1; // transform it from 0,1 to [-1,+1]
    // we scale only x & y then normalize it
    normal = normalize(normal* float3(_BumpScale,_BumpScale,1)) ;

    // transform the normal by our world space tangent space
    // this gives us a normal in world space
    float3 normalWS = normal.x * normalize(i.tangentWS);
    normalWS += normal.y * normalize(i.binormalWS);
    normalWS += normal.z * normalize(i.normalWS);
    normalWS = normalize(normalWS);

    // always normalize vector coming from the vertex shader
    float3 viewDirWS = normalize(i.viewDirWS);

    // we use -viewDir because viewDir goes from the current point to the camera
    // and we need the inverse of this vector to compute the reflection vector
    float3 reflectVec = reflect( -viewDirWS, normalWS );

// reflectVec being in world space, we can now sample the cube map
float4 reflectionColor = texCUBE( _SkyCube, reflectVec );

    // camera facing lighting
    float kD = dot( viewDirWS, normalWS);

    return float4(reflectionColor.rgb * kD, 1);
   }

   ENDCG
  }
}*/
}

DistortionTexture 쉐이더

Thu, 27 Jan 2011 13:20:04 +0000

Normal을 이용해서 텍스쳐를 흩어버릴 수 있게 하는 쉐이더.

파워포인트 2010 템플릿

Thu, 27 Jan 2011 09:17:23 +0000

http://office2010.microsoft.com/en-us/templates/CT010336615.aspx

165개의 파워포인트 2010 용 무료 템플릿

Reflect Bump Spec Detail Shader

Wed, 26 Jan 2011 18:17:32 +0000

이건 공개해도 될 내용으로 검열완료.

쉐이더 3.0 전용의 쉐이더. 알파는 사용하지 않고 A 텍스쳐와 B 텍스쳐를 B 텍스쳐 알파로 마스킹해서 멀티 합성해 줍니다.
큐브맵과 스페큘러가 적용되어 있고 마스킹은 A 텍스쳐의 알파.
노말맵도 적용되어 있습니다.

재미있는건 이 엔진에서는 UV의 이름으로 세컨드 채널을 구분하는군요. ㅋㅋ
uv_Texture uv_Texture2 하면 uv 1채널로 다 나오구요
uv_Texture uv2_Texture2 해줘야 2번 채널이 활성화됩니다 :)

노말 연산도 지 멋대로고 하여간 웃김 ㅋㅋ

리플렉션 작업

Wed, 26 Jan 2011 09:25:36 +0000

별 생각없이 ‘대충 이쁘면 되지 뭘’ 이란 마인드로 제작된 리플렉션.
뭐 그런대로 대충 이쁘긴 한데 뭔가 좀 큐브맵 각도가 이상하다.
쉐이더가 이쁘다기 보다 모델링이 잘되어서 이쁜 느낌.
반사되는 모습이 꼭 로컬좌표계의 노말맵인것 같은…
이상하게 유니티는 월드변환 노말맵 단계가 없어도 제대로 노말이 표현되어서, 그냥 써온것이 화근이었다.

그래서 노말 계산을 아예 수동으로 일일히 받아봐 계산을 때려줬다.
애석하게도 버텍스 쉐이더에서 바이노말 연산을 하고 싶었는데 out 에서 하나 더 나가면 오버플로우 나서 실패.
할 수 없이 부하를 각오하고 픽셀쉐이더에서 계산.

vertex:vert

struct Input
{
float3 normalWS : TEXCOORD3;
float3 tangentWS : TEXCOORD4;
};

void vert (inout appdata_full v, out Input o)
   {
  o.viewDirWorld = mul( (float3x3)_Object2World, -ObjSpaceViewDir( v.vertex ) ); //same to upper line
  // we transform the normal and tangent in world space as well
  o.normalWS = mul( _Object2World, float4(v.normal,0) ).xyz;
  o.tangentWS = mul( _Object2World, float4(v.tangent.xyz,0) ).xyz;
  //~ o.binormalWS = binormalWS;  이걸 여기서 계산하면 오버플로우 OTL
  }

void surf (Input IN, inout SurfaceOutput o)
{
half4 NormalTex2 = tex2D (_BumpMap2, IN.uv_BumpMap2);
o.Normal = normalize(half3(NormalTex2.rg,1)*2.0f-1.0f);

  // we cross product directly from world space vectors so we save one transform
  float3 binormalWS = cross( IN.normalWS, IN.tangentWS ) ; // 그래서 여기서 계산

  // transform the normal by our world space tangent space
  // this gives us a normal in world space
  float3 WorldNormal= o.Normal .x * normalize(IN.tangentWS);
  WorldNormal += o.Normal .y * normalize(binormalWS);
  WorldNormal += o.Normal .z * normalize(IN.normalWS);
  WorldNormal= normalize(WorldNormal); // 여기서 합쳐줌

//Reflect——————————————————
  float3 reflectVec = reflect( IN.viewDirWorld ,WorldNormal); // 여기서 씀.
  half3 ReflectTex = texCUBE (_Reflection, reflectVec ).rgb;
  ReflectTex *= NormalTex2.b;
  Albedo = lerp (ReflectTex*2, ReflectTex * MainTex.rgb, 1-_RefTexDimmer ) +MainTex.rgb;

결과는 확실히 이쪽이 이쁘다. 반사가 제대로여.

AT2_Char_Main / MainMetal 쉐이더 제작

Tue, 25 Jan 2011 18:35:42 +0000

AT2_Char_Main 쉐이더 2.0 버전입니다.

변경된 내용은 다음과 같습니다.

염색 기능이 최적화 되었습니다. 기능은 같지만 코드가 단 두 줄 ! 굉장히 단순해 졌습니다.
디퍼드 렌더링 모드에서도 림라이트가 완벽히 작동합니다.
디퍼드 렌더링 모드에서도 알파 테스팅이 완벽히 작동합니다.

현재 남아있는 디퍼드 렌더링과 포워드 렌더링의 다른점은, 2번째 스페큘러가 추가되지 않는다는 것과, 스페큘러의 넓이값이 좀 다르다는 것입니다. 큰 문제는 되지 않으므로 넘어갑니다.

노말 맵 갈라짐 현상은 현재 시속적으로 순호스승님이 보고 계십니다. 성공가능성은 별로 높지 않다는게 문제 (…)

AT2_Char_MainMetal 쉐이더 완성
메탈 재질을 표현하기 위한 쉐이더입니다. 기본적으로 캐릭터 쉐이더를 베이스로 하고 있기 때문에, AT2_Char_Main 쉐이더의 모든 기능을 그대로 사용할 수 있습니다. 거기에 반사재질까지 추가된 형태로, 현재 나온 쉐이더중 가장 묵직한 쉐이더가 될 것입니다. 그러므로 자주 쓰는 것은 당연하게도 금지입니다. 꼭 필요한 금속재질에만 사용해 주세요.

리플렉션 텍스쳐로는 큐브맵을 사용하고 있습니다.
독특한 점은, 그 아래 있는 Reflection Texture Contrast 인데, Contrast 라기 보다는 리플렉션 강도처럼 움직입니다.
그 예는 아래에서 볼 수 있습니다.
이해를 돕기 위해 기본 텍스쳐는 검은색으로 만들어져 있습니다.

Reflection Texture Contrast 가 낮은 상태입니다. 반사 재질이 약해지면서 기본 텍스쳐가 강하게 나옵니다.
나머지 옵션들은 Char / Main 쉐이더와 동일하므로 조작하기 어렵지는 않습니다.

Reflection Texture Contrast 를 중간 정도의 옵션으로 했을때 입니다. 기본 텍스쳐와 약하게 섞인 느낌을 볼 수 있습니다. 일반적 금속에 어울립니다. 또한 마모셋 스타일의 라이트 때문에 근육이나 바지의 아래 부분이 어둡게 되는 효과까지 볼 수 있어 더욱 리얼하게 보입니다. 이 기능을 적절히 사용하시기를 추천합니다. 특시 마모셋 스타일의 라이트 조정옵션에서 GLight Top 색을 바꾸면 반사 색이 달라 보이는 느낌까지 줄 수 있습니다.

Reflection Texture Contrast 를 가장 높은 옵션으로 했을 때입니다. 마치 수은과 같이 반짝이며, 이대로라면 블룸과 반응하여 하얗게 날라갈 것입니다. 적절하게 사용하시길 바랍니다.

마스킹은 스페큘러 마스킹과 동일하게 작동됩니다. 즉 노말맵의 블루값입니다.
염색도 노말맵의 알파로, 동일하게 작동됩니다. 염색과 리플렉션이 섞이는건 현재로썬 별로 추천하지 않습니다. (요청 들어오면 섞어지게 재 작업 해드리겠습니다) 어렵거나 무거워 지는 것은 아닙니다.

현재 쉐이더 3.0 에서만 돌아가도록 제작되어 있는 관계로, 그보다 아래로 떨어뜨리면 그냥 Specular가 나오게 됩니다.
필요하다면 염색만 작동하는 2.0 이하 쉐이더를 추후 제작하여 추가할 수 있게 되어 있습니다.

Nvidia graphics processing units : 그래픽 카드 성능표

Tue, 25 Jan 2011 04:37:50 +0000

http://en.wikipedia.org/wiki/Comparison_of_Nvidia_graphics_processing_units

일단 원하는 내용은… Geforce 7600 GT 와 6600 이므로.
메가(Mega : 100만) 기가( Giga : 10억) 테라(Tera : 1조)

일반적으로 퍼져있는 6600 GT를 최소로 봤을때

vertex 처리 속도는 초당 0.375 GV (기가 버텍스?) …
1기가를 10억개라고 보았을 때, 초당 3억 7천 500만 버텍스 처리 가능.
30프레임이 나와야 하므로 0.375 를 30으로 나누면 초당 처리할 수 있는 버텍스는 0.0125 기가 버텍스.
즉 1,250만 개의 버텍스( 12.5M , 12500k Vertex ) 를 1/30로 처리할 수 있다는 말입니다.

그리고 무식하게 3개의 버텍스가 1개의 폴리곤을 만든다면, 12,500,000/ 3 = 4,166,666
즉 416만 트라이앵글을 처리할 수 있다는 말입니다. 하지만 보통 스트립 처리하게 되면, 심한 경우 버텍스 1개당 폴리곤 1개가 생성될 수도 있으므로 1,000만 폴리곤 내외까지는 허가할 수 있으리라고 보이는군요.
(10M,10,000k Tris)

픽셀은 2기가 픽셀을 초당 처리 가능. 20억개이므로 약 6천7백만 픽셀을 1/30에 처리 가능.
픽셀 처리는 다양한 요소가 있습니다만, 특히 알파 블렌딩과 해상도에 영향을 많이 받는 편입니다.
그러므로 뭐 여기까지. (67M Pixel)

텍스쳐는 4기가를 1초에 처리 가능. 그렇다면 0.133 기가를 1/30초에 처리 가능.
약 133 메가 처리가 가능합니다. (133.3M texture)

즉 6600에서의 최소인 그냥 6600으로 계산해 보면,
Vertex : 0.225 GV
Tris :
Pixel : 1.2GP
Texture : 2.4G
이므로

7600 GS로 계산해 보면

7600 GT 80nm 로 계산해 보면 (숫자 높은것)

참고
설명이 잘 된 zupet 님 글

http://www.gpgstudy.com/forum/viewtopic.php?topic=2800

안녕하세요. 매크로 없는 메비~랍니다.

Vertex Cache란 그래픽 카드의 GPU 내부에 있는 자그마한 캐쉬로 Vertex 정보들을 일정기간 동안 보관해주는 영역입니다. 이 부분은 그래픽카드마다 크기가 다른데 적게는 4개많게는 수십개의 Vertex 정보를 LRU 방식(을 주로 쓴다고 아네요.)으로 관리하는 캐쉬입니다. 그래서 최근에 접근했던 Vertex 정보를 메모리에서 읽어오지 않고 바로 캐쉬에서 불러다 쓰도록 해서 메모리 접근이나 TnL에 대한 패널티를 최소화 시킬 수 있는 부분이죠.

Strip 와 비슷한데 Strip는 이전에 읽었던 2개의 Vertex를 활용해서 1개의 추가 Vertex 정보만 읽어오면 새 폴리건을 그릴 수 있게 되는 것에 반해서 최적화가 잘되었을 경우 이러한 것보다 더 최적화가 되어서 1개의 삼각형당 0.7~0.8개의 Vertex 정보만 읽어오고도 그릴수도 있게 됩니다. 어떻게보면 신기한데 꽤 효과가 있고 그러한 것이 Optimized Mesh론 예제로 DX 예제에 나와 있습니다. (항상 적용되는 것은 아니지만 효과는 있죠.)
http://research.microsoft.com/~hoppe (에서 Mesh Optimization 참고)

Fill Rate 란 그래픽카드의 픽셀 채우기 능력을 가르킨다고 보면 정확합니다. 저는 여기서 조금 더 확장해서 Fill Rate 의 한계를 주는 여러가지 요소를 모두 가르키는 용어로 쓰고 있지만 일단 Fill Rate란 그래픽 카드가 비디오 메모리에(Target Surface에) 얼마나 많은 점을 찍을 수 있느냐의 수치를 가리킵니다.

가령 폴리건이 적은 경우에도 화면을 채우는 면적이 많을 경우 Vertex 정보를 처리하는 것보다 픽셀을 그리는 능력에서 파워가 부족하게 됩니다. 고급 그래픽 카드의 경우는 이러한 픽셀을 그리는 능력(Fill Rate)이 뛰어나고 메모리 대역폭이 넓기 때문에 크게 신경을 쓰지 않고 빠른 3D 출력이 가능하지만 성능이 떨어지는 그래픽 카드들의 경우 이러한 수치가 급격히 낮아집니다.

가령 Texture의 크기에 따라 Fill Rate가 크게 영향을 받을 수 있습니다. 작은 삼각형을 그리는데 큰 텍스쳐(512 * 512)를 사용해서 축소해서 그림을 그리게 되면 20 픽셀짜리 삼각형 하나를 그리기 위해서 그래픽 카드는 1MB 짜리 텍스쳐를 랜덤하게 접근하여 데이터를 읽어오게 됩니다. 일단 메모리는 Random Access 지만 Random 하게 접근하기 위해서는 상당한 패널티가 주어질 수 있습니다. 따라서 작은 삼각형이 1MB 의 공간을 랜덤하게 접근해서 데이터를 읽어올 경우 20픽셀어치의 텍스쳐만 필요하다고 하지만 경우에 따라서는 1MB 의 텍스쳐 데이터를 모두 읽어올 수도 있습니다.

또 그 반대의 경우로 화면에 어떤식으로 데이터를 접근하냐에 따라 크게 달라질 수 있습니다. 가령 알파 블렌딩을 적용한 1600 * 1200 짜리 텍스쳐를 통채로 화면에 덥어 씌운다고 생각해봅니다. 그럼 일단 1600 * 1200 만큼 화면 데이터를 읽어와야 하고(7.68MB) 알파 블렌딩을 한 다음 다시 그만큼 데이터를 써 넣어야 합니다. 텍스쳐는 1MB 짜리를 읽어서 1600 * 1200에 전부 덮어 씌운다고 하면 7.68 * 2 + 1 = 16.36MB/Frame 만큼의 데이터가 메모리를 통해서 읽고/씌여져야합니다.

화면 전체를 덥는 텍스쳐는 고작 2개의 삼각형이지만 16GB/s의 대역폭을 갖는 그래픽 카드에서 저러한 작업을 시키면 무려 1ms의 시간을 저 한장을 씌우는데 사용하게 됩니다. 만약 반투명을 잔뜩 쓴 이펙트를 화면 전반에 걸쳐서 덕지덕지 붙이게 되면 이펙트만으로 프레임이 급속도로 떨어지게 됩니다. 이러한 경우가 자주 있는 것은 아니지만 캐릭터가 마법을 쓰거나 스킬을 쓸때 전 화면이나 큰 면적의 알파 블렌딩을 두세겹씩 겹쳐쓰는 경우는 자주 볼 수 있습니다. 또한 전화면 파티클 같은 경우도 같은 결과가 나오겠죠.

조금 일반적인 예를 들어보자면 10* 10짜리 공간을 채우는 2개의 삼각형들로 화면을 가득 채운다고 생각해 봅니다. 그럼 1600 * 1200 짜리 화면을 채우기 위해서는 38,400 개의 삼각형이 필요하게 됩니다. GeForce FX 5950 의 경우 3.8GTexel/s 이므로 Fill Rate로 계산을 하면 이러한 작업을 초당 1979 번 정도 수행할 수 있습니다. (빠르다 -_-a ) 그런데 그에 비해서 이러한 화면을 그리는데 들어가는 삼각형은 약 76 M Tri/s 정도가 됩니다. Strip 로 전부 그려진다고 하면 거의 1 Vertex/Triangle 이 되고 (최적화될 경우 그것보더 덜 필요하죠) 그럼 76MVertex/s 가 되는데 5950의 Vertex 처리 능력은 356M Vertex/s 나 됩니다. 그렇다면 Vertex 처리기의 약 1/5의 성능만을 쓰고 Fill Rate에 제한을 받아버리는 결과가 나옵니다.

Fill Rate는 생각보다 민감한 문제입니다. 고화질 텍스쳐를 위해서 텍스쳐 해상도가 늘어나고 많은 데이터에 접근하게되면 데이터에 접근하는 만큼 대역폭. Fill Rate가 제한을 받게 되니까요. Z 버퍼에 접근하는 것도 대역을 소모하게 되고 텍스쳐 한장한장이 대역폭을 일정량 이상 먹게 되니 요즘의 3D는 삼각형 숫자보다는 Fill Rate 쪽에 더 민감하다고 생각해야 합니다.

근데 1600*1200 이면 1,920,000 픽셀이고, 한 픽셀당 24비트라고 하면 46,080,000 비트가 되고,
이걸 메가로 환산하면 5.493164 메가바이트(MB) 가 되지 않나요? 어째서 7.68 메가가 되지요?
알파 블렌딩이니까 32비트로 계산해야 하는걸 잊었었네요 :) 감사합니다 JOHN_DOE 님.

무한도전 플레이어

Sat, 22 Jan 2011 09:58:47 +0000

http://www.mudoplayer.net/

뭐냐 이건 . ㄷㄷㄷㄷㄷ

새로운 캐릭터 쉐이더 베타버전 공개

Fri, 21 Jan 2011 17:49:34 +0000

일단 공유 시스템이 확정될때까지는 여기 올리기로 했으므로…

새 버전의 캐릭터 쉐이더입니다. 반드시 쉐이더 3.0 이상이 되어야만 작동합니다.
#pragma target 3.0 을 선언 안하고 작업하니까 arithmetic instruction limit 제한에 걸려 버리네요.
수식이 너무 많아서 2.0 에서는 처리하지 못한답니다 ㅎㅎㅎ

이 쉐이더는 지금까지 만들어진 쉐이더중 가장 고급 연산을 하고 있는 쉐이더입니다. 하지만 알파 블렌딩은 지원하고 있지 않기 때문에 이펙트 쉐이더보다는 가벼울지도 모르겠습니다 (ㅎㅎ)

반드시 캐릭터, 특히 주인공 캐릭터 용으로 사용해 주시기 바라겠습니다. 일단 몬스터나 NPC에도 사용하셔도 상관없지만, 만약 부하가 걸린다면 몬스터나 NPC 쉐이더는 따로 만들도록 하겠습니다. 즉 캐릭터에는 아직까진 무조건 사용하셔도 된다는…

장팟장 취향에 따라 SSS 나 하프 렘버트는 집어넣지 않았습니다. 노말이 죽는다고 별로 안 좋아해서 (…)
대신 노말이 잘 보일 수 있게끔 겜브리오 시절에 만들어 놓았던 “마모셋 스타일의 노말 처리” 기능이 들어가 있습니다.
덕분에 최종 쉐이더는 이런 모습이 되었습니다. 특징

기본으로 내장되어 있는 Bumped specular 쉐이더와 비교해 보겠습니다. 팔은 아닙니다 몸통만 비교해 주세요 :)

————————————————————————————
a: 기본적으로 화면 전체에 적용되는 Ambient Color는 계산량이 빠르지만 모델링의 가장 어두운 부분의 색상을 결정해 버리는 단점을 가지고 있습니다. 때문에 그늘이 진 곳에서는 열심히 노말맵을 만들었더라도 노말맵이 전혀 나타나지 않는 현상이 발견되어 집니다. 노말맵은 빛의 음영이 있어야 보이기 때문이지요.

때문에 제작된 쉐이더에서는 엠비언트 큐브를 통한 돔라이트 처리처럼 처리되었습니다. 물론 아주 간단한 2가지 색상의 반구조명 방식이며, 반구조명보다도 가벼운 방식입니다. 메뉴의 a 에서 노말 표현 부분의 윗 색상과 아래 부분 색상을 결정해 줄 수 있습니다.

결론적으로, 훨씬 입체감이 살아나며 노말맵이 잘 표현되는 쉐이더가 되었습니다.

b: 스페큘러는 빛의 추가 없이 2개로 나타납니다. 하나는 실제로 빛 방향과의 계산을 통한 기본적인 스페큘러이며, 또 하나는 카메라 방향을 바라보고 있는 스페큘러 (드라마나 방송 등을 보시면 볼 수 있는 카메라 위에 조명 달린 것을 상상하시면 됩니다 ) 를 흉내낸 카메라 입니다. 각각 빛의 범위와 색상을 따로 정할 수 있으며, 가죽 질감 등 광택이 있는 질감을 강조할때 무척 유용합니다.
물론 노말맵을 강조하는 효과도 있습니다.

c : 림 라이트 추가되어 있습니다 역광 효과등 배경과 분리되는 느낌을 나타낼때 무척 유용합니다.

캐릭터에 적용하는 것도 마찬가지의 효과를 볼 수 있습니다. 얼굴과 같이 Normal 표현이 상당히 적은 곳에는 그 효과가 확연하게 보이는 편은 아니긴 하지만…

a : 림라이트 적용되어 역광효과가 납니다. 블룸에 반응하여 저런 느낌이 되었습니다. 노말 적용으로 얼굴도 좀 더 부드럽게 나옵니다.
b: 화면 방향의 스페큘러 적용으로 입체감이 더 나오고 있습니다. 림라이트 때문에 입술이나 콧구멍 부분이 밝아지는 것은 단점에 속합니다.
c : 단순히 텍스쳐로만 표현했던 근육의 입체 부분이 보다 리얼하게 반응하며, 색상도 조정할 수 있습니다.

세부 사용법

기타 추가 사용법은 다음과 같습니다.

두둥.

<가슴에는 염색. 배에는 그라디언트, 몸에는 스페큘라 스페큘라 스페큘라…>

머리카락이나 복장 표현을 위한 알파 테스팅이 구현되어 있습니다 알파 블렌딩은 사용금지입니다!
알파 테스팅은 Cutout 바로 테스팅 되는 정도를 조절할 수 있습니다.

또한 염색과 스페큘러 마스킹이 적용되어 있습니다.
이 기능을 사용하실때의 주의점은 다음과 같습니다.

현재 사용되는 텍스쳐는 2장, Main Texture 와 Normal Texture 입니다.
Main texture는 일반적으로 제작하시면 되겠습니다만 Normal Texture를 제작하실때 주의하셔야 할 점이 있습니다.

절대로 텍스쳐를 Normal map으로 변환시키지 마세요.
엔진 자체적으로는 데이터를 줄이기 위해 텍스쳐를 Normalmap으로 선택하면, 노말 텍스쳐를 인식해서 그레이 스케일의 1bit 이미지로 변환시켜 버립니다. 텍스쳐는 그냥 텍스쳐 모드로 사용해 주세요

스페큘러 마스크는 노말맵의 R,G,B 에서 B 채널입니다. 흰색은 스페큘러가 나타나는 부분이고, 검은색은 스페큘러가 나타나지 않는 부분입니다.
스페큘러 2개는 각각 색상과 넓이를 따로 조절할 수 있게 되어 있습니다.
염색은 노말맵의 A 채널입니다만, 특이하게도 흑백이 반대로 되어 있습니다!!!!!!!!!!
이 점을 주의해야 하는데, 이렇게 제작한 이유는 염색이 필요 없는 캐릭터의 경우 알파 채널을 만들지 않으면 자연스럽게 알파는 흰색으로 인식하기 때문입니다. 즉 염색이 필요 없는 캐릭터는 그냥 알파 채널을 만들지 않아도 되게끔, 이렇게 제작되었습니다.

당연하게도 알파 채널의 검은색 강도에 따라 염색의 적용 강도도 결정되며, 색상도 변하게 할 수 있습니다.
염색은 밝게도 어둡게도 들어갈 수 있으며, 이전에 제작된 염색보다 색상이 강하게 들어갑니다.
그러므로 초기값은 회색 (128,128,128) 이며, 염색 칼라를 회색으로 하면 염색이 보이지 않습니다.

디퍼드 렌더링 / 포워드 렌더링

유니티 엔진에는 두 가지의 렌더링 방식이 공존하고 있습니다.
빛 표현을 무제한이라 해도 좋을 만큼 자유스럽게 할 수 있는 대신 처리 제약과 기본적 시스템 부하가 따르는 디퍼드 렌더링,
상대적으로 가볍고 처리를 자유롭게 할 수 있는 대신 빛 처리가 추가로 들어가면 굉장히 무거워지는 포워드 렌더링.

옵션에서 판타스틱까지 올라가면 디퍼드 렌더링이 가동되며, 그 이하 옵션으로 조정되면 포워드 렌더링으로 돌아갑니다.
지금 이 쉐이더도 두 가지 렌더링에 모두 대응할 수 있도록 제작되어 있지만, 디퍼드 렌더링의 단점인 처리 제약때문에 몇 가지의 기능이 제한됩니다. 아래 제약 외에는 모두 동일합니다.

림라이트가 생기지 않습니다.
뷰 디렉션을 받지 않는 렌더러 특성상 림라이트 처리가 힘들어집니다. 추후 UI (선택) 등을 위해서는 2D에서 외각을 추출하는 방식을 따로 개발해야 합니다. (개발중입니다)
두 번째 스페큘러가 생기지 않습니다.
스페큘러 라이트가 계산되어 넘어오기 때문에, 또 하나의 스페큘러를 계산하기 불가능해 집니다. 이런 경우에는 라이트를 하나 더 추가해 주면 되겠습니다.
스페큘러 표현이 달라집니다.
스페큘러가 대부분 계산된채 넘어오기 때문에 넓이 조절이 달라집니다. 전체적으로 스페큘러가 좁아지게 됩니다.

추후 작업 / 수정내역 :
- 메탈 질감 쉐이더를 추가해야 할 듯 합니다. 금속 재질을 표현하는 방법이 구현되어 있지 않습니다.

알파 테스팅 작업시 Z 버퍼 문제가 디퍼드에서만 발생합니다. 순호스승님이 봐주시기로 되어 있습니다.
노말 연결부분에 이음새 (seam) 이 생깁니다. 이 부분도 순호스승님이 봐주시고 계십니다.

Shader 버전별 제약

Fri, 21 Jan 2011 13:35:13 +0000

퍼옴 : http://en.wikipedia.org/wiki/High_Level_Shader_Language

PIXEL shader comparison

Pixel shader version	2.0	2.0a	2.0b	3.0[2]	4.0[3]
Dependent texture limit	8	Unlimited	8	Unlimited	Unlimited
Texture instruction limit	32	Unlimited	Unlimited	Unlimited	Unlimited
Position register	No	No	No	Yes	Yes
Instruction slots	32 + 64	512	512	≥ 512	≥ 65536
Executed instructions	32 + 64	512	512	65536	Unlimited
Texture indirections	4	No limit	4	No Limit	No Limit
Interpolated registers	2 + 8	2 + 8	2 + 8	10	32
Instruction predication	No	Yes	No	Yes	No
Index input registers	No	No	No	Yes	Yes
Temp registers	12	22	32	32	4096
Constant registers	32	32	32	224	16x4096
Arbitrary swizzling	No	Yes	No	Yes	Yes
Gradient instructions	No	Yes	No	Yes	Yes
Loop count register	No	No	No	Yes	Yes
Face register (2-sided lighting)	No	No	No	Yes	Yes
Dynamic flow control	No	No	No	24	Yes
Bitwise Operators	No	No	No	No	Yes
Native Integers	No	No	No	No	Yes

PS 2.0 = DirectX 9.0 original Shader Model 2 specification.
PS 2.0a = NVIDIA GeForce FX-optimized model.
PS 2.0b = ATI Radeon X700, X800, X850 shader model, DirectX 9.0b.
PS 3.0 = Shader Model 3.
PS 4.0 = Shader Model 4.

“32 + 64” for Executed Instructions means “32 texture instructions and 64 arithmetic instructions.”

Vertex shader comparison

Vertex shader version	VS 2.0	VS 2.0a	VS 3.0[2]	VS 4.0[3]
# of instruction slots	256	256	≥ 512	4096
Max # of instructions executed	65536	65536	65536	65536
Instruction predication	No	Yes	Yes	Yes
Temp registers	12	13	32	4096
# constant registers	≥ 256	≥ 256	≥ 256	16x4096
Static Flow Control	Yes	Yes	Yes	Yes
Dynamic Flow Control	No	Yes	Yes	Yes
Dynamic Flow Control Depth	No	24	24	Yes
Vertex Texture Fetch	No	No	Yes	Yes
# of texture samplers	N/A	N/A	4	128
Geometry instancing support	No	No	Yes	Yes
Bitwise Operators	No	No	No	Yes
Native Integers	No	No	No	Yes

VS 2.0 = DirectX 9.0 original Shader Model specification.
VS 2.0a = NVIDIA GeForce FX-optimized model.
VS 3.0 = Shader Model 3.
VS 4.0 = Shader Model 4.

NormalMap 연산

Tue, 18 Jan 2011 19:49:21 +0000

//—————————————————————-
//Normal1 method : NormalMap, Traditional method
//—————————————————————-
half4 NormalTex = tex2D (_BumpMap, IN.uv_BumpMap); // 범프맵 변환 텍스쳐를 좌표로 연산. 이 시점에서 그레이스케일
half3 UPNormal =UnpackNormal(NormalTex); // 언펙한다. 언펙 함수 내용은 거기 (…) 안에 있긔
//~ o.Normal = UPNormal; // 이걸 노말로 리턴한다. 푸르게 변해있음.
//—————————————————————-
// 기본적인 방법. 언펙함수로 그레이스케일을 한 번 거쳐서 최종 데이터를 만들어 낸다. 텍스쳐는 범프맵으로 변환.
// 이렇게 하면 3채널을 다 써야 하는데다가 알파도 따로 사용하지 못한다는 단점이 있다.

//—————————————————————-
//Normal2 method : Texture , Old (Gamebryo) method
//—————————————————————-
half4 NormalTex2 = tex2D (_BumpMap2, IN.uv_BumpMap);// 일반 노말 텍스쳐를 UV좌표에 대입
//~ o.Normal = normalize(float3(NormalTex2.rg,1)*2-1);// 이걸 곧장 노말로 리턴. b 채널은 어차피 잉여로우므로 다른데 쓰자. *2-1 따위는 이제 기본이므로 (훗) 굳이 설명하지 말자.
//—————————————————————-
// 겜브리오때 썼던 방법의 재현. 노말맵의 Z 값은 다른데 쓰기 위해 강제지정한다. 텍스쳐는 일반 텍스쳐 상태로 유지.
// 채널 2개를 사용. 2개의 채널이 남아있다.

//—————————————————————-
//Normal3 method : Texture, Only use GREEN channel !
//—————————————————————-
half4 NormalTex3 = tex2D (_BumpMap2, IN.uv_BumpMap); // 일반 노말 텍스쳐를 UV좌표에 대입
half4 FakeNormal = half4(NormalTex3.g,NormalTex3.g,NormalTex3.g,NormalTex3.g); // 그린 채널만 가지고 half4를 재구성
half3 UPNormal3 =UnpackNormal(FakeNormal ); // 그레이스케일로 나왔을테니 언펙하자.
o.Normal = UPNormal3; // 1번 방식과 동일하게 리턴.
//—————————————————————-
// 복합적인 방법. 이번엔 노말 텍스쳐의 그린 채널만 이용해서 그걸 다시 언펙시켜 노말맵을 만든다! 당근 텍스쳐는 일반 상태.
// 채널 3개가 잉여롭게 남는다. 아이 기뻐라.

…. 1번은 텍스쳐 채널을 3개 써야 하고 2번은 2개 쓰고 3번은 1개만 쓴다…..
…. 웃긴건 결과가 모두 똑같다 OTL (미세한 차이가 있는 것 같긴 하지만 눈에 띄지 않을 정도)
1번 방법에서 그레이스케일로 변환한 데이터를 보니 그린채널과 크게 다른 점이 없길래 그냥 그린채널을 이용해서 3번을 만들었더니 결과가 똑같애.. OTL 뭐냐 얘…. (3번은 좌우 대칭할때 문제발생)

그림은 공개불가 ㅎㅎ
언젠가 공개할 날이 있을듯

VPOS

Mon, 17 Jan 2011 16:48:48 +0000

작업을 하다가 보면, VPOS 라는 Pixel Shader 입력 Sementic을 사용할 필요가 있습니다.

(VPOS는 현재 Screen 상의 Pixel Position을 자동으로 생성해주는 역할을 함.)

주로 Screen 상의 UV를 구할 때 사용을 하지요.

그런데, 이 녀석이 SM3.0 이상에서만 지원하는 기능이기 때문에, 아래와 같이 처리를 해주어야 합니다.

http://www.gamerendering.com/category/rendering-methods/shaders-rendering-methods/

2.0 타겟으로 처리할 경우, 유용하겠죠?! ^^

그래픽과 기획이 알아두면 좋은 최적화와 가속화

Sun, 16 Jan 2011 21:29:56 +0000

사내교육을 위한 자료입니다.

최적화와 가속화

최적화와 가속화는 사실 별 차이가 없는 말이기도 합니다. 어찌되었건 ‘게임이 빨리 돌아가게’ 라는 목표를 위해서 존재하는 것들이니까 말이죠. 굳이 최적화 기법과 가속화 기법을 나눈다면, 최적화는 ‘이왕 들어가야 하는거 효율적으로 넣지’ 라는 것이고, 가속화라고 하는 것은 ‘빠르게 하기 위해서 갖가지 눈속임 기법들을 쓰자’ 정도로 분류할 수 있을 것입니다.

은퇴후 계획

Sun, 16 Jan 2011 21:19:15 +0000

평균수명 90세 시대, 은퇴후 30년의 꿈은 무엇인가?

사실 은퇴후 계획을 벌써 세우는건 ‘벌써부터 은퇴할 생각인거냐!’ 라는 말을 들을 수도 있지만
이미 10살도 안되는 어린 아이에게 ‘넌 뭐가 되고 싶니?’ 라고 질문을 하는 것과도 같이, 미리미리 꿈을 꾸어 두는 것은 매우 좋은 일입니다. 저 역시 ‘암시의 저주’ 를 믿고 있기 때문에 ‘난 뭐가 될거야’ 라고 공공연히 떠벌리고 다닌다던가, 자기가 손에 넣고 싶은 것을 늘 바탕화면으로 쓰고 있으면 언젠가 비슷한 것이라도 손에 넣게 된다는 것을 잘 알고 있기 때문이지요.

그런 의미에서 노년의 인생은 뭘 할 것인가 - 를 자유롭게 상상해 두는 것은 매우 바람직한 일입니다. 또한 즐겁기도 하고요.
‘늙어서 아무 계획도 없이 집에서 뒹굴댈거야’ 라고 생각하고 실천한다면 그것은 바로 치매와 직결되는 지름길 -

저는 일단 생각하고 있는 노년의 인생은 몇 가지가 있습니다. 쉽게 실현할 수 있는 것도 있고 단지 꿈일 뿐인 수준의 것도 있지요.
하지만 어렸을때는 단지 꿈일 수준의 것이었던 것이 지금에서는 실현된 것도 꽤 있는 바 … 꿈이라고 해서 완전히 불가능한 것은 아니겠지요.

아래는 몇 가지 생각하고 있는 노년의 꿈 - 한 20년 남았네요 ㅎㅎ

이민가기 : 이민까지는 아니더라도, 적어도 외국에서 몇 년 이상 살아보고 싶습니다. 공부도 괜찮고 일도 괜찮죠. 가능하다면 정착해서 온가족 이민하는 것도 좋은 고려대상. 일단 여러 가지 경로를 기웃대고 있긴 합니다만, 역시 영어부터 시작해야 하겠지요.
강의하기 : 정식 교수는 별로 … (기회가 온다면 모르겠지만 큰 기대는 하고 있지 않습니다. 그쪽 세계의 분들이 쌓아놓은 것에 무임승차식으로 들어가면 별로 마음이 안좋을테니까요) 겸임혹은 시간강사, 혹은 학원급의 강사도 좋습니다. 강의도 해온지 오래 되었네요. 거의 8년이 넘어가고 있군요. 대학강의만 한 4-5년 한 것 같고, 교재 하나 , 기술서적 두 개 집필, 그 외 게임 아카데미 강의나 자질구레한 강연도 십수 회 되니까 나중에 강의하는데는 큰 문제될 것 같지 않습니다. 이미 친해놓은 교수분들도 꽤 있고 (후후후). 강의는 재밌습니다. 안개속인 학생들의 마음속에 불을 지필 수 있도록 살살 약올리는 것도 매우 재미있구요. 학력도 이것때문에 석사 따 놓은 거니까 뭐 준비 완료. (사실 리뷰하고 있는 것도 여기에 연관…)
연극하기 : 간간히 ‘연극하면 잘할 것 같다’ 라는 소리를 듣고 있는데요. 남 앞에서 약간 반쯤 맛간채 얘기하는 것도 사실 가능하고, 어렸을때 간간히 음악으로 무대활동했던 기억이 있어서인지 여전히 그쪽은 매력적입니다. 따로 준비하고 있는 것은 없는 실정이지만, 늙어서 기회가 된다면 액스트라라도 해보고 싶어요 :)
음악하기 : 연극하기와 물러 있는 건데, 녹슬은 기타를 다시 잡아보고 싶군요. 다시 쳐보니 손이 꼬여 ㄷㄷㄷ 스케일부터 다시 공부해야 할듯
혼자 게임 만들기 : 프로그래밍을 공부하게 된 계기이기도 하지요. 그냥 맘대로 혼자 게임을 만드는 것 - 혼자 작품세계를 펼쳐 보는 것은 제가 언제나 꿈꾸는 것이었으니까요. 마침 모바일 세계도 열렸겠다, 스마트폰용으로 게임을 혼자 만들어 쉬엄쉬엄 발표하면서 제 스타일의 무언가를 찾고 싶네요.
비밀 활동 : 사회적으로 뭔가 활동하고 싶은게 있는데, 여기에 쓸 수 있는건 아니군요 :) 하여간 그동안 받은게 있으니 뭔가 뿌리고 싶은 생각이 들긴 합니다.

그외 그림그리기, 전문리뷰어 등등 하고 싶은 일들은 여전히 많기도 합니다 :)

Normalmap seam 현상

Sun, 16 Jan 2011 20:44:52 +0000

생각해 보니 언렙하다보면 저렇게 노말맵이 seam 하게 만들어지는 경우가 생길 수 밖에 없는데.
이게 게임 엔진에 따라 저 부분이 seam 이 있게 보이는 것도 있고 안보이는 것도 있다니 이해할 수 없네요.

seam이 생기는 이유는 확실히 알 것 같은데 - 이걸 절대적인 좌표로 처리하지 않고 탄젠트는 버텍스에 있는 탄젠트 벡터를 참조해서 재 계산하게 하면 해결될 것도 같고 말입니다.

일단 테스트해본 바에 의하면 겜브리오에서는 저 부분의 seam을 확실히 없애줍니다. 오오 만날 욕하던 엔진이었는데 뭔가 대단.
근데 000 엔진이랑, 맥스 뷰포트용 fx 쉐이더에서는 저 부분의 seam이 남아 있습니다. 이유가 뭘까요? 엔진에서 처리하는 능력의 차이일까요 뭔가 탄젠트 재처리하는 공식이 있는 걸까요? 탄젠트 재정렬이라는 가정하에 찾아 보았는데 별로 뾰족한 부분을 찾지 못했다능.

맥스 뷰포트에서도 안보이게 seam 처리 하는게 있긴 하던데 쉐이더 코드가 알아보기 열라 힘들게 되어 있어서 재현불가..

아 머리 뽀개지는중

Fri, 14 Jan 2011 15:26:20 +0000

찾기 귀찮으니 여기다 백업해 놔야지.
이건 공개해도 되겠지 (ㅎㅎ)

struct appdata_base {
    float4 vertex : POSITION;
    float3 normal : NORMAL;
    float4 texcoord : TEXCOORD0;
};

struct appdata_tan {
    float4 vertex : POSITION;
    float4 tangent : TANGENT;
    float3 normal : NORMAL;
    float4 texcoord : TEXCOORD0;
};

struct appdata_full {
    float4 vertex : POSITION;
    float4 tangent : TANGENT;
    float3 normal : NORMAL;
    float4 texcoord : TEXCOORD0;
    float4 texcoord1 : TEXCOORD1;
    float4 color : COLOR;
};

노출도와 공격력에 대한 진실

Thu, 13 Jan 2011 09:55:30 +0000

….
과연!

캐릭터 쉐이더 시작

Thu, 13 Jan 2011 09:52:04 +0000

여기서부터 시작합니다.

… 뭘 어쩔까나…

DistortionRim2 쉐이더

Tue, 11 Jan 2011 12:11:24 +0000

기본 내장된 물 쉐이더를 조금 개조해서 이펙트용으로 제작해 봤습니다.
물 쉐이더에 있던 디스플레이스먼트 기능 (버텍스 쉐이더에서 버텍스 위치를 이동시켜 출렁임을 표현한 방법) 을 제거하고, 프레넬 공식을 입맛에 맞게 제어할 수 있도록 바꿔봤습니다. 지면 인식해서 투명해지고 다른 텍스쳐가 표현되는 Form 은 이름만 바꿔서 그냥 적용했구요. 굴절과 반사를 적절하게 섞어서 제작되었습니다.

어쨌거나 별칭은 코카콜라 병 쉐이더 ㅋㅋ

수중던전이라던가… 뭔가 하여간 물과 연관된 곳에 사용하면 좋을 듯 하네요.
그치만 당연하게도 무거우므로 낭비 금지 ㅋㅋㅋ 큐브맵 까지 합쳐서 4장의 텍스쳐를 사용하는, 3.0 전용 쉐이더입니다.
2.0에서 돌아가는 버전도 추가할 수 있지만 지금은 필요없으므로 안했지유. (2.0으로 하면 기능도 꽤 빼야 하고)
그래도 저사양 옵션에서를 위해 추후 기능을 추가해야 할 것 같긴 합니다.

뒷면 처리 (2face처리) 는 되어 있지 않습니다. 일단은 할 생각 없어유. ㅋ 하려면 pass를 늘여야 해서…

Base texture는 현재 저기 코카콜라 질감을 보이는, 그냥 텍스쳐입니다.
Base Texture Overlay 값을 높이면 불투명해지는게 아니라, 텍스쳐가 진해집니다. 물론 내리면 무색 유리병이 되지요.

Bump 텍스쳐는 노말맵.
Refractivity를 내리면 굴절이 약해져서 사라집니다. 굴절만.

Edge texture는 사물의 경계면과 맞닿는 부분을 인식해서 다른 텍스쳐로 바꿔주는 것입니다. 이 부분 공식 좀 어려워서 아직 이해 안가요… 스승님한테 물어봐 연구할 예정. 일단은 그냥 넣기.

Egde fade를 올리면 지면과 맞닿는 부분의 투명함의 범위가 증가해요.
대충 이 정도가 한계치. 필요하면 범위를 더 올려 드릴 수도 있어요
edge texture의 사용 예. 오브젝트들이 들어 있으면 영향받는다는걸 주의.

큐브 텍스쳐는 반사를 위한 것이므로 적절하게 이용하시면 됩니다.

Ambient는 전체적인 색을 어둡게 하고, 반사와 굴절을 막아 버립니다. 남는건 스페큘러 뿐…
Shiness는 스페큘러의 강도를 결정해 주는데요. 매우 민감하게 반응하니 조심스럽게 사용하세요.
최하 옵션으로 하면 이렇게 됩니다. 좀 오바지만 왠지 이뻐서 결정.

Spec Color 는 스페큘러 칼라니까 굳이 설명할게 없겠고…

Reflect Inverse는 반사의 영역을 뒤바뀌게 해줍니다.
기본값으로 반사는 Rim light 처럼 프레넬 공식으로 바깥에만 반사재질을 나타내고 있는데 (최하)

최상값으로 올리면 뒤집혀서 안에만 반사 재질이 들어가게 됩니다.
물론 그 아래 Reflect power로 넓이를 조정할 수 있구요.

World light Dir은, 이 쉐이더를 사용한 오브젝트만을 위한 가상의 조명 방향입니다. 이 조명은 오직 스페큘러가 생기는 방향을 결정하기 위해 만들어진 가상의 벡터이며, 진짜 조명이 아닙니다. 이 이펙트는 사실 조명 연산이 되지 않기 때문에 현재 지형에 있는 조명값을 가져오지 않으며, 때문에 전용의 조명 방향이 있어야 스페큘러를 만들 수 있는 것입니다. 적절하게 이용하세요.

ADD 버전.
Multi 버전

아이노트 블루투스 키보드 FS-94KBT 리뷰

Sun, 09 Jan 2011 20:31:24 +0000

이번에 리뷰한 제품은 퓨전에프앤씨 (FusionFNC) 에서 제작한 아이노트 (inote) 블루투스 키보드 FS-94KBT 입니다.
http://www.okcdr.com/

역시 협찬리뷰이지만 내용은 가차없는 (…정직은 생명)
가지고 있는 3종의 블루투스 키보드와의 비교도 있습니다.

Glow / Halo (Ghost) 쉐이더

Thu, 06 Jan 2011 15:55:23 +0000

전부터 만들고 싶었던 “무척 싸고 유용한 쉐이더” 를 목표로 만든 쉐이더입니다. 내용도 간단하고 범용적이며, 다양한 곳에 응용할 수 있습니다.
텍스쳐도 필요없고, UV 좌표도 필요 없습니다. View Direction 과 World Normal 만 사용합니다.

오브젝트 기반입니다. 필요한 곳에 오브젝트를 생성시켜 줍니다. 주전자 모양이건 구 모양이건 상관 없습니다.

기본적으로는 이렇게 쓰라고 만들어 놓은 쉐이더입니다. 쉐이더 2.0 이상이면 잘 동작합니다. (더 아래로도 만들 수 있지만 그럴 필요도 없고 귀찮…)

Desktop.zipHalo 쉐이더는 총 4종으로 제작되어 있습니다. 늘 그렇듯.

HaloScreen
SrcAlpha - one 으로 제작되어 있습니다. 약간 은은하게 빛나는 효과

HaloAdd
one- one 입니다. 좀 더 강한 효과가 나타납니다.

HaloMulti
Zero - OneMinusSrcColor 입니다.

HaloStandard

SrcAlpha - OneMinusSrcAlpha 어디다 쓸지는 잘 모르겠습니다만… 재미있는게 나올지도.

위와같이 조명과 함께 일렁이는 불빛 Glow 효과로 사용하면 휏불 등을 더욱 강하게 만들어 줄 수도 있습니다.
당연히 강약 에니메이션이 가능하기 때문에 여러 군데 응용가능.

꽤나 심플한 효과가 나기 때문에, 가로등 / 무기의 인첸트 등에도 광범위하게 사용할 수 있습니다.

[#VIDEO|20110106150100011335631701.jpg|pds/201101/06/03/|mid|480|400|pds18#]
또한 프레넬 계산을 역으로 연산할 수 있도록 만들어 놓아서, Rim Inverse 수치를 조정하면 Rim 라이트 모양의 Halo로 만들수도 있습니다. 머리에다가 설치하면 예수님 강림 등의 표현도 가능…

역시나 각종 블렌딩도 그대로고, 모델링 모양에 따라가므로 유령 / 보호막 표현에도 유용합니다.
나중에 텍스쳐와 연동되게 만들면 Halo 게임에서 나왔던 보호막 효과도 낼 수 있지만 그건 나중에…

쉐이더 하나로 양쪽을 왔다갔다 할 수 있다는게 자랑.

[#VIDEO|20110106150100011335951701.jpg|pds/201101/06/03/|mid|480|400|pds18#]

겸해서 지난 번에 만든 Distortion 쉐이더와 합체해 봤습니다. 이것은 물귀신 …?

DistortionRim 이란 이름의 쉐이더로 제작되어 있습니다.
특이한 점은 여기는 Rim 효과만 만들어 놓았으며, 일반 Normal이 아닌 적용되어 있는 Normalmap에 따라 효과가 나오도록 제작되어 있다는 것입니다.

[#VIDEO|20110106160100011336591701.jpg|pds/201101/06/03/|mid|480|400|pds19#]

Distortion 쉐이더

Tue, 04 Jan 2011 18:38:34 +0000

Grap 쉐이더 특성을 알아보고자 하는 테스트에 가까웠던 쉐이더입니다.
겸해서 이것저것 새로 깨달은 것도 있고…

어쨌건 이렇게 나옵니다. 노말맵 한 장을 이용해서 이미지를 굴절시킵니다. 내부적으로는 ‘두 장’ 을 씁니다.
노말맵 한 장, ‘Grap’ 텍스쳐 한 장.
grap 텍스쳐란 화면에 보이는 이미지를 캡쳐해서 맵핑소스로 만들어 놓은 것입니다.

물론 에니메이션을 주면, ‘흘러가게’ 도 만들 수 있습니다.
[#VIDEO|20110104180100011315151701.jpg|pds/201101/04/03/|mid|480|400|pds18#]

쉐이더 2.0 이상에서 가동되며, vertex alpha에 따라 투명도가 조절되니 적당히 사용하세용.
전체적인 강도도 옵션으로 조절할 수 있습니다.

응용하면, 플렌 두 장으로 한 장은 flow 쉐이더로 한 장은 Distortion 쉐이더로 해서 불 위의 아지랑이를 만들 수도 있습니다.
결과물은 이것. 핫 뜨거뜨거 핫 뜨거 핫
불 위의 아지랑이를 보세요.

[#VIDEO|20110104180100011315791701.jpg|pds/201101/04/03/|mid|480|400|pds18#]

기타 응용될 만한 곳은 사막 등의 아지랑이 효과라던가, 검광 (트레일) 등에 사용되게 될 것입니다.
캐릭터가 반사되는 것 같은 이미지는 유일한 단점이랄까. 고치기 귀찮… (아니 그전에 어떻게 하는지도 잘..)

Skin shader for unity3

Tue, 04 Jan 2011 15:34:10 +0000

http://forum.unity3d.com/threads/64210-Skin-Shader-for-U3-need-help-with-converting.

Shader “Skin for Unity 3/Bumped Specular” {
Properties {
_Color (“Main Color”, Color) = (1,1,1,1)
_SpecColor (“Specular Color”, Color) = (0.5, 0.5, 0.5, 1)
_Shininess (“Shininess”, Range (0.01, 1)) = 0.078125
_MainTex (“Base (RGB) Gloss (A)”, 2D) = “white” {}
_BumpMap (“Bump (RGB)”, 2D) = “bump” {}
_RimTex (“Rim ramp (RGB) Fresnel ramp (A)”, 2D) = " grey" {}
_WrapTex (“Wrap ramp (RGBA)”, 2D) = “black” {}
}

SubShader {
Tags { “RenderType” = “Opaque” }
LOD 400

CGPROGRAM
#pragma surface surf BumpSpecSkin

uniform float4 _Color;
uniform float _Shininess;
uniform sampler2D _MainTex;
uniform sampler2D _WrapTex;
uniform sampler2D _RimTex;
uniform sampler2D _BumpMap;

half4 LightingBumpSpecSkin (SurfaceOutput s, half3 lightDir, half3 viewDir, half atten) {
// rim factor
float rimf = dot(s.Normal, viewDir);
half4 rim = tex2D (_RimTex, rimf.xx);

half3 h = normalize( lightDir + viewDir );

// This is “wrap diffuse” lighting.
// What we do here is to calculate the color, then look up the wrap coloring ramp so you can tint things properly
half diffusePos = dot(s.Normal, lightDir) * 0.5 + 0.5;
half4 diffuse = tex2D (_WrapTex, diffusePos.xx);
diffuse.rgb *= rim.rgb * 4;

float nh = saturate( dot( h, s.Normal ) );
float spec = pow( nh, s.Specular ) * s.Gloss;

half4 c;
c.rgb = (s.Albedo + _SpecColor.rgb * spec * rim.a) * diffuse * (atten * 2) * _LightColor0.rgb;
// specular passes by default put highlights to overbright
c.a = _LightColor0.a * _SpecColor.a * spec * atten;

return c * _Color;
}

struct Input {
float2 uv_MainTex;
float2 uv_BumpMap;
};

void surf (Input IN, inout SurfaceOutput o) {
half4 texcol = tex2D( _MainTex, IN.uv_MainTex);
o.Albedo = texcol.rgb;
o.Gloss = texcol.a;
o.Specular = _Shininess * 128;
o.Normal = UnpackNormal (tex2D (_BumpMap, IN.uv_BumpMap));
}
}

ENDCG

}

And now some nice images using the great model from Infinite, 3D Head Scan by Lee Perry-Smith (http://www.ir-ltd.net/blog/).

The model on the left is rendered with a classic Bumped Specular shader, while the right model is rendered using the skin shader:

Front directional light

Left directional light

Light from below

Directional light with soft shadows

flow shader 버전별 제작

Mon, 03 Jan 2011 10:36:00 +0000

음… 블렌딩 옵션별 flow 쉐이더를 제작했습니다.

예제에서도 이렇게 따로 나눠 놓은 걸로 봐서 techniq 등으로 처리할 수가 없나봐요.

어째서 쉐이더 UI 에는 라디오버튼이다 드랍다운 메뉴가 없단 말인가!!! 만들어라! 만들어라! … 심지어 유니티에는 Bool도 없어유… 0과 1로 처리할 수 밖에 없어요… 그나마도 0과 1 로 해놓고 단위를 1로 해 놓으면 On/Off 처럼 쓸 수 있을텐데 그것도 없어유… OTL 하지만 뭐 추가로 만드는게 거의 스트레스가 없기 때문에 (이름 중복하는 것만 주의하면) 그다지 불편하지는 않아유…

바로 만들 수 있었는데 좀 오래 걸린 이유는, CG로 쉐이더를 짜는 스타일을 정할 때 크게 두 개로 할 수 있는데, 하나는 이미 있는 라이팅 구조에 슬쩍 끼워서 짜는 방식과 (그게 이전방식. 라이트 연산을 아예 안할 수 있는 방법을 못찾았음) 아예 버텍스 쉐이더와 픽셀쉐이더를 따로 짜서 넣는 방법 ( 해봐서 성공. 라이트 연산을 아예 안할 수 있다) 을 테스트해 보느라고 말입니다.

일단 두 번째 방법으로 라이트 연산을 아예 안하는 방법을 성공시키긴 했지만, 그렇게 몽땅 수동으로 바꾸니 가장 유용한 옵션이었던 텍스쳐 타일링 등의 수치를 툴에서 못바꿔요 …OTL 너무 수동이 된거야.. OTL OTL OTL

그래서 할 수 없이 포기하고 다시 처음 방식으로 만들었습니다. 라이트 연산이 좀 된다 하더라도, 기능이 통합된 자동 방식이 훨씬 유용하고 작업효율이 좋지요. (사실 라이트 연산이 되는지도 불명확 하고)

하여간 참으로 다양한 방식으로 쉐이더를 짤 수 있으니 이거저거 건드려 보는데도 하루가 잘도 갑니다 그려.

어쨌건 그런 사연끝에 만든 쉐이더 블렌딩 베리에이션입니다.

Screen

일반적으로 많이 사용하는 SrcAlpha - One 입니다. 이름처럼 소스의 알파채널을 사용하며, 뒤의 이미지를 밝게 만들어 버립니다.

ADD

- Screen과 비슷하지만 훨씬 강하고 밝은 이미지가 나오게 됩니다. One-One을 사용하기 때문에 알파 채널은 필요 없고 최종 연산된 칼라에 따라 투명도가 결정됩니다.

Standard

일반적인 투명도 계산입니다. 알파 채널을 이용하며, 라이트 계산은 되지 않지만 특별히 더 밝아진다던가 어두워진다던가 하지 않습니다. SrcAlpha - InvSrcAlpha (유니티에서는 OneMinusSrcAlpha) 한마디로 그냥 반투명.

Multi

- 엄밀히 말하면 진짜 Multi와는 좀 다릅니다 :) Zero- InvSrcColor (유니티에서는 OneMinusSrcColor) 로, 특이한 변이재질에 가깝습니다. 알파는 사용하지 않고, 소스의 칼라에 따라 투명도가 정해집니다. 또한 색도 뒤집힙니다.

…. 그리고 이건 지금 연구하고 있는 쉐이더 . ㅋㅋ

빌립 S5에서 불멸온라인 돌리기

Sun, 02 Jan 2011 17:03:32 +0000

참으로 아무 컴퓨터에서나 마구 잘 돌아가는군요.

폰트 뒷배경이 좀 검게 나오긴 하지만 게임은 꽤나 쾌적한 정도로 즐길 수 있습니다.

고급 쉐이더를 사용한 멋진 게임도 좋지만 이렇게 아무 컴퓨터에서나 잘 돌아가는 게임을 만드는 것도 꽤나 이상적인 일이지요.

12월 29일 에버랜드

Sun, 02 Jan 2011 10:33:59 +0000

추워 듁는 줄 알았다뇨.
… 라고 하지만 사실 낮에는 날씨가 깔끔하게 맑아서 좋았지유
폭설내린다고 TV에서 하도 겁줘서 다행히 사람도 없었구요
수준높은 라이드들은 꽤 많이 닫았지만 어차피 롤러코스터를 싫어하니 상관없고 ㅋㅋ

불꽃놀이등이 너무 추워서 취소되었다는것 정도만 아쉬울까나.

이쁘긔

연말파티

Sun, 02 Jan 2011 02:04:36 +0000

회사 놀이방에서 진행한 연말 가족파티.

각 집마다 요리 하나씩 가져오는 아메리칸 스타일.

식구가 다 모이니 30여명이라는 대 인원이…

앗 저건 실바다.

퍼포먼스 테스트

Sun, 02 Jan 2011 00:03:56 +0000

Unity's Rendering Pipeline

Fri, 31 Dec 2010 14:56:43 +0000

Unity’s Rendering Pipeline

Shaders define both how an object looks by itself (its material properties) and how it reacts to the light. Because lighting calculations must be built into the shader, and there are many possible light & shadow types, writing quality shaders that “just work” would be an involved task. To make it easier, Unity 3 introduces Surface Shaders, where all the lighting, shadowing, lightmapping, forward vs. deferred lighting things are taken care of automatically.

This document describes the pecularities of Unity’s lighting & rendering pipeline and what happens behind the scenes of Surface Shaders.

Rendering Paths

How lighting is applied and which Passes of the shader are used depends on which Rendering Path is used. Each pass in a shader communicates its lighting type via Pass Tags.

In Deferred Lighting, PrepassBase and PrepassFinal passes are used.* In Forward Rendering, ForwardBase and ForwardAdd passes are used.* In Vertex Lit, Vertex, VertexLMRGBM and VertexLM passes are used.

Deferred Lighting path

PrepassBase pass renders normals & specular exponent; PrepassFinal pass renders final color by combining textures, lighting & emissive material properties. All regular in-scene lighting is done separately in screen-space. See Deferred Lighting for details.

Forward Rendering path

ForwardBase pass renders ambient, lightmaps, main directional light and not important (vertex/SH) lights at once. ForwardAdd pass is used for any additive per-pixel lights; one invocation per object illuminated by such light is done. See Forward Rendering for details.

Vertex Lit Rendering path

Since vertex lighting is most often used on platforms that do not support programmable shaders, Unity can’t create multiple shader permutations internally to handle lightmapped vs. non-lightmapped cases. So to handle lightmapped and non-lightmapped objects, multiple passes have to be written explicitly.

Vertex pass is used for non-lightmapped objects. All lights are rendered at once, using a fixed function OpenGL/Direct3D lighting model (Blinn-Phong)* VertexLMRGBM pass is used for lightmapped objects, when lightmaps are RGBM encoded (this happens on most desktops and consoles). No realtime lighting is applied; pass is expected to combine textures with a lightmap.* VertexLMM pass is used for lightmapped objects, when lightmaps are double-LDR encoded (this happens on mobiles and old desktops). No realtime lighting is applied; pass is expected to combine textures with a lightmap.

유니티 렌더링 파이프라인

쉐이더는 두 개로 정의한다. 그 자신의 메터리얼 설정에 의해 어떻게 보여지는 것과 라이트에 어떻게 반응하느냐 말이다.
왜냐면 라이팅 계산은 쉐이더에서 이루어 지기 때문이다. 그리고 거기에는 많은 타입의 가능한 조명과 그림자 타입이 있다. 제대로 움직이는 퀄리티 쉐이더를 짜는건 복잡한 테스크이다. 쉽게하려면, 서페이스 쉐이더 시작을 읽어봐라. 거기엔 라이팅, 쉐도우, 라이트 맵핑. 포워드와 디퍼드 라이팅이 자동으로 관리된다.
이 문서는 서술한다 유니티의 라이팅과 렌더링 파이프라인의 특성들(pecularities:유산, 버릇) 이 서페이스 쉐이더에서 뭔 일이 일어나는지를 말이다.

렌더링 패스

어떻게 라이팅이 적용되고 어떤 패스가 어떤 렌더패스에 의해 작동하는지. 각 패스는 아래의 패스 테그에 딸린 라이팅 타입으로 커뮤니케이션 한다.

디퍼드 라이팅 : 프리페스 베이스 또는 프리패스 파이널 패스를 사용한다
포워드 라이팅 : 포워드 베이스나 포워드 에드 패스가 사용된다.
버텍스라이트 : 버텍, 버텍스 NMRGBM이나 버텍스 LM 패스가 사용된다.

디퍼드 렌더링 패스
… 아래는 일단 패스

Unity Shader 기본 CG 쉐이더

Fri, 31 Dec 2010 11:52:29 +0000

유니티에서의 쉐이더 처리는 크게 3가지로 나눌 수 있다 (라고 지금까지는 보인다)

내장 스크립트로 처리하는 방법 : 가장 효율이 좋고 범용적이지만 할 수 있는게 별로 없다.
CG 사용법 : 버텍스 쉐이더와 픽셀 쉐이더를 정해서 처리하는 법.
3. 서페이스 라이팅 구조 : 라이팅 구조를 따로 작성해서 깊이 파고드는 법이다. inline등으로 직접 라이트 계산이 가능하다.

아래는 라이팅 연산을 하지 않는, 이펙트를 위한 CG 기본구조를 CG와 서페이스 라이팅으로 만들어 본것.
아직 연구중이라 틀린게 많을 수도 있다.

밝혀낸것. (밝혀낸것 같은것 : 의문점들)

애석하게도 CG 상태로 하면 내장된 텍스쳐의 타일링이나 옵셋 변화가 작동되지 않는다.
서페이스 라이팅 구조를 사용하면 라이트 세트의 선택이 가능하지만, 조정에 한계가 있다.
CG 상태에서는 Pass 를 필수로 사용해야 하지만, 서페이스 라이팅 구조로 사용하면 Pass 를 사용하면 에러가 난다.

==============================================================
그중 CG 사용의 기본구조. 단순 칼라 출력

Shader “Color” {

Properties {

_Color (“Color Tint”, Color) = (1,1,1,1)

}

SubShader {

    ZWrite On
    Tags { “Queue” = “Transparent” }
    Blend SrcAlpha OneMinusSrcAlpha

Pass {

CGPROGRAM

#pragma vertex vert
#pragma fragment frag
#include “UnityCG.cginc”

float4 _Color;
struct v2f {
V2F_POS_FOG;
};

v2f vert (appdata_base v)
{
    v2f o;
    PositionFog( v.vertex, o.pos, o.fog );
    return o;
}

half4 frag (v2f i) : COLOR
{
return _Color;
}
ENDCG

}
}
Fallback “Diffuse”

}

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

이번엔 거기다 텍스쳐추가 * 아까 그 칼라에 곱셈

Shader “Color_Texture” {

Properties{
  _Color (“Color Tint”, Color) = (1,1,1,1)
  _MainTex (“MainTex”, 2D) = “white” {}
   }

SubShader
{
  ZWrite On
  Tags { “Queue” = “Transparent” }
  Blend SrcAlpha OneMinusSrcAlpha

Pass
  {
   CGPROGRAM

   #pragma vertex vert
   #pragma fragment frag
   //~ #pragma fragmentoption ARB_fog_exp2
   #include “UnityCG.cginc”

   sampler2D _MainTex;
   float4 _Color;

  struct v2f
   {
    V2F_POS_FOG;
    float4 texcoord : TEXCOORD0;
   };

  v2f vert (appdata_base v)
   {
    v2f o;
    PositionFog( v.vertex, o.pos, o.fog );
    o.texcoord = v.texcoord;
    return o;
   }

  half4 frag (v2f i) : COLOR
   {
    float4 Final = tex2D (_MainTex, i.texcoord.xy) * _Color;
    return Final;
   }

  ENDCG
  }

}
Fallback “Transparent/Diffuse”

}

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

서페이스 라이팅 구조로 붉은색만 나오게 만든 것.

Shader “Color_Texture” {

Properties{
  _Color (“Color Tint”, Color) = (1,1,1,1)
  _MainTex (“MainTex”, 2D) = “white” {}
   }

SubShader
{
  ZWrite On
  Tags { “Queue” = “Transparent” }
  Blend SrcAlpha OneMinusSrcAlpha

//~ Pass
  //~ {
   CGPROGRAM

   //~ #pragma vertex vert
   //~ #pragma fragment frag
   //~ #pragma fragmentoption ARB_fog_exp2
   //~ #include “UnityCG.cginc”
   #pragma surface surf Lambert

   sampler2D _MainTex;
   float4 _Color;

  /* struct v2f
   {
    V2F_POS_FOG;
    float4 texcoord : TEXCOORD0;
   };



  v2f vert (appdata_base v)
   {
    v2f o;
    PositionFog( v.vertex, o.pos, o.fog );
    o.texcoord = v.texcoord;
    return o;
   }

  half4 frag (v2f i) : COLOR
   {
    float4 Final = tex2D (_MainTex, i.texcoord.xy)* _Color;
    return Final;
   }
*/
  struct Input
   {
    float2 uv_MainTex;
   };


  void surf (Input IN, inout SurfaceOutput o)
  {
   o.Albedo = float4(1.0,0.0,0.0,1.0);
   o.Normal = float3(0.0,0.0,1.0);
   o.Emission = 0.0;
   o.Gloss = 0.0;
   o.Specular = 0.0;
   o.Alpha = 1.0;
  }

  ENDCG
  //~ }

}
Fallback “Transparent/Diffuse”

}

불멸 온라인 두분토론

Fri, 31 Dec 2010 10:28:04 +0000

그래도 우리 회사에서 하는건데 퍼와주는 노력정도는 해야죠. ㅎ
불멸… 은 중국 완미시공 게임인데 가져와서 퍼블리싱 하는 겁니다.
해본감상은 회사 내부 게시판에 올렸었지요. 아쉽게도 내용이 거시기(내부내용이 많아서) 해서 퍼올수는 없구용.
“편의점 알바에게 추천하고 싶은 게임” 이라는게 제 리뷰 제목이었었죠 ㅋㅋ

어쨌건 어라 뭐지 와우의 탈을 쓴 뮤 …? 라고 생각하면서 우습게 시작했다가…
… 어라? 하다보니 45렙….
그래서 그런지 지금 동접과 매출이 ㅎㄷㄷㄷㄷ 아니 그정도 나왔으면 왜 발표를 안하지? 라는 정도 ㄷㄷㄷ
3만 5천이라고 기사가 나왔던데 그거보다 훨씬 오른지 오래 됩니다 ㄷㄷㄷ
요즘 우리 사업팀 분들이 공격적인 분들이 많이 들어오셔서 그런지 마케팅도 엄청 공격적이네요
(전 매우 마음에 듭니다 원츄. 노이즈 마케팅이 묻히는 마케팅보다 백배 낫다라는 말이 있지요)
사업팀 이번 기회에 대박터트릴 것 같네요. 첫 퍼블리싱 게임이 이리 잘되다니. 와와

게임에 대한 제 감상은요 “MMORPG의 탈을 쓴 육성시뮬레이션” ㅋㅋㅋㅋ

본격적으로 잡아서 하는 게임이 아니고 진짜로 가게에서 손님 없을때 조금 돌리다가 손님오면 손님맞고 하기에 딱 적합한 게임입니다 ㅋㅋ . 이런 시장도 분명히 있어요. 그 소비자들이 루리웹에 없을뿐 ㅎㅎ 분명 이런 게임도 필요하달까요.

인터넷에서 적극적으로 의견 피력하는 인터넷 세대 말고요. 정말로 가게 주인 아저씨들 게임 많이 하더라고요. 인터넷에 글 올리거나 그런 활동은 절대 안하지만 혼자 짬짬이 할 게임 없는 찾으시는분. 정말 많다고 생각했거든요. 가끔 동네 슈퍼마켓 가보면 하루종일 TV만 보면서 손님맞기 지겨우신 아저씨가 옆에 조그만 넷북이나 작은 본체 놓고서 뮤 오토 돌리는걸 꽤 봤어요.

이런 분들은 아이온이다 테라다 … 무거운 게임은 당근 못하시겠죠. 넷북에서 돌아갈만큼 가벼우면서도 쉬우면서도 쉬엄쉬엄 할 수 있고… 뭐 그런 게임 없나? 라고 찾고 계실거라고 생각했어요. 이 게임 보면서 딱 그런 분들한테 맞는 게임이라고 생각했었고, 시장이 있을 것 같다… 라고 생각했는데 아직까지는 정말로 그러고 있네요 :)

새 Flow 쉐이더 제작

Thu, 30 Dec 2010 12:13:04 +0000

생각해보니 저번에는 여기에 한 장 더 마스킹을 했더군요.
그대로 다시 재현해서 제작했습니다.
쉐이더 2.0 이상 한정해서 돌아갑니다.

웹게임 주제에 이펙트 텍스쳐를 3장이나 써서 되겠느냐! 라는 생각에 3번째 텍스쳐는 기본을 블랙으로 넣어서
2장만 넣어도 돌아가게 만들었습니다.
에니메이션은 에니메이션 그래프 창에서 전부 조절할 수 있지만 조작편의를 위해 스크롤 컨트롤러를 만들어 놓았습니다.

그리고 3번째 마스킹은 선택에 따라 스크린 블렌딩과 멀티플라이 블렌딩을 선택할 수 있도록 되어 있길래 재현했습니다만
Bool 인터페이스가 없어 OTL 숫자 0과 1로 해버렸습니다.

여전히 Diffuse 렌더링 패스를 따라가는 프레그먼트 시스템을 피할 방법은 못찾겠슈… OTL

Unity 엔진용 Flow 쉐이더 컨버팅

Wed, 29 Dec 2010 11:18:32 +0000

이런 제길. 결국 다 다시 만들었습니다.

쉐이더 툴에서 만드는건 결국 참고로만 쓰고, 최종으로는 다시 수작업으로 작성.
커스텀 라이팅 체계를 쓰다보니까, 오히려 이펙트처럼 라이트 체계가 필요 없는 경우에서는 쓸데없이 커스텀 라이팅을 활성화 시켜서 디퍼드 렌더링까지 건드리는 사태를 초래하네요. 이펙트에 무슨 디퍼드 렌더링이야… 알파 들어간 녀석은 무조건 포워딩입니다.

동작은 잘 됩니다. 코드도 간단.

Shader “test/jpflow2” {
Properties {

_MainTex (“MainTex”, 2D) = “white” {}
_MainTexU(“MainTex U Scroll”, Float ) = 0
_MainTexV(“MainTex V Scroll”, Float ) = 0

_MainTex1 (“MainTex1”, 2D) = “white” {}
_MainTex1U(“MainTex1 U Scroll”,Float ) = 0
_MainTex1V(“MainTex1 V Scroll”,Float ) = 0

}

SubShader {
Tags { “Queue”=“Transparent” “IgnoreProjector”=“True” “RenderType”=“Transparent” }
Blend SrcAlpha One
//ColorMask RGB
Cull Off
ZWrite Off
Fog { Color (0,0,0,0) }

CGPROGRAM
      #pragma surface surf Lambert
//(라이팅 체계를 프레그먼트로 사용하는데, 렘버트를 사용중. 더 심플한건 없나? 무슨 종류가 있는지 알 수 없어서 고생스럽네요. 내부를 볼 수 없으니… )
//#pragma target 2.0

      struct Input {
          float2 uv_MainTex;
    float2 uv_MainTex1;
      };

   sampler2D _MainTex;
   float _MainTexU;
   float _MainTexV;

      sampler2D _MainTex1;
   float _MainTex1U;
   float _MainTex1V;

      void surf (Input IN, inout SurfaceOutput o)
  {
   o.Albedo = 0.0;
   o.Normal = float3(0.0,0.0,1.0);
   o.Emission = 0.0;
   o.Gloss = 0.0;
   o.Specular = 0.0;
   o.Alpha = 1.0;

   float2 MainTexScroll=_Time.x * float2(_MainTexU,_MainTexV ) ;
//(_Time이 float2로 되어 있습니다! 선언할 필요 없이 가져다 쓰는건 편하지만 덧셈할때 주의해야 합니다. )
   float2 UV_Pan0 = IN.uv_MainTex + MainTexScroll ;

   float2 MainTex1Scroll=_Time * float2(_MainTex1U,_MainTex1V ) ;
   float2 UV_Pan1 = float2(IN.uv_MainTex1.x ,IN.uv_MainTex1.y) + MainTex1Scroll ;

   float4 Finaltex = tex2D (_MainTex,UV_Pan0) * tex2D (_MainTex1,UV_Pan1) ;
   o.Emission = Finaltex.rgb;
   o.Alpha = Finaltex.a;
  }
      ENDCG
}
}

2010년 내 이글루 결산

Wed, 29 Dec 2010 09:03:15 +0000

Flow Shader 유니티 버전

Tue, 28 Dec 2010 14:15:52 +0000

Unity 버전으로 컨버팅.
노드 에디터 무료로 올라온 걸로 만들어 보긴 하는데 기능이 많이 부족하긴 하구나. 그래도 이게 어디냐.
뭐 일단 이걸로 초벌로 만든 다음에 코드를 직접 수정하면 될듯.

근데 .. 이렇게 만들면 무조건 커스텀 라이팅 시스템으로 제작되어서, 프레그먼스 쉐이더로 만드려면 결국 처음부터 다시 짜야 한다. 물론 구현할때 참고할 것들은 많아서 큰 도움이 되는건 사실.

연말연시 모임 추천 . 숯불돼지갈비 태능 맥갈비

Sun, 26 Dec 2010 01:14:35 +0000

경기도 남양주시 별내면 광전리 369
031-527-8800
http://dmaps.kr/d97

회식 언제 할까요, 곧 연말이고 크리스마스라서 일정들 바쁘실텐데"

이 말 한마디 했다가
… 이 날이 회식이 되어 버렸습니다.
뭐든 말꺼내면 바로 그 즉시 해버리는 훌륭한 우리 회사 전통 (…)

목적지도 역시 아무 생각 없이 “갈비가 먹고 싶어요” 라는 S 대리의 한마디에, 이미 예전에 검증되었던 맥갈비로 가기로 결정.
자 오늘의 회식 목적지는 유명한 태릉갈비집중 하나인 “맥갈비” 입니다.

회사에서 거의 한 시간을 가야 하는 거리지만, 저번 제 추천으로 갔던 이후에 다들 만족한 이유로 아무도 불평하지 않습니다.
아, 신입사원 H군은 아직 몰라서 이렇게 얘기하는군요 “왜 그리 멀리까지 가요?”
그래서 직장상사의 온화한 기운을 담아 이렇게 얘기해 주었습니다.

“… 닥치고 조용히 따라와 보면 알어…”

회사 끝나자 마자 곧장 차에 나눠타고 출발합니다.

40분쯤 걸리겠네요.

저 어플 자꾸 묻는 분이 계셔서 말하는데, 거금 5만원이나 주고 결재한 맵플3D 입니다. 쇼네비 아닙니다 .
쇼네비는 무료인 대신 기능이 부족하고,
검색기능이 자체적으로 내장되어 있지 않고 네트웍 연결을 통해 받아오는 방식이라 불안하고 느립니다.

“아이폰으로 GPS 쓰면 쓸만해요?”

연말연시의 유부중립국 대처방법 추천. 라 시갈 몽마르트

Sat, 25 Dec 2010 22:34:36 +0000

솔로들에게 수면제 사용을 권장하던 크리스마스도 가고, 본격적인 연말연시입니다.

솔로들은 수면제로 해결한다 하고, 커플들이야 뭐 알아서 하건 말건 신경 쓸 필요 없겠지요.
유부중립국들은 살짝 솔로당 소속입니다.

… 뭐 그건 솔로나 커플 얘기고
사실 솔로에서 지나 커플의 산을 넘고 아이들

간간히 컴백

Thu, 23 Dec 2010 20:00:01 +0000

뭐 공식적으로 컴백이라고 밝힐 것도 없이 리뷰때문에 간간히 쓰고는 있었는데…

하는 일이 아직까지는 (한동안도) 비밀 프로젝트가 될 것 같아 그쪽 공부는 정리할 수 없겠는데요

뭐 그대신 소일거리라도 간간히 올리렵니다. 원래는 트위터가 그런일을 주로 담당할 거라 생각했는데… 의외로 트위터도 슬슬 질려가네요.

IPAD 버전 그래픽 기술연구 보고

Thu, 23 Dec 2010 16:53:22 +0000

IPAD 용 데이터 제작을 위해 연구한 내용입니다. 일단 이것으로 종료 (프로그램팀이 삼품쪽으로 지원나가서) 하고 추후 다시 진행합니다.
IPAD(iphone)용 게임을 유니티에서 만드실 때에는 다음 내용을 숙지하심이 좋을 것 같습니다.

IOS용 데이터는 라이트 연산을 하기 어렵습니다. (거의 불가능합니다)
    : IOS는 타일 기반 디퍼드 렌더러 (Tile-Based Deferred Renderer) 를 사용합니다.

    : 라이트의 실시간 연산에 대한 부담이 매우 큰 편이며, 때문에 캐릭터 외엔 라이트 연산을 하지 않는 것이 좋습니다.
    배경은 모두 라이트맵을 굽거나, Texture only로 작업해야 합니다.
캐릭터에 사용될만한 쉐이더는 Diffuse fast 입니다.
: 일반 라이트 연산보다도 훨씬 가벼운 Diffuse fast 쉐이더가 캐릭터용으로 권장됩니다.
배경에 사용되는 쉐이더 기능은 텍스쳐 , 라이트맵 , 리플렉션 , 알파 , 버텍스 칼라 입니다.
    : 보통 위의 기능들을 조합한 쉐이더들이 있습니다. 자세한건 쉐이더 기능문서가 올라와 있습니다.
     Opengl 기반의 기기이기 때문에 일반적으로 사용되는 쉐이더를 사용할 수 없습니다. 또한 조명 연산이 힘들기 때문에
    실시간 조명 연산 쉐이더는 가급적 사용하지 말아야 합니다.

: Vertex shader까지 지원되므로 사실 스페큘러나 저수준의 노말맵도 사용할 수 있습니다. 하지만 효과에 비해 자원소모가
크기 때문에 그다지 추천하지는 않습니다.

IOS 용 데이터는 엔진에서 내장된 라이트맵 기능을 이용할 수 없습니다.
    : 사실은 구동이 가능하긴 합니다만, 엔진에서 자동으로 지원하는 라이트맵 텍스쳐 자동 적용 기능들이 사용불가능해집니다.
    복사한 건물 같은 경우 엔진 자체내에서 건물의 라이트맵만 다르게 구워서 입혀주지만, IOS 용 쉐이더로 바꾸면 깨집니다.
    맥스의 RTT (렌더투 텍스쳐) 기능을 이용하면 간편하고 최적화된 라이트맵을 생성할 수 있습니다.

    : RTT 기능을 이용하는 것이 유지보수에도 훨씬 유리하며, 후처리도 용이합니다.
    게다가 엔진에서는 사용 불가능한 point light 를 이용한 그림자도 사용할 수 있습니다.

    : 또한 엔진에 내장된 비스트 기능으로 만들어진 라이트맵은 일반적 텍스쳐가 아니라 채널당 32비트의 HDR 파일인
    exr 파일입니다. 아이폰 쉐이더에서는 이 이미지를 그대로 쓰기 어렵습니다.

텍스쳐는 무조건 한 장
: 텍스쳐를 여러 장으로 그리면 드로우콜이 대폭 증가하게 됩니다. 가능한한 DPcall을 줄여주도록 계획되어야 하며,
그룹지어져야 합니다. 캐릭터 커스터마이징은 상당한 부하를 유발합니다.

: 사실은 총 8장의 텍스쳐를 블렌딩 할 수 있습니다… 하지만 할 수 있다는 것이고, 멀티 패스로 그려야 하므로
시스템 부하를 각오해야만 합니다.

화면에 보이는 폴리곤은 10000 개 내외. 드로우콜은 10-30개 정도
: 관련자료를 못찾겠네요. 대략 저 정도의 데이터가 사용되어야 속도를 보장할 수 있습니다.
FOG는 사용금지.
: 느리답니다.
알파 블렌딩이 테스팅보다 빠르다
: 신기하게도 PC와는 반대로 알파 블렌딩이 테스팅보다 빠르다고 합니다. 아직 테스트는 안해봤지만…
테스팅을 위한 옵티마이즈 과정이 더 느리다던가… IOS 렌더러에서 알파 테스팅은 ‘대단히’ 비싸고 느리다고 합니다.
텍스쳐는 PVRTC 포맷을 사용합니다.
: 애석하게도 IOS 라이센스를 가지고 있는 머신에서밖에 이 옵션을 볼 수 없습니다. 일반적으로는 그냥 신경쓰지 않고 작업하는
수 밖에 없겠습니다.

====================================================================
그리고 위 내용을 근거로 만들어진 예제입니다.

RTT 라이트맵을 사용했고, 배경은 큐브맵을 이용한 스카이박스입니다.
나무는 뒷면 때문에 저런 모양으로 만들지 않는 것이 좋을 것 같습니다.

위에서 얘기한대로, 배경은 라이팅 계산을 ‘전혀’ 하지 않습니다. 오직 텍스쳐와 라이트맵만 사용합니다.
각종 Asset들은 황재철군이 만들었고, 라이트와 각종 베이킹들은 제가 제작했습니다.
본격적으로 그래픽 팀이 붙어 제작한다면 최소 이 정도 퀄리티 이상이 나올 것입니다.

이 정도가 약 13000 개 정도의 폴리곤입니다. 즉 한 번에 보일 수 있는 한계치라고 보시면 됩니다.
거리는 약 가로 세로 100미터로, 실제로는 이것을 1/4 로 나누어 50미터 단위로 끊어서 만들어 주면 안보이는 블럭을 컬링해
가면서 속도를 보장할 수 있을 것입니다. 블럭 사이즈 등에 의해서도 이 기준은 달라질 것입니다.(현재 한 블럭 사이즈는 1.7미터입니다) 또한 지형은 터레인을 사용못하고 매쉬만 사용가능하므로, 이동하지 못하는 지역의 폴리곤등은 최적화를 시켜줄 수 있습니다.

현재 캐릭터를 제외하면 1만개 정도이므로, 약 이정도 폴리곤이 ‘한 번에’ 그려질 수 있도록만 신경써 주면 됩니다.
즉 카메라 각도만 잘 조정하고 컬링만 신경쓰면 512 미터의 넓은 지형도 표현가능하다는 말씀입니다.

배경에서 사용된 드로우콜은 단 3개.
지형. 건물(들), 나무(들)
현재 저 화면에서는 캐릭터 3마리 덕분에 드로우콜이 30이 넘어 버렸습니다. 캐릭터 커스터마이징은 막아야 할 듯.
건물들과 나무들은 한 번에 로딩되는 녀석들끼리 Attach를 시켜놓는 것이 좋습니다.
PC 버전처럼 프리팹으로 복사되는 것을 기대할 수 없습니다. 그렇게 되면 라이트맵이 제대로 먹지 않습니다.
라이트맵도 3장이며, 각각 128*128로 만들어졌지만 효과는 그럴 듯 합니다.
일반 텍스쳐도 3장이며, 지형만 1024*1024 이고 건물과 나무는 256*256 으로 되어 있습니다.
아이폰에서 돌려서 테스트 해 보고 싶었지만, 현재 아이폰 팀이 삼품 작업에 올인하고 있는 관계로 수치상으로만 확인한 결과입니다. 추후 실제로 돌려서 테스트 해 보겠습니다.

최적화 링크 페이지

http://unity3d.com/support/documentation/Manual/Optimizing%20Graphics%20Performance.html#iPhoneOptimizingGraphicsPerformance

텍스쳐 데이터 일람.

* 지형 텍스쳐를 타일링 식으로 하면 이쁘지는 않아도 용량은 더 줄일 수 있습니다.

해외전문가 초청 게임제작 워크숍 라이팅 과정 후기

Tue, 21 Dec 2010 16:10:30 +0000

사정상 오전만 참여. 오후 강연은 못들음

ILM, 드림웍스, 웨타 등에서 일하신 17년 경력의 라이팅 디렉터 Kate Chio 님 강연.

피쳐(영상)는 결과 이미지가 수많은 레이어로 나뉨. 30 개도나옴

- 분위기 창작하는게 라이팅. 불만 켜는게 아니다

- 테크닉 기반 사람과 아트 기반 사람의 감각은 다르다. 테크닉 기반인 사람은 이해못하는 감각이 있다.

라이트의 종류
- spot light: 70-80% 는 스팟 라이트만 쓴다. 속도도 빠르고 싸다 ( 주: 게임에서는 스팟라이트는 무거워서 거의 안쓴다)

- point light: 촛불이나 전등에서 사용 . 비싸다. 그림자가 6개가 나온다.(렌더맨에서 6면에서 뎁스 쉐도우를 계산하기 때문) 조정이 힘들다

- area light : 사진촬영시의 소프트박스. 비싸다. 소프트하게, 넓게 소프트하게 하고 싶을 때 쓴다. 사이즈가 클수록 오래 걸린다

- indirect light : 네온을 들고 다니면 주변에 비치는 라이트. 지오메트리가 라이트가 된다.광선검 라이트 등도 마찬가지.

- directional light : 선라이트 . 위치는 상관이 없다. 넓어서 연산이 오래 걸린다.조정하기 힘들다..영역을 제한 안하면 느리기 때문이다 ( 주: 게임에서는 디렉셔널 라이트가 가장 빠르다. 하지만 영상에서는 실시간 계산은 그다지 신경쓰지 않고 얼마나 넓은 면적을 그림자 계산해야 하느냐가 시간의 관건이기 때문에 느리다고 판단하는 듯)

- ambient light : 전체의 블렉 레벨이 올라가서 잘 안쓴다. 급할때만 쓴다. 대신 environment 라이트를 쓴다

- volume light : 비싸다. cheat(fake)를 할 수 있으면 한다 ( 주: 게임에서는 거의 사용이 금지되어 있다고 봐도 좋을 정도로 잘 안쓴다)

- environment light ; 유용하다 . fake GI이다. 주변 사진을 찍어 라이팅 소스로 쓴다. 텍스쳐로 라이팅 제어한다 (주: 3dmax의 HDRI 맵을 이용한 라이트 방식을 말한다. 실시간 게임에서는 ambient cube를 이용해서 같은 효과를 낸다)

3점 라이트

- Key light : 강한 라이트

Fill light : 그림자 부분 (어두운 부분)을 채워주는 것이 필라이트

- Bakelight : 뒤에서 주제를 분리해주는 기능. 림라이트라고도 한다.

쉐도우

-조명의 반은 그림자

-아트 분들 출신이 아니면 그림자의 중요성을 잘 모른다.

-Object inter - relationship

-그림자는 라이트랑 완전히 맞추진 않는다 필요에 따라는 페이크 처리

-쉐도우맵을 일일히 체크해라. 해상도나 오브젝트가 맞는지

쉐도우 종류

Depth map shadow (뎁스 맵 쉐도우 ): interger 넘버(상수) 라서 퍼, 모션블러 워터 등 특별한 고급 계산이 안됨.. 스피드는 빠르다. ( 주: 간단하게 맥스에서 쉐도우 맵 정도의 수준)

해상도 주의. 필요없는 계산을 줄이기 위해 필요없는 쉐도우 맵은 프레이밍할 것

Bias 주의 : 그림자 옵셋. 그림자의 위차 주의할 것

- DEEP SHADOW : 퀄리티 좋음, 느려서 댑스맵과 섞어서 씀.

- Ray tracing ; 원스텝으로 쉐도우를 한번에 계산한다. 정확하지만 너무 느리다.

-쉐도우에는 블러를 좀 넣어줘야 이쁘다. 아니면 너무 강하다

-색도 좀 약하게 . 덴시티를 조절 해야 네추럴하다

-고보(Gobo) ; 치트 그림자 기법. 카메라에서 그림자 스크린 끼워주는 방식 .(주: 맥스에서 프로젝트 라이트와 같다)
예를 들어 블라인드를 표현할때 감독은 블라인드에 가려진 얼굴이라고 해도 눈은 보고싶어한다. 이럴때 맵으로 그림자가 되어 있으면 수정하기 쉽다. 공룡이 지나갈때 숲의 나무 그림자에도 쓴다.God ray(갓 레이) 효과 할때도 쓴다.

-2D라서 애니가 쉽다

-블록커(Bloacker) : 빛 막이 . 보이진 않지만 그림자는 있는 . 진짜가 아닌 의도적인 그림자를 생성하기 위한 오브젝트

-이미지의 집중 등을 위해

쉐이더의 중요성

-라이팅만으로 해결 불가. 쉐이딩이 중요함

3종류의 쉐이더

라이트 쉐이더 : 라이트의 성질을 조정해 주는 것. (주: 하프 램버트 같은…)

- 서피스 쉐이더 : 오브젝의 재질을 조정해 주기. 질감.

디스플레이스먼트 쉐이더 : 재질의 울퉁불퉁함을 조절해 준다

디스플레이스먼트와 범프의 차이

제대로된 쉐이더를 쓰는게 중요하다

글로벌 일루미네이션

-인바이론먼트 맵으로 라이트를 표현

-Hdr 이미지를 만들어 조정함

-프로덕션에서는 메우 많이씀

엠비언트 오클루젼

오버케스트 된 곳에 흰 오브젝트가 있는것이라고 생각하면 됨
돔라이트라고 생각한 소프트한 쉐도우를 말한다

(주: 캐릭터 3D 그래픽 디자이너들은 오클루젼 맵이라 부르는 것.)

(주: 프로그래머들은 스크린 스페이스 엠비언트 오클루젼 -SSAO- 라 부르는 것)

conclusion

그림자 맵을 주의하라. 대부분의 문제가 거기서 알어난다

디스플레이스먼트는 최소한으로 사용해라. 렌더타임 낭비가 있다

저해상도로 먼저 확인해라. 옵션도 끄고. 키프레임도 건너뛰고..

라이트 에니메이션은 피해라. 문제가 많이 생기더라

이름 제대로 지어라. 무슨 라이트가 무슨 라이트인지 모른다.

수시로 버전을 저장해라. 뒤로 돌아갈일 생긴다. 디렉터는 변덕스러우니까.

라이트를 종류별로 구분해 보는건 자주 일어난다. 디퓨즈나 스페큘러를 따로 보기..

범프맵과 디스플레이스먼트 차이를 알고 써라

프로시절 텍스쳐는 도움이 많이 된다

라이트는 흰색이 없다 조금이라도 색을 넣어라.

레이트레이싱의 디스턴스등. 느린요소를 찾아라. 쉐이더가 잘못되어서 느릴 수도 있다.

라이트 링크. 주인공 전용 라이트를 만들던가 하는 식으로 돋보이게 할 수도 있다.

쉐도우 치트(fake)는 늘 사용해라

인바이론먼트 맵을 블러시키면 문제가 별로 없다. 그걸 찾을땐 칼라 블록이나 번호를 그려 놓아 디버깅해라

레이어 만들어서 넣어라. 컴포지팅의 중요성

라이터들은 디버그가 주 일이다 .때문에 테크니컬 언더스테딩이 필요하다.

감상평

-한국어 서투르시지만 .알아 들을만함.
-게임쪽은 정말로 전혀 모르심
-대부분이 결과물을 빨리 뽑아내기 위한 개념으로 잡혀 있음. 때문에 게임과 목표 자체가 다른게 많음.
-몇 년 전의 파이널 판타지 무비 때의 프로세스와 그렇게 달라진게 없다. 아니, 다른 영상 업체의 프로세스도 마찬가지.
-영상쪽은 이미 파이프라인이 확실히 굳어진 느낌. 게임과는 다르다 게임과는!
-영상 업계의 프로그램 팀장같은 느낌. 디버그 전문…
-15명 참여. 평일이라 그런지 오기로 한 분들이 거의 안옴.
-학생들은 사전지식이 없으면 알아듣기 힘들듯. 특히 용어가 비슷하면서도 달라서, 원리를 이해하고 있지 않으면 못알아 들을 것 같은 말이 많음.
-원래 3번째 시간에 강사로 초청받았지만, 본인은 ‘해외전문가’ 가 아니므로 정중히 거절 ㅋㅋㅋ

exr 파일 포맷

Sat, 18 Dec 2010 16:37:39 +0000

exr 파일 포맷이란 HDR 이미지입니다. 채널당 32비트의…
사실 float 하나가 32비트인데 TGA 이미지는 겨우 8비트밖에 되지 않지요. 즉 처리할 수 있는 용량대비 너무 적은 이미지를 사용하고 있었던 것입니다.
때문에 마치 카메라의 RAW 파일처럼 깊이값이 깊은 이미지를 생성해 낼 필요가 생기는데, 이것이 exr 파일 포맷입니다.

Pro EXR 이라는 프로그램에서는 각 레이어별로 이미지의 렌더 패스를 생성하고 읽을 수 있는 모양입니다. (일부 DCC 툴에서도 가능한듯 합니다) 그렇지만 000 에서 제작된 라이트맵은 그 정도의 path를 내장하고 있지는 않더군요. (뭐 사실 당연하겠지만)
그래도 exposer 등을 조절할 수 있는 것은 꽤 마음에 듭니다. - 그렇다는 것은 툴 안에서도 조정할 수 있다는 뜻일텐데요-

첨부한 exOpenEXR_Photoshop-1.2.1.Win.zip 을 포토샵 플러그인 폴더에 설치하면 exr 파일을 불러들일때 노출값등을 조절할 수 있습니다.

OpenEXR is a high dynamic-range (HDR) image file format developed by Industrial Light & Magic for use in computer imaging applications.

OpenEXR is used by ILM on all motion pictures currently in production. The first movies to employ OpenEXR were Harry Potter and the Sorcerers Stone, Men in Black II, Gangs of New York, and Signs. Since then, OpenEXR has become ILM’s main image file format.

OpenEXR’s features include:

Higher dynamic range and color precision than existing 8- and 10-bit image file formats.* Support for 16-bit floating-point, 32-bit floating-point, and 32-bit integer pixels. The 16-bit floating-point format, called “half”, is compatible with the half data type in NVIDIA’s Cg graphics language and is supported natively on their new GeForce FX and Quadro FX 3D graphics solutions.* Multiple lossless image compression algorithms. Some of the included codecs can achieve 2:1 lossless compression ratios on images with film grain.* Extensibility. New compression codecs and image types can easily be added by extending the C++ classes included in the OpenEXR software distribution. New image attributes (strings, vectors, integers, etc.) can be added to OpenEXR image headers without affecting backward compatibility with existing OpenEXR applications.

ILM has released OpenEXR as free software. The OpenEXR software distribution includes:

IlmImf, a library that reads and writes OpenEXR images.* Half, a C++ class for manipulating half values as if they were a built-in C++ data type.* Imath, a math library with support for matrices, 2d- and 3d-transformations, solvers for linear/quadratic/cubic equations, and more.* exrdisplay, a sample application for viewing OpenEXR images on a display at various exposure settings.

Commented by

둘리바보at 2007/04/15 01:07 #

제가 아는대로 exr 파일에 대해 말씀드리자면.. 합성시에 여러가지 렌더패스들을 하나의 파일에 다 넣어서 렌더링 하는 방식입니다. 그렇게 되면 합성시에 패스별로 이미지들을 일일이 로드하지 않아도 되니 작업이 훨씬 수월해 지겠죠?
마야의 렌더글로벌에 보면 exr을 지원하기는 하지만 아직까지는 여러가지 렌더 패스들을 한번에 다 넣을수는 없는걸로 알구요 현재로는 렌더맨이 유일한걸로 알고있습니다. 멘탈레이도 제약이 있지만 지원한다고 하네요.. ^^;

http://www.openexr.com 이 사이트에 가시면 저 많은 자료들이 있으니 참고하시구요 도움이 되셨길 바랍니다 ^^;

-http://blog.naver.com/lm76?Redirect=Log&logNo=44692201

포토샵이나 에프터이펙트 의 경우 최근의 CS3 까지도 멀티채널 exr 파일을 직접 지원하지 않습니다.

따라서 ProEXR 같은 플러그인 등을 사용하여야 합니다. http://www.fnordware.com/ProEXR

이 플러그인을 사용하게 되면 포토샵 같은 경우 각 패스들이 레이어로 구분이 되어 불러와집니다.

http://billywagner.blog.me/150085181911-

뭐야 이게;;;

Sat, 18 Dec 2010 01:40:32 +0000

조카네서 전화가 와서 찾아봤더니 진짜 올라와 있네요 ㄷㄷㄷㄷ

7차개정 초등학교 6-2 교과서에 임진록이 올라와 있다니 ㄷㄷㄷㄷ 그것도 임진록2+ 조선의 반격 (일명 조반) 이네요 ㄷㄷㄷㄷ

살아생전에 교과서에 실리는 영광이 ㄷㄷㄷㄷㄷㄷㄷ

일단 결정. AT2 제작사양및 옵션 결정

Fri, 17 Dec 2010 18:25:42 +0000

AT2 클라이언트 사양.
짧은 시간만에 테스트해서 나온 결과라 얼마나 정확할지는 잘 모르겠지만 어쨌건 나름대로 분석해 봤슴당.

일단 그래서 나온 잠정결정. 결론부터 얘기하기.

권장사양.

CPU ………… Pentium4 Dual(=하이퍼쓰레딩: 가상으로 CPU를 2개인 것 처럼 돌림) 3.2GHz (프레스캇) 이상
RAM ……….. 2Gbyte
HDD ………… 글쎄요 이건 나중에
VGA ……….. GeForce 7600 GS (256M) 이상
네트웍 사양…….. 왠지 있어야 할 것 같다는

CPU 벤치마크 . 524점. 사실 이젠 추억속의 CPU

아이온의 권장사양이 Pentium Dual Core 이상으로 535점입니다. 대략 비슷한 정도로 보입니다.
WOW 의 권장사양 역시 Pentium Dual Core, 2G , 8600으로 CPU는 비슷하지만 그래픽 카드는 와우의 사양이 더 높습니다.
리니지2 의 권장사양은 코어2 DOU 6300 이상을 요구하고 있습니다. (대규모 공성전 때문인가) 압도적으로 높은 사양입니다.
대신 메모리는1G로 낮고, 그래픽 카드는 7600으로 우리와 동일합니다.
그라나도 에스파다는 역시 권장사양으로 Core2 Duo 를 요구하고 있고 메모리는 2G, 그래픽 카드는 8600 GT로 전체적으로 우리보다 높은 사양을 요구하고 있습니다.

이렇듯 일반적인 MMORPG와 비교하였을때 비슷하거나 살짝 가벼운 수준을 요구하고 있는 것을 알 수 있습니다.

최소사양

CPU ……….. 펜4 2.4GHz (노스우드)
RAM ……….. 1Gbyte
HDD ………… 글쎄요 이건 나중에
VGA ……….. GeForce 6600 이상
네트웍 사양…….. 왠지 있어야 할 것 같다는

최저 옵션에서 약 15프레임 이상을 유지하면서 게임을 진행할 수 있습니다. 옵션 조정이나 일부 데이터를 포기함으로써 최저사양을 좀 더 내릴 수 있는 여지도 있습니다. CPU 벤치마크 위치는 다음과 같습니다.

참고로
아이온의 최소사양이 Pentium4 2.8G 이며, 그래픽 카드를 Geforce 6600 이상을 요구하고 있습니다. 거의 사양이 비슷하거나 우리가 살짝 낮은 정도입니다. 하지만 아이온은 실제 이 사양에서 게임을 진행하기 거의 불가능합니다.
WOW의 최저사양은 Pentium4 1.3G 이며 메모리 1G , 그래픽 카드는 지포스 FX 이상을 요구하고 있습니다. 거의 AT1과 맞먹는 사양요구입니다. 사실상 이 사양에서도 현재의 AT2는 돌아는 갑니다만, 약 3-4 프레임을 보입니다.
리니지2의 최저사양은 ‘기본 사양’ 이라고 불리며, Pentium4 3.0 이상을 요구합니다 (아이온보다 높습니다) 메모리는 1G , 그래픽 카드는 6600 이상을 요구합니다. 게임을 업그레이드 하면서 사양도 대폭 증가해서, 이제는 최저사양이 아이온보다 높을 정도입니다.
그라나도 에스파다는 Pentium4 2G 이상을 요구하며 메모리 512M , 지포스 FX 이상을 요구하고 있습니다. 역시 AT2 보다 조금 낮은 정도입니다.

최저사양은 다른 게임과 비슷하거나 살짝 높은 정도이긴 합니다만, 최저사양으로 하더라도 현재 AT2는 ‘해상도를 떨어뜨리지 않고도 원활하게 게임 플레이가 가능한’ 수준을 기준으로 잡았으므로, 단순비교만으로는 쉽게 말할 수 없습니다.
사실 같은사양에 지포스 FX5700 정도로도 원활히 플레이가 가능하였습니다만, 조금 여유를 두고 잡았습니다.

옵션

게임에서 사용할 옵션에 대한 제한 사양입니다.
가능한한 값싸고 효과좋은 옵션은 최후까지 남기고, 부하를 유발하면서 효과가 상대적으로 적은 옵션은 고급 사양으로 남겨둡니다. 또한 각 옵션은 커스텀으로 조절할 수 있도록 만듭니다.

지형의 LOD
터레인의 LOD은 자동으로 이루어 지고 있습니다. 그렇지만 통맵던전은 LOD가 이루어 지지 않습니다. 뭐 그래도 통맵은 어클루젼만 잘 처리해 준다면 터레인보다 가볍다는 것이 일반적 통설입니다. 통맵을 제작할 때는 이 점을 고려해 주시기 바라겠습니다.

건물의 LOD

기본적으로 건물은 굳이 LOD를 제작할 필요는 없습니다. 그렇지만 멀리 보이는 성 등은 LOD를 제작하는 것이 좋을 경우도 있습니다. 이런 경우에는 case by case로 처리해 주십시오. 저사양 옵션이 될 때 프러스컴 컬링의 Far 를 당겨서 처리합니다.

캐릭터의 LOD

캐릭터는 스키닝 부하가 퍼포먼스에 큰 영향을 끼치므로, 본 LOD와 매쉬 LOD 를 모두 사용해야만 합니다. 문제는 그래도 무겁다는 것인데… 필드에서 일부 거리이상 혹은 일부 개수 이상의 주인공급 캐릭터 (NPC는 제외) 가 보인다면, “렌더링을 포기하고 머리 위 이름만 나타나게 합니다.” 가장 직설적이고 무식한 방법이지만 효과는 최고로 좋은 방법입니다. 가까이 전진할때 로딩랙이 생길 것을 예상할 수 있지만, 분할로딩 방법이 가능한지 알아본다던가 등으로 해결하도록 합시다.

기타 옵션

기타 옵션들은 다음과 같습니다. 일반적으로는 Bootcamp를 많이 참고했습니다만, 우리 게임의 특성에 맞도록 개조한 부분도 있습니다.
* 기본은 ‘일반’ 옵션입니다.

데이터 제작 가이드라인

다음은 그래픽 데이터를 제작하기 위한 가이드라인입니다. 다행히 엔진이 좋아서 수시로 현재의 데이터 상황을 체크할 수 있습니다.

배경

건물은 1개의 UV만 사용하십시오 2개의 UV는 라이트맵 연산에 문제를 일으킬 수 있습니다. 반드시 1개만 사용해 주십시오. 혹시 라이트맵이 특별한 UV를 사용하길 원한다면, 라이트맵을 위한 UV2를 만들 수는 있겠습니다. 담당팀장의 허가를 득하세요.

- 텍스쳐는 가급적 1개의 슬롯, 또는 2개의 슬롯을 사용해 주십시오 (멀티 - 서브 텍스쳐 사용을 최대한 자제해 주심시오)
만에 하나 커다란 건물이나 특별히 유니크한 건물에는 3개 이상의 멀티 서브 텍스쳐를 사용할 수도 있겠지만, 이 경우는 말그대로 매우 유니크한 경우로 제한합니다. 담당팀장의 허락을 반드시 득하시기 바랍니다.

엔진에서 [DrawCall] 수치를 민감하게 확인하십시오! 가벼운 오브젝트로 만들었다 하더라도 그 오브젝트가 너무 많이 보인다면 드로우 콜은 급격히 올라갈 것입니다. 반대로 무거운 오브젝트를 만들었다 하더라도, 화면에 그 오브젝트만 보일 정도로 크거나 시야를 가린다면 드로우 콜은 떨어질 것입니다. 이렇게 드로우 콜이 떨어지는 뷰라면, 텍스쳐 슬롯을 더 사용하거나 오브젝트를 축가로 더 설치해서 퀄리티를 높일 수 있습니다.
권장사양에서 원활하게 돌아갈 수 있는 적정한 드로우콜은 , 1000 정도입니다.(캐릭터까지 포함해서 권장하는 드로우콜은 1500 정도입니다) 가능한한 이 이하로 맞춰주시길 부탁드립니다. 재미있는 아이디어로는, 캐릭터가 많이 나오지 않을 것 같은 지역에서는 1000 또는 1100등과 같이 슬금슬금 더 높여 주셔도 됩니다. 반대로 사람이 많이 모일 것 같은 광장지역이나, 초반 마을 같은 경우에는 500 등과 같이 평소보다 적은 수치로 만들어 주시기 바랍니다.
표준건물의 폴리곤은 2500개 정도로 결정하였습니다. 이건 배경팀에서 표준 건물을 가지고 있을 것입니다. 물론 가능한한 적으면 좋습니다. 그렇지만 가급적 1000 이하의 오브젝트는 피해주시기 바랍니다. 너무 적은 폴리곤을 가지고 있는 오브젝트나 건물도 퍼포먼스에 좋지 않은 영향을 줍니다. 200 폴리곤짜리 오크통을 5개 늘어 놓는 것 보다는, 5개의 오크통을 하나의 오브젝트로 만드십시오.

캐릭터

캐릭터에서의 퍼포먼스는 거의 스키닝이 관건을 보이고 있습니다. 파츠별 구분도 상당히 중요한 관건을 보이고 있구요.
때문에 폴리곤이 줄어든다면 퍼포먼스의 향상을 보일 수 있습니다. 그렇지만 너무 줄이기만 한다면 데이터 외형에 심각한 문제를 일으킬 수 있습니다.
주인공 캐릭터는 5000개 미만으로 사용할 것을 권고합니다. 할 수 있다면 3000대로 줄여도 좋습니다. Look 이 손상되지 않는 범위 내에서 최대한 줄여 주십시오. 주인공의 스키닝은 줄이면 줄일수록 프레임 향상이 큽니다.
NPC나 몬스터 류 들은 상대적으로 캐릭터 보다는 부하에 대한 영향이 적습니다, 그렇지만 가능한한 줄여 주시는 것이 좋습니다. 유니티 엔진은 스키닝의 프레임 저하가 특히 큰 것으로 보고되었습니다.
몬스터의 Bone 개수는 특히 주의해 주십시오. 팔이나 다리가 많이 달린 몬스터는 퍼포먼스에 악영향을 줄 수도 있습니다.
물리에 대해서는 재 협상해야 합니다. 사용한다면 옵션에 따라 ‘사용할지 않을때’ 는 어떻게 처리해야 할지에 대한 얘기도 진행해야 합니다. 물리 에니메이션이 Bone 에니메이션으로 교체되는 것은 사실상 힘들기 때문에, 물리 에니메이션이 꺼질 때에는 ‘안 움직이는 ’ Attachment가 된다는 점을 고려해야 합니다. 추천은 ‘사용하지 않음’ 입니다.
당연하게도, 최대한 Texture 를 합쳐 주십시오. 배경과 마찬가지로, 가능한한 1장으로 처리해 주시길 권고하며 특이한 경우에는 2장을 사용하도록 조정해 주시기 바랍니다.

기타 (이펙트 / UI)

이펙트나 UI 에서 고려할 내용들은 다음과 같습니다.

실시간 조명
디퍼드 렌더링 방식에서는 실시간 라이트에 대한 부하가 매우 적은 것으로 알려져 있습니다. 기존의 포워드 방식의 랜더링에서는, 조명이 한 개가 추가된다면 게임에 있는 모든 Asset들에게 조명 연산을 추가로 해 줘야 합니다. (실제로 사용하지 않더라도 말입니다) 그렇지만 디퍼드 렌더링 방식의 엔진은, 화면에 보이는 것의 노말데이터를 따로 버퍼로 출력해 낸 다음 그 데이터만을 가지고 조명연산을 하므로 실시간 조명 연산이 필요하다 하더라고 포워드 렌더링 방식과는 비교도 할 수 없을만큼 빠르며 유동적입니다. 그렇다고 마구 사용하는 것은 물론 적절하지 않은 선택입니다. 가급적 꼭 필요한 곳에만 실시간 조명을 사용하시기 바랍니다.
허용되는 실시간 조명은 포인트 라이트입니다.
파티클
파티클은 예나 지금에나 부하를 유발하는 심각한 물건이었습니다. 가급적 파티클 사용을 자제해 주시기 바랍니다. 말은 이렇게 해도 사실 제작할 때 힘들다는 것은 알고 있습니다만…
아래 옵션으로 내려가면 파티클을 제거할 수 있으므로, 이를 감안하셔서 되도록이면 파티클 사용을 자제해 주십시오.
빨리 쉐이더로 지원해야 하는데….
UI의 드로우 콜
UI의 드로우 콜 점유는 언제나 심각한 문제였으며, 지금도 또한 그렇습니다. 가능한한 텍스쳐를 합쳐 주십시오. UI는 일반적으로 한 번에 로딩되며 바뀌는 일이 적기 때문에, 가능한한 모든 UI를 한 장의 텍스쳐로 넣는 것이 가장 이상적이긴 합니다. 다소 크기가 크더라도 그렇게 진행해 주시기 바랍니다.

변수
네트워크 환경과 엔진의 한계가 제일 큰 변수입니다. 웹게임을 한 번도 만들어 본 적이 없기 때문에, 데이터 스트리밍이 어떤 느낌으로 진행될지 알 수가 없으니까요. 그래서 웹으로도 제작되었던 Bootcamp를 일단 Base로 하고 만들었던 것입니다.
잦은 로딩이 일어나야 하는 (전투맵) 우리 게임에서 이 엔진이 어떻게 반응할지 알 수 없습니다.

캐릭터별 100마리 카피 데이터 비교

Fri, 17 Dec 2010 13:50:30 +0000

사양은 역시 이전에 올린 권장사양에서 테스트 되었습니다.
2기가 메모리인줄 알았더니 하나가 256이 꽃혀 있어서 사실은 1792M 였다는 소소하지만 놀라운 사실.

기본적인 테스트가 끝난 상태에서 이번 테스트의 목적은 ‘주인공 캐릭터의 폴리곤이 더 적을때와 NPC로 대치되었을때의 비교’ 였습니다.
캐릭터만 놓고 따로 비교하는 것은 뭐 분명 차이가 있을게 뻔하기 때문에, 배경과 함께 있는 상태에서 테스트 되었습니다.

방법은 역시 배경 테스트 할 때 가장 무거운 뷰에서,

주인공 4800 폴리곤 100마리 카피,
주인공 2700 캐릭터 100마리 카피,
NPC 3400 폴리곤 100마리 카피였습니다.

대충 이런 환경.

비교 결과데이터는 다음과 같습니다.
Total 메모리와 Object count 에도 변동이 있긴 하지만 큰 수치가 아니인 데다가, 당연하게 예상할 수 있는 정도이기 때문에 넘어감.

그럼 이제부터 데이터 분석.

프레임 비교입니다. 4800 캐릭터 데이터보다 2700 캐릭터가 월등히 높은 수치를 보입니다. 특히 옵션을 내릴 수록 프레임이 벌어지는 것을 볼 수 있는데, 이 것은 옵션을 낮출수록 렌더링 부하는 줄어들면서, 스키닝 부하가 높게 비율을 차지하게 바뀐다는 것입니다. 실제로 상위 옵션에서는 스키닝이 34% 정도의 부하를 가지고 있다가 옵션을 낮추니 55% 정도(가끔 74%) 올라가는 것을 알 수 있습니다. 즉 “스키닝 부하를 줄이면 다른 데이터를 줄이는 것보다 훨씬 더 저사양 커버리지가 높아진다"는 것을 알 수 있습니다.

그리고 이것은 다시 Drawcall 비교를 해 보아도 증명이 됩니다. Drawcall은 배경의 수치가 줄어드는데 더 영향을 받게 되고, 그에 따라 수치가 변동되었지만, 덕분에 스키닝의 부하 비율이 늘어나면서 프레임이 저하되었다는 것을 알 수 있습니다.

또 하나 덤으로 재미있는 수치는, 2700 주인공일때 실시간 그림자가 없어지는 simple 모드에서 배치가 118로 증가했다는 것입니다. 이것만 봐서는 실시간 그림자와 Batch의 상관관계를 예상할 수 있는데, 이번에는 NPC3400이 Good 모드에서 배치가 22가 나왔습니다. 신기하기도 하지…

어쨌건 결론적으로 캐릭터, 특히 스키닝(Skinning) 되는 주인공 캐릭터는 사양 결정에서 높은 비율을 차지하는 역할을 하고 있다는 것을 알 수 있습니다. 다른 게임도 이를 잘 알고 있기 때문에 갖가지 꼼수를 사용하곤 하는데요. 우리는 어떤 방법을 사용해야 할까요? (이미 생각해 놓은거 있으면서 질문하기 ㅋ )

그리고 그 전에, 캐릭터의 폴리곤(특히 본)과 파츠의 개수는 최대한 줄이는 것이 유니티 엔진에서는 더욱 효과가 크다는 결과가 나타났으므로 캐릭터 제작시 폴리곤과 본을 엄밀하게 관리하여 제작해야 할 것입니다.

사양결정중

Fri, 17 Dec 2010 10:42:12 +0000

최소 최대 사양 및 제약사항 결정중. 오늘 끝내자

Lightmapping In-Depth

Wed, 15 Dec 2010 03:52:01 +0000

If you are about to lightmap your first scene in Unity, this Quickstart Guide might help you out. Lightmapping is fully integrated in Unity, so that you can build entire levels from within the Editor, lightmap them and have your materials automatically pick up the lightmaps without you having to worry about it. Lightmapping in Unity means that all your lights’ properties will be mapped directly to the Beast lightmapper and baked into textures for great performance. Unity Pro extends this functionality by Global Illumination, allowing for baking realistic and beautiful lighting, that would otherwise be impossible in realtime. Additionally Unity Pro brings you sky lights and emissive materials for even more interesting scene lighting. In this page you will find a more in-depth description of all the attributes that you can find in the Lightmapping window. To open the Lightmapping window select Window – Lightmapping. Object

Per-object bake settings for lights, mesh renderers and terrains - depending on the current selection.

Mesh Renderers and Terrains:



Static	Mesh Renderers and Terrains have to marked as static to be lightmapped.
Scale In Lightmap	(Mesh Renderers only) Bigger value will result in more resolution to be dedicated to the give mesh renderer. The final resolution will be proportional (Scale in lightmap)(Object’s word-space surface area)(Global bake settings Resolution value). A value of 0 will result in the object not being lightmapped (it will still affect other lightmapped objects).
Lightmap Size	(Terrains only) Lightmap size for this terrain instance. Terrains are not atlased as other objects - they get their individual lightmaps instead.
Atlas	Atlasing information – will be updated automatically, if Lock Atlas is disabled. If Lock Atlas is enabled, those parameters won’t be modified automatically and can be edited manually.
Lightmap Index	An index into the lightmap array.
Tiling	(Mesh Renderers only) Tiling of object’s lightmap UVs.
Offset	(Mesh Renderers only) Offset of object’s lightmap UVs.

Lights:



Lightmapping	The Lightmapping mode: Realtime Only, Auto or Baked Only. See Dual Lightmaps description below.
Color	The color of the light. Same property is used for realtime rendering.
Intensity	The intensity of the light. Same property is used for realtime rendering.
Bounce Intensity	A multiplier to the intensity of indirect light emitted from this particular light source.
Baked Shadows	Controls whether shadows are casted from objects lit by this light (controls realtime shadows at the same time in case of Auto lights).
Shadow Radius	(Point and Spot lights only) Increase this value for soft direct shadows - it increases the size of the light for the shadowing (but not lighting) calculations.
Shadow Angle	(Directional lights only) Increase this value for soft direct shadows - it increases the angular coverage of the light for the shadowing (but not lighting) calculations.
Shadow Samples	If you’ve set Shadow Radius or Angle above zero, increase the number of Shadow Samples as well. Higher sample numbers remove noise from the shadow penumbra, but might increase rendering times.

Bake

Global bake settings.



Mode	Controls both offline lightmap baking and runtime lightmap rendering modes. In Dual Lightmaps mode both near and far lightmaps will be baked; only deferred rendering path supports rendering dual lightmaps. Single Lightmaps mode results in only the far lightmap being baked; can also be used to force single lightmaps mode for the deferred rendering path.
Quality	Presets for high (good-looking) and low (but fast) quality bakes. They affect the number of final gather rays, contrast threshold and some other final gather and anti-aliasing settings.
Bounces	The number of light bounces in the Global Illumination simulation. At least one bounce is needed to give a soft, realistic indirect lighting. 0 means only direct light will be computed.
Sky Light Color	Sky light simulates light emitted from the sky from all the directions - great for outdoor scenes.
Sky Light Intensity	The intensity of the sky light - a value of 0 disables the sky light.
Bounce Boost	Boosts indirect light, can be used to increase the amount of bounced light within the scene without burning out the render too quickly.
Bounce Intensity	A multiplier to the intensity of the indirect light.
Final Gather Rays	The number of rays shot from every final gather point - higher values give better quality.
Contrast Threshold	Color contrast threshold, above which new final gather points will be created by the adaptive sampling algorithm. Higher values make Beast be more tolerant about illumination changes on the surface, thus producing smoother but less-detailed lightmaps. Lower numbers of final gather rays might need higher contrast threshold values not to force additional final gather points to be created.
Interpolation	Controls the way the color from final gather points will be interpolated. 0 for linear interpolation, 1 for advanced, gradient-based interpolation. In some cases the latter might introduce artifacts.
Interpolation Points	The number of final gather points to interpolate between. Higher values give more smooth results, but can also smooth out details in the lighting.
Ambient Occlusion	The amount of ambient occlusion to be baked into the lightmaps. Ambient occlusion is the visibility function integrated over the local hemisphere of size Max Distance, so doesn’t take into account any lighting information.
Max Distance	Beyond this distance a ray is considered to be unoccluded. 0 stands for infinitely long rays.
Contrast	Controls the transition between fully occluded to not occluded.
Lock Atlas	When Lock Atlas is enabled, automatic atlasing won’t be run and lightmap index, tiling and offset on the objects won’t be modified.
Resolution	The resolution of the lightmaps in texels per world unit, so a value of 50 and a 10unit by 10unit plane will result in the plane occupying 500x500 pixels in the lightmap.

Maps

The editable array of all the lightmaps.



Compressed	Toggles compression on all lightmap assets for this scene.
Array Size	Size of the lightmaps array (0 to 254).
Lightmaps Array	The editable array of all the lightmaps in the current scene. Unassigned slots are treated as black lightmaps. Indices correspond to the Lightmap Index value on Mesh Renderers and Terrains. Unless Lock Atlas is enabled, this array will get auto-resized and populated whenever you bake lightmaps.

Lightmap Display

Utilities for controlling how lightmaps are displayed in the editor. Lightmap Display is a sub window of the Scene View, visible whenever the Lightmapping window is visible.



Use Lightmaps	Whether to use the lightmaps during the rendering or not.
Shadow Distance	The distance at which Auto lights and Close By lightmaps fade out to just Far Away lightmaps. This setting overrides but not overwrites the QualitySettings.shadowDistance setting.
Show Resolution	Toggles the scene view Lightmap Resolution mode, which allows you to preview how you spend your lightmap texels on objects marked as static.

Details

Dual Lightmaps

Dual lightmaps is Unity’s approach to make lightmapping work with specular, normal mapping and proper blending of baked and realtime shadows. It’s also a way to make your lightmaps look good even if the lightmap resolution is low.

Dual lightmaps can only be used in the Deferred Lighting rendering path.

Dual lightmaps use two sets of lightmaps:

Far: Contains full illumination* Near: Contains indirect illumination from lights marked as Auto, full illumination from lights marked as Bake Only, emissive materials and sky lights.

Realtime Only lights are never baked. The Near lightmap set is used within the distance from the camera smaller than the Shadow Distance quality setting.
Within this distance Auto lights are rendered as realtime lights with specular bump and realtime shadows (this makes their shadows blend correctly with shadows from Realtime Only lights) and their indirect light is taken from the lightmap. Outside Shadow Distance Auto lights no longer render in realtime and full illumination is taken from the Far lightmap (Realtime Only lights are still there, but with disabled shadows).

The scene below contains one directional light with lightmapping mode set to the default Auto, a number of static lightmapped objects (buildings, obstacles, immovable details) and some dynamic moving or movable objects (dummies with guns, barrels). The scene is baked and rendered in dual lightmaps mode: behind the shadow distance buildings are fully lit only by lightmaps, while the two dummies are dynamically lit but don’t cast shadows anymore; in front of the shadow distance both the dummy and static lightmapped buildings and ground are lit in realtime and cast realtime shadows, but the soft indirect light comes from the near lightmap.

Single Lightmaps

Single Lightmaps is a much simpler technique, but it can be used in any rendering path. All static illumination (i.e. from baked only and auto lights, sky lights and emissive materials) gets baked into one set of lightmaps. These lightmaps are used on all lightmapped objects regardless of shadow distance.

To match the strength of dynamic shadows to baked shadows, you need to manually adjust the Shadow Strength property of your light:

Adjusting Shadow Strength of a light from the original value of 1.0 to 0.7.

Lightmapped Materials

Unity doesn’t require you to select special materials to use lightmaps. Any shader from the built-in shaders (and any Surface Shader you write, for that matter) already supports lightmaps out of box, without you having to worry about it - it just works.

Lightmap Resolution

With the Resolution bake setting you control how many texels per unit are needed for your scene to look good. If there’s a 1x1 unit plane in your scene and the resolution is set to 10 texels per unit, your plane will take up 10x10 texels in the lightmap. Resolution bake setting is a global setting. If you want to modify it for a special object (make it very small or very big in the lightmap) you can use Scale in Lightmap property of Mesh Renderers. Setting Scale in Lightmap to 0 will result in the object not being lightmapped at all (it will still influence lightmaps on other objects). Use the Lightmap Resolution scene view render mode to preview how you spend your lightmap texels.

Lightmap Resolution scene view mode visualising how the lightmap texels are spent (each square is one texel).

UVs

A mesh that you’re about to lightmap needs to have UVs suitable for lightmapping. The easiest way to ensure that is to enable the Generate Lightmap UVs option in Mesh Import Settings for a given mesh.

For more information see the Lightmap UVs page.

Material Properties

The following material properties are mapped to Beast’s internal scene representation:

Color* Main Texture* Specular Color* Shininess* Transparency + Alpha-based: when using a transparent shader, main texture’s alpha channel will control the transparency+ Color-based: Beast’s RGB transparency can be enabled by adding a texture property called _TransparencyLM to the shader. Bear in mind that this transparency is defined in the opposite way compared to the alpha-based transparency: here a pixel with value (1, 0, 0) will be fully transparent to red light component and fully opaque to green and blue component, which will result in a red shadow; for the same reason white texture will be fully transparent, while black texture - fully opaque.* Emission + Self Illuminated materials will emit light tinted by the Color and Main Texture and masked by the Illum texture. The intensity of emitted light is proportional to the Emission property (0 disables emission).

Note: When mapping materials to Beast, Unity detects the ‘kind’ of the shader by the shader’s properties and path/name keywords such as: ‘Specular’, ‘Transparent’, ‘Self-Illumin’, etc.

Advanced

Automatic Atlasing

Atlasing (UV-packing) is performed automatically every time you perform a bake and normally you don’t have to worry about it - it just works.

Object’s world-space surface area is multiplied by the per-object Scale In Lightmap value and by the global Resolution and the result determines the size of the object’s UV set (more precisely: the size of the [0,1]x[0,1] UV square) in the lightmap. Next, all objects are packed into as few lightmaps as possible, while making sure each of them occupies the amount of space calculated in the previous step. If a UV set for a given object occupies only part of the [0,1]x[0,1] square, in many cases atlasing will move neighboring UV sets closer, to make use of the empty space.

As a result of atlasing, every object to be lightmapped has it’s place in one of the lightmaps and that space doesn’t overlap with any other object’s space. The atlasing information is stored as three values: Lightmap Index, Tiling (scale) and Offset in Mesh Renderers and as one value: Lightmap Index in Terrains and can be viewed and modified via the Object pane of the lightmapping window.

Right-clicking a lightmap allows to select all game objects, that are using the chosen lightmap. Lightmaps of the active object from the current selection will be highlighted in yellow.

Atlasing can only modify per-object data which is Lightmap Index, Tiling and Offset and can not modify the UV set of an object, as the UV set is stored as part of the shared mesh. Lightmap UVs for a mesh can only be created at import time using Unity’s built-in auto-unwrapper or in an external 3D package before importing to Unity.

Lock Atlas

When Lock Atlas is enabled, automatic atlasing won’t be run and Lightmap Index, Tiling and Offset on the objects won’t be modified. Beast will rely on whatever is the current atlasing, so it’s the user’s responsibility to maintain correct atlasing (e.g. no overlapping objects in the lightmaps, no objects referencing a lightmap slot past the lightmap array end, etc.).

Lock Atlas opens up the possibility for alternative workflows when sending your object’s for lightmapping. You can then perform atlasing manually or via scripting to fit you specific needs; you can also lock the automatically generated atlasing if you are happy with the current atlasing, have baked more sets of lightmaps for your scene and want to make sure, that after adding one more object to the scene the atlasing won’t change making the scene incompatible with other lightmap sets.

Remember that Lock Atlas locks only atlasing, not the mesh UVs. If you change your source mesh and the mesh importer is set to generate lightmap UVs, the UVs might be generated differently and your current lightmap will look incorrectly on the object - to fix this you will need to re-bake the lightmap.

Custom Beast bake settings

If you need even more control over the bake process, see the custom Beast settings page.

Page last updated: 2010-11-02

[미션2] MIO GPS Car Kit 과 함께하는 일상 : 그리스 요리점 산토리니

Sun, 12 Dec 2010 22:28:46 +0000

MIO GPS Car Kit 과 함께하는 일상 :

그리스 요리점 “산토리니”

1부에서는 아이폰과 아이팟 터치에 사용가능한 , GPS 내장형 거치대 및 블루투스 핸즈프리 기능까지 가지고 있는 미오카킷의 외형에 대해 알아보았습니다. 뭐 외형이나 포장은 그걸로 됐고…

2부로는 사실 차량에 설치하기, 차량에서 사용가능한 기능 소개, 실제로 GPS 감도가 얼마나 올라갔나, 응용은 이렇게, 블루투스 핸즈프리 기능은 이러쿵저러쿵… 등등에 대한 얘기를 하려고 잔뜩 준비하고 있었는데

정작 발표된 2차 미션은 “미오 카킷과 함께 하는 일상이야기” 네요 OTL

세상은 역시 생각대로 되지 않습니다 ㅎㅎ

그나마 다행인건, ‘리뷰처럼 보이지 않고 그냥 여행기처럼 쓰면서 자연스럽게 이 제품 최고예요 라는 말을 넣을것 ’ 이라는 어려운 주문이 들어오지 않고, 자유스럽게 쓰도록 되었다는 걸까요. 어차피 그렇게 의식적으로 쓰면 더 글이 어색해져서 읽는 사람들의 기분상하는 글이 되어 버릴 수 있으니까요. 리뷰라는거 밝히고 쓰면 되는 겁니다. 재미있으면 어차피 보는 법.

장착완료

… 어쨌거나 장착은 잘 했습니다. (장착기 쓰려고 찍어놓은 사진 대 방출)

차가 요상한 곡선이 많아서 붙일 만한데가 없어유…
그렇다고 유리창에 붙이면 너무 멀어져서 조작하기가 힘들고요

이럴때 유용한 프리무브 거치대 (별매품) 이라는게 있는데 아직 배송이 안온 상태라서 말이죠. 붙이고 테스트는 해 봐야 할텐데…

어쨌거나 프리무브 거치대가 오기 전까지는, 동봉된 겔패드 판을 이용해서 저기에 거치하기로 결정.
운전대에서 손을 떼지 않은채로 손가락만으로 조작할 수 있는 위치입니다.

자세한 장착기와 작동기는 다음 기회에 올리도록 하지요. :)
오늘은 실제 사용기로 작동기를 대신하도록 하겠습니다. - 어차피 장착하고 첫 장거리 (?) 나들이이기도 하였으므로..

12월 10일, 비가 내린 금요일.

저녁약속이 잡혔습니다. 모이는 인원은 제 논문 심사때 도움을 많이 주신 교수님과, 곧 미국으로 갈 대학원 동기, 그리고 또 한명의 디자이너 아가씨. 4명이 모이는 [저녁 수다 및 디너타임]

연말이 되면 느낌좋은 분들끼리 서로 왜 보고 싶어지잖아요.
전부 간만에 보는 얼굴들이라 기대만땅.

아이 씐나.

“교수님이 이태원으로 오시라는데요”

이태원?

“교수님 회사가 거기잖아요”
… 그걸 내가 어떻게 알어

… 이태원이라. 서울에 30년을 넘게 살았지만 이태원을 가본 적은 없어유 OTL
왠지 가면 막 외국 같을지도 몰라. 수제버거가 맛있다는데 막상 갔더니 막 험상궂은 흑인 아저씨들이 모여서 웅성대고 있으면 어떡해.. 호, 혹시 권총가지고 다니는 사람도 있는건 아닐까 ㄷㄷㄷ
(이러면서 미국은 어떻게 갔다 왔을까…)

이미지는 뭐 대충 이런 느낌.

아랫쪽 사진에 신경쓰면 지는 겁니다.

어쩔 수 없습니다. 강동쪽에서만 살아왔던 외길 30년, 이태원으로 가야지요.
게다가 전 모태길치, 네비게이션 없으면 절대로 아무데도 못 갑니다. ㄷㄷㄷ

드디어 이 놈을 제대로 써먹을 때가 왔습니다.

그 동안에도 사실 그냥 겔패드로 아이폰만 딸랑 거치해서 네비게이션으로 사용해 왔는데, 아이폰의 비루한 GPS와 불편한 위치 때문에 이만저만 고생이 아니었거든요 (1부 리뷰 참고)

이제 GPS도 미오카킷으로 보강되었겠다, 위치도 조작하기 딱 좋은 곳으로 바뀌었겠다
자신감있게 찾아갈 수 있을 것으로 보입니다. 최소한 빌딩 숲 안에서 빙글빙글 돌면서 3분동안 재탐색 하지는 않겠죠.

장착 완료. 간단하게 꽂아주고 머리를 눌러 조여주면 충전이 시작됩니다. 그리고 파란 불이 들어오면서 블루투스가 연결이 됩니다. (물론 페어링은 시켜 놓았었죠) . GPS는 특별한 조작을 해 주지 않아도 자동으로 연결됩니다.

블루투스는 GPS와 상관이 없으므로, 굳이 페어링 하지 않아도 GPS를 사용하는데는 아무 불편함이 없습니다. 아이팟 터치를 연결했다면 블루투스를 연결할 필요가 없겠지요.

AUX 단자도 연결해 놓았기 때문에, 음악도 차량 스피커로 들을 수 있습니다.

참고로 말씀드리자면, 블루투스의 프로토콜은 헤드셋용이고, 이 헤드셋 사운드는 AUX 단자로 나가지 않습니다.
무슨 말이냐면, AUX 선을 연결해서 음악을 듣고 있는 중이라고 할 지라도
전화가 와서 블루투스 연결로 받으면 , 미오 카킷 하단부에 있는 스피커로 상대방의 목소리가 나온다는 말입니다.
AUX로 연결되어 있더라도 차량용 스피커로 상대방의 통화목소리가 들리지는 않습니다.

그리고 이 블루투스 연결은 직접 카킷에 연결되어 있지 않더라도 가동되므로,
전화기는 주머니에 넣은 상태로 카킷만 이용해서 전화를 받을 수도 있습니다.
굳이 네비게이션 연결이나 충전이 필요 없는 상태라고 할지라도 차량에 탑승하는 것 만으로 차량용 핸즈프리가 된다는 거지요.
꽤 괜찮은 아이디어입니다.

파란 불이 들어와 있다는 얘기는, 현재 주머니에 (혹은 가방에) 있는 아이폰과 블루투스 연결상태라는 말입니다.
이 상황에서 전화벨이 울리면 미오 카킷의 뒤에 있는 버튼을 눌러주면 통과가 가능합니다.

잠깐 얘기가 샜습니다.
어쨌건 지금은 비오는 금요일 저녁 퇴근 시간, 이태원 같은 중심가로 가는건 서울 시내에서는 쉬운 일이 아니지요.
그래도 생각보다는 한산하네요. 비가 와서 사람들이 많이 안나온 모양입니다. 어찌어찌 잘 만나고 주차도 잘 하고 잘 도착.

이태원에 도착

우왕 이곳이 이태원이라는 곳인가!!!! 과연!!! 길거리에 이상한 옷가게가 많아!!!!
… 그리고 ….
영어만 하는 외국인만 있는게 아냐!!! 별별 말소리가 다 들린다!!!

그리고 한 블럭 뒤로 들어가니 또 별천지군요.
진짜로 외국에라도 온 듯, 다양한 외국 음식점들이 즐비합니다.
하관에 털난 터키아저씨들이 하는 정통 캐밥집도 보이고, 인도 음식같은거야 신기하지도 않은 정도입니다.

그리고 ‘모처럼 이태원에 왔으니 신기한걸 먹어야지!’ 라며 교수님이 추천해 주신 음식점은
정통 그리스 음식전문점 산토리니.
산토리니라니, 여기?

아, 물론 현실의 산토리니는 좀 더 저렴하게 생겼긴 합니다.
파랑색이야 당연한듯한 키 칼라.

나름 유명한 곳인가 보더군요.
그래도 비온 뒤의 금요일 밤이라 그런지, 기다리지 않고 자리를 잡을 수 있었습니다.

위치는 대충 요기쯤. 위치는 2층과 3층입니다.

지도를 클릭하시면 위치정보를 확인하실 수 있습니다.

수, 수블라키…? 사가나키? 이거 일본어 아냐

2층으로 올라갑니다.

아기자기하고 이국적인 인테리어의 귀여운 레스토랑입니다.

아아, 창문 바깥이 지중해였다면 얼마나 좋았을까요 ㅎㅎ
파란 창문이 강렬합니다.

자리잡은 곳은 3층의 창가. 파란 컵과 희고 파란 종이.

창문에는 파란 지중해… 가 꿈에 보일 것 같은 느낌의 파란 그림들.

파란 조명이 빛나는 작고 아기자기한 레스토랑입니다.

그리고 사람을 파랗게 질리게 만드는 가격표 …

아니 이건 농담입니다 ;;;
가격은 그런대로 적당한 느낌이네요. 대부분 1만원대의 가격. 적어도 그리스 가는 비행기표 보다는 몇 배나 쌉니다.

안심하셔도 됩니다.

주문한 요리는 일단 홍합 나가사키 사가나키.
아아 영 익숙해 지지 않는 이름입니다.

쉽게 말하면 홍합탕.

토마토 소스에 홍합과 치즈, 야채를 넣고 조리한 요리입니다.
한국 사람 입맛에 잘 맞는 요리네요.
살이 잔뜩 오른 홍합은, 탱탱하면서 부드럽게 입 안에서 터지는 신선한 맛을 보여줍니다.

아아 즐거운 기분.
그리스 음식이라고 해서 엄청나게 독특한 소스를 쓴다던가 이상한 향신료를 쓰는게 아니라는게 일단 맘에 드네요.

그리고 다음 메뉴는 수블라키 (꼬치요리).
새우 수블라키와 돼지고기 수블라키입니다. 꼬치에 끼워서 불에 굽는 요리이지요.
새우 역시 살이 탱탱하게 오른 것이 식욕을 마구 자극합니다. 아아 .

꼬치도 맛있지만 특히 감자가 별미.
바삭하도록 얇게 튀긴 것은 아니지만 감자의 풍미가 잘 살아나면서 고소합니다.

쌀은 전부 인디카 (안남미)
어디서 구하는 걸까요 이런 쌀을.

저 앞에 있는 빨간 것은 … 무로 만든 피클 같은 맛이 납니다

마지막으로 시킨 메뉴는 레몬으로 요리한 닭가슴살 요리

음….

이건 좀 미묘…

새콤하고 부드럽고 담백한 소스에 닭가슴살 튀김이 적셔져 있는 요리입니다.
레몬의 새콤한 향이 좋고 자극이 적은 요리이긴 합니다만, 남자들 취향은 아닌듯. ㅎㅎ

맛있는 음식을 먹으며 신나게 대화하다 보니 어느새 9시가 넘었네요.
슬슬 움직여 봅니다.

" 비가 와서 그런가, 금요일 저녁 이태원이 이정도로 한산하다니"

교수님이 말씀하셨습니다.
아아 그나저나 가고 싶은 각국의 식당들이 즐비한 곳이로군요 여기.
수제버거로 유명한 스모키 살룬도 있고, 그 옆의 중국만두집도 강추라는데…

근처 조용하고 작은 카페를 찾아 수다질로 시간보내기.

제대로 나온 사진 공개만은 피해달라던 K양 공개. 언제나 말많고 쾌활한 아가씨 ㅎㅎ
교수님은 차마 도촬할 수 없었고 백군…은 남자사진따위는 안올린다는 저의 강력한 의지로 안올립니다.

이렇게 이태원의 밤은 깊어갑니다.

자주 오고 싶을만큼 재미있는 곳이지만, 집이랑 거리가 꽤 멀어서 차없이는 곤란하고,
차를 가져와도 댈 곳이 마땅치 않은게 흠이라면 흠이군요 :) 언제 또 오게 될까요?

얌전히 주인을 기다리고 있던 미오 GPS Car Kit과 528i
덕문에 즐거운 하루였네요.

자, 이제 집에 가자꾸나.

[미션1] MIO GPS Car Kit 개봉기

Sat, 04 Dec 2010 21:12:03 +0000

http://cafe.naver.com/exploremore
‘미오와 40인의 탐험대’ 2차 체험단

저는 네비가 있습니다.

그것도 근사해 보이는 놈으로 말이죠. 네비가 있습니다. 차에 매립된채 말이죠.
하지만 보기에만 근사할 뿐 사실은…

실상은 불편하기 이를데 없습니다.

검색이라도 한 번 하려치면
터치스크린도 아니고 요상한 휠을 돌려서 한 글자씩 입력해야 하는가 하면,
빈약한 업데이트도 1년에 한 번씩 거금을 주고 해야 하질 않나
교통정보 같은 서비스는 기대도 할 수 없습니다.

그렇다고 사제네비를 달면 거금이 깨지게 된단 말이죠..

그래서 간편하게 생각한 것이, ‘아이폰의 네비게이션을 보조로 이용하자’ 였습니다.

차에 이것저것 주렁주렁 달고 다니는 것을 극도로 혐오하는 저는,
아쉬운대로 아이폰을 저쪽에 거치하여 해결하였습니다.
음악도 아이폰으로 듣는 것이 훨씬 편해서 말이죠.

거치하는 방법은 무식하게도, 두꺼운 겔패드로 그냥 붙여버리는 방법을 이용했습니다.

어쨌거나 저는 이런 네비가 있습니다.

그치만 아이폰용 네비의 고질적인 단점은 그 빈약한 GPS 입니다.
건물 사이에라도 들어가면 빙글빙글 돌아버리는 네비 소프트웨어는, 소프트웨어 제작사의 잘못이 아니라
조금만 신호가 약해도 미쳐버리는 아이폰의 약한 GPS 때문입니다.

게다가 전화가 와도 받기 용이하지 못합니다. 스피커폰으로 전환해서 큰 소리로 말해야만 하지요.
음악을 컨트롤 하기도 불편합니다.
저 자리가 사실 좋아 보이지만, 치명적으로 안좋은 자리거든요.

뭔 소리냐면….

…. 핸들에 가려서 아이폰이 안보여요 …

아 잠깐 눈물좀 닦고 …

이 얘기는 이제 좀 나중에 하고, 중요한 본론으로 들어갑니다.
그래서 한참동안 구입할까 말까 고민하던 아이폰 거치대 겸 GPS 증폭기, 그리고 블루투스까지 지원되는 ,
제 고민을 한 번에 해결할 수 있는 제품을 리뷰하게 되었던 거지요.

Mio GPS Car Kit 입니다. 연결하면 충전도 되고, 블루투스 연결도 되고, SiRF StarIII GPS 칩이 들어 있어서 GPS가 없는 아이팟 터치도 네비게이션으로 이용할 수 있게 해주는 최종보스. AUX out 같은 소소한 기능은 기본. 딱 원하던 바로 그 것이로군요.

케이스는 단순하지만 탄탄하게 잘 이루어져 있습니다. 젖거나 충격에 쉽게 파손되지 않게 되어 있어요.

전체적으로 Mio GPS Car Kit 본체의 마감상태는 훌륭했고, 기능이나 디테일도 기대 이상이었습니다.
메뉴얼에는 없는 마이크의 존재여부라던가(실험해 보니 아래쪽에 있는 것 같더군요),
2A 입력을 지원해서 일반 USB 충전기로는 이용할 수 없다는 아쉬움이 있지만 말이죠.

그럼 이번엔 부수기재들을 뜯어보도록 하겠습니다.

볼조인트이므로 가동범위는 예상한대로 이정도.

고정링을 어느 정도 조여준 상태인데도, 너무 꽉 끼거나 헐렁함 없이 기분좋게 돌아갑니다.
‘기분좋다’ 라는 표현은 정확한 것 같습니다.

이제 Mio GPS Car Kit 의 내용물은 전부 확인해 보았습니다.
전반적으로 제품의 디테일이 섬세하고, 마감과 재질이 지금까지 봤던 네비게이션 관련물품중 최고군요.

그럼 이제 차에 내려가서 장착하는건 다음 시간으로 미루고,
간단하게 아이폰과 결합해 보겠습니다.

이렇게 아이폰/ 아이팟 자동차용 거치대이자, 네비게이션용 외부 GPS 기기이자,
블루투스 핸즈프리, 충전기 역할을 하고 있는
Mio GPS Car Kit (미오 카킷) 리뷰의 1부, 개봉기였습니다.
다음 시간에는 본격적으로 차량에 연결하고 사용해 봐야 하겠군요.

유니티 셈플 테스트

Fri, 03 Dec 2010 15:29:44 +0000

영어 공부법

Fri, 03 Dec 2010 15:20:35 +0000

이번에 배운 영어 공부법

박PD님 블로그에서 트랙백

읽기는 Oxford Bookworms
듣기는 Impact Listening 이군요.

꼬르륵 .

Thu, 02 Dec 2010 23:15:59 +0000

한동안 잠수모드로 열공하다가, 리뷰할 것이 왔네요. 할 수 없이 잠수풀고 리뷰 모드로 변신!

Unity3D

Thu, 25 Nov 2010 11:40:37 +0000

Unity3D 링크모음

Thu, 25 Nov 2010 09:22:28 +0000

——————————————————————————————————————– Unity Documentation : Unity 에서 제공해 주는 문서 사이트 입니다.

Unity Resources

Unity Blogs
Unity Videos on Vimeo : Keynote 및 기술관련 자료들이 Vimoe 에 저장되어 있습니다.
Unity Videos on YouTube : Keynote 및 기술관련 자료들이 Youtube 에 저장되어 있습니다.

여기까지가 회사에서 공식적으로 제공해 주는 문서 사이트 입니다.

3rd party 회사들에서 지원해주는 교육자료들 입니다.

design3 (academic)
design3 (corporate)
design3 (developer)

Unify Community Wiki : unity 관련 커뮤니티 위키입니다. Tutorial 이나 필요한 사이트 들이 Wiki 형식으로 정리되어 있습니다.

Unity 관련 책들입니다.
Unity Game Development Essentials (book)
Unity 3D Game Development by Example Beginner’s Guide (book)
Creating 3D Game Art for the iPhone with Unity (book, coming Oct. 29, 2010)
Unity Creative (magazine)

회사에서 제공해 주진 않지만, 커뮤니티 사이트들입니다. 튜토리얼과 다른 학습자료들이 소개되어 있습니다.

http://www.theunityartist.com/forum/index.php : Unity 를 사용하는 Artist 를 위한 포럼입니다.
http://infiniteunity3d.com/
http://unity-tutorials.com/
http://www.unityprefabs.com/
http://www.unitymagic.com/shop/en/
http://unity3dtotal.com.br/
http://unity3dstudent.com/
http://gameassets.net/
http://www.gamergfo.com/site/index.html
http://www.vtc.com/products/Introduc…-Tutorials.htm
http://showmethatagain.com/use/server.php?page_id=5847
http://www.m2h.nl/unity/
http://www.unity3dbrasil.com.br/
http://www.unity3d-france.com/
http://www.unity-insider.de/
http://www.unityspain.com/
http://unityusersgroup.com/

Youtube & Vimeo 에 올라가 있는 교육자료들입니다.
http://vimeo.com/channels/ncsuunity
http://vimeo.com/ryanzec
http://www.youtube.com/user/tornadotwins

Unity Game Engine (Playlist)

Reddit.com 의 튜토리얼과 웹사이트 입니다.
Unity Tutorials on reddit.com

한동안 잠수

Mon, 22 Nov 2010 08:09:11 +0000

한동안 잠수타야겠습니다. 여러 가지 큰 일이 (!) 생겼네요. 한동안 집중하려면 힘들것 같습니다. 아 물론 트위터에는 계속….

겜브리오 이펙트 쉐이더

Fri, 19 Nov 2010 17:13:32 +0000

언리얼에서 자주 사용되는 효과를 따라 만들어 봤습니다.
응용하기에 따라서 매우 많은 곳에 사용가능한 기술.

일단 에너지 보호막이나 방패스킬이나, 기타 몬스터 죽을 때, 불타오르는 재 부터시작해서
나중에는 마법진이 붓글씨 써지듯 경로에 따라 나타나게 할 수도 있습니다. Linear 공식때문에 머리좀 아팠지만 스승님이 만들어 주셔서 간단히 해결. 역시 수학의 정석을 공부해야 하는 걸까나 …

이것이 Linear interpolation 공식.

어쨌거나 완성한 효과, 가장 처음과 마지막에 살짝 버그가 있지만 고치기는 어렵지 않을듯 싶고, 효과도 꽤 마음에 드네요 :)
[#VIDEO|20101119171100010087311701.jpg|pds/201011/19/03/|mid|480|400|pds20#]

겜브리오 이펙트 쉐이더 연구

Thu, 18 Nov 2010 16:30:40 +0000

뭔가 겜브리오의 이펙트 쉐이더는 뿌옇고 싸보인다라는 얘기를 들어서,
캐릭터에서 사용했던 방법으로 대충은 이유나 해결방법을 짐작하고 있었지만 구체적으로 연구하지는 않고 있었습니다.
그렇게 어려운 고급 기법도 아니니까. 아니 기법이라기 보다는 ‘설정’ 이었으니까요.

그러다가 이번에 우리 이펙트 디자이너가 의뢰한 문제를 해결하다가 같이 해결되어 버렸는데요.

겜브리오 이펙트는 일단 이게 문제입니다.

이렇게 노말맵에 리플렉션 준 이펙트를 만들었습니다. 굳이 뭐 리플렉션 아니더라도 그냥 이펙트도 다 그렇습니다만.

이렇게 만든 이펙트를 좀 멀리 떨어뜨리면, 노말맵의 강도가 급격히 줄어듭니다. 굳이 노말맵이 아니더라도, 이미지 자체가 뿌옇게 됩니다. 뭐 캐릭터 텍스쳐는 anisotrpic으로 해결했습니다만…

거기다가 clamp를 이용해서 알파로 뺀 부분에 뭔가 찌꺼기가 나타나기 시작합니다.

행여나 기울이기라도 한다면 끝장. 알파로 다 빼버린 부분에 알파가 다시 다 생겨 버립니다.
덕분에 이펙트 디자이너분들이 겜브리오 이펙트는 뿌옇고, 알파도 잘 안빠지는 버그가 많다고 투덜대셨었죠.
언리얼 이펙트는 ‘뭔가 날카롭고 쨍하다고’… 우린 그렇게 안되냐공…
으음 네에. 겜브리오 구린건 맞습니다만…

그래서 뭐 이번에 알파 버그 고친다고 바쁜 스승님까지 동원해서 역추적한 결과.

결론은 역시 예상했던데로 샘플링이더군요.
그런데 이펙트용 샘플링 옵션은 캐릭터랑 다릅니다. 캐릭터에서 개선했던 방식으로 하면 별로 해결이 안되는데,
그건 캐릭터 텍스쳐는 보통 크게 만드는데 이펙트 텍스쳐는 아주 작게 만들기 때문이지요. 샘플링할때 충분히 샘플링할만큼의 텍셀이 안나와요. 그래서 캐릭터의 샘플링 옵션과 정 반대(?) 로 가 줘야 합니다. 요게 잡기술.

결론적으로 같은 이미지인데 쉐이더에서 이 설정을 적용하면 다음과 같이 됩니다.

일단 아주 가까이 하면 이전 방식과 이미지가 똑같지만,
조금 떨어지면 그전보다 이미지가 날카롭게 남아 있는 것을 볼 수 있습니다.
다소 지글댈 수도 있지만, 짧은 시간 안에 강렬한 이미지가 나와야 하는 이펙트의 특성상 이쪽이 훨씬 나을 수 있지요.

좀 멀리 빼도 디테일이 죽거나 하지 않습니다. 오히려 날카롭게 샤픈 되어 있는 느낌이 되지요. 캐릭터한테는 못쓸 설정입니다만, 이펙트니까 쓸 수 있습니다.

뿐만아니라 알파 버그 찌꺼기도 일어나지 않습니다.

눕혀봐도 마찬가지입니다. 그전보다 이미지가 거칠어졌지요. 그렇지만 알파 버그는 완벽하게 고쳐졌습니다.
이대라면, 멀리서라도 이펙트가 강렬하고 선명하게 보이겠지요. 이제 디테일 떨어진다고 플렌에다가 핏자국 터지는걸 파티클로 굳이 옮기지 않아도 될 듯. 파티클 효과를 꽤 대체할 수 있을 것으로 예상되는군요.

이미지의 느낌이 이전보다 강렬해졌으므로, 이펙트 소스를 제작할때 감안하고 제작하면 문제 없을듯 합니다.

DirectX SDK 다운로드

Tue, 16 Nov 2010 23:46:30 +0000

DirectX SDK 다운로드

500여 메가… 꽤 걸리네 이거.

7강 완성

Tue, 16 Nov 2010 04:36:15 +0000

우후후 드디어 7강째 완성. 마지막 강의입니다.
원래 조명 연산까지 빡세게 시키려고 8강까지 잡았었는데
… 그러다 다 졸것 같아서

좀 소프트하게 만들었습니다. 이것만 알아도 사실 그래픽 디자이너 지망생들에게는 황송.
이정도 다루면 사실 쉐이더 기본은 다 안거라고 할 수 있죠.

시험문제도 다 내 놨겠다.. 이번주는 휴강이겠다…

이젠 좀 여유를 가질 수 있을 … 지도?

ShaderFX 공부중

Tue, 16 Nov 2010 04:15:54 +0000

강의용으로 쓰기에는 쉐이더 FX 만한게 없어서 쓰고 있었는데
마지막 강의를 위해서 준비하다가 하프 렘버트가 이상하게 나와서 말입니다.

… 뭐야 하프 램버트가 왜 이래..
엠비언트 더한 것 같은 이미지가 나와서 이래저래 고민했습죠. 이거 어디선가 노말라이즈 하는 느낌.

보니까 dot 공식에서 - 값을 짜르는 옵션이 있어 OTL
어쩐지 OTL OTL OTL
아놔 … 역시 옵션이 통일되지 않고 이리저리 버튼으로 따로 만들어서 숨겨 놓으니 알아볼 수가 있어야죠. 진짜 코딩하는게 낫겠다. OTL
어라 나도 프로그래머가 되어 가는건가…?

어쨌건 옵션 끄니까 하프 램버트 잘 나오네요. 룰루랄라.

하아.. 어디까지 가르칠까.

어라 림라이트도 댑따 쉽네.

역시 코드를 공부하고 난 후에는 노드구조따윈 껌이구나…
그냥 생각하는대로 휘릭휘릭 이어 버리니까 되네. 최적화따윈 신경 안써서 좋군.

거만해졌다.

아 빨리 강의 끝내고 다이렉트 X 책 공부할래요. 12월달에는 외부활동 금지. 공부다 공부!!!!!!!

6강자료

Thu, 11 Nov 2010 01:45:39 +0000

이번엔 모자이크가 좀 많네요. 본격적으로 쉐이더 설명에 들어가게 됩니다…

Team SCV 소울 콜렉터 시연연상

Mon, 08 Nov 2010 21:47:22 +0000

게임개발자 협회 맨토링 사업에서 제가 담당했던 팀의 게임이 완성되어서 올려봅니다.
전 뭐 별로 해준건 없고 잔기술 조금 가르쳐 준거랑 욕만 잔뜩 해준 것 밖에 (…)

다들 열심히 해서 잘 나왔네요. 제법 연출도 넣고, 할 수 있는 것은 다 해 냈다는 느낌
IT 전문학교 학생들 팀인데 교내 대회에서 1등했다고 합니다 ㅎㅎㅎ
열악한 환경에서도 밤새서 열심히 하더니 결과가 좋네요.
두번째 영상 큰 보스 나오는 부분 멋지군요. 꼭 보시길 ㅎㅎ

[#VIDEO|20101108211100009859151701.jpg|pds/201011/08/03/|mid|480|400|pds18#]
[#VIDEO|20101108211100009859471701.jpg|pds/201011/08/03/|mid|480|400|pds18#]

게임개발의 이상과 현실

Sun, 07 Nov 2010 21:58:35 +0000

KGCA강의자료: 게임개발의 이상과 현실 (MMO시장자료 포함)

역시나 훌륭하시고 직설적인 스톰님의 강연자료.

저번에도 어떤 친구가 자기는 별로 성공하지도 못한 프로젝트에 있다고 징징거리길래

“별로 성공하지 못하기가 얼마나 힘들었는줄 알고 그런 말을 하냐!!! " 라고 얘기한 적이 있었었죠.

진짜 중박 내기도 얼마나 힘든건지 이 PT를 보면 잘 알수 있습니다.

아무래도 말이 없는 문서만이라서 결론이 좀 짧아 보이긴 합니다만, 결국에는 기본적인 얘기가 다 옳은 얘기…

5강자료

Sun, 07 Nov 2010 16:02:03 +0000

5강자료는 최적화와 가속화에 대한 설명.
어차피 이쪽은 해도해도 정답이 없는 관계로
프로그래머와 함께 문제점을 찾아나갈때 못알아듣거나 짜증내지 말고 서로 협력하라는 내용의 강의였습니다.
뭘 협력하려 해도 대충 알아야 협력하지.

밉맵을 쓰면 무조건 빨라지고 메모리가 절약되는게 아니라던가, 폴리곤만 줄이면 다 해결되는게 아니라던가
최적화나 가속화를 위해서 모델링이나 맵핑 말고도 수많은 이상한 더미나 박스등을 넣어줘야 한다는 얘기들이었습니다.

가장 중요한 것은 자기만족을 위해 일하지 말고 팀과 게임의 성공을 위해 일하라는것.

iZel 스마트폰 휴대용 거치대 리뷰

Sun, 07 Nov 2010 10:41:24 +0000

원래 이런거 받으면 하루만에 뚝딱 해치우는 성격이지만
이번주는 택배도 꼬여서 늦게 왔고 개인적으로도 힘든게 많은 한주라 늦었네요

노말맵 사용시 미러링 현상 해결

Thu, 04 Nov 2010 16:42:13 +0000

노말맵은 하이 폴리곤의 버텍스 위치를 벡터화 시켜 로우 폴리곤의 벡터에 적용하는 픽셀단계의 벡터 속임 기법입니다.

덕분에 노말맵의 절대적 단점이 생기게 되는데, 그것은 ‘미러링을 할 수 없다’ 라는 것입니다.

즉 symmetry 기능을 써서 좌우대칭으로 모델링을 했을때, 다른 텍스쳐들은 좌우대칭을 해도 별 문제가 없지만 노말맵만은 좌우대칭을 하면 X 축 (U값. 맞나?) 이 좌우로 뒤바뀌게 되어
볼록 튀어 나와야 할 무릎이 반대쪽은 오목하게 들어가는 현상등이 일어나게 되는 것입니다.

즉 이렇게 하나의 텍스쳐에 양쪽 다리를 Unwrap을 하면

아래처럼 노말맵의 X 축 (Red값) 도 좌우대칭이 되어 버립니다.

(크게보면 좀 더 잘보이지만 비공개 프로젝트라 짤라서 일부만…)

위 그림은 노말맵의 X축 (Red) 값만 보이도록 처리한 것입니다. (normalmap.rrr)
저렇게 노말맵이 좌우대칭이 되면서, 한 쪽에서 빛을 받으면 계산이 이상하게 됩니다. 튀어나와야 하는 부분이 오목하게 보인다던가 하게 말이죠.

이렇게 말입니다. 프로그래머들은 뭐가 이상한지 못찾던데 OTL 아니 딱봐도 이상하잖아요. 아참 나도 프로그래머지.
그래픽스 하시는 프로그래머분들은 알아볼 수 있으실듯. 왼쪽 무릎이 튀어나온게 아니라 들어가 버렸습니다.

그래서 뭐 어렵지 않은 처리로 …

힌트는 UV를 이렇게 배열하는 것.

비대칭으로 한 장 더 그리는게 아니라, 타일링된 UV 배열만 옆으로 이동시키면 U 값이 1을 넘어간 것을 인식하여,
그 부분에서만 노말맵의 R 값을 뒤집어 주게 만들었습니다.

짜잔. 노말맵이 좌우대칭이 아닙니다. 제대로 되었습니다.

결과물도 다음과 같이 해피해피

텍스쳐 추가도 필요 없고 그냥 UV 좌표만 이동시켜 주는 것으로 해결 완료.
이제 그래픽팀은 마음놓고 Symmetry를 쓰시오 ~~~

4강자료

Sat, 30 Oct 2010 23:24:59 +0000

4강자료 올리려 했더니 점검이라서 못올리고 이제야..

하아 5강부터 산넘어 산이군요 OTL

역시 한 3달은 준비하고 강의했어야 했을듯.

요새 그래픽 강의할 때는 맥스의 기본 라이트도 안배우고 가네요. 그래픽 디자이너들이 실무에서도 빛에 대해 관심이 없고, 텍스쳐나 노말맵 이쁘게 그리기에만 집중되어서 그런지 중요한 교양인 빛의 이론과 맥스에서의 빛 실습은 건너뛰어 버리네요…

하긴 취업을 위해서는 그런 것에 집중해야 하겠지만, 나중에는 분명 이런 부분에 대해서도 공부해야 한다는 유행이 들겁니다.
쉐이딩 처리만 바꿔도 게임이 확 바뀌니까요.

그래픽 디자이너들이 모델링과 텍스쳐, 에니메이션 (연기자와 분장과 연기) 에만 집중하고 있는 형국이랄까요.
빛과 카메라 (조명과 카메라) 도 제대로 배우지 않으면 영상 매체를 만들 수 없을텐데요. 카메라는 그렇다 쳐도, 이렇게 중요한 라이트를 프로그래머들에게만 맡겨 놓는다는 것이 잘 이해가 가지 않습니다.

담에는 이걸 강의하기 위해서는 맥스의 라이트 강의만 몇 주 한 후에 해야겠더군요.

삼국지를 품다

Sat, 30 Oct 2010 21:18:41 +0000

ㅋㅋ 진짜 제목 이걸로 걍 가네.
첨 만든 제목은 끝까지 간다는 법칙을…

아, 제가 참여한 프로젝트는 아닙니다. 이건 JJ 가 AD로 참여한 첫작품! 기대됩니다!
… 알고는 있었지만 참 이런 엄청난 제작속도는 늘 익숙해 지지가 않아요.
조금 충격적인 반전이 기다리고 있지만 이건 지스타때 기미사가 발표한다니깐 아직 비밀입니당.
어쨌건 이래저래 신기한것만 만드는 울 회사 -_-;;;

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

Head line : 엔도어즈 김태곤 프로듀서, 삼국지 소재로 한 전략 MMORPG 개발 중

- 지난 2007년 아틀란티카 공개 후, 3년 만에 지스타에서 차기 작 공개 예정

- 역사 게임의 대가 김태곤PD가 삼국지 원작을 충실하게 담아낸 ‘삼국지를 품다’

게임개발 및 서비스 전문업체 엔도어즈(대표 조성원)는 29일 ‘MMORPG 흥행 제조기’로 불리는 김태곤PD가 차기 작으로 역사 MMORPG인 ‘삼국지를 품다’를 개발 중이라고 밝혔다.

‘삼국지를 품다’는 삼국지의 세계관을 바탕으로 한 MMORPG로 역사와 전략을 주제로 하는 김태곤PD의 개발 철학이 철저하게 담겨 있으며, 삼국지 원작의 흐름에 맞는 게임 구성과 위, 촉, 오 국가의 별도 시나리오 모드를 통해 삼국지 고전 내용이 충분히 반영될 예정이다.

그 동안 김태곤PD는 임진록 시리즈, 거상, 군주온라인, 아틀란티카 등 역사를 기반으로 한 MMORPG를 개발해왔으며, 역사소재를 바탕으로 정치, 경제시스템을 게임에 도입하는 등 독창성을 인정받아 출시 게임마다 흥행에 성공, 지난 2008년에는 대한민국 게임대상에서 2관왕(최우수 상, 우수개발자 상)을 거머쥐기도 했다. 특히 글로벌 시장에서도 턴제 전략 MMORPG장르를 새롭게 개척하며 북미, 유럽, 일본, 태국 등 전 세계 주요 시장에서 큰 성과를 거둔 바 있다.

엔도어즈 김태곤PD는 “단순히 삼국지 느낌이 나는 게임이 아닌, 정통 삼국지를 충실하게 담아낼 수 있는 게임을 개발하기 위해 노력하고 있다"며 “이 게임을 통해 유저들은 정통 삼국지를 보다 사실적으로 체험하게 되길 기대한다"고 밝혔다.

한편, ‘삼국지를 품다’는 오는 11월 18일 부산에서 열리는 지스타를 통해 첫 공개될 예정이다.

2010 팀 전체 워크샵

Sat, 30 Oct 2010 20:40:36 +0000

동접 20만을 기록하면 유혈사태는 일어나지 않을 것입니다.

카메라는 가져갔지만, 한 번도 꺼내지 않고 아이폰만으로 찍었습니다.

아래는 새 버스 불멸버스.

퍼블리싱하는 중국게임인데, 별 기대 안하고 했다가 오토 기능 덕분에 즐겁게 플레이중.

이번엔 차를 가지고 가지 않았기 때문에 어디로 갔는지도 잘 모르겠습니다. 양평이던데.

100명이 넘는 직원이 워크샵 장소로 가서 운동회.

그중의 꽃은 역시 계주.

여자 계주에서 숟가락 살인마를 보았다 …

종합순위 4등. 호주우 획득. 냠냠.
근데 어차피 식당이 고기가 무한정으로 나오는 곳이어서 그다지 의미가 없었다는.

저 티에 그려진 것은 무엇인지 묻지마세요.

날씨도 너무 좋아서 덥지도 춥지도 않은 즐거운 워크샵이었슴다.

밤새 타뷸라랑 달무티로 새웠지만.

회사에서 나눠준 불량식품

Tue, 26 Oct 2010 16:01:23 +0000

사내테스트 시간에 나눠준 PC방 분위기 아이템들 ㅋㅋㅋ

에버랜드 갔다 왔습니다.

Mon, 25 Oct 2010 00:47:26 +0000

금요일날 회사에서 긴급번개로 오후에 갔다 왔습니다.
워낙 갑자기 떨어진 번개소풍이라, 일이 있어서 못가게 된 직원도 많아서 심심한 위로를…

가는 길은 노약자라고 특별히 회사 버스가 아닌 원이의 미니를 타고 갔습니다. 오예! 빨간 미니 이쁘당!

오후에 가서 저녁 폐장시간까지 있으면서 퍼레이드에, 불꽃놀이까지 다 보고 왔습니다.

퍼레이드를 제대로 본 건 처음이군요. 퍼레이드 규모는 오오 디즈니랜드에 떨어지지 않는 규모인데, 아쉬운건 역시
캐릭터가 없다는 것이로군요. 우리나라는 역시 소프트웨어는 별로인건가 …

어쨌거나 즐겁게 봤습니다. 좀 추웠지만 :)
불꽃놀이도 규모도 좋고 진행도 좋더군요. 담에도 또 오고 싶네요

3강 완성

Wed, 20 Oct 2010 06:02:16 +0000

2강때에는… 학생들 수준을 잘못 파악해서 (UDK도 했다길래 알파 블렌딩 정도는 이해할 줄 알았징 OTL) 좀 힘들었습니다.
자고로 강의는 학생들 수준에서 살짝 아래로 만들어야 하지요.

왠지 쪽대본도 아니고 쪽강의 쓰는 것 같아서 미안하기 서울역에 그지없지만 , 제 블로그 총집합편이 되는 것 같아서 또 그지없지만
어쨌건 이번엔 쉽게 준비해 봤습니다. 느긋하게 학생들과 토론하는 분위기로 만들어야 겠군요 .

제주도 올레길

Mon, 18 Oct 2010 22:04:29 +0000

주말동안 8,9 코스 완주했습니다.
9코스는 거대한 말똥지뢰밭의 산길…

20km를 넘게 걸으니 삭신.. 은 아니고 옆구리와 발목만 아프군요. 헬스의 효험.
늙으면 제주도에 가서 살까라는 생각이 들었습니다.

폴리와 폴리곤, 트라이앵글 이야기 (The story of Poly, Polygon and Triangle)

Mon, 18 Oct 2010 18:28:42 +0000

의외로 기초적이면서 단순하지만, 이상하게 오해되고 있기도 한 폴리와 폴리곤, 트라이앵글 이야기입니다.

기본적으로 폴리곤 ( Polygon: 다각형, 多角形 ) 이란, 세 개 이상의 선분으로 둘러싸인 평면도형을 말합니다.
( 출처: 네이버 백과사전 )

mathworld.wolfram.com/StarPolygon.html

즉 폴리곤이란 삼각형만을 의미하는게 아니라 그냥 ‘다각형’ 을 의미하는 것으로, “삼각폴리곤” “사각폴리곤” “오각폴리곤” “십만 육천 구백 팔십 삼 폴리곤” 이 모두 “폴리곤” 이라 부를 수 있는 것들이라는 것이지요.

그렇지만 그래픽 카드에서 3D 그래픽을 처리할 때에는 가장 간단한 단위인 삼각형만을 생성할 수 있기 때문에 컴퓨터 그래픽스에서는 “폴리곤” 을 “삼각형” 이라는 의미로 널리 사용하게 되었습니다.
(주 : 예전에 넙스를 실시간 처리하는 그래픽 카드는 들어본 적이 있습니다만, 삼각형 이상의 다각형을 동시 처리하는 그래픽 카드는 아직 들어본 적이 없습니다. 혹시 존재하고 있나요?)

그리고 그걸 줄여서 “폴리(Poly)” 라고도 부르기 시작했습니다. “삼만 육천 폴리..” 라는 식으로 말이죠.
즉 삼만 육천 폴리는 삼만 육천개의 삼각형 (= 트라이앵글) 을 의미하는 것이었었죠.
사실 이것은 사전적으로 보면 무척 위험한 표현이긴 했습니다. “폴리” 라는 말의 의미는 “수가 많다 / 다수의” 의 의미를 가지는 접두어였거든요. 하지만 뭐 말이 통한다면 상관없었었었었었었었었었었었던거죠.

즉 그래픽 카드의 처리속도를 나타내는 폴리곤 처리양이라는 의미는 그래픽디자이너나 프로그래머나 모두가 같은 의미로 잘 이해하고 사용하고 있었습니다.

뭐 거기까지는 모두 행복하게 살고 있었습니다만…

어떤 말을 마음대로 자유롭게 써도 상관없었죠.

그렇게 새로운 기능인 Edit Poly 가 나오기 전까진 우린 행복했는데….

그런데 맥스 7인가 8인가부터 신기한 기능이 나오게 됩니다. 그건 지금까지의 모델링 작업의 삽질을 줄여주는 유용한 도구로,
삼각형만 처리하던 3D MAX 에서 삼각형 이상의 폴리곤도 처리할 수 있게 바뀌었던 거지요.

예를 들어 저 가운데 버텍스를 삭제해 버린다면, 더이상 삼각형을 유지하지 못하므로 저 아래의 면은 위 그림과 같이 통째로 날라가고,
다시 처음부터 면을 만들어 이어붙여 줘야 했었다는 거지요.

그리고 저기 보이는 사각형 폴리곤도 사실은 삼각형 폴리곤들이고, 엣지가 숨겨져 있었을 뿐이었습니다.
즉 최소단위인 삼각형을 언제나 신경쓰고 모델링을 했었었었었었었었어야만 했지요.

그렇지만 새로나온 폴리 모드로 바꾸고 저 가운데 버텍스를 remove 시켜 버린다면,
이렇게 간편하고 자유롭게 몇 각형이건 상관없이 면이 생성되게 되었습니다. 폴리 모드일때는 숨겨진 edge도 없고, 저 상태로 그냥 작업할 수 있어서 엄청나게 편안해 졌던 거지요. 진정한 의미의 “다각형” , 즉 진짜 “폴리곤” 이 만들어 질 수 있게 된 것입니다.

그렇지만 이건 맥스일때 얘기고… 게임 엔진은 맥스가 아닙니다. 게임으로 넘기게 되면 결국 자동적으로 (눈에는 보이지 않아도) edit mesh로 변환되어 넘어가게 되는 거고, 그렇게 되면 저 면은 자동적으로 삼각형으로 변환되어 넘어가게 됩니다.
왜냐면 게임에서는 삼각형 외엔 인식하지 못하니까요.
즉 게임에는 이렇게 들어간다는 말씀.

즉 폴리 구조는 단순히 맥스에서 모델링을 편하게 만든 구조일 뿐, 게임에서는 다시 삼각폴리곤(트라이앵글) 로 변환되어 넘어가기 때문에 게임과는 상관이 없는 수치였다는 겁니다.

그치만 여기서 용어의 혼선이 생기기 시작했다는 거지요.

3D max에서는 폴리 구조를 만들면서 용어를 재정의 해버렸습니다. 즉 진정한 ‘다각형’ 구조의 조작이 가능해 졌으므로 ‘다각형’ 의 의미인 ‘폴리’를 여기다 써버린 것이지요. (사전적으로는 정확하지요 ) 그리고 이러한 ‘폴리(다각형)’ 들을 계산해서 보여주면 게임에서는 혼선이 있을까봐 삼각형으로 계산한 ‘삼각폴리곤 (트라이앵글)’ 을 따로 표시할 수 있게 해 주었다는 것입니다.

< 면은 34개지만, 삼각형으로 환산하면 64개가 되어 버립니다. 저 64개가 이전까지 부르던 ‘폴리곤’>

즉 위에서 보는 Polys 는, 그냥 다각형들, 즉 삼각형이 아닌, 순수하게 하나씩 있는 면들 - 아래의 바닥도 폴리곤 하나 - 라고 계산한 것입니다.
예전에 알고 있었던 “폴리” 나 “폴리곤” 이란 말은 “삼각형” 이란 말이었는데, 지금은 그냥 ‘면이 몇 개’ 라는 의미가 되었던 거지요.
그래서 지금은 [폴리 모드에서 폴리곤 수치]를 보면 절대로 안됩니다. 폴리 모드라면 Tris 로 표시되는 “트라이앵글” 이 순수한 옛날의 삼각형 개수를 의미하게 되는 거지요. 즉 여기서는 Tris 개수를 봐야 진짜 게임에 들어가는 면수가 됩니다.

당연히 프로그래머들은 맥스를 안쓰니까, 폴리 모드에서 ‘폴리곤 5천개예요’ 라고 하면 아직도 ‘삼각형이 5천개’ 인줄 압니다.
사실은 ‘삼각형으로 하면 거의 1만개예요’ 라는 의미인데 말입니다.

이건 에디트 폴리 모드를 에디트 매쉬로 바꿔보면 명확해집니다.

메쉬로 바꾸면 … 메쉬는 모든 면이 삼각형이므로 …

Polys 와 Tris의 숫자가 똑같아지는 것이지요. 당연하죠. 엣지가 숨어있을뿐, 모두 삼각형이니까.

이런 얘기는 그런데 프로그래머는 모릅니다. 프로그래머는 여전히 버텍스에 인덱스버퍼 붙여서, 트라이앵글 스트립으로 빠르게 삼각형을 그릴 생각만 하지, 폴리곤이 한번에 4각 5각 6각으로 처리된다고 상상을 하지 못하지요.
그래서 혼선들이 가끔 생깁니다. “프로그래머는 폴리 개념을 모릅니다”
아니 뭐 알면 말고…

그러니 가급적이면 용어는 통일해 주는 것이 좋습니다. 게임에서는 삼각형만이 고유의 처리단위이므로, “폴리곤” 이라고 한다면 “삼각폴리곤” = 트라이앵글 이라고 말하기로 말이지요. 즉 그래픽 디자이너도 폴리 모드가 정말 편하고 좋지만, 일부러라도 Tris 숫자를 ‘폴리곤’ 이라고 부르는 것이 혼선이 적게 됩니다. 여기서의 의미는 “메쉬 상태로 바뀌었을때의 폴리곤” 이라는 의미가 되겠군요.

뭐 , 나중에 좀 더 좋은 용어나 정의가 나온다면 바꾸면 되는 거구요.

결론 : 폴리곤이란 ‘삼각 폴리곤’ 을 의미하는 말로 통일.
맥스의 폴리 모드(Poly Mode)에서는 “Tris” 를 “(메쉬상태에서의)폴리곤"숫자 라고 불러야 합니다.
우리 모두 용어를 통일해서 프로그래머들과 혼동이 없게 하도록 합시다.

혹시나 모르는 사람 있으면 비웃어줍시다.

올레9코스

Sat, 16 Oct 2010 11:52:54 +0000

으악 9코스는 산길에 말똥밭이야

응?

Thu, 14 Oct 2010 12:01:29 +0000

reflect(x,y)
공식하고

(2.0f*dot(x,y)*x-y)
공식하고

분명 둘다 리플렉션 벡터 구하는 공식인데
큐브맵에 대응시켰을때 결과가 다르다 (…멍)
이거뭘까. 무서워.

2강 강의자료

Thu, 14 Oct 2010 00:25:14 +0000

배포용 PPT도 따로 만들어 다 나눠주고 그럼 좋겠는데 … 참 그게 바쁘다는 핑계로 하기 힘드네요. (아니 정말 좀 바빠효 )
그리고 좀 편하게 강의하려 했는데 평가도 하라네요 .. 어쩌지..
조금 위험하다 싶은건 일단 블러처리 해 놓았습니다.
1강때 bit 개념을 잡아 놓았으니, 이제 이 얘기를 알아 들을 수 있겠지요 :)

학생분들은 8bit 칼라는 256 색이긔 … 라는 개념에서부터, 다시 거꾸로 왜 bit가 색인가 라는 개념부터 돌아가서 설명한 후, 그래픽 포맷까지 연결한 다음에 또 여기로 발전하여, 나중에 쉐이더까지 그 개념이 주우욱 관통되어서 하나의 개념으로 연결되는걸 앉은자리에서 보실 수 있으실 겁니다 :) 이거 개념 다 연결되면 신세계가 열려요. 회사 들어가서도 그림만 그리는 그래픽 디자이너보다 훨씬 깊이있게 참여할 수 있게 됩니다 :)

보통 이런 그래픽스 이론서가 어려운 이유는, 개념이 어려운게 아니라 ‘용어’ 에 대한 설명이 하나도 없어서 이해할 수 없는 것이고, 거기다가 개념 설명을 말로만 때우거나 세련되지 못한 그림 - 프로그램책이니 어쩔 수 없을지도 - 으로 대충 표현해 버리기 때문이지요. 저 또한 용어설명때문에 포기했던 전력이 오래 되었던지라, 적어도 그래픽 디자이너나 기획자들이 낯설어하는 용어가 뭔지는 파악할 수 있습니다 :)

아아 강의자료 제작중

Sun, 10 Oct 2010 00:53:45 +0000

강의자료중 가장 심플한 6강 완성.
한 번 해보니 다소 빡빡하지 않나 싶긴 합니다만
그 늦은 시간에 듣는 학생들의 강의태도나 이해도를 봤을때 이정도는 커버할 것 같다는 생각이…
아아 열심히 하더군요 역시 게임 아카데미. (게다가 이해도도 빨라! ㅠㅠ)
급하게 준비하느라고 자료도 얼마 없어서 듣기만 하는거라 어려웠을텐데 말입니다.

진짜 이번에는 급해서 그랬지 담에 제대로 준비하면 게임 그래픽스 11강 정도는 충분히 나올 것 같더군요
이제 마지막 7강. “고난도 쉐이더 만들기"를…

Shader FX / 멀티 텍스쳐링 일단 하나 또 완성 ...

Wed, 06 Oct 2010 03:56:55 +0000

이젠 좀 천천히 해도 되겠군요.
이것도 블로그에서 한번 연재해볼까 라는 생각이 드네요.

개발자 판별법

Mon, 04 Oct 2010 09:24:24 +0000

블리자드 PC방 유머사진에서

지형 텍스쳐와 건물 텍스쳐 해상도 차이가 먼저 눈에 띈다면 당신은 개발자 ♥

괴산절임배추집 사위님 트위터이야기

Fri, 01 Oct 2010 19:37:31 +0000

괴산절임배추 얘기는 다 아실테고..

사위분께서 제 트위터에 연결되어 계시네요.
하나 하나 긁어 봤습니다.

http://twitter.com/staff6

조금 슬픈 배추 이야기.
about 11 hours ago via web
배추 농사를 지어서 돈을 많이 못 번다. 그래서 편한 거 좋아하는 도시 사람들 취향에 맞춰서 배추를 다듬고 소금에 절여서 팔기 시작했다.
그러니까 1차 가공.
about 11 hours ago via web
도시 사람들은 배추가 자판기의 콜라처럼 만들어지는 줄 안다.
about 11 hours ago via web
그렇다보니 항상 정가에 팔아야 한다. 어느 해에 배추 값이 떨어졌다는 얘기를 듣자마자 도시 사람들이 깎아달라고 전화를 하기 시작했다.
다듬고 소금에 절이는 노동 비용은 절대 계산하지 않는다.
about 11 hours ago via web
배추 값이 미쳐 날뛰기 시작했다. 그런데 절인 배추의 가격을 올릴 수 없다.웃긴 건 배추보다 절인 배추의 가격이 싼 것에 대해서는 별다르게 불만을 가지지 않고 외려 좋아한다.
about 11 hours ago via web
절인 배추의 가격을 올리자는 말에 장인 어른은 이렇게 답하셨다. ‘장사 한 해 두 해 하는 것도 아니고… 이런 것 가지고 일희일비하면 도시 사람들이 우리를 믿겠어? 손해봐도 팔아야지.’
about 11 hours ago via web
그렇게 장인어른은 올해도 절인 배추를 작년과 같은 가격으로 판다는 편지를 고객들에게 보냈다. 참고로 이웃 농가에서는 밭떼기로 배추를 팔았다. 가격을 듣고 장인어른은 씁쓸하게 한 번 웃으시고는 소주를 따르셨다.
about 11 hours ago via web
괴산절임배추가 네이버 검색 순위 4위. 주위 사람들은 소문나서 좋겠다고 하지만… 장인어른은 오늘도 또 소주를 마실 거다…
about 10 hours ago via web

겜브리오로 마모셋 엔진 따라잡기

Wed, 29 Sep 2010 18:19:12 +0000

제가 그린 것도 아니고 (그래픽 치프 작품) 회사작품이라 전체 다 공개는 불가.

어쨌건 한쪽이 겜브리오고 한쪽이 마모셋. 제 눈에는 결정적인 차이가 딱 보입니다만 어쨌건 처리되는 느낌은 비슷하게 만들 수 있었습니다.
마모셋이 퀄리티가 좋다고 다들 말하길래 ’ 우리 겜브리오로도 할 수 있다는걸 보여줄께!’ 라고 큰소리 친다음 만들어 봤습니다만
… 생각외로 대단한 기술은 쓰이지 않았던데요. 생각보다 굉장히 단순했습니다. 뭐랄까 기본기가 좋달까? 라는 느낌. 확장성은.. 그게 뭐임? 먹는거임? 이라는 느낌이네요. 뭐 뜯으면 뜯을 수 있어 보이긴 합니다만 굳이 그럴 필요는…

어쨌건 결과물에 그래픽 디자이너들도 만족 만족. 이제 정리해서 커밋하면 되겠군요. (Fake짓 한게 한 두개 있어서…)
새로 넣고 싶은 기술이 있는데 한두개 적용해 봐야 겠어요.

코드는 사실 프레그먼트로 되어 있어서 역추적 하려면 상당히 귀찮은 시간을 보내야 합니다만,
이제는 그냥 그림 보고도 어느 정도 코드를 유추할 수 있어서 -_-;;; 그냥 짜봤더니 예상대로 되더군요. (그림쟁이 스타일)
오히려 제가 그전에 더 이쁘게 만든다고 이래저래 넣었던 코드들이 서로 섞여서 더 안이쁘게 되었었던 거였더군요. 우하하하 역시 심플한게 짱이야.

스페큘러나 기타 XXX 라던가 XXXX 기능들도 사용하지 않게 되어 있거나 그냥 섞여있고, 오히려 라이팅 프리셋이랑 AO, 후처리들이 정말 잘 되어 있더군요. 크흑 부러워. 그런쪽이 압도적으로 잘 되어 있고 편하게 되어 있어서 그래픽 디자이너들이 좋아하는 것 같습니다. 고급 기술은 차라리 쉐이더 FX쪽이 더 있달까…

그건그렇고 간지개발자님 추천의 Indirect light를 한번 써봐야지… 후후후
간만에 쉐이더 잡아보니 참으로 재미지네요.

게임 개발자 지망생분들이 보아야 할 좋은 글

Wed, 29 Sep 2010 09:25:29 +0000

이 길은 공부보다 편한 길이 절대 아닙니다

역시 스톰님 OTL 엉엉

하프 렘버트 쉐이더 FX 버전

Sun, 26 Sep 2010 23:16:16 +0000

어딘가에서의 강의 준비를 위한 쉐이더 FX 공부 이틀째입니다.

뭐랄까. 코드로 짜던걸 노드로 연결시키니까 확실히 편하긴 하지만
수박 겉핥기 하는 느낌이랄까 -_-;
전체로 잘 안보여요. 뭐 그래픽 디자이너들에게 설명할때는 확실히 편하긴 하겠지만…

이 회사에서도 그걸 알고 있는지 자주 쓰는건 그냥 그룹화 시켜서 편하게 편하게 만들어 놓았네요.
덕분에 마치 우버 쉐이더 처럼 조금만 손대려 하면 큰일이 되어 버리는…

일례로
dot(N,L)
로 끝나는 라이트 계산을 편하게 하느라고 그룹노드로 만들어 놓은것까진 좋은데,
거기에 추가로 하프 렘버트 적용하느라고
dot(N,L)*0.5f + 0.5f;
이라고 수정하면 코드에서는 초 간단한데 말이죠. 보기에도 쉽고.

그런데 여기서는 이거 하나 수정하려고 이렇게 만들어야 한단 말이죠
부왘 ㅋㅋㅋㅋ 뭐야 거창해
(하프 렘버트 쉐이더 예제가 있길래 열어봤습니다. 짠 사람은 이해가겠지만 처음 보는 그래픽 디자이너들은 어떻게 이해하라고…)

여기다가 warp 칼라라도 적용하려면 갑자기 또 신세계가 열립니다.
코드라면 역시 하프 렘버트 코드 아래에
tex1D(warp, halfLambert) * LightColor;
한줄 추가하면 끝나는 것을

부왘 ㅋㅋㅋㅋㅋㅋㅋ
뭐야 이거 ㅋㅋㅋㅋㅋㅋㅋㅋ

저 위의 거창한 그림이
float halfLambert = dot(N,L)*0.5f + 0.5f;
tex1D(warp, halfLambert) * LightColor;

요 두 줄이라면 믿으시겠습니까?

(뭐 선언까지 하면 거창하지 않느냐라고 따지신다면, 그건 관점의 차이라고 변명하겠습니다만 ㅎㅎ)

ps. 그나저나 마모셋 엔진도 구입해서 함 봐야 하는데 공동구매하실분 없으십니까 ㅋ

shaderFX 공부중

Sun, 26 Sep 2010 03:05:10 +0000

강의할 일이 생겨서 부랴부랴 공부중입니다.
일단 너무 자동으로 만들어 주는 것이 많아 헷갈리는군요.
이렇게 자동으로 해버리면 교육이 안되기 때문에 전부 수동으로 만드는 연습중입니다.
근데 그 썰렁한 라이트 dot 연산을 구현해 봤는데, 그 단순한 쉐이더 구현만으로도 이미 화면이 저렇게…
이거 조금만 더 복잡한 쉐이더를 이걸로 짜려면 그야말로 말도 안되는 사이즈의 모니터가 있어야 겠군요.
코드로 짰다면 기껏해야 3-4줄 정도밖에 안될 양인데 말입니다. (아, 선언하는것 때문에 좀 더 되어야 하나?)

인테리어 디자인북

Sun, 26 Sep 2010 01:09:19 +0000

얼굴가득 보이는 장난끼

매형 사무실 . A4지로 쌓아 만든 벽 이뻤는데요. 지금은 없어졌다고.
제가 옛날에 3D 알바했던 건물은 리스트에 없군요 ㅋ

인테리어 디자이너이신 매형 책이 나왔다길래 받아왔습니다 :)
그래도 같은 디자이너 계열이라고 장난치는 레벨이 비슷하신 …;;;
협회에서 단체로 낸 작품집으로 보입니다만 어쨌거나 자랑스럽네요 :) 빨리 돈벌어서 저렇게 모던한 주택 하나 지어 달라고 부탁해야겠습니다.

ShaderFx에서 패럴렉스 맵핑 만들기

Fri, 24 Sep 2010 09:45:11 +0000

http://knol.google.com/k/shader-fx-parallax-mapping#

자기식 모션 캡쳐 장면

Thu, 23 Sep 2010 20:02:14 +0000

옛날에 찍었던 사진들을 DVD에 보관해 놨는데, 아시다시피 DVD에 보관하는게 하드에 보관하는 것 보다 더 불안하기 때문에 하드로 옮기는 작업을 이번 추석에 했습니다. 그러다가 발견한 자기식 모션 캡쳐 장면 사진 ㄷㄷㄷ

벨크로 사다가 전부 수작업으로 만든 고정판입니다;;;
허리에 감은건 무려 자석 복대에서 자석 뗀 것

한시적으로 대여해 와서 잘도 사용했지요. 왼쪽의 검은색 박스가 센서입니다. 센서의 범위가 그리 넓지 않아서 제자리에서만 캡쳐해야 했다는…

생각해 보니 위 장면은 아래 동영상 제작을 위해 작업했던 것이로군요.
지금보니 손발이 오글오글… 아 창피해서 미치겠다 ㄷㄷㄷ
알파 채널의 검은 색 찌끄러기 빼는 것도 제대로 모르고, 카메라 개념이고 뭐고 전혀 모른 채 무작정 해보겠다고
덤벼들어서 갖가지 시행착오를 잔뜩 했던 … 것이지요.

그렇지만 그 경험을 바탕으로 다음에 작업한 것이 이것… 이네요. 자신없는 부분은 연출로 자르고, 눈동자는 마우스 모션캡쳐를 이용, 적절하게 합성하는 요령도 생겼… 지만 지금보면 역시 오골오골 ㅋㅋㅋ

(위 동영상 초반에 뭔가 설치하라는거 설치 안해도 아무 문제 없습니다. 설치하지 마세요)

이 팀들이 그동안 쌓인 경험으로 마지막에 만든게 동X의 여명이라는 RPG 프로젝트 동영상이었는데, 그건 그나마 그동안 만든것 중 가장 퀄리티가 좋았던 것으로 기억합니다. 공개하지도 못하고 묻힌 프로젝트지만, 어디 찾아보면 있을법도 한데요 .(나중에 찾아봐야지)

이때 모션 캡쳐 담당했던 K 군과 C 군 정말 고생 많았습니다. 잘 알지도 못하는 기계와 소프트웨어를 가지고, 잘 되지도 않는 기계와 영어밖에 없는 메뉴얼에, 상반신밖에 캡쳐 불가능한 자기식 장비로, 난폭하기 밀어 붙이는 저같은 악덕 팀장 밑에서 -_-; 잘도 밤새면서 즐겁게 작업해 주었었지요. 아울러 저도 한 번 했었… 우히히 (절벽에서 창질하는 일본군이 접니다)
이때는 정말 저도 열의에 차서 미친듯이 밀어붙였던 젊은때였습니다. 밤도 많이 샜지요. 덕분에 지금 몸은 이따위가 되었지만 OTL

EXIF 정보에 따르면 카메라는 무려 제 첫 디카였던 코닥 DC210 ㄷㄷㄷ ..100만화소짜리… 군요.
날짜는 1997년 1월1일로 되어 있는걸로 봐서, 날짜 셋팅이 제대로 안되어 있었거나 데이터가 날라갔었나 봅니다.
게임 발매가 2000 년도라니까, 아마도 1999년도 시절 조이온때 대회의실 옆의 남는 방 하나 빌려서 작업했었나 봅니다.
지금 생각하면 그저 아련한 추억일뿐…

가락시장

Thu, 23 Sep 2010 12:03:21 +0000

킹크랩 두 마리가 쪄지고 있습니다. 츄릅.

맥도날드 산책

Tue, 21 Sep 2010 12:45:36 +0000

거의 20여년만에 만나는 친구가 점장으로 있어서 산책겸 잉여짓하러 놀러나왔습니다.
교양있게 재규어를 읽으며 커피질중.
여기는 확실히 예전에 없어진 4호 잠실점을 많이 닮았네요.

사람과 사람사이의 거리 실험

Tue, 21 Sep 2010 10:42:53 +0000

스킨쉽의 기술

사람마다 부담을 느끼는 거리는 분명 있지요.
이상주의도 좋지만, 분명히 현실적인 한계는 존재한다고 그어 놓고 접근하는 쪽이 저는 좋다고 생각합니다.
저런게 완전 없는 이상적인 사회를 부르짖지만, 실제로는 아무리 친하려고 해도 거리감은 존재하거든요. 우리는 식구가 아니니까.
인정할건 인정하고, 융합하여 살아갈 방법을 고민한다.

잠깐 회사에

Mon, 20 Sep 2010 17:11:57 +0000

머리가 아파서 공부좀 하려 봤더니 책이없어.
책가지러 잠깐 회사와서 카페테리아에서 책보고 있습니다.

TA 1강

Sun, 19 Sep 2010 21:21:42 +0000

솔직히 강의할 수 있는 수준이 되지 않은걸 알고 있지만, 이렇게라도 하지 않으면 금방 게을러지는걸 잘 알고 있기 때문에
수락해 버렸습니다. 흑흑 죄송해요 학생분들. 최선을 다해보겠습니다.
이쪽 과목은 뭘 가르칠 것인가에 대한 정립도 제대로 잡혀있지 않은지라, 편하게 편하게 해달라는 요청이 있었습니다만
부담되는것은 맞네요. 무조건 겸손은 답이 아닐 것 같아서 일단 수락했습니다만…
혹시 빼먹은 내용이나 추천하고 싶으신 내용이 있으시면 조언부탁드리겠습니다.

테크니컬 아트 강의계획 - 작성중

Sat, 18 Sep 2010 16:04:12 +0000

총 8강…
솔직히 강의할 수 있는 수준이 되지 않은걸 알고 있지만, 이렇게라도 하지 않으면 금방 게을러지는걸 잘 알고 있기 때문에
수락해 버렸습니다. 흑흑 죄송해요 학생분들. 최선을 다해보겠습니다.
이쪽과목은 뭘 가르칠 것인가에 대한 정립도 제대로 잡혀있지 않은지라, 편하게 편하게 해달라는 요청이 있었습니다만
부담되는것은 맞네요. 무조건 겸손은 답이 아닐 것 같아서 일단 수락했습니다만…
혹시 빼먹은 내용이나 추천하고 싶으신 내용이 있으시면 조언부탁드리겠습니다.

1강 색상깊이와 텍스쳐 포맷개념

- 텍스쳐의 포맷과 그 기초 .
    색상과 텍스쳐 포맷
    게임에서 사용하는 텍스쳐 포맷
    어째서 DDS를 쓰는가?
    DDS에서 사용 가능한 텍스쳐 사이즈
    DDS 텍스쳐의 속성(픽셀 포맷)과 그 색상깊이. DDS 텍스쳐의 단점. 알파 채널의 문제
    DDS를 쓰면 안되는 경우. DDS의 한계 극복법 (PNG나 TGA의 사용. TGA는 인덱스로 바꿀 수 있는 툴도 있음)
    큐브 맵의 개념, 큐브 맵의 제작법
    (실습. 큐브 맵 제작하기 : 어떻게 보나?)

참고
http://chulin28ho.egloos.com/5217901
http://cafe.naver.com/ui.cafe?iframe_url=https://jpcorps.com/ArticleRead.nhn%3Farticleid=613
* 위 링크의 내용에서 하나 틀린 부분은 ‘현재 게임개발에선 2D Texture 외엔 쓰지 않는다고 하니 나머지는 중요치 않습니다.’
입니다. DDS에서 큐브맵을 사용 가능한 것은 DDS의 큰 장점입니다. 큐브맵은 엠비언트 큐브, 큐브맵을 이용한 리플렉션 등 많은 곳에 사용 가능하지요.

텍스쳐 필터링 개념
(필터링과 샘플링을 따로 설명해야 할까..? 차이를 잘 모르겠어요. 이쪽은 그냥 아래 예를 들어주는 것으로 끝내야 하나…
일단 프로그래머들한테 물어봐야겠군요)

   linear filtering 선형 보간법/ Bilinear filtering (2중 선형 보간법)/ trilinear filtering3중 선형 보간법 /anisotropic filtering
   이미지 보여주는 것에 첨부하여, 맥스에서의 옵션 조절로 기능의 맛을 약간 보여주는 정도.
   여러 가지 개념과 이론이 있어서 전부 다 설명하기 어려움. 이런게 있다는 정도로 끝내야 할지도.

참고
http://blog.naver.com/members2?Redirect=Log&logNo=90078861328
http://en.wikipedia.org/wiki/Bilinear_filtering
텍스쳐 필터링

http://blog.naver.com/kyuniitale?Redirect=Log&logNo=40030708140
http://blog.daum.net/progress99/8014228

2강 버텍스와 알파 소팅

버텍스 데이터 개념

Vertex를 이용한 기초적인 용량 계산법.
-스무딩과 노말
-버텍스 칼라 개념
- 노말이란 무엇인가?

알파 소팅 이론
- Z 버퍼와 알파 소팅
- 알파 블렌딩과 알파 테스팅
개악마 알파 블렌딩

3강 카메라와 라이팅

카메라 이론
- 전통적 카메라 이론
전통적 카메라 움직임의 종류

전통적 카메라 용어와 디지털 카메라 용어와의 차이
DOF (피사계 심도) : 틸트 쉬프트 렌즈는 왜 그렇게 보이는가?
보케효과 : 렌즈 플레어

모션 블러

- HDR 이란 무엇인가? / 사진에서 쓰이는 HDR, 게임에서 쓰이는 HDR

레퍼런스 : 3D max 8.x - 디지탈 북스
게임영상연출 & 이펙트 - 게임아카데미
영상연출기법 - 바다출판사
http://www.geodetic.com/whatis.htm
http://www.gamecareerguide.com/features/222/book_excerpt_programming_a_.php

라이팅 개념
- 일반적인 3D 라이트의 개념
http://www.huevaluechroma.com/011.php

멀리 있는 것이 더 밝다?
이상한 그림자의 세계
- 실제 세계의 라이팅 구분

- 실생활의 라이트를 흉내내기 위한 노력
    레이트레이스
    레디오시티 - 버텍스 베이킹 레디오 시티 / 포톤맵에 의한 레디오시티 . 파이널 게더링
    커스틱 (Caustics)
    엠비언트 오클루젼 : SSAO

게임에서 사용하는 실시간 라이팅 기술
다이나믹 라이트와 쉐도우
스테틱 라이트와 쉐도우
라이트맵과 버텍스 베이킹
그림자. 셀프 쉐도우

4강 최적화와 충돌

최적화 개념 / 충돌개념 / AI 기초

- 업데이트와 드로우 콜
- 쿼드트리 , 옥트리
- 포탈 / BSP

A*
충돌박스 개념
LOD / LOD의 종류
   본LOD
   오브젝트 LOD
   쉐이더 LOD
   스테틱 LOD
빌보드

5강 캐릭터 / 배경 기술

6강 쉐이더 기초

쉐이더 기초

렌더링 프로세스
행렬
행렬이란 무엇인가? 메트릭스의 세계
- 버텍스 쉐이더와 픽셀 쉐이더

- 실습 (쉐이더 FX)

7강 쉐이더 기초 2 / 쉐이더 FX실습

피부 쉐이더 표현 방법
스페큘러
엠비언트 칼라 / 엠비언트 큐브

   - SSS 란 무엇인가
   - Rim Light : 림 라이트의 개념. 게임에서 쓰이는 림 라이트(유행하는) , 재질에 따른 림라이트의 성질 . 어째서 림라이트를 쓰는가?
   - 노말 맵

실습
소프트 파티클

…계속 작성중.

참고서적 : 디지털 라이팅 & 렌더링
쉐이더 FX

노트북 4대

Fri, 17 Sep 2010 09:37:19 +0000

평소에 하던 작업 말고 갑자기 다른 일좀 맡아서 하고 있습니다.

인터페이스랑 조작성 뒤바꿀 일이 있어서 작업하느라고 작업공간을 만들었는데 파티 테스트 하려고 보니 한대로 안돼서 어느새 노트북만 4대 …

팀 회식 왔슴둥

Thu, 16 Sep 2010 18:46:21 +0000

오늘의 팀 회식은 인도요리집 강가.
우리 팀 회식은 술도 안먹고 맛집만 찾아가서 깔끔하게 일찍 집에 가는 것으로 유명.

OST CD받음

Thu, 16 Sep 2010 17:48:09 +0000

비매품 한정판 . 이런 기념품 레어해서 참 좋아요:)

일단 강연은 잘 끝냈습니다만.

Wed, 15 Sep 2010 21:21:07 +0000

:) 역시나 팀장의 정치얘기는 뺄까말까 마지막까지 고민했던 주제였는데,
일반적으로 (정치 = 악) 으로 판단하고 계신 분들이 많지 않을까 하는 예상이 그대로 적중해 버리고 말았습니다.
뭐 이것도 저질러 놓은 업보이니…

원래 이 생각은 이 글
http://chulin28ho.egloos.com/4815035

에서부터 생각한 것이며, 강연에서의 ‘당신이 국회의원이 되었으면 정치를 하라’ 란 말은
사실 ‘수동적으로 묻어가지 말고 옳다고 생각하는 주장과 행동을 하라’ 라는 의미였습니다.
민주주의도 정치이고, 독재도 정치이니까요. 사실 무정부주의도 정치라면 정치중 하나입니다.
모든 집단의 결정을 내리기 위한 행동이 정치니까요. 여기서의 정치는 ‘행동’ 의 의미입니다.

인간은 정치적 동물이다.

아리스토 텔레스-
http://kin.naver.com/qna/detail.nhn?d1id=11&dirId=1112&docId=55181431&qb=7J246rCE7J2AIOygley5mOyggeyduCDrj5nrrLzsnbTri6Q=&enc=utf8§ion=kin&rank=1&search_sort=0&spq=0&pid=g5uGdz331y0ssvxWRc0ssv--514609&sid=TJCpPGKMkEwAADofS-U

위의 말처럼 여기서 말하는 정치란 자신의 이익을 위해서 이상한 방향으로 야비하고 비열하게 이끄는 못된 의미가 아니라
인간이란 공동체를 떠나서 살 수 없는, 모이게 되면 공동체와 공동체의 방향을 위해 움직이는 동물이라는 의미입니다.

즉 여기서 ‘정치를 안한다’ 라는 말은 ‘회사 돌아가는 방향에 전혀 신경을 안쓰고 시키는 대로만 한다’ 라는 의미였습죠.
그렇게 신경을 안쓰는 것은 ‘정치를 안하는’ 것이 아니라 사실상 ‘나쁜 정치를 하고 있는’ 것이라는 의미입니다.
하지만 이나라의 정치인 분들이 너무 정치 혐오증을 느끼게 행동을 하시는 관계로… 정치라는 얘기만 꺼내는 것도 위험한 사회가 되어 버렸군요 .

ps. 사실 가장 중요한 주제와 하고 싶은 말은 카운셀링 6단계였는데 말이죠 :)

부장과 사원의 문자대화

Sat, 11 Sep 2010 22:39:28 +0000

.. 외부사람들이 잘 못믿는 우리 회사 대화 분위기

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

000-0000-0000님의 말 (오후 09:49) :
000입니다 핸펀번호가 000 0000 0000 으로 변경됐삼 꼭 저장해주삼 ㅠㅠ

김윤정 (010-1111-1111) 님의 말 (오후 10:28) :
싫어

000-0000-0000님의 말 (오후 10:31) :
싫으면 시집이나 가버려욧 풉 ㅈㅅ저 아이폰 샀삼

김윤정 (010-1111-1111) 님의 말 (오후 10:31) :
풋 원래 너의 번호따위 저장 안되어 있었다

000-0000-0000님의 말 (오후 10:33) :
OTL 저주 할꺼에욧 사실 이번호 실수로 보낸거에욤 ㅋㅋ

김윤정 (010-1111-1111) 님의 말 (오후 10:33) :
ㅋㅋㅋㅋ 사악한놈
이게 사원과 부장의 대화냐 ㅋㅋㅋㅋ

000-0000-0000님의 말 (오후 10:39) :
ㄷㄷ 조랩이라서 겁이업서욧 캬캬캬

김윤정 (010-1111-1111) 님의 말(오후 10:40) :
캬캬캬 아이폰4 좋겠다

000-0000-0000님의 말 (오후 10:41) :
담주에 구경오세욧 절대 안보여줄께에욧 ㅋㅑ 캬

김윤정 (010-1111-1111) 님의 말 (오후 10:41) :
에잇 울팀에도 아이폰 산사람 넘침

000-0000-0000님의 말 (오후 10:42) :
젠장 나 이래서 겜회사시롯 ㅋㅋ

김윤정 (010-1111-1111) 님의 말 (오후 10:42) :
ㅋㅋㅋㅋ

강연자료 추가

Fri, 10 Sep 2010 08:55:51 +0000

일단 이정도 소심한 저항밖에…

… 아냐 좀 더 쇼킹하게 해볼까.

초딩개발자J의 막무가내 1인던전 잡설

Thu, 09 Sep 2010 19:55:34 +0000

개인적으로 예전에는 TBS를 조작성때문에 여러번 시도했다가 모두 포기했었습니다.
제가 좀 쓸데없이 예민한 구석이 있어서리 -_-a

제 눈에 안경인지는 모르겠지만 조작성 바꾼 후로 드디어 중간에 포기하지 않고 끝까지 할 수 있었습니다 -_-;;
아직 바닥 피킹 조작성 개선은 안끝났기 때문에 몇 번의 실수조작이 느껴집니다만, 해결방법도 일단 몇 가지가 보입니다 …

그건 그렇고, 덕분에 그동안 못해봤던 TBS를 즐길 수 있었습니다. 개인적으로 거기 어디야… 미이라 다음에 나오는 TBS… 그 큰 나무있고 물떨어지던.. 거기가 재밌네요. 90렙 근방의… 맨손으로 포쏘는 이상한 괴물 나오는데… 마구 끼어드니까 좋군요.

그리고 병욱이 고친 타일도 볼 겸, 조작성도 볼 겸 몇 판 트로이를 했습니다.
튜터리얼은… 고쳐야할 부분이 몇 군데 보이는군요. 가르쳐주는 방식도 조금 손봐야 할게 있고… 그 전에 일단, 몇 가지 초보자의 눈에서 인지하기 힘들었던 것들을 정리해 올려봅니다.

입장할때

이 상황에서 무엇을 했을까요? 저는 그냥 “전투방 개설” 버튼을 눌렀습니다.
맞는 행동은 전황조사나 주둔지 수비를 먼저 선택하는 것이었겠지만, 제 눈에 들어온 ‘버튼 모양’ 은 전투방 개설이었습니다.
‘몇 번 해보면 익숙해지겠지’ 라는 접근은 옳지 않습니다. 그 몇 번의 짜증이 쌓여서 게임 전체에 영향을 끼치게 되니까요.
보통 이런 경우라면, 일반적으로 색을 연하게 해 놓거나 , 체크박스를 넣고 비워 넣거나 해서 체크하고 싶게 만들어야 합니다만
지금은 ‘일반 텍스트 박스’ 와 구별할 수 있는 방법이 없습니다.
<보통 이렇게 넣곤 하죠>

그 다음에, 이래저래 실험하다가 그만 전투 바깥으로 나가버리게 되었는데, 다시 들어갈 수가 없더군요. 재입장 버튼을 찾을 수가 없었어요.

사실 ‘내 정보’ 를 보면 전투방에 재입장이 가능하더군요.
그런데 사실,

‘내 정보’
라는 말이
“내가 개설한 전투방에 재 입장하기” 라는 말로 들릴까요
“내 캐릭터의 각종 데이터와 정보” 라는 말로 들릴까요?
그냥 ‘내 전투방’ 하면 안되는 거였나요?

캐릭터 선택시

캐릭터 선택까지 왔습니다. 네네 왔어요.
일단 형태적으로도 아름답지 않은 느낌을 주는 비율의 화면이 뜨는군요.

전에부터 느꼈지만,

내 캐릭터 이름은 “0/5” 가 아닙니다.

저건 도대체 무슨 뜻일까요? (다 알지만, 제가 초보자의 마음을 빙의시켜 말하고 있는것도 아시지요?)
굉장히 쌩뚱맞은 위치에, 쌩뚱맞은 크기에, 캐릭터 이름 0/5 라는 쌩뚱맞은 정보를 출력해 주고 있습니다. 정보의 배열로 봤을때,
중요도는 굉장히 낮은 것 같습니다. 사실 그렇게 낮은 중요도의 정보라고는 생각하고 있지 않은데 말입니다.

그다음 이거. 보기도 힘들고 이쁘지도 않은 이런 식의 모자이크 표보다는
너무나도 유명한
이런 능력치도 있고, (능력치 이름 옆에 숫자 하나만 써주면 되겠지요)
3칸의 그래프로 표시해줘도 충분하고 훨씬 보기 좋고 한눈에 인지하기도 좋고 비교하기도 좋겠죠.
지금 캐릭터가 비대칭으로 이동거리가 바뀌는 것도 아니고…

그다음
이 지도는 뭘 말하고 있는 걸까요? (커다란 Z?조로가 나타났다? 우와아아앙?)
뭔가 단순히 빈자리를 채우고 있는게 아니라면, 적의 배치라던가, 이동경로라던가, 기본적 정보라도 주면 좋지 않겠습니까?
예를 들어 이런거라도 말입니다. 아니면 비밀로 하고 싶으면 아예 숨겨버리던가. 최소한 시작점이 어딘지 정도는 알려줘야죠.

이건 보너스.

바로 뭐 어쩌라고 … ㅋㅋㅋ

그래서 이래저래 중요도에 맞게 내가 다시 생각한 인터페이스는 대충이런 모양.

아니 뭐 그렇다는 거죠.

어쨌건 그래서 어찌어찌 들어갔단 말입니다.
튜터리얼에서도 할 말이 많지만 그건 일단 다음으로 미루고…

일단 게임을 해 봤습니다.
흠 연출대사가 나오는군요… 개인적으로 이정도 퀄리티라면 차라리 잘 그린 일러스트가 훨씬 낫다고 생각하긴 합니다만,
뭐 보기에 그렇게 이상한 정도까지는 아니군요.

그치만 이건 이상하지 않나요? 왜 말하는 캐릭터가 오른쪽 구석에 붙어서, 그것도 짤려 있지요?
저 손에 있는 것은 뭡니까? 뭔가 이상한 조각이 붙어 있군요
이건 좀 더 심하군요. 저는 처음에 ‘저 움직이지 않는 커다란 나무기둥’ 이 뭘까 라고 생각했습니다.
그 기둥 옆에 붙어 있는 십자마크는 뭔가 깨진건가? 라고 잠시 생각했습니다만,

이건 카메라를 캐릭터 완전 정면 (Y 방향) 에서 Perspective 도 아닌 Orthographic 으로 바라본 뷰입니다. ㄷㄷㄷ
만약 실제 세상에서 저런 카메라를 흉내내려면,

이 카메라로 1km 밖에서 촬영하면 그나마 비슷해 지겠지요.

좀 더 좋은 얼짱각도라던가… 를 정할 수 있었을 텐데 수정을 하지 않은 것이겠군요.
저라면 보기좋은 호감형의 일러스트로 대치했겠습니다만…

그리고, 게임 진행하다 보니까 함정에 걸리지 않는게 무척 중요하겠더라고요. 함정에 걸려서 부지기수로 사망했…
그럴 경우 주술서를 사용하면 함정을 파괴할 수 있을 것 같아 보이는데,
딸랑 저 메세지 나오고 끝? 왠일로? -_-a
그냥 작더라도 폭발되는 장면이 타일에 나오는 것으로 안좋나요?
스타의 스파이더 마인 폭발 정도라도 말입니다.
함정을 부쉈다는 뿌듯함이 전혀 안 느껴지더군요.

또는 마력의 탑 이펙트라는데 이건 또 너무 밝아서 다른걸 (심지어 캐릭터의 하반신까지도) 다 묻어버리는군요.
이런 과도한 이펙트 안좋습니다. 아무것도 구별할 수 없게 만들어 버리거든요. 특히 완전한 전략게임으로 바뀐 TBS에서는 , 인디케이터 이상으로 올라가는 지속이펙트는 반드시 피해야할 항목입니다.

게다가 몇 분 남았습니다 표시가 왜 이리 안보인다는 의견이 많나 했더니, 저랬었 …
사방이 전부 움직이는데다가 채도도 비슷한 글씨가 어둡게 움직이니 눈에 띌리가 없었던 거죠.
그냥 심플하게 표시해도 얼마든지 눈에 띄였을텐데, 과도한 디테일이 인지도를 떨어뜨리는 전형적인 현상이 일어났습니다.

보통 흰색으로 단순하고 굵게 표시하는게 ‘자질구레한 디테일’ 이 많은 게임에서는 잘 눈에 띄지요.
굉장히 무섭게 협박하고 싶다면 붉은 색으로 처리해도 좋구요.

오늘은 일단 이정도, 튜터리얼 얘기라던가 추가되는 점들은 추후에 또 올리도록 하지요.

KGC2010 아젠다

Wed, 08 Sep 2010 23:35:53 +0000

제 강연 시간엔 다들 철권 제작 들으러 가겠군요 ㅋㅋ

그때그때 달라요

Wed, 08 Sep 2010 10:04:43 +0000

그게 참, 언제나 정확한 100%의 답을 주고 싶지만 특히나 최적화의 부분에서는 명확한 답을 내려주기 힘듭니다.
게임에 따라서, 카메라에 따라서, 캐릭터에 따라서, 환경에 따라서 만드는 방법의 효율성이 마구 왔다갔다 하기 때문이지요

비공개 문서로 제작한 퍼포먼스 테스트의 결과에 따르면, 클론을 이용한 오브젝트 카피는 퍼포먼스가 점점 증가하다가 각 오브젝의 폴리곤이 1000개 이하로 내려가면서부터는 퍼포먼스가 급격히 저하되는 결과를 나타내기도 했었죠.

<이런 거>

이렇게 게임 개발에서는 ‘절대적인 영역’ 같은게 없습니다. 무엇을 하면 반드시 좋아진다라는 그런 영역 말이지요.
그러므로 최적화 할 때에도 구체적인 최적화보다는 근본적인 최적화를 먼저 작업하고, 추후에 데이터가 플레이 될 때 구체적인 최적화를 해 주는 것이 좋습니다. 예를 들면 tga로 만든 큰 사이즈의 텍스쳐 같은 것이겠지요. 이것을 dds로 만들고 용량줄이는 것은 아무것도 아니니 나중에 해 주는 것이 좋습니다. (물론 텍스쳐가 외부로 관리된다는 전제가 있어야 하지만요)
또는 폴리곤 줄이기도 생각보다 쉽습니다. 캐릭터는 어려워도 건물에서는, 폴리곤 줄이는게 그렇게 엄청난 기술이 아니지요.
UV를 건드리지 않고 줄이는 방법이 생겨 버린 이후로 말이죠.
이런 것도 구체적 최적화에 약간 속합니다. 언제든지 줄일 수 있고 줄이면 효과가 확실한 것들은 나중에 줄이는 것이 좋습니다.
게임이라는게 미묘해서, 게임의 스타일과 환경에 따라 최적화의 방법은 어떨때는 맞고 어떨때는 틀리기 때문이지요

환전하러갔는데

Tue, 07 Sep 2010 08:47:53 +0000

80년대 구권은 환매매가 안된다는군요. 중국갔다 오시는 분은 지갑에 구권없나 잘 보심이…

5위안은 800원 정도라길래 그냥 기념으로 가지기로 했습니다:)

아아 고급호텔

Mon, 06 Sep 2010 11:05:50 +0000

5성급이라고 해도 다 같은 호텔이 아니로군요. 상하이 동방빈강호텔보다 훨씬 좋네요.
지금까지 평생 다녀본 호텔중 가장 좋았어요. 역시 중국 정부의 힘…

저 통유리로 된 샤워부스 때문에 2인 1실이었으면 상당히 민망했을 …

북경 갔다 왔습니다.

Sun, 05 Sep 2010 23:00:23 +0000

아이고 삭신이야. 잘 다녀 왔습니다.
일정이 너무 빠듯해서 관광같은건 꿈도 못꾸었습니다 (…)

가는 날은 새벽 5시에 일어나서 출발하지 않나, 1시 반에 겨우 호텔 도착하니 2시에 회의시작, 일정 끝나니 9시…
쇼핑몰 한시간쯤 돌고 바로 돌아와 씻고 뻗고 다음 날 아침 8시 반에 체크아웃하고 공항출발 …
정말로 딱 일만 하고 왔네요.

사진기는 가져갔지만 찍을 일이 없…

뭐 일단 출발이요

오오 컵 전용 홀더까지 있는 신형 비행기구나 . 역시 KAL기 짱이야. 라고 생각했는데
이게 오히려 구형이었읍니다. 올 때 진짜 신형 타 봄

럭키! 토요일에 출발해서인지 옆자리 2 좌석에 아무도 없네요. 혼자서 뒹굴대며 이코노믹 클래스의 최고 호화로움을 느껴봤습니다.

음 ? 뭐야 이 어눌한 한국말은.
중국간다고 여기서부터 중국 분위기를 낼 것 까지야.

추억이네요. 이런 이어폰.

역시나 재미없는 게임만 가득.

아아 날씨 좋습니다.
북경 국제공항은 KAL 쯤 되어야 교통좋은 2청사를 쓸 수 있다는군요. 그래서 배려해 주신듯.

기내식 기내식. 무난하군요

두어 시간만에 도착한 북경공항.
저기 멀리 보이는 것은 북조선의 고려항공 비행기…!!
중국에 온 실감을 느끼게 해주는군요.
하긴 공항에서 평양이라고 씌인 쇼핑백도 봤다는…

공항도착입니다.

택시는 현대 엘란트라 (한국명 아반떼 XD) 와 폭스바겐이 거의 다네요.

아놔 얼마만이냐 ㅋㅋㅋ

고속도로 톨게이트는 이쁘군요.

닛산 티아나 (한국명 sm7) 인데 번호판이 없엉 ㅋㅋㅋㅋㅋ 걸리지만 않으면 된다다군요

중국에 오긴 왔나 봅니다. 새벽부터 움직여서 정신이 혼미…
묘하게 특이한 IBM 건물.

공항에서 한시간 거리쯤 되는 호텔에 왔습니다.

공항도착

Sat, 04 Sep 2010 07:24:09 +0000

뭔가 게임 심사를 위해 주말동안 중국으로 출장입니다
아이폰일 때는 트위터만 줄창 매어서 하다 역시 다시 PC가 생기니 블로그를 하네요,
아직 키보드가 손에 익지 않지만 익숙해지면 100여타 정도까지는 기대할만 하겠습니다,

빌립 사람들 키보드 배치한 것 보면 진짜 센스가 장난 아니예요

사진은 공항에서 잉여롭게 맨토링 팀 주간보고를 체크하는 늠름한 모습.
사진은 아이폰으로 찍어서 N드라이브로 올린 후 포스팅. 이야 세상이 바뀌고 있어요

잇힝

Wed, 01 Sep 2010 18:34:10 +0000

수잉추 작업도촬

TA 상식

Wed, 01 Sep 2010 09:44:30 +0000

TA 상식: 그래픽은 눈에 보이는 순간이 완성이고 프로그래밍은 눈에 보이는 순간부터 시작이다.

디버그에서 돌아간다고 완성되었다고 생각하면 싸움나요.

그래픽의 심장을 가지고, 프로그래머의 머리로 생각하라.

자작 크래들

Tue, 31 Aug 2010 08:52:51 +0000

이것은 친환경 그린 자원인 나무에서 추출한 압축 섬유질 페브릭 으로 만들어진 아이폰 크래들입니다. 절대 노트북 충격방지 따위에 쓰는게 아님

적조했습니다.

Sun, 29 Aug 2010 22:52:01 +0000

한동안 마음의 여유가 없었거든요 :)
인터페이스 수정작업하느라고 집중하고 있었고, 가끔 하고 싶은 말들은 트위터에 해버리는 바람에 정작 블로그는 가볍게 쓰지 못했었습니다. 이것이 트위터의 매력이로군요. 게다가 회사에서는 야머를 사용하고 있어서 사실 블로그가 좀 뒷전이 되어 버렸습니다.

KGC 2010 일정이 발표되었군요. 300석!!! 부담감에 갑자기 PT 자료를 열고 열나게 뜯어고치고 있었습니다. NDC 때와 기본적으로는 같은 포맷이지만, NDC는 이틀만에 만든 자료라 사실 강연의 리듬이나 흐름, 주제 전달부분과 타이밍을 정밀하게 신경쓰지 못했거든요. 각종 예시와 비유, 알아듣기 쉬운 결론등을 짜내기 위해서는 많은 시간이 듭니다.

게임이건 영화건 만화건 소설이건 강연이건 튜터리얼이건, 소비하는 사람들의 리듬과 타이밍, 흐름을 정밀하고 감각적으로 느끼면서 작업하지 않으면 멋진 작품은 나오지 않는 법입니다. 그런 의미에서 강연을 준비하는 것은 게임 인터페이스와 매우 비슷한 느낌이랄까요.

아무튼 바쁘더라도 나름대로 즐기며 살고 있으니,

날 동정하지 마세요 (뭔소리야)

색각 이상, 색약, 색맹의 배려를 할 때가 되었다.

Mon, 23 Aug 2010 11:26:13 +0000

색각 이상. 색약, 색맹의 배려가 없는 게임 현실

예전에 금자양 일할 때부터 이쪽 부분의 지원을 위해 뭔가 해야 하지 않나라고 생각해 왔었는데,

그간 잊어버리고 있다가 글을 보고 다시 인지하게 되었습니다.

문제는 개발환경이겠네요. 이쪽에 대해서 좀 더 의학적으로 알아봐야겠습니다.

네비게이션 구조 구상중

Mon, 23 Aug 2010 00:08:13 +0000

원래 달려있는 네비게이션이 좀 찐따인데, HUD랑 연동되기도 하고 그래서 함부로 손대기도 좀 그렇고…
그래서 일단 구형 네비 가지고 저렇게 만들어 봤습니다.

깔끔한 편이긴 한데 좀 구형이라 더 깨끗한 모습을 가지고 싶어서, 동호회분께 팔아버리고 아이폰 전용 네비인 맵플로 교체.
우후후 이제 더 깔끔해 질 수 있다!!

…
일단 평도 가장 좋은 편이고 음악도 동시에 들을 수 있고 깔끔하고 값싸고 교통정보까지 보여주는 등 보조네비로는 분에 넘치는 성능을 가지고 있어서 만족하며 설치해 봤는데…

OTL
차 안에서 네비를 못잡아…
아니 잡긴 잡는데, 널뛰기를 해요. 아무래도 잘 못잡는 것 같은 느낌.
그래서 내 아이폰이 이상한가 해서 주말동안 밀고 다시 깔고 난리를 쳤는데
그래도 이상해 OTL

그래서 에이 환불받아버릴까보다 생각하고 마지막 테스트 겸해서 마눌님 차인 뉴카렌스에 연결하고 해봤더니
… 너무 잘돼 …….
아아아아아아아아아아아

뭔가 유리창에 금칠이라도 해놨단 말이냐..
내일 유리창에 더 가까이 설치하고 마지막 테스트 해 본다음 안되면 할 수 없이 네비게이션 하나 또 사야 겠네요 흑흑흑.
교통정보까지 되는 작은 놈은 없는데… 흑흑흑….

버텍스에따른파일용량계산법

Sun, 22 Aug 2010 23:48:13 +0000

버텍스에따른파일용량계산법
모든계산은텍스처용량을제외하고계산

l 버 버텍스수는 1,000개라고가정

매핑없는순수버텍스만가진오브젝트

버텍스는 Position(위치) 정보만가지고있으면된다.

Position은 X, Y, Z 값이필요. 각값은 float으로 float 1개당 4byte를쓴다.

따라서, 1개의 Position을표시하기위한용량은 4*3 = 12byte

1,000개의버텍스를가졌기때문에 12 * 1,000 = 12,000 byte = 12kb가된다.

하지만, 요즘은 Index 없이버텍스를표현하지않으므로 Index를추가한다.

Index는버텍스를그리는순서를저장하는데, 통상버텍스보다많다.

Index는 Integer 하나를사용하는데, Integer 하나당 4byte를쓴다.

대략버텍스숫자만큼만쓴다고가정하면, 4 * 1,000 = 4,000 byte = 4kb가된다.

1,000개의버텍스를가진기본오브젝트의용량은 12 + 4 = 16kb이다.

* NIF의경우여기에각종정보들이포함된헤더가추가되므로용량은이보다늘어나게된다.

매핑정보를가진오브젝트

텍스처한장의매핑이되어있다고보면, 각버텍스마다하나의 UV 좌표를갖게된다.

1개의 UV는 2개(U, V)의 float을갖는다. 즉, 2*4 = 8byte

기타추가되는내용

Normal : 12byte

BiNormal : 12byte

Tangent : 12byte

예제

만약어떤오브젝트가 Index, Position, UV1, UV2, UV3, Normal, BiNormal, Tangent를가지고있다면용량이얼마나될까?(텍스처제외, NIF 헤더제외)

버텍스 1개당용량 = Index (4) + Position (12) + UV1 (8) + UV2 (8) + UV3 (8) + Normal (12) + BiNormal (12) + Tangent (12) = 76byte

버텍스가 1,000개라면 76kb

버텍스가 10,000개라면 760kb

단순텍스처한장만사용하는오브젝트와의비교

버텍스 1개당용량이 Index (4) + Position (12) + UV1 (8) = 24byte 이므로, 76byte에비해 1/3 수준임.

웨딩 스넵사진

Sun, 22 Aug 2010 22:00:40 +0000

조명근 ♥ 김지현
저저번주 페레스튜디오에서 촬영.

직장동료와 친구 동생을 소개시켜주었는데, 어느새 결혼에 골인하게 되었군요 :)
처음으로 맺어지는 소개 커플인데다가 둘다 저와 친한 관계라서 더욱 애착이 가는 스냅사진 촬영이었습니다.

총 800장의 사진중 건진건 500장, 그중에서 약 100여장이 쓸만하더군요. 기본 수정에만 일주일이 걸렸다능 ;;; 하악하악.
특히 수정이 힘들었던 이유는 빌어먹을 마이크로포서드!!!! 역시 아무리 성능좋은 GF1 이라고 해도 스튜디오급 기기와는 상대가 되지 않는군요. 담엔 5D를 사버릴테다. 아 라이브뷰가 좀 그런가… 그럼 7D라도…

아무튼 둘 다 성실하고 착한 친구들이니까 아무쪼록 알콩달콩 아들딸 낳고 잘 살기 기원합니다.
도와주는 것도 없이 알짱거리면서 사진찍었는데도 쿨하게 봐주신 페레스튜디오 실장님에게도 감사드립니다.

포토샵 수정여부는 비밀로 하는게 예의.

인터페이스 수정중

Fri, 20 Aug 2010 17:23:25 +0000

원래 잡학에 잡식에 아무데나 투입되는 버전이라, 라이브 프로젝트의 전투 인터페이스를 수정중입니다.
기존 인터페이스에 불만을 잔뜩 토로했으니, “불만있으면 직접 고쳐봐라” 라는 거죠 -_-a
팀원들 동원하고 나는 니나노하면서 끄적대볼까 생각하면서 고쳐야 할 리스트를 정리했더니,
배경 그래픽 25% 이펙트 40% 프로그래밍 20% 인터페이스 15% 정도 느낌의 인원이 ‘동시에’ 작업해야 한다는 결론이… ㄷㄷㄷ

그래서 배경 그래픽 - 타일 색감 교정 - 만 배경팀에 맡기고, 프로그래머 한 명 배정받아서 혼자 작업중입니다 ㄷㄷㄷ
덕분에 차기작 제작은 이주일쯤 보류. 하긴 이게 되어야 응응응 될테니까. 중요한거네요

일단 목표는 이것.

유저가 생각하지 않고 느낌으로 알아야 할 것과, 한 번 생각한 후에 의지에 따라 인지하여야 할 것을 구분한다.
유저의 시선은 동시에 하나씩밖에 보지 못한다고 생각한다. 무조건 모든 인터페이스는 순위를 정한다. 가장 눈에 띄는 인터페이스는 크거나, 움직이거나, 밝거나, 디자인이 단순한 인터페이스이다. 그중 녹색이 제일이요, 붉은색이 다음이다.
보지 않고 느낄 수 있는 인터페이스가 최고이다.
유저의 생각 흐름을 유도하라, 유저가 가장 먼저 알고 싶은 것은 ‘내가 어딨지?’ 라는 거다.
전투 게임이라면, 기본적으로 이동하고 공격하는데 모든 우선순위를 걸어라. 데미지라던가, 이동지역에 가면 느려진다던가, 장애물이 있다던가 등등을 생각하지 않고 ‘느끼게’ 만들어라.
인터페이스에서는 유저를 바보로 알아라. 절대 유저는 복잡하게 생각하지 않는다. 아무 생각 없이 무심하게 플레이 해보라. 답은 반드시 나온다. 유저가 원하는건 어떤 조건이 아니라 ‘클릭하면 그냥 가란말야 이 바보야! ’ 이다.
복잡하고 역동적인 화면이 좋은가 정갈하고 심심한 화면이 좋은가? 균형은 모든 경우에서 유용한 해결책이다.
카메라의 움직임과 뷰는 모든 게임 화면 인터페이스에서 가장 먼저 잡아야 할 규칙이다. 그 다음은 배경이다. 그 카메라와 그 배경에서 가장 잘보이는 인터페이스를 만들어라.

장난질

Thu, 19 Aug 2010 16:11:48 +0000

어느날 누구랑 수다떨고 싶어 궁시렁대고 있는데 걸려온 문자. 장난질에 낚이면 놀리려 했는데 안낚이데.

10년간 외국 50번 다녀오니[펌]

Thu, 19 Aug 2010 16:06:28 +0000

안녕하세요.
서른 초반 직장인입니다.
당직이라서 사무실 있거든요.
해외서 재밌었던 일들 올리시는 거 보니 저도 좀 생각나는 것들이 몇개 있네요.
99년부터 학업, 출장을 위해 여러 나라 다녔습니다.
스무 나라는 넘는 것 같네요.
특히 아프리카와 동남아는 같은 나라를 여러번 다녀온지라 방문 횟수까지 따지면 꽤 될 듯 합니다.
몇가지만 읊어보지요. 몇개만 추려도 상당히 길어질 듯.
재미없다고 야유보내고 그러면 새해 금연 안되고 애인 안생기고 돈 나감. 워워~
새해 복 많이 받으세요!!

*아프리카 (다수 나라)

체류 기간 길어서 젤 오래 있었음.

모든것이 열악하고 없이 살아 그런지 뻔뻔스럽게 거짓말 잘함.

월급 오전에 주니 다 집으로 토낌.

담날 한국인 관리자가 한명씩 조지기. 그 중 한명 엄마 돌아가셨다고 집에 갔다고 함.

관리자가 서류 집어던지면서 ‘닌 엄마 세번 죽냐’고 소리 지르는 거 들었음.

저번에도 그러고 갔던거임.

엄마 세명 있다고 당당히 얘기함.

순간 아 그런가 싶었음. 낚일 뻔.

국민 아이큐 평균 69인가…그러함.

물론 아이큐라는게 절대적인 기준이 될 순 없겠지만 수리 계산 능력 현저히 떨어짐.

(아. 이건 아시아 쪽이 똑똑하긴 함)

2500더하기 250하면 2750 아니냐. 라고 따지자.

are you sure? 이럼서 개정색.

그럼서 밑에 직원한테 계산기 갖고 와보라고 호통 치더니 계산해보고 깜놀.

걸어다니는 계산기 취급 받았음.

애들이 나만 보면 무술하자고 깝침.

태권도 1단 어설픈 검은띠인지라 프로인 척 하면서 발차기랑 정권 지르기 정석대로 알려줬음.

또 어설프게 아는 합기도류 호신술 몇개 시연.

얘들 신체능력 상상 초월.

마음 순수하고 애 같아서 유치하게 덤블링이나 발차기 자꾸 보여주고 인정 받으려 하고

태생 자체가 호전적인지 나랑 자꾸 대련 붙으려 함.

조낸 아팠음. 실전으로 발길질 함.

그럼서도 지가 세게 차는 줄도 모르고 내가 어쩔 수 없이 맞는다는 거 모름. 안 아플거라 생각하는 것 같음.

일대일 맞장뜨면 난 백프로 터짐. 장담함. 눈에 보임.

한국은 중국이랑 똑같은 말 쓰는 줄 알고 한국 어딨는지도 모름.

(이건 우리도 ‘아프리카’라고 하면 거의 하나로 생각하지만 큰 대륙. 언어, 사람 다 다름. 반성해야 함)

되게 못살면서도 자기들 머릿속엔 백인 다음에 흑인 다음에 황인종임.

아프리카 애들 메이커 좋아함.

NIKE랑 KAPPA(사람 서로 등 맞대고 앉은 모양) 로고 가슴에 문신 새긴 놈도 봤음.

내 짐가방 사라지고 일주일 만에 찾았음.

열어보니 없어질 물건들은 없어졌는데 특이사항은 베트남서 장당 오천원 주고 산 가짜 나이키 티 여러벌 다 훔쳐갔는데

그래도 걔중 명품이라는 베리베리 티셔츠는 손도 안댔음.

아프리카 내 도시에서 도시로, 나라에서 나라로 여러번 다니면서 위험천만 쌍발 프로펠러기 많이 탔음.

뱅기 연착 여덟시간까지 기다려봤음. 방송도 안 나옴. 기다리라 함.

몇번 이골 난 후 긴장 풀리니 한번은 화장실 다녀온 후 내 짐은 싣고 뱅기는 떠버린 적도 있음.

뱅기에서 기장이 담배핀 거 본 사람?

나 봤음.

특히 이쪽 사람들 암내 장난 아님.

나 자다가 내 앞에서 짐 꺼내려고 팔 들었던 승무원 겨드랑이 암내 때문에 잠에서 깬 적 있음.

겨드랑이에 후추가루 들이부은 것 같음.

한국 간식류 사탕, 음료수, 아이셔, 천하장사 쏘세지 보면 떡실신.

아이셔 한번 뿌렸다가 줄 서는 거 봤음.

중요한 곳 들어가는데 출입증 없어 빠꾸 먹다가 천하장사 쏘세지 하나 내밀었더니 뭔지 모름.

까서 줬더니 통과시켜줬음.

한국 컵라면은 아주 싫어함. 나 배고파서 굶고 있을 때 일하는 놈들 갖다 줬더니 냄새만 맡아보고 패대기 쳤음.

아까워 죽을 뻔.

접해 본 애들은 한국 노래 환장함.

특히 브라운 아이즈나 플투 스카이, 에스 지 워너비 등 소몰이 창법에 열광.

현지인 중 하나가 나 정말 좋아하는 노래 있는데 제목 알고 싶다 해서 음이라도 좀 불러보라 하니.

“베이베~ 음음음아~” 라고 했음.

10초 생각하다가.

“베이베~ 내사랑아~ 이제 그만 내게 돌아와줘~” 맞냐 물었음.

맞다 함.(브라운 아이즈 ‘가지마 가지마’)

물은 놈이나 맞춘 나나 대단하다고 생각함.(내 가창력 쩔어!)

러시아.
극동 아닌 유럽에 가까운 곳 주로 방문.

러시아에 갖는 선입견 중 하나.
보드카를 물처럼 마신다. 주량이 강하다.
강한 선입견을 앞세우고 갔음.
콜라랑 위스키랑 섞어 마시고 새벽 네시에 떡실신 된 사람들 하나씩 업어다 택시 태워 보내면서
내가 여기서 왜 한국서 하던 짓거리를 또 하고 있는가 생각했음.
참고로 나 술 그냥저냥 보통 수준.

한날 시장 구경 같이 가서 이상한 양배추 피클 같은 거 가리키며 ‘이거 카레이스키(고려인)들이 만든 김치’라고 했음.
이거 김치 아님. 다음에 진짜 김치 갖다 주겠음.
다음 출장에 공항서 팩에 든 김치 사다 맛 보여줬음.
마늘 냄새 난다 할까 걱정했었음.
기우였음.
환장함. 김치국물까지 빵으로 찍어 긁어 먹었음.

식당 가서 김치 꺼내면서 접시 하나 부탁하면 사람들이 김치를 받아가서 주방서 접시에 담아다 줌.
한날 김치 위에 하얀 가루 뿌려져 있길래 보니 포장 안에 들어있는 가스흡수제까지 스프인줄 알고 풀어놓았음.
걷어내느라 땀 뺐음.
그 다음에는 무말랭이, 마늘장아찌,컵라면 사 갔음.
호밀빵 위에 버터 바르고 치즈 얹고 무말랭이 얹어 먹는 스킬 공동으로 개발하여 파티 열고 그날로 들고 간 김치 완판.

한국 컵라면 먹어보고 ‘영혼을 울린다’고 했음.
그럼서 질질 울었음.
근데 러시아 히트상품 중에 팔도 도시락 있음.
맛 좀 느끼한데 먹을만 함.

베트남.
베트남서 세달 살았음. 중국집도 없는 시골 동네서 한달 버티다 미칠 것 같아 뱅기타고 호치민으로 탈출.
기쁜 마음으로 김치 3키로 구입.
거래처에서 만나자 해서 가니 으리뻔쩍한 주점.
주방에다 키핑해달라고 줬더니 잠시 후 양주랑 같이 김치 3키로 대짜접시에 까서 나옴.

왈왈 짖고 다시 싸들고 뱅기 타고 넘어왔음.
나 있던 호텔 방에 냉장고 너무 작고 힘 떨어져서 주방에 맡겼음.
사회주의 국가 특성 상 서비스 마인드 현저히 떨어짐. 손님인 나랑 거의 친구먹음.
김치 자꾸 시식함.
갖다 줄때마다 줄어있고 쿨하게도 ‘맛있더라!’ 칭찬해 줌.
니들 먹으라고 뱅기 타고 가서 사온 거 아님.
끝내 이길 수 없어 대인배처럼 굴기로 함.
호텔 주방 직접 들어가 장금이로 변신. 김치볶음밥 제작.
호텔 사장도 와서 먹었음.
정기적으로 만들어서 상납했더니 나중에 호텔 숙박 계산할 때 꽤 많이 할인 받았음.

한국 드라마 히트 치던 몇년 전( 지금도 인기 있겠죠?)
티비에서 매일 방영.
문제는 성우가 한명.
등장 인물 여러명일 때도 무조건 한명이 더빙함.

한국이 축구 잘하는데 부러움과 아시아인으로서 자랑스러움 같이 느끼는 것 같음.
2006년 월드컵 당시 본선 경기 광고할 때 한국 경기 장면 젤 많이 나오면서 배경음악은 ‘손에 손잡고’였음.
감격 먹고 울었음. 정말 방에서 찔끔거렸음.

박지성 사랑함.
장동건 사랑함.
장동건을 ‘양동군’으로 발음함.
첨에 양동근이 베트남 사람들한테 먹히는 외모인 줄 알았음.

한날 술 너무 많이 먹고 공원서 쓰러졌음.
호치민 동상 옆에 쓰러져 자다가 경찰에 잡혀갔음.
신성한 호 아저씨( 호치민 매우 존경)를 모독했다 하여 큰일 날 뻔 했으나
내 김치 자주 훔쳐먹던 호텔 직원이 오토바이 끌고 와서 나 델꼬 감.
얘 착한 애고 맨날 일만 하니 한번만 봐달라 사정하는데 가슴 뭉클.

베트남 출국일 가까워오면서 당시 여권이 거의 뜯어질라 했음.
베트남에서 옆나라 라오스로 너무 자주 넘어다니고 스탬프 찍으면서 너덜너덜해진거임.
그냥 뒀어야 하는데 또 불안하다고 강력본드로 붙였음.
하노이 공항서 여권 펼치는 순간에 뚝 부러짐.
잡혀감.
여권 위조 혐의.
통역관 왔음.
한국말 하는데 도저히 못 알아듣겠음.
영어 통역 가능자로 요청하고 둘이 멍 때리고 앉아있다가 한국말 어디서 배웠냐 물어보니
안산. 씽크대 공장! 이라고 했음.
그럼서 니가 내 말 못 알아들어서 나 짤릴 거 같다고 원망했음.

알다시피 베트남 오토바이 천국임.
거기서 사귄 놈이 재밌는 구경 시켜준다고 야밤에 공원 델꼬 갔음.
공원서 오토바이 위에 우리 아베크 족 차 안에서 붕가붕가 하듯이 오토바이 위에서 붕가붕가.
묘기에 가까움.
대체 왜 저기서 저러는지 이해 안됨.
근데 괜히 멋있음. 부러웠으나 경험해보진 못했음.

우크라이나 갔음. 미녀 천지임.
한가인이 밭갈고 김태희가 소 모는 건 과장이지만 환경 미화원 청소하다가 마스크 벗을 때 얼굴 보고 깜놀.
차라리 한국서 란제리 모델만 해도 먹고 살 듯.

근데 대부분 영어 못하고 한국에, 동양인 자체에 관심없음.
그쪽 특성임.
그쪽 눈에 나는 그냥 노란 원숭이.

나 말고 동양 사람 한명도 못봤는데 천연덕스럽게 러시아 말로 말 걸어 옴.
내가 러시아 어 못할 거라는 생각 전혀 안하는 것 같음.
바가지 쓰는 경우도 없고, 특별히 눈길 주지도 않음. 그냥 투명인간 취급.
근데 일본 좋아함. 일식집 성업 중이고 일본 애니메이션에 호감 많은 듯.
곤니찌와, 곤방와, 부시도, 아리가도, 사무라이 자꾸 말하길래 화 버럭 냈었음.
일식집 갔더니 말이 일식집이지 아시아 퓨전임.
김치란 메뉴 있어서 보니
‘~according to chinese classical recipe..’ 정통 중국 조리법 따라 만들었다는 말.
씁쓸함.
참고로 러시아, 동유럽 권 일식집에서 장국이나 해초류 등 울 나라 기준 기본 무한리필 아이템도 돈 받음.
비쌈.

동남아 (싱가폴, 홍콩, 미얀마, 태국, 라오스 등등)

알다시피 한류 열광.

근데 드라마 할때마다 워너비 바뀜.

한국 아침 드라마나 크게 히트 못친 드라마 같은 거 할 때 배우들 사진 열쇠고리나 브로마이드로 잘 팔림.

미얀마에서 이정진이랑 송일국, 그 외 뜬금없는 비인기 배우들 사진 울 나라 광화문, 경복궁 같은 국가 중요 문화재 입구에서 팔고 있음.

그래도 송혜교, 김희선은 언제 어디서나 지존급.

동남아 쪽 여러 나라에서 건강식이라고 이상한 것들 많이 먹었는데

개중 기억에 단연 남는 건

부화하기 직전 병아리 들어 있는 계란. 곤달걀이라 함.

껍질 까니 병아리 웅크리고 있음.

안 먹으면 실례일 것 같아 먹었음.

물똥쌌음.

팔길이 만한 바닷가재 등에 대나무 빨대 끼우면 투명한 피 나오고 그거 몸에 좋다고 받아 먹으라 함.

빨대 꽂을 때 바닷가재 이상한 소리 냄. 비명소리 비슷함.

죄책감.

큰 술통 들고 왔는데 안에 뱀, 도마뱀, 까마귀 등 수십마리 짬뽕되어 있었음.

그거 먹으면 강한 남자 된댔는데 그 이후로 삭았음.

벌받은 거 같음.

터키.

한국 사람들에 우호적임.

2002년 월드컵 3,4위 전 때 관중석에서 터키 국기 걸어준 것 보고 역시 형제의 나라람서 감동 눈물 흘린 사람 많음.

반면에 우호적인 척 하면서 사기 치려는 사람들도 많음.

술집서 20분 앉아 있다가 나오는데 500불 계산서 폭탄 맞은 적 있음.

따지려 했는데 기도들이 와서 ‘형제’라고 했음.

계산해주고 형동생 맺었음.

캐나다.

99년 어렸던 시기 젤 어설펐음.

닭다리 하나 넣고 통발에 게 잡기 하다가 걸렸음.

한 시간에 스무마리는 낚았음.

그러다 걸려서 자연보호 철저히 하는 나라라 봉변 당할 뻔.

일본 사람인 척하고 빌고 빌어 토꼈음.

뱅쿠버 유명한 시계탑 위에 올라가서 사진 찍다가 걸렸음.

일본 사람인 척하고 빌고 빌어 토꼈음.

후회되는 과거.

다녀보면서 느낀 한국의 특징.

식당에서 물 공짜로 주는 나라는 한국이 거의 유일.
한식 자체가 독보적인 음식이며 문화임.
   메인 메뉴 하나 시키면 밑반찬 딸려 나오는 문화는 유일함.
   김치나 김 같은 사이드 메뉴들 리필 가능하다는 말에 모두 다 놀람.
   사이드 메뉴에 대해서는 선택권이 없다는(밑반찬 총각김치 나왔는데 싫다고 물김치 달라하는 경우 없잖아요?) 말에도 흥미진진해 함.
한국 사람 옷 잘 입음.
한국 사람 팔다리 비율이 좋고 동양인 중 좀 괜찮은 외모임.
업무 능력 우수함. 기본 타고 나는 머리 있는 것 같음.
주량 강함.
한국을 아예 모르면 모를까, 드라마나 가요 접해 본 사람들은 열광함.
한글 보면 그림 같다 함. 그래서 아랍 신밧드 애들한테 니네 글자는 라면 뿌개논 것 같다 했음.
경험해 본 사람들은 대부분 ‘불판에 삼겹살’ 환장함. 직접 굽는다는 자체에 신선한 충격 느끼는 듯.
식습관이나 입맛 자체가 상당히 독창적임. 한국인 대부분이 입 짧은 편. (김치 없인 못산다! 고추장 없인 못산다!)
삼성, 현대는 없는 곳이 없다.

결론은 한국만큼 수입 대비 물가 싼 곳 거의 없고 치안 안전하고 살기 좋은 나라 없음.
다만 문제는 교육비 비싸고 사람들 너무 빡빡하다는 것.

나름 재밌다고 생각되는 것만 추렸지만 추억이 많습니다. 눈물 나는 경험도 많았고.. 가슴 아팠던 순간, 감동적인 순간들도.

이 모든 것들이 나중에 추억이 되고 밑거름이 되겠죠?

아. 그리고 단편적인 시각, 경험일 뿐이니 일반화의 오류는 분명히 있을 듯.

다시 한번. 새해 복 많이 받으세요. 알럽 코리아.

...

Tue, 17 Aug 2010 13:58:15 +0000

내가 자랄 때만 해도 ‘밥 남기지 마라. 중국아이들은 굶고 있어’라는
어머니의 말씀을 들었지만,
나는 지금 딸아이에게 이렇게 말한다.
‘더 열심히 공부해라. 중국과 인도 아이들이 네 직업을 넘보고 있어.’

토머스 프리드먼

커스텀 싱글쉐이더와 겜브리오 스텐다드 쉐이더의 차이

Sun, 15 Aug 2010 22:46:27 +0000

부왘ㅋ

게임에서와 사진에서의 HDR 차이

Sun, 15 Aug 2010 22:27:14 +0000

출처 : 김학규님 레임프루프
http://www.lameproof.com/


많은 사람들은 HDR이라는 단어를 정확히 두가지 반대방향으로 사용하고 있다. 사진기에서의 HDR과 CG에서의 HDR은 서로 다른 방향을 의미한다. DR(Dynamic Range) 은 전체 빛의 영역중 일부 스크린에서 표현할 수 있는 만큼의 영역을 설정한 것을 의미하는데, 사진기의 HDR은 스크린 표현영역을 넓게 설정한 것이고, CG의 HDR은 전체 빛의 영역을 넓게 설정한 것을 말한다. [——스–크–린—————] [—–전—–체—–빛——영——–역————————————————————————-] 다르게 표현하자면 분자 (스크린상의 표현영역) 가 커지느냐 분모 (전체 빛의 영역) 가 커지느냐의 문제이기 때문에 완전히 거꾸로라고 할 수 있는데, 이것때문에 한참 혼동을 해야 했던 기억이 난다.

많은 사람들은 HDR이라는 단어를 정확히 두가지 반대방향으로 사용하고 있다. 사진기에서의 HDR과 CG에서의 HDR은 서로 다른 방향을 의미한다. DR(Dynamic Range) 은 전체 빛의 영역중 일부 스크린에서 표현할 수 있는 만큼의 영역을 설정한 것을 의미하는데, 사진기의 HDR은 스크린 표현영역을 넓게 설정한 것이고, CG의 HDR은 전체 빛의 영역을 넓게 설정한 것을 말한다. [——스–크–린—————] [—–전—–체—–빛——영——–역————————————————————————-] 다르게 표현하자면 분자 (스크린상의 표현영역) 가 커지느냐 분모 (전체 빛의 영역) 가 커지느냐의 문제이기 때문에 완전히 거꾸로라고 할 수 있는데, 이것때문에 한참 혼동을 해야 했던 기억이 난다.

===================================================================================
톤매핑의 차이뿐 아니냐고 말하는 분도 계신데… 그냥 제작하는 차원에서는 컴퓨터 그래픽에서도 아날로그 사진의 원리를 똑같이 흉내낼 수 있으니 그런 말씀을 하시는 것이겠지요. 그렇지만 이 기술을 제작한 목표나 의도는, 정반대의 방향으로 제작되었다는 말입니다. 사실 반대라는 말도 맞지는 않은 것 같지만, 사용할때 반대의 방향으로 사용하는 경우가 많긴 합니다. ㅎㅎ
정확히는 그래픽에서 아날로그 사진 원리를 흉내낸 전형적인 실사풍의 컴퓨터 그래픽스 기술이지요.

이것은 렌즈 플레어나 색수차와도 비슷한(완전히 같지는 않은…) 얘긴데, 실제 카메라 세계에서는 렌즈 플레어나 색수차를 없애기 위해 노력하지만, 게임 등의 디지털 매체에서는 있을리가 없는 렌즈 플레어나 색수차를 ‘일부러’ 만들어 넣어서 아날로그 카메라 세례를 흉내내려고 노력하기 때문이지요.

같은 목적으로 사진쪽에서는 ‘원래 더 디테일한 색이나 정보가 있지만 사진으로 찍었을때 어쩔 수 없이 날라가는 부분’ 을 살려보기 위해서 HDR 이란 이름을 사용하면서 화면에 넓은 영역을 가능한한 많은 정보를 한 화면에 집어넣으려 노력합니다. 즉 실제 보이는 것보다 더 많이 보이도록 축약해 넣는다는 거지요. 이것은 ‘보이는 영역’ 을 만들어 구겨넣은 것입니다.

카메라에서 사용하는 HDR 기술. 주로 여러 노출로 찍어 합성한다.

그치만 컴퓨터 게임에서의 그래픽 정보는 원래 ‘더 디테일한 정보’ 자체가 나오지 않는게 정상이지요. 0~255 사이로만 출력하는 8비트 체계에서는 말이죠. 그래서 이것을 16비트 체계로 만들어 ‘표현은 할 수는 없지만 있기는 있는 영역’ 을 만든 것입니다. 이게 반대라는 거죠. 사진은 원래 있는 데이터를 결과물에 구겨 넣는 거고, 게임에서는 원래 없는 데이터를 사진처럼 있게끔 만든 것이니까요.

컴퓨터 게임에서의 HDR 기술 구현. 일단 영역부터 확장하고 본다.

그렇게 만들어 놓으면 게임에서는 사진에서 사용하는 방식의 흉내를 톤커브를 통해 낼 수가 있게 됩니다. 하지만 많은 기술이 그렇듯, 아날로그에서는 ‘없애려고 하는’ 기술을 굳이 ‘만드려고’ 하는게 게임의 그래픽이니. 사진에서의 HDR 기술은 흉내내지 않고 사진이 가지고 있던 원래의 약점인 ‘데이터가 날아간다’ 라는 느낌을 흉내내는 것입니다 :)

웰시 코기의 놀라운 점프력

Sat, 14 Aug 2010 14:18:30 +0000

아놔 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ잠시 눈물좀 닦고..

Plants vs Zombies 제작과정

Wed, 11 Aug 2010 11:46:01 +0000

식물 대 좀비의 제작과정 ( Alan Smithee 번역)

번역문은 여기서 볼 수 있습니다.

https://docs.google.com/View?id=d238vr2_459gsgkqjch

역시, 성공하는 게임의 공식은 늘 같습니다. 그래픽에 신경쓰지 않는 재빠른 프로토타입, 프로토타입 제작 후 게임의 재미를 위한 그래픽 방향 결정과 수많은 테스팅, 그리고 만드는 과정에서의 재미. 제가 중요하게 생각하는 것 순서대로 절묘하게 씌여져 있군요.

개인적으로 게임의 재미를 결정하기 전에 그래픽을 잡는건 반대하는 편입니다. 그래픽은 게임을 위해 준비해야지, 그래픽을 위해 게임이 따라가는 프로젝트들 중 제대로 인정받은 프로젝트를 본 적이 없거든요.

이 더운날에

Tue, 10 Aug 2010 19:03:06 +0000

누가 귀마개를 길가에 떨어뜨리고 갔을까

버텍스 칼라를 이용한 라이트맵 베이킹

Sun, 08 Aug 2010 19:47:37 +0000

멘토링 교육과정 학생이 질문해서 뚝딱 30분만에 만든 초 허접 튜터리얼.
겜브리오에서 버텍스 라이트 베이킹 하기.

게임조작에서의 인지측면에서의 게임인터페이스 규칙

Sun, 08 Aug 2010 13:28:28 +0000

밝힐 수 없는 문서 또 하나 제작중입니다 … 인터페이스와 조작성에 대한 얘기.
이런거를 결정할 수 있는 위치에 있는건 맞긴 한데 그렇다고 강압적으로 결정해 버리면 곤란하고, 최대한 직원들을 이해시키고 설득하면서 접근해 나가야 겠지요 (하지만 어차피 인터페이스의 절반은 감각이라고 여전히 믿고 있기 때문에, 아니다 생각하면 밀어붙일 각오도 …)

정보량이 많기로 소문난 우리 게임에서는 꼭 짚고 넘어가야 할 문제라서 말입니다.

판다!!!

Sun, 08 Aug 2010 12:01:09 +0000

아 이런박명수 같은 성격 너무 좋아 크허헣허헣허헣
…근데 회사에서 내가 하는 짓하고 되게 비슷하잖아….

A : 이거좀 먹어 볼래?
B : 아니 됐어
Panda : …..

A: 우리 치즈 주문은 안 했었잖아..

B: 네 반품할게요..

PANDA:…………..

B: 아니 사장님이 …

PANDA : ………………..

아들 : 아빠 이거 사자

아빠 : 모르는 브랜드인데 다른거 집어

PANDA:…………

A: 식사 왔습니다.

B: 아 난 됐어..

PANDA: ………………

대충 살아가는 게임개발자

테스트 3번

테스트 2

배경씬 제작 과제 _ 300팀

Flow shader 신버전 제작

예제파일

유니티 물 쉐이더 강의용 예제

사수가 하나도 없는 상황이 되었어요 ㅠ 어째야 하지요?

CCRC 좋다

성공한 사람의 인생은 성공한 후에 포장되어 평범한 사람을 망친다.

유니티 툰 쉐이더 강의용 예제들

캐릭터그림자 제어

고전 액정 게임을 해보자

타블렛으로 3D max 모델링 작업시에, 회전이 뚝뚝 끊어지는 문제 해결법

게임 중독법 반대 서명 운동

오늘의 C# 공부 :server / client

오늘의 C# 공부 : winform

오늘의 C# 공부 : WinForm

오늘의 C# 공부 : 인터럽트 , 싱크로 나이즈

오늘의 C#공부 : 직렬화, 스레드/ 테스크

오늘의 C# 공부 : 파일 다루기, 스트림.

오늘의 C# 공부 : 애트리뷰트, 다이나믹.

오늘의 C# 공부 : LinQ

오늘의 C# 공부 : 이벤트 /람다식

오늘의 C# 공부 : 델리게이트

오늘의 C# 공부 : 예외처리 (try ~ catch, finally)

오늘의 C# 공부 : stack, 일반화, 예외처리들

오늘의 C# 공부 : Indexer, Generic

c# 오늘의 공부 : 배열, 어레이.

오늘의 C# 공부 :

오늘의 C# 공부 : 구조체, 인터페이스, 추상 클래스, 프로퍼티

오늘의 C# 공부 : 계속 클래스 공부

오늘의 C# 공부

오늘의 C# 공부. 테스트 문제 , 클래스

오늘의 C# 공부 : 매개변수

오늘의 C# 공부

Test 10번 문제

오늘의 C# 공부

제작중. 9번문제.

문제 7번

문제 5번 6번

문제 3번

게임업계의 장래가 너무 어두운 것 같아요. 취업해도 될까요?

오늘의 C# 공부

오늘의 C# 공부

오늘의 C# 공부

오늘의 C# 공부하기

C# 공부하기

namespace ConsoleApplication1 { class HelloWorld { static void Main(string[] args) { Console.WriteLine(“Hello,World!”); Console.WriteLine(“Helle,{0}!”, args[0]); } } }

Console.WriteLine(a);//a 를 출력한다. } } } // 오버플로우. 값은 0이 나오게 된다.

//부동 소수점의 정밀도

double b = 3.14159265358979323846; Console.WriteLine(b); // double 은 전부 다 표시해 준다. } } }

Console.WriteLine(a); Console.WriteLine(b); } } }

Console.WriteLine(a); Console.WriteLine(b); Console.WriteLine(c); Console.WriteLine(d); } } }

오늘의 shader 공부

ShaderFX를 이용한, 그래픽 디자이너를 위한 기초 쉐이더 강좌 10강

아이노트 블루투스 헤드셋 BT-555 리뷰

PDB-MD 슬라이드 멀티독 리뷰

포은아트홀 '레미제라블' 보고 왔슴다.

지난번 제주도 여행

photoshop eclipse tour 2012

[KGC2012]Multi Platform Full 3D MMORPG 만들기- "삼국지를 품다"의 테크니컬 아트

삼국지를 품다 출사표 영상

인재 채용

"TEXCOORD" has too big of a numeric index (8) 에러

스승님의 테스트 코드 2

테스트 코드 / 스승님

surface shader 컴파일 파라미터

fragment shader Texture 추가

fragment shader 기본형

명일역 항아리 닭강정

유니티 4.0이 발표되었습니다.

게임테크 2012 강연료 기부 인증

ShaderFX를 이용한, 그래픽 디자이너를 위한 기초 쉐이더 강좌 9강

Phong 셰이더보다 싼 유사 Blinn-Phong 셰이딩 모델

뷰 벡터 / 카메라 벡터 구하는 식

이벤트 2부 : 이태원 여행

마눌님을 위한 이벤트 1부 : 시네 드 셰프

듀얼 라이트맵에 대한 연구

아치바 이동형 모니터 M9

namespace ConsoleApplication1
{
class HelloWorld
{
static void Main(string[] args)
{
Console.WriteLine(“Hello,World!”);
Console.WriteLine(“Helle,{0}!”, args[0]);
}
}
}

Console.WriteLine(a);//a 를 출력한다.
}
}
} // 오버플로우. 값은 0이 나오게 된다.

double b = 3.14159265358979323846;
Console.WriteLine(b); // double 은 전부 다 표시해 준다.
}
}
}

Console.WriteLine(a);
Console.WriteLine(b);
}
}
}

Console.WriteLine(a);
Console.WriteLine(b);
Console.WriteLine(c);
Console.WriteLine(d);
}
}
}