Однажды у меня была книга про трехмерную графику на Basic, и всё бы ничего, если бы не одна интересная глава в книге. В ней рассказывалось о том, как сделать так, чтобы линии, которые рисовались, могли скрываться за другими выпуклыми фигурами. Это оставило впечатление на меня, и я до сих пор не могу понять, как это сделать.
Если разобраться, то процесс сокрытия линий в целом простой. Допустим, нам надо провести трехмерную линию и проверить, где и в какой точке она будет отрезаться лежащим перед ней объектом. Для этого надо проверить все пересечения линии всех объектов.
То есть, если взять линию, то надо просмотреть все грани фигур на трехмерной сцене и сравнить. Могут быть следующие случаи.

• Один конец линии начинается за гранью и заканчивается тоже за гранью. Такую линию вообще не выводить
• Первая точка линии начинается перед гранью, а вторая за гранью. Необходимо отрезать линию в том месте, где она пересекает грань. И закончить на этом.
• Первая точка линии начинается перед гранью, вторая тоже, и причем обе точки пересекли эту грань. Надо найти точки пересечения грани, после чего найти срединную точку и проверить, где она находится. Если она находится перед гранью, то тогда линия выводится без обрезки. Если за гранью, то вырезается кусок линии в точке пересечения.

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

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

Целый день я провел, работая над внутренним обновлением механизмов редактирования статей на сайте и остался очень доволен результатом своей работы. Эти обновления, на самом деле, надо было делать очень давно, но мне было жутко лень и я ничего не делал. И вот, наконец-то, когда немного разгрузился с работой, принялся за свой сайт.
У меня много идей, которые стоят того, чтобы их реализовать, и в частности, из-за неудобства работы с контентом, их было реализовать не так легко. Надеюсь что сейчас работа над сайтом пойдет более активно.

В течении десятка лет мое отношение к любым праздникам портилось и вот наконец, добралось и до нового года. Я окончательно перестал радоваться абсолютно всему. Больше в моей жизни нет ничего, кроме беспросветной тоски, страха и тревоги. Я больше не буду отмечать новый год хоть как-нибудь, разве что только негативно. Больше его не существует. Ничего больше нет, все растворилось и растаяло, словно дым.
ВСЁ ПЛОХО
Вот потому я ничего и не буду делать. Да, я делаю сайт постепенно. Появилась регистрация на сайте, теперь задача в том чтобы сделать личный кабинет, добавить "избранное" на статьи, чтобы можно было отмечать те, которые можно потом посмотреть в личном кабинете.
Также можно придумать систему оповещений внутри сайта, например, личные сообщения между участниками или еще сделать напоминалки, чтобы приходили сообщения.

Никто не знает, но я начинал свою жизнь программиста именно с Бейсика. Сначала это был GW-BASIC, потом QBasic 4.5. Всего диалектов бейсика было лишь два в моей жизни, но этот период оставил неизгладимый след, ведь на Бейсике я писал до 19 лет, исключая ассемблер, конечно. На нем я научился писать тоже не так уж поздно, а достаточно рано.
Сейчас мне интересно заниматься разработкой различных процессоров на плисе, но Бейсик так и не уходит из моих мыслей. Часто думаю над темой, вот бы сделать бейсик, который бы выполнялся на ПЛИС, пусть даже с помощью компиляции. В своей жизни я еще ни разу не делал интерпретатор "Бейсик" и это довольно большое упущение, особенно с тем, что мне этот язык программирования нравится, как ностальгическая память и не очень. На нем удобно иногда подсчитать несложные формулы.
На самом деле, даже сейчас я иногда пишу на бейсике.

Суть в чем. Есть уравнение Гуkа: Fs = -kx, которое гласит, что чем сильнее ты натягиваешь сову на глоб... то есть, чем дальше оттягиваешь резину (хватит тянуть резину, давай уже!), тем больше сила, с которой пытается эта сила оттянуться по полной. Ну, до разумного предела, конечно же.
Итак, вот у нас есть некая сила, которая оттягивает. По уравнению Ньютона, F=ma, как известно, так что уравнение можно переписать так: ma = -kx. Это значит, что a = -kx/m. То есть, мы знаем, с каким ускорением пытается оттянуть обратно пружина.
Что такое ускорение? Это , и если взять за отсчет t=1, то в таком случае будет , то есть, .
Находясь на позиции x, и имея уже определенную скорость V, к этой скорости добавляется еще V + a, или V - kx/m, если так. То есть, по этому уравнению, происходит замедление скорости в обратную сторону. Чтобы рассчитать, где в следующую секунду будет маятник, надо лишь добавить x' = x + V. Вот и всё!
И получается гармоническое колебание, причем здесь не учтено еще трение воздуха, например, и трение самой пружины, так что колебание получится просто в виде не затухающей синусоиды.

Вчера я задумался насчет 3Д графики и понял, что если не сделать тени, то в таком случае графика будет слишком неинтересной и пресной. Но как сделать тени? Этот вопрос мучает меня до сих пор в очень огромных масштабах.
В графических программах основным строительным блоком является треугольник, и он должен отбрасывать тень на другие треугольники, если они там есть. Есть множество различных способов высчитывать тень, но я хочу рассмотреть пока что одну из самых для меня доступных для понимания.
Допустим, что есть только 3 объекта на сцене: источник света L, треугольник A (который отбрасывает тень) и второй треугольник B (на который отбрасывается тень). Сама по себе тень образует некий треугольный конус, в который может полностью, частично или вообще не попасть треугольник, на который эта тень отбрасывается.

Задача в том, чтобы проверить, попадает ли тень на второй треугольник. Для этого надо провести из точки L через каждую точку треугольника A прямую и проверить, где именно на плоскости треугольника B попадет эта прямая. Если треугольник лежит параллельно этой прямой, то это значит что эта прямая, собственно, нигде треугольник не пересечет.
По итогу получится что-то вроде проекции на плоскость, где лежит треугольник B. Это значит, что от трехмерных координат мы переходим к двухмерным, что дает возможность определить область попадания тени на треугольник B.

Вот тут конечно, начинается самое интересное. Как видно, проекция тени A1'A2'A3' пересекла треугольник B в двух местах, раздробив изначально простые треугольнки на большое количество составляющих.

• Раздробилась сама проекция тени, образовав дочерние теневые треугольники 1,2 и 3
• А также раздробился исходный треугольник, разделившись на две группы — 4 и 5 (там где легла тень) и 6,7,8 там где тени нет

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

В 2000-м году я впервые увидел Спектрум, и не простой, а то ли Пентагон-128 с музыкальным чипом, то ли еще какая его модификация. Спектрум выглядел как обычный компьютер, с дисководом, настольный, прямо почти что копия 386, но только спектрум. У него были колонки, которые проигрывали шикарную музыку, и конечно же, на нем была запущена та самая, Elite.
Увидев эту игру, я конечно же, был удивлен. Для меня это можно сказать, это было еще одно прикосновение к 3D-графике в том пространстве и времени. Естественно я постарался ее повторить, и даже кое-что смог сделать на компьютере, который был там рядом, то был 386 комп, и я напрограммировал там некое подобие разлетающихся звезд так, как я думал, что это работает, то есть они летели с разной скоростью просто из центра экрана. Да, в 12 лет мало чего получилось бы у меня напрограммировать толкового, не имея особенного доступа к компьютеру.
Чуть позже, на другом компьютере и тоже 386, я постарался повторить эту игру как сумел. Получилось что-то очень глючное, но в то же время, я даже смог немного поиграть и полетать в космосе, на графике, основанной даже не на 3Д, потому что в тот момент я не знал о трехмерной проекции. Да, конечно на Бейсике, да еще и на тормозном компе, было убого, но всё же, оно было.
А сейчас я даже не могу сделать того же самого. Ну и дела, я скажу.

Мне кажется, что нарисовать трехмерный куб, это просто классическая задача, которая точно так же как и Hello World, начинается и заканчивается на этом. То есть, это задача-максимум, нарисовать трехмерный куб и на этом завершить программу. Больше от трехмерных программ ничего не надо. Только куб.
Я не умею больше ничего делать, только рисовать кубы, иногда без текстур, иногда с текстурами. Больше чем куб, мне не нарисовать никогда. Да даже его нарисовать сложно. А почему кстати, я не могу нарисовать что-то посложнее куда? Потому что у меня нет инструментов и трехмерного редактора, чтобы можно было какую-то геометрию посложнее куба сделать. А почему у меня нет такого редактора? Вопрос простой — мне лень делать.
Куб — это всё, на что я способен вообще в принципе. Кажется, я совершенно разучился что-либо делать, разленился, и у меня нет абсолютно никаких идей. Всё так надоело, вообще.
Поэтому надо нарисовать куб прямо срочно. Прямо вот сейчас взять и нарисовать какой-нибудь куб. Того требует время.

SCREEN 13

LINE (50, 75)-(150, 175), , B
LINE (50, 75)-(75, 50)
LINE (75, 50)-(175, 50)
LINE (175, 50)-(150, 75)
LINE (175, 50)-(175, 150)
LINE (175, 150)-(150, 175)

LOCATE 4, 8: PRINT "Cube of Your Dream"

Этот куб был начертан за непродолжительное время в 5 минут.
320x