Добавлена первая демка “Cathedral” - демонстрирует игровой уровень с основными физическими законами.
Подробно здесь
Скоро выложу еще 5 демок!
Добавлена первая демка “Cathedral” - демонстрирует игровой уровень с основными физическими законами.
Подробно здесь
Скоро выложу еще 5 демок!
приветствую :))) Охото пощупать твой движок, можешь поделиться? И не плохо было бы доки
Все в свое время. Сейчас исправляю баги, вывожу пользовательские настройки и пишу документацию.
Движок планируется быть бесплатным?
Для некоммерческого использования да.
Спасибо за интересные статьи.
Оч понравилось.
Красиво! А с движущимися персонажами что-нибудь из демок планируется?
Спасибо, да и с динамическими объектами будут демки.
Ууу 5000++ треугольников в кадр, это круто. Качество значительно лучше, чем на аналогичных движках. Хотя видно перспективную коррекцию, но значительно меньше чем на других движках. Я на http://www.flasher.ru читал что у вас в движке есть пиксельная коррекция, в этой демки она не включена почему? PVS - это хорошо серьезно расширяет возможности. Поражает RenderTime для 5000++ треугольников всего 3 миллисекунды - это же сколько надо было шаманить над математикой движка и алгоритмами. В демках Papervision 30-40 миллисекунд тратится на просчет всего 2500 полигонов.
Очень хочется попробовать движок в деле.
Михаил, да в движке есть и пиксельная перспективная коррекция. Демка опубликована на старой версии движка (3 поколение), в 4 поколении удалось настолько ускорить пиксельную коррекцию, что адаптивная триангуляция больше не нужна, визуальная информация всегда выводится в самом высоком качестве. Более того, благодаря новым алгоритмам объединения полигонов в группы по принадлежности материалам, удалось получить еще и прибавку в скорости. Скоро выложу эту демку на новой версии движка, прибавка в FPS около +15FPS.
последний пост автора звучит несколько пафосно, осмелюсь прокомментировать
1) “в 4 поколении удалось настолько ускорить пиксельную коррекцию, что адаптивная триангуляция больше не нужна, визуальная информация всегда выводится в самом высоком качестве” - просто напросто адоби добавил drawTriangles в 10-й плеер, который умеет делать перспективную коррекцию.
2) “Более того, благодаря новым алгоритмам объединения полигонов в группы по принадлежности материалам, удалось получить еще и прибавку в скорости.” - опять же, это скорее недоработка drawTriangles, позволяющего текстурить только одним битмапом за вызов.
3) Выскажусь по общей скорости демок - скорость такая же, как и у аналогичных по сложности демок других движков, так как на 90% тормоза рендеринга обусловлены внутренностями векторной рендерилки флеш-плеера.
ну а так, в общем, демки приятные, автор молодец.
- Вы понимаете движок использует все методы отрисовки, в зависимости от ситуации (например от угла и размеров полигонов). Так же метод drawTriangles сам по себе медленный и заставить его работать на приемлемой скорости можно лишь отправлением в него данных в оптимизированном виде - это и есть ускорение.
- Ничего общего с данным подходом нет, те кто работал с движками на С (или на других “высших” языках) поймут о чем речь.
- Да есть у flash ограничение по fillRate, но как вы понимаете с этим нечего не сделать.
Скорость достигается за счет мат. расчетов, если другие движки тратят 40-80 милисекунд на обработку 3000 полигонов, то мой движок тратит 3 - 7 милисекунд. Думаю понятно, что если на мат. расчеты затрачено 40-80 милисекунд, то смысла отправлять на отрисовку нет т.к. FPS уже ниже 15, а после отрисовки будет 0 - 2.
Как информация, демка “Cathedral” тестировалась на всех известных движках и не на одном она не показывала даже 10 FPS. Причина проста в демки за кадр рисуется 3000 - 5700 полигонов, все тестируемые движки тратили от 40 - до 280 милисекунд на мат. расчеты.
Если все это обобщить и взять к примеру одинаковую область отрисовки, например 640х480 (т.е площадь отрисовки одинаковая ==> fillRate одинаковый), то другие движки смогут выводить до 3000 полигонов при FPS не ниже 25, а мой до 18000. Вот в этом и заключается производительность.
P.S.
Стоит отметить:
1) тесты проводились на Intel Core 2 Duo E4600 2.4 Ghz;
2) чем мощнее компьютер, тем больше будет скорость моего движка в сравнении с другими, т.к. скорость растет не пропорционально;
3) ради эксперимента демка недавно тестилась на Intel Core 2 Quad Q9300 2.5 ГГц и выдавала 71 minFPS при размерах flash окна 800х600;
4) не стоит забывать, что нет у других движков возможности выводит динамические объекты с такой же скоростью как и статичные.
1) “Скорость достигается за счет мат. расчетов, если другие движки тратят 40-80 милисекунд на обработку 3000 полигонов, то мой движок тратит 3 - 7 милисекунд. Думаю понятно, что если на мат. расчеты затрачено 40-80 милисекунд, то смысла отправлять на отрисовку нет т.к. FPS уже ниже 15, а после отрисовки будет 0 - 2.”
давайте согласимся с тем, что разные движки заточены под разные задачи. Нет ничего удивительного в том, что ваша сцена оптимизирована под ваш же движок (разбиение на замкнутые комнаты + pvs, заданный наверняка вручную, и т.п.) и тем самым достигается вышеуказанная производительность. Это вполне нормально и для таких узкоспециализированных задач вполне подходит. Но давайте так же согласимся с тем, что движок, который может более-менее адекватно рендерить куда более разнообразную и менее подготовленную сцену (та же альтернатива) - заметный шаг вперед по сравнению с узкоспециализированными движками. В цикле производства всегда присутствуют несколько людей, и не обязательно там будет специалист, который так же хорошо как вы знает внутренности вашего движка, сильные и слабые стороны. А сможет ли ваш движок нормально отрендерить неподготовленную сцену, сделанную дизайнером средней руки - большой вопрос.
Достигнуть же пиковых скоростей в рендеринге специально подготовленных сцен - не проблема, все упирается в филлрейт, математика проценты отбирает.
2) “Так же метод drawTriangles сам по себе медленный и заставить его работать на приемлемой скорости можно лишь отправлением в него данных в оптимизированном виде - это и есть ускорение.” - все методы отрисовки упираются в филлрейт, и никакой оптимизацией с этим не справиться. Если вы под оптимизацией имеете ввиду избавление от повторных зарисовок (overdraw), то это немножко не то, о чем я писал в первоначальном посте. Проблема overdraw решаема, в том числе и с помощью pvs.
3) “Ничего общего с данным подходом нет, те кто работал с движками на С (или на других “высших” языках) поймут о чем речь” - а что имеется ввиду, фраза какая-то уж больно туманная.
4) по поводу динамических объектов вообще не понятно - что вы имеете ввиду? Если скорость отрисовки - опять же филлрейт, а если вы утверждаете, что ваш движок может быстро рисовать допустим движущихся персонажей в “сложной” обстановке и не испытвает при этом проблем с сортировкой полигонов - демку в студию. Демка cathedral проблемы с сортировкой испытывает, и именно там, где и должна испытывать проблемы любая не-bsp рендерилка (в вашем случае это лестница в последней комнате).
P.S.: в любом случае демка сделана хорошо, в первую очередь за счет грамотных текстур и модели, использующей преимущества движка. Но проблема-то в том, что задача разработчика движка не столько в достижении внушительных fps на тестовых сценах, сколько в создании такой системы, которая приемлемо будет работать с разнообразными входными данными, подготовленными отнюдь не мега-супер специалистами.
- Узкоспециализированный хех, функционал вообще то выше чем у той же Альтернатива (которую вы упомянули).
- Может, а Альтернатива может? Там настройка BSP-дерева очень сложная (требует знания иерархических деревьев) и занимает гораздо больше времени чем у меня PVS :).
- Вообще то у меня тоже есть BSP-дерево и полностью адаптивное.
У меня BSP-дерево не требует никаких знаний от пользователей в иерархических деревьях.
- Возьмем ту же Альтернативу раз вы ее упомянули. Есть объект 1500 полигонов, когда крутим камеру, то FPS допустим 30-50, но если начать крутить объект или перемещать его, то FPS упадет раза в 2-3 (И это не мои домыслы у них на форуме это неоднократно обсуждалось). У меня нет такой проблемы не важно какой объект и что с ним происходит скорость будет такая же, если бы он был статичным.
Демка не оптимизирована, не считая PVS. Весь уровень состоит из треугольников, хотя движок поддерживает квады и многоугольники, эта основная тестовая демка (которая не меняется, по ней отслеживается скорость новых алгоритмов и экспирементов), но если ее оптимизоровать получим еще 5-10 FPS.
- Я, не
с 3D моделированием дела не имел, только с программированием, а изучил лишь для написания демок, так что не думаю что они созданы оптимальным способом и оптимизированы.
- Скажу вам по секрету
в управлении движок легче аналогов (и это не мое мнение, а разработчиков, которые работают на движке), т.к. почти все алгоритмы адаптивные знаний для управления движком нужно меньше.
P.S.
1) Возьмите мою библиотеку и библиотеку другого движка;
2) возьмите любую модель или сцену (скажем с 5000 - 10000 полигонов) загрузите в другой движок, оптимизируйте всеми средствами движка;
3) сделайте тоже самое и в моем движке, можно даже не оптимизировать. Хотя движок обладает многими видами оптимизации моделей;
4) и сравните результат - собственно для этого я и выложил библиотеку, что бы разработчики могли сравнить.
mono, если вы захотите дальше обсуждать тонкости движка и т.д. давайте переместимся на форум, т.к в блоге просто не удобно писать большие сообщения.
Круто. Добавлю блог в избранное и друзьям посовету. Ждите новых читателей
Разместил это на своем блоге с ссылкой на ваш сайт. Надеюсь, Вам это какую-нибудь пользу принесет
Круто. И не поспоришь ведь
Знакомый посоветовал зайти на этот блог и явно не зря.