Valery Blazhnov

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

Между прочим, диаметр кабеля ЛЭП - порядка 50 мм. Прикиньте в уме массу одного такого провода между мачтами ЛЭП и сравните с массой самолета. Кабель-то, возможно, и порвется, но самолету мало не покажется.

А я о чем? Точную расстановку объектов лучше делать прямо в 3D и не заморачиваться точностью карты и условными знаками. Зачем привлекать картографический интерфейс, чтобы затем искусственными приемами преодолевать его ограниченные возможности? Если я правильно уловил суть сообщений разработчиков, то генерация объектов в симуляторе, в принципе, может производиться по мере их появления в редакторе, а не только при запуске миссии. Следовательно, их можно увидеть не только на карте, но и на местности в 3D еще на стадии планирования. Простейший инструментарий перемещения объектов - и вопрос расстановки наземки будет решен гораздо более удобным для пользователя способом. Мы же можем сейчас перемещать камеру относительно местности или объекта. Следовательно, теми же методами можно двигать объект относительно местности или камеры. Карта специально генерализуется, чтобы отвлечься от мелких деталей, она нужна для схематичного планирования, а не для точной установки объектов на местности.

Куда информативнее чего - неориентированного условного знака или трехмерного изображения? Или изображение типа Google map, но в 3D и с любой степенью приближения, по информативности не дотягивает?

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

Давненько тебя не было. По личным вопросам пиши в личку.

Мэтт Вагнер - американец.

Логика просматривается в многозначительной приписке: "ВВС США дали согласие..." В этом контексте несущественные мелочи отходят на второй план :) Если отношения с военно-промышленными кругами налаживаются, то стабильность фирмы укрепляется, а это хорошо для всех заинтересованных лиц.

Всему свое время. У приличных пацанов уже геометрические шейдеры работают, так что не все так безнадежно.

Замечено, что симуляторы все больше не разрабатываются, а вынашиваются. Оно и правильно, потому что руками у нас все гораздо хуже получается :)

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

Визуализация в этом деле, конечно, важна, спору нет. Но реальные подвижки произойдут только тогда, когда прикладные программисты "заболеют" физикой атмосферных явлений. До недавних пор все силы уходили на моделирование техники и вооружения, что вполне можно понять. Однако, на каждом новом этапе развития AFM вопросам взаимодействия со средой придается все большее значение. А редактор - дело вторичное, он под возможности моделей затачивается.

Если бы такие вещи могли делать умельцы, то сеть была бы забита разнообразными симуляторами. Такую штуку качественно на коленке не сделаешь. По поводу кустарных поделок на тему динамической кампании разговоров было много, делали даже макеты, но всякий раз приходили у выводу, что овчинка выделки не стоит. А по-хорошему IMHO сделать могут только в ED, потому что настоящая ДК тесно связана с внутренней организацией и поведением моделируемых объектов. В ED за последние годы пришло много заинтересованных вирпилов, многие из них хотят реализации ДК не меньше вашего. Но ни у кого пока сил на это не хватает. Пусть ED сначала сделает хотя бы триггеры, это послужит хорошим начальным шагом в направлении ДК. Кстати, а при чем здесь погода? ;)

Для тех, кто никогда не пытался получить деньги от военных, может быть, и очевиден :) На самом деле, не все так просто, как кажется со стороны.

Все зависит от того, откуда придет больше денег.

Ты ED и MS приравниваешь? Ну-ну, не кипятись так сильно только, маркетолог ты наш :)

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

Если бы моделирование зависело от FPS, то треки никогда не сходились бы, а поведение объектов менялось бы от переключения камер.

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

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

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

IMHO все такие штучки нужно делать опциональными.

Прочитал пару популярных книжек и уже дорос до тривиальных советов разработчикам графических движков? Не рановато ли?

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

Ну, это уже не ко мне :)