Ждём Ваших отзывов о материале.
Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!

ну тогда Вы, как физик, и скажите нам свою точку зрения, и почему смешно


как раз щас пиши курсовую по интеллектуальной системе управления полетом там же нечетная логика используеться и нейросети, поэтому сранивать с компами(PC) вообще не в тему.

TyyOx91 В ней и держать.


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


Естественно. В более новом F-22 большинство задач как раз интегрировано в центральный блок. Остальные контроллеры гораздо слабее. Так, полагаю, в курсе, какие у него производительность и объем памяти?


Это только в игрушечном бизнесе любят из десятка бочек летающих супертехнологию городить и три видеокарты с четырехядерным камнем требовать...

Заверять не нужно, я с потолка программы не называю. И сложные модели из тысяч КЭ, где, как известно, сложность вычислений растет квадратично, никакому сравнению с банальными летающими цилиндрами не подлежат.
А вот работал Ансис очень задолго до всяких П4, и весьма успешно.


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

При желании же, такие вещи, как повреждение грунта в стратегиях, к примеру, существуют очень давно.

ArtAnd

Ну свою точку зрения (не вдаваясь в подробности) я приводил выше. А что именно вас интересует?

Потому что в студенческие годы самому приходилось считать физику на 486-х. Решение только одного дифференциального уровнения с частными производными по методу преобразования Фурье (с использованием оптимизированных библиотек FFT) занимало несколько минут. Ни о каком real-time речи не идёт.

Цитата:

там же нечетная логика используеться и нейросети, поэтому сранивать с компами(PC) вообще не в тему.

С PC можете не сравнивать, но это комп (компьютер) в полном смысле слова. Причём от PC далеко не ушёл так как имеет вполне стандартные компоненты (CPU, память и прочее). Да и сравнивались не архитектура, а вычислительные возможности.

Varg 'Euthanasiologist'

А все остальные манипуляции с обьектами (помимо физики) вы предлагаете на GPU проводить? Не забывайте - GPU это всего лишь узконаправленный ускоритель. Он может хорошо считать. И всё же, разработка каких нибудь, извиняюсь, "хитро-попых" алгоритмов для частных случаев какой нибудь банальной сортировки, чтобы достичь уровня производительности одноядерного Р4 - это удел академических исследований.

Вот-вот. Именно из-за "школьного" уровня физики и имеем, то что имеем - почти не-интерактивные игрушки с не-правдоподобной физикой.

Цитата:

В более новом F-22 большинство задач как раз интегрировано в центральный блок.

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

Тогда не понятно зачем вы приводили ANSYS - по сути ещё одно доказательство что качественную физику не возможно реализовать в real-time на 486-ом.

Вы что-то путаете. Именно для физики твёрдотельные модели не подойдут - они не "поддаются" деформации. Как раз таки для физики используются полигональные модели, так как хорошо ложатся под Finite Element Method.

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

TyyOx91 А нам не нужна сортировка уровня Р4, нечего там так сортировать. В том и дело, что задачи в неинтерактивной физике все простые и требуют лишь большого числа однообразных алгоритмов.

А с этим, как ни крути, 128 пусть и более медленных ядер справляются лучше двух.


Так данные об этом модуле не секретные. Наверняка там полно и резервных индивидуальных контроллеров, но >95% вычислительной мощности - именно этот блок.

Так вот, по производительности это примерно Пентиум 3.

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

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

Ну какое же натягивание текстур? Я про Earth 2150, где его копать можно. Вроде еще где-то реально образовывались ямы.
Физики в оном процессе мало, но изменение модели присутствует.

dSilver

Цитата:

Вот это и называется "не в одну корзину". в ЛА, думаю тож самое.

Естественно, этих модулей два, дублирующихся. И каждый из них многопроцессорен - разумеется, военные процессоров вроде П3 не используют, это они суммарно на него набирают, а каждый там и на Пентиум не тянет. С системой, устойчивой к частичному отказу лучше QNX. Есть 25% запас для расширения софта.
Пишу по данным в основном из открытых и полуоткрытых источников, ес-но, я не шпион в Локхиде.

Цитата:

Приведите пример ресурсоемких военных задач.

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

Цитата:

Может и его мощи будет лишко для требуемых задач....

В других самолетах то же самое, за исключением расчета аэродинамики, делают компьютеры куда слабее, часто уровня того самого 386.

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

Открытые и полуоткрытые источники никогда не скажут правды ни про наше ни про ваше...

Да... у аэродинамического крыла по коему строят США и бомбордировщики B-2 и Стелс нуждаются в управлении компьютером.
Но... эта задача для компутера, имхо, настолько простая, что её даже бессмысленно обсуждать. Стелсу не один 10 лет, и вычеслительные мощности тогда небыли такими как сечас.
Для сбора каждой конкретной задачи есть свои требования. И всё это далеко от нашего десктопа.
Всё... давно военщина с настольны не пересекается. Может ещё пересекется с распознованием звука, видео, отпечатков... и прочего.
А вообще, всю военщину абсолютно тупо осбуждать... мы тут некомпитентны ни на грамм... ламаки, лохи...
Только догадки... и прочее.
Давайте больлше в будущее и реальность смотреть

dSilver Правды про детальные характеристики и схемы не скажут, а такие вещи, как словесное описание структуры электроники, для шпиона бесполезное - выкладываются из гордости.

Ага, простая, то-то же для них все время приходится поработать над компьютерным блоком.
В-2 Спиритам как раз десяток лет, разработке побольше. Но, повторяю - никто не ставит в военные компьютеры П4, там процессорные модули своей разработки.

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

Очень неправильный подход, кстати. Лень здесь непричем. Невозможно на должном уровне повторить то, что целый НИИ делал годами в рамках бюджета одной игры. Отсюда идет вполне логичное следствие - использование чужих разработок и алгоритмов. Иногда они фактически являются частью какой-либо железки. Сюда как раз относятся вычисления физики на GPU и физикс. И лично я не против платить за эту железку если от нее виден толк. Особенно много толку видно когда технология "активная" - не требуется переписывать существующие игры для задействования большинства вкусностей.
Показателен как раз пример с "Sounds best on Nosound". Предлагаешь каждому разработчику все алгоритмы (зачастую защищенные вагонами патентов) напихать в собственный движок и выполнять на CPU? А 80386 потянет?

4e_alex
И проблемы здесь две.
Первая - то, что в модели тысяча параметров, а игра использует четыре или пять. Но обсчитываются индивидуально все.
Вторая - лень/экономия разработчиков того самого движка. Когда нет ни выбора сложности моделей (наподобие выбора типа конечного элемента в МКЭ), ни даже читаемой документации для игрового разработчика.

Не взлетит. Вводить фичи без ведома разработчиков - только портить игру, в большинстве случаев. С АА/АФ нормально, т.к. это чисто полировка, но не с физикой.

Подавляющее большинство сторонних движков не столь тупы.

Даже у халявных движков доки к SDK подчас насчитывают сотни страниц. А коммерческие лицензии предполагают раскрытие исходников под NDA и всяческий саппорт от создателей.

Отчего же не взлетит? Взять тотже хавок 2/3. В нем движение твердых тех и ragdoll явно есть куда улучшать, их физика ненатуральна. Притом здесь требуется только усложнить рассчет. Единственная преграда - либа хавока вшита внутрь, а не лежит отдельным файликом, который можно подменить. Но во-первых можно и патч самим разрабам сваять. Во-вторых это все временное явление пока нет общепринятого физического API.

Varg 'Euthanasiologist'

Ну как же нечего? А если у вас 10000 обьектов в сцене? Да и сортировку я привёл для примера - это не единственная операция CPU с игровыми обьектами. Я, кстати, так и не понял - вы что, действительно предлагаете переписать все игры (не только графику) под GPU?

Об этом и речь - разговор изначально вёлся об игровой физике и её низком качестве в нынешних играх.

dSilver

Цитата:

если Вы такой умный, почему Вы такой бедный?

Это к чему? Или вы по себе людей судите? Впрочем нет - первая часть вашей фразы (до запятой) похоже к вам не относится.

Цитата:

сорри если что... пиво дало в голову...

Вот-вот... идите проспитесь!

4e_alex Увы... сдается, что столь. Поскольку на экране результат трех формул, а ресурсов жрет несоразмерно. Хотя все равно небольшой процент от общего.

А когда какой-нибудь регдолл от сюжетного взрыва должен (как величайшее достижение игростроения) перелететь через ворота и сбить засов... но не делает это с натуральной физикой - игроку что делать?
Так что без ведома не взлетит.


TyyOx91

Эм... 10,000 значений - это будет, емнип, что-то около 100,000 операций (не пузырьком же сортировать). Что составляет менее миллисекунды на простом быстром RISC блоке.

В принципе даже из сегодняшних задач 95-98% можно переложить на GPU без проблем. Нет, не обязательно. Но имело бы смысл, для игр с высокими требованиями, создавать наконец многопоточную организацию. Многопоточная - это не 2 или 3 потока, а ровно столько, сколько проводится одновременных операций, 100, 1000 или 10000. Для цисков комбинировать в последовательные блоки, для GPU отправлять потоками.
Собственно, примерно так с самого начала и пишется любое реально требовательное приложение.


Которое связано исключительно с отсутствием нужного кода, а вовсе не с нехваткой железа.

Varg 'Euthanasiologist'

Большинство типичных алгоритмов поиска на GPU не возможно реализовать из-за отсутствия indirect write в память (тривиальной операции для любого CPU). Вроде бы читал где-то про достаточно быструю реализацию Radix sort для GPU (на уровне Р4 3.0Ггц для 7900GTX) для каких-то локальных случаев да и то с кучей различных ограничений. Не один вменяемый програмист с этим париться не будет.


Да только GPU - это не "простой быстрый RISC". Там "миллисекунда", здесь "миллисекунда" - в результате "тормоз" . Способность GPU нормально считать физику всё ещё вызывает сомнения, а вы уже хотите на него весь рассчёт игры повесить.


Весьма голословное утверждение, имхо. Доказать приведённые цифры можете? Только не надо опять приводить рекламные проспекты NVidia/ATI. А так же F@H, который используя GPU ещё и на 80% грузит CPU, при том, что таки не понятно что быстрее E6600 отдельно или 1900XTX (с 80% загрузки E6600).


Не понял вас. Вы по прежнему настаиваете, что "нужный код" для игр с качеством физики сопоставимом с ANSYS можно написать под любое железо (включая 486)?

TyyOx91 А собственно игрушка от Ageia на что?

Ну тогда так - что нельзя переложить?
Графика - уже.
Физика - в стадии демок и разработки.
Иные взаимодействия - можно.

ИИ - сложно, но он сегодня настолько бетонный, что и не нужно.
Интерфейс - те самые остатки.
Что там у нас осталось?

Разумеется, не считая собственно процесса перекидки в память и на видеокарту, и прочей подгрузки.



На качество серьезных систем никто и не рассчитывает. То, в каком виде физика в играх сегодня - да, работа для 486, но никак не более.

а на чем потоки делать будем ? Вот есть такой язык - Erlang, как раз заточен на десятки и сотни тысяч потоков... На АТСах некоторых работает. Но совсем не заточен под числа и для игр бесполезен. Есть еще какой-то язык от Google... Держит умопомрачительное число потоков.... на ферме из сотен серверов, которых у обычного геймера не наблюдается.
Так на чем десятки тысяч потоков делать ? А если они еще и работать будут не по одному, а одновременно....

Кстати, делал я маленький схожий тест. Win2000, Celeron 3 850MHz. Соединяем COM-порты проводом, запускаем две программы и они через COM играют в пинг понг.
Первая отправляет сообщение и ждет в течении ХХ мсек ответа от второй. Вторая, соответствено, принимает сообщение и посылает ответ.
В течении XX мсек Windows должен успеть переключиться между двумя копиями программы и обратно, иначе первая не дожидается ответа и выдаёт ошибку таймаута.
XX >= 60 - гарантированный успех, практически 100%
XX <= 20 - гарантированный облом, меньше 1%
В промежутке - относительно плавное уменьшения процента ошибок.

Возможно что потоки в Windows переключаются гораздо проще и быстрее, чем 30мсек. Но едва ли намного - тут скорее все упирается в кванты (timeslices) планировщика. И сколько тебе будет нужно времени, чтобы 10 000 потоков получили управление, если переключение 300 раз в секунду ?

Arioch Это вопрос кодерский - сегодня вариантом для отправки на видеокарты является Cg, скажем.


Поэтому я и писал - для CISC комбинировать в блоки. Windows же изначально был надстройкой над клоном CP/M, только с заменой TSR на несколько лучшую форму. И хоть прогресс шел к многозадачности, но суть не перевернулась, даже Winnt - ОС одной задачи, в первую очередь. Поэтому ей нужно давать столько потоков, сколько есть ядер, а в них уже последовательно отправлять блоки. В идеале динамически распределять загрузку из микроблоков, более приземленный вариант - держать до 16 потоков, скажем.
Главное здесь не цифры, а архитектура. Если программу изначально строить с блоками, позволяющими разбивку на потоки, то и масштабируемость по многоядерникам, и, в перспективе, другим платформам и GPGPU у нее будет.

Varg 'Euthanasiologist'

А собственно при чем тогда GPU физика ?

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

А вот и нет. На GPU даже сейчас выполняют только тяжелые рутинные операции. Грубо говоря современные 3D-ускорители ускорителями 3D в полном смысле не являются. Они получают конечный набор полигонов и текстур, уже обрезанный для минимизации работы и пригодный для рендеринга только с данной точки, притом батчами, а не всю информацию о мире.

А пр ичем тут DOS ? Windos NT - это пoмесь Microsoft OS/2 и Digital Что-то-там, от RT-11 до VMS. И переносить на нее DOS-наследство странно.


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