Больше всего понравился чайник.

>>4275
Сам балдею.

>win-only
>.rar
>.rar
>.rar
>.rar
>.rar
>.rar
>.rar
>.rar
>.rar
>.rar
>Пикрелейтед

А еще я могу только позавидовать твоему упорству, написать столько кода на непригодном для этого языке.

>>4277
Я ждал этого поста. :3
Кроссплатформ задумывался давно (видно по инклюдам), но мне лень его прикручивать, ибо вендоблядок. Платформ-специфик кода немного совсем, спасибо SDL+OpenGL.
Ну а фрипаскаль - язык богов.

>Пикрелейтед
ЧТО ЗА АДСКАЯ ВИДЯХА?
Хотя если запускал под вайном, то всё ок.

ОП молодец! Так держать и удачи тебе.
Дело в том, что я тоже давно пытаюсь сделать нечто подобное, но когда начинал было очень мало опыта, поэтому многие части сейчас перепроектирую и переписываю, и показать соответственно нечего.
Несколько вопросов к тебе:
1. Движок полностью свой?
2. Форматы моделей и текстур придумывал и загружал сам? Зачем тогда нужен devIL?
3. Откуда моделька и анимации суигинты?
4. Чтобы получился плавный переход между анимациями, они смешиваются? Уж очень неплохо движение получилось
5. Тени, на сколько понимаю, рендерятся в текстуру?
6. Не пробовал сделать территорию по карте высот? Тогда ее можно неплохо оптимизировать, ROAMом например

>>4282
Спасибо.
> перепроектирую и переписываю
Перманентно этим занимаюсь :3
Ну что ж, по порядку.

1. Да.

2. rawraw, rwbinmesh - свои, причём ориентированные на хранение данных в том же формате, что и в видеопамяти. Этим rawraw похож на DDS. DevIL загружает всё остальное; если нет PNG и проч., его можно отключить, но пока для этого нужна перекомпиляция.

3. Свои. Формата анимации пока нет, поэтому полёт и бег, о ужас, прописаны в Main. Поленился писать экспорт скиннинга из Collada (да и с весами костей в максовском Skin не до конца разобрался), в следующий раз не поленюсь. По этой же причине подбирал повороты [почти] вручную.

4. Анимация скелетная, кости поворачиваются кватернионами, так вот, для них придумали slerp, но с очень небольшой (<1°) погрешностью можно юзать тупую линейную интерполяцию. Получается взвешенная сумма нужных анимаций.

5. Да, как и отражения-преломления. Серьёзный недостаток - пикселизация тени увеличивается с увеличением расстояния от источника. PSM до сих пор не осилил. Для постпроцесса буду рендерить в текстуру вообще всё.

6. Нет... думаю обойтись столкновением сфера<->меш, а ландшафт разбивать на куски, скажем, 5x5 метров, для которых, как для обычных объектов, будут задействованы LOD'ы.

Генерация облаков (точнее, турбулентности на основе шума Перлина): дописать в scenario.rw
>texture {dims 512 512 generate turbulence scale 8 freq 8 save2bmp "noise.bmp"}

Фишка крузиса в "обычной" уже охуенной графике на ближних расстояниях и размытой на дальних, вместо тумана. Раньше запиливали просто туман на некотором расстоянии так что отдаённые объекты небыло видно или выкручивались по другому. А в крузисе это не нужно.

D:Temprr>main
rwDebug watches you
Words for random resource names: 2174
refl1: resolution changed to 256
5024 cdtrimeshes: 1.903 Mbytes
An unhandled exception occurred at $0148F878 :
EAssertionFailed : Some memory leaks by classes here: rest of allocatedByClasses is 7919, but must be 0. (rwObjects.pas, line 118)
$0148F878

Думал, намного лучше будет это всё.

Прикрутил постпроцесс.

>>4288
Без конфига ты Стив простой.

>>4296
Моя полагать, что дело в этом:
[000000000] Using OpenGL renderer
[000000539] Library "opengl32.dll" is loaded
[000000539] Loading OpenGL...
[000000539] glBindFramebuffer, glDeleteFramebuffers, glGenFramebuffers, glFramebufferTexture2D, glBindVertexArray, glDeleteVertexArrays, glGenVertexArrays, VAO (Vertex Array Objects) not supported! Replaced with hand-made simulation.
[000000540] OpenGL loaded
[000000540] Library "opengl32.dll" is unloaded
[000000540] === GL implementation-dependent info ===
[000000540] Vendor: ATI Technologies Inc.
[000000540] Renderer: Radeon X1650 Series

>>4303
Ты случаем не кун с софтом 3-хлетней давности из соседнего треда, использующий свободные дрова? Судя по уверениям гугля эти штуки в опенгл появились во времена 2 гефорса, и не поддерживаются только еще более древними картами, либо, вероятно, картами без драйверов.

>>4303
>[000000540] Vendor: ATI Technologies Inc.
Here's your problem

>>4303
>>4311
Ычую сэра Адама.

Добавил экспорт скиннинга из Collada и теоретическую поддержку иксов. У меня не компилируется (спасут лазарь и 9000 затребованных пакетов?), но анон может попробовать, вдруг повезёт!

To-do:
- экспорт самого скелета оттуда же
- формат для анимации
- вики

>>4339
>спасут лазарь и 9000 затребованных пакетов?
Спасет написание на человеческом языке.

>>4282 у меня версия rr 0.0025-7_base_pp рисует черный экран и надписи, в 6.6 все было нормально. Причем буффер на каждом кадре не чистится, и надписи рисуются поверх предыдущих.

Win7, видюха gf 8800

Еще про тени и отражения вопросик: ты их в кубемапы рендеришь, или в плоские текстуры? Как преломление на модельку наложить(я только с водой подобное делал, у меня была одна горизонтальная плоскость и одна 2d текстура отражения)

>>4344
Видел такое на одной ати (вместе с моргающими отражениями и вырезанными из шедоумапы гранями, ага), ещё проверю, completed ли фреймбуферы, но, конечно, не очень здорово, что проявилось и на GF. Запусти с ключами -fs -nopp, это отключит "Omsk ni youkoso" постпроцесс и получится та же 6.6.

Всё рендерю в кубемапы, тогда в шейдере можно рассчитать отражение и преломление как textureCube( envMap, reflect( v_eye, normal ) ) и textureCube( envMap, refract( v_eye, normal, eta ) ). Это приближение для небольших объектов.

Плоские текстуры, наверное, использовать не буду - для спотлайтов и воды (сейчас отражение обновляется вообще неоптимально) просто расширю frustum culling.

>>4341
>на человеческом языке
>FP
Всё в порядке же...

>>4346
>Всё в порядке
>У меня не компилируется (спасут лазарь и 9000 затребованных пакетов?)
На ноль же делишь, ну.

>>4347
Вот послезавтра возьму и скомпилирую. ;_;

Зато там есть PROPERTY и ANSISTRING, чо.

Кажется, пофиксил чёрный экран. Могу предположить, что если рендертаргет ни разу не очищался, некоторые драйверы считают его не валидным - а при включенном постпроцессе экран как раз никогда не очищался, т. к. fullscreen quad рисуется поверх и без теста глубины. (Хотя текст выводился, странно).

>>4344-кун, теперь работает?

>>4359 да, теперь заработало, Омск забавный! Алсо с ключами, которые ты предлагал в >>4346 тоже работало.

Спасибо про кубемапы, я и не думал что так просто все вычисляется. Еще нубский вопрос - процесс рисования в кубемап выглядит как-то так: ставим камеру в точку наблюдателя, fov 45 градусов, рендерим в 6 сторон, поворачивая по каждой оси на +-90 градусов?

Если ландшафт делать кусками с переключающимися лодами, то между соседними кусками с разными лодами будут разрывы же, нэ?

>>4387
>ставим камеру в точку наблюдателя, fov 45 градусов, рендерим в 6 сторон, поворачивая по каждой оси на +-90 градусов
Правильно. И, очевидно, такое обновление кубемапы можно размазать во времени, особенно если объект с ней далеко.

Зачем-то съездил на ТИБО, экспорт скелета завтра зоделаю.

С велосипедом для анимации Суигинта научилась бегать в разные стороны по-разному. В скелетке ещё должны появиться способы интерполяции (сейчас только SmoothStep), возможность "закрепить" промежуточное состояние (например, 50% вперёд и 50% вправо), изменение длины кости, slerp для кватернионов и прочие плюшки.

>возможность "закрепить" промежуточное состояние
>изменение длины кости
done

>>4428 да, анимация намного лучше стала!
Бака-вопрос: как приземляться?

>>4435
Ну-у, лети на землю, если повезёт - приземлишься.

>>4349

>>4440
Внезапно, сконпелировалось! У меня всё равно не пашет, с Mesa - AV на одном из glGetIntegerv, с родным драйвером - "Couldn't find matching GLX visual", пробовал разные комбинации флагов и размеров surface'а. Судя по http://410chan.ru/dev/res/1360.html (гугл выдал среди первых ссылок, кстати), проблема в драйверах нивидии и/или в SDL. С этим наверное разберусь красноглазопроблемы, потестите кто-нибудь то, что есть.

>>4450
>[err] OpenGL library ("libgl.so.1") is not loaded
>[warn] GLU library "libglu.so.1" not found, gluBuild2DMipmaps is not available
Регистр имеет значение. Библиотеки называются libGL и libGLU, можно без .1, это все равно симлинк туда же.
>[err] Exception "EAccessViolation" raised: Access violation
EAssertionFailed : Some memory leaks by classes here: rest of allocatedByClasses is 1133, but must be 0. (rwObjects.pas, line 118)
$BFB61BB8

End of logAn unhandled exception occurred at $0806DC58 :
EAccessViolation :
$0806DC58
$0806DD47
$080600B9

Runtime error 210 at $08052CEA
$08052CEA
$080E2613

Да, положи наконец все это в папку, неудобно распаковывать же.
И еще
>[Linux]
>[
Это немного проблемно набирать, лучше делать _linux где-нибудь в конце, в такой форме не нужно бекслешей или кавычек.

>>4451

Ну он же говорил, что пока что делает подвенду. А в венде регистр не имеет значения.

>>4451
Обновил, но линукс - зло.

To-do: стресс-тест кучей моделек с отдельными скелетами (интересно, во что упрётся производительность - CPU или GPU), вики, окклюдеры, нормальный граф сцены.

>стресс-тест кучей моделек с отдельными скелетами
done

Как-то очень внезапно выяснилось, что отрисовка, обновление сцены и особенно колижн, мягко говоря, не оптимизированы.

1. Отходим в сторону.
2. Зажимаем Q и R.
3. Ждём, пока все соберутся.
4. Отпускаем.

Такой вот херни не замечал никто?

>>4510
>sended
sent

>>4511
Там много такого? Стоит качать, чтобы посмеяться?

>>4511
Ve laik Engrish, хулѣ. В комментариях к коду и не такое увидишь.

>>4557 Расскажи про проверку столкновений
Ты тримеши между собой проверяешь, каждый треугольник первого меша на пересечение с каждым второго меша?
Это работает с динамическими телами (в physx'е, например, тримеши только для статических тел, для динамических только конвексы)

>>4590
Только сфера <-> сфера и сфера <-> тримеш (с каждым треугольником). :(

Для скелетов ещё будет капсула <-> тримеш.

Насчёт тримеш <-> тримеш или конвекс <-> конвекс... чем плоха, скажем, аппроксимация девятью тысячами примитивов?

>>4593 то есть ты предлагаешь вместо конвексов и тримешей каждое тело составить из, к примеру, over 9000 сфер?! Хм... вроде для определения столкновений должно прокатить, и наверно даже быстрее сеток или конвексов... не очень представляю как в этом случае нормаль контакта получить, но думаю это решаемо. В 2d вроде бы такой прием используется, и весьма успешно

>>4594
>нормаль контакта
Столкнуть сферы одного с тримешем другого и наоборот. В случае тримеш<->тримеш придётся пересчитывать трисы какого-то из них, это дорого.

Посоны, стоит переводить строки (вообще все, и в именованных ресурсах, и имена файлов) на UTF-8?

>>4610
>UTF-8
Почитал про него и про частичную совместимость с ANSI, узнал, что у меня давно поддерживается (не считая имён файлов, хотя кому они нужны). Такие дела.

Отвлёкся чевой-та.
http://rghost.ru/7899451
Грибы-грибочки.

Update: "родные" линии, визуализация kD-деревьев и скелетов.
L - режим отображения трисов: линии / сплошная закраска
I - скелеты
K - kD-дерево коллайдеров
O - включить/выключить Суигинт (чтобы скелеты рассмотреть)
NumPad +/- 1-9.

Пилю GUI. :3

>>4675
С линуксами-то что, все так же падают?

>>4678
Ага. После того, как для элементарного действия - компиляции в FPC IDE - пришлось создать симлинк с libncurses.so на некую libtinfo.so, желание разбираться с поддержкой линукса пропало напрочь. Не говорю, что её не будет когда-нибудь.

>Пилю GUI

Можно окошки перетаскивать.

вот

Собрал в кучу.

Сглаживание запили

>>4774
Есть такое.

>>4782
Включи в драйвере. >_>

Прикрутил Render Targets Ping-Pong - в шейдере постпроцесса доступен предыдущий кадр, можно рисовать моушенблюр.
Ключ -rgb32f - float текстуры, точность выше.

А ещё скроллбары, отсечение через gl_ClipDistance[] (используется в GUI и для отражений) и "группы рендеринга" - костыль для исключения объектов из зеркал/шедоумап. Впрочем, по сравнению с прежним исключением по имени это хорошее решение.

Попробую реализовать Perspective Shadow Maps. Ну или утащить их из OpenSceneGraph.

>>4796
SF лагает. http://rghost.ru/10873791

>Включи в драйвере.
Нет ты!

>>4808
Ладно, уговорил.
Ключ -aa <число> - количество сэмплов, по умолчанию 4. С 4 и более включается также фейковый - тупое увеличение текстуры экрана - 4x AA для FBO. Заюзать бы multisample textures, но они непрозрачны (даже работа в шейдере немного другая) и, будучи фичей OpenGL 3.2, не везде поддерживаются.

Прости няша, но моушен блюр не нужен. Из-за него игры становятся убогими. Сравни например как идёт Quake 3 Arena и Quake 4. Не удивительно, что тру геймеры до сих пор играют в Quake 3, потому что движения там чёткие и резкие без всяких блюров за счет высокого FPS.

>>4814
То же относится к доф, хдр, простому блюру, но ведь никто не мешает сделать их отключаемыми.

Не могу я в математику этих PSM, иду дальше. Из исходников OSG:
>I later understoood why it works.

Пользовательские рендерпассы (done, пикрелейтед) и рендертаргеты, MRT, распределение объектов по освещаемым объёмам, граф мира и подгрузка на лету, например.

2D рендертаргеты - done.
CROSS-EYED STEREO, вот.

Уменьшил в два раза расстояние между "глазами".

Доступна магнитно-резонансная томография! Но (пока) не используется.

>распределение объектов по освещаемым объёмам
Работает. В демке 9 источников, но каждый объект рисуется максимум с двумя.
Генерация шейдеров для разных типов источников и нефиксированного количества лайтов на проход, Cascaded Shadow Maps для бесконечно удалённых - будут.
Хорошая идея: перекатиться на Lua.

Переписал загрузку на Lua. Мейну уготована та же участь.

Неспешный бамп. Вся логика теперь на Lua.

Пожалуй, приведу в порядок код и прикручу физику (Newton).

>>4274
ЖМУ/Линуксовая сборка не запускается вообще, пикрелейтед и

No heap dump by heaptrc unit
Exitcode = 217

в ошибкологе.

Версия для ШИНДОШС запущенная в вайне показывает только чайник и кнопки не работают.

>>5174
Запуск через терминал дает

An unhandled exception occurred at $FF965DD8 :
EAssertionFailed : Some memory leaks by classes here: rest of allocatedByClasses is 1037, but must be 0. (rwObjects.pas, line 118)
$FF965DD8

End of logAn unhandled exception occurred at $0806DC58 :
EAccessViolation :
$0806DC58
$0806DD47
$080600B9

Runtime error 210 at $08052CEA
$08052CEA
$080E24A3

Оп, зачем ты перекатился на Луа? У меня после переката какой-то пиздец - нехуя не работает и видны линии от осей обьектов.

> .pas
> .pas
> .pas
> .pas

>>5201
just as planned

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

Самодельные Lua-модули выгружаемы. (Если стандартные module/require предусматривают выгрузку и я изобрёл велосипед - дайте мне знать). Сконпелировал бетку Lua 5.2, полёт нормальный.

>>5453
>Lua 5.2
Но зачем?

>>5458
Например, поддерживаются финализаторы (__gc) таблиц, а раньше они были привилегией userdata. Джва года этого ждал!

Внезапно, физика! ^_^

Z - бросить чайник. Не стоит насыпать горы из чайников: они очень, очень, ОЧЕНЬ сильно лагают, Ньютон же.

>>5776
Теперь и с базовой сериализацией коллизий, а то Tree для платформ чуть ли не по полсекунды строится.

To-do:
- обёртка над материалами - физические свойства, обратная связь, плюс как-нибудь обойти то, что Newton не умеет уничтожать их по отдельности;
- описание скелета капсулами;
- лоды скелета же - обрезать мелкие кости на расстоянии;
- Cascaded Shadow Maps.

Оп, а ты что-нибудь собственно собираешь запиливать на этом?

>>5797
Конечно! Правда, пока не знаю, что именно.

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

Суигинта больше не движется рывками.

>>4274
Ты конечно охуителен, но где игра то?
Неужели не существует людей, которые могут добавить сюжет и геймлей\Новые локации? Никто не хочет тебе помогать? foreveralone.jpg

Как от программиста от тебя требуется только добавить вменяемое управление персом без наркоманского управления и пофиксить мелкие баги в виде проваливание камеры за стену. (Полет очень хуёво реализован)
И парочку новых возможностей:
1 ЕБАНОЕ МЕНЮ БЛЯДЬ
2 СПРАВКУ КАК В 1 КВЕЙКЕ, НИХУЯ НЕ ПОНЯТНО
3 Ебенящих человечков для закликивания до смерти
4 Возможность снимать скрины :3

А графон как в крузисе и физика шикарно реализована.

>>5968

Пока я занимаюсь непосредственно движком для ЭрПоГе, все ресурсы исключительно тестовые. Главное - не делать этот процесс бесконечным, да.

>проваливание камеры за стену
Fxd (рейкаст).

>Возможность снимать скрины
F12

Теперь каждая шейдерная программа находится в единственном файле, т. е. они не могут шарить шейдеры. Ибо толку от такой возможности было немного, а линковка даже ускоряется. Сегодня запилю пользовательские типы в Lua-скриптах - свойства + методы, доступ через точку, не двоеточие! :3 - и Collision Callbacks для материалов.

>пользовательские типы в Lua-скриптах
done. Вообще-то не стоит переносить всю логику игры на скрипты - и в плане производительности, и из архитектурных соображений единственным православным вариантом является отдельный фреймворк. Тем не менее, удобная вещь.

>Collision Callbacks для материалов.
done. Искры (Z) и чуть более человеческий подъём по лестнице. Callback'и, даже те, что вызываются единожды для нового контакта, довольно-таки заметно лагают на кучах чайников, если выставлены на Lua-функцию: кажется, Newton любит пересоздавать контакты между нестатическими объектами чуть ли не каждый апдейт.

> описание скелета капсулами;
Хм. С одной стороны, для
> Ебенящих человечков для закликивания до смерти
и махания мечом хватит и капсулы на персонажа. С другой, взаимодействие скелета (не только ragdoll'а) с окружением смотрелось бы круто. Опять же, при небольшом лоде можно менять на одну капсулу. Посмотрим.

Перекатился на FPC 2.6.0. По-видимому, в очень редких случаях он может не освобождать автоматические поля олдскульных object'ов. Полдня ловил утечку >_<

Но вложенные типы - это, конечно, круто.

Windows8

>>6081
Только в релизе? мало ли
Почти наверняка дело в SDL! Я их накажу.

Сейчас разбираюсь с джоинтами.
J - сджоинтиться с чайником.
B - разджоинтиться.
Должно хватить встроенных (http://newtondynamics.com/wiki/index.php5?title=Joints), но в крайнем случае - джоинт изменяемой длины? брейкейбл? - есть User-defined bilateral. Теоретически, они ещё и дают халявную инверсную кинематику.

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

>>6116
и да, геодата вся на сервере.
все перемещения у клиента - с разрешения сервера.
т.е. сервер говорит клиенту, когда он падает, когда он куда бежит, когда он летает или тонет.

ОП, тут какая-то беда с куллингом(???) - пикрелейтед. Win7x64, 8800GT. Раньше работало.

Расскажи поподробнее про скелет и анимации - как ты их конвертировал в свой формат - из какого-то стандартного формата, или прямо из макса/маи? Как хранишь матрицы костей для каждого фрейма?
Мне просто тоже захотелось запилить скелетную анимацию, а нормальных 3d форматов не нашел. Думаю тоже изобретать велосипед:3

Запилил карту высот с ТОННЕЛЕМ. Newton не позволяет явно создавать в ней дырки, но я извернулся при помощи магического MaterialID для вырезанных ячеек и его проверки в broad phase. Способ этой проверки, вообще-то, неверный - проецирование центра масс на карту высот, но пока работает. Особенно если объект не больше ячейки, а края дырки замаскированы.

>>6116
Дружище, превращать какую-либо из этих технологий в golden hammer совершенно не обязательно. Карта высот для ландшафта, BSP для всей статики, не вписывающейся в карту высот, меши для разных там плавающих островов - всему своё применение же.

>карта высот - сразу отпадает. высота в 255 слишком мала.
>кастомная карта высот - но как тогда запиливать многоэтажные сложные домики, секретные базы, пещеры, левитирующие острова?
Есть 16-битные хаймапы. Для входов в данжи, зданий и прочего достаточно реализовать дырки, что многие движки и делают (UT3: http://www.wonderhowto.com/how-to-create-holes-terrain-surface-ut3-editor-197074).

>>6123
;_;
Похоже, не скомпилировался шейдер. Что пишет дебаг насчёт dift_bumpt_spect?

Скелет сконвертирован из Collada. (Дойдут руки - запилю экспорт из MikuMikuDance через неё :3) Для каждой кости в самом скелете и в анимациях, в которых она задействована, хранятся её длина и кватернион поворота - интерполяция каждой составляющей с достаточной точностью сводится к взвешенной сумме.

Модельные матрицы с некоторого момента решил не использовать вообще: преобразования в виде "смещение (vec3) + поворот (кватернион) + скейл (float, почти всегда единица)" применяются к вершинам медленнее - 18 умножений / 15 сложений, против 12/9 для матриц, зато быстрее комбинируются (30/21 vs. 64/64) и занимают в 1.5+ раза меньше памяти - актуально для шейдерных констант.

ОП, >>6123-кун на связи: та же история, в новой версии никакой карты высот не видно. Запустил debug-версию, посмотрел лог - туда постоянно выдается строка
[err] Routine "DrawBatch" raised OpenGL error with code 1282 (GL_INVALID_OPERATION)

Начинается вот отсюда, хотя скорее всего она просто на каждом шаге рендеринга выбрасывается:
Dynamic cube render target "starlight": [ok] complete
Compiling shader "dift_skel" (vs, flags 3)... [ok] OK
Compiling shader "dift_skel" (fs, flags 3)... [ok] OK
Loading "dift_skel" (flags 3): Linking... Validating... [ok] Done
[err] Routine "DrawBatch" raised OpenGL error with code 1282 (GL_INVALID_OPERATION)
Compiling shader "dift_bumpt_spect" (vs, flags 3)... [ok] OK
Compiling shader "dift_bumpt_spect" (fs, flags 3)... [ok] OK
Loading "dift_bumpt_spect" (flags 3): Linking... Validating... [ok] Done

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

про дырки спасибо, скину пишущему клиент куну, надеюсь ирллихт это поддерживает.
можно поподробнее про 16битные хейтмэпы? алсо, какой у них шаг? единица? не будет ли при таком шаге ступенек вместо горок?

Я иногда захожу в /dev/, ничего не пишу и не читаю, а просто смотрю на эту картинку. Теперь эту картинка не показывается среди последних постов треда, поэтому я запощу её ещё раз, уж извините.

Юникод в GUI'шном тексте, русский шрифт и пул строк, совместимый с ansistring.

>>6150
Да... проблема. И совершенно не представляю, в чём. vertex layout? вроде давно не менял. Залей полный лог, а? :3

>>6156
А нужна ли поиску пути геометрическая точность? Можно искать стандартными волной/A* на одной или нескольких (скажем, основная + данжи) дискретных двухмерных картах, а если мир в них не проецируется или для отдельных участков со сложной геометрией поступить так: заполнить проходимое пространство точками (не плотно и не равномерно, где нужна точность - больше), провести рёбра между соседними достижимыми и работать уже с этим графом.

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

>алсо, какой у них шаг? единица? не будет ли при таком шаге ступенек вместо горок?
Шаг задаётся флоатовым фактором масштабирования. Битность влияет только на максимальную высоту при выбранном шаге, ну или наоборот - на плавность переходов при известных границах.

>>6168
Ок.

>>6172
Ну а напомни мне мморпг без клеточек, где нету геометрической точности при поиске пути? Волнами легко искать по карте высот, да, но предположим у нас небоскрёб с 18 этажами. Игрок переключается с 4го, где он сейчас, на 18ый и тыкает бежать туда. даже если сделать этот небоскрёб мешами и наполнить его тупо модельками, которые обрабатывать как один большой прозрачный/непрозрачный меш (т.е. забить на BSP) - печаль и горе.
я думал сделать как ты говоришь - создать систему графов из зон и переходов между зонами и использовать рекурсивную систему поиска с подбором кратчайшего или первого найденного пути. но не будет ли слишком высокая нагрузка на сервер, если, например, игроки захотят устроить осаду такого небоскрёба и набижат туда пачкой из 500 игроков?

>Большая нагрузка же. Пусть клиенты сами ищут путь, отправляют его на сервер (с валидацией и корректировкой) и перемещаются снова с его разрешения.
>перемещаются снова с его разрешения.
в этом самая главная проблема же - определить возможность прохождения/не прохождения клиента.
золотое правило сетевого программирования: всё, что можно взломать на стороне клиента - будет взломано. без контроля со стороны сервера - привет ноклип, как это было в нескольких ММРОПГ, кстати. геймгуард от нцсофт не помог даже. весь Виетнам и все русские айпи в итоге побанили.
предположим клиент отсылает мне пачку вэйпоинтов, по которым хочет пройтись. как я могу определить что они валидны, в этом например небоскрёбе? с картой высот всё довольно просто, да - делаю проекцию от точки к точке.

про шаг спасибо, это очень радует. есть-ли готовая библиотека или хотя-бы ресурс/набор статей посвящённый 16битной карте высот?

Я не знаю, о чём вы тут разговариваете, просто хотел сказать, что искать путь волной на взвешенном графе — инстант фейл. Только Дейкстра / A.
мимопроходил*

И ещё:
>без клеточек
>500 игроков
Это вообще возможно?

>>6175
Я почти уверен, что все "мморпг без клеточек" в том или ином виде используют графы вэйпоинтов; NavMesh'и тоже сводятся к ним. (Конечно, на открытых пространствах это излишне, сработает элементарный "алгоритм руки"). Пачка из 500 игроков, собравшихся в одном месте, даст лаги в любом случае.

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

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

Всё-таки запилю CSM (PSSM), без них беспонтово как-то. Благо в GPU Gems 3 расписано (http://http.developer.nvidia.com/GPUGems3/gpugems3_ch10.html), что к чему.

>>6179
>Пачка из 500 игроков, собравшихся в одном месте, даст лаги в любом случае.
да нет, играл я на своём веку в большое количество ММОРПГ и видел подобные баталии, зачастую лагов не было. если сервер не пиратский, конечно.

>По идее, если клиент посылает индексы вэйпоинтов, достаточно проверить смежность соседних (помимо собственно валидности индексов). Не вижу здесь возможностей считерить.
>проверить смежность соседних
что ты имеешь под этим ввиду?

>Не вижу здесь возможностей считерить.
ну например перепрыгивать через дырки в полу, пролагиваться через близко стоящие стенки.

>>6196

>>Пачка из 500 игроков, собравшихся в одном месте, даст лаги в любом случае.
>да нет, играл я на своём веку в большое количество ММОРПГ и видел подобные баталии, зачастую лагов не было. если сервер не пиратский, конечно.

Не знаю во что там там играл, но во в играх WOW, Lineage2, EVE Online, RIFT лаги при возникновении описанной ситуации есть. В EVE сделали клёвую штуку с замедлением времени в больших баталиях. Очень годная идея, правда спизженная у Supreme Commander, хотя может быть они в свою очередь её тоже у кого-то спиздили.

>>6197
>Lineage2
Но ведь не было же. Пиклирейтед - драка 200 vs 300 у порта Гирана. Лагов сервера не было. Фришка работающая на спиженном PTS ядре С4. Давно дело было, да. В другие ММО хоть и играл, но в таких баталиях не участвовал.
Что примечательно - позже фризы появились, да. Ну да ладно, это не важно.
В общем суть в том чтобы клиент занимался паффайндингом, а сервер лишь проверял вэйпоинты на валидность?
Предположим при побегушках по хейтмэпе всё понятно - я просто строю путь от точки да точки и проверяю разницу высоты между точками с шагом в n, при разнице высоты больше определённой - я помечаю эту точку как последний вэйпоинт и отсылаю клиенту, в потоке обработки клиента помечаю движение, обсчитывая координаты с учётом скорости движения персонажа. ок.
А вот теперь самое сложное - как просчитывать вход с земли в дом и например подьём на 2 этаж со двора? Земля - хейтмэпа, дом - система графов. Создавать дополнительные точки соприкосновения зон графов с хейтмэпой?

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

>проверить смежность соседних
>что ты имеешь под этим ввиду?
Бака! Проверять элементарное существование рёбер между соседними вершинами пути.

>>6229
Я делал "активные векторы" в зоне действия здания. Если персонаж движется по этому вектору, то попадает не в соседнюю клетку, а туда, куда прописано в свойствах вектора. Естественно, что и клиент, и сервер должны работать в трёхкоординатном пространстве, где третья координата — номер "этажа". И поиск пути тоже нужно выполнять в трёх координатах.
мимопроходил

>>6230
>Ну да, по аналогии с порталами в отрисовке сцены. Других способов не вижу, это всё-таки разные структуры.
okay.jpg

>Бака! Проверять элементарное существование рёбер между соседними вершинами пути.
т.е. по сути
>я просто строю путь от точки да точки и проверяю разницу высоты между точками с шагом в n
я просто этим не занимался ещё :<

>>6235
Зоны выглядят попроще и без жёсткого разграничения на этажи. Хотя это будет работать быстрее, да.

>от точки до точки
slfix

Реализовал Cascaded Shadow Maps. Ничего сложного, я-то думал. 3 сплита; каждый описывает свою часть фрустума камеры и, кроме того, вытягивается в сторону Солнца до края сцены - иначе горы, которые не видны непосредственно, тени могут и не отбросить. Затенённая геометрия рендерится за один проход с выбором из трёх сплитов прямо во фрагментном шейдере.

>>6235
Это не Сырно ;_;

http://sourceforge.net/projects/rr-rr/ зачет

>>6282
Травон!

Прикрутил подобие SSAO. Не учитываются нормали прямо как в крузисе!, не используется псевдослучайный поворот... в итоге фейк фейка, эффект ещё больше напоминает неведомые ореолы. Впрочем, с пивом потянет.

>>6370

>>4274
Стив, расскажи, пожалуйста, с чего ты начинал. Что нужно читать?

>>6372
NeHe, спеки, http://www.gamedev.ru/code/forum/?graphics и пейперы разработчиков.

>>6370
Лучше бы траву сделал, хотя бы как в обливионе.

>>6383
Challenge accepted. В самом деле, нужно. Заодно добавлю геометрический инстансинг.
Да и про геометрические шейдеры я совсем забыл, хотя для систем частиц они подходят идеально.

Запустил твой крузис, показывает такую фигню. Если подойти к фиолетовой хрени проявляется такой же фиолетовый террейн, но если при развороте назад снова пропадает.
В консоль пишет '[err] Routine "DrawBatch" raised OpenGL error with code 1282 (GL_INVALID_OPERATION)'
Win7 x64, GTX580.

Похоже, ты разбираешься в компьютерной графике. У меня есть вопрос.
В универе задали сделать приложение "демонстрирующее работу с 3D функциями видеоадаптера", я решил сделать трехмерный опенинг сериала Doctor Who http://www.youtube.com/watch?v=WCD_Aw9RXxU%%.
Уже сделал ТАРДИС и соорудил прогу на OpenGL, которая умеет его отображать. Но вот вопрос - как сделать тоннель?
По идее, его нужно генерировать на ходу, потому что он должен быть бесконечным. Может, для есть какие-то известные приемы для подобных случаев?

>>6395
Спойлеры, спойлеры!

>>6395
В тред стремительно врывается http://nehe.gamedev.net/

Из соображений гибкости вернул создание нового VAO для каждой комбинации "меш + шейдер", вместо фиксированного лейаута на меш. >>6387-кун, всё то же?

>>6395
Круто! ^_^
Очевидный способ - сделать "тайлящийся" кусок тоннеля, т. е. такой, что края при стыковке совпадают. А то и просто замкнутый, вроде torus knot.

>>6403
Черт, про замкнутый я даже не думал! Если сделать его форму не слишком правльной, никто и не поймет, что летает "по кругу". Спасибо.

>>6401
Тебе тоже спасибо. Второй раз просмотрел уроки на этом сайте, на этот раз до конца - заприметил несколько эффектов, которые могут пригодиться.

>>6403
Теперь совсем текстуры пропали.

>>6405
FFFFFFFFFFF-
Лог?
Найди в config.lua
>Config('GL.disableAdvFloats', false)
и замени на true.

>>6414
Сейм щит.
http://rghost.ru/36811993 - лог.

>>6418
А теперь?
Изменил порядок операций в рисовании батча: сначала биндится шейдер, потом VAO. Больше идей нет, если что, буду воспроизводить. :C

>>6425
Увы, ничего не изменилось.
http://rghost.ru/36836068 - новый лог, если надо.

Запилил ГЕОМЕТРИЧЕСКИЙ ИНСТАНСИНГ. Пока что инстансы умеют различаться только модельным преобразованием, в будущем - чем угодно, кроме текстур. Для скрипта всё прозрачно.

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

Пикрелейтед - новая иконка. ^_^

>>6418
Воспроизвёл на GF GT 540M (заявлен OGL 4.2), ошибку бросает glDrawElements. Куда копать - не вижу.
Предыдущие версии

http://sourceforge.net/projects/rr-rr/files/rr%200.0025-17_skeleton_node.zip/download
http://sourceforge.net/projects/rr-rr/files/rr%200.0028_phys.zip/download

работали?

В предыдущих то же самое, но изредка проглядывающие текстуры вроде нормальные. Последняя правильно работающая версия - 0.0025-15.
Алсо в какой-то из версий в чайнике отражался мой десктоп, лол, так и было задумано?

>Последняя правильно работающая версия - 0.0025-15.
saem shit. Win XP SP3. ATI, AMD.

>>6464>>6477
Спасибо за информацию, завтра посмотрю.

>Буду запоминать локейшны в каждом объекте.
done, здесь теперь всё круто.

>фиолетовая хрень
А вот с этим ещё разбираюсь. Бинарный поиск ревизии, с которой начались баги - весьма увлекательное занятие :3

Мне всегда было интересно, а как организовать правильное юнит-тестирование для проектов с существенным количеством графики?

>>6498
Эм, графика - такая же подсистема, как и остальные, значит, и принципы не отличаются. Берёшь и пишешь тестовое приложение ^^"

>>6464>>6477
Господа, вроде починил, теперь работает? Если всё ок, расскажу, в чём было дело.

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

>>6499
Да, теперь все отлично. ПЕЧ580

>>6500
YEAAAAAAAAHHHH

Так вот. Я просто-напросто отказался от glBindAttribLocation, т. к. иногда индексы выставляются без ошибок, при запросе возвращаются новые... но не работают. Баг драйвера с вероятностью в 99%. Горжусь вендорами!

ОП, ты офигенен! Скажи, а ты работаешь в этой области, или это твое хобби? Я вот на работе довольно тесно связан с OpenGL, но вот технологии вроде psm и прочие штучки с освещением никогда не юзал; посмотрел на твой движок и очень захотелось попробовать. Алсо, вот еще интересный и простой эффект:
http://http.developer.nvidia.com/GPUGems3/gpugems3_ch13.html
Да, почему именно паскаль, а не плюсы?

>>6546
>Да, почему именно паскаль, а не плюсы?
Чтобы никто не смог присоединиться к разработке, очевидно же.

>>6547
Я могу без проблем, например.

Дельфиняша

>>6547
Траву мне когда запилишь?

>>6546
Я студентота и занимаюсь этим just for fun.

>http://http.developer.nvidia.com/GPUGems3/gpugems3_ch13.html
Чёрт. Вспомнил, что в движке до сих пор нет postprocess chain'а, а ведь он элементарно реализуется на базе уже имеющегося пинг-понга. Запилю.

>Да, почему именно паскаль, а не плюсы?
Паскаль мне более симпатичен как язык, очевидно же. Почти не приходится воевать с компилятором или выискивать UB.

>>6549
Сделано. ^_^
ТРАВОН генерируется автоматически (рандом + колижнкаст).
- С единственной разновидностью кластера он выглядит клонированным, это исправимо.
- Карта растительности позволила бы заменять камень на почву.

И наконец появился профит от инстансинга. Его можно ещё усовершенствовать, если определять количество инстансов динамически. Совсем-совсем продвинутым будет http://www.opengl.org/wiki/Buffer_Texture, это фактически снимет ограничение на количество инстансов, но является нативной фичей аж OGL 4.2. Впрочем, почти везде поддерживается как расширение.

ОП, как ты относишся к Overgrowth?
Там тоже чуваки постоянно добавляют всякие фичи в движок, каждую неделю выпускают новую версию и рассказывают о изменениях.

>>6577
Всё правильно делают. Тоже планировал скелетную анимацию, привязанную к физическому миру, и основанную на ней IK.
До сих пор руки не доходят.

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

>>6569
Решил посмотреть твой крузис. Обещанного травона не обнаружил.
лог: http://rghost.ru/37411668

У меня конечно не топовый пека, но тот самый крузис на минималочках и с тормозми траву всё же рисует.

>>6601
С заявленной
>GL version: 2.1
я бы вообще не стал на что-то рассчитывать — юзаются фичи вплоть до 3.0 + инстансинг из 3.1. А не вылетать ли в таких случаях сразу? Возможно, это потолок для x2300, но попробуй обновить драйвер.
Тем не менее, сделал инстансинг отключаемым, при этом ТРАВОН прореживается, чтобы как-то считаться с тормозами. Проверь.

Там ещё какая-то ерунда насчёт фреймбуферов, так что не исключены проблемы с тенями. Но здесь я вряд ли смогу помочь.

>>6594
Сомневаюсь, что это хорошая идея. Лучше сюда глянь: http://code.google.com/p/cartwheel-3d/
Или, в принципе, сюда (осторожно, луркосленг): http://www.gamedev.ru/pages/unsolved/articles/statebased_control

>>6603
Теперь вообще вылетает при запуске.

>>6612
Идея понятна. Если это просто навороченный способ приближать на каждом шаге текущее значение каждой степени свободы к желаемому, должно получиться то же. Матан не читал.

>>6615
Failed to link без подробностей? Зашибись.
Отключил пару фич для GL ниже 3.0. Что теперь?

>>6618
>должно получиться то же.
Почему ты так уверен? Опиши, какими джоинтами ты собираешься связывать регдолл и анимацию, будешь ли ты задавать анимацию в мировом пространстве или в пространстве модели, и почему под действием, скажем, силы тяжести всё не упадёт. (мне эта тема интересна, но лень что-то кодить самому)

>>6618
>Отключил пару фич для GL ниже 3.0. Что теперь?
shu.exe выдаёт сообщение об ошибке 216 (это же очевидно как её решить!) и закрывается, отладочная версия закрывается молча. Скрин сообщения об ошибке и лог прилагаю.

Хотелось бы задать глупый вопрос по opengl.
Есть игровой движок и система партиклов. Рендерер движка заменен на новый, который вначале отрисовывает сцену и затем вызывает onDraw() партиклов. Система партиклов использует свои настройки состояния opengl и затем восстанавливает исходные, для того чтобы на следующем кадре сцена отобразилась как надо. Это нормально? Как обычно решаются такие задачи? Исправлять пришлось внезапно, до этого с opengl не работал.

>>6652
VBO.

>>6652 Это нормально. Обычная практика для использования рендеров разных подсистем в одном контексте - сохранить старое состояние(glPushAttrib), матрицы, если нужно(glPushMatrix), выполнить отрисовку, вернуть старое состояние (glPopAttrib, matrix). Also, будь внимателен: push/pop matrix работает отдельно для каждого режима матрицы, поэтому если пушишь MODELVIEW, то и попать надо MODELVIEW.
И да, как написал >>6659-кун, лучше запихнуть все частицы в один VBO и отрисовать за один DIP - так будет быстрее всего

>>6659>>6672
Спасибо.
Где можно почитать поподробнее про DIP/DPUP/DIPUP?
А о сохранении VBO беспокоиться не нужно, если движок перед каждым pass его апдейтит сам?

>>6711
> А о сохранении VBO беспокоиться не нужно, если движок перед каждым pass его апдейтит сам?
Или между ними переключаться можно? Немного посмотрел исходники движки, похоже на это. Ничего ещё не читал пока, сейчас буду.

>>6619
Пытался реализовать фейк, т. е. персонажа, представленного бжд-куклой для правдоподобной анимации конечностей и капсулой для всего остального, но так и не подружился с Ball and socket джоинтом. -_-" То есть, конечно, его крайне нестабильное поведение — исключительно моя заслуга, т. к. это последнее дело, явно устанавливать матрицы, ведь физический движок предполагает задавать силы, максимум — моменты/скорости, но как это увязать с текущей архитектурой... В общем, работаю над этим™.

Пока же запилил УБЕРШЕЙДЕРЫ с пользовательскими флагами. Для драйвера разницы никакой, зато намного меньше копипаста в GLSL-коде. А потом прочитал http://www.gamedev.ru/community/gamedev_lecture/articles/?id=816 и достиг просветления. Идея очень нравится, но это будет... нетривиально, хотя по сути получаем то же, что и с убершейдерами, просто в более организованной и восприимчивой к изменениям форме.

Итак, ближайшие планы - (1) цепочка постпроцессов, (2) помахать мечом в кого-нибудь и (3) добить бжд.
"Уберсистема микрошейдеров" привлекательна ещё и тем, что шейдеры отвязываются от конкретного GAPI. Обязательно повтыкаю.

>>6722
>бжд
неспешнофикс

>>6722
Это что-то типа пикрелейтед?

>>6725
Ага, вот эти ребята.

Абсолютно внезапно прикрутил BASS. Йоба-3D источники звука в качестве узлов сцены и всё такое.

Можно добавлять свои песенки в data/musik/playlist.lua.

http://rghost.ru/37898157

>>6729
Правда, пока очень любит вылетать.

>>6729
>BASS
Почему все так любят эту проприетарщину?

>>6734
Мне хватило продуманного и интуитивно понятного API которым подавляющее большинство свободных либ похвастаться не могут и поддержки трекерной музыки.

>>6735
>и поддержки трекерной музыки
Вот это, кстати, большая проблема. Даже большинство библиотек, которые заявляют, что поддерживают, скажем, .it, на деле любят игнорировать каждую третью инструкцию в них и выдавать невнятную ерунду вместо нормального трека. А вот BASS прекрасно играет.

>postprocess chain
Думаю, достаточно именно цепочки постпроцессов, а не графа, т. к. для МЫЛА есть мип-уровни, а для дополнительных данных - MRT. Пилю.

>>6742
Забавно, история описала петлю. Создание эффектов из графов и цепочек фиксированных шейдеров довольно сильно напоминает opengl combiners.

>>6758
Бака! Я говорю о последовательном применении постэффектов из отдельных пользовательских, конечно шейдеров, т. е. об универсальном механизме для разных там многопроходных техник. Всё же склоняюсь к тому, чтобы не заморачиваться и задавать порядок и рендертаргеты вручную, как, например, здесь: http://www.uraldev.ru/articles/id/23. Только, быть может, писанины поменьше и уровень абстракции повыше. :3

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

>postprocess chain
Done. Многопроходные постэффекты — ничего необычного в реализации, зато какой ГРАФОН!
MAXIMUM PELEVIN

А ещё инстансинг теперь автоматически подстраивается под объём данных экземпляра и возможности карточки.

<fat>Одному мне кажется, что нынешняя 3d графика, основанная на растеризации полигонов и z-буффере, целиком состоит из костылей и хаков?</fat>

>>6835
Это цена реалтаймовости же.

И вообще, будто что-то плохое. Костылём можно назвать любую числодробилку, ведь инты и флоаты в общем случае не подчиняются правилам соответствующих числовых множеств.

>>6836
Когда я в последний раз читал статьи из dx sdk, я смеялся сквозь слёзы. Все эти mapping и culling - это же такое производство троллейбусов из буханок хлеба. ОП, лучше бы занялся GPU raytracing или придумал бы более эффективный метод хранения 3d моделей.

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

>>6837
>Все эти mapping и culling - это же такое производство троллейбусов из буханок хлеба.
Не забывай, что цель всей компьютерной графики не в максимально "честной" визуализации, а в максимальном эффекте при минимальных затратах.

>GPU raytracing
Если речь не о демке с примитивами вместо моделей, это подразумевает вокселы — в будущем, возможно, и станут применяться наравне с поликами (id Tech 6 же!), но никогда их не вытеснят, т. к. у обоих свои достоинства и недостатки.

>Это абсолютно неуместное сравнение.
Хорошо, тогда вот ещё пример: живопись. Она состоит из не менее ужасных костылей и хаков — так, штриховка напоминает сканлайн — и ничуть от этого не страдает.

>>6842
>при минимальных затратах
Полигоны? При минимальных затратах? А зачем тогда изобретали сначала LOD, а затем тесселяцию? Суть в том, что в этот метод не заложена минимизация затрат, её нужно подпирать костылями. В сыром виде этот метод даже frustum culling не умеет, какие уж тут минимальные затраты. А вот старые-добрые voxel octrees, например, устроены так, что нужная детализация получается автоматически. С этой точки зрения метод более красив.
>Если речь не о демке с примитивами вместо моделей, это подразумевает вокселы
Почему? Raytracing можно применить к чему угодно, хоть к тем же полигонам (что успешно делается).
>Она состоит из не менее ужасных костылей и хаков — так, штриховка напоминает сканлайн — и ничуть от этого не страдает.
Опять неудачный пример. Художник строит изображение в своей голове и переносит его на бумагу удобным для него инструментом. Вот если бы у него вместо кисти был один только циркуль-балеринка, и ему нужно было рисовать даже то, что закрыто другими объектами, я бы принял такое сравнение.

>>6843
При чём здесь надстройки над полигонами? SVO является точно такой же надстройкой над вокселами и точно так же не может без дополнительных телодвижений в какой-либо куллинг, к примеру. Тесселяция, при ручной доводке, тоже умеет генерировать лоды автоматически, сохраняя все преимущества полигонов: НАМНОГО меньшие затраты памяти и вычислительных ресурсов и быструю обработку вершин — а это анимация и вообще любое процедурное искажение. Как ты представляешь анимацию SVO?

>Raytracing можно применить к чему угодно, хоть к тем же полигонам (что успешно делается).
Не в реалтайме.

>Опять неудачный пример. Художник строит изображение в своей голове и переносит его на бумагу удобным для него инструментом.
Пример как пример. Доводится рисовать и поверх, стирая лишнее. Кстати, любой уважающий себя движок рисует непрозрачные объекты в порядке от ближних к дальним.

>>6844
>SVO не может без дополнительных телодвижений в какой-либо куллинг, к примеру
Вот и нет. Традиционная технология рендеринга SVO - raycasting - сама находит именно тот воксель, куда попадает луч из камеры. Никакой куллинг не нужен, как и для любой технологии, "идущей" от камеры к геометрии.
> Не в реалтайме.
Скоро будут делать это и в реальном времени. Лови волну, что называется.
>НАМНОГО меньшие затраты памяти и вычислительных ресурсов и быструю обработку вершин — а это анимация и вообще любое процедурное искажение. Как ты представляешь анимацию SVO?
Ну так я и не предлагал тебе делать SVO, а предложил придумать что-то своё. Что-нибудь + фракталы для интерполяции, например.

>>6845
>Вот и нет.
И правда ведь, каюсь.
>Скоро будут делать это и в реальном времени.
Подозреваю, что лет 15 назад считали так же. Ну вот когда начнут, по-быстрому и переделаю. :3
>что-то своё
Не думаю, что это хорошая идея. Здесь всё уже придумано до нас.

>>6847
>Не думаю, что это хорошая идея. Здесь всё уже придумано до нас.
Фу таким быть. Ладно уж, оставлю тебя в покое :3

Как там этот твой крузис поживает? Когда поиграть то можно будет?

>>7136
Если мне память не изменяет, автор не задавался целью написать что-то играбельное. Просто движок, просто знания.

>>7137
По правде, всё-таки задавался, пусть и не в первую очередь. Была мысль пилить движок и эрпоге одновременно, однако архитектура слишком далека от "вменяемой", и, если обвешаться ресурсами, ломать её до несовместимости будет не так весело. Хотя можно и попробовать.

Сейчас хочу запилить подгрузку мира на лету, поиск пути и пикрелейтед. (Моделька для MikuMikuDance). ОП Летающей Сырны, я знаю, что ты здесь, добра тебе. :3

>>7152
Ну, если бы я тебя чему хорошему научил... А то ты занимаешься той же ерундой, что и я — пишешь движок.

Кстати, было бы забавно написать что-нибудь вместе. :3

>>7152
О БОЖЕ
Ты совсем ебонулся? Зачем ты запиливаешь МЫЛО?

>>7152 а я тоже с mmd модельками баловался! Если придумаешь, как запилить там лицевую анимацию без переписывания всех вершин в буффере, буду очень признателен.

Проснулся. ^_^

Планы всё те же: >>7152, плюс переписать обработку сцены, да и всего остального, на триггеры-события.

DIVINE HALO

>>7467 красивенько! А pmd ты в свой формат конвертишь, или грузишь как есть? И анимации, судя по скрину, пока нету?

>>7467 забыл добавить, запили мягкие частицы, чтобы свет не пересекался с моделью, и будет вообще как в крузисе!

>>7472
Конвертирую в свой (http://www.vocaforum.com/showthread.php?t=1644). Анимация по ключевым кадрам есть, хочу IK.

Добавил поддержку DDS — соответствующий велосипед можно выбрасывать, т. к. отличия только в заголовке. ^^"

>>7491 DDS - это вообще лучшее, что придумали для хранения текстур. Жаль для моделей нет такого gpu-friendly универсального формата, близкого к промышленному стандарту.

Такие дела.

Пока зауряднейшие вэйпоинты и поиск в ширину. Предполагается допилить до A☆-like и разных нужных фич вроде отключаемых рёбер, хотя добавить противников можно уже сейчас, чем, наверное, и займусь. °w°

>>7582
Выглядит страшно неэффективно. Пили navmesh.

>>7584
Где бы про него почитать? Это по сути не тот же граф на вершинах / центрах трисов?

>Выглядит страшно неэффективно
На >>7582 15K вершин и 158K рёбер (~1.5 Mb). Тупой 15-минутный поиск в ширину через весь данж (путь в 160 точек) занимает около 8 мс (Intel P6200 @ 2.13 GHz), а реально будет ограничен парой десятков метров. Потенциально дополняется эвристикой и кэшированием. Так что именно для indoor подходит.

LET IT END IN HELLFIRE

Огненные глаза, огненная руна — надо было меньше играть в DCSS.

В кои-то веки запилил действия, т. е. вместо того, чтобы сдвигать объект на дельту каждый кадр, можно сказать ему перемещаться (поворачиваться etc.) с пользовательскими функциями обратной связи. ОЧЕНЬ удобно.

Пикрелейтед — постановка. Ещё напишу глазам ИИ.

Вторая после текстуры панцу вещь, качество которой меня устраивает — система сквадов, или команд персонажей и взаимоотношений между ними. На >>7618 их 3 — игрок, монстры и... трупы. Контролируемый ИИ персонаж, обнаруживая кого-то в радиусе видимости / поражения, выясняет, как же к нему относиться, и поступает соответствующе. Это стирает различие между игроком и другими существами и делает тривиальной реализацию сражений ИИ с ИИ и тому подобное. Пикрелейтед говорит сам за себя.

>>7618
>вместо того, двигать объект на дельту каждый кадр, можно сказать ему перемещаться
Расскажи, как ты это реализовал. Я пытался прикрутить физику и уйти к такой же системе от дельты, но где-то в этом месте застрял.

>>7698
Для создания анимации придуман довольно интересный подход, т.н. реактивное программирование: http://conal.net/fran/tutorial.htm
Использовать функциональные языки при этом не обязательно, нечто подобное реализовано, к примеру, в .NET.
Более сложная модель: использование для анимации физического движка. Для этого придётся находить моменты сил, которые нужно прикладывать к телам. Есть несколько готовых библиотек (Euphoria, сartwheel-3d), в простейшем случае можно попытаться изобразить что-нибудь своё с помощью PID-контроллеров.

>>7706
Анимацию прикрутить как раз не проблема. Проблема в том, как заставить его двигаться с нужной скоростью, правильно остановить в нужный момент времени, и еще в едином интерфейсе для передвижения у игрока и аи. Скорее в понимание того, как должна вести себя физика.

>>7707
Т.е. тебе нужно то, что ищется по ключевому слову character controller? Это делается с разным количеством хаков, насколько я знаю.

>>7698
Я говорил не о физике, а просто об архитектурном решении. Добавляешь узлу сцены действие и оно выполняется уже без твоего вмешательства, заканчиваясь одним из возможных исходов — done, stall, timeout, например. Что характерно, если передать рассчитанные скорости с силами сложнее физическому движку откуда и stall, всё работает, но я не очень на это полагаюсь.

Предсказуемо, A☆ быстрее волны раза так в 2, редко до 5. Неплохо.

>>7582
Сглаживание кубическими B-сплайнами.

>>7791 А каким образом ты точки для графа расставил? На регулярную сетку непохоже, неужели вручную? И это таки A-star, или пока еще нет?

>>7796
Да на скриптах за 5 минут!™ https://sourceforge.net/p/rr-rr/code/199/tree/trunk/shu-work/data/pathfinding.lua, 5K вершин и 60K рёбер за полсекунды. Но не помешала бы выборочная ручная доводка.

>И это таки A-star, или пока еще нет?
Самый что ни на есть A☆, он не сложнее Дейкстры. Кстати, неканонная эвристика уже не гарантирует оптимальность пути, но даёт интересные эффекты, например, если учитывать смену направления, получишь путь повышенной или пониженной извилистости. :3

>>7798 А каноничность эвристики достигается, насколько я помню, тем, что она должна возвращать значение не больше, чем стоимость пути по графу... Хотя может чего-то путаю.

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

В очередной раз, огромный тебе респект:3

>>7805
Если цель заметно сдвинулась, ничего другого и не остаётся, а вот для обхода препятствий есть http://alenacpp.blogspot.com/2005/10/steering-behaviors-opensteer.html. В демке OpenSteer (https://sourceforge.net/projects/opensteer/) очень здорово просматриваются состояния 'avoid obstacle' и 'seek & evade'.

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

Идея >>7806 не нова (кто бы сомневался), в UDK есть похожая сущность — Pawn. По задумке это максимально настраиваемый персонаж с кучей функций обратной связи и интерфейсом, предусматривающим управление как игроком, так и AI. Посмотрим, что из этого выйдет.

Добавил Trigger Volumes — физические тела, не участвующие во взаимодействиях, но отзывающиеся на попадание других тел внутрь. Вообще-то Newton 2.xx их не поддерживает: как ВНЕЗАПНО выяснилось, NewtonCollisionSetAsTriggerVolume — пустышка. Автор обещает добавить в Newton 3, а пока буду эмулировать жутко неэффективным отбрасыванием контактов в narrow phase.

В чём суть игры? какую помощь желал бы получить?

>>7969
>В чём суть игры?
Набросал.
>какую помощь желал бы получить?
Только контент. В первую очередь — mid-poly модельки монстров со скелетами до 80 костей, предметов, окружения и звуки.

>>7971
как алиса мак_ги?

>>7972
Ну да, по сути TPA.

>>7973
Для чего всё это, игра мускулами, проверить себя? На сколько серьёзные намерения? Будет ли доведено до конца? Когда будет готова?

>>7974
>игра мускулами, проверить себя
this
>На сколько серьёзные намерения
Ни на сколько.

>>7975
жаль

>>7975
Ничего, потом придешь устраиваться на работу, тебя попросят показать, что ты умеешь, а ты им сходу: смотрите, какой я крусис запилил, с такими-то Суигинтой и травоном, и тебе сразу дадут должность ведущего программиста/руководителя проекта с окладом в $5к, красный Астон-Мартин с личным водителем, и гарем с пятью наложницами.

>>7971
А с какой целью булевые характеристики у тебя выражены цифрами?

>>7978
Внимательнее.
>Все числа — вещественные.
Num6/Num9 в демошке. Просто прикинул масштаб на случай, если захочу указать конкретные значения.

>>7971
Неужто совсем не будет монстров, не убивающих с одного удара?
>Огненный глаз
Может будет лавовый слизень, плавающий в лаве?

Полет чем-то напоминает Descent. Требую оставшиеся 2DOF.

Как же в этой игре Суигинто достать?

>>8040
В ранних версиях?

Добавил следование пути, пока что без стирингов. Поговаривают (слышал у Алёны C++, вроде), что перемещаться в пределах видимости можно исключительно стирингами — в таком случае понадобится на пару порядков меньше вэйпоинтов. Но это в другой раз.

Из мелочей: подобие групповых делегатов в качестве обработчиков событий. На стороне скрипта, конечно.

Press X, чтобы понять всю прелесть КУКЛЫ. :3
WAЯNING: на данный момент в демке сломано всё остальное. Кроме того, компьютер не догадывается о существовании дверей, поаккуратнее с этим.

>>8040
Не понял тебя.

Отключаемые рёбра — done. Дверь — не самый удачный пример, но для более перманентных препятствий это нужная фича.
Была мысль генерировать данж (полу)случайным образом, как в рогаликах.

1. Нарисовать таких вот клеточных ваултов и сопоставить каждому скрипт.
2. Сгенерировать данж, сохраняя данные о заюзанных ваултах.
3. Воспроизвести ваулты.
4. ???
5. PROFIT!

>>8241
Ну и шг, у меня глаза вытекли.

>>8242
А так? :3
Пиксельность и моноширинность нужны, знаешь ли.

>>8243
Ничего не изменилось. Не знаю, какой у тебя шрифт, но поставь лучше terminus. Он почти идеален для "пиксельности и моноширинности".

>>8244
Поставил. Спасибо за совет, но не вижу преимуществ перед Courier New: непривычно.

>>8245
Это был не совет, а просто мысль вслух. Без сглаживания у courier new жуткий алиасинг.

>>8246
>сглаживания

>>8247
ClearType и blur - совершенно разные вещи.

>>8245
Попользуйся терминусом пару дней, потом попробуй прочитать страничку с комментариями курьером.

>>8249
Ага. Клиртайп ещё добавляет жирную тень, шоб мылом реще глаза резало.

>>8243
Склонность к генерации циклов (мне всё-таки не нужен лабиринт-дерево) добавлю позже. С другой стороны, реальные ваулты будут крупнее и должны брать качеством.

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

>>8258
Стандартные спайки всё-таки лучше "воротничков".

Выложил билд с генерацией. Карта сохраняется в data/dungeon/visualize.
Не пытайтесь перерисовывать data/dungeon/＊.vaults, это всего лишь информация для алгоритма.
И не дошли пока руки до склеивания вейпоинтов, так что поиск пути не работает.

Неплохо бы в кои-то веки добавить геометрические шейдеры для партиклов и UBO/TBO.

Запилил в билд спойлер постпроцесс в такт музыке ^_^
а если не только амплитуды, но и спектр учитывать...

>спектр учитывать
done

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

>>8328
Сам не представляю интуитивно, как оно вычисляется. Ну я и б-дло. Позже разберусь.

>>8328
http://www.ega-math.narod.ru/Nquant/Fourier.htm
http://www.dsplib.ru/content/propdft/propdft.html

>>8316
>геометрические шейдеры для партиклов и UBO/TBO
Пожалей людей с интелом вместо видеокарты и месой вместо драйверов. Оставь фоллбек какой-нибудь.

Надо все-таки попробовать добраться и посмотреть на твой код будет.

>>8328
И дискретное преобразование Фурье и интегральное - это по сути разложения вектора сигнала по базису из комплексных экспонент. k-й коэффициент разложения вектора s по ортонормированному базису {e} равен проекции s на e_k. Проекция вектора на вектор единичной длины, как известно, делается с помощью скалярного произведения (s, e_k).
Если посмотреть с этой точки зрения на формулы дискретного преобразования Фурье, можно понять, что они представляют собой просто скалярные произведения базисных векторов на вектор сигнала.

>>8335
Уже не пожалел, т. к. GLSL 1.40 и FBO — это OpenGL 3.1, поддерживающая GS/UBO/TBO по определению. Даже если запилю фолбэк вплоть до 2.1 (а то и FFP), выглядеть будет ужасно.

>>8336
>просто скалярные произведения базисных векторов на вектор сигнала
Не >>8328-кун, но это я и хотел услышать.

>>8336
>вектора сигнала
Чё?

Сигнал я представляю в виде функции y=f(x) (или как последовательность квантованных отсчётов), а при чём тут векторы я не въезжаю.

>>8339
Имеется в виду, вектора в пространстве функций. Базисные векторы - базисные функции e^{ikx}.

>>8339
> при чём тут векторы
Под "вектором" часто понимают элемент евклидова пространства. На самом деле это понятие шире, поскольку в математике введено в принципе бесконечномерное обобщение евклидова пространства - гильбертово пространство. Его аксиомам удовлетворяют в том числе и определённый класс функций, если скалярное произведение определить как

\langle f | g \rangle=\int_a^b f(x) \overline{g(x)} dx

Интегральное преобразование Фурье понимается просто как разложение вектора (в данном случае функции) по соответствующему базису в гильбертовом пространстве.

В случае дискретного преобразования Фурье всё проще. Допустим, мы хотим вычислить преобразование Фурье для функции f(t), t - n чисел. Вектор сигнала f = {f(t)|t∈t} (мы подставляем в f все значения из t).
Аналогично определяем базисные вектора e_i. Тем самым, мы получили базис и вектор в n-мерном пространстве. Разложение f по базису e_i и будет преобразованием Фурье.

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

>>8351
А нельзя просто следить и сообщать об этом родному потоку? Пусть сам освобождает.

>>8352
Ага, так и сделал, просто непонятно, какая разница для драйвера — он-то всё равно в своём потоке крутится.
Безумная идея #16: вынести GL-контекст в отдельный поток

>>8355 Есть еще такой хак: в потоке загрузке создается еще один контекст OpenGL и расшаривается с основным контекстом. Тогда у них общие ресурсы, контекст рендера может их читать из контекста загрузки. И тогда геометрию и текстуры можно грузить/удалять в отдельном потоке, только надо постоянно делать активным соответствующий контент.

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

>>8357
Да пожалуйста. А МОДЕЛЬКИ РИСОВАТЬ КТО БУДЕТ?!
>>8356
Видел. Пока забуду про рендер в отдельном потоке, но если дойдут руки — так и сделаю, ибо
>SDL
>Its wrong to create windows in other threads than the main one
Или вот прямо сейчас возьму и откажусь от SDL, т. к. она сложнее, бажнее и беднее по функциональности pimpl'а над винапи. Понимаю, наименьший общий знаменатель платформ и всё такое, но сам её дизайн начинает надоедать.

>>8358
>А МОДЕЛЬКИ РИСОВАТЬ КТО БУДЕТ?!
A где ты украл текущие крези-лесбо-модельки? Поищи у фаготов из страны восходящего крези-лесбо-солнца. Полюбому есть.

>>8358 А вместо SDL рикамендую glfw, она кроссплатформенная и умеет создавать окно, обрабатывать основные события и обрабатывать ввод.

>>8359
＊_＊
>>8365
Да ладно, я уже выбросил SDL, раскопал древнюю обёртку над винапи и добавил в неё MSAA и Forward Compatible контексты. Не хочу работать с окном как с синглтоном.
Версия GL-контекста в текущем билде — 3.0, но рассчитываю на 3.2.

Как это запустить?

>>8358
Вот я тоже хочу выкинуть сдл. Она и не нужна особо, если все рендерить через glut, а загружать через soil. Вот только проблема во всяких ее плюшках, типа сдлинпута. Чем ты обрабатываешь управление? Чем можно одновременно обрабатывать и геймпад и клавиатуру и еще какие-нибудь безумные контроллеры?
>winapi
Хотя, я кажется понимаю. У вас таких проблем обычно нет.

>>8372
>Чем ты обрабатываешь управление?
WM_KeyDown, WM_KeyUp :)
>Чем можно одновременно обрабатывать и геймпад и клавиатуру и еще какие-нибудь безумные контроллеры?
RegisterRawInputDevices / WM_Input. На всех платформах будут аналоги.

Еще архивчик. В покеболе крези-лесбо-няша

>>8374
>будут аналоги
Так почему же нам не написать кроссплатформенную библиотеку инпута с нуля, попутно ознакомившись с работой устройств ввода на каждой платформе? Спасибо, с этим я и так знаком, как-то приходилось уже дебажить сдл, когда я нашел там баг (с которым меня послали, кстати, сказав, что они делают новый анальный сдл 1.3, а старые фиксить не будут), а так же писать какие-то простенькие тестеры под джойстики. Больше не хочу. Я и так взял на себя труд писать всю эту ерунду с нуля, пусть хоть лоулевел штуки делает чужой код, который не нужно поддерживать.
>WM_KeyDown, WM_KeyUp
Вот за отказ от подобной статической привязки в пользу динамических биндингов я и поплатился привязкой к удобству SDL_PollEvent, и не могу найти ему замены, чтобы не пришлось переписывать всю систему ввода, хотя она мне и жутко не нравится в нынешнем состоянии.

Всё же помучаю MTR в порядке эксперимента. Не факт, что вообще взлетит, но если компиляция шейдеров на лету станет хоть чуточку менее заметной — буду рад.

>>8380
>сказав, что они делают новый анальный сдл 1.3, а старые фиксить не будут
По этой же причине дропнул. Какие проблемы с кроссплатформностью через cheshire cat aka pimpl? Один раз обернуть API платформы и запрятать подальше, делов-то, зато взамен — полный контроль над ситуацией.

>>8377
https://crawl.develz.org/tavern/viewtopic.php?f=8&t=5383
Крези-лесбо-Стив, это просто 100/100 какое-то, где ты их берёшь?

>>8388
Можно сунуться в этот крези-лесбо-сервер ftp://sub.monster-girl.zamanen.net/ Попробуй повыкачивать архивчики - в них может быть что-нибудь интересненькое (даже незаконченные игры например)
Алсо, если нет проблем с форматом моделек, то я жду с нетерпением скриншоты :3

>>8388
>Какие проблемы с кроссплатформностью через cheshire cat aka pimpl
Поддержка. Это только кажется, что это одноразовый код, но потом начинаются какие-то проблемы с поддержкой, а время, по большому счету, тратится в никуда, потому что заново пишешь с нуля то, что уже написали другие.

> Так почему же нам не написать кроссплатформенную библиотеку инпута с нуля
OIS есть, но я не знаю, как она.

Экспериментальная версия рендера в отдельном потоке.
Отключаемый. По умолчанию включен в дебаге. Из-за моих безумнейших умений по части синхронизации ОЧЕНЬ забагован. Буду исправлять баги и уменьшать число точек синхронизации, т. е. рефакторить команды, возвращающие значение — те же CompileShader или LinkProgram вполне могли бы тихо сохранять флаг ошибки, а то их даже в очередь не поставишь.

Багрепорты, при условии, что однопоточные версии работали, а эта чудит — приветствуются.
Известные проблемы (зависят от конфигурации и фазы Луны; кроме первых двух, с какого-то момента не встречал — возможно, уже исправил):
— в консоль сыпятся ошибки OpenGL
— статистика видеопамяти показывает чушь
— преломления и тени теряются / заполняются мусором
— рандомно теряются таргеты с Bright Pass и SSAO
— вылет при попытке перезагрузить постпроцесс.
Ха, будто это делает его менее крутым! :3

>>8406
Рано радовался. По неизвестной мне причине оно по-прежнему не даёт удалять GL-ресурсы из другого потока — тупо падает с AV. (屮ﾟДﾟ)屮

>>8407
Отбой тревоги, лол, я просто забыл включить отдельный поток в тот раз. В общем, извините, Стивы, но отныне рендер будет только в отдельном потоке. Это очень красиво решает проблему владения OpenGL-контекстом — "не доставайся же ты никому".

>>8408
Напомни, зачем тебе рендер в отдельном потоке. Улучшилась ли производительность, или весь профит съели синхронизации? В DirectX SDK не советовали выделять рендер в отдельный поток и я склоняюсь к их мнению.
С высоты моего дивана мне кажется, лучше уж распараллеливать вычислительно сложные участки, но сами их пускать последовательно.

>>8409
Сейчас исправил часть багов — практически не изменилась, -8～+5%. Учитывая, что есть способ убрать всю синхронизацию, кроме EndFrame, могу предположить, что она станет-таки немного быстрее. Но дело даже не в FPS. Главный аргумент —
>Это очень красиво решает проблему владения OpenGL-контекстом — "не доставайся же ты никому".
Мне нужен был способ отвязать контекст OpenGL от главного потока, чтобы манипулировать GL-сущностями откуда угодно (>>8351).

>>8411
Т.е. дело в том, что нужно освобождать ресурсы с какой-то задержкой, а удалить их можно только из главного потока? Не смотрел сторону реализации простейших green threads?

>>8413
С ConvertThreadToFiber работает чуть медленнее.
>In general, fibers do not provide advantages over a well-designed multithreaded application.
В очереди бывает по 150 отложенных команд, при том, что в кадре всего 200. А ещё я уберу синхронизацию отовсюду, кроме EndFrame и совсем уже маргинальных GetTexImage/GetRTImage. Так что пусть будет нормальный поток.

Разобрался с синхронизацией. Абсолютное большинство багов магическим образом испарились.
Меня пикрелейтед смущает T_T

>>8419
Енжой ёр социальная сеть.

А вообще ни описания, ни ридмишки, ни мануалов, ничего.
Так и быть, скачал, запустил, получил йух на рыло. Хотел минусануть, но аккаунта нет.

>>8420
Отдельные элементы ≠ социалочка, SF не ставит такую цель.
...хм, только из-за 3.0-lvl glGetStringi? Обновил, перескачай. И карточку скажи.

>>8421
Да все равно ругается на старый ОпенГЛ. Карточка - древнее ноутбучное оно мамонта radeon x1150, новых драйверов под нее давно нет.

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

>>8425
Если SF - социалка, то github - филиал 4chan. До сих пор вспоминаю тот тред про баг в bumblebee.

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

Дан буфер. Некоторые его участки (отмечены красным) необходимо обновить. Цена обновления диапазона ячеек с M-й по N-ю — A + B＊(N - M + 1). Вернуть f(buf, A, B) — список диапазонов. Обычно A >> B, но это не обязательно.

Пригодится для любых буферов в VRAM, не только UBO. Если не найду (не подскажешь, Стив :3) готовый велосипед — запилю жадный алгоритм.

UBO — done. Сугубо опционально.
Реализовать расшаривание буферов между шейдерами было бы затруднительно в рамках текущей архитектуры и совместимости с олдскульными юниформами, да и не нужно это. Основной профит — меньше вызовов API.

Правда, пока сражался с дровами, разочаровался в обоих вендорах.

>>8430
Просто ты слишком спешишь угнаться за стандартом.

>>8429
done
по-хорошему надо запоминать, какие юниформы изменились, а не сравнивать весь блок памяти, но это далеко не боттлнек

>>8432
Да я понял уже. В любом случае, не пойду дальше GL 3.2. Из интересного могу вспомнить геометрические шейдеры, R2VB, TBO, текстуры с мультисэмплингом, Async Queries и Transform Feedback, но не уверен, что все эти фичи оправданны, так что просто добавлю GS (системы частиц, шлейфы и т. п.) с фоллбэком на динамические меши и графон можно до поры до времени считать завершённым.

>>8434
Да, вот расскажи про отпимизацию юниформов. Что-то я заметил, что изменение одного чаще чем раз за кадр (флаг использования нормалмапов) роняет мне производительность чуть ли не на сотню фпс.
А gs для системы частиц - это хорошо, но у нее нет фидбека и использовать эти мощности для каких-то игровых механик не получится, только красявости.

>флаг использования нормалмапов
O_O Неужели динамический бранчинг? На GPU if — достаточно дорогое удовольствие, даже с юниформом. В убершейдерах такие вещи разруливаются дефайнами и компиляцией нового шейдера для каждого набора флагов.
UBO дали от силы +2-4% FPS, т. к. производительность в юниформы и не упиралась.

>у нее нет фидбека и использовать эти мощности для каких-то игровых механик не получится
Но ведь я знаю, что прописал в GS. Это всего лишь снимает нагрузку по передаче данных механики рендеру: в лучшем случае — полностью, но и юниформы + out'ы VS дешевле динамических мешей. Что-то я растеоретизировался, пойду покурю GS.

Я все-таки добрался почитать твой код. В чем ты его пишешь, кстати? Без нормальной иды эти простыни очень трудно читаются человеком со стороны. Хотя, разработчику проще, думаю. Некоторые интересные идеи уже взял на заметку.
Расскажи про свой темплейтер для шейдеров. Синтаксис того, что лежит в ресурсах не совпадает с тем синтаксисом, что обрабатывает парсер, что я у тебя нашел, поэтому я предполагаю, что он работает по какой-то запутанной схеме.

>>8454
Кстати, да, может у тебя есть какой-нибудь жаббер, чятик, гуглоплюс или иная какая-нибудь социальная ерунда, где бы я мог спрашивать разные глупые вопросы по твоему коду, не засоряя тред?

>>8455
>IDE
Lazarus.
>интересные идеи
Ты мне льстишь.
>темплейтер для шейдеров
Этим занимается отдельная структура (tShaderParser @ framework/GL/GLBase.pas), она кроит шейдер на кусочки, а потом собирает назад в уже известном контексте. Обычно так не извращаются, обходясь препроцессором (http://users.livejournal.com/__vortex__/3391.html).
>вопросы по твоему коду, не засоряя тред
Арта по Дайбастеру немного, так что всё в порядке.

Занятная вещь. Так и вижу шлейф-линию, на лету разворачивающийся в полигональную кашу.

>>8458
А у тебя где-то в репозитории есть файлы проекта, чтобы я мог тем же лазарусом собрать, ничего не потеряв и не тратя уйму времени на поиски нужных параметров?

>>8453
> На GPU if — достаточно дорогое удовольствие
Не всегда. У nvidia производительность ухудшают только ветвления внутри одного блока потоков.
> даже с uniform
Недоработанность драйверов?

>>8467
>Недоработанность драйверов?
Судя по тому, что производительность падает и на радеоне и на интеле, либо это недоработки месы в одном и том же месте, либо что-то еще.

>>8465
есть https://sourceforge.net/p/rr-rr/code/232/tree/trunk/ — достаточно shu, shu-work и framework раньше можно было скачать тарбол, сейчас вроде только svn checkout.

>>8467
Видел, как на SM3.0-capable гефорсах тормозил for по uniform int nLights. Это не сломило мой дух касательно тяжеленного бранчинга в фрагментном шейдере для тех же CSM, но поумерило желание рисковать производительностью на пустом месте. В лучшем случае это лишняя работа драйверу, в худшем — лишний условный блок.

Ответь мне няша как на духу! Ты со всякими примочками балуешься или игру делаешь? Если не игру, то желаю тебе сажи еще на десять тысяч минусов на страничке твоего проекта, если игру, то где мои монстро-няшиаааааа?

>>8481
> Видел, как на SM3.0-capable гефорсах тормозил for по uniform int nLights.
Я к тому, что само железо в принципе способно обрабатывать ветвления без оверхеда при некоторых условиях. При реализации GAPI этим, видимо, не воспользовались.
И насколько честный цикл тормозил по сравнению с unrolled?

Ты так теперь и дебажишь, ОП?
Конечно, так повеселее стало, но ни черта не видать же.

>>8484
Насколько я помню, ~3x, в обоих случаях производительность упиралась в FS.
>>8483
Можешь считать, что с графоном я закончил. ^^"
Сейчас вот допилю пару мелочей (склеивание вейпоинтов, партиклы) и подумаю насчёт контента.
>>8494
Чего-чего?

>>8497
Музон и мыло на экране.

>партиклы
"GPU idle? Add triangles for free!"
Случайно шлейф из 120K динамических треугольников, FPS по-прежнему ограничен только филлрейтом. На этапы графического конвеера, не являющиеся боттлнеками, добавлять нагрузку можно забесплатно. А я не верил.

>>8514
Добавь им текстуру. Получишь 0.

>GS (системы частиц, шлейфы и т. п.) с фоллбэком на динамические меши
done. Можно стрелять друг в дружку. ^_^
По идее, разницы с вёдрами с гайками неподдерживаемыми карточками быть вообще не должно. GS отключаются автоматически или в конфиге (GL.allowGS); если шлейфы выглядят по-разному или GS вообще падают — попрошу доложить.

>>8515
Не-а. Интерполятор больше не прохлаждается, но всё в порядке, ~40 FPS в той же ситуации.

>>8517
А какая у тебя карточка, кстати?

>>8518
Radeon HD 6370M, дрова — лето'2010 (8.741.1.5000, заявлен GL 4.0). 0.0036_GS больше нигде не тестировал. Есть и помощнее: GeForce 8500/9500 GT, различающиеся только количественно, и GeForce GT 630M.

Вернул возможность выключить рендер в отдельном потоке. Изредка сваливало карточки в что-то вроде софтвара, да и gDEBugger тихонько ругается. Хотя ситуация, на которую он указывает — получение GL-функций в одном контексте и вызов в другом — в принципе невозможна. Чудеса.
To-do: склеивание вейпоинтов. Поиск пути выглядит сломанным, но это не так. :3

>>8434 Расскажи поподробнее про алгоритм. Я как понимаю, что это для того, чтобы morph-анимации лица из MikuMikuDance работали? Тоже хочу загрузить такую сырну:3 Не могу придумать ничего лучше, чем пробегаться по всем вершинам в копии буффера в RAM, отмечая непрерывные изменившиеся куски, и их уже заливать в VRAM.

>>8547
Нет, просто для UBO, потом соптимизировал сравнением "версий" юниформов (нативных интов). Алгоритм банальный, это я себе чего-то навыдумывал: из A и B вполне себе следует максимальное расстояние между поддиапазонами. Можно использовать и для динамических мешей, но я не заморачивался и просто сообщаю, что изменился такой-то диапазон такого-то атрибута / индексов или весь меш. Morph не трогал.

kD-дерево путевых точек, например.

>склеивание вейпоинтов
done. С >>8581 работает относительно шустро. А учитывая, что проверяется весь присоединяемый кусок, хотя достаточно пересечения с новым соседом — можно соптимизировать до мгновенного.

>>4274
А расскажи, как ты передаешь юниформы в шейдеры. Непосредственно перед их использованием? В каких-то других местах? Как ты определяешь, какой юниформ какому шейдеру нужно забиндить? Или у тебя все статично?

Автор можешь запилить сырну в NIF формате?

Оп, ты молодец. Удачи тебе и всего самого лучшего. Можно я тебя обниму?

>>8602
:3

>>8593
Экспортнул плагином.

>>8592
Некоторые GL-сущности хранят таблицы именованных параметров, чьи типы примерно соответствуют типам юниформов: float-vec2-3-4, текстура и так далее. При создании шейдера из него вытаскивается сводка юниформов, и с каждым биндом выполняется поиск по именам в рендеробжекте, материале и в глобальной таблице — именно в таком порядке. Сравнение и хэширование строк сводится к сравнению и хэшированию указателей (пул строк), поэтому поиск несравнимо быстрее самого glUniform＊.

С таким подходом я могу создать материал "сферическое стекло в вакууме" с refrCoeff = 1.2, reflectivity = 0.5, baseColor = (0.0, 0.1, 0.3), о которых движок ничего не знает, и выборочно перекрыть эти значения в конкретном объекте.

>>8626
Я уже примерно так и сделал, но чуть попроще, ибо сильной детализованности не нужно, и вместо строк использую индексы, присваеваемые на этапе инициализации, на элементы массива с описывающими тип объектами, это вообще 2-4 asm вызова, быстрее уже некуда. Единственный недостаток, что приходится прописывать в конфиге у каждого шейдера имена юниформов и их тип, но не так уж это и плохо на самом деле.
>baseColor
Мне кажется, удобнее это хранить в VBA, чем в материале, разноцветные материалы делать проще. Правда оверхед при загрузке данных небольшой (в 3 раза меньше, чем вершины, все равно), но это исправляется отправкой только изменившихся данных, хотя это и труднореализуемо.
А сколько у тебя гл-вызовов на рендерлуп? Я бы сам посмотрел апитрейсом, но из линуксов твою штуку все никак не возьмусь собрать.
Есть еще одна идея, которую я думаю реализовать. Анбиндишь ли ты семплеры после того, как ими воспользовался? Если, предположим, сделать пулл забинженых текстур и менять индекс семплера, посылаемый в шейдеры, а текстуры обновлять только когда в пулле кончается место, начиная с самой поздней? Мне кажется, можно неслабо сэкономить на ребинде, что является достаточно дорогой операцией, особенно если вместо текстур большие атласы.

>>8632
>Единственный недостаток, что приходится прописывать в конфиге у каждого шейдера имена юниформов и их тип
Запросить (http://www.opengl.org/sdk/docs/man/xhtml/glGetActiveUniform.xml) религия не позволяет?
>удобнее это хранить в VBA, чем в материале, разноцветные материалы делать проще
Не понял тебя. VBO? В вершинах? Во-первых, удобнее это хранить в текстурах. Тот материал по смыслу однотонный, но ок, #define GLASS_MAP, baseColorMap = "glass-color.dds". Vertex Paint всё же немного для других целей, а VertexAttribDivisor — изврат.
>А сколько у тебя гл-вызовов на рендерлуп?
На той же сцене, что в билде, в среднем 1-2K на кадр. >1.2K — это если пострелять.
>Анбиндишь ли ты семплеры после того, как ими воспользовался?
Я задаю сэмплеры единожды при создании шейдера, а потом просто биндю текстуры в соответствующие юниты. Что быстрее, ActiveTexture + BindTexture или Uniform1i + те же Active/BindTexture, если не повезёт — не проверял.

>>8633
>glGetActiveUniform
Так еще проще, я как всегда про него забыл, спасибо.
>VBO
VAO, который array object, не VBO, я все время путаюсь в написании.

Добавил полную поддержку юникода в именах файлов, включая самодельные паки. Точно, у меня же ещё паки есть! :3 Идея последних из http://insidecpp.ru/art/44/ , хотя встречаются они повсеместно.

>>8643
Разве этим не должна заниматься ОС и файловая система? 2013 год же, пора бы уже поддерживать юникод.

>>8644
Ни винда, ни FPC RTL не дружат с няшной UTF-8, пришлось импровизировать посредством UTF8Encode/Decode.
А ещё теперь можно переключаться между полноэкранным и оконным режимами на лету (Alt-Enter).

>>8643
>http://insidecpp.ru/art/44/
Эта лабуда касается только нтфс-а, или прыщефс тоже таким страдают?

>>8648
Не должны, по идее.

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

Апофеозом неведомой хрени, на которую я последнее время отвлекался (>>8643>>8646), стала безумная идея сериализовывать целые числа адаптивно: NNNNxxxx xxxxxxxx xxxxxxxx ... , где NNNN — количество байт. (Как ни странно, это нисколечки не ухудшает сжимаемость). Вовремя проверил на MemoryStream'ах и понял, что выигрыш в размере того не стоит, хотя...

И добавил мини-карту. :3

>>8648
Логично предположить, что это актуально для любой не-readonly ФС. Когда загрузка упирается в чтение с диска, разница заметна на глаз. Кстати, такой велосипед давно изобретён и называется PhysicsFS.

Оп, можно ли как-нибудь с тобой связаться, кроме как тут?

>>8687
>или иная какая-нибудь социальная ерунда
Вообще есть G+ и тентакль, но предпочёл бы автобус. :3 В любом случае, в течение этой недели вряд ли отвечу.

Прикрутил поддержку MIDI с принудительно пользовательскими SoundFont'ами. Так что звучание MIDI-композиций можно полностью преобразить, заменив lib/etc/Scc1t2.SF2 из архива на что-нибудь поувесистее, вроде http://uk.un4seen.com/files/extra/ChoriumRevA.zip .

Впрочем, если "упаковка" и "распаковка" .sf2 работают, запакую-ка я второй "шрифт" в lossy...

>>8748
Разобрался, как применять к SoundFont'ам внешние кодеки, но что MP3, что OGG, что AAC даже на максимальных настройках делают с сэмплами, особенно высокочастотными, нечто ужасное. Запаковал прежний набор во FLAC в качестве proof of concept.

>>8749
>что MP3, что OGG, что AAC даже на максимальных настройках делают с сэмплами, особенно высокочастотными, нечто ужасное
А можно вот поподробнее про это, а то мне интересно стало.

>>8750
Сейчас проверил — дело в другом: они могут изменить время, добавив тишину по краям ради упрощения ДКП, оконных функций, психоакустики и всего такого. Для большинства сэмплов это недопустимо. Пикрелейтед и http://lame.sourceforge.net/tech-FAQ.txt :
>encoder/decoder delay at start of file
>1056 sample delay
Характерно не только для MP3.

Прикрутил к пакам zlib.

>>8756
...и LZO (http://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Oberhumer). Метод сжатия каждого файла в отдельности выбирается эвристикой. Так, если LZO не сильно отстаёт в степени сжатия от Deflate, будет выбран именно он как более шустрый.

>>8699
Оставь тентакль, молю.

>>8758
kudere

>>8759
Дуров украл у меня вконтакт, поэтому я нашел тебя в плюсаче, пусть будет. Не->>8758

Заодно прикрутил LodePNG (http://lodev.org/lodepng/) вместо очень уж тяжёлой DevIL.

Почему именно LodePNG? Да потому, что интерфейс канонной libpng писали идиоты, даже zlib после ЭТОГО кажется изящной. Всегда продумывайте свои API. Пожалуйста.

>>8762
Посмотри на SOIL, там 3,5 файла, c, маленькая статиклиба, public domain. Есть поддержка S3TC, правда она поганит текстуры. Сохранения в пнг нету, но я форкнул и как-нибудь допишу.