Динамические тени

Автоматический UV-маппинг продолжает приносить плоды. Органично внедрились теневые текстурные объекты, рисующие соответствующее затемнение от объектов в текстуре.

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

Динамические тени

  • Пробел — старт-стоп анимации
  • Enter — изменить объект
  • Колёсико (ИЛИ кнопки «Вверх-вниз», для юзеров макинтоша) — изменить масштаб
  • Ctrl + Колёсико (или кнопки «Влево-вправо») — качество текстуры
  • L — статическое освещение/динамическое освещение
  • Q — вкл/выкл интерполяцию текстуры

Динамические тени: 35 комментариев

  1. Если вы доделаете этот движок то вы в не зависимости от игры сделаете себе мировое имя.

    >>Спасибо, парни! Ваша поддержка очень важна для нас!
    Спасибо Антон Волков, твоя поддержка нас в поддержке вас тоже очень важна для нас, что бы мы не уставали поддерживать вас.

  2. Athon64 3000+

    Загрузка проца: 80-90%
    Когда смотрел в первый раз — мог покрутить сцену. Когда смотрел во второй раз — реакция на мышку была с большой задержкой.

    Т.е. выглядит это так: кубик нормально вращается, тени рисуется — всё это с хорошим fps.
    Но если попытаться повернуть сцену мышкой — ничего не происходит. Спустя секунд 5 сцена резко поворачивается под другим углом и снова в нём «фиксируется».

    Кроме того, я не мог нажать в Opera кнопку Back — браузер тоже перестал реагировать на мышку.
    И закрыть браузер я смог только через диспетчер задач.

    Это не притензия, просто feedback по поводу производительности.

  3. Многое зависит от браузера и установленной в него версии FlashPlayer.
    У меня, например, Athlon(tm)XP 2000+ 1.53 ГГц и 512 оперативки.
    При вращении всей сцены — fps около 30.
    Сижу в Firefox, версия плеера 9.0.60.184.

  4. Спасибо за фидбэк! Тени пока что экспериментальная фича. Толком никаких оптимизаций ещё не сделано. Если примем решение о внедрении теней в игру, то скорость поднимем. По идее, если объект и источник света не двигаются, то не будет потребления вообще. Но для этого надо будет сделать (кое-что уже было во 2-й версии движка) систему анализа взаимного расположения объектов.

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

    1) Каким образом вы накладываете карты освещения? Обычный beginBitmapFill, програмно созданные градиенты или что-то еще ?

    2) Качества текстур/карт освещения. Почему оно такое низкое? В своем варианте я сначала тоже использовал маленькие карты, думая что так будет быстрее, однако как показала практика разрешение карты не сильно влияет на скорость, если рисовать все-таки через beginBitmapFill. Посему я сделал вывод что вы рисуете текстуры как-то по-другому.

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

    заранее спасибо

  6. Буду рад знать, с кем общаюсь — тяжело обращаться к «Анонимно» ;)

    1. Стоит посмотреть заметки в начале августа, там как раз идёт речь о том, что освещение находится прямо в текстуре (как и во «взрослых» 3D-движках). Впрочем в первой версии движка мы делали градиентную заливку, но скорость нас не устроила и в дальнейшем мы от неё отказались.

    2. Качество текстур и освещения можно менять, это хорошо видно в недавней демке. Т.к. работа идёт с растром, то чем меньше битмапа, тем быстрее.

    3. Делали и так и эдак. Остановились на освещении по граням. А вот если делать градиентное освещение, то придётся считать его по вершинам, с расчётом нормалей.

  7. >Буду рад знать, с кем общаюсь — тяжело обращаться к “Анонимно”
    Да сорри, сразу не соориентировался куда тыкать.

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

    > 2. Качество текстур и освещения можно менять, это хорошо видно в недавней демке. Т.к. работа идёт с растром, то чем меньше битмапа, тем быстрее
    Вот это меня и смущяет, сильная зависимость FPS от разрешения текстур говорит о попиксельном рисовании теней/освещения через setPixel, или я туплю где-то?

    >3. Делали и так и эдак. Остановились на освещении по граням
    Понятно. Кстати если не секрет, почему отказались от заливки Фонга (градиентная заливка). Если с ним поковыряться можно сделать environment mapping, ну типа зеркальные поверхности, отражения.

  8. Да блин, я ведь не прошу куски кода приводить.
    Базовые агоритмы трехмерной графики разработаны уже давным-давно, это ведь не сакральная тайна за семью печатями. Я просто пытаюсь понять, в своем движке пошел-ли я с самого начала не в ту сторону или большой fps в вашем движке — следствие безпощядной оптимизации всего и вся, а базовые концепции что у меня что у вас одинаковые.
    ЗЫ: очень сильно надеюсь что этот блог создан НЕ ТОЛЬКО для выслушивания рукоплесканий в ваш адрес.

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

    1. Идея то верная, но мы сделали не так. Мы просто тонируем его текстуру в том месте. Ну например, есть текстура. Ей залиты несколько полигонов с разным освещением. Так вот мы рисуем в текстуре это освещение по UV-координатам полигонов.

    2. FPS не зависит от разрешения текстур. Тормоза проявляются при перегенерации текстуры (в том числе и освещения). А в этом случае, чем больше битмапа, тем медленнее. Попиксельно мы ничего не рисуем (см. п.1.)

    3. Во-первых делали ещё в первой версии. Нас не устроила ни скорость, ни качество. EnvMapping тоже делали. Красиво, но для игры нам не нужно. Возможно, когда нибудь и реализуем в новом виде.

  10. > …есть определённые ноу-хау, которые мы не хотели бы раскрывать
    согласен, уважаю

    > Обсуждение же общих идей на мой взгляд полезно не только для посетителей, но и для нас, поэтому предлагаю и дальше этим заниматься :)
    Руками и ногами ЗА!

    > Ну например, есть текстура. Ей залиты несколько полигонов с разным освещением. Так вот мы рисуем в текстуре это освещение по UV-координатам полигонов.
    Так уже теплее.
    Т.е. берется UV-проекция полигона на карту освещения, аффинными преобразованиями совмещается с UV-проекцией на текстуре и рисуется в текстуру. Потом процедура повторяется только для текстурной UV-проекции (уже освещенной) и экранных координат.

    > Тормоза проявляются при перегенерации текстуры (в том числе и освещения).
    Вот тут не понял. У вас на каждом кадре, для каждого полигона генерируется новая карта освещения? Сурово.
    сам я делал так: есть один большой lightmap (радиальный градиент от белого к прозрачному). Он рисуется один раз в жизни, и больше никогда не меняется. Каждый полигон вырезает нужный ему кусочек из этой карты и «натягивает» на себя. Таким образом наложения света и текстуры достаточно двух аффинных преобразований битмапы, что есть гуд т.к. флэш выполняет их с одинаковой скоростью, не зависимо от разрешения.

  11. > Т.е. берется UV-проекция полигона на карту освещения…
    Можно сказать, что так.

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

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

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

    Нас этот вариант не устроил ни по качеству, ни по скорости. Например, такого мягкого освещения как здесь http://blog.alternativaplatform.com/ru/2007/08/16/texture-lighting-specular/ в принципе не получится добиться градиентным освещением при небольшом количестве полигонов.

  12. так, кажется я начинаю плавать, давайте внесем ясность в определения.
    3 способа заливки полигона:
    1) flat — освещенность полигона не меняется по его площади. Т.е. карта освещения одноцветная
    2) ground — освещенность меняется линейно. Карта освещения — линейная интерполяция освещенности вершин (линейный градиент).
    3) phong — освещенность меняется по закону косинуса. Карта освещения — радиальный градиент.
    В моем понимании модели 2-3 — градиентные, модель 1 — плоская.

    > брали битмапу 2х2 пикселя, заливали три из них освещением в соответствующей вершине
    ну да, ground shading в чистом виде. Кстати, если уж быть честным, это ведь и есть попиксельная обработка, только пикселей всего 3 =)

    Теперь по поводу указанной демки.
    > такого мягкого освещения как здесь http://blog.alternativaplatform.com/ru/2007/08/16/texture-lighting-specular/ в принципе не получится добиться градиентным освещением при небольшом количестве полигонов
    Значит в этой демке используется НЕ градиентная заливка?

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

  13. Serega, посмотрите вот этот пост http://blog.alternativaplatform.com/ru/2007/07/04/landshaft/
    Там как раз видно переход с полигонально/вершинной системы освещения на текстурную. Ещё раз, текстурное освещение не относится ни к какому перечисленному вами виду, это совершенно другой способ, когда высветление/затемнение рисуется и интерполируется прямо в текстуре. Можно также посмотреть, что происходит в натянутых битмапах здесь http://blog.alternativaplatform.com/ru/2007/08/28/texture-objects-in-action/

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

Добавить комментарий