master_li

Группа просто офигительная! Особенно прет Inside the Particle Storm. Кстати, к слову, ребята были в Москве год назад (18 декабря) и играли песню с последнего (на тот момент еще не вышедшего) альбома We Are The Void - Dream Oblivion. Зачетная вещь! PS. У меня со зрением проблемы или в названии темы опечатка? Видимо, именно из-за этого я создал дублирующую, ибо искал поиском =) Благо, администрация быстро подчистила, за что им спасибо!

На мой взгляд (частично повторю предыдущих ораторов) канализация в ИГ нужна как: 1) Место кемпинга особо элитных, столичных гоблинов 2) Средство для проникновения в чужие подвалы, дворцы и прочие Имперские библиотеки 3) Средство для побега из тюрьмы 4) Средство для обратного проникновения в тюрьму с целью кого-нибудь проведать (например, Валена Дрета) 5) Место для кемпинга столичного вампира в светлое время суток (помните кровати в Затопленной канализации?) 6) Просто халявный дом для проходимцев 7) Резервуар потрясающе чистой для подобного места воды, очевидно, на случай осады

Я, честно говоря, тоже не совсем понял =/ И слово "пичалька" также мне неведомо.

Да. Редукция отрисовки графики под вайном не привязана к работе ГПУ в режиме D3D или OGL. Падение возникает на преобразовании D3D->OGL. Т.е., процессору нужно время, чтобы сконвертировать полигональный набор. Т.о., получаем, что чем больше ядер у процессора, тем больше потоков трансляции можно создать. Чем больше потоков создано, тем быстрее можно заполнять память ГПУ. Результат - больше фпс =)

Максимум. Отредактированный INI позволяет включить распараллеливание, которое, при грамотной настройке Direct3D->OpenGl пайпа освобождает несколько миллионов свободных тиков на ядро, что и позволяет получить ускорение, приравнивая FPS на лине к виндовым показателям, а иногда и обгоняя их. Но! В каждой бочке меда, известное дело, содержится деготь. В моем случае это торможения на системах частиц. И иногда довольно значительные Пока борюсь с этим. Получится - сделаю слив в гит. Еще одна неприятность - странные провалы в скорости преобразования при обработке нифок, открыто находящихся в ФС, а не запакованных в дерево БСА. Тут есть мысль глянуть в сторону локальной оптимизации File I/O, но руки не доходят. К тому же, баг очень непериодический, возникает хаотично, так что не сильно мешает.

Нет. 45-50 Но зависит от многих параметров. К тому же, я как программер, постоянно экспериментирую с механизмами ретрансляции полигональных наборов.

Господа! Поскольку пользуюсь исключительно никсами, в Облу играю под ними же. И при этом прекрасно играю. Если кого интересуют вопросы запуска - я являюсь супермэйнтейнером Обливиона на WineHQ AppDB. Вы можете с легкостью найти ответы на вопросы по запуску, а также тест-результаты ЗДЕСЬ

Возвращаясь к сабжу. Вот я набросал черновичек инструкции по эксплуатации лома модифицированного Автоматической Вычислительной Машины. Если кому не сложно - прочтите и покритикуйте, я более чем уверен, что многое упустил, на что уже "глаз замылен". Насчет разрушений. Я имею ввиду написание dll-плагина к OBSE, который, с учетом уже имеющихся nif-related плагов, будет создавать новые модели старых моделей =) Т.е., на вход он будет получать ссылку на файл объекта (nif-файл) и вектор удара. На выходе будет генерироваться совершенно уникальная новая модель, коя и будет замещать текущую. Тут вопрос только в том, как ее заместить в текущем CELL-е. Т.е., REFR "старый объект" надо перманентно заменять на новый генеренный REFR "разрушенный объект". Есть несколько идей (например, способность движка запоминать REFR в ess, если его параметры изменились, однако, так же есть способность через некоторое время все это терять), но нужны эксперименты. UPDATE Спасибо! Интерфейс у него в виде хорошо знакомых кнопок, пластинок и светящихся (или нет - в зависимости от состояния 0 или 1) велкиндских камней =)) UPDATE02 Вот сделал несколько снимочков интерфейса =) [IMG]http://s004.radikal.ru/i207/1012/4d/8793c7895019t.jpg[/img] А вот оно в режиме работы [IMG]http://s04.radikal.ru/i177/1012/e8/87e313a3b4abt.jpg[/img] [IMG]http://s007.radikal.ru/i300/1012/eb/11e158ab7f7et.jpg[/img] И (просто до кучи) - скрин из Лабиринта Хаоса. [IMG]http://s008.radikal.ru/i306/1012/7d/7562adee0473t.jpg[/img] cc10-descr-full.pdf.zip

MOC наверное, тут его никто не знает, но для меня, в свое время, он стал палочкой-выручалочкой.

Развертка - это лишь способ упрощенного представления расположения UVW-координат. Human readable, так сказать. Т.е., в чистой теории, без отсылки к специфике NetImmerse, каждый полигон имеет: 1) Набор вертексов 2) Вектор нормали 3) Набор координат текстуры (в нашем случае они двумерны, так что только U и V) 4) Дополнительные свойства (например, материал) Для ГПУ это выглядит так. Вопрос в том, как это обрабатывает движок Gamebryo. Тут надо экспериментировать. Почему фантомную? Создает оверрайд-модель. Текущая (дефолтная) удаляется, заменяясь на только что сгенерированную "подставную". Вполне осязаемую для физического движка. Причем, это не затронет другие экземпляры этой модели. Насколько мне известно, в файл сейва такое действие будет записано, потому что в ess-ы летят все координаты даже Static объектов, если эти самые координаты (либо одно из свойств, например Enabled) изменились.

1) В-основном, Aptosid x86 (rolling release), ранее известный как sidux. KDE 4.4.5. Другие машины под управлением PC-BSD и DarkRoseOS. 2) OpenOffice 3.2.1 К сожалению, на фряхе (точнее, на ее деривативе - PCBSD) ОБСЕ отказался нормально работать. На AppDB есть мой репорт на эту тему, если кому интересны подробности здесь. Вайн версии 1.2.1 (второй стабильный) работает просто на ура. В текущей девелоперской ветке иногда пробегают глюки, мешающие работе ОБСЕ. ОС от Майкрософт не пользуюсь. Не умею, не нравится, не привык, и она неоправданно дорогая.

Не совсем так. Идея заключается в очерчивании окружности в окрестности удара. Полигоны, попавшие в нее, подвергаются адаптивному разбиению с лимитом среденей площади. Далее, вертексы смещаются по вектору приложения усилия, при этом коэффициент искажения уменьшается с ростом расстояние от центра приложения силы по Гауссу. Это если посмотреть на проблему грубо. При более точном рассмотрении можно выделять локальные подпространтва, на которые будет распространяться удар, а не "тупо" смещать окрестность. Далее, расчитывается возможное пересечение сеток для выпуклых моделей. Что делать в случае засечения такого пересечения - еще вопрос, который надо обдумать. Вторая проблема, как правильно замечено - UV координаты. Решаемая, впрочем. Havok-связанная геометрия искажается соотв. образом. В первом приближении так. =)

Не в тему, просто вспомнил. Была еще давно идея реализовать искажаемое пространство - например, возможность вручную продолбить в скале пещеру, или, скажем, снести подпорку в подвале. Думаю теперь, при наличии OBSE, можно попробовать =) Как думаете, было бы полезно, или пустая трата времени?

Спасибо, сейчас напишу. Upd: Вот примерно такое описание получилось: Нормально получилось? Если это подходит, я могу завтра (26-го числа) написать инструкцию.

Если он может быть кому-то интересен, я всегда "за" =)