Продолжая тему предыдущего поста...

Штука, похожая на ту, которую я так изобретаю в миру называется Sparce Voxel Octree и применяется для рендеринга сложных объектов, как оказалось. Именно похожая, а не такая же. Во-первых, у меня нету "вокселей", которые состоят из 2х2х2=8 (и поэтому octree), хотя это имеет свои плюсы. Во-вторых, дело пока не касается рендеринга.

Если же говорить о том, чем кончилось то, что я начал в прошлый раз, то за выходные там пофиксились некоторые баги, время обработки для одной "точки наблюдения" упало до примерно 20 миллисекунд (это только за счет правки багов, без оптимизаций, хотя все равно много), прикрутилось сохранение блоков на диск и загрузка с него (правда, настолько неэффективная, а может быть, даже бажная, что немного побродив, я занял гигабайта 2 на диске и создал порядка 250К файлов) , а еще выгрузка тех блоков, что уже не нужны. Также я нашел небольшую статью (http://0fps.net/2012/01/14/an-analysis-of-minecraft-like-engines/) про эту тему, однако в ней метод нашли "опасно привлекательным" и "на самом деле очень медленным", так как действительно не очень просто бывает отыскать, скажем, соседний блок. Хорошо, если он оказывается в одном "суперблоке", но если нет, приходится делать запросы "наверх", которые, при большой глубине, действительно оказываются долгими. Что актуально для настоящих octree, где "наверху" знают только 2х2х2. В случае, когда "суперблок" содержит, например, как в случе моего эксперимента 8х8, это менее актуально, на самом деле. Тем более, что в силу изменяющейся с расстоянием точности обработки, соседи становятся все крупнее.
Правда, пока не известно, как в такое впихиваются некоторые другие вещи. Например, меня до сих пор гложут сомнения, что так можно будет легко и просто обрабатывать, например, жидкости и газы, для чего нужно, как минимум, находить границы сред. Ведь я уже говорил, что у большинства подобных движков есть, например проблемы с водой, точнее с ее течением в более низкие места, вызванные "бесконечным миром" и "очень много блоков нужно пересчитать". Так как мир в моем движке, во-первых, конечен, во-вторых, все равно пересчитывается каждый тик, само собой нужно попытаться и настоящую работу с жидкостями и газами реализовать.
И так как я уже закончил, по моему мнению, с 2D, прежде чем копаться куда-то дальше в 3D опять таки придется заниматься поиском простого решения для прототипирования в 3D. Потому что писать на голых вызовах OpenGL все-таки будет очень долго.
И есть еще темы для размышления, только из того, что хотелось-бы видеть возможным:

1. Как впихнуть в это некие сети (провода, трубы, конвейры, что угодно), по которым бы можно было передавать энергию или сигналы или предметы. Как эффективно их обрабатывать после перехода с отдельных блоков на более крупную сущность? Впрочем, наверняка это и без таких извратов как-то сначала преобразуется в один объект и соответственно обрабатывается. Однако, к сети обычно подключаются сущности, которые делают из А какое-то Б, и вот тут уже нужно крепко подумать. Можно ли, например, сделать из такой сети с сущностями достаточно простой объект, который и без блоков выполняет нужные действия. А еще, можно ли сделать так, чтобы сложность его обработки не сильно росла с размером этой сети...
2. Как впихнуть в это мультиблочные структуры? Рано или поздно их захочется видеть и они должны как-то, во-первых, узнавать, что они правильно собраны, во-вторых, что они до сих пор целы, а в третьих - взаимодействовать всей своей тушей с окружающим миром.
3. А еще явно обязательно захочется иметь что-то, что больше 1 блока и умеет двигаться. Ну, я не знаю. Динозавриков. Улиток размеров с 9-этажку. Мало ли что. Звездный крейсер Дарта Вейдера. Причем, что-то обязательно захочется собирать из блоков, например. Однако, такое сооружение должно не просто двигаться взад и вперед, а иметь возможность делать это, во-первых, плавно, во-вторых, плавно же поворачивать. И нужно будет обнаруживать столкновения, конечно же.
4. И самый эпичный вопрос мне в голову пришел ночью. Скажем, у нас есть лодка, которая плавает на поверхности воды. Сейчас она находится далеко от нас, но плавает на поверхности озера, которое мы случайно осушили у себя тут. Неужели нужно хранить сущность лодки как-то отдельно, а потом проверять, влияет ли на нее какой-то процесс? Глупо как-то и неэффективно смотрится. Другой вопрос - при осушении вода должна все-таки оставаться в разных неровностях, из которых она не могла бы утечь. То есть, вытекание воды из водоема процесс не настолько простой как "да просто в этом суперблоке уровень моря меняем и все". В общем, вещи, которые кажутся естественными, вносят немало вопросов для размышления. 5+) ... много всего, чего страшно озвучивать

С учетом того, что в 2D простейшая операция, которая просто брала одно число из каждого "блока" и усредняла его с соседними заняла 20 мс, у меня уже есть сомнения в производительности того, что получится. Хотя, конечно, это быстрее обсчета всего мира. Я уже приводил пример Земли, с радиусом около 6000 км. Так вот, в итоге двухмерный мир получается размером примерно 4.5е8*2.2е8, то есть 12е12 блоков. С учетом текущих алгоритмов, которые его разбивают на 16х8 частей, а потом каждую 8-ю часть полученного постепенно разбивают на 8 и углубляются до уровня отдельного блока, который находится на небольшом расстоянии от игрока, выходит всего порядка 30 тысяч блоков. Хотя, конечно, во-первых, в 3D это будет на порядок больше, во-вторых, мне эта дистанция "высокого разрешения" кажется все-таки крайне маленькой. Но 30 тысяч это уже большая цифра. Стоит делать что-то сложнее с каждым из 30 тысяч блоков и движок просто не будет успевать делать это вовремя. Является ли это проблемой Java? Не знаю. Можно узнать, только если переписать все на С++. Чем я, возможно, и начну заниматься, ради того, чтобы вспомнить, как оно и будет ли от этого какой-то прок.
Как это не создает проблемы в Майнкрафте? Дело в том, что там не обрабатывают каждый блок, насколько я знаю. У него есть сущность TileEntity, и только она обрабатывается, причем только если чанки, в которых они находятся, загружены. Это может быть какой-то монстрик или еще что-то. Они там хранятся в списке отдельно от блоков, поэтому размер мира никак не влияет на производительность. Зато влияет количество таких, генерирующих события, объектов. И ложится все где-то на количествах порядка одной-двух тысяч, по моему.

О срывах

Кажется, я опять немного сорвался со своего режима. Все дело в подлом программировании, которое иногда способно вызвать желание играть в игру "еще одна идея относительно этого и все". Мне все-таки захотелось проверить, можно ли в кубическом мире достаточно быстро обрабатывать глобальные процессы, не загружая весь мир поблочно в память. Почему нельзя загрузить? Ну, возьмем, например, такую планету, как Земля. Она имеет радиус около 6 тысяч километров. Это значит, что если мы хотим ее превратить в кубики, получится порядка 40*20*6 миллионов кубиков, без учета атмосферы. То есть, очень большое число, порядка триллионов. Если даже хранить блок как один байт, требуется терабайт с копейками, без учета всяких там структур данных. Сгенерировать его - я, полагаю, в зависимости от алгоритма, дело многих часов, может даже дней. Просчитывать его изменения с точностью до одного блока - невозможно в реальном времени. Идея была в том, чтобы проверить, насколько правдоподобную картину можно получить, если, скажем, генерировать и считать все большие и большие блоки по мере удаления от наблюдаемой игроком точки. Начал, конечно, с двухмерного мира, который имеет просто блоки километр*километр, то есть, в тысячу раз уменьшил Землю. Просто для удобства. И тут началось. Вроде бы все было идеально продумано, но где-то влезли какие-то, видимо, недостаточно хорошо обдуманные баги и пока что не получилось ни шиша. То есть, вроде-бы все работает на этапе рассчетов и весь мир успевает "тикнуть", без рассчетов и прочих операций, за десятки миллисекунд, на жаве, но отобразить его кусочек пока не получается. Где-то косяк с "взять вон тот блок с этими вот координатами". Хотя, конечно, и десятки миллисекунд это много. Еще и в двухмерном варианте. В общем, пока разочаровываюсь в идее, поэтому, видимо, так сильно залип в проблеме. Даже вот сюда ничего не писал. Хотя подход сначала казался очень правильным и даже казалось, что он офигенно должен масштабироваться, как на отдельные потоки, так и на разные процессы и даже физические машины. То есть, такой мир можно было бы размазать на целый кластер серверов и пускать игроков толпами. Но что-то, похоже, будь все так просто, это давно уже сделали бы.

На самом деле это важно, вовремя останавливаться и переключаться на другую деятельность, чтобы она не страдала. Работа та же. Летсплей. Обучение. И еще одна проблема - я эту задачу никак не разбил на части, она никак не спланирована и даже каких-то идей, которые возникли по мере попыток ее реализовать, я не записал. То есть, все потеряно. Хотя идей было много, и часть из них может быть полезна даже для других каких-то проектов. Вообще привычка это все записывать и обрабатывать у меня, похоже, развита не очень хорошо, потому что такое бывает часто. И не знаю, что с этим поделать, потому что это скорее касается самоконтроля и привычек. Менять и прививать новые привычки у меня пока получается плохо. А может просто очень неудачно реализован функционал добавления новых задач в текущем софте, ведь MLO написан под винду и что-то не спешит ловить нажатия хоткея, когда не активен. И иконку в трее не всегда делает. В общем, дело дрянь. Надо привыкать натыкивать новые задачи в андроиде, что не всегда удобно.

Чего, возможно, можно искать в песочнице, что считать выживанием, в принципе?

Все-таки пытаюсь точно понять, чего хочется. То, чего искал и чего не нашел. И много ли таких же.
Майнкрафт, наверное, сначала зацепил тем, что можно сделать себе ранчо с нехилым особняком на берегу моря. Или замок на вершине горы. И вообще осваивать большую территорию, которая ничья. Плохо стало, когда некому показать и нет, перед кем выпендриваться. Скучно. Нужно было много копать и заниматься прочим микроменеджментом.
Потом моды нашлись. В модах можно было сделать такую классную штуку, чтобы выкапывать помногу и где-то далеко, а складывалось у тебя дома. И можно было все хранить в маленьком пространстве и легко искать, что нужно. И автоматический крафт по запросу. И можно было долго ковыряться. И тоже хотелось осваивать большую ничейную территорию. И тоже стало плохо, когда некому пользоваться. А потом еще и стало надоедать, что все неидеально. Океаны не высасывались, местность не опустынивалсь, гармония с природой никуда не девалась. И да, одинокий чувачок в квантовой броне не знал, куда девать бесконечные богатства, добытые индустриальными методами. Одни и те же руины, одни и те же монстры. Одни и те же заброшенные шахты. Опять скучно. Похоже, вы хотите сказать, что надо было идти на сервере играть с кем-то? Я тоже так думал. Но с этими модами, как правило, я заставлял все дико тормозить и в одиночку.

Потом они сделали кое-что интересное. Появился мод HQM, который требовал от тебя дополнительных целей. Особенно порадовал немного упоротый модпак с картой Agrarian Skies, в котором "небожители" настойчиво требовали целые составы цистерн молока, тысячи и тысячи бревен, миллионы и миллионы блоков камня из нечего. Неплохой был челленж построить автоматический завод для производства всего этого. Ну и это позволило пощупать кучу разных модов, которые раньше не пробовал, потому что они немного не той направленности. Правда, там не хватало одного - не было мира, из которого нужно это все высосать. То есть, все получалось буквально из ниоткуда, нужно было только достаточно много поставить машинок, которые делали камни из ничего. Возможность получать бесконечное количество блоков камня из одного ведра лавы и одного ведра воды, конечно, в Майнкрафте доставляет. Особенно, когда хочется говорить о реализме. Но это я отвлекся.

Как всегда бывает, в любой игре есть есть эндгейм. Не геймовер, а эндгейм. Когда у тебя уже все есть и дальше может быть только больше, даже если ничего не делать. У кого-то он наступает быстро, потому что они наигрываются еще на этапе заведения коровы и постоянной дойки молока с нее, чтобы поесть сегодня тыквенного пирога. Зависит от любопытства, задротистости и амбиций. Оригинально в МК это пойти в другое измерение и убить дракона. Достаточно сложная цель для ванильного игрока. С модами нового эндгейма не появлялось, кроме, разве что, ГрегТеха, который многие считают почему-то хардкорным и упоротым. Я бы сказал, что это нетипичный для мира Майнкрафта мод, который все пытается переделать в какой-то псевдорелистичный sci-fi. И он добавляет никому не нужный термоядерный реактор, с которым у вас, скорее всего, все, наконец, ляжет и станет тормозить, потому что он ест много дейтерия/трития, которые получаются с нужной скоростью только через несколько десятков машинок. В общем, да, упоротый, но именно этот подход не дает мне покоя. Я люблю sci-fi.

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

Вот что действительно бы хотелось, это чтобы эти все штуки могли получаться сами собой. Я не знаю, генерироваться, придумываться, конструироваться игроком в разумных пределах, не нарушающих баланс. Подобно тому, как можно из любых блоков построить себе иридиевую избу с золотыми ставнями. Чтобы была экономика и влияние местную флору и фауну, конечные ресурсы, и, главное, чтобы продукцию было куда девать. Но, наверное, это нечто очень уж глобальное, и лучше и правда делать это в бесплатном симуляторе с хорошей графикой. Но. Во-первых, в нем уже и так куча игроков, которые все уже забрали себе, во-вторых, все происходит медленно. То есть, есть причина искать другой способ. Но сделать ускоренный симулятор симулятора с классной графикой... да, может быть. В общем, интересный вопрос: возможно ли теоретически вместо создания контента дать достаточно вольный набор законов/правил, чтобы оно как-то само... генерировало мир (это уже умеют), наполняло его интересностями (это уже умеют, кто-то лучше, кто-то хуже), возможно, создавало уникальных обитателей, приспособленных для этого мира, а потом давало возможность игроку из всего найденного придумать что-то свое. Не только построить из разноцветных кубиков себе хатку, но и сделать таким же образом работающие вещи, которые могут из А делать Б и так далее? Нет, я понимаю, продумать и написать код для такого - невероятно сложно. Еще сложнее придумать под это необременительный интерфейс. Абсолютно неподъемно превратить это в модельку для отображения на экране. Поэтому вряд-ли это путь. Но может, тогда, можно сделать добавление фич более простым занятием? Или что-то среднее?Чего, возможно, можно искать в песочнице, что считать выживанием, в принципе?Чего, возможно, можно искать в песочнице, что считать выживанием, в принципе?

Немного анализа подхода к продуктивности. И снова про идеальную песочницу.

Конец очередной недели. Сплю все так же - обычно раньше 11, иногда раньше 12. Эффект интересный - сонливость днем пропала, вроде-бы появилась энергия. Правда, она иссякает к вечеру, даже я бы сказал, довольно быстро, уже часам к 7 (хотя 12 часов это вполне нормально, если смотреть с другой стороны). Но пока правильный сон рулит. Я вижу меньше проблем с прокрастинацией на этой неделе.
Правда, несмотря на какое-то приподнятое настроение, в конце недели всякий анализ реальных цифр уже не так радует, повторяя результат прошлой недели. И дело не в том, что "не успел", а в том что не очень много времени попадает в фокус. Большие перерывы между подходами, которые растягиваются до 15-30 минут, сожрали все время, я полагаю. А были они из-за кучи разных вещей, которые происходили дома. То появился аквариум с рыбами, то еще больше рыб. Потом с неба упала еще и черепаха. В общем, домашние во всю пытаются кого-то понянчить и склонны к неконтроллируемому накоплению всего, что плохо лежит и выгодно покупается. Пока не придумал, как это лечить.
На фоне всего этого роение мыслей по поводу того, чего бы мне хотелось попробовать реализовать (а страшно хочется сделать свой клон Minectaft почему-то) достигает пика. Однако, не хочется делать тупой клон. В голову лезут всякие разные идеи, начиная с объяснимого сюжета и заканчивая какой-то другой системой крафта. Хотя, в MC, она, возможно, наиболее удачная, потому что сочетает как визуальный "рецепт", так и компоненты, и их размер оптимален - от 4 до 9 предметов в квадратной матрице. Это относительно просто запоминать, иногда выглядит очень наглядно и дает огромное количество вариантов. Правда, в ней все очень по-игрушечному, но для игрушки это как раз хорошо. В общем, мне нравится этот подход, но во-первых его не хочется копировать, во-вторых, хочется чего-то серьезнее, реалистичнее, что-ли, выдумать.
Да и вот, с чего все начинается там? Вы появляетесь в случайном месте и в руках у вас есть волшебное ничего, чем можно рубить деревья, копать землю... Как это рубить деревья ничем? Вот мне тоже никак не лезет в голову этот факт. Ладно копать землю руками, в принципе, если очень захотеть, можно. Но голыми руками сделать из дерева бревна, а из бревен - планки...
Потом вы делаете из нарубленного голыми руками дерева деревянный топор. Голыми руками. Возможно, помогаете себе зубами и ногами. В конце концов, вы получаете деревянный топор и, самое важное - деревянную кирку. И этой деревянной киркой вы добываете себе первый камень. Из трех огромных камней в один кубометр объемом и пары палок вы голыми руками можете сделать себе теперь уже каменный топор. Да, именно так. Я еще забыл сказать, что вы эти три кубометра камня носили в карманах, пока шли от пещеры к своему верстаку. А может и больше. Ведь деревянной киркой можно не один десяток кубометров камня отрезать. Всего, при желании, вы можете переносить, по-моему, 4*10 стеков по 64 кубометра камня. 2560 кубометров камня в карманах! Если это гранит, вы способны носить в карманах 6656 тонн гранита. Нет, я все понимаю, иначе было бы очень сложно и неинтересно, наверное. Но, вообще-то, такое не очень хочется повторять один в один, хотя это офигенно играбельно.
Да, еще. Если взять бревно и обжарить его в печке, вы получите древесный уголь, который ничем не хуже каменного, то есть горит так же прекрасно. И лучше, чем сами бревна. А если насадить уголь на палку, можно получить вечный факел. В Minecraft очень мало законов из реального мира, которые соблюдаются.
На самом деле многие вышеперечисленные вещи там правили с помощью хардкорных модов. Факелы, которые делались из пропитанных креозотом кусков шерсти. В Terrafirmacraft они со временем гасли. Кто-то даже пытался ограничить размер инвентаря. Но это все полумеры. Натягивать на полностью выдуманную вселенную реальные законы природы - неблагодарное занятие.

Про Coursera

Год у меня лежала где-то в списке "попробовать" идея посмотреть на Coursera. Наверняка, все уже посмотрели, что это, может даже взяли один-два курса и забили. Последние две недели я офигевал от того, насколько много разных курсов там есть. И первым взял Learning How To Learn, из которого кое-что, конечно же, подтвердило правильность моих подходов и я вынес немного новой информации о том, как получше учиться и не только. А потом я просто тыкал во все, что интересно. И вот, затрачивая всего около часа в день, я прошел курс Managing Your Money, который меня настойчиво пытался убедить, что кредиты это тоже хорошо, и что всем стоит подумать стать предпринимателями, затем курс тайм-менеджмента (Work Smarter, Not Harder), который ничего, в принципе, нового узнать не позволил, а затем и более сложный, но все-таки легкий Introduction To Communication Science, в котром я ожидал увидеть что-то про там, ну, сети, интернеты, но оказалось, что нет. И поэтому, наверное, курс был полезен как небольшое краткое вступление не то чтобы в передачу информации, а в то, как средства массовой информации могут воздействовать на свою аудиторию. В этом плане было полезно еще раз осмыслить, как чего происходит у нас прямо сегодня и еще раз подумать о том, как хорошо, что я не смотрю телевизор. Хотя, наверное, было бы полезно и в интернетах новости пореже читать. Но даже читая их, смотришь уже несколько трезвее. В общем, курс прикольный. Теперь мне попался курс про машинное обучение, но я только начал, и он, конечно же, посложнее предыдущих, в котром пока что все началось с того, что меня заставили поставить GNU Octave. Может пользоваться научат, а то я как-то больше умел из такого только немножко в Maple. Есть, конечно, еще десяток всяких других курсов, которые меня заинтересовали, но я решил не изучать больше двух за раз.
Конечно, забрать час в день из своего времени на получение знаний, которые не нужны прямо сейчас - не очень умная затея, и с этим надо что-то будет делать. Однако, я заметил, что бывает и так, что знание о существовании готовых методов впоследствии позволяют не изобретать колесо. В этом, в принципе, полезность любого учебного заведения, в том числе. Даже школы. То что на Coursera мне дали возможность выбрать интересные темы - это несомненный плюс. Параллельно радует незаметное дальнейшее прокачивание скилла восприятия английского на слух. Не радует, что изученные термины бывает непонятно как перевести на русский язык. То есть, смысл понятен, а сказать не получается. Но это у меня было еще когда я готовился к сертификациям от Cisco Systems.
Ну а что касается их сертификатов - не вижу смысла покупать их, так как никакой ценности кроме повешения на стену они не имеют. Так что для меня это "бесплатное обучение".

И снова про OpenGL

Пришло время снова поныть про OpenGL. Дело в том, что я никуда не продвинулся в своих попытках изображать что-то объемное, а тем более сферу. Потому что в OpenGL3 все стало намного более низкоуровневым и без каких-то дополнительных слоев абстракций это сущий ад. Если кто такого опыта не имел, поясню. Чтобы изобрать что-нибудь, нужно задать массив вершин треугольников, из которых будет это что-то изображено. Построили? Ну, понятно, это, в большинстве своем, школьная геометрия, хоть и в трехмерном пространстве. Далее вам нужно написать шейдерную программу. На языке шейдеров - GLSL. Это такой высокоуровневый язык, похожий на C. В этой программе вы будете объяснять видеокарте, что делать с массивами значений, которые вы ей скармливаете (и не всегда это могут быть координаты вершин). То есть, возможно, применять какие-то операции с матрицами, чтобы передвинуть объект, отобразить его в перспективе, то есть, не как что-то плоско спроецированное на экран, а сделать его проекцию с учетом того, что пространство уходит куда-то вдаль и там все становится меньше. Кроме того, шейдерные программы позволяют рисовать разными цветами, налеплять текстуры, делать всякую тесселяцию (т.е. сгладить угловато-треугольниковую поверхность) и т.п. Так вот без дополнительного слоя абстракции все сводится к тому, что это все нужно написать самостоятельно и так же самостоятельно загрузить куда нужно.
И здесь мне хочется остановиться и подумать. Стоит ли продлжать пытаться сделать это с Java и JOGL на таком низком уровне, изобретая собственный трехмерный движок, или, скажем, взять какую-то, возможно унылую и отсталую абстракцию вроде JMonkeyEngine или jOGRE, или вообще пойти на С++, где выбор намного шире. Вопрос, в общем-то, имел бы простой ответ, будь у меня в последние лет пять какой-то опыт написания приложений на С++, чтобы я хотя-бы имел представление о том, что нынче есть в стандартной библиотеке и распространенных вещах вроде того же Boost. Ведь с пониманием, какие структуры данных и абстракции уже есть в языке, писать что-то сложнее хелловорлда намного проще. Тут же, у C++, есть эта самая OGRE, которую мне почему-то советуют (но я еще не смотрел).
Впрочем, никто не мешает подсматривать в код других движков и писать что-то свое, заточенное именно под задачу шариков или кубиков. Но, вынужден сказать, что уже немного опускаются руки, и хочется вообще забить на эту идею. Однако она иногда не дает нормально спать, и это заставляет ковыряться дальше. Правда, ничего целостного насчет применения не вырисовывается, и, похоже, мне просто хочется проверить некоторые концептуальные идеи сначала, да, касательно кубических миров и возможного уровня их детализации без серьезных потерь производительности. Может и зря я заморочился при этом сразу с отображением в 3D на видеокарте, хотя с таким средством наглядной демонстрации было бы проще.
Прошу ли я совета? Не думаю. Все равно я достаточно упертый, чтобы попробовать и выбрать самостоятельно, не учитывая чужое мнение. :)

Про попытки изучать OpenGL снова

Пока выдались пара часов вчера вечером, засел за очередную задачу. Как вы помните, в прошлый раз я использовал LWJGL и нарисовал кружочек на белом фоне. Теперь мне хотелось как-то написать движение "камеры". Однако, с тех пор прошло много времени и я узнал, что, во-первых, то что я делал, это называлось Legacy OpenGL и так со времен появления OpenGL 3.0 уже не делают. Так что я начал искать новые источники знаний и примеров. А еще я попробовал использовать другую библиотеку - JOGL. К ней нашлось немало примеров "более современного" кода - https://github.com/elect86/modern-jogl-examples. Это набор примеров к книге "Learning Modern 3D Graphic Programming", и он уже точно использует новые инструкции API. А это, в том числе, шейдеры и их загрузка. В общем, кружочки и шарики я пока не смог, но в общих чертах понять, как рисуется один белый треугольник на черном фоне из первого примера я уже понял и даже догадался, как сделать его розовым. Теперь интересным опытом будет переход все-таки к рисованию трехмерных объектов вроде пирамидок, движению камеры и накладыванию текстур и создания источников света. Зачем? Все-таки не уймусь, пока не смогу отображать рандомно генерированные множества планетарных систем. А что если научить их еще и "вращаться"? Добавить туда 2-Body гравитационные взаимодействия было еще веселее. Люди даже из этого умудрились сделать игрушку, например вот: http://universesandbox.com/2/. Правда, стоит, как по мне, непомерно много, так что я ее не пробовал сам и поиграл в нее по Youtube. Не то чтобы в ней нет кучи разных интересных возможностей, просто мне кажется, это не та игра, в которую можно играть долго и с удовольствием, как чуть более дешевые KSP или Minecraft.

Но это еще не всё. Пока я жаловался на тяжкую жизнь с OpenGL, мне вообще посоветовали, что лучше бы C++ изучать, тем более что современные его стандарты уже определяют улучшенный поиск утечек памяти и даже встроенную поддержку сборки мусора. Правда, для этого нужно даже от gcc пока отказываться и пользоваться clang. Всё это очень интересно и лежит далеко за пределами того, к чему я привык и чем давно пользуюсь. Ну, вроде как свежий воздух. Это, правда, не значит, что я начну страдать сразу от двух новых направлений - OpenGL и С++11. Все-таки, думаю, поразбираться в OpenGL можно и на Java. Все равно, когда мне говорят, что на С++ все будет "быстрее", я не всегда склонен в это верить. Я бы сказал, что все, скорее всего, будет просто "плавнее", без внезапных вмешательств сборщика мусора.

Не факт, что в итоге получится новый кубический движок для очередного клона Minecraft на C++, конечно, но в итоге я надеюсь в общих чертах понять, что можно делать с помощью всего этого, и, надеюсь, применять эти знания, в том числе, для создания чего-то полезного, например, на работе.

Гитарных страданий пост

Добрался я и до этой темы. Сначала про оборудование. Гитара самая что ни на есть обычная, дешевый Squier Affinity Stratocaster HSS, включенная самым обычным шнурком в самый обычный линейный вход встроенной звуковой карты Intel HD Audio, где ее с радостью слушает Jack 2. Этот же Jack играет потом звук в USB-свисток от беспроводной гарнитуры Logitech G930. И где-то между ними раньше был Rakarrack, это такая штука, чтобы добавлять гитарные эффекты. И это основная проблема.

Хамбакер через него не издает приятных звуков вообще. Это просто какой-то анальный рык, а не звук. Синглы - нормально. Из того, что более-менее внятно звучит, я нашел только один готовый пресет, который называется Big Stack. И в нем только дисторшен, овердрайв, немного ревера и "кабинет" Mesa Boogie. В него можно играть ритм даже синглами и даже павер-аккорды звучат не противно на слух. Накрутить что-то свое у меня не получается от слова совсем.

Недавно услышал хорошие отзывы про альтернативу - Guitarix. Первые впечатления весьма отличные. Потыкал встроенные пресеты, High Gain Solo дает вообще отличный, тяжелый звук, и в нем даже можно хамбакер включить, можно играть, заглушая струны ладонью, ну, в общем, под тяжелое нормально должно быть. Однако, стоит какой-то аккорд зажать - получается какой-то странный пердеж. Еще и сустейна нет. Другие пресеты не так радуют, но в целом с дисторшеном можно что-то и потыкать, но... стоит попытаться поиграть под что-то в TuxGuitar и сразу заметно сильную разницу в тембре. Настолько, что "не звучит". Опять же, подкрутить что-то свое так и не вышло. Так что все еще играю под Rackarrack, там хоть звук привычный. Интересно, а там, под другими виндами и маками, так же страдают? Или там какие-то мега-крутые алгоритмы искажения звука, которые невозможно написать под этот наш Linux? Хотя я больше склоняюсь к тому, что руки не той системы и не из тех мест растут.

Да, еще у меня есть одинокая педалька овердрайва от Marshall. Но толку от нее в данный момент никакого нету. Покупать еще и комбик или еще педальку дисторшена мне пока не хочется совсем.

В общем, где-то надо искать внятное описание, что по чем и какого эффекта позволяет добиться. Одно радует - можно записать чистый звук и гонять его через эффекты, пытаясь что-то подбирать. Наверное, этим и займусь сегодня. Видимо, описание проблемы вызывает вал идей по ее решению еще до того, как задашь вопрос. :)

Про опыты с продуктивностью.

В конце прошлой недели стал замечать, что как-то вот не успевается все делать в нужном ритме. Ну, то есть, на самом-то деле все было хорошо, только казалось, что надо иногда уделять чуть больше времени какому-то из занятий, так как оно начинает отставать. Подумал, что надо просто удваивать число утренних "тайм-слотов" для какого-то вида из четырех (у меня это работа/обучение/проекты/дисциплина) и выбирать его первым на одну неделю. И вот на этой неделе попробовал "удвоить" время на проекты. То есть, проснувшись и сделав всякие утренние мелочи, я садился и делал одну задачу из своих личных проектов в течение 2-х часов.
Но результат удивил. Почему-то именно эти самые проекты я и не успел продвинуть как следует. Даже пришлось отложить выход очередной серии летсплея. Я пропускал написание постов в блог. И оказалось, что потрачено на проекты времени не больше, чем на прошлой неделе (хотя, в этом еще одна причина - меня вынуждали раньше ложиться спать). Тот час, что я урвал в начале дня просто исчез в его конце.
Вчера я пытался это анализировать, и нашел у себя довольно-таки частую, как мне кажется, ошибку. Во-первых я выбирал не ту задачу, которая была наверху списка, когда начинал работу. Во-вторых, даже если бы я выбирал именно ее, я бы не мог ее никогда завершить, потому что она повторяется после завершения, ведь это выпуск новой серии. :) В общем, на следующей неделе я попробую оставить механизм со сменой фокуса в начале дня, но попробую в начале тайм-слота выполнять первую задачу из списка, а потом, спустя один подход переключаться на следующую и т.д. Главное тут не забыть, что не всегда переключение имеет позитивный эффект, и, вообще, если заниматься при этом чем-то вроде кодинга, например, продуктивность упадет, так как обычно требуется много времени, чтобы снова понять, где остановилось решение задачи и как оно, в принципе, задумывалось.

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

Про Perl, продолжение

Ну что, я дописал до того места, где оно уже рисует картиночки. Но работы там еще много. Несмотря на это я не утерпел выложить это на GitHub, пропиарить тут и еще немного написать всякого текста про это дело.

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

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






Пример картинки, правда, показывает, что где-то в поиске связей между никами есть ошибки, это раз. Во-вторых, он показывает, что модуль GD::Simple плохо работает с юникодом. Я еще заметил модуль Imager, нужно будет проверить, как там дела. Он, вроде-бы и больше возможностей дает, наверняка можно будет делать связи между нодами полупрозрачными, чтобы не мешать чтению ников. Также требуется улучшить поиск связей между никами, так как в данный момент он просто проверяет наличие прямых упоминаний.

Про Perl

Я тут взялся писать маленький скрипт, который казался простым, ну, чтобы можно было пропарсить уже готовый лог IRC и построить на его основе картинку с диаграммой, на которой будет нарисован социальный граф. Есть штуковина, написанная на Java, которая делает аналогичное, но это отдельный бот, и это, пожалуй, неудобно. Поэтому захотелось что-то свое, что просто будет читать и парсить лог и будет написана на чем-то, что чаще встречается на VPS.
Выбрал Perl, потому что когда-то на нем писал чуть более сложные, чем HelloWorld приложения. Попытался написать, и вот уже часов 12 убил в сумме, а все никак не выходит каменный цветок. А все потому что изначально сделал ряд ошибок. Все-таки, любая достаточно сложная задача все-таки требует плана решения, как это ни странно, и если попытаться сразу написать код, это не всегда получается сделать быстро. Так что я уже раза три написал и стер основную часть кода, так как не сразу понял, к чему на самом деле сводилась часть задачи, которую решает скрипт. А еще я совсем забыл, как пишутся программы без объектно-ориентированного подхода. Слишком привык за те несколько лет, когда писал только на Java (ну, все-таки иногда я писал и на Perl тоже, но обычно на это уходила пара рабочих дней и это было редко). Так что лучше бы я сначала написал какой-то понятный план со структурами данных, которые нужны для этого скрипта, может быть, и быстрее получилось бы.
Теперь уже, чтобы ускорить возню с ним, приходится пользоваться исходниками PieSpy, но уже в части рисования готовой картинки. Но я так полагаю, что получив конечный результат, придется еще некоторое время поковыряться, собственно, в парсинге и составлении социального графа.
Есть ряд сложностей, которые, наверное, у PieSpy вообще не возникают. Например, бот сразу имеет список ников на IRC канале. Чтобы из лога его узнать, нужно его распарсить полностью, чтобы потом можно было искать упоминания этих ников в текстах сообщений (для чего его нужно распарсить уже второй раз). Следующей проблемой становится то, что ники могут меняться. Причем, хорошо еще, если они просто меняются на какой-то новый ник постоянно, можно просто сохранить историю и использовать список. Проблема появилась на этапе складывания информации о нике из списка его "псевдонимов", когда такая очевидная вещь, что меняться ник может и на какой-то из старых (зацикливая цепочку), от меня ускользнула.
Ну и еще одной неприятностью стало то, что на вспоминание ньюансов вроде хешей, ссылок на хеши и работу с ними ушло почти два или три подхода к кодингу. Зато теперь, вроде-бы, я и правда понимаю, что пишу. Но все-таки Perl в плане удобства программирования уступает даже Java, прежде всего отсутствием IDE для разработки, необходимостью постоянно вставлять разнообразные специальные последовательности символов, которые иногда визуально путаются ('}' и ')', например), кавычки, стрелочки, в общем, слишком много возни с клавиатурой выходит.
В процессе нашел забавный модуль, из которого даже сделали маленький ресурс - http://perlcritic.com/. Правда, я ожидал более жесткой матерной реакции на уровень "brutal". Еще бесит, что везде ссылаются на книжку Perl Best Practices, которую, в общем-то, нормальным людям положено купить, что некрасиво делать. Ну и где-то четверть придирок, по моему мнению, бывают неадекватны. Например, он будет постоянно требовать как можно скорее закрывать файлы, даже если между open и close оказывается только цикл для построчного чтения из него с достаточно длинным телом в 10-15 строк.
В общем, раньше я любил Perl для длинных скриптов, теперь стал любить меньше. Хотя лет 5 назад писал сугубо проприетарный набор скриптов для удобной работы с LDAP, вроде создания пользователей, групп и перемещения их туда и обратно по разным OU, и это довольно большой объем кода, строк эдак под 10К. Еще ради смеха писал блогодвижок на перле. В общем, опыт был. Только все это быстро забывается, и теперь уже, спустя годы, имея опыт работы с чем-то еще, смотришь на это уже не так, как раньше. Так что, наверное, полезно бывает и уйти от любимого инструмента на время и посмотреть на что-то другое. Отрезвляет.

О средствах инвентаризации и учета адресов для сетевых инженеров

О средствах инвентаризации и учета адресов для сетевых инженеров

Так как там, где я работаю, есть достаточно большое множество разных хостов и управляемых свичей с десятками сабнетов, вланов, портов, у нас остро стоит необходимость где-то держать описание всего состояния - ну там, какие адреса заняты и что куда подключено. Какое-то время назад у нас даже была самописная ерунда для этих целей, но ее как-то надоело поддерживать и мы искали куда переехать. Переехали на OpenNOC, это такая вроде-бы классная штука, которая даже умеет автоматически что-то там обнаруживаеть, но вот вчера захотелось того, чего там нет.
В общем-то, от нее сначала был экстаз - ее можно пустить сходить на сервера, свичи, собрать всю информацию там и внести в базу данных. Экстаз немного приутих, когда оказалось, что для этого ей непременно хочется иметь права для администрирования. А позволять какой-то чужой штуке в буквальном смысле управлять настройками мы пока совсем не готовы и предпочли бы делать это руками. Хотелось только возможности собирать информацию про интерфейсы, подключения, адреса, в общем, все что нам и так руками нужно было туда вносить. Это, конечно, решается небольшими правками кода, но все-таки грустно, что разработчики про это не думают.

Ну и о том, чего там очень нехватает. Дело в том, что у нас довольно часто применяются кросс-коннекты с другими организациями, и их тоже нужно как-то там описывать. И не всегда это "пиринг по BGP". То есть, эта штука хорошо работает для провайдеров интернета, у которых все на BGP и завязано. В то время как всякие финансовые институции, к которым обычно подключаемся мы, чаще всего вообще используют либо VLAN с выделенными нам адресами, либо статические маршруты, еще реже - какой-то IGP. Иногда даже RIP. И это нам тоже хотелось бы иметь в этой документации. То есть, куда, в какие порты свичей приходят кабели от этих ребят, какого типа у нас "пиринг", какой пиринг-сабнет, если есть, или там, по какому VLAN мы с ними сообщаемся.

В общем, такого, как оказалось, там нет. Конечно, как всегда есть два выхода - например, написать свой модуль с тем, что нужно нам. Или второй - найти то, что умеет все то же самое, но еще и хотя-бы физический ID подключения (по мнению датацентра), порты, и, собственно, кто с другой стороны (организация, контакты), в чем есть сомнения, так как наши задачи, похоже, очень специфичны. Третий - вообще забить и держать все отдельно. И вот сижу я и думаю думу по этому поводу. Собственно, от такой системы нам нужно немного, всего лишь:

• Инвентаризация оборудования, желательно с указанием физического размещения, хотя-бы на уровне Датацентр/ID стойки. Ну вроде что за железка, ось, версия, и кто ее владелец.
• Инвентаризация виртуальных машин, опционально.
• Учет VLAN, подсетей, сетевых портов свичей и прочего оборудования. Занятых/свободных адресов, с привязкой к интерфейсам на оборудовании/виртуальных машинах.
• Собственно, учет кросс-коннектов, хотя-бы на уровне физического места подключения кабеля.

Вроде-бы все просто, а найти что-то оказалось не так просто. Хотя делал я это пару лет назад, может чего теперь появилось нового. Нужно повторить.
Имел ли кто опыт с OpenNOC и написанием своих модулей для него? Или может пользуется чем-то, что похоже на то, что мне подходит?

Про (само)обучение

В тестовом режиме, чтобы понять возможности Coursera, взял там курс Learning How To Learn ради интереса. Узнал не то чтобы очень много нового, но какая-то ясная картина по поводу многих ранее известных вещей начала складываться. Там даже проблема прокрастинации освещается. И есть кое-какие интересные выводы. Все, наверное, знают, что многие занимаются подготовкой к экзамену в последний день, например. Так вот, даже если в таком случае удается сдать экзамен, знания эти, скорее всего, забудутся и пропадут гораздо быстрее, чем если бы мы готовились постепенно и очень долго, так как в этом случае мы постоянно вспоминали бы материал с перерывами в много часов или дней. Что позитивно влияет на запоминание. Так что метод последнего дня, пожалуй, весьма хорош для бесполезных с вашей точки зрения знаний, но не подойдет для того, что кажется полезным.
Хотя тут, конечно, тут можно и подискутировать, ведь тема "нужных" и "ненужных" знаний весьма неоднозначна. Конечно, многие вещи легко можно вспомнить с помощью гугла и их не обязательно запоминать. Но есть один такой фактор, как память о методах решения какой-то задачи или о каких-то исторических фактах. Скажем, вам подворачивается задача, которую вы можете решить путем изобретения способа с самого начала (что иногда, конечно, дает неожиданный результат) или вообще простым методом грубой силы. А можно вспомнить когда-то изученный метод, теорему или что-то вроде того, и получить решение намного быстрее и эффективнее, даже если придется вспомнить суть с помощью того же гугла. Такие вот дела. Но это, скорее, касается студентов, кем большинство читателей уже не является.

В курсе даже упоминается способ преодоления прокрастинации, которым я пользуюсь, то есть Pomodoro. Но есть и еще один часто забываемый метод для борьбы с ним - чаще всего негативные эмоции вызывает тот факт, что задача, над которой нужно работать, очень нескоро будет завершена. Так вот, в таком случае, чаще помогает забыть о необходимости результата концентрация на самом процессе. Это может уменьшить негативные эмоции, связанные с началом работы, а в процессе они и вовсе, как правило, пропадают. Ну и постепенный прогресс все равно приведет задачу к завершению.

Кстати, там прокрастинация не зря упоминается, так как регулярные занятия имеют ключевое значение для изучения материала, а прокрастинация мешает это делать регулярно.

Ну и к чему мне вообще учиться учиться? Не знаю почему, но мне кажется, что прекращать учиться не стоит, особенно если в свое время это сделать не удалось. Ведь и навыки для обучения тоже могут атрофироваться и их будет сложно вернуть, а возможность быстро сменить специализацию сегодня бывает важной. Тем более для работников в сфере информационных технологий, где за год-другой может появиться совершенно новый инструмент/язык программирования/технология, владение которым влияет на полезность, как сотрудника. Ну и требования рабочих проектов тоже нередко заставляют изучать что-то новое. Мог бы я раньше, работая эникеем, предположить, что мне вдруг понадобится работать с Java, Hadoop, протоколами обмена финансовой информацией, например? Или маршрутизировать мультикаст? Не думаю. И сегодня я тоже не знаю, что окажется нужным мне завтра. Так что необходимость постоянного (само)обучения сама собой объяснима.

Ну и еще я следую заветам бабушки - "Те, що знаєш, за плечіма не носиш".

Проблемы игровых миров и их моделирования с точки зрения дилетанта

Еще одной темой, которая меня волнует в сфере генераций мира для игры, это картина его целостности. Вот взять случайно сгенерированный бесконечный мир Minecraft - в лучшем случае, существует мод, который позволяет как-то разместить на нем "климатические" пояса, то есть, скажем, есть экватор, полный сухих пустынь, из которых, двигаясь на юг или север можно попасть в тропики, умеренные широты, затем тундры и, наконец, в заснеженные места. И потом - в обратном порядке. Если такой мир замкнуть, появится полное ощущение движения по сферической планете. Это полностью соответствует ожиданиям. Однако.
У мира всегда есть история. Когда-то на нем могла быть весьма бурная геологическая жизнь с вулканами, были какие-то места обитания древних существ, где они умерли и как-то их следы должны находиться. В подходе с полной случайностью это обычно проявляется в виде плавно размазанных по миру древних шахт и сокровищниц, каких-то, таких же случайных, пещер и все такое прочее. Мне это не очень нравится, потому что "целостность" пропадает. Было бы куда интереснее находить заброшенные деревни, рядом с которыми можно найти следы деятельности жителей в виде тех же шахт и т.п.
В этом смысле интресно выделяется, как наиболее яркий пример, Dwarf Fortress, где случайно сгенерированный мир перед, собственно, игрой, длительное время переживает в ускоренном темпе какой-то исторический процесс. Появляются и исчезают цивилизации, народы, цари и герои, свидетельства о которых оказываются закопаны где-то в глубинах в виде древних легендарных артефактов, руин старых городов и такого прочего. И практически никогда у вас не будет двух одинаковых историй. Это по-своему интересно, но ставит сложный вопрос - как не генерировать весь мир полностью, и в то же время создать для него последовательную и целостную историю, которая может быть получена путем изучения мира? И, конечно, просто поставить вопрос, не пытаясь ответить на него, я не могу :)
Во-первых, можно пытаться сделать вид, что история была, но создать только ее конечные результаты. Скажем, изначально вписать в некоторые переменные для всего мира его возраст и уровень, до которого что-то там развилось и умерло. Можно там же создать и записать функцию, которая сможет вычислить распределение останков этого прошлого в чанках/кубиках этого мира и потом генерировать чанки, как это и предполагается - только там, где кто-то на это смотрит.
Второй вариант - это повторить DwarfFortress, но если детализовать это до уровня каждого мелкого блока, ваш сгенерированный мир превратится в многотерабайтный ужас для вашего жесткого диска. Это, как по мне, совсем не круто.
Ну и третий вариант это нечто смешанное. Мне давно приходит на ум, что любители писать игры в мир из кубиков могли бы сделать его более динамичным и интересным, не рассматривая его только на уровне "блоков" и "загруженный/выгруженный чанк - как набор блоков". Я имею в виду, что можно постепенно, по мере удаления от наблюдателя, уменьшать детализацию мира. Ведь, по сути, кусок 2х2х2 блока есть сущность, которая состоит из 8 блоков, и, при правильном подходе, наверняка можно смоделировать процессы внутри более крупных "блоков" так, чтобы при обратном преобразовании в отдельные части создавалась иллюзия правдоподобности процессов. По мере удаления можно сжимать эти "двублоковые" блоки дальше, вплоть до уровня чанков, 2х2-чанков и т.п. И, наверняка, на таком уровне можно даже моделировать какие-то процессы глобального уровня, не загружая каждый чанк в память для рассчетов, а только представления этих групп. И кто-то мне уже подсказывал, что для вокселей есть какой-то такой алгоритм, который работает примерно так же. Для теста этой концепции, конечно же, надо было бы сначала написать такой себе маленький кубический движок и найти пример такого процесса, чтобы оценить производительность. Да, кстати, это могло бы позволить обеспечить очень широкую область видимости не вызывая загрузку в x^2 большего количества чанков/блоков целиком, просто чтобы нарисовать их. Ведь давно применяется метод уменьшения детализации с расстоянием, почему бы и тут не поступать так? :) Мне даже кажется, что для проверки концепта не нужно даже писать рендерер, можно ограничиться простейшей моделью без всякой визуализации, чем и собираюсь заняться в ближайшее свободное время.

Про OpenGL

Как я упомянул в предыдущем посте, хочется изобразить летающие шарики в объемном виде. Для этого вчера я попытался нарисовать всего один шарик с помощью lwjgl 2, у меня получилось, я изобразил красное пятно на белом фоне, но на это у меня ушла пара часов. В связи с чем есть кое-какие вопросы.
Во-первых, стало ясно, что просто так, с наскоку, OpenGL использовать не получится. Мне очень не хочется писать код, собирая в гугле кусочки какой-то работающей фигни, но не понимая, что она делает. А экспериментировать путем вписывания других значений не очень выходит, потому что результаты бывают совсем интуитивно-непонятные. Так что хотел бы спросить совета, если кто имел опыт, чего бы такого хорошего почитать, чтобы понять побольше, и чтобы не про старые версии OpenGL. Потому как я уже где-то нашел, что с версии 3.0 все стало как-то немного иначе.
Во-вторых, у меня теперь есть большой вопрос, на чем писать. В принципе, для Java есть несколько реализаций биндингов OpenGL: JOGL, LWJGL2, LWJGL3, который использует JGLFW. От этого уже начинает плавиться мозг, но похоже современнее всего из них LWJGL3, который, правда, еще не зарелизился. Есть другой вариант - забить на Java и для полнейшего прогружения мозга в новую среду писать на С++, чтобы можно было совсем уж заниматься тем, что в языках с управляемой памятью делать не получится (ну, для шариков это не обязательно, но для кубиков может понадобиться). Правда, на C++ я не писал уже давно, и писал раньше максимум хелловорлды.
Ну и в третьих, если остаться на Java, то стоит ли этот самый LWJGL3 уже использовать... или JOGL внезапно лучше, судя по его описаниям?
Кстати есть один плюс в Java для опенсорца - если такое писать, то зависимости, как правило, не приходится качать руками, если использовать Maven, который умеет затянуть все сам. А вот как с инфраструктурой для C++, которая давала бы такие возможности, как maven - уже непонятно.

Относительно прошлого поста и перевода цветовой температуры в RGB, получился такой вот код: https://gist.github.com/stasikos/06b02d18f570fc1eaa9f. Там есть маленький тест, который генерит картинку с разной температурой, результат кажется мне адекватным, так что спасибо тому чуваку за его полиномы. :)

Кончился очередной сумасшедший день, в котором все наложилось и сбило обычные ритмы. Неправильное обещание выпускать серии летсплея в определенные дни, наверное, сказалось. Как только подошло время заливать серию на Youtube, стало весело. Сначала провайдер приказал "наши специалисты уже работают над исправлением проблемы, ждите", а потом появилось жгучее желание поднять еще один сервис по работе прям щас. Параллельно кое-кто решил, что его взломали и требовал внимания к собственной персоне. В общем, дурдом.
Вчерашний вечер внезапно посвятил исследованию проблемы генерирования планетарных систем, которые бы вменяемо выглядели. Я давно начал этим заниматься, так что просто дорабатывал вещи, которые были сугубо случайными. А, как говорится, случайные числа появляются там, где мы чего-то не знаем. Вот я решил узнать.