Внимание, положительный отзыв.
Тебя очень приятно читать. Ты отлично изъясняешься. Что на самом деле тут не часто происходит. Я, конечно, не имею отношения ни к аниме, ни к варкрафту, ни к музыке, о которой здесь может пойти речь. Но твой стиль повествования - супер. Надеюсь, сообщество примет тебя тепло, со всем уважением к твоим интересам.
одинаково, но коду придаст гибкости и расширяемости
Я заапдейтил предыдущий пост. Результат оказался в три раза медленнее.
По сути эти переборы можно вообще убрать, сделать один перебор на объект. Но в этом случае функции считывания/записи станут еще уродливей, будет одно длинное такое спагетти.
UPD:
В общем. Нашел мыслю как сделать только по одному перебору за объект. Меньше никак, но там можно грамотно их расфасовать, закидывая то, что реже используется на дальние проверки. В результате будет разделенная логика в отдельных файлах, каждый из которых создается лишь один раз, что еще один плюс.
Как доделаю, накину обновление. UPD:
Залил изменения.
Теперь каждый случай обособлен в отдельный класс, благодаря чему убралось несколько свитч-кейсов
Остался перебор, отвечающий за перевод в константу. Там пусть лучше так и будет
Немного комментов
Переиначил ByteConstants в ObjectTypes
Добавил кеширование полей в классах и структурах
UPD:
чё т долговато выходит. Попробовал на реальных операциях. один объект жует несколько секунд. Думаю дело в расширении массива, в общем будем разбираться.
UPD: да, дело таки в расширении массива, без этого все летает. Надо обдумывать как сделать так, чтобы объект перерасчитывался пореже UPD:
Исправил. Теперь массив с байтами умножается на два, когда заканчивается, а уже после всего ресайзится до короткого. UPD:
Добавил параметр capacity к ByteObject, чтобы можно было предсказывать начальный размер массива. По умолчанию он равен 16, не может быть меньше 8 (хотя размер массива - может быть, так то), и автоматически изменяется при изменении массива (ну чтобы две записи подряд не нагружали шибко).
Вот такого кода хватает для хранения дерева в окне:
[MenuItem("Window/Test")]
public static void Open()
{
var w = GetWindow<TestWindow>();
w.tree = CreateTree();
}
public void OnEnable()
{
tree = treeSaver.Get<TreeView>();
}
public void OnDisable()
{
treeSaver.Set(tree);
}
public TreeView tree;
public ByteObject treeSaver = new ByteObject();
UPD: При большом количестве объектов и определенных связях сейчас переполняется стек, потому надо переписать ссылочность. Но это уже завтра.
ByteConstants не отображает суть( Это же на самом деле ObjectTypes
Я планировал туда вообще закидывать константы. Но да, по сути смысл иной, переименую. alexprey:
Расстроился из-за большого количества switch/case конструкций
Меня это тоже очень огорчает, но не придумал, чем это заменить. Думаешь вызов данных из скажем хеш таблицы будет быстрее?
Была мысль задействовать функторы в массивах, но они точно медленней. Проверил, да, хештаблицы+функторы медленнее. Мой ход мыслей таков, что это все равно относится к кишкам, в которые лезть не придется. Там все эти классы лежат в internal'e, с ними работать не нужно напрямую. Потому в принципе я так или иначе должен выбирать наоборот то решение которое быстрее, даже если быстрее свитч кейс. Хотя согласен, что перебор лучше делать реже.
За комментарии и кеширование - это временно. Пока слишком часто все переделываю
да это я понял и уже сам подзабил. Мне обидно то не за нас конкретно, а вообще за исход голосования, в котором выбрали самый "не очень" проект из всего массива.
Обычная жесть.
Вот допустим сравним первое и второе место.
Второй проект - 150 лайков внутри проекта, охотно верю что их действительно смотрели (или они сами себя полайкали, в любом случае, выглядит адекватно).
А теперь внимание, первое место - 30 лайков внутри, меньше 50 подписчиков в паблике, меньше 100 просмотров видео. Зато 450 лайков в пользовательском голосовании. То есть за них проголосовало в 9 раз (минимум) больше человек, чем тех, кому реально проект понравился.
В общем то я другого и не ждал. Но лучше бы хоть сколько-нибудь интересный проект набрал лайки. Хоть со сколько-нибудь качественной реализацией. Такой "первый" проект, без обид, можно собрать за неделю на коленке и ходить с важным лицом, потому что мой проект про "образование" (хотя по моему перекладывание фишечек исторических личностей в дырочки не есть образование, методика для детей дошкольного возраста). Мне бугуртит, честно.
С этой карточки я вообще ору: russiandevcup.ru/uploads/files/923fe05eec4c95038b436072895aea8b....
Вот мой вариант таблички:
_
VK
Facebook
XGM
Компания
Майлру
Цукерберг
ЗибадаИндастриал
Целевая аудитория
люди
люди
люди, единороги, тюлени
Форма общения
срать в комменты
срать в комменты
писать в комментарии
Наличие оранжевой кнопки отмены редактирования комментариев
нет
нет
да
Система поощрений
нет
нет
да
Наличие чата
нет
нет
да
Как вы видите, такие проекты как VK и Facebook никуда не годятся, и, что логично, проиграют нам в честной конкурентной борьбе.
Посмотрите на команду. БЛИН! Да я не могу сказать ни про одного из них, что они старше меня (а мне, между прочим, сигареты без паспорта не продают). Откуда все эти "кандидат педагогических наук", "кандидат технических наук", "опыт предпринимательства 5 лет". Я не верю.
Я шевелил кого мог. Писал в личку тем кто имеет отношение к геймдеву, объяснил почему это важно. Пробовал запостить, но личная беседа оказывается гораздо более убедительным делом.
Кстати, а что XGM не создаст свой движок типа Варкрафта, но только улучшенный? Т.е. чтобы тот движ. работал во всех направлениях..?
Кстати, так как я с головой ушел именно в разработку редакторов для Unity (во многом потому что мне хочется делать хоть что-то посложнее казуала, но на полноценные игры меня не хватит), сделать вот такой тулкит под него - прямо мечта. Это, конечно, не отдельный движок, нафигачить движок у меня кишка тонка. Но другое дело, что и это даже не так просто, как может показаться обывателю. Но кто знает, мейби на почве всякой наделанной всячины и соберу что-то приемлемое и не требующее кода.
случай из жизни
Если же брать по существу, я не осилил, например, редактор сценариев. Точнее осилил, но это все такая жопа и костыли, и при том совершенно ясно что без них там при текущей поддержке кода в Unity не обойтись, что у меня начала выносить мозг попытка это все оформить, в результате чего это дело я забросил, ибо поддерживать все это дело очень тяжело.
Тем не менее на сегодня мне под силу собрать такой тулкит качественно (по крайней мере на сегодня я знаю как делать всякие нестандартные штуки, которые только могли бы понадобиться для таких редакторов), другое дело буду ли я это делать.
Еще есть такой вопрос как распространение такого тулкита в случае написания. Ясен перец, было бы невыгодно в открытую отдать его игроделам. Это титанический труд все-таки. И это собственно основное "но" во всей этой истории.
Можно пойти по тропинке, продавая сначала все отдельно (поиск пути/инструмент для сценариев и все такое), а уже потом собрав "в сумме" вот такой тулкитик, который по цене как все эти наработки отдельно, без скидки, но уже соединенный и с игровой логикой.
Итого: затея хорошая, и скорее всего можно даже попробовать пойти по этому курсу, так как пассивный доход по мере разработки обеспечить себе можно, но так как на XGM в редакторах юньки по серьезному копошусь только я + у меня серьезный заклин по качеству кода -> вряд ли это появится скоро. Скорее v9 на горе свистнет
И то, надо учитывать что через год-полтора разработки этих редакторов я могу приоритеты поменять и начать вышивать крестиком.
Итак. Мой вариант поиска на RTS:
Между точками юзаем лучевой эвристический поиск пути. Он быстро, очень быстро находит все пути. Алгоритм дает разветвление на препятствиях. По оптимистичному сценарию, как вы помните, мы просто берем короткую "руку" и сохраняем.
Но нам нужен кратчайший путь. Мы сохраняем оба результата. Понятно, что на стадии сглаживания, создавая всего по 4 вариации (сгладить левый и правый рукав со следующим левым и правым) пути мы так или иначе найдем, какой рукав короче. Таким образом мы найдем и кратчайший путь. В результате мы получаем относительно быстрый алгоритм без необходимости запекания (немного жертвуем скоростью, но все равно опережаем астар). И это еще без оптимизаций.
Говорю про лучевой алгоритм не с потолка, это самое частое решение для RTS. И есть несколько способов сделать из него "кратчайший" поиск.
Очень хорошо вышло. Действительно полноценная игра :О
Беседа с тыквой и комментарии жуков порадовали )
Не понимаю где там найти столько секретных комнат вроде все излазил, нашел только 7. Как пройти дальше труб, кто смог?
Кстати нашел баг:
Зашел в подземелье, вышел обратно в местность. Снова зашел и игра зависла на загрузке.
линейка методов - цепочка вызовов. a.b().c() вместо c(b(a)). Это самопровозглашенное понятие от незнания, как это еще обозвать.
Сегодня я склонен полагать что нужно сделать что-то, чем можно пользоваться, и при том лучше, чем то что уже есть (нативный редактор выражений может использовать в качестве объектов только GO и вызывать только методы-инстанса, а в качестве параметров использовать только конкретные значения, без возможности указать встроенные выражения).
Затем уже, после того как будет это что-то чем можно пользоваться - наращивать по приоритетности. По крайней мере если что-то не получится - это не будет значить, что нужно начинать с самого начала.
Добавил к статье пункт Создание попапа без фокуса. Такие попапы широко могут использоваться для создания собственного оформления подсказок в редакторе или, например, для предложения вариантов автозавершения строки.
Давненько искал способ сделать так, и даже спрашивал на форумах, но в ответ лишь пожимали плечами. Совершенно случайно бегая под рефлектором нашел как это делают в юнити, найденный код портировал, чем и делюсь.
Я тут поймал себя на мысли, что если бы в школы звали людей разных специальностей, которые бы могли рассказать про свою профессию, то не было бы серьезных проблем с профориентацией и отсутствием интереса к предметам.
Господа, таки подстиг я дзен и нашел способ значительно улучшить алгоритм. На замерах кода показывает, что при тестовых условиях новый алгоритм в 20 раз быстрее, но я предполагаю, что это был субъективный замер. Однако могу заверить, что на выпуклых многоугольниках новый алгоритм - полиноминален. Кроме того, измененный код занимает всего 57 строк. Его можно было бы ужать еще больше, но там уже страдает оптимизация.
код по катом
using System.Collections.Generic;
using UnityEngine;
public static class Triangulation
{
public static List<Vector2> GetVertices(List<Vector2> points)
{
var results = new List<Vector2>();
var checkPoints = new List<Vector2>();
for (int j = points.Count - 1; j >= 0; j--)
{
var a = points[(j + points.Count - 1) % points.Count];
var b = points[j];
var c = points[(j + 1) % points.Count];
if (GetClockwiseCoef(a - b, c - b) < 0f)
checkPoints.Add(b);
}
for (int j = points.Count - 1; j >= 0; j--)
{
var a = points[(j + points.Count - 1) % points.Count];
var b = points[j];
var c = points[(j + 1) % points.Count];
if (GetClockwiseCoef(a - b, c - b) > 0f && !TriangleStrictlyAnyContains(a, b, c, checkPoints))
{
results.AddRange(new[] { a, b, c });
points.RemoveAt(j);
j = points.Count - 1;
}
}
return results;
}
private static float GetClockwiseCoef(Vector2 v1, Vector2 v2)
{ return Mathf.Sign(v1.x * v2.y - v1.y * v2.x); }
private static bool TriangleStrictlyAnyContains(Vector2 a, Vector2 b, Vector2 c, List<Vector2> points)
{
if (points.Count == 0)
return false;
var ky1 = (b.y - a.y);
var ky2 = (c.y - b.y);
var ky3 = (a.y - c.y);
var kx1 = (b.x - a.x);
var kx2 = (c.x - b.x);
var kx3 = (a.x - c.x);
for (int i = 0; i < points.Count; i++)
{
var point = points[i];
var a1 = (a.x - point.x) * ky1 - kx1 * (a.y - point.y);
var b1 = (b.x - point.x) * ky2 - kx2 * (b.y - point.y);
var c1 = (c.x - point.x) * ky3 - kx3 * (c.y - point.y);
if ((a1 < 0 && b1 < 0 && c1 < 0) || (a1 > 0 && b1 > 0 && c1 > 0))
return true;
}
return false;
}
}
Ради спортивного интереса попробовал его ужать еще сильнее, его можно описать в 39 строк, но с небольшим ущербом для производительности :)
спортивный интерес
using System.Collections.Generic;
using System.Linq;
using UnityEngine;
public static class Triangulation
{
public static List<Vector2> GetVertices(List<Vector2> points)
{
var results = new List<Vector2>();
var checkPoints = new List<Vector2>();
for (int j = points.Count - 1; j >= 0; j--)
{
var a = points[(j + points.Count - 1) % points.Count];
var b = points[j];
var c = points[(j + 1) % points.Count];
if (GetClockwiseCoef(a - b, c - b) < 0f)
checkPoints.Add(b);
}
for (int j = points.Count - 1; j >= 0; j--)
{
var a = points[(j + points.Count - 1) % points.Count];
var b = points[j];
var c = points[(j + 1) % points.Count];
if (!(GetClockwiseCoef(a - b, c - b) > 0f) || TriangleStrictlyAnyContains(a, b, c, checkPoints)) continue;
results.AddRange(new[] { a, b, c });
points.RemoveAt(j);
j = points.Count - 1;
}
return results;
}
private static float GetClockwiseCoef(Vector2 v1, Vector2 v2)
{ return Mathf.Sign(v1.x * v2.y - v1.y * v2.x); }
private static bool TriangleStrictlyAnyContains(Vector2 a, Vector2 b, Vector2 c, List<Vector2> points)
{
return (from point in points let a1 = (a.x - point.x)*(b.y - a.y) - (b.x - a.x)*(a.y - point.y) let b1 = (b.x - point.x)*(c.y - b.y) - (c.x - b.x)*(b.y - point.y) let c1 = (c.x - point.x)*(a.y - c.y) - (a.x - c.x)*(c.y - point.y) where (a1 < 0 && b1 < 0 && c1 < 0) || (a1 > 0 && b1 > 0 && c1 > 0) select a1).Any();
}
}
Я еще немного поработаю над ним, он выйдет, конечно, чуть-чуть поширше, но зато будет более удобным к использованию. Например хочется добавить автоматическое переворачивание точек многоугольника в нужный формат или возможность подать самопересекаемую фигуру.
Вообще есть мысль написать полноценную статью по многоугольникам, так как последнее время пришлось много с ними работать - кое-что напридумывал, один алгоритм даже абсолютно уникальный, из головы :) Что думаете?
Еще один вариант - удаляет избыточные точки. Производительность этого способа выше на большом многоугольнике (от 100 точек). Кстати по тесту код был в 70 раз быстрее старого способа.
using System.Collections.Generic;
using UnityEngine;
public static class Triangulation
{
public static List<Vector2> GetVertices(List<Vector2> points)
{
var results = new List<Vector2>();
var allPoints = new List<P>(points.Count);
var checkPoints = new List<P>();
for (int j = points.Count - 1; j >= 0; j--)
{
var a = points[(j + points.Count - 1) % points.Count];
var b = points[j];
var c = points[(j + 1) % points.Count];
var p = new P { x = b.x, y = b.y };
allPoints.Insert(0, p);
if (GetClockwiseCoef(a.x - b.x, a.y - b.y, c.x - b.x, c.y - b.y) < 0f)
checkPoints.Add(p);
}
for (int j = allPoints.Count - 1; j >= 0; j--)
{
var a = allPoints[(j + allPoints.Count - 1) % allPoints.Count];
var b = allPoints[j];
var c = allPoints[(j + 1) % allPoints.Count];
if (GetClockwiseCoef(a.x - b.x, a.y - b.y, c.x - b.x, c.y - b.y) > 0f && !TriangleStrictlyAnyContains(a, b, c, checkPoints))
{
results.AddRange(new[] { new Vector2(a.x, a.y), new Vector2(b.x, b.y), new Vector2(c.x, c.y) });
Remove(allPoints, j);
j = allPoints.Count - 1;
}
}
return results;
}
private static void Remove(List<P> p, int index)
{
p[index].needRemove = true;
p.RemoveAt(index);
}
private class P
{
public float x;
public float y;
public bool needRemove;
}
private static float GetClockwiseCoef(float x1, float y1, float x2, float y2)
{ return Mathf.Sign(x1 * y2 - y1 * x2); }
private static bool TriangleStrictlyAnyContains(P a, P b, P c, List<P> points)
{
if (points.Count == 0)
return false;
var ky1 = (b.y - a.y);
var ky2 = (c.y - b.y);
var ky3 = (a.y - c.y);
var kx1 = (b.x - a.x);
var kx2 = (c.x - b.x);
var kx3 = (a.x - c.x);
for (int i = 0; i < points.Count; i++)
{
var point = points[i];
if (point.needRemove)
{
points.RemoveAt(i--);
continue;
}
var a1 = (a.x - point.x) * ky1 - kx1 * (a.y - point.y);
var b1 = (b.x - point.x) * ky2 - kx2 * (b.y - point.y);
var c1 = (c.x - point.x) * ky3 - kx3 * (c.y - point.y);
if ((a1 < 0 && b1 < 0 && c1 < 0) || (a1 > 0 && b1 > 0 && c1 > 0))
return true;
}
return false;
}
}
Ну очень же просто! Это SphereOverlap и чек коллизий!
Колдуется сферка, радиус которой увеличивается. Все что попадает в радиус - подходит.
Далее берем две нормали
первая направлена от 1го юнита ко 2му.
вторая нормаль - направление атаки 1го юнита
Высчитываем между ними минимальный угол - если он меньше угла атаки - цель подходит.
не, это материал внутри текста. Он хотел именно это.
Единственное что в качестве текста в шейдере нужно указать маской сам атлас с текстом, а текстуркой что хочется
Я хочу научить новичков лучше и качественно и при том ещё экономить запас модели
Прошу простить мне мой снобизм, но по-моему ты этого сам делать не умеешь.
Для подтверждения сказанного могу продемонстрировать следующие твои работы под катом.
раскрыть
Существенно лучше пополнить раздел статей по моделлингу в геймдеве (хотя туториалов в этом интернете уже до тошноты много), а еще лучше создать справочник по модификаторам, где можно было бы поглядеть все нативные эффекты и узнать практическую применимость каждого модификатора и его свойств в каком-нибудь 3д максе. Ценность подобного материала значительно выше (хотя уверен это уже в точно таком же виде тоже где-то есть).
Ред. Devion
» Блог этого, как его? / Блог этого, как его?
Тебя очень приятно читать. Ты отлично изъясняешься. Что на самом деле тут не часто происходит. Я, конечно, не имею отношения ни к аниме, ни к варкрафту, ни к музыке, о которой здесь может пойти речь. Но твой стиль повествования - супер. Надеюсь, сообщество примет тебя тепло, со всем уважением к твоим интересам.
Ред. Devion
» Unity / Devion.Serialization
По сути эти переборы можно вообще убрать, сделать один перебор на объект. Но в этом случае функции считывания/записи станут еще уродливей, будет одно длинное такое спагетти.
UPD:
В общем. Нашел мыслю как сделать только по одному перебору за объект. Меньше никак, но там можно грамотно их расфасовать, закидывая то, что реже используется на дальние проверки. В результате будет разделенная логика в отдельных файлах, каждый из которых создается лишь один раз, что еще один плюс.
Как доделаю, накину обновление.
UPD:
Залил изменения.
- Теперь каждый случай обособлен в отдельный класс, благодаря чему убралось несколько свитч-кейсов
- Остался перебор, отвечающий за перевод в константу. Там пусть лучше так и будет
- Немного комментов
- Переиначил ByteConstants в ObjectTypes
- Добавил кеширование полей в классах и структурах
UPD:чё т долговато выходит. Попробовал на реальных операциях. один объект жует несколько секунд. Думаю дело в расширении массива, в общем будем разбираться.
UPD: да, дело таки в расширении массива, без этого все летает. Надо обдумывать как сделать так, чтобы объект перерасчитывался пореже
UPD:
Исправил. Теперь массив с байтами умножается на два, когда заканчивается, а уже после всего ресайзится до короткого.
UPD:
Добавил параметр capacity к ByteObject, чтобы можно было предсказывать начальный размер массива. По умолчанию он равен 16, не может быть меньше 8 (хотя размер массива - может быть, так то), и автоматически изменяется при изменении массива (ну чтобы две записи подряд не нагружали шибко).
Ред. Devion
» Unity / Devion.Serialization
alexprey:
Была мысль задействовать функторы в массивах, но они точно медленней.
Проверил, да, хештаблицы+функторы медленнее. Мой ход мыслей таков, что это все равно относится к кишкам, в которые лезть не придется. Там все эти классы лежат в internal'e, с ними работать не нужно напрямую. Потому в принципе я так или иначе должен выбирать наоборот то решение которое быстрее, даже если быстрее свитч кейс. Хотя согласен, что перебор лучше делать реже.
» XGM Team / XGM v9 на Russian DevCup
Ред. Devion
» XGM Team / XGM v9 на Russian DevCup
Вот допустим сравним первое и второе место.
Второй проект - 150 лайков внутри проекта, охотно верю что их действительно смотрели (или они сами себя полайкали, в любом случае, выглядит адекватно).
А теперь внимание, первое место - 30 лайков внутри, меньше 50 подписчиков в паблике, меньше 100 просмотров видео. Зато 450 лайков в пользовательском голосовании. То есть за них проголосовало в 9 раз (минимум) больше человек, чем тех, кому реально проект понравился.
В общем то я другого и не ждал. Но лучше бы хоть сколько-нибудь интересный проект набрал лайки. Хоть со сколько-нибудь качественной реализацией. Такой "первый" проект, без обид, можно собрать за неделю на коленке и ходить с важным лицом, потому что мой проект про "образование" (хотя по моему перекладывание фишечек исторических личностей в дырочки не есть образование, методика для детей дошкольного возраста). Мне бугуртит, честно.
С этой карточки я вообще ору: russiandevcup.ru/uploads/files/923fe05eec4c95038b436072895aea8b....
» Интересное от Mocherad / Хорошие новости 2
Ред. Devion
» XGM Team / XGM v9 на Russian DevCup
Ред. Devion
» XGM Team / XGM v9 на Russian DevCup
та маленькая девочкаАльберт Эйнштейн. Ибо его возраст под самым что ни на есть вопросом.» XGM Team / XGM v9 на Russian DevCup
Но
» XGM Team / XGM v9 на Russian DevCup
» XGM Team / XGM v9 на Russian DevCup
» XGM Team / XGM v9 на Russian DevCup
Ред. Devion
» Jusper's Notes / Почему я так люблю WarCraft 3 и стоит ли смотреть по сторонам?
другое дело буду ли я это делать.» Логово Снежного Волка / Работа в Paradox Interactive
Между точками юзаем лучевой эвристический поиск пути. Он быстро, очень быстро находит все пути. Алгоритм дает разветвление на препятствиях. По оптимистичному сценарию, как вы помните, мы просто берем короткую "руку" и сохраняем.
Но нам нужен кратчайший путь. Мы сохраняем оба результата. Понятно, что на стадии сглаживания, создавая всего по 4 вариации (сгладить левый и правый рукав со следующим левым и правым) пути мы так или иначе найдем, какой рукав короче. Таким образом мы найдем и кратчайший путь. В результате мы получаем относительно быстрый алгоритм без необходимости запекания (немного жертвуем скоростью, но все равно опережаем астар). И это еще без оптимизаций.
Говорю про лучевой алгоритм не с потолка, это самое частое решение для RTS. И есть несколько способов сделать из него "кратчайший" поиск.
Ред. Devion
» Двери, которые лучше не открывать / Двери: демо-уровень
Беседа с тыквой и комментарии жуков порадовали )
Не понимаю где там найти столько секретных комнат вроде все излазил, нашел только 7. Как пройти дальше труб, кто смог?
Зашел в подземелье, вышел обратно в местность. Снова зашел и игра зависла на загрузке.
Ред. Devion
» Unity - Triggers Editor / Пятая попытка
Затем уже, после того как будет это что-то чем можно пользоваться - наращивать по приоритетности. По крайней мере если что-то не получится - это не будет значить, что нужно начинать с самого начала.
Ред. Devion
» Unity / Как вызывать меню и попапы в Unity
Давненько искал способ сделать так, и даже спрашивал на форумах, но в ответ лишь пожимали плечами. Совершенно случайно бегая под рефлектором нашел как это делают в юнити, найденный код портировал, чем и делюсь.
» Самый важный блог / Школьная мясорубка скачать бесплатно
Ред. Devion
» Unity / Триангуляция
Вообще есть мысль написать полноценную статью по многоугольникам, так как последнее время пришлось много с ними работать - кое-что напридумывал, один алгоритм даже абсолютно уникальный, из головы :) Что думаете?
Ред. Devion
» Unity / Конус в поле атаки
Колдуется сферка, радиус которой увеличивается. Все что попадает в радиус - подходит.
Далее берем две нормали
- первая направлена от 1го юнита ко 2му.
- вторая нормаль - направление атаки 1го юнита
Высчитываем между ними минимальный угол - если он меньше угла атаки - цель подходит.» XGM Team / XGM Team - Мы работаем для вас!
Я тоже под яндексом сижу.
Ред. Devion
» Unity / Unity5 question. Image in text.
Единственное что в качестве текста в шейдере нужно указать маской сам атлас с текстом, а текстуркой что хочется
Ред. Devion
» Unity / Unity5 question. Image in text.
Это ответ
» Мастерская Психа / Статьи. Нужно ли это ?
Для подтверждения сказанного могу продемонстрировать следующие твои работы под катом.
Ред. Devion
» Hanabishi's Blog / Управление громкостью на колесо мыши