Очень странное решение с двухпроходным рендером и стенсилом. Т.е. у них на каждое пятно очистка стенсила, отрисовка пятна только в стенсил и отрисовка квада с чтением стенсила и все ради того, чтобы пятно не "самопересекалось". У них на 300 пятен будет 900 вызовов отрисовки, из которых 300 — полная очистка стенсила и никакой физической возможности это забатчить. Выглядит мега-криворуко.
Сейчас думаю, как это можно было бы сделать красивее, пока мысль в том, чтобы при отрисовке писать в ZBuffer и использовать ZTest NotEqual. В этом случае плоское пятно не будет пересекать само себя. Конечно, придется следить за порядком отрисовки (и есть подозрение, что сделать батчинг все равно не получится). Надо проверять.
Вообще, надеюсь, тут найдется кто-то еще, кто предложит еще парочку вариантов, более адекватных, чем предложенный в статье.
Путаете причину и следствие.
Gta5/Witcher3 делала огромная команда высококлассных специалистов.
А Unity3d/Ue снижают порог входа, соответственно, проекты могут делать и куда менее серьезные ребята. И качество таких проектов, очевидно, ниже.
Полагаю, разработчики gta и из юнити вытянули бы очень приличную картинку и fps.
Как плюсовый разработчик, который сейчас перешёл на юнити, открытым текстом: 95% проблем с Юнити — кривость рук разработчиков.
Думаю, история как с js — он так снизил порог входа, что стало появляться много некачественных продуктов. Однако это не означает, что профессиональные разработчики будут писать на js такой же плохой код, как и все.
А чего там хитрого? Там видно же, как он сделал.
Для каждого соединения:
Взять две соединенные комнаты
Получить дельту позиций комнат и выбрать максимальный по модулую компонент (x или y).
Так мы понимаем, горизонтальный или вертикальный коридор и с какой стороны
Получить минимальную и максимальную позицию коридора (для y:
minY = Max(firstRoom.y, secondRoom.y)
maxY = Min(firstRoom.y + firstRoom.height, secondRoom.y + secondRoom.height)
Min и Max не перепутаны)
Если min > max, тоннель нужно "сломать" посередине
Выбрать позицию из указанного интервала: tunnelY = Random.Range(minY, maxY — tunnelHeight)
Нарисовать тоннель
Если проще: понять, горизонтальный или вертикальный коридор нужно нарисовать и нарисовать его, не выходя за границы комнат.
У Дробышевского в лекциях про это хорошо написано/сказано. Если ты охотишься на рыбу — все, что тебе нужно, быть умнее рыбы.
Собственно, он противопроставляет хищникам всеядных — им сложнее, т.к еда каждый раз разная, её нужно по разному добывать и из-за разнообразия возможностей развитый разум становится эволюционным приемуществом. У хищникам разум тоже может быть полезен, но им нужно, как я уже говорил, всего лишь быть умнее жертвы.
Плюс в океане затруднена орудийная деятельность. Это можно обойти, но не ради рыбы же :)
Добрый день!
Ответ получится развернутым, вы уж извините :)
Про проект. В какой-то момент времени я понял, что нарушил основную идею этого проекта — написать быстро и выложить в стор. Потому что копаюсь с эффектами и долго делаю кодом то, что художник мог бы сделать за минуты. При этом на работе во время хакатонов у меня есть прекрасная команда из меня+художника+геймдизайнера, и вместе мы успеваем за два дня сделать куда более глубокое и красивое произведение. Поэтому я пока отложил эту разработку и хочу вернуться к ней небольшой командой. Так логичнее и быстрее.
Саморазвитие. Эти статьи и проекты — мой способ учиться. Я научился делать эффекты, классно работать с графикой, писать тексты, наконец. Сейчас я применяю эти знания на работе и учусь новому. Пока что фокус интереса смещен в сторону столярного дела — а статьи об этом я не пишу. Думаю, когда вернусь к эффектам — продолжу писать.
Хабр. К сожалению, я потерял веру в хабр. Для меня хабр — это не только способ прочесть крутые статьи про it-тематику. Это способ вступить в диалог профессионалами, которые могут задать вопросы, подсказать другие решения, оценить работу с точки зрения своего опыта. К сожалению, мои статьи не получают такого отклика. Я не знаю причину, но, за редким исключением, в комментариях не появилась ни одна полемика о графике, решениях, которые я применял, оптимизациях и т.д.
Для меня было важно не только дать — поделиться контентом, но и получить — фидбек, мнения, обсуждения. Но хабр мне этого не даёт. :)
Возможно, я попробую повторить этот опыт на другой платформе, может, англоязычной. Но пока что я не знаю где это можно сделать.
Закончу на позитивной ноте. Я не бросил своего увлечения и продолжаю делать что-то интересное их программных эффектов. Правда сейчас это редко становится достоянием общественности и обычно ограничивается рамками внутренних хакатонов.
Да, согласен, что полупрозрачные объекты будут оставлять полутени, которые при наложении дадут более густую тень. Просто сейчас на скринах такие тени отбрасывают непрозрачные объекты, например, деревья. Насколько я вижу, у вас два типа объектов, условно-прозрачные вещи, которые отбрасывают легкую тень и непрозрачные объекты — деревья. Просто сейчас из-за особенностей реализации вы не можете сделать равномерное затенение от непрозрачных объектов, которое бы не выглядело бы странно.
Знаете, на gpu можно делать очень ламповый пиксель :)
Ух ты, на мою статью ссылаются! Спасибо!
А вообще есть пара мыслей.
На скринах видно, что тени накладываются друг на друга и зоны пересечения теней становятся темнее. Это некорректное поведение, т.к источник света только один и точечный. Можно исправить, если рисовать тени в буфер одним цветом, а полупрозрачность теней делать уже после — отрисовывая этот буфер целиком с какой-то прозрачностью.
Мне кажется, что можно не рисовать рисовать дугу в начале тени — так станет проще и не будет видно резких углов, как на последнем скрине. Эта дуга сейчас необходима, иначе тень будет закрывать сам объект частично. Если не менять подход к отрисовке, но хочется убрать эти кружки, возникнет проблема.
Придется отрисовывать объект их тень от самых дальних к игроку до самых ближних. При этом тени объектов будут рисоваться в таком порядке: объект1, тень1, объект2, тень2 и т.д. И тогда нельзя будет поправить наложение теней, про которое я говорил выше. Собственно, стандартная пробема с алгоритмом художника.
Мой совет — попробовать рисовать все на видеокарте. Не знаю, насколько сложно это делать на современном Delphi, возможно есть нужные библиотеки.
Если проект делается ради фана и опыта, можно попробовать переделать его на движок, более удобный для работы с 2d/3d, да тот же Unity3d мой любимый.
Просто все эти вкусные вещи с тенями, освещением и т.д. делаются в разы проще, если можно оперировать ими как 3д/2д объектами на видеокарте, с буфферами, шейдерами, стенсилом и т.д.
Я правильно понимаю, что изначально меш с небольшим количеством треугольников, а когда пользователь начинает рисовать, вы тесселируете их?
После того, как игрок закрасил бОльшую часть фигуры, объединяете треугольники с одним цветом?
И еще, судя по гифке, размеры треугольников очень маленькие, по сравнению с размером самой фигуры. Не тормозит? Я пробовал сделать тесселяцию на лету, у меня лагало)
Ну, обычно фио с посыки и города (плюс знания, что человек с хабра и из it скорее всего) хватает, чтобы нагуглить и через несколько запросов выйти на аккаунт. Думаю, многие так внуков гуглили, чтобы понять, что им дарить :)
Наконец-то новогодние праздники закончились и появилось время написать. :)
Огромное спасибо моему дедушке oWart, который приготовил чудесный подарок:
Интересная книга, игорные фишки из Лас-Вегаса (из тех самых казино, которые грабил Оушен!), удобный мультитул (уже помог), уточка для знаменитого метода утёнка, снеговичка, который теперь гордо стоит на рабочем месте, и…
офигенные nucleo mb1136 и NodeMCU Amica! Пока что не придумал, как именно их применить, но дедушка прямо как знал, что я люблю возится со всякой классной электроникой!
P.s. Ну и конечно, в подарке были классные конфеты, но они уже использованы с превеликим удовольствием ;)
Надеюсь, и мой внучек будет доволен, судя по трекингу, он сегодня утром забрал посылку :)
Просто фидбека стало мало. Хочется каких-нибудь обсуждений в комментах, критики и т.д. А хабр стал сильно добрее в комментариях к техническим статьям. :(
А каким образом после построения графа остаются несвязанные waypoints? На изображении видно несколько отдельных зелёных точек, от которых есть прямая видимость до ближайшего waypoint, находящегося на графе
Техническая возможность есть, конечно :)
Но тогда для консистентности нужно сделать и отражающие стены тоже со свечением пульсирующим. В общем, чаще проще убрать какие-то возможности, чем придумывать способы отображения )
Этому проекту подрезание ветвей точно пойдет на пользу.
Да, про форму пятен — вопрос отдельный. В этой статье я более-менее рассказал, как я получил бесконечный источник "материала" для пятен — мозаику из диаграмы Вороного. А вот конкретная форма пятен определяется через metaballs из точек, где исчезают осколки. Но про это я хочу подробнее в следующей части написать.
Можно, но такой шейдер будет сложнее (из-за полноценной модели освещения для пикселей, которым она не нужна).
Да, нужно избегать, но это ведь не жесткое правило: чем меньше условных переходов, тем быстрее. Просто они довольно тяжелые. Опять же, если их используют в вертексном шейдере, это приемлемо, а вот в фрагментном уже не стоит.
[Комменарий удален]
Очень странное решение с двухпроходным рендером и стенсилом. Т.е. у них на каждое пятно очистка стенсила, отрисовка пятна только в стенсил и отрисовка квада с чтением стенсила и все ради того, чтобы пятно не "самопересекалось". У них на 300 пятен будет 900 вызовов отрисовки, из которых 300 — полная очистка стенсила и никакой физической возможности это забатчить. Выглядит мега-криворуко.
Сейчас думаю, как это можно было бы сделать красивее, пока мысль в том, чтобы при отрисовке писать в ZBuffer и использовать ZTest NotEqual. В этом случае плоское пятно не будет пересекать само себя. Конечно, придется следить за порядком отрисовки (и есть подозрение, что сделать батчинг все равно не получится). Надо проверять.
Вообще, надеюсь, тут найдется кто-то еще, кто предложит еще парочку вариантов, более адекватных, чем предложенный в статье.
Путаете причину и следствие.
Gta5/Witcher3 делала огромная команда высококлассных специалистов.
А Unity3d/Ue снижают порог входа, соответственно, проекты могут делать и куда менее серьезные ребята. И качество таких проектов, очевидно, ниже.
Полагаю, разработчики gta и из юнити вытянули бы очень приличную картинку и fps.
Как плюсовый разработчик, который сейчас перешёл на юнити, открытым текстом: 95% проблем с Юнити — кривость рук разработчиков.
Думаю, история как с js — он так снизил порог входа, что стало появляться много некачественных продуктов. Однако это не означает, что профессиональные разработчики будут писать на js такой же плохой код, как и все.
А чего там хитрого? Там видно же, как он сделал.
Для каждого соединения:
Так мы понимаем, горизонтальный или вертикальный коридор и с какой стороны
minY = Max(firstRoom.y, secondRoom.y)
maxY = Min(firstRoom.y + firstRoom.height, secondRoom.y + secondRoom.height)
Min и Max не перепутаны)
Если проще: понять, горизонтальный или вертикальный коридор нужно нарисовать и нарисовать его, не выходя за границы комнат.
У Дробышевского в лекциях про это хорошо написано/сказано. Если ты охотишься на рыбу — все, что тебе нужно, быть умнее рыбы.
Собственно, он противопроставляет хищникам всеядных — им сложнее, т.к еда каждый раз разная, её нужно по разному добывать и из-за разнообразия возможностей развитый разум становится эволюционным приемуществом. У хищникам разум тоже может быть полезен, но им нужно, как я уже говорил, всего лишь быть умнее жертвы.
Плюс в океане затруднена орудийная деятельность. Это можно обойти, но не ради рыбы же :)
Добрый день!
Ответ получится развернутым, вы уж извините :)
Про проект. В какой-то момент времени я понял, что нарушил основную идею этого проекта — написать быстро и выложить в стор. Потому что копаюсь с эффектами и долго делаю кодом то, что художник мог бы сделать за минуты. При этом на работе во время хакатонов у меня есть прекрасная команда из меня+художника+геймдизайнера, и вместе мы успеваем за два дня сделать куда более глубокое и красивое произведение. Поэтому я пока отложил эту разработку и хочу вернуться к ней небольшой командой. Так логичнее и быстрее.
Саморазвитие. Эти статьи и проекты — мой способ учиться. Я научился делать эффекты, классно работать с графикой, писать тексты, наконец. Сейчас я применяю эти знания на работе и учусь новому. Пока что фокус интереса смещен в сторону столярного дела — а статьи об этом я не пишу. Думаю, когда вернусь к эффектам — продолжу писать.
Хабр. К сожалению, я потерял веру в хабр. Для меня хабр — это не только способ прочесть крутые статьи про it-тематику. Это способ вступить в диалог профессионалами, которые могут задать вопросы, подсказать другие решения, оценить работу с точки зрения своего опыта. К сожалению, мои статьи не получают такого отклика. Я не знаю причину, но, за редким исключением, в комментариях не появилась ни одна полемика о графике, решениях, которые я применял, оптимизациях и т.д.
Для меня было важно не только дать — поделиться контентом, но и получить — фидбек, мнения, обсуждения. Но хабр мне этого не даёт. :)
Возможно, я попробую повторить этот опыт на другой платформе, может, англоязычной. Но пока что я не знаю где это можно сделать.
Закончу на позитивной ноте. Я не бросил своего увлечения и продолжаю делать что-то интересное их программных эффектов. Правда сейчас это редко становится достоянием общественности и обычно ограничивается рамками внутренних хакатонов.
Да, согласен, что полупрозрачные объекты будут оставлять полутени, которые при наложении дадут более густую тень. Просто сейчас на скринах такие тени отбрасывают непрозрачные объекты, например, деревья. Насколько я вижу, у вас два типа объектов, условно-прозрачные вещи, которые отбрасывают легкую тень и непрозрачные объекты — деревья. Просто сейчас из-за особенностей реализации вы не можете сделать равномерное затенение от непрозрачных объектов, которое бы не выглядело бы странно.
Знаете, на gpu можно делать очень ламповый пиксель :)
Ух ты, на мою статью ссылаются! Спасибо!
А вообще есть пара мыслей.
На скринах видно, что тени накладываются друг на друга и зоны пересечения теней становятся темнее. Это некорректное поведение, т.к источник света только один и точечный. Можно исправить, если рисовать тени в буфер одним цветом, а полупрозрачность теней делать уже после — отрисовывая этот буфер целиком с какой-то прозрачностью.
Мне кажется, что можно не рисовать рисовать дугу в начале тени — так станет проще и не будет видно резких углов, как на последнем скрине. Эта дуга сейчас необходима, иначе тень будет закрывать сам объект частично. Если не менять подход к отрисовке, но хочется убрать эти кружки, возникнет проблема.
Придется отрисовывать объект их тень от самых дальних к игроку до самых ближних. При этом тени объектов будут рисоваться в таком порядке: объект1, тень1, объект2, тень2 и т.д. И тогда нельзя будет поправить наложение теней, про которое я говорил выше. Собственно, стандартная пробема с алгоритмом художника.
Мой совет — попробовать рисовать все на видеокарте. Не знаю, насколько сложно это делать на современном Delphi, возможно есть нужные библиотеки.
Если проект делается ради фана и опыта, можно попробовать переделать его на движок, более удобный для работы с 2d/3d, да тот же Unity3d мой любимый.
Просто все эти вкусные вещи с тенями, освещением и т.д. делаются в разы проще, если можно оперировать ими как 3д/2д объектами на видеокарте, с буфферами, шейдерами, стенсилом и т.д.
Зависит от разряженности объектов. У них, судя по всему, из-за волн противников может оказаться очень много юнитов в одной клетке.
Я правильно понимаю, что изначально меш с небольшим количеством треугольников, а когда пользователь начинает рисовать, вы тесселируете их?
После того, как игрок закрасил бОльшую часть фигуры, объединяете треугольники с одним цветом?
И еще, судя по гифке, размеры треугольников очень маленькие, по сравнению с размером самой фигуры. Не тормозит? Я пробовал сделать тесселяцию на лету, у меня лагало)
filldens, а как Алиса отвечает на вопросы про суицид и тд? Есть какие-то обработчики, чтобы переправлять на телефоны доверия?
А как быть, если внучок подарок получил (судя по трекингу посылку забрали), но не отмечает в adm? И связаться с ним не получается. (
Ну, обычно фио с посыки и города (плюс знания, что человек с хабра и из it скорее всего) хватает, чтобы нагуглить и через несколько запросов выйти на аккаунт. Думаю, многие так внуков гуглили, чтобы понять, что им дарить :)
Наконец-то новогодние праздники закончились и появилось время написать. :)
Огромное спасибо моему дедушке oWart, который приготовил чудесный подарок:
Интересная книга, игорные фишки из Лас-Вегаса (из тех самых казино, которые грабил Оушен!), удобный мультитул (уже помог), уточка для знаменитого метода утёнка, снеговичка, который теперь гордо стоит на рабочем месте, и…
офигенные nucleo mb1136 и NodeMCU Amica! Пока что не придумал, как именно их применить, но дедушка прямо как знал, что я люблю возится со всякой классной электроникой!
P.s. Ну и конечно, в подарке были классные конфеты, но они уже использованы с превеликим удовольствием ;)
Надеюсь, и мой внучек будет доволен, судя по трекингу, он сегодня утром забрал посылку :)
Просто фидбека стало мало. Хочется каких-нибудь обсуждений в комментах, критики и т.д. А хабр стал сильно добрее в комментариях к техническим статьям. :(
С течением лавы крутой хак. Я люблю такие шейдерные эффекты, но Гаусса для маски скорости никогда не применял, мб попробую где-нибудь
А каким образом после построения графа остаются несвязанные waypoints? На изображении видно несколько отдельных зелёных точек, от которых есть прямая видимость до ближайшего waypoint, находящегося на графе
Техническая возможность есть, конечно :)
Но тогда для консистентности нужно сделать и отражающие стены тоже со свечением пульсирующим. В общем, чаще проще убрать какие-то возможности, чем придумывать способы отображения )
Этому проекту подрезание ветвей точно пойдет на пользу.
Да, про форму пятен — вопрос отдельный. В этой статье я более-менее рассказал, как я получил бесконечный источник "материала" для пятен — мозаику из диаграмы Вороного. А вот конкретная форма пятен определяется через metaballs из точек, где исчезают осколки. Но про это я хочу подробнее в следующей части написать.
Можно, но такой шейдер будет сложнее (из-за полноценной модели освещения для пикселей, которым она не нужна).
Да, нужно избегать, но это ведь не жесткое правило: чем меньше условных переходов, тем быстрее. Просто они довольно тяжелые. Опять же, если их используют в вертексном шейдере, это приемлемо, а вот в фрагментном уже не стоит.