@KaminskyIlya

Существуют ли особые методики тестирования 3D-приложений?

Всем, привет!
Занимаюсь проблематикой TDD и вообще тестированием лишь недавно. Пока изучаю теоретические аспекты. Вот возникли такие, на мой взгляд, нетривиальные, вопросы. Коллеги, поделитесь опытом!

Вопрос 1.
Допустим мы делаем редактор 3D-мешей для модели. У нас есть в редакторе покрытая тестами функция объединения мешей. Но вот досада: при некоторых сочетаниях геометрий и взаимного расположения моделей слияние формирует вовсе не ту фигуру, которую ожидает увидеть пользователь. Например, при слиянии двух сфер, в некоторых случаях, получается нечто, очень напоминающее комету Чурюмова-Герасименко. В добавок, появляются полигоны, неправильно ориентированные к наблюдателю.
Существует ли способ программно выявить такие лаги. Есть способ на "это" написать тест?

Вопрос 2.
Представим, что мы проектируем 3D-игру или демку. Мы пока только можем отображать ландшафт, небо с облаками, строения, траву, деревья, некоторые другие статичные объекты. Наконец, мы решили привнести в нашу модель мира понятие "ветра". Пока просто: он либо есть, либо его нет. На ветер будут реагировать только трава и деревья: они будут просто покачиваться, имитируя сам факт ветра. Плюс в мире появляется фоновый звук ветра. Первый этап пройден.

Затем мы решили параметризировать ветер, добавив ему силу и направление. Теперь трава и деревья нагибаются в сторону от ветра, а амплутида их колебаний зависит от силы ветра. (Можно сказать, что логическое поле "есть или нет" для ветра, превратилось в вещественное "сила" ветра. А старая функция isWindOn возвращает результат теперь проверкой: wind.force > 0). Но представим, что после этого, у нас стало лагать фоновое сопровождение звука. Оно когда появляется, а когда нет. Каким методом протестировать вообще сам факт этого, чтобы впредь не допустить?

Ну или другая вероятная проблема со звуком: при очень маленьких значениях силы ветра колыхание травы и деревьев не происходит, а вот звук еще идет. Получается, что шум от ветра есть, а действия нету. Понятно, что решение здесь - как минимум, поставить зависимость громкости фонового звука от силы ветра. Но каким образом (чисто гипотетически) написать тест на несоответствие громкости звука амплитуде колебаний деревьев и травы? Мало ли: а вдруг рефакторинг, или дальнейшие "нововведения"?

Или представим, что некоторые деревья в процессе деформации ствола (под действием ветра) при некоторых сочетяниях значения силы ветра и своего расположения на местности, скажем, переворачиваются к верху ногами. Причем заметно это становится, только при определенном ракурсе камеры наблюдателя. Каким тестом отслеживать подобное? Ведь формально, модульные и функциональные тесты проходят. Они не могут выявить нарушение геометрии. Человеко-тестеры тоже не всегда могут выявить такое безобразие. А ну как в продакшн?

Ну или еще подобное. Скажем, выявилось проникнование части персонажей за преграду (например, рука сквозь стену). В общем факты этого отслеживается специальной логикой. Есть даже тесты, проверяющие работу модуля, контролирующего пересечение двух объектов в пространстве. Но каким образом гарантировать, что тест в принципе верный? Что если сам тест написан неверно, и его писатель, допустил ошибку при оценке множества выходных значений (заузил возможный диапазон)?
  • Вопрос задан
  • 3065 просмотров
Пригласить эксперта
Ответы на вопрос 2
@mamkaololosha
TDD работает если к задаче можно написать тест и с написание теста может справиться хотя бы джуниор-мидл. Как вы напишете тест к октодереву, освещению или шейдеру? Никак же. FPS, артефакты, корректное отображение входных данных и прочее. Можете держать 100500 мелких тестовых проектов для отладки. Пишите генератор ресурсов на питоне и скармливайте программе. Может в Юбисофтах и прочих ЕА всё более гибко за счет овер-експириенсных кадров.
Ответ написан
donkaban
@donkaban
Умею рисовать тени
1 случай - ну вообще то триада Хоара в чистом виде, у вас по входу набор вершин и по выходу тоже. Можно строить автоматизированные тесты по образцу.

2 ручное тестирование. Ну и опять же, амплитуда - это численная характеристика, наносите на террайн изомапу амплитуд звука, сравнивайте с эталонными.

3. Гарантировать корректность теста можно только если тест алгоритмически тривиален, очевидно. К счастью все тесты (почти все, скажем) - именно таковы.

Про тестирование шейдеров - я обычно вывожу в MRT какие то виузализации промежуточных вычислений, почти всегда можно придумать что-то такое. Читать нормализованные вектора в rgb все уже привыкли, если что :)
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы