Я в одиночку 3D не потяну. По крайней мере на том уровне, где я сейчас. Тут надо быть реалистом. :/

Ну я вот помочь могу. У меня как раз период дипрессии (мана в минусе). smt005 может, тоже потроллить поможет, SHW посоветует, где свет в конце туннеля искать - разберёмся, не ссы. :) У меня реальне куча примочек для OpenGL, шейдеров, и всякой векторной геометрии понаписана. Описан удобно оформленный класс для создания OpenGL окна - бери и юзай; для функций OpenGL есть простой хеадер с автозагружающимися функциями вплоть до OpenGL 4.0 (не нужно расширения проверять - указатели всех функций-расширений в одном хеадере, и при первом запуске каждая самоинициализируется) - т.е. просто подключаешь один хеадер и все функции OpenGL у тя в кармане; для шейдеров (GLSL) тоже есть хеадер, грузящий шейдеры из файла; для геометрии есть хеадер-эмулятор GLSL, с описанными там классами векторов и ГЛСЛевских функций над ними (написанные причём в ассемблере).
Чувак, ну довай в 3D попробуйся, с моими библиотеками для чайников не много знать надо, чтоб глайд по экрану повалтузить. Есть в наличие как раз такой простенький проект для Вижуалки.
Кста, твоё железо OpenGL 3.3 поддерживает?

_________________
Сообщество креативных механоидов:
aim-fans.ru

В перспективе это было бы прекрасно, но сейчас я хочу закончить то, что начал.
У меня много идей, которые стоит воплотить, но 3D будет обузой. Задумка построена не на графике.
Продвину свой скилок - потом посмотрим. :]

Добавлено:
А у самого идеи есть? Что бы ты хотел сделать в 3D? Я имею ввиду, полноценный продукт. Недоделки сейчас мало кому интересны.

Карту размером с материк хоцца без подзагрузок во время полёта, онлайновство, физически реалистичная симуляция устройств глайда (грави-эффекторы, обеспечивающие векторное отталкивание).
Карта огромного размера уже частично реализована путём 8 уровней детализации: базовый фрагмент (уровень 0) имеет размерность 1024х1024 метра, второй уровень 2048х2048 метров... уровень 7 - 65.5км. Т.е. на диске каждый фрагмент карты высот имеет 1024х1024 вершины, но в зависимости от того, какой уровень приписан этому кусочку карты, расстояние между вершинами считается разным. Менеджер карты динамически управляет подгрузкой карт, держа в памяти лишь куски карты вокруг текущей позиции игрока (по 4 смежных куска для каждого уровня детализации). Если требуемый кусок карты отсутствует на диске, он генерируется из соответствующей части куска большего размера, так что не всю карту нужно прописывать в высокой детализации - лишь те фрагменты, где Игрок будет ошиваться. При смещении игрока на определённое расстояние (128м) менеджеру карты приходит запрос составить 8 custom-карт всех уровней детализации для данной позиции игрока и в видеопамять перезагружается пирожок из карт (8 карт 1024х1024 - 32Мб) из каждого уровня детализации - таким образом дальность видимости составляет 65км. Вершинный шейдер берёт из этой текстуры высоту вершины, так что покадрово ничего передавать видюхе не нужно.
Однако я пошёл дальше - я сделал возможность терраформинга: карту можно динамически менять, после чего модифицированный вариант перезаливается в видюху (по моим тестам, не тормозит, даже если это покадрово делать); а при запросе нового "пирожка" старый передаётся обратно менеджеру карты для апдэйта фрагментов карты.
Насчёт симуляции устройств глайда (особенно грави-эффекторов) пока лишь задумка. Типа, гравик - это такая фуфняшка на корпусе, создающая силу отталкивания, пропорциональную накачанной в гравик энергии и обратно пропрциональную квадрату расстояния до поверхности отталкивания. Т.е. теоретически - конус отталкивания, но на практике рассчитывается как луч - для каждого гравика высчитывается расстояние от него до поверхности - ландшафт, статический объектили другой глайд, и обоим объектам передаётся противоположно направленная в точках вз.-ия сила отталкивания. Каждый кадр точка вз.-ия пересчитывается, и если расстояние до неё увеличилось, значит гравик совершил работу (dA=F*ds), и потребил энергию из аккумулятора глайда. Если наоборот, расстояние уменьшилось, то гравик вернул энергию в аккумулятор. Уровень статически накачанной в гравик энергии определяет силу отталкивания - чем больше энергии накачать, тем сильнее отталкивание. Так, гравики, торчащие на корпусе в разные стороны, позволяют держать глайд в подвешенном состоянии, толкать глайд и вращать его. Менеджер гравиков перераспределяет накачку энергии в гравиках так, чтобы результирующая сила двигала глайд туда, куда желает игрок - например, если игрок хочет лететь вперёд, гравики на жопе глайда накачиваются сильнее. Если игрок ничё не жмёт, менеджер глайдера пытается балансировать гравики, чтобы результирующая сила на глайд была равна нулю (с учётом гравитации).
При разрушении отдельных гравиков глайд всё равно сможет летать, но некоторые действия станут ограничены. Например, при разрушении задних гравиков для полёта вперёд придётся наклонять нос в землю, чтобы толкаться вперёд гравиками на пузе. При этом высота полёта очевидно будет ниже. Симулятор же!

_________________
Сообщество креативных механоидов:
aim-fans.ru

Расскажу вкратце о моем проекте. (У меня, к слову, такое сейчас состояние, что болтать легко, а делать сложно. Сесть и запрогать что-то толковое хоть убей не могу.)
Задумка очень простая - небольшая группа ученых обживает Марс и сталкивается с внеземной наркоманией. Так начинается путешествие в новые глуби физики и сознания.
Чтобы руки не были связаны, я организовал очень общие классы, которыми легко манипулировать. Я могу создавать окошки, класть на них кнопки и назначать процедурки реагирования (окошки/кнопочки регистрируются для событий) парой строк кода, или создавать эти окошки с мировыми координатами, так что они являются юнитами. Внутри окна элементарно поместить еще одно, которое тоже можно перетаскивать. А самое главное - в рамках концепции это необходимо, потому что внеземная наркомания - не хухры-мухры.

Возвращаясь к твоему предложению.
Я бы с радостью поработал над ареной! ^_^
(Когда одно надоедает, можно взяться за другое!)
Во-первых, это целостная задумка, а такое проще и приятнее прогать (потому что можно потрогать :D).
Во-вторых, хорошей арены у нас так и нет.
В-третьих, арена предусматривает свежий подход к интерьеру. У нас нет карты высот, а в большинстве своем произвольной формы объекты. Будь то карта высот или нет, в любом случае необходимо иметь дело с объектами, и запрогать такое - отличный способ изучить и поупражняться.

Добавлено:
И еще, я бы попробовал сделать это БЕЗ всяких PhysX. Это не значит, однако, что не нужно прочитать тонны литературы о том, как это делается. :D

Добавлено:
Что насчет воксельного подхода в плане физики столкновений?
Кстати это же позволяет реализовать реалистичную систему повреждений и ее визуализацию.

А я хз насчёт вокселей. Точечные повреждения, думаю, можно реализовать просто - если модельку глайда составить из универсальных частей, то каждая такая часть может иметь свои хэлы, и этого вполне будет достаточно, имхо.
Я вот как думал насчёт структуры и конструирования глайдов. Пусть у нас будет набор функциональных элементов, из которых можно глайд составить: ну там балки и узлы для рамы, и слоты с пепяками. Узел - это типа такой как шарик, на котором сходятся балки (цилиндрические элементы, длина которых скалируется). Слот с устройством (реактор, гравик, аккум, ремонтная система, бустер, трюм, слот оружия, антенна, ЦП, камера и пр.) представляет собой абстрактную модельку с узлами в определённых точках - туда подводятся балки, тем самым делая пепяку частью конструкции глайда. Балка - не просто элемент рамы. Подразумевается, что внутри ещё и проходят информационные и силовые кабели, а также есть канал, в котором маршируют ремонтные наноботы от ремонтной системы к повреждённому органу глайда, так что ничё не болтается во внутреннем пространстве глайда. Т.е. грубо говоря, постройка глайда сводится к позиционированию пепяк в пространстве и соединению Узлов балками (тыкаешь один Узел, второй - и между ними протягивается балка). Разумеется, движок должен проверять, не пересекаются ли объекты, и все ли из них соединены в целостную конструкцию, прежде чем разрешать игроку юзать модель. Плюс некоторые пепяки (камеры, гравики, слоты оружия, трюм) требуют определённого открытого наружу пространства (расширение физической модельки) - это пространство должно быть свободно от прочих объектов глайда.
Ах, броня же ещё! Тоже есть простое решение. На торчащих из меша устройств и балок Узлах крепим маленькие штырьки - опорные столбики для крепления уголков листовой брони. Каждый такой столбик можно вертеть вокруг шарообразного Узла, выбирая, куда будет направлена нормаль к поверхности брони в данной точке. Затем щёлкаем по трём таким столбикам и между ними натягивается броня, изогнутая так, что в каждом углу её поверхность перпендикулярна стобику. Получается зализанный корпус из изогнутых треугольных сегментов.
Текстурка зависит от типа брони. Каждый такой треугольный участок брони имеет счётчик массы и температуру. Урон, наносимый броне, повышает температуру участка брони. Со временем она понижается, но если температура повышается выше критической и урон продолжает наносится, масса участка брони уменьшается (текстурка плавно изменяется на покоцаную). Чем меньше масса, тем быстрее повышается температура. Когда масса становится равной нулю, анимируется маленький пшик и разлетание осколков брони, после чего графическая и физическая модельки убитого участка брони убираются - броня этого участка больше не задерживает снаряды и они пролетают насквозь, коцая балки, Узлы и пепяки внутри глайда.
Броня восстанавливается нанороботами - при этом поглощается материал, который тоже нужно возить с собой в трюме. Типа, тараканы внутри балок ползают между трюмом и покоцаным сегментом брони и наплавляют микросварками чтоле материал, как осы улей строят. Во время ремонта броня разогревается, т.е. становится уязвимой - если сегмент получит урон, он сразу приведёт к снижению массы, а часть активных наноботов погибнет, т.е. скорость ремонта (наращивание ед. массы в минуту) снизится.
Ремонтная система управляет наноботами и имеет лимит на их количество. Наноботы - дорогие игрушки.
Насчёт камер. Для начала, неплохо было бы просто выбирать одну из камер, установленных на глайде, как источник картинки. Но как максимум, круто было бы поделить экран на части, в каждую из которых ренедерить вид из одной из камер глайда. Камеру мочат - картинка исчезает или переключается на ближайшую камеру глайда.
Таким образом получаем конструктор глайдов и симулятор глайдов с высоким коэффициентом реалистичность/сложность_реализации.

_________________
Сообщество креативных механоидов:
aim-fans.ru

Кроготе, вот привёл в боль-мень наглядный вид самый простенький вариант проги, что у меня нашёлся - рисует текст в 3D, Ястреба из .obj файла, позволяет двигать камеру и модельку:
MechEngine.rar.
Для скачивания файла тыкай на него и тогда в правом нижнем углу будет кнопочка download (сам еле разобрался, как качать с Гугель-Драйва). :)
Сначала погоняй ехе-шник, прежде чем в код лезть, а то может шок преждевременный случится. :) Ну, в смысле, букафф там дофига, правда половина из них - это комменты (я богато комментю, но на инглише, так что тряси меня на объяснения что там к чему).

_________________
Сообщество креативных механоидов:
aim-fans.ru

Интересный подход к созданию брони вы предлагаете. Я сейчас как раз думаю о переписывании своего редактора звездолётов для SE (видео тут). Хочу его расширить и обобщить для создания всяких разных транспортных средств. Попробую реализовать и вашу идею.

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

_________________
Your mind is software. Program it.
Your body is a shell. Change it.
Death is a disease. Cure it.

Синхронизация квазиментального поля 90%! И офигенский проект, божественно!
Я просто в стиле мехов мыслю - там можно просто условиться, что вся канализация внутри балок и проходит, так что приконнектенный к раме девайс сходу функционален. А проблема охлаждения (отвод тепла от девайсов в глубинах корпуса) решается читом мехофантастики, допустив существование какой-нить наноплёнки, конверсирующей тепло в электричество. Типа, девайсы ею кроют, чтобы и КПД повысить за счёт рекуперации и об охлаждении, соответственно, не париться. От этого и геймплею хорошо будет - поверхностные повреждения девайса рвут наноплёнку и отвод тепла снижается, заставляя драйвер девайса снижать мощность во избежание перегрева - т.е. перформанс покоцаного глайда снижается постепенно вместе с полоской хэлов.

_________________
Сообщество креативных механоидов:
aim-fans.ru

У мехов есть атмосфера, так что и охлаждать их проще обычными радиаторами, как автомобили. А уж турбореактивные двигатели итак охлаждаются потоком воздуха.
А по поводу наноплёнки - термодинамика негодует :-) . Любая тепловая машина работает на градиенте температур. А чтобы его создать, надо с одной стороны греть, а с другой - охлаждать.
Термоэлектрические элементы так и работают. С одной стороны нагреватель, с другой - охлаждение. Проходящее тепло вырабатывает электричество. Нельзя просто так взять и преобразовать тепло в электричество, второе начало термодинамики запрещает.

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

_________________
Your mind is software. Program it.
Your body is a shell. Change it.
Death is a disease. Cure it.

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

_________________
Сообщество креативных механоидов:
aim-fans.ru

Какая прелесть. Вот вам еще идейка.
Я тут размышлял над тем, что мне категорически не нравится поведение всевозможных самолетков в играх. Ну, разве что в DCS все вроде хорошо, у крафтов с AFM. Так вот, я решил попытаться придумать реалистичную и легкую в плане ресурсов модель поведения объекта произвольной формы при полете в атмосфере. Может, это не новость, конечно... Короче идея токова:
Во-первых, изначальный посыл такой - любое воздействие на любой объект можно разделить на две составляющих - сила, приложенная к центру масс объекта, и момент силы, приложенный туда же. Честно говоря, я не изучал детальней этот вопрос, может быть, это и неверный посыл, но на первый взгляд кажется, что так все в реале и может быть разложено.
Во-вторых, у нашего мега-симулятора есть две составляющие - сама симуляторно-геймплейная часть и отдельная "экспериментальная" часть.
Суть экспериментальной части в следующем: есть отдельная программа, условно назовем её "аэродинамическая труба", с очень реалистичной моделью аэродинамики. Так вот, модель из игры загружается в эту трубу, и там рассчитывается сила и момент, действующие на объект, повернутый некоторым образом к однородному потоку газа с некоторой скоростью. Эти расчеты повторяются много раз для разных ориентаций объекта и разных скоростей потока. На выходе мы получаем некоторую функцию от трех аргументов(трехмерный вектор задает ориентацию потока относительно объекта, длина этого вектора задает скорость потока), которая известна для некоторых значений своих аргументов. Значения можно организовать в виде трехмерного массива. Не имеет значения, как долго выполняются эти вычисления, т.к. для каждой модели они делаются только один раз.
В симуляторной части для объекта загружается эта рассчитанная матрица, и вычисляется сила и момент. Это должно происходить достаточно быстро, т.к. вектор скорости объекта относительно атмосферы известен, и вся сложность будет выбрать ближайшие к нему несколько векторов из матрицы, интерполировать их, и вуаля, - получим готовую силу и момент силы.
Точность симуляции можно сделать почти любой(зависит от количества элементов трехмерной матрицы, и их "плотности"), лишь бы была хороша точность модели аэродинамической трубы. Можно даже не использовать программу-трубу, если откуда-либо известны значения сил и моментов для данного объекта.

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

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

Разуме, ну слишком сложно же. Для убер-симулятора самолётиков, может, сие и будет единственным выходом, но если мыслить в направлении наших фантастических глайдов, предлагаю иначе. Глайд не летает в небесах, он огибает неровности ландшафта на высоте пары метров, поэтому скорость в пару сотен км/ч - это будет вапще предел, определённый скоростью реакции игрока и устройств глайда: небольшая ошибка пилота, ухаб на пути - глайд кувырком и вдребезги. Аэродинамика глайда - как у танка на воздушной подушке, т.е. это многотонный самосвал размером с Оку. Чтобы его в воздухе держать без антигравов, ему придётся прилепить крылья бессмысленного размера. С такой плотностью и инерцией управлять глайдом аэродинамически - как веслом титанику помогать. Так что достаточно умножать площадь лобовой проекции к потоку на универсальный коэффициент и на квадрат скорости воздуха, чтобы вычислить силу торможения воздухом.
Следуя таким измышлениям, убираем из списка меховских глайдовых девайсов двигатели - чтобы интерактивно маневрировать столькими тоннами металла, опираясь на воздух, нужны вентилляторы размером побольше самого глайда. Посему универсализируем модель приведения глайда в движение (ускорения, повороты, подвеска) - пусть все движения глайдер осуществляет посредством перебалансировки энергонакачки грави-эффекторов. Каждый из них статично закреплён на корпусе и светит своим "отталкивающим лучом" в поределённом направлении. Чем больше энергии накачано в гравик и чем меньше расстояние между гравиком и точкой отталкивания, тем сильнее отталкивание, вектор которого коллинеарен лучу. Таким образом при перемещении глайда каждый гравик, толкающий в направлении не перпендикулярном к движению глайда, совершает работу, а значит потребляет (или вырабатывает) энергию (dA=F*dS). Т.е. чем быстрее глайд летит, тем больше энергопотребление гравиков. Очевидно, как и у любого девайса, у гравиков есть предел мощности. Да и у реактора тоже. Это значит, что разогнав глайд выше некоторой скорости гравики станут толкать слабее (или энергия кончится). А сопротивление воздуха растёт пропорционально квадрату скорости. Так что чёткий предел максимальной скорости глайда будет. И в основном поведение нашего кирпича в воздухе на этом пределе скорости будет определяться геометрией расположения гравиков на корпусе и окружающего глайд рельефа, а не обтекаемостью корпуса.

_________________
Сообщество креативных механоидов:
aim-fans.ru

Пф, Разуме, вапще просто мой подход можно реализовать прям в реал-тайме. Ставим камеру носом по ветру, в ортогональной проекции, глайд в центре, в экран обязан помещаться полностью. Итак, мы знаем ширину и высоту проекции, т.е. общую площадь. Фон - нули. Рендерим глайд единичками. Получаем пиксели глайда - единички, остальные - нули. Допустим, мы юзали текстуру типа одноканального float-а, прикреплённую к фреймбуфферу, так что теперь вызываем для неё glGenerateMipmap(), и таким образом цвет последней мипмапы будет чем? Правильно, отношением лобовой площади глайда к общей площади экрана. Т.е. мы слегонца вычислили лобовую площадь глайда.
Но мы пойдём дальше! Теперь используем все 4 канала текстуры: единичный цвет теперь будет в 4-м канале, а в первые 3 пойдут 3 компонента векторов нормалек. Тогда результирующий вектор покажет нам среднестатистическую ориентацию плоскостей глайда к потоку, позволив вычислить дополнительно не только силу влоб, но и силу вбок/вверх. Так, клинообразный глайд будет прижимать к земле на большой скорости или подымать в воздух (в зависимости от ориентации). Но тут такой нюанс: отрываясь от земли, глайд теряет с ней сцепление, т.е. становится неуправляем, и толкающая сила становится минимальной. Так что для высоких скоростей на гравиках придётся сильнее жаться к поверхности, что лимитирует управление скоростью реакции игрока, т.е. высокая_скорость=опасно и пипец как стрёмно, ухаха!!! :)

_________________
Сообщество креативных механоидов:
aim-fans.ru

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

Вообще, моя система, наверно, больше подходит каким-то авиаигрушкам, но в упрощенном виде(небольшая матрица), вполне ок и для мехов. А зачем? А затем, что лично мне очень не нравится, что поведение глайдера очень нереалистично в М1-М2, там максимальная скорость зависит почему-то от массы, хотя должно от нее зависеть ускорение, а макс. скорость вообще с потолка берется.
Все-таки у нас футуристический симулятор, а не shoot-em-all. Кроме того, такая система лично мне бы очень пригрела душу разными реальными эффектами, типа изменения управляемости на разных скоростях, что, например, сделало бы осмысленным существование скоростных глайдеров(ну, типа, кирпичеобразная пиранья хорошо управляется на малых скоростях, а на больших - плохо, а какая-нето молния - наоборот), всякие милые вещи типа флаттера, появление подъемной силы, позволяющей разгрузить антиграв, смерть тактики жополетов, появление смысла в разных визуальных примочках на глайдерах, типа стабилизаторов и нижнего крыла на "Смерче".

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

Разум, тебе не кажется, что ты предлагаешь жутко сложное решение? Для такого расчета, как мне представляется, нужна заумная моделирующая программа, разработка которой займет у разработчиков в 10 раз больше времени, чем разработка самой игры, и которую можно будет отдельно продавать. Этим чуть ли не целые НИИ занимаются, а ты в игру хочешь это включить. По-моему, это не оправдано. Выход Шамана кажется гораздо более жизненным. Тем более, если эта игра с проекциями и нормалями поможет рассчитать подъемную/толкающую силу с какой-то долей реалистичности.

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

_________________
Тысячи часов поиска и все впустую.

Ой, да ладно, если есть хорошая модель газа(это проблема, да, по крайней мере для меня, я ничего лучше идеального газа из точечных частиц придумать не могу, но ее использоание не даст нужного эффекта, скорее всего), чего там такого суперсложного? Не нужно ни графики, ни звука, ни синхронизации, ни физики, ни даже интерфейса, только расчет одной-единственной модели. Не нужно даже особо над оптимизацией париться. Я даже больше скажу: можно даже вообще программы не делать. А отпечатать на 3D-принтере модели глайдера и продуть их!
И потом, НИИ не совсем это рассчитывают, они скорее рассчитывают конструкцию, там, прочность, нагрев. На этого не надо, нам нужны только силы.

Ну, Разум, если так хочешь модель симулятора, могу подсказать подход. Делишь объём своей виртуальной аэродинамической трубы на маленькие кубики. Все кубики, находящиеся внутри модели, исключаешь из рассчёта, работаешь только с теми, что снаружи модели. Итак, каждый кубик - это маленький объём газа. У всех одинакова температура, но количество газа в кубике и распределение давления на каждую из граней в каждый момент времени может быть различным. Соседние кубики могут обмениваться газом, чтобы уравнять давление (т.е. согласно модели, газ из кубика в кубик перемещается исключительно под действием разности давлений). Т.е. на каждую грань действует давление - это вектор. Суммируя все эти вектора получаем направление потока газа через данный кубик. Если газ перетекает из одного кубика в другой, то, по теореме Бернулли, давление на грани перпендикулярно-расположенных соседних кубиков уменьшается. Если эти соседние кубики принадлежат модели, то вот тебе вектор силы на кусочек модели. Набегающий поток симулируешь покадровой накачкой газа в слой передних кубиков и соответствующей откачкой такого же количества из слоя задних кубиков. После нескольких миллионов покадровых симуляций картина распределения давлений на грани всех кубиков станет статичной - результат симуляции готов.
Ну это всё упрощённо, без особо глубокого понимания мною законов гидродинамики, но как-то так это симулируется. В любом случае, каждая такая симуляция выжрет у тебя гиги памяти и загрузит все ядра на сутки.

_________________
Сообщество креативных механоидов:
aim-fans.ru

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

Я так понял, этот виртуальный газ может втекать в кубики, занятые моделью? Тогда можно сразу сказать, что твоя система даст рандомные результаты. Наличие объекта, через который газ пройти не может, сильно изменит течения газа, и распределение сил будет совсем не таким.

Кроме того, кубиков понадобится ну очень много. Например, для таких частей глайдера, как нижнее крыло у Смерча. Оно тонкое, и для того, чтобы нормально моделироваться, в нем должно укладываться хотя бы 3 слоя кубиков. Это многие миллионы кубиков на весь глайдер.
Выходом может быть переменный размер кубиков. Но это должно усложнить модель, т.к. их теперь нужно сопрягать.
Но все равно работать не будет по заявлению выше

_________________
Тысячи часов поиска и все впустую.

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

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

_________________
Сообщество креативных механоидов:
aim-fans.ru

Возвращаясь к моему проекту ...
Прошу прощения, что забил на него, но я кажется я потихоньку возвращась к работе.)
Называется он Mars 2D RPG, и это уже самостоятельный, непосредственно с Механоидами не связанный проект.
Движок остался на том же месте, что и в середине июня:
Клацнуть демку (v0.02)
На самом деле сделано больше, чем показано, но кого это волнует. Мне и не только предстоит дофига работы.

А пока что синопсис к самой игрушке, сегодня ночью накалякал.

А вот где будет начинаться игра:


Все, больше распространяться не буду.
Просто чтоб идею уловили.