Всем привет, меня зовут TaHk и по ночам я программирую на c++.
Недавно я столкнулся с задачей (не столько про c++, сколько математической), решение которой показалось мне красивым, и я хочу им поделиться.
Я не занимаюсь профессионально ни математикой, ни программированием (ABAP не считается), поэтому написанное ниже может показаться специалистам довольно банальным и очевидным, но я не исключаю, что кому-то из начинающих разработчиков приведенные в посте решения могут пригодиться.
Итак. Задача -- нарисовать в 3d поверхность, которая задана не набором полигонов, а формулой.
Алгоритм был выбран следующий:
0. Исходные данные.
*Координаты нулевой точки поверхности (точка в глобальной системе координат, являющаяся центром координат для формулы, которой задана поверхность);
*Вектор нормали поверхности в нулевой точке (показывает, как наклонена поверхность относительно глобальных координат);
*Размеры поверхности по x, y и z (чтобы она просчитывалась не по бесконечность во все стороны, а в рамках определенного объема);
*Координаты "глаза";
*Вектор направления взгляда;
*Вектор, показывающий, где у "глаза" верх;
1. Формируем лучи из каждого пикселя экрана и проверяем на пересечение с поверхностью.
2. Если луч не пересекается с поверхностью -- окрашиваем пиксель в черный.
3. Если пересекается -- определяем освещенность точки. Для этого определяем нормаль к поверхности плоскости, и чем меньше угол между нормалью и лучом из камеры -- тем ярче точка.
Давайте разбираться с каждой задачей в отдельности.
1. Лучи из каждого пикселя экрана.
Ну, тут все просто. Чтобы задать луч -- нужна точка и вектор. Точка у нас есть -- это координаты "глаза". И направление взгляда есть. Соответственно, луч для координат [0,0] у нас уже есть. Что же делать с остальными координатами? Ответ на этот вопрос даст (или нет) эта картинка:
Для начала, нам нужны единичные векторы dx и dy, перпендикулярные друг другу и вектору взгляда, чтобы построить на них плоскую систему координат, которая будет для нас экраном. Вектор dy у нас уже есть («Вектор, показывающий, где у "глаза" верх» в исходных данных). Что же на счет dx? А тут приходит на помощь векторная алгебра, из которой мы помним (или нет), что результатом векторного произведения двух векторов является вектор, перпендикулярный векторам-множителям, с нормой равной площади параллелограмма, построенного на этих векторах. Соответственно, если исходные векторы перпендикулярны друг другу и оба с длиной равной единице – длина результата тоже будет равен единице. А это прекрасно, ведь нам нужен именно единичный вектор.
Таким образом,
dX[0] = tv[1]*dY[2] - tv[2]*dY[1];
dX[1] = tv[2]*dY[0] - tv[0]*dY[2];
dX[2] = tv[0]*dY[1] - tv[1]*dY[0];
где tv — вектор направления взгляда, а dY вектор, показывающий где у взгляда верх.
Дальше, было бы неплохо определиться с длиной векторов dx и dy, определив таким образом размер экрана (по сути, это управление углом обзора). Мне оптимальным показался вариант, когда у экрана размер равен единице
dX[0] /= max_x;
dX[1] /= max_x;
dX[2] /= max_x;
dY[0] /= max_x;
dY[1] /= max_x;
dY[2] /= max_x;
Где max_x – разрешение экрана по x. Да, dy тоже делится на max_x, чтобы длина вектора dx была равна вектору dy, так как иначе изображение будет растянуто по одной из осей.
Итак, у нас есть:
dX, dY – векторы, определяющие плоскость экрана.
dZ – вектор направления взгляда.
for (int y = 0; y <= max_y; ++y) {
for (int x = 0; x <= max_x; ++x) {
tv[0] = dZ[0]+x*dX[0]+y*dY[0];
tv[1] = dZ[1]+x*dX[1]+y*dY[1];
tv[2] = dZ[2]+x*dX[2]+y*dY[2];
// tv – вектор, показывающий направление луча из точки [x,y] экрана
// ...
};
};
В рамках этого цикла мы и будем работать дальше.
2. Пересечение луча с поверхностью.
Обычно лучший способ найти в пространстве точку пересечения луча с поверхностью, которая задана формулой – это решить систему уравнений, состоящую из уравнения плоскости и уравнения луча. Но если в уравнение плоскости проникает тригонометрия – решений становится бесконечное множество (буквально бесконечное, вида x = 0 ± 2πn, где n∈R ), и что делать программно с этой бесконечностью – не ясно. Поэтому мы будем искать точку пересечения итеративно:
1. Определяем параллелепипед, ограничивающий нашу поверхность (мы помним, что по условиям ограничили ее в размерах).
2. Ищем точки пересечения луча и параллелепипеда. Получаем 2 точки – «вход» и «выход» в пределы параллелепипеда.
3. В точке «входа» переводим координаты из глобальной системы координат в локальную для параллелепипеда.
4. В локальных x и у находим по формуле поверхности координату z. Если найденная координата z больше, чем у точки «входа», фиксируем, что мы «под» поверхностью. Иначе – фиксируем, что мы «над» поверхностью.
5. От точки «входа» до «выхода» проверяем аналогичным образом все точки на луче с заданным шагом. Как только на следующем шаге состояние отличается от того, что было на предыдущем – значит, нашли точку пересечения.
6. Если до точки «выхода» состояние не менялось – значит пересечения не было.
Теперь по пунктам.
Существует простой и понятный алгоритм быстрого поиска пересечения прямоугольника с лучом на плоскости. Для его понимания нужно ввести пару терминов:
Точка входа – точка пересечения луча с прямой, в случае если нормаль этой прямой направлена навстречу лучу.
Точка выхода – точка пересечения луча с прямой, в случае если нормаль этой прямой направлена навстречу лучу.
Алгоритм такой:
Проверяем каждую прямую на пересечение с лучом и определяем для каждой точку входа или выхода. Если самая дальняя из найденных точек входа ближе, чем самая ближняя из найденных точек выхода, то это значит, что луч пересекает прямоугольник в этих точках. Если самая дальняя из найденных точек входа дальше, чем самая ближняя из найденных точек выхода, то это значит, что луч не пересекает прямоугольник.
К чему это я? А вот к чему. Этот подход отлично работает и в пространстве, если заменить 4 прямые на 6 плоскостей.
Как мы помним, поверхность задана точкой и нормалью и ограничена в размерах по x, y и z. Причем эти x y и z – в локальных координатах. То есть наш параллелепипед, ограничивающий поверхность, должен уметь вращаться вместе с поверхностью.
Поэтому для начала определим эти плоскости с учетом поворота параллелепипеда с поверхностью. Для этого нам понадобятся 3 вектора:
ddX[3] = {0,0,0}; // единичный вектор, который направлен вдоль оси X нашей поверхности
ddY[3] = {0,0,0}; // единичный вектор, который направлен вдоль оси Y нашей поверхности
ddZ[3] = {0,0,0}; // единичный вектор, который направлен вдоль оси Z нашей поверхности
с ddZ все понятно – это нормаль к поверхности.
С ddX и ddY сложнее. Одной только точкой и нормалью можно задать в пространстве только бесконечную поверхность. А тут нам нужно зафиксировать поворот этой плоскости вокруг оси z. Это можно сделать разными способами – я беру еще одну точку на плоскости и фиксирую ее координаты в глобальной системе координат. Допустим, это точка point2, а нулевая точка поверхности — point. Тогда
ddX[0] = point2[0] - point[0];
ddX[1] = point2[1] - point[1];
ddX[2] = point2[2] - point[2];
len = sqrt(ddX[0]*ddX[0]+ddX[1]*ddX[1]+ddX[2] *ddX[2]) ;
ddX[0]/=len;
ddX[1]/=len;
ddX[2]/=len;
Как мы видим, я не забыл, что нам нужен именно единичный вектор (с длиной равной единице), поэтому я посчитал длину вектора от точки point к точке point2 и разделил каждую координату на длину. Эта процедура называется нормализация вектора – приведение его к единичной длине с сохранением направления.
Ну и ddY по старой схеме (как в пункте 1, где мы экран рисовали) определяем как векторное произведение ddX на ddZ:
ddY[0] = ddX[1]*ddZ[2] - ddX[2]*ddZ[1];
ddY[1] = ddX[2]*ddZ[0] - ddX[0]*ddZ[2];
ddY[2] = ddX[0]*ddZ[1] - ddX[1]*ddZ[0];
Таким образом, мы можем задать все 6 плоскостей. Например, плоскость, ограничивающая параллелепипед «снизу» определяется так:
spoint[0] = point[0] - z * ddZ[0];
spoint[1] = point[1] - z * ddZ[1];
spoint[2] = point[2] - z * ddZ[2];
n[0] = -ddZ[0];
n[1] = -ddZ[1];
n[2] = -ddZ[2];
где point — нулевая точка нашей поверхности, а z - половина высоты параллелепипеда.
Остальные – по аналогии, меняем только - на + и буквы координат.
Дальше нужно в общем виде понимать, как мы будем искать точки пересечения луча и плоскости. Допустим, плоскость задана точкой point[3] и нормалью n[3]. Луч задан точкой tp[3] и вектором tv[3]. Еще одна картинка в стиле «я у мамы paint master»:
Несложно догадаться, что если векторы n и tv имеют единичную длину, то расстояние от точки tp до точки пересечения с плоскостью будет равно -h/p. Шучу, сложно догадаться. Но при желании вы можете это проверить. Даже так – если вы сейчас в школе проходите векторную алгебру – вы должны это проверить и выложить в комментариях доказательство. Иначе вам поставят двойку. Или что там сейчас ставят в школах…
Как же найти эти h и p? Тут на помощь снова приходят определения из векторной алгебры. Скалярное произведение векторов численно равно длине проекции одного из этих векторов на другой. Как определить скалярное произведение? А примерно так:
float MulVecSc(float *Vec1, float *Vec2){
return Vec1[0]*Vec2[0] + Vec1[1]*Vec2[1] + Vec1[2]*Vec2[2];
};
Как мы видим из рисунка, h – это проекция на нормаль вектора от точки tp до точки point, принадлежащей плоскости, а p – это проекция на нормаль вектора tv.
vp[0] = point[0] - tp[0];
vp[1] = point[1] - tp[1];
vp[2] = point[2] - tp[2];
p = MulVecSc(n,tv);
h = MulVecSc(n,vp);
t = - h/p;
Знак p покажет нам, с какой стороны плоскости мы находимся (а значит покажет, нашли мы точку «входа» или «выхода»).
Резюмируем. В пространстве точки пересечения луча с параллелепипедом находятся так:
float ddY[3] = {point2[0],point2[1],point2[2]};
float ddX[3] = {0,0,0};
float ddZ[3] = {n[0],n[1],n[2]};
tmMulVec(n,ddY,ddX);
// 6 плоскостей. Ищем самый поздний "вход" и самый ранний "выход"
// Плоскость 1
spoint[0] = point[0] + x * ddX[0];
spoint[1] = point[1] + x * ddX[1];
spoint[2] = point[2] + x * ddX[2];
vp[0] = tp[0]-spoint[0];
vp[1] = tp[1]-spoint[1];
vp[2] = tp[2]-spoint[2];
n[0] = ddX[0];
n[1] = ddX[1];
n[2] = ddX[2];
p = tmMulVecSc(lv_n,tv);
t = - tmMulVecSc(lv_n,lv_vp)/p;
if(p>0.0f){ // выход
if(t<t_out)
t_out = t;
}else{ // вход
if(t>t_in)
t_in = t;
};
// Плоскость 2
spoint[0] = point[0] - x * ddX[0];
spoint[1] = point[1] - x * ddX[1];
spoint[2] = point[2] - x * ddX[2];
vp[0] = tp[0]-spoint[0];
vp[1] = tp[1]-spoint[1];
vp[2] = tp[2]-spoint[2];
n[0] = -ddX[0];
n[1] = -ddX[1];
n[2] = -ddX[2];
p = tmMulVecSc(lv_n,tv);
t = - tmMulVecSc(lv_n,lv_vp)/p;
if(p>0.0f){ // выход
if(t<t_out)
t_out = t;
}else{ // вход
if(t>t_in)
t_in = t;
};
// Плоскость 3
// ...
// Плоскость 4
// …
// Плоскость 5
// …
// Плоскость 6
// ...
if(t_in<t_out&&t_out>0){
// есть пересечение
};
Так. Теперь мы знаем, что в промежутке от t_in до t_out мы внутри параллелепипеда.
Дальше, как и планировали, будем проверять каждую точку с неким шагом h на то, находится она выше или ниже поверхности в локальных координатах.
Что такое локальные координаты?
Это система координат, образованная теми самыми ddX, ddY, ddZ которые мы определили выше. Как очевидно из рисунка (на этот раз действительно очевидно), если у нас есть точка p, то вектор, ведущий от нулевой точки нашей поверхности до точки p будет определяться векторной суммой x*ddX+y*ddY+z*ddZ, где x y и z локальные координаты этой точки. Что ж, в таком случае, зная глобальные координаты точки p мы можем получить локальные таким образом:
vtp[0] = p[0]-point[0];
vtp[1] = p[1]-point[1];
vtp[2] = p[2]-point[2];
x = MulVecSc(ddX,vtp);
y = MulVecSc(ddY,vtp);
z = MulVecSc(ddZ,vtp);
Дальше, проверяем, находимся мы в этой точке под поверхностью или над.
F = F_xy; // тут у нас определение значения функции, описывающей плоскость. Его мы рассмотрим позже, в 3й части.
if(z<F){ // определяем, находимся мы в точке входа «над» или «под» поверхностью
in = true;
}else{
in = false;
};
Дальше – просто делаем это в цикле, перемещая точку p:
for(t = t_in+h;t<=t_out;t+=h){
pt[0] = tp[0] + tv[0]*t;
pt[1] = tp[1] + tv[1]*t;
pt[2] = tp[2] + tv[2]*t;
vtp[0] = point[0]-pt[0];
vtp[1] = point[1]-pt[1];
vtp[2] = point[2]-pt[2];
x = -tmMulVecSc(ddX,vtp);
y = -tmMulVecSc(ddY,vtp);
z = -tmMulVecSc(ddZ,vtp);
F = F_xy;
if(z<F){ // сейчас внутри
if(!in){ // были снаружи
break;
};// были снаружи
}else{ // сейчас снаружи
if(in){ //были внутри
break;
};//были внутри
}; // внутри/снаружи
}; // for t_in ... t_out
if(t>=t_out){
break; // никакого пересечения не было
};
// на данный момент t – это расстояние от точки tp до точки пересечения
// фактически точка на расстоянии t уже после пересечения с плоскостью, поэтому
// в качестве точки пересечения берем t-h
t-=h
collision_pt[0] = tp[0] + tv[0]*t;
collision_pt[1] = tp[1] + tv[1]*t;
collision_pt[2] = tp[2] + tv[2]*t;
Вот мы и нашли, где луч пересек поверхность. Запихнув это решение в цикл, который мы получили в первой части, мы получим картинку, на которой будут видны очертания поверхности. Но на 3d картинку это не будет похоже – чтобы одна точка поверхности отличалась от другой (что создаст объем) нужно определить освещенность.
3. Определение освещенности точки.
В рамках этой задачи мы не будем заморачиваться с источниками света – будем считать, что у нас один источник и он расположен непосредственно за «глазом». В таком случае расчет освещенности сводится к простому определению нормали к поверхности. Чем меньше значение проекции – тем темнее точка, так как свет падает под большим углом. Поскольку векторы у нас единичные, значение проекции будет изменяться в диапазоне [0..1], что позволяет просто домножать значение цвета на проекцию и получать нужную картинку.
Итак, вернемся к «простому определению нормали».
Пора наконец определиться с тем, какую поверхность мы рисуем. В коде ранее была конструкция F = F_x; Тут F_x это макрос, в который я подставляю формулу, которую хочу рисовать. Разумеется, в последствии в код можно будет подставить любую формулу, но для примера нужно взять что-то конкретное. Я выбрал такое:
#define F_xy cos((x*x+y*y)/20.0)/(1+(x*x+y*y)/100.0)
Чтобы понимать, что мы хотим увидеть в программе, построим этот график в каком-нибудь инструменте, который это уже умеет:
Так как же определить нормаль в какой-нибудь точке поверхности? Нормаль – это вектор перпендикулярный касательной плоскости к поверхности в заданной точке, правильно? А коэффициент угла наклона касательной к графику функции в точке – это ни что иное как производная функции в этой точке. Таким образом, нужно просто взять с обратным знаком производные исходной функции по трем координатам – это и будет вектор нормали.
Для примера возьмем двумерный график:
(графики касательных смещены для наглядности)
Функция Y=x^2. Её производная Y'=2x. Соответственно, в точке X=0.5 коэффициент угла наклона равен единице, а в точке 2 – четырем. Из графика видно, что коэффициент угла наклона с обратным знаком показывает угол наклона линии, перпендикулярной касательной. Эта же логика работает и для более сложных графиков. Так же она работает и в пространстве.
Поэтому запишем уравнение поверхности в виде cos((x*x+y*y)/20.0)/(1+(x*x+y*y)/100.0) - z = 0 и возьмем производные по трем координатам:
F'x = ((sin((x*x+y*y)/20.0)*x/10.0)*(1+(x*x+y*y)/100.0)-(x/50.0)*cos((x*x+y*y)/20.0))/((1+(x*x+y*y)/100.0)*(1+(x*x+y*y)/100.0))
F'y = ((sin((x*x+y*y)/20.0)*y/10.0)*(1+(x*x+y*y)/100.0)-(y/50.0)*cos((x*x+y*y)/20.0))/((1+(x*x+y*y)/100.0)*(1+(x*x+y*y)/100.0))
F'z = -1
Вернемся к коду. Теперь зная точку пересечения и ее локальные координаты – мы можем найти нормаль. Она будет определяться как N[3] = {-F'x,-F'y,-F'z}. Но нужно помнить, что это ее значения в локальных координатах. Чтобы перевести в глобальные – нужно каждый компонент умножить на значение вектора той оси, которой он соответствует:
#define F_x ((sin((x*x+y*y)/20.0)*x/10.0)*(1+(x*x+y*y)/100.0)-(x/50.0)*cos((x*x+y*y)/20.0))/((1+(x*x+y*y)/100.0)*(1+(x*x+y*y)/100.0))
#define F_y ((sin((x*x+y*y)/20.0)*y/10.0)*(1+(x*x+y*y)/100.0)-(y/50.0)*cos((x*x+y*y)/20.0))/((1+(x*x+y*y)/100.0)*(1+(x*x+y*y)/100.0))
#define F_z 1.0
float Fx = F_x;
float Fy = F_y;
float Fz = F_z;
collision_normal[0] = ddX[0]*Fx+ddY[0]*Fy+ddZ[0]*Fz;
collision_normal[1] = ddX[1]*Fx+ddY[1]*Fy+ddZ[1]*Fz;
collision_normal[2] = ddX[2]*Fx+ddY[2]*Fy+ddZ[2]*Fz;
Теперь мы готовы определять компоненты цвета в заданной точке. Допустим, базовый цвет поверхности у нас лежит в переменной rgb:
Shade = 255.0f * MulVecSc(collision_normal,tv);
if(Shade < 0)
Shade = -Shade;
r = Shade * rgb[0];
g = Shade * rgb[1];
b = Shade * rgb[2];
Оценим результат:
Сменим формулы:
#define F_xy 0.3*(sin(x)*cos(y/2.0)+cos(x/2.5)*sin(y/1.5))
#define F_x -0.3*(cos(x)*cos(y/2.0)-sin(x/2.5)*sin(y/1.5))
#define F_y -0.3*(-sin(x)*sin(y/2.0)+cos(x/2.5)*cos(y/1.5))
Если кого-нибудь заинтересовало – подписывайтесь. Если будет достаточно желающих – освещу другие моменты и задачи, с которыми я столкнулся в ходе разработки: преломление, рассеивание света. Картинка для затравки (на ней чуть менее чем всё, что сейчас умеет программка, в ходе реализации которой я столкнулся с описанной выше задачей):
Ооочень скептически отношусь к идее реализации своего движка в 2020 году.
Для UnrealEngine4 есть в маркете не очень дорогой плагин, дающий примерно то же самое. Плюс вся мощь UE4, а не вот эта костыльная штука.
Попробуйте тот же Monogame - только фреймворк и утилитка загрузки ресурсов, или любой другой "молоточек вместо микроскопа". После этого дружелюбная Юнити покажется раем. Если не хотелось найти конструктор, конечно.
А как размер движка коррелируется с размером проекта?
Хочешь просто - делай просто. Никто не запрещает.
Ну 10 гигов движок - это притянуто за уши, в 2020 году это не должно быть проблемой. Я тут на днях игру 60 гигов качал. А минимальная игра, собранная на UE4, весит мегабайт 150 - не идеально, но все же копейки.
Но про порог вхождения отчасти соглашусь. На UE4 надо часов 500 убить на всякие туториалы поначалу, чтобы понять работу материалов, анимации, системы экторов и все вот это. С другой стороны, оно даёт тебе за это огромную мощь, возможность сделать игру любого масштаба. Но я понимаю, как новичкам хотелось бы иметь что-то проще для начала.
Но, UE4 - open source, поддерживает плагины. Можно сделать надстройку, меняющую интерфейс и ограничивающую фичи, чтобы было легко начать пользоваться. А когда пользователю этого станет мало, он сможет переключиться на полноценный движок, и даже продолжить работать над тем же проектом. Вот это было бы реально полезно. Но я понимаю, это не так интересно разрабатывать.
Это по UE4 информации мало?!
Но я уже писал - полезнее и проще было бы сделать надстройку над существующим движком, которая бы оставляла только основную функциональность, чтобы уменьшить порог вхождения. Изобретать свой движок - значит заново реализовать сложную работу с мешами, тенями, материалами, шейдерами, там огромная работа на десятки (если не сотни) человеко-лет. Зачем это заново проходить?
Шокирующие новости, от нас это скрывали многие годы, чтобы вайти в айти, оказывается нужно учиться. Немыслимо. Никто не думал о том что такое возможно.
Потому что ты неадекватно оцениваешь характеристики разных продуктов. Отвергая огромные плюсы, несущественными минусами.
Госпадее, как можно в 2020 году вообще заикаться на счет 30гб места? Когда 256 ссд стоят баксов 50. А если мало, возьми за эти бабки терабайт hdd.
Короче хочешь ты свою шестерку починить, и стоит у тебя выбор, между батиным гаражом с 5 ключами из СССР и здоровой мастерской автосервисом с кучей мыслимого и немыслимого инвентаря и свободным доступом ко всему этому.
И ты такой "бля, ну у меня же шестерка, нахера мне там разбираться с этими подъемниками, гайковертами, домкратами гидравлическими. В яме сцепуху поменяю по простому".
И ты её поменяешь, рано или поздно. Но будешь грязный, заебанный и заречешься никогда больше заниматься этой хуйней. Не узнав при этом как просто все это можно было бы сделать.
Жопу с пальцем не путайте. Делать простенькие игрушки и войти в айти разные вещи. Согласен, чтобы получить работу в геймдеве нужно учиться и нужно учить сложные полноценные движки. Но потратить 5 минут и сделать игру на три спрайта это еще не значит войти в айти.
В каком месте я что-то отвергаю? Я говорю о том что для разных задач нужны разные инструменты. Юнити крутой инструмент, но это не значит что его обязательно использовать для решения всех задач.Представьте что вы хотите учить детей делать игры в провинции в классе информатики на железе 2010 года с мегабитной сетью на 15 машин. Или что вы живете в Зимбабве и технологический процесс до вас тупо не дошел? А проблему нехватки физических носителей памяти не слышали? Если билд тех же птиц увеличится на 10 мб, это даст нагрузку в несколько петабайт данных. Могу обобщить цитатой - "Напьются смузи, напрограммируют мышкой, а потом у них текстовые редакторы зависают".
Если мне нужно поменять резинку на дворнике, то зачем мне ехать в автосервис, оплачивать инструменты или механика, читать мануалы по шахе, по дворникам, по работе с подъемником? Мне нужно поменять один дворник, а не перебрать движок.
Если честно, я проблемы не понимаю. Юнити все также позволяет сделать на коленке что-то простое за неделю. А так учиться минимально надо всему. Разве что в дримс можно сесть и "играть", но там и кпд пиздецовый)
Ну да, ну да, пошел я нахер. Вместо минуса, можно было бы объяснить нормально в чем проблема, может вместе бы разобрались что нужно)
Результат Юнити - это и неоптимальный результат. Конечно, скажут "щас бы париться из-за ресурсоёмкости", но мне как-то кажется неправильным, моветоном что ли, закладывание в проект кучи неиспользуемых функций. Плюс Юнити сам по себе тяжелее, медленнее ворочается, и строение проекта сложнее.
Я недавно выкладывал тут пост про Godot, можете почитать мои соображения на эту тему.
з.ы. минусовал не я
Ну ресурсоемкость зависит от разраба все же. Относительно неиспользованных функций я тоже не очень понял, зачем их закладывать. Относительно строения проекта все интереснее, если писать в рамках юнити используя принциаы ооп и в целом мысля объектами, то да, все тяжко будет. Но если использовать ECS шаблон проектирования, то становится поняьно, что юнити инзачально на него расчитан был)
Закладываются эти функции, как я понимаю, в движке при компиляции проекта. А насчет объектного ориентирования - речь о том, что больше подходит для новичков - я, например, даже что такое ECS не знаю)))
Движок в первую очередь нужен как средство ренлеринга, во вторую как набор инструментов логики. Я, возможно, не до конца понимаю что вы имеете в виду под "функциями", но на этапе компиляции там ничего лишнего нет, если вы, как разработчик, это лишнее не оставили.
Относительно позиции "для новичков" все несколько сложнее. Сразу обозначу, что я по образованию преподаватель физики и информатики, поэтому говорю основываясь на педагогическом опыте. При выборе движка нам важнее целеполагание, если нам нужно что-то для прототипирование или создания минимальных концептов, то можно выбирать вообще что нравится, но предпочтительнее тут будут не движки, а редакторы (как пример тот же дримс, недавновышедший на плойку). Если же мы подразумеваем законченный продукт и обучение, пусть результат работы и остается минималистичным и "для себя", нас интересуют уже "взрослые" инструменты разработки.
Попробую объяснить точнее, даже если мы рассматриваем целью платформер с минимумом механик, нам все равно надо работать с полями данных, а для нормальной работы нужна возможность их организации. Мнение, что для маленких проектов не нужно работать над архитектурой логики проекта очень пагубно, потому что зачастую случается ситуация, когда задуманная концепция требует значительно более сложной реализации, чем казалось ранее.
Немного сумбурно вышло, но как итог я бы советовал новичкам изучать подобные вещи на простых реализациях, но с таким подходом, будто это большой проект)
Ясно, понятно. У тебя все получится.
Опять ты ядом своим в комментах брызжешь. Гражданин же понятно пишет, что никто в IT входить не собирается. Вот я в спортивный кружок хожу. Я - любитель, просто поднимаю штангу, у меня работа сидячая и размяться приятно. Я не собираюсь на соревнования, не планирую работать тренером и вообще свою жизнь со спортом связывать не планирую. Я просто поднимаю штангу, для ОФП это нормально. И если я встречусь с экспертом уровня олимпийского чемпиона, для которого мои максимальные веса - разминочные правильно ли ему начинать брызгать ядом и кричать, что так на олимпиаду не попасть! Вот посмотрите на меня - красавец, а вы все дебилы. Понятно, что ты вот такой эксперт с мировым именем, и какой-нибудь Бобби Котик на совещаниях обсуждает, что в этом месяце игру не выпускаем, там shakagami свою игру релизит, а конкурировать с ним - безумие. Но здесь любители собираются, что, с моей точки зрения, хорошо и это поддерживать надо, а не ядом брызгать.
О, мой поклонник объявился, давно тебя не было, я уже начал переживать)
Да я каждый день здесь, но спасибо за заботу. Тебе тоже не болеть. На коммент ответишь?
Боюсь ты забыл задать вопрос)
Поэтому...
Я как обычно просто понаблюдаю, как очередной человек сводит тему разговора ко мне любимому, при этом полностью зацикливаясь на этом.
Но нет...
Твой пример невалидный, так как суть тут не про "профессионал - неуч". А про "я хочу качаться, у меня есть выбор, при свободном доступе, между большим крутым тренажерным залом и маленьким полуподвалом. И с одной стороны у тебя куча людей которые готовы помочь, куча обучающих материалов, новейшие тренажеры разных видов, все удобно, красиво. А с другой задрыпанный кулер, 3 калеки в трениках, плакаты на стенах времен СССР, и по паре видов весов для гантелей и штанг. И ты такой, ммм, куда же пойти? Пойду в подвал. А почему? Потому что мне только гантели нужны, и здание там что-то большое. А банки я себе и так накачаю..."
И да...
И не стоит себя ограничивать, я верю что сможешь употребить словосочетание "брызгать ядом" больше 3 раз за коммент. Я в тебя верю.
Давай!
Давай попробуем сразу под этим комментом.
Это потому что я матом на незнакомых людей не ругаюсь, поэтому такое цензурное словосочетание заменяет разные, подчеркиваю, разные, нецензурные.
Если пример не релевантный, приведу другой. У меня есть телефон и я на него фотографирую кота. Просто фоткаю кота и даже не обрабатываю потом фотки в фотошопе, потому что кот и так прекрасен. Я не использую для этого Nikon с гитлериардом пикселей (Unity) или не использую Canon (Unreal), не планирую «войти в профессию» и всякое такое. Тупо фоткаю кота. Приходит shakagami и говорит, что кота нужно фоткать только на Nikon. И точка, всё, баста. Ничего другого не положено. Ок, по твоей наколке перехожу на Nikon, пол года разбираюсь с Апертурой, учусь настраивать баланс белого и выдержку, покупаю обвес (плагины) и фоткаю кота. Тут снова приходишь ты, ну и мы оба знаем что ты обычно делаешь в комментах и как относишься к чужому труду.
Правильно, скажу что говно, потому как если ты потратил бесценные полгода жизни на обучение, то ты должен показывать результат этого обучения.
Но!
Пример снова не верный. Яркость моей великолепной персоны снова ослепила тебя. И снова все перешло в обсуждение чудесного меня.
Мы не оцениваем в примерах результат работы основываясь на его качественных показателях. Цель будет достигнута так или иначе. Нас интересует выбор оптимального пути к этой цели, при условии равной доступности необходимого инструментария, и неотвратимой необходимости прохождения входного порога. При этом сложность вхождения на данном этапе, должна быть практически одинакова.
А учитывая что паря похоже хочет организовать кружок игропроизводства для "маленьких и тупых", выбор становится еще уже, так как нет более лучшего движка для школоло чем юнити.
О причинах этого предлагаю тебе подумать самому.
Хотя... У тебя же вся голова забита мыслями обо мне, так что давай лучше напишем еще коммент о том какой я плохой.
Простите, что влезаю в ваш диалог, но вот этот момент меня заинтересовал. Почему вы считаете, что юнити больше подходит для кружка школоло, чем годот?
Я совсем немного знаком и с ними обоими, но у меня есть на этот счет свое мнение.
1. Годот намного менее требователен к ресурсам. Это может быть очень важно как для школьного кружка с не самыми топовыми машинами, так и для самого школьника, у которого не игровой комп, а "для учебы".
Я сам нахожусь в подобной ситуации, только ноут у меня не для учебы, а для работы, но то же не самый мощный. И я по достоинству оценил легковесность годота.
2. Годот проще сам по себе, как система. Там нет никакого "центра проверки лецензии", там не нужно заводить никакой аккаунт. Просто как топор: скачал нужную версию с сайта и запустил. Дополнительные шаги нужны только для настройки билдов под разные платформы.
3. Пресловутый порог входа для годота все-таки намного ниже, чем для юнити. Намного меньший объем знаний требуется, что бы начать что-то делать собственной головой, а не повторяя действия по мануалу. Впрочем, это может быть субъективно, я открыт для дискуссии на эту тему.
А школяры они такие. Мы конечно не берем прям вообще бедненькие семьи, где еще на 4 пеньках гоняют сейчас. Но в основном они только и ноют что у них плохие машинки, а там ого-го. И даже если там "игры не идут что же делать", 5-7 летнее железо, 2д на юнити полетит там в легко.
Ну бывает, чо. Чо за ноут у тебя, пиши характеристики. 2ядра, 2гига, игровая видеокарта? И юнька прям вообще не живая? Если VS2019 идущий по стандарту напрягает, то можно легковесный VSCode поставить, возможностей которого хватает на 120%.
Ну да, гогот проще. А в чем проблема завести аккаунт? Минута делов, это же сделано для удобства. А чем тебя напрягает проверка лицензии? Выскакивающим окошком при первом логине в хаб?
Я вот сейчас не уверен, но раньше тоже можно было сделать юньку "портативной", тягать её на флешке на компы без интернета, и все вот это вот.
Порог вхождения везде примерно одинаков, дойти с нуля до "ооо у меня движется спрайтик когда я нажимаю на кнопки" довольно легко везде.
Было бы конечно по приколу вписаться в какой нить челенж "А где же проще?", где мы бы выполняли одинаковый задачи на разных движках наиболее тупым и простым способом, но блять...
Школяры, это такие существа, которым трудно что-либо делать в одиночку ради идеи, важна компания. Охват аудитории у юньки намного больше (если вбить в гугл что нить типа "сделать игру уроки", там сто процентов в монитор на со всех сторон полезен инфа о юнити), следовательно легче найти компанию таких же отбитых ребят и организовать "студию разработки видеоигр". Ну легче социализироваться короче.
Из-за огромной аудитории, у юнити просто неприличное количество обучающего материала в всех его проявлениях, книги, видео, статьи, повести дедов из того времени когда юные игроделы еще только планировались. Шутка ли, у юньки наверное на главном сайте информации больше, чем всего по Gogotу в интернетах.
Так же огромное количество различных "материалов" для разработки (бесплатных/спиженных), которые дают почувствовать себя еще круче. Так называемый "хуяк хуяк и в продакшен" развит как нигде. Что на первых порах дает почувствовать себя суперменом, что для школяров опять же важно (чем быстрее на первых порах ты видишь реальный результат, тем больше шансов что ты пойдешь дальше). Что и прославило ютини как "школодвиж" в глазах общества, что аж некоторые брезгуют его использовать.
А для более вдумчивых все эти материалы и уроки дают возможность сравнить различные подходы в разработке. Нельзя написать тот же хороший код, так ни разу его и не увидев. Там что-то подсмотрел, там что-то черпнул. Оп, что-то уже и получилось.
А по гоготу даже если авесом подборки загуглить, там уныло все что пздц, большая часть страничек на гитхабе даже не оформлены должным образом, что даже хуй проссышь что это и с чем это едят.
Так же огромный плюс, что ты учишь реальный язык программирования (а не псевдокод аля "хачу быть питоном"). По которому так же тонны инфы и различных примеров того как нужно и главное как не нужно делать.
Про производительность я писал уже выше.
1. это не движок, это среда столько весит
2. ААА раньше на с++ писали и в текстовом редакторе, что мне от языка тоже отказаться и от того же блокнота?
3. Нормально писать и на юнити, конечные файлы выходят довольно компактными.
Сто лет уже собираюсь начать что-то пилить на годоте, но как всегда "руки не доходят" (угу, а до очередного сериальчика зато доходят).
-__- кто ты?
увы но ты прав
Погуглил Ютуб. Чота все игры на этом двигле ужасны. Он вообще поддерживает например terrain? А травку? Хардваре инстансинг там есть, чтоб лесные массивы рисовать? А водичку как? Ну хотябы на уровне FarCry 1 или HL2. Хотелось бы запилить простенькую игруху типа леталки на вертолетике от 1-3 литса.
Главное чтобы на корованы набигать можно было)
Рубить? Мне кажется это всё же пилить надо назвать, а вот эти пеньки потом можно рубить.
Дерево можно и спилить, и срубить, так же как и бревно - его можно и распилить на чурки, и разрубить на них же.
Я правильно понимаю, что вам известна технология получения из растущего дерева при помощи топора вот таких ровных пеньков? Дерево на чурки (дрова: круглый короткий отрезок дерева) можно только распилить. То, что происходит в процессе анимации ну никак нельзя назвать рубить. Дерево срубить можно, но это будет цельное бревно и место сруба не будет иметь такой ровный торец, не говоря уже о том, что никто в последствии это бревно потом не рубит на части топором, его пилят.
Так же я могу сказать что испытываю отвращение к GDScript.
Все проекты, созданные на Годо, можно бесплатно реализовать, ни копейки/цента не отчисляя разработчикам движка или компании-владельцу. В этом, я считаю, большой плюс Годо. Да и монополия - это плохо)
Моё любимое) Повторюсь в очередной раз, но многие люди, будут только рады достичь того момента (той прибыли), чтобы их попросили что-то приплатить за пользование движком.
как же ты прав. Как будто заработать 100к $ (для юнитей) изи таска для нуборазрабов...
кому нужен годот, если есть анрил и юнити?
интересно, но вот этот объектный подход совсем мне не нравится, где на каждый чих надо объект создавать. Когда я этим занимался у меня игрок состоял из одного объект и никаких камер к голове не надо было болтами ему прикручивать все было внутри одного скрипта. А такие редакторы будто специально заставляют делать все по своему а не так как я хочу
Объектный подход имеет, конечно, много серьезных недостатков. Но на вашем понимании архитектурных шаблонов я бы советовал не выебываться и писать по методичке. Ну или почитайте про Ecs, там, конечно, еще более пиздецовая раздробленность всего и вся, но есть предпосылки на популяризацию подхода)
И это самый хреновый подход к разработке...
нет, можно написать скрипт на 300 строк и все будет работать а можно сделать штук пять объектов в каждом сделать свой скрипт, один перетащить туда другой соединить с третьим и еще с пятым и десятым и получится запутанное говно, вот это плохой подход точно
Это называется модульность и слабая связность. Как только вы захотите создать 20 игровых персонажей, в чём-то похожих, а в чём-то нет, затем подкрутить у всех камеру в зависимости от их внутренних параметров или что-то в этом духе, то сядете в лужу с необъектным подходом. Принцип любой автоматизации и здравого проектирования - потратить больше времени в начале, чтобы упростить себе жизнь на куда большее время в будущем.
все намного проще, мы создаем персонажа, как одно целое задаем ему параметры, в каком месте к нему крепится камера, сколько у него ног и как он прыгает, а дальше он все сам делает, если нам нужен еще один то мы изменяем параметры. Перетаскивать отдельный объект на сцену для рейкаста это дикость, точно так же как и делать отдельный ассет из трех срубленных бревен. Есть дерево, у дерева есть параметры - какое дерево и сколько бревен выпадет. Чтобы создать березу не надо делать отдельный ассет, достаточно в создать базовый объект типа дерево и сказать ему ты береза. Это намного проще и более гибко, позволяет создать любой объект данного типа и кастомизировать его. То что происходит тут это повторение того что уже сделано по несколько раз
Я вас не понимаю. По моему вполне логично, когда у вас есть несколько компонентов которые делают одно тоже просто у них отличаются параметры сделать один класс с настраиваемыми параметрами вместо того чтобы создавать две копии одного и того-же просто потому что захотелось поменять модельку или цвет.
Это верно, пока эти компоненты/объекты не отличаются (и даже теоретически в будущем не будут) поведением или структурой, а не только цветом/размером/прочей косметикой. Композиция, агрегация, наследование, шаблоны проектирования, UML-диаграммы - всё это не от скуки и отнюдь не глупыми людьми придумано.
да, они и поведением могут отличаться вас что не учили что собака делает гав а кошка мяу но они оба животное с четырьмя лапами и хвостом? Где как не в играх бывает кошка?
ты троллишь? :D ты просто перечисляешь причины ООП подхода и говоришь, что это причина делать не ООП. Как это работает? :D
я никогда не троллю, просто меня не понимают люди. вкладываешь один смысл. А они говорят что-то совсем связанное с моими мыслями и ругаются. Ты еще не видел ветку со спором о религии. Там я пытался объяснить какую роль она должна выполнять по моему мнению, а в ответ мне говорят что не попы должны воспитывать детей, а родители. Тот человек был бараном. Услышал что-то про религию и начал гнать на попов. А когда предложил ему представить что в нашей вселенной нет попов и прочитать все тоже самое он обругался и убежал :( Представляешь в каком мире я живу?
Ты явно очень плохо знаком с программированием, и говоришь откровенную чушь, не нужно так.
я очень хорошо знаком с программированием и начинал игр.
Нифига не грузит сейчас, не могу ни погуглить ничего, ни видео посмотреть, подскажите пожалуйста, под какие платформы подходит?