[Опыт спустя] Скриптовый редактор трехмерных изображений

Я часто встречаю и с большим удовольствием читаю вопросы типа:

Это выглядит забавно, думаешь, кто вообще эти люди, которые пишут такие глупости? По большей части это люди, которые только хотят встать на путь разработчиков и сопутствующих профессий. Получается, что мало кто рассказывает о том, как "вообще" сделать то, что ты придумал и как обретаются нужные знания для этого.

Вы можете прослушать курсы про организацию процессов разработки, про использование игрового движка, про язык программирования, про монетизацию проектов, но найти ответ как “вообще” создать придуманное - трудно.

Люди как-то незаметно проходят этап понимания того, как создать проект. Мне видится это так:

Если нужен короткий ответ, то, чтобы узнать, что происходит в пункте 2, нужно начать делать проект и довести его до какого-то состояния. Еще один способ - прочитать историю создания какого-то проекта.

Мне захотелось написать про пункт 2 именно в стиле историй о создании, потому что я сделал огромное множество проектов разной степени полезности: несколько десктопных приложений, много сайтов на заказ, писал свои игровые движки(несколько раз), пару ненужных игр, писал свой Стим(до Стима там далеко, конечно), написал продукт для себя, который вдруг стал популярным, работал в скучном энтерпрайзе и в нескольких продуктовых командах. Для меня, каждый проект, даже неудачный, это приятный и полезный опыт, о котором интересно рассказать, хоть бывает и немного стыдно.

По большей части, проекты, о которых я бы хотел рассказать, больше не поддерживаются, поэтому прошу не рассматривать это как рекламу, но и как post mortem тоже прошу не рассматривать, т.к. писалось все это не для какого-то заработка и какой-либо цикл жизни не закладывался, мне просто было интересно. Я даже избегаю слова “продукт” в статье. Нет, будучи школьником я представлял как зарабатываю этим миллионы, но очень быстро фантазии разбивались о реальность.

Пост немного похож на мемуары (и это одна из причин, почему это в разделе блоги), но я бы хотел акцентировать внимание на том, почему принимались те или иные решения в проектах, тогда, эта информация была бы полезной.

Вступление, полное оправданий, написано, можно переходить к сути.

Первое, о чем мне захотелось написать, это проект, который в каком-то смысле изменил мою жизнь, позволив стать профессиональным разработчиком. Проект приблизительно 2004 года (17 лет прошло с релиза. Это не опечатка). Это был мой 9-10 класс. Приложение называется "Скриптовый редактор трехмерных изображений Суслик 3D".

В том далеком году, я мечтал сделать трехмерную RTS игру.

Многие люди начинают заниматься программированием, потому что хотят делать игры. Я не исключение.

На момент начала работы над Сусликом 3D у меня уже были какие-то мелкие проекты, от которых даже не сохранились скрины, т.к. на курсы Паскаля в Станции Юных Техников я пошел в 7 классе.

"Чтобы делать трехмерные игры - нужны трехмерные модели" - вроде очевидный тезис.

Чтобы сделать трехмерные модели - нужен редактор 3D моделей. Я немного ковырял 3D Studio Max, но мне она казалась безумно сложной, я не понимал, как там создавать модели, которые бы подходили для моих нужд. Плюс ко всему, я не знал как использовать созданные модели в своих проектах. Зато я уже немного знал OpenGL и в Delphi, которое началось на занятиях после Pascal была обертка для OpenGL команд.

Что мог сделать школьник с кучей свободного времени и с доступом к Интернету по временнЫм карточкам, которые надо было выпрашивать у родителей? Искать в Рамблере (он тогда реально был лучше Гугла и Яндекса) либу, для чтения файлов 3D Max на Делфи или написать свой редактор с удобным выходным форматом? Ответ мне казался очевидным - писать свой редактор.

Прошу еще обратить внимание, на тот период времени, я даже не знал, что бывают динамические массивы, а чтение бинарных файлов казалось мне каким-то колдовством, поэтому вариант с написанием парсера 3ds моделей я рассматривал лишь мельком. Зато я умел читать текстовые файлы методами вроде ReadLn(f, myVar); Выходной формат должен был быть текстовым.

Языки программирования захватили меня на тот момент времени. Я практически не умел пользоваться графическими редакторами. Я даже не знал, что есть Фотошоп, но пользовался PaintShop'ом. Отсутствие навыков визуального создания объектов навело меня на еще одну особенность проекта. Редактор должен был быть скриптовым. Я прекрасно мог представить в голове точку с координатами { x: 5, y: -5, z: 10 } и мог нарисовать её программно по формуле, которую мне сообщил мой учитель по программированию.

Cо школьной программы, я умел раскладывать изображения по ортогональным проекциям.

Мой дед был инженером, и я видел программы типа Ферма и SCAD для расчета строительных конструкций. Он мне немного показывал, как это работает, я знал, что, когда есть 2 точки, мы можем их соединить отрезком. В OpenGL были такие сущности как треугольники и ректанглы. Весь скриптовый язык уже вырисовывался в моей голове:

Механика была максимально простая - задал точки в пространстве, потом объединил их в треугольник или ректангл. На этом строилось все.

Скриптовый редактор позволял сделать одну интересную вещь - проводить действия не с реальными объектами в памяти, а с текстом команд. ООП? Классы, объекты, стек, куча, освобождение ресурсов? Не, я, конечно, на тот момент слышал немного об этом и, конечно, классы и объекты этих классов использовались в проекте, но я не понимал все это на должном уровне, я думал, что это понимают только гении, к коим я себя не относил. Следить за циклом жизни объектов мне было сложно. Я использовал структуры (record в терминах Паскаля). Зачем создавать в памяти объект треугольник? Делфи выдаст какую-нибудь ошибку типа null-reference, когда объект случайно уничтожится. Со структурами такой проблемы не было. Я мог просто копировать строки скриптового языка Суслика 3D и менять им номера, а после - перекомпилировать трехмерный объект. Это позволило мне без каких-то адекватных знаний в ООП сделать то, что вы видите на картинке.

Основная часть программы рисовала объекты средствами Канваса, а не OpenGl, мне не хватало знаний и информации, чтобы сделать выделение с помощью OpenGl.

Но трехмерная модель это не просто координаты, это ещё и текстуры.

Дальше я кое-как нарамблерил как натягивать текстуры на ректанглы. И сделал вторую часть проекта:

Эта часть проекты тоже была скриптовой, я следовал той же логике, что и раньше - не умеешь работать с объектами в памяти - меняй скрипт описания объекта и перекомпилируй. Кстати, текстуры с надписью USSR, вполне себе отражают информационный фон тех лет.

Текстуры можно было просто вращать за счёт второго аргумента.

В этой части программы мне пришлось всё-таки сделать выделение в OpenGl, к тому времени я даже смог найти в Интернете как это делать и даже сохранил себе найденную страницу, чтобы не тратить время с интернет-карточки. Увы, найденная статья была слишком сложна для меня. Выделение я сделал путем параллельных с OpenGL расчетов положения точек треугольников. Я находил проекцию на экран и использовал формулу "для определения того, попадает ли точка в треугольник", которую мне также подсказал учитель по программированию.

Оставалась третья часть программы. Мне были нужны анимации. Я разобрался, что OpenGl имел команду glNewList(), а анимации представляла из себя подготовленные листы объектов для быстрого отображения.

Нужно было минимальными усилиями создать нужное количество кадров анимации.

В моем кругозоре была старинная досовская программа для создания анимации FantaVision.

Меня она безумно зацепила, и я запомнил механизм, как она создавала анимации по ключевым кадрам.

Оставалось повторить это так, как я мог. Я сделал очередной скриптовый язык, который позволял проводить стандартные манипуляции над набором точек: Translate, Rotate, Scale. Каждый ключевой кадр выглядел как применение этих трансформаций. Промежуточные кадры строились с помощью интерполяции (не уверен, что я знал это слово на тот момент, может быть я оперировал понятием пропорций)

Получалось что-то такое:

Три описанные части программы позволяли мне создать удобный для использования с OpenGl вывод. Так я сделал свою очередную утилиту для создания игр, с помощью которой в том же году приступил к созданию своей RTS.

Проект понравился учителю, и я выступал с ним на научно-практических конференциях и даже занимал какие-то места на них.

Все решения по разработке редактора приходили в голову на стыке моих ограниченных знаний и случайно увиденных вещей.

Наверное, так и должно быть. Возвращаясь к первому забавному скрину: если не знаешь как что-то делать, нужно больше смотреть по сторонам. Критически смотреть и запоминать.

Спасибо

P.S. Редактор статей DTF отвратительно работает в FireFox и вообще имеет сомнительные механики отмены изменений.

#личныйопыт #будетполезно #постмортем