ВанёХ писал(а):
Прослеживая работу твоего генератора обнаружил что в расчетном листе изначально все клетки пустые. Может я чего то недопонимаю, но думаю лучше изначатьно значение всех ячеек поставить на 0.
Для Ехселя пустая клетка - всё равно что 0. Нет разницы.
ВанёХ писал(а):
Иногда замена значений идет в уже отредактированной области, т.е. была цепочка гор высотой в 7, стала одна большая гора высотой в 12.
Да, наложения гор друг на друга - обычное явление. Но я не думаю, что это как-то отрицательно сказывается на результате. Но если одна цепь пытается пересечь другую - она принудительно обрывается (введено ещё с v.2.0).
ВанёХ писал(а):
Совет на будующее - пустые пространства между горами заполнять впадинами, пропастями и руслами рек, чтобы вышел настоящий В.М.
Да, в дальнейшем планирую (если лень не пересилит
) ввести новую опцию - полную рандомизацию рельефа путём сложения полученной карты гор с рандомной картой (такого же размера), но небольшими перепадами высот. Таким образом, плоские участки будут заполнены. Ну а что касается ручейков, рек и даже озёр - есть кой-какие глобальные задумки насчёт их реалистичной постройки на карте (по тому принципу, как это происходит в природе
), но это будет не скоро, бо проще сделать вулканы, что я и собираюсь реализовать в версии 4.0, которая пока только в задумках и не далее.
ВанёХ писал(а):
Ты уже и так все сделал, отсалось заменить положительные значения на отрицательные (если конечно Exel поддерживает отрицательные значения).
Поверь, нет предела совершенству - было бы желание (пока есть
). А насчёт отрицательных значений - Ехсель может всё (ну, почти...
), но
зачем отрицательные значения? К тому же на 3D-графике это будет выглядеть также.
Хотя, если в дальнейшем за 0 будет принят уровень моря, т.е. отрицательные значения = подводные территории, то возможно. Но как писал выше - это далеко потом.
ВанёХ писал(а):
Если ты собираешься воплощать АГР в чем то момощнее екселя, следует продумать такую вещь, как автоматический накладыватель текстур.
Неправильная формулировка задачи.
Цель работы моего А.Г.Р. - только составление цифровой карты высот. Синий убогий 3D-график нужен лишь для того, чтобы визуально контролировать результат. Продукт А.Г.Р.-а - та матрица цисел, что появляется в конце на "Расчётном листе". Возможно, вторым продуком будет также ещё одна карта, хранящая данные не о высотах рельефа, а о его особенностях (в этой точке вода, тут вулкан и т.п.). А о текстурах и др. графических фичах - пусть заботятся разработчики, если, конечно, моя работа достигнет такого уровня, чтобы их заинтересовать, но до этого ещё далеко.
smt005 писал(а):
А на С++ ни "бум бум".
Ты ж грозился умениями 3D воротить?!
smt005 писал(а):
Зачётно получилось.
Но всё равно я нашёл, что улучшить.
Вот
А.Г.Р. v.3.1 (646 kb)-усовершенствован принцип построения вторичных цепей (раньше все вторичные цепи начинались строго перпендикулярно направлению главной цепи (и сливались), но щас изначально расходятся веером с настраиваемыми характеристиками).
smt005 писал(а):
Описание алгоритма построения гор есть в этой теме?
Нет. Он постоянно совершенствуется и расширяется, но могу расписать текущий принцип его работы.
В версии 2.0, А.Г.Р. строил только главные цепи, поэтому получалось примитивно-однообразно. Сейчас же, от каждой горы главной цепи строятся ещё и несколько "побочных".
Это если в общем и в двух словах.
Ну а если интересен сам технический процесс, то это до-о-ольше. Лень писать, так что отмечу только самые важные моменты.
Что касается основы - постройки отдельной горы (модуль 3, "Rounder"):
1) выбирается точка карты - вершина горы с заданной высотой.
2) для всех точек квадрата, центром которого является вершина горы, просчитывается их высота, в результате чего получаются склоны. Это распишу поподробнее.
-берётся каждая точка квадрата, и высчитывается её радиус (расстояние до центра квадрата, т.е. до вершины будущей горы);
[-если радиус точки слишком велик, то высота для неё просто не просчитывается];
-высота точки зависит от её отдалённости от пика горы и высчитывается по особой сверхсекретной меганавороченной суперформуле, в основе которой лежит функция "косинус".
Меганавороченность этой функции определяется кучей всунутых в неё констант (см. настройки), используемых для укрощения косинуса
. Так уж и быть, открою Вам тайную формулу
, если это что-то даст:
[Высота точки] = (Cos(
(([Радиус] / [Выс.Ц.Точки]) ^ [ОстротаПика]
) / [Полог.Склона] * 3.1416) + 1) * ([Выс.Ц.Точки] / 2)
Что касается ведения цепи гор: сначала определяются характеристики цепи:
-количество гор в цепи,
-пологость гор цепи,
-максимальный угол изменения направления распространения цепи после каждой новой горы;
-координаты первой горы,
-начальное направление распространения цепи.
Высоты гор цепи определяются по не очень навороченной синусоиде (это не очень важно).
Сперва ставится первая гора. Вторая гора ставится в зависимости от начального угла распространения цепи, и после этого угол распространения цепи немного меняется (на рандомный угол из определённого в настройках интервала). И так до конца цепи. Получается извилистая цепь.
Отмечу, что "идеальная высота" горы перед тем, как будет поставлена на карту, корректируется рандомом.
Обращу внимание на некоторые хитрости работы А.Г.Р.:
-если цепь натыкается на другую, она принудительно обрывается (иначе выглядит так, что цепи гор подлезают одна под другую; а кто себе представляет, как образуются горы в природе, поймёт, почему так быть не может
).
-значение высоты вводится в ячейку только если превышает её текущее значение.
Вообще, если интересно, то лучше загляните в макросы - там я все действия снабдил понятными пояснениями на нашем языке.
Тем более, я уже сам подзабыл многое, с чего начинал
, да и вообще, слишком долго это всё разжёвывать.
Короче, не парьтесь - я далеко-о-о не один час парился над всем этим, так что в двух словах доступно всё объяснить не смогу.
Но если есть конкретный вопрос - пожалуйста.
Лучше б с С++ помогли, а не военную тайну раскрыть просили.