Вброшу свой крузис. http://sourceforge.net/projects/rr-rr/
Больше всего понравился чайник.
>>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 Зоны выглядят попроще и без жёсткого разграничения на этажи. Хотя это будет работать быстрее, да.