Комментарии 51
Православненько!
Подтверждаю. Если раньше было влом писать кучу кода по загрузке ресурсов в форматах JPG, OBJ, подключение OpenAL и прочей рутины, то теперь можно навайбкодить всю второстепенную обвязку и сосредоточиться непосредственно на разработке игры.
надеюсь такой ИИ есть, мне модель не смогла слёту без ошибок сделать експорт/импорт из блендера/в блендер(там постоянно ошибки или експорт/импорт статики, а скелет не захватывает или не пишет) костной анимации
У меня получилось написать с помощью ChatGPT скрипт на Питоне, который экспортировал скелет из Блендера + анимацию в текстовый файл. Получилось не с первого раза, но если с умом уточнить некоторые моменты, то ИИ напишет скрипт
ок то что она импортировала сеньор 3д дизайнер должен загружать в блендер, чтобы работать с моделькой исходной и с анимациями, которые прикреплены к родителю мешу по логической связи
тоесть проверкой служит хотябы фул перенос скелета с моделькой на диск/с диска в рамках блендера
(по пайплайну я делаю модельку, креплю скелет и анимирую, нужна возможность редактирования, чтобы выстраивалась последовательность из попыток у 3д дизайнера)
например клонирование родителя ради ввода кастомной анимации ну тоесть из Т позы(добавление одежды по размерам родителяс последующим мержем к анимациям либо через скрипт либо просто из нулевой точки через открывание редактирование ), но должна быть возможность открывания формата в блендере
вот типо такого, это я уже сам сделал
Скрытый текст
import bpy
ob = bpy.context.object
me = ob.data
print ("vertices",len(me.vertices))
for i in range(len(me.vertices)):
print(me.vertices[i].co.x,me.vertices[i].co.y,me.vertices[i].co.z)
print ("indices",len(me.polygons))
for i in range(len(me.polygons)):
print(me.polygons[i].vertices[0],me.polygons[i].vertices[1],me.polygons[i].vertices[2])
причем моделька делает другой код а не такой, теперь буду делать анимационный формат
В блендере разделены: меш, арматура, анимация.
В арматуре у костей есть имена, у анимаций - тоже, поэтому переносить анимации между разными скелетами возможно (вроде менять веса у меша для разных арматур тоже).
В 2021 году писал свой экспортер из блендера. Вспоминая размер контекста, который надо хранить в голове, нейронки вряд ли справятся (либо затратите х5 времени на объяснения и проверки, чем написали бы сами).
Дело не столько в объёме, сколько в понимании устройства блендера, так как получить нормали модно несколькими способами, но в первом они будут правильные, а во втором - (0; 0; 0;).
В итоге - да навайбкодить простой экспортер можно, а доводить до product-ready придётся вручную.
нормали(при условии что они настроены при моделировании в нужную сторону ) можно получить инверсной матрицей(если с математики начинать чутка можно понять как сделать) вроде после загрузки(они же нужны для света), чтобы загрузить надо меш, так что всё сходится главное меш, веса (кароче рабочий материал - чтобы запускаешь анимацию и визуально была как надо)
суть в том что когда анимация заработала(лично так делал несколько раз проследил паттерн) она войдёт в рабочий цикл(можно прикидывать что и как хочется), чтобы через свой формат уже гонять/клонировать и тп(тоесть можно и с нуля так делать полный цикл моделировать человека, потом крепить скелет), ну а можно хотябы к своей же модельке получить полную Т позу - то что в наше время дизайнер может получить Т-позу значительно прибавляет интерес(есть понимание что хоть лоу поли рабочий можно сделать) и там уже будет видно где косяки - это минимальный набор джентельмена
плюс свой формат убирает пласт ненужных библиотек и уже понимаешь что оптимизировать в модельках/ке, проще работать становится с данными
у меня через ассимп настроено, Т поза невидимая она root, далее пошли скелеты на нужные анимации (идти, бежать, танцевать и тд) так что наверно можно и так, это у fbx так через ассимп у меня
у меня вот что получилось по арматуре и вершины-индексы )
Скрытый текст
import bpy
ob = bpy.context.object
me = ob.data
#f = open("", "w")
print ("vertices",len(me.vertices))
#f.write(str("vertices ")+str(len(me.vertices)))
#f.write('\n')
for i in range(len(me.vertices)):
print(me.vertices[i].co.x,me.vertices[i].co.y,me.vertices[i].co.z)
# f.write( str(me.vertices[i].co.x)+str(' ')+str(me.vertices[i].co.y)+str(' ')+str(me.vertices[i].co.z) )
# f.write('\n')
print ("indices",len(me.polygons))
#f.write(str("indices ")+str(len(me.polygons)))
#f.write('\n')
for i in range(len(me.polygons)):
print(me.polygons[i].vertices[0],me.polygons[i].vertices[1],me.polygons[i].vertices[2])
# f.write( str(me.polygons[i].vertices[0])+str(' ')+str(me.polygons[i].vertices[1])+str(' ')+str(me.polygons[i].vertices[2]) )
# f.write('\n')
armature_obj = None
for obj in bpy.data.objects:
if obj.type == 'ARMATURE':
armature_obj = obj
break
if armature_obj:
print(len(armature_obj.data.bones))
for i in range(len(armature_obj.data.bones)):
a=' '
str1=str(i)+a+armature_obj.data.bones[i].name
# print(bpy.context.object.data.bones[i].name)
if armature_obj.data.bones[i].parent:
str1+=a+str(armature_obj.data.bones[i].parent.name)
str1+="\n"
str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[0].x)
str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[0].y)
str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[0].z)
str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[0].w)
str1+="\n"
str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[1].x)
str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[1].y)
str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[1].z)
str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[1].w)
str1+="\n"
str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[2].x)
str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[2].y)
str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[2].z)
str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[2].w)
str1+="\n"
str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[3].x)
str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[3].y)
str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[3].z)
str1+=a+str(armature_obj.data.bones[i].parent.matrix_local[3].w)
str1+="\n"
# print(bpy.context.object.data.bones[i].parent.name)
else:
str1+="\n"
str1+=a+str(armature_obj.data.bones[i].matrix_local[0].x)
str1+=a+str(armature_obj.data.bones[i].matrix_local[0].y)
str1+=a+str(armature_obj.data.bones[i].matrix_local[0].z)
str1+=a+str(armature_obj.data.bones[i].matrix_local[0].w)
str1+="\n"
str1+=a+str(armature_obj.data.bones[i].matrix_local[1].x)
str1+=a+str(armature_obj.data.bones[i].matrix_local[1].y)
str1+=a+str(armature_obj.data.bones[i].matrix_local[1].z)
str1+=a+str(armature_obj.data.bones[i].matrix_local[1].w)
str1+="\n"
str1+=a+str(armature_obj.data.bones[i].matrix_local[2].x)
str1+=a+str(armature_obj.data.bones[i].matrix_local[2].y)
str1+=a+str(armature_obj.data.bones[i].matrix_local[2].z)
str1+=a+str(armature_obj.data.bones[i].matrix_local[2].w)
str1+="\n"
str1+=a+str(armature_obj.data.bones[i].matrix_local[3].x)
str1+=a+str(armature_obj.data.bones[i].matrix_local[3].y)
str1+=a+str(armature_obj.data.bones[i].matrix_local[3].z)
str1+=a+str(armature_obj.data.bones[i].matrix_local[3].w)
str1+="\n"
print(str1)
Основная проблема с ИИ в том, что есть мнение, что он уже сейчас может написать корректно работающий код под достаточно объёмную задачу с первого раза, даже если пользователь не имеет представления как это сделать. Это заблуждение, именно знания пользователя позволяют в запросе дать чёткие критерии, чтобы он не галлюцинировал и не выходил за рамки объёма токенов.
можно навайбкодить всю второстепенную обвязку
А FPS какой будет?
Ох как же много плюсов. Что вынес для себя из опыта взаимодействия с Unreal Engine (не претендую на истину последней инстанции), и использования готовых движков в целом:
Минусы:
- Никакого контроля над тем, куда плывет этот огромный корабль - в новых релизах могут сломать то что у вас работало, добавить то что вам не надо, поменять API, лицензирование, и т.п.;
- Весомая часть навороченного функционала скорее всего будет простаивать;
- Бэкпортить нужные вам фиксы и новый функционал - отдельный тяжелый пласт работ сверху;
- Разбираться в чужой философии как использовать движок, и чужом коде;
- Скорее всего особо новых знаний вы не получите, т.к. большая часть вопросов (особенно базовых) должна закрываться существующим уже написанным функционалом;
Плюсы:
- Масштабируемые знания - в теории можно в дальнейшем работать по найму, если разобраться полностью как работает та или иная чужеродная технология и сделать ее "своей";
- Сложные вещи могут быть реализованы гораздо лучше, чем если вы будете пытаться их делать сами (особенно по части рендера).
Большой плюс таких игр без движков, это Р А З М Е Р !!! Он получается компактным!!!
не получится изза костной анимации, хотя я сужу по ассимпу, если его как-то ухитриться собрать конечно то может быть
со своим форматом получится наверно(а свой формат дотягивает до инструментария например блендер, от которого будут зависеть прогеры скрипта - хотя это проще если уже есть спецификация собственного формата, потом если есть формат свой значит уже есть визуализатор модельки, ну его можно сделать впрок отдебажить в блендере например ))
Достаточно глянуть на текстуры:
1024х1024 в формате ETC2_RGB займёт 0.5 МБ, плюс простейший MIP = 0.68МБ, условно 0.7 МБ. Brotli / z сожмет до 0.2-0.5 (а зависимости от данных).
В одном материале: цвет, нормаль, металличность, шероховатость. Последние две - одноканальные, их можно сжать до RG, B оставить пустым.
Итого 3 текстуры на 1 материал = 2.1 (1.2 сжатый) МБ.
100 материалов - 120МБ только на текстуры.
Если текстуры не 1к, а 2к, то размер больше в 4 раза (480 мб).
Ещё меши, но они занимают 30-40% от размера текстур.
Анимации - зависит от игры. Может получиться сравнимо с текстурами, а может раз в 5 меньше.
Музыка занимает много, сравнимо с текстурами, возможно больше.
я пока делаю упор модельки и свет, с текстурами я уже понял что может много весить
пока сам их рисую в блендере
Вспоминается .kkriger в 96кб.
.kkrigger, насколько я помню, так и не дошёл до релизной версии, а всё ради минимизации .exe, из-за чего игра гвоздями прибита к win api, и, скорее всего к какой-то конкретной версии винды, так как на win 11 запускается в режиме совместимости с некоторыми багами.
Портируемость - нулевая.
Расширяемость - околонулевая.
Популярность - вечная в сообществе минимизаторов.
Ценность для игрока - мизерная.
Полностью поддерживаю, у нас тоже свои велосипеды :)
математика портал в костную анимацию )
Мысли конечно во многом верные, но не универсально полезные.
Чтобы так делать, нужно подсобрать граблей, кроме того, это не универсальный ответ для команд и серьезной разработки игр.
Время - деньги даже для себя лично, а уж для других людей в случае найма - и подавно.
Любую фичу можно сделать, но современное разнообразие и сложность инструментов и фич такова, что сделать с нуля весь тулсет (или даже собрать из кусков) требует огромного количества времени.
Движки же обеспечиваются стабильную основу, понятные правила, множество специалистов, с ними знакомых и готовые решения.
Если не нравятся платные движки - можно стать энтузиастами для опен сурсных.
Единственное, что страдает - чувство контроля, но проблема в том, что свой движок тоже не то чтобы дает это когда что-то в очередной раз ломается во внешних API.
Обьективные проблемы движков, которые вылезают при долговременном использовании большой командой могут быть не релевантны проблемам разработчика-одиночки.
неизменная математика поидее,отрисовка текста, примитивов, и далее грабли - формат(статика, анимация), тулсет на блендер, и вот уже вы можете сделать игру, мерж террейна и разбиение виртуально на квадранты не совсем подподает под сложность как только поймём как генерить что нужно,
тогда стоит вопрос что добавляют и изменяют в движках
а кажись понял, у движка стоит задача пром масштаба по доступности, плюс реализация фишек, а у студии стоит вопрос написать своё решение если его пишут с нуля например
Сделать игру можно конечно на спичках, простые головоломки можно написать за вечер вообще с нуля.
Но во первых на движках их вероятно можно написать еще быстрее (впрочем такого же можно достигнуть, имея свой джентльменский набор).
Но чтобы делать нечто серьезное - посмотрите на современные игры. Если вы хотите сделать не инди для себя, а коммерческий проект - игроки будут ожидать от него графики, количества уровней, музыки, других вещей. Да и вы не энтузиаст 80-х и знаете, как выглядят крутые игры.
Не всем подходит делать креативные инди платформеры (и хорошие инди платформеры тоже делаются не за 5 минут).
И как только нужно нормальное 3д, физика, какой никакой звук, или, к примеру, нормальный редактор для части контента (ведь делать нужно не только уровни, но и меню, и заставочки и интерфейсы) - ты спекся.
Банальная возможность купить набор 3д ассетов чтобы не делать заборы и бочки на уровне - великое благо, потому что тебе лично придется потратить времени в эквиваленте гораздо больше, чем 5 долларов стоимости ассета.
Время - деньги
В коммерческой игровой игровой индустрии это давно превратилось(исключения есть, но они лишь подтвержают общее правило), в то что игровой софт это наиболее кривой, глючный и отвартительно оптимизированный софт.
И коммерческие "супер-движки", тут пожалуй основная причина, так например руководитель одной из коммерческих игродельных компаний(не буду называть какой), на вопрос о поддержке мноядерных процессоров в играх, пояснил, что если события гейплея, как таковые, распаралеливаются, то поддерживаем многоядерность, если нет, то извините!
Время деньги - это всегда было так.
То, что сегодня считается "живой классикой" делали не только энтузиасты на коленке, но и вполне себе волчары капитализма со всеми атрибутами - сжатыми сроками, переработками, спорными компромиссами и т.д.
С качеством игр вопрос связан с развитием индустрии и рынка, а не с самописными движками. Просто потому что могут и это дешевле - продукты супер сложные, все не проверишь, патчи можно делать хоть каждый день. Цена ошибки низка, достаточно, чтобы критическая масса игроков была довольна. Раньше игры отвратительного качества тоже выходили, но цена была другой - тираж дисков не перепечатаешь.
Вообще ситуация характерна не только для игр, они лишь выпуклый пример. Весь софт стал сильно хуже, позасовывают модных веб фреймворков на виртуальный сервер со встроенным браузером - все, интерфейс утюга готов.
По поводу участия движков в этом, то конечно связь есть, но с другой стороны. Порог вхождения действительно низок и мы видим взрывной рост игр. Естественно не все они одинаково качественные. История ровно как и с другим хорошим инструментом - он не ведет к уменьшению и улучшению работы, он ведет к тому, что работы делают больше, потому что могут.
Копроэкономика. 2k. Это хорошая статья, иллюстрирующая происходящее.
ну извините вы говорите об уровне дум, даггерфол, там и учили по другому, откройте описание формата файлов(есть 2 формата, которые показывают динамику изменения требования знаний к подходу) для интереса и вы поймёте разницу, те студенты вполне могли реально быть ентузиастами, просто так совпало все аргументы вместе в то время я считаю тем более не забывайте Skeletal_animation а еще если посмотреть глубже проводились исследования как её делать и до сих этот вопрос полу открытый отсюда и обилие форматов, по сути движок это окружение для создания движений моделей или их интерактивного проигрывания, но не такой как редактор(типо блендер или майя)
чтобы понять о чем я необходимо избавиться от слова анриал или юнити и взглянуть на это наивнее, тоесть буквально надо чтобы интерактивно проигрывались анимации вот то как наивно показалось это поидее то и есть буквально, движок и создан для этого, а рисование примитивов и математика подкрепляют это и дают уверенность
Вы говорите об определенном аспекте движка, прежде всего рендере (и это безусловно важная часть).
Движок в целом понятие довольно размытое - начиная от просто набора библиотек и заканчивая целым тулсетом.
И собственно ровно дум и показал, насколько это сложно и важно в смысле технологий, но в то же время как это можно отделить от игры и переиспользовать. Дум был одним из первых лицензируемых 3д движков, хотя библиотеки существовали и до этого.
В контексте требований и знаний, необходимых для разработки, они безусловно изменились. Еще в ранних нулевых была куча движкописателей по очереди имплементирующих самые вкусные штуки свежих релизов - от мощных 3д фич до симуляций на 10000 юнитов.
Проблема в том, что к играм это не всегда приводило.
Я не считаю либерализацию разработки игр злом, хотя безусловно проблемы создает.
Но и талантливейшие дизайнеры тоже прорезались сильно позже. Раньше, когда надо было быть обязательно программистом, а так же и швец и жнец и на дуде - было печальнее.
Игры безусловно развиваются, просто не всем нравятся направления. Но эволюция не так работает.
потомучто сделать скелетку, это значительная часть(+математика) плюс если смотреть на формат и требования-технологию отрисовки 95(прямая отрисвка(листы(1 версия GL) или более старые технологии)) - один вид рендера, 2005 другой вид (более похожий на буфферный погуглите mdx ваще магия ) такой как щас, в контексте что загрузили пачку анимаций персонажа и вот уже можно симпровизировать сцену(а сцена это декорации всего лишь) ну еффекты по вкусу - это как раз частички, текстуры, кусочки полигона(у dx это где-то Effect где-то шейдер наверно, я пока частички делал только на GL)
конечно говорю об этом ведь кто-то юзает хавок чтобы не париться
не просто так завёл реч о формате, потомучто если посмотреть разные форматы, лично мне очень нравится 3ds, можно увидеть что формат - это выражение движка, в формате можно прокидывать штуки или определять что упрощает обработку в коде, тоесть опять приходим к подходам по работе с данными
Скрытый текст
потомучто пришлось столкнуться с этим чтобы разобраться как хранить данные, чтобы потом было удобнее
тоесть как через векторное пространство настроить скелет, да это задача формата, хранить данные чтобы удобнее было их прочитать, формат - интерфейс для человека чтобы прочитать и воспользоваться им
Я с этим просто не согласен.
Конечно скелетная анимация - сложная задача. И в смысле реализации, и в смысле тулзов. И там действительно много зарыто, именно поэтому даже современные движки используют сторонние инструменты физики например.
Но это довольно минорная часть движка. Играм от гонок до стратегий продвинутой скелетной анимации не нужно, зато нужна куча других фич.
Формат безусловно выражение движка, но он во многом строится от основных механизмов в памяти, а не непосредственно от формата (хотя обычно он их и отражает)
про годот и то что он поддерживается сообществом, недавно был скандал с ними. нетерпимость. и разработчик годот, сказал что это нормально.
Пробовал такой подход. Делать игру на собственном движке первое время весело, а потом оказывается, что многие удобные вещи на коленке за пару вечером не делаются - сборка под разные платформы (особенно мобильные), поддержка разных разрешений экрана, создание атласов текстур, оптимизации отрисовки, системы частиц, столкновение различных форм, UI, внутриигровые покупки, профилировщик и т.д. - в других движках кто-то другой уже потратил сотни человекочасов, чтобы сделать всё как следует, а тебе только предстоит.
система частиц прикольная смотрите на то что вы выделили не как на тягость, а как на содержание книги, как на практики, тоесть всё заработает только вместе,
профилировщик это чаще RenderDoc, уи на первое время может помоч Imgui, столкновение надо разобраться с математикой и там определиться что точно нужно, оптимизация отрисовки надо смотреть практики и учиться, перенос кода на мобилку можно делать с sdl библиотекой, атлас достигается через понимание плоскости и переноса в шейдер данных, разные разрешения не сталкивался, с такой базой сложности начнутся только на этапе создания контента и 3д анимаций(улучшение через математику), да еще лоды не сказали и всякие новые практики
попробуйте начать с кубического мира через полигоны, там куб это точка может проще будет вьехать в тематику
Я не говорю, что это невозможно - но крайне утомительно и трудозатратно, особенно для хобби-проекта, который делает один или пара человек по вечерам
а зачем тогда программировать еще? тоесть где вы хотите научиться тому что есть и посмотреть какие бы вещи были бы для удобства реально нужны? тоесть не делать движок окей.
не делать утилит которые нужны? тоесть вы хотите только за деньги программировать или как?
нет ну конечно сложно, там всё как снежный ком по итогу, и не одна сфера участвует в создании код-визуализация, но не знаю
Простите, мне очень сложно следовать за мыслью в вашем комментарии, но попытаюсь ответить.
Метафорически говоря, если я хочу поесть салат и начну его приготовление с посадки семечек на грядку, то я умру с голоду быстрее, чем что-то вырастет. Вместо этого я пойду в магазин, сколько бы ни твердили, что выращенные своими руками овощи полезнее и вкуснее.
И в программировании точно так же. Я хочу получить готовую игру в обозримое время. Когда ресурсы ограничены, их лучше потратить на высокоуровневые вещи типа оттачивания геймплея и баланса, сюжет и т.д., а не ковыряние низкоуровневых проблем и поиска костылей для них. С нормальным движком можно рассчитывать на то, что эти скучные вещи уже решены.
Жду подобный пост от разработчика сколько-нибудь известной игры за год-два от начала создания, а не от разработчика узконишевых фан-проектов на протяжении 20 лет.
Да, естественно, такие бывают, но это исключения.
Вспоминается цитата с баша про "ненужный" широкополосный интернет: "канализационная труба такая широкая чтобы пики трафика пропускать". Современные комбайны-движки для того же: чтобы ты мог загуглить как сделать фичу в игре, которую захотел, а не для того чтобы ты неделю гуглил как программировать инструмент, который позволит эту фичу сделать. Поэтому почти все крупные студии, не имеющие собственный движок, дорабатывают существующие движки, а не изобретают велосипеды. А для 99% инди и дорабатывать ничего не надо.
Плюсую и в закладки.
Коммерческие "супер-движки", по моим скромным наблюдениям, давно превратили игровой софт пожалуй в наиболее кривой, глючный и отвартительно оптимизированный софт.
Полностью согласен с автором, что на каждое обновление "супер-движков", потом необходимо ставить кучу заплат в софте их использующем, и это касаеться всех, а не только малых студий и соло-разработчиков.
Желаю автору удачи, мотивации. Сам форкнул Quake 3 движок и занимаюсь переписыванием всего а также встраиваю obj формат моделей, физику пишу, скриптовый интерпретатор свой итд
не, ну если это не про бизнес, а про то, что писать свои движки это так прикольно и речь идет о проектах масштаба Celeste...
Это пост не про игры как бизнес, не про деньги вообще. Человек любит программировать, всё сделать сам от начала до конца и рассказывает как это делает таким же, как он.
Похоже, SFML всё никак не может набрать популярность, раз про неё забывают упоминать.
Начинал с него, но придётся переходить на SDL, т.к. выглядит более навороченным и активно развивается.
Как делать видеоигры в 2025 году (без движка)