Учусь программировать. Кубочанки
ч. первая Чем я занимался пол года. Учусь программировать.
Пока я занимался конструктором, все задавался вопросом, а почему же никто не делал этого до меня, почему игры настолько примитивные и мир в них настолько статичный ? Я был наивен, поэтому с большим энтузиазмом вкладывал силы в свое, как мне казалось "Детище" :))). Но как и следовало ожидать, появилась куча проблем и ограничений, о которых я ничего не знал. Во первых, это физика и коллайдеры. Так вот чем больше объектов-деталек с коллайдерами появлялось на игровом поле, тем тяжелее все это обрабатывать машине.
Сразу закрались некие сомнения, а правильно я все делаю, почему то вспомнился знаменитый "Майнкрафт" со своим бесконечным кубическим миром, в который мне кстати так и не довелось поиграть. Я начал заваливать форумы вопросами, а как же это все работает, в нем спокойно обрабатываются миллионы кубиков, а у меня уже после 10 000-20 000 деталек производительность сводилась на нет. Тогда я узнал, что такое Mesh и что, так называемые кубики в Майнкрафте - вовсе не кубики, а огромные кучи кубов объединенные в большие объекты называемые Чанками.
На самом деле такие вопросы на форумах появляются чуть ли не каждую неделю, я был не исключением.
Вообще, на форумах сообщение со словом "Майнкрафт" вызывает дикую неприязнь. >>"Вот очередной клон пилится". На самом деле устройство мира этой игры хороший пинок в понимание многих вещей оптимизации больших игр. И интерес у меня был не к самой игре, а именно к устройству обработки таких больших объемов данных.
Поняв, что конструтор - это тупик для большого мира, я забросил его, выложив исходники в отрытый доступ. На самом деле, подобная схема вполне себе жизнеспособна для игр с небольшим миром :). У меня же были имперские замашки.
А потом я увидел разработки Miguel Cepero с его VoxelFarm:
и Jens Blomqvist с BlockScape:
На тот момент сказать, что я был впечатлен - это не сказать ничего. Этих людей смело можно назвать богами виртуальности. Полностью изменяемый до мельчайших деталей мир - это просто фантастика. На самом деле, направление которого они придерживаются - это перспектива компьютерных игр через 3-5 лет, так сказать работа на будущее.
Я еще не догадывался, какие коллосальные знания нужны, чтобы сделать нечто подобное.
Мои же знания сводились скорее к опыту игрового процесса, а не устройтсва игр.
Но, вернемся к моему примитивному понимаю :))). Впечатлившись этими наработками, я с удвоенной энергией стал вникать в понятия Чанков, Мешей, оптимизации игрового пространства. На самом деле внятных уроков как же сделать подобный Майнкрафту мир на русском языке практически не найти. Зато, есть вполне себе приличные уроки на Английском и печатные и видео, благо с языком я дружен на том уровне, чтобы понимать, что нужно делать. И начал я колупаться в основах построения процедурных мешей, на основе кубочанков.
Итак, чтобы понять как же программно построить фигуру из полигонов, и вообще как нарисовать простейший полигон чистым кодом я потратил около недели практически бессонных ночей. Может это и долго, но если учесть, что слово "Алгоритм" для меня звучало как нечто доступное понимаю в узких кругах яйцеголовых - это был прорыв :))). Так я начал свое изучение алгоритмов в принципе. Я еще не знал, что в изучение различных алгоритмов станет для меня основным занятием и интересом...
Провозившись еще некоторое время со своим кодом, я родил таки первый процедурный кубочанк, а потратив еще пару дней - смог создать довольно большую площадь, состоящую из таких конструкций. Но это было только началом. Я столкнулся с тем, что даже в таком виде достаточно большие конструкции размерами в несколько миллионом потенциальных кубиков приводили к жесточайшим тормозам. Тогда мне подсказали, что не нужно заниматься отрисовкой того, что не видно. Зачем рисовать невидимые детали? Так я начал постигать основы оптимизации рендера (вывода графики). На то, чтобы дополнить код я потратил еще пару дней и получил примерно вот такую конструкцию.
На видео несколько миллионов потенциальных кубиков, оптимизированных по рендеру :)). Первый вариант. Видео от июня этого года, снимать я их начал позже начала своих изысканий.
Затем я потратил еще некоторое время, чтобы прикрутить свой примитивный поиск пути к этой конструкции и понял, что такая схема поиска пути совершенно не подходит для более менее серьезного проекта. Боты конечно обходят простенькие препятствия, могут даже их сломать, но в мало-мальском лабиринте - они скорее умрут, чем найдут правильную дорогу )).
Так я пришел к тому, что нужно вникать в суть "поиска пути".
ч.3 Учусь программировать. Знакомлюсь в теорией поиска пути.
Пока я занимался конструктором, все задавался вопросом, а почему же никто не делал этого до меня, почему игры настолько примитивные и мир в них настолько статичный ? Я был наивен, поэтому с большим энтузиазмом вкладывал силы в свое, как мне казалось "Детище" :))). Но как и следовало ожидать, появилась куча проблем и ограничений, о которых я ничего не знал. Во первых, это физика и коллайдеры. Так вот чем больше объектов-деталек с коллайдерами появлялось на игровом поле, тем тяжелее все это обрабатывать машине.
Сразу закрались некие сомнения, а правильно я все делаю, почему то вспомнился знаменитый "Майнкрафт" со своим бесконечным кубическим миром, в который мне кстати так и не довелось поиграть. Я начал заваливать форумы вопросами, а как же это все работает, в нем спокойно обрабатываются миллионы кубиков, а у меня уже после 10 000-20 000 деталек производительность сводилась на нет. Тогда я узнал, что такое Mesh и что, так называемые кубики в Майнкрафте - вовсе не кубики, а огромные кучи кубов объединенные в большие объекты называемые Чанками.
На самом деле такие вопросы на форумах появляются чуть ли не каждую неделю, я был не исключением.
Вообще, на форумах сообщение со словом "Майнкрафт" вызывает дикую неприязнь. >>"Вот очередной клон пилится". На самом деле устройство мира этой игры хороший пинок в понимание многих вещей оптимизации больших игр. И интерес у меня был не к самой игре, а именно к устройству обработки таких больших объемов данных.
Поняв, что конструтор - это тупик для большого мира, я забросил его, выложив исходники в отрытый доступ. На самом деле, подобная схема вполне себе жизнеспособна для игр с небольшим миром :). У меня же были имперские замашки.
А потом я увидел разработки Miguel Cepero с его VoxelFarm:
Click to viewи Jens Blomqvist с BlockScape:
На тот момент сказать, что я был впечатлен - это не сказать ничего. Этих людей смело можно назвать богами виртуальности. Полностью изменяемый до мельчайших деталей мир - это просто фантастика. На самом деле, направление которого они придерживаются - это перспектива компьютерных игр через 3-5 лет, так сказать работа на будущее.
Я еще не догадывался, какие коллосальные знания нужны, чтобы сделать нечто подобное.
Мои же знания сводились скорее к опыту игрового процесса, а не устройтсва игр.
Но, вернемся к моему примитивному понимаю :))). Впечатлившись этими наработками, я с удвоенной энергией стал вникать в понятия Чанков, Мешей, оптимизации игрового пространства. На самом деле внятных уроков как же сделать подобный Майнкрафту мир на русском языке практически не найти. Зато, есть вполне себе приличные уроки на Английском и печатные и видео, благо с языком я дружен на том уровне, чтобы понимать, что нужно делать. И начал я колупаться в основах построения процедурных мешей, на основе кубочанков.
Итак, чтобы понять как же программно построить фигуру из полигонов, и вообще как нарисовать простейший полигон чистым кодом я потратил около недели практически бессонных ночей. Может это и долго, но если учесть, что слово "Алгоритм" для меня звучало как нечто доступное понимаю в узких кругах яйцеголовых - это был прорыв :))). Так я начал свое изучение алгоритмов в принципе. Я еще не знал, что в изучение различных алгоритмов станет для меня основным занятием и интересом...
Провозившись еще некоторое время со своим кодом, я родил таки первый процедурный кубочанк, а потратив еще пару дней - смог создать довольно большую площадь, состоящую из таких конструкций. Но это было только началом. Я столкнулся с тем, что даже в таком виде достаточно большие конструкции размерами в несколько миллионом потенциальных кубиков приводили к жесточайшим тормозам. Тогда мне подсказали, что не нужно заниматься отрисовкой того, что не видно. Зачем рисовать невидимые детали? Так я начал постигать основы оптимизации рендера (вывода графики). На то, чтобы дополнить код я потратил еще пару дней и получил примерно вот такую конструкцию.
На видео несколько миллионов потенциальных кубиков, оптимизированных по рендеру :)). Первый вариант. Видео от июня этого года, снимать я их начал позже начала своих изысканий.
Затем я потратил еще некоторое время, чтобы прикрутить свой примитивный поиск пути к этой конструкции и понял, что такая схема поиска пути совершенно не подходит для более менее серьезного проекта. Боты конечно обходят простенькие препятствия, могут даже их сломать, но в мало-мальском лабиринте - они скорее умрут, чем найдут правильную дорогу )).
Так я пришел к тому, что нужно вникать в суть "поиска пути".
ч.3 Учусь программировать. Знакомлюсь в теорией поиска пути.