>>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