Форум » Моделинг » Берега, берега ... » Ответить
Берега, берега ...
Esin: Ход действий русско-японской войны протекал в основном не в далеке от побережья и японская сторона, а также ВОК, совершали набеговые операции на побережье противника. В связи с чем возник вопрос, который и выношу на обсуждение - будем ли мы моделировать сушу - Порт-Артур, Владивосток и пр.? Что до меня, то я потихоньку собираю уроки о моделировании различных ландшафтов, населенных пунктов, растительности, а также провел поиск карт П-А и Владивостока. Кое что удалось найти и пока лежит мертвым грузом. Прошу высказаться на эту тему.
Naumov: Интересно получилось! Ты масштаб соблюдал? А то в западный бассейн у меня только один Пересвет влез. С горами надо что-то делать, тигриный пов имее низкую часть на перешейке и достаточно высок в остальной части. Тут придется ориентироваться по фоткам.
Esin: На перешейке вертексы можно поднять. А высоту по фотографиям не сделаешь! Как делался масштаб напишу завтра - не помню до какой точки мерялось расстояние от г.Высокой. И источник этой информации.
Esin: Имевшаяся схема Порт-Артура привязывалась следующим образом: В сборнике "Порт-Артур. Воспоминания участников" (ссылка), в главе "Высокая" (автор офицер 5 всп Б.Н. Третьяков) есть следующая фраза: Это была та гора Высокая (иностранцы ее называли Высотой 203 метра), — тактический ключ крепости, с вершины которой вся Артурская гавань со всеми ее портовыми сооружениями была видна, как на ладони. Лежала эта высота в одной версте к северо-западу от передовых люнетов укрепления № 4, и от вершины ее до Морского госпиталя на набережной Нового города в Артуре не было и трех верст. На плоскости с картой П-А расстояние от Высокой до люнета Новый - 1000 м. К сожалению, нормальной карты не нашлось и другой привязки по местности не было.
Flashasa: немного для информации (на модели не проверял): в одной русской версте 1.067 км "шатровые" горы, конечно, придется делать более сглаженно - вряд ли они были чисто пирамидальной формы
Esin: Flashasa пишет: "шатровые" горы, конечно, придется делать более сглаженно - вряд ли они были чисто пирамидальной формы Согласен. Дайте топографию!!!
SII: А я тут долго и нудно думал над картами (стратегическими, так сказать: мне не требуется трёхмерный вид, потому что работаю над свосем другой задачей) и пришёл к банальному выводу: растровая графика не годится, с ней жутко много геморроя с масштабированием (нужно несколько наборов карт -- от всей Земли на одной и до уж не знаю какого масштаба -- в одном пикселе один метр, грубо говоря :) ), что будет весить очень много, да и вообще неудобно. Отседова мораль: карты надо делать в векторном виде. Для интереса попробовал что-нить сделать в Maya -- всё получилось. Для этого я делал замкнутые кривые, соответствующие высотам или глубинам (при необходимости на них можно наложить поверхности -- и сразу готова трёхмерная модель рельефа). Экспорт осуществлял в формат DXF, поскольку он официально описан разработчиком (Autodesk). В дальнейшем полученную карту можно загрузить в игрушку и на её основе рисовать что плоскую карту, что трёхмерную модель местности. Проблема только одна: создать эти карты :)
Esin: Это и Макс позволяет. SII пишет: Для этого я делал замкнутые кривые, соответствующие высотам или глубинам (при необходимости на них можно наложить поверхности -- и сразу готова трёхмерная модель рельефа). Я точно также делал обсуждавшуюся здесь карту. Текстура - битмап любого размера. У меня пока трудности с топографией и картографией Ляодунского полуострова. Катастрофически не хватает информации. Всё что было сделано - делалось по схемам.
SII: Esin пишет: Я точно также делал обсуждавшуюся здесь карту. Текстура - битмап любого размера Ну, мне текстуры вообще как зайцу стоп-сигнал, потому что мне нужны плоские карты, фактически физические. Но, как я говорил, одно в другое легко преобразуется, потому что вся геометрическая информация есть в наличии. Esin пишет: У меня пока трудности с топографией и картографией Ляодунского полуострова. Катастрофически не хватает информации. Всё что было сделано - делалось по схемам Чую, что это будет одна из двух главных картографических проблем. Может, у кого есть какие-нибудь лоции и всё такое? Ну или у знакомых?.. Кстати, если Вам не сложно, не могли бы Вы экспортировать получившуюся модель побережья в DXF и мне на мыло скинуть? Чтобы мне не сочинять для себя тестовую карту, а работать с уже имеющейся...
Naumov: Рисоваться карта в движке будет по точкам, а вот информацию хранить придется в приблизительно растровом файле.
Esin: SII пишет: Кстати, если Вам не сложно, не могли бы Вы экспортировать получившуюся модель побережья в DXF и мне на мыло скинуть? Чтобы мне не сочинять для себя тестовую карту, а работать с уже имеющейся... Завтра отправлю её Вам. Только она действительно тестовая, т.к. имеются проблемы с масштабом, что видно из рендера Егора. Кстати, появилась мысль как уменьшить полигоны на карте. Руки дойдут попробую проверить свою мысль. 8-)
SII: Naumov пишет: Рисоваться карта в движке будет по точкам, а вот информацию хранить придется в приблизительно растровом файле Ну, я пришёл к выводу, что хранить надо как раз в векторном виде и выводить карту, просчитывая её математически. Растровый формат не только займёт многократно больше места, но ещё и крайне неудобным при масштабировании и т.п. окажется
Esin: SII пишет: Кстати, если Вам не сложно, не могли бы Вы экспортировать получившуюся модель побережья в DXF и мне на мыло скинуть? Отправил, смотрите почту.
SII: Esin Спасибо, получил. Будем посмотреть.
Naumov: SII пишет: Растровый формат не только займёт многократно больше места, но ещё и крайне неудобным при масштабировании и т.п. окажется Приветствую Александр. Откуда такие сведения насчет разницы в размерах? Один пиксел передает три координаты, а вектор три координаты своего местоположения + три координаты своего направления.
SII: Naumov пишет: Приветствую Александр. Откуда такие сведения насчет разницы в размерах? Один пиксел передает три координаты, а вектор три координаты своего местоположения + три координаты своего направления. А сколько пикселов потребуется? ;) Нужно по пикселу на каждую "клеточку" моря и суши. А вектор, кстати, -- это совсем другое. Даже математический вектор не "хранит" своё местоположение, он задаёт исключительно направление. Ну а векторный формат хранит координаты неких ключевых точек, по которым математически постраиваются все остальные. Возьмите те же кривые Безье -- это ж как раз чистая математика.
Naumov: Пикселами мы задаем высоту в каждом квадрате, а дальше по этим высотам уже выстраивается сетка. Кривые Безье к игре неприменимы, в виду большой траты машинного времени :-)
SII: Naumov пишет: Пикселами мы задаем высоту в каждом квадрате, а дальше по этим высотам уже выстраивается сетка А вы посчитайте, сколько этих квадратов нужно. Мне, например, требуется максимальный масштаб порядка метра -- десяти метров на пиксел. Сколько уйдёт, чтобы описать хотя бы район действий РЯВ, не говоря уже о всей Земле? ;) Naumov пишет: Кривые Безье к игре неприменимы, в виду большой траты машинного времени Очень даже применимы. Во-первых, для отображения (именно отображения, а не хранения всей карты в целом) рельефа (а водные массивы, в т.ч. моря -- это тоже рельеф, только с отрицательными высотами и наличием воды) требуются не миллионы и даже не тысячи кривых, а обычно пара десятков -- обсчитать их проблемы не составляет даже не на гиперсуперпупермегапентиумах. Во-вторых, вычислительные мощности растут, и треугольники будут постепенно уходить в прошлое (особенно с учётом того, что визуализация хорошо поддаётся распараллеливанию -- вот где простор для многопроцессорных машин). Естественно, это длительный процесс, и пока перевести всё на кривые Безье не удастся, но часть элементов сцены -- вполне.
Naumov: Хотелось бы посмотреть на пример кода с Безье для игры ;-) Хотя сплайны вроде используют.
SII: Naumov пишет: Хотелось бы посмотреть на пример кода с Безье для игры ;-) Хотя сплайны вроде используют Есть надежда, что увидите ;) Во всяком случае, для отрисовки местности в морской игрушке это мне представляется куда более разумным, чем рисовать её треугольниками (это ж не шутер, где игрок видит всё у себя под носом). А вот модели кораблей придётся, конечно, треугольниками делать -- там слишком большое число кривых нужно, чтобы качественно всё изобразить, и просчитывать замучаешься. Кстати, мне кажется (пока утверждать не буду -- детально не думал), что основное время будет пожирать расчёт освещённости и т.п. вещей, а не собственно отрисовка геометрии... Кстати, ещё такой вопрос, про который нередко забывают: расход оперативной памяти. Дело не в том, влезет модель в неё или нет (сейчас объёмы ОЗУ такие, что забить их проблематично), а в том, что скорость обмена между процессором и памятью во много раз меньше, чем скорость обработки данных процессором. Поэтому модель размером, грубо говоря, 100 килобайт процессор обработает в 1000 раз быстрее, чем модель в 1 мегабайт. Поэтому может оказаться, что обсчитывать кривые реально быстрее, чем туеву кучу треугольников. В общем, пожуём -- увидим.
Naumov: Тут нужно иметь примеры кода перед глазами, чтобы представить себе быстродействие проги. Проекция кривой Безье на экран - это обсчет каждого пиксела по сложной формуле, так что, быстродействия тут не предвидется, хотя в частных случаях возможно и применимо :-)
полная версия страницы