Мипмаппинг
24.12.2009 Антон ВолковЭто страшное слово, на самом деле, означает изменение детализации текстур в зависимости от расстояния от камеры (подробнее в Википедии). Методика позволяет избавиться от шума на удалённых объектах и существенно повышает производительность отрисовки.
24.12.2009 в 21:43
встроенное неплохо работает при кволити=бест. что, конечно, не гуд для 3д.
24.12.2009 в 23:25
Нету никакого встроенного мипмаппинга на drawTriangles, даже на BEST-качестве:
Внизу - с помощью нашего алгоритма.
И не забываем про скорость отрисовки - жмём пробел и смотрим на FPS.
Вобщем, и визуальное качество улучшили, и скорости добавили - красота! :)
24.12.2009 в 23:26
я так понимаю при whell меняется величина этого мипмаппинга?
если погонять туда сюда скролл и потыркать спайс то мипмаппинг перестается регулироваться даже если он включен :)
25.12.2009 в 00:40
круто!
молодцы так держать!
а что на счет сортировки что нить изменилось? добавили быструю сортировку?
25.12.2009 в 00:42
ну я за себя говорю что в бест видел улучшения. но это старый добрый lineTo/moveTo
25.12.2009 в 00:46
)) вы режете пространство в камере плоскостями параллельными плоскости экрана на несколько частей, и каждой части соответствует свои текстуры , т.е. сначала большие потом меньше и потом совсем меньше ))) интересный подход фпс с 24 до 30 при этом увеличивается ) комп слабый ))
25.12.2009 в 00:51
слегка видно, то что если объект разрезан этими плоскостями то видно две разные текстуры, правда это сразу в глаза не бросается… ) тока если прищуриться ))) супер! вы прям фокусники )))
25.12.2009 в 06:14
@makc
Да для филлов это работает, но только для чётных битмап и никак не контролируется
@SuperMan
Так и есть! Раскрыл весь фокус :) Стык видно из-за Адобовской ошибки UV-маппинга (они начинают отсчёт с центра пикселя, а не с края), соответственно, чем меньше текстура, тем сильнее этот баг виден. Баг-репорт когда нибудь отправим, а в движке будет опциональный компенсатор. Ну и для каждой текстуры имеет смысл выбирать соответствующую степень мипмаппинга (в демке - колесом мыши), чтобы визуально границ практически не было видно.
25.12.2009 в 12:06
вот более точная формулировка: прокручиваем скролл вниз до того как расплывчатость не дойдет до камеры, потом спайсом вырубаем мэппинг, опять спайсом врубаем, теперь достаточно несколько раз крутнуть скролл вверх / вниз как после 3го раза флеш перестает реагировать на скролл вообще.
25.12.2009 в 12:50
Ага ))) я вижу все насквозь ))) дак вы бы не давали нам скроллить мипмаппинг! ))) или не резали бы треугольники, а просто если треугольник выходит за предел определенный то менять текстуру для всего, но утт кроется проблема длинных треугов…
Что там с сортировкой ? я так и не получил ответ )))
25.12.2009 в 13:19
@SmivaL
Да пофиг на это. В демке речь не о лимитах кручения колесом. Главное, чтоб менялось.
@SuperMan
Давно уж, и в Танках применяется и уже с начала года в демках показывали.
Три сортировки: Z, статическое BSP, динамическое BSP
При этом они всячески друг с другом взаимодействуют.
Например, в танках, дома - статик-BSP, танки - динамик-BSP, парашюты/бонусы - Z
25.12.2009 в 13:42
супер! прям как я и хотел ))) а как вам удалось объединить? создаете статическое бсп, и каждый рендер добавляете в него динамическое дерево и ЗЕТ?
25.12.2009 в 13:51
Типа того
25.12.2009 в 14:11
а со светом оно красиво
Осталось уяснить текстуры создаются автоматом или ручками надо делать?
25.12.2009 в 23:57
@Антон Волков
ну кто знает, вдруг это уходит корнями в движок)
26.12.2009 в 01:49
Flop, опередил, блин :)
Действительно, очень красиво все выглядит, вот и вопрос: видел как-то раз видео, по-моему, с этой же сценой и освещением, и освещение вроде бы осуществлялось на движке. Боюсь спросить.. Текстуры - запеченные? Или вы уже и GI научились предпросчитывать?!
26.12.2009 в 03:56
Не, смысла делать расчёт света на клиенте нету. Прижигаем в текстуру.
Жаль, что не удивил, но с точки зрения практической пользы так (пока) лучше.
26.12.2009 в 19:10
да смысла нету делать еще и освещение динамическое, единственное - на танках самих можно было бы сделать… и то нагрузка возрастет…
26.12.2009 в 20:47
танки стоило бы как единое целое приглушить колортрансформом в зависимости от того в тени он или нет, да и всё там
26.12.2009 в 21:13
@SuperMan, makc
На танках будет, по карте освещения, именно колортрансформом.
Пробовали сделать на картах нормалей, но PB уж очень медленно работает с растром — от силы на один танк хватит.
27.12.2009 в 04:47
На очереди трилинейная интерполяция и анизотропка?)
27.12.2009 в 05:02
@beef34t3r
Боюсь, что это потребует работы на уровне текстуры, а с этим во флэш не очень шустро справляется
28.12.2009 в 18:26
жаль
запекать свет (и бамп) конечно же можно в 3Д редакторе за 4Килобакса )
можно в разы красивее сделать чем сможет опенгл или дирек3д
но автоматом сделать для статики на клиенте кажется вполне реально
загрузить набор тайлов - сгенерить одну текстуру с статичным светом и сохранить в 5 разных размеров для мипмапинга
28.12.2009 в 18:35
Между “реально” и “целесообразно” большая пропасть.
Реально вообще рейтрейсер сделать на AS, а вот имеет ли это сейчас практическую пользу - большой вопрос.
Есть более важные задачи, чем прижигание света на клиенте, и пока мы их не решим, неприоритетные задачи делаться не будут.
28.12.2009 в 19:02
интересно а какие вы задачи у вас щаз?
28.12.2009 в 19:08
Выпустить первый билд “семёрки”.
29.12.2009 в 16:37
2Flop:
Вот и дилемма - с одной стороны, с прижиганием получается красиво, настоящие атмосферные тени, рефлексы и все такое. Но - трафик кушается порядка четырех метров. С другой стороны, если будет иметься возможность сгенерировать все текстуры с нуля на самом клиенте (как здесь: http://alt-generator.ru/blog/wp-content/uploads/2009/12/ns_0.JPG) и предпросчитать освещение (речь не о GI, а примерно вот об этом: http://forum.alternativaplatform.com/posts/list/2016.page), то настолько красиво все равно не будет. Либо, как Антон Волков написал, можно сделать рейтрейсер (кто его еще будет делать) с распределенным по времени просчетом, но это выкинет клиента в аут часа на два :) Так что возникает логичный вопрос - нужны ли процедурные текстуры в 3D, если между ними и готовой сценой стоит еще шейдинг, который все равно целесообразнее выполнять в стороннем редакторе?
2Антон Волков:
> Выпустить первый билд “семерки”.
Плюсадин :))
31.12.2009 в 15:10
@Антон Волков “Реально вообще рейтрейсер сделать на AS, а вот имеет ли это сейчас практическую пользу - большой вопрос” http://lists.motion-twin.com/pipermail/haxe/2009-December/032464.html
31.12.2009 в 16:57
@makc, не понял что ты хотел сказать этой ссылкой
01.01.2010 в 17:53
там Николас сообщает, что он “have almost finished a
game that is using extensively this api to make realtime raytracing”
01.01.2010 в 22:10
Выводы то какие? :)
Quake уже два года как на флэше запускали.
Ну и рейтрейсинг рейтрейсингу рознь.
А самое главное в моей фразе “имеет ли это сейчас практическую пользу - большой вопрос”
01.01.2010 в 22:43
ну вроде раз юзают для игр, значит видят какую-то пользу
01.01.2010 в 23:11
Ну вот когда увидим пару-тройку реальных проектов, тогда и посмотрим :)
А делать какие-то выводы по огрызку фразы Канассе смысла не вижу
04.01.2010 в 19:46
Может я не заметил но…
Что с мип-маппингом в зависимости от угла зрения на нормаль поверхности? И какие технологии применяются/планируются для фильтрации текстур?
05.01.2010 в 15:27
Коррекцию по нормали мы делали в “пятёрке”, т.к. там каждая грань рисовалась отдельно.
Можно посмотреть здесь: http://drevnii.ru/bunker.htm
Сейчас мы отрисовываем пакетно и стараемся экономить на drawcall’ах.
Так что, в принципе, это реально, но применять не планируем.
Фильтрации текстур здесь нет, т.к., как я уже говорил, флэш медленно работает с растром.
В демонстрации выбираются нужные мипы для геометрии на определённом расстоянии.
05.01.2010 в 17:21
А какой прирост производительности дает использование drawTriangles() вместо lineTo()? И еще, может, вы пробовали применять Graphics.drawPath() или Graphics.drawGraphicsData(), имеет ли это смысл, хотя бы в изометрии?
05.01.2010 в 18:59
Пакетная отрисовка конечно-же имеет свои преимущества, из-за резкого сокращения вызовов методов, а также в силу своей “нативности”. Также - это единственный способ сделать качественные перспективные искажения (ранее приходилось их эмулировать триангуляцией). Работа с Path медленнее, т.к. приходится создавать больше экземпляров и сами методы выполняются дольше (видимо из-за дополнительного парсинга). Вы это можете легко проверить сравнив по таймеру “олдскульную” отрисовку и на Path’ах.
06.01.2010 в 13:28
ахахаха в итоге полезных-быстрых функций в существующем 10 плеере, которые можно юзать для 3д - drawTriangles() и все ))) все ихние матрицы и вертексы тормозят походу дела… а забыл еще Vector. для массивов, но вы все таки юзаете Dictionary почему???
06.01.2010 в 17:45
Дайте предположу - вместо того, чтобы вызывать Vector.splice(n, 1) для удаления единственной вершины, можно попросту сделать Map.remove(id) или Set.remove(id)? Таким образом, при удалении целых наборов вершин (скажем, вследствие удаления грани) перевес эффективности сместится в сторону случая с использованием словаря?
06.01.2010 в 18:04
незнай незнай
во всяком случае не в каждом проекте надо вершины удалять/добавлять постоянно, да и вообще зачем это надо? ))) вы че морфинг налету делаете? и то при морфинге и анимации можно обойтись одним и тем же набором вершин… к тому же ваш класс Мап или Сет - для добавления/удаления вызывается функция которая замедляет эти операции
07.01.2010 в 02:06
Может, новые вершины получаются при работе динамических BSP-деревьев.. Это единственное, что приходит в голову. А по поводу drawTriangles() - да, согласен :) Да и тот не сахар, иначе не было бы этого поста ))
07.01.2010 в 02:12
С чего вы взяли что мы юзаем Dictionary? :) В “пятёрке” да, активно. В “семёрке” - нет.
07.01.2010 в 02:13
Кстати, в этой демонстрации не динамическое, а что ни на есть статическое BSP ибо динамик далеко не всегда даёт хороший результат и любит моргать T-junction’ами.
03.03.2010 в 00:45
кстати, почему сцена пересчитывается постоянно? даже когда не двигаюсь все равно пересчитывается или рисуется… всегда один фпс… разве не вы говорили о новой системе сигналов?
03.03.2010 в 12:54
Потому что в 7-ке нет системы сигналов.
По-крайней мере пока.
04.03.2010 в 01:02
странно а зачем так? ведь лишние рассчеты делаете! думаю еще и 30% производительности теряете…
04.03.2010 в 21:21
наверно затем, что когда пересчёты идут постоянно (а ля танчики), уже сами сигналы становятся лишними рассчётами.
05.03.2010 в 02:09
это говорит тока о не правильном подходе “танчиков” (еще учитывая что это был как индивидуальный проект), в любом случае постоянно пересчитывать нельзя ))
05.03.2010 в 11:07
что значит нельзя, юзер же кнопки давит, хочет башней вертеть, ездить туда-сюда. а ты ему мессагу “куда спешишь, дарагой? постой секнду, а то цпу дымит”, да?
05.03.2010 в 12:33
не я к тому что когда юзер едет - то тут приходится пересчитывать все, а когда он остановился и вращает башней тока - то смысл пересчитывать трансформацию например вершин “мира” тех же… пересчитывать надо то что движется, в принципе это можно сделать с помощью “немногих” флагов тем самым и производительность повысится чуть чуть )
05.03.2010 в 15:14
Сейчас все наши проекты связаны с постоянным изменением камеры.
Делать систему сигналов для этих проектов, тратить дополнительное время — нет смысла.
Когда будем участвовать в проекте, где постоянной перерисовки нет - сделаем оптимизашку.
29.08.2011 в 20:26
Как всегда, полезно и интересно, спасибо автору.
23.10.2011 в 10:13
Спасибо за информацию, очень интересно.