Оригинал материала: https://3dnews.ru./173244

Лицом к лицу c 3dfx. Интервью.

Стр.1 - Лицом к лицу c 3dfx. Интервью.

Интервью Fullon3D с Брайеном Бранингом - начальником отдела по работе с приложенями сторонних разработчиков компании 3dfx

Можем ли мы считать что Napalm будет передавать в T-Buffer только 4 кадра?

Ну, пожалуй, все наши примеры до сих пор передавали 4 кадра, потому что это проще понять, хотя возможность передачи 2 или всех 8 кадров не исключена. Сама технология не ограничена 4 кадрами, мы просто всегда демонстировали столько, но ничто не мешает использовать больше или меньше.

Когда раздельные кадры будут обьединяться в T-Buffer, будет ли тратится на это специальный проход, и соответственно тратится производительность?

Это аппаратная фишка, так что никаких дополнительных затрат ресурсов не будет.


Brian Bruning перед пресс-конференцией

Разные кадры рендерятся в T-Buffer параллельно, или же это делается в порядке очереди?

У нас есть такая штука, как "Маска записи". Процесс будет контролироваться разработчиком, и если к примеру делается Motion Blur, то можно отключить Write Mask и писать все 4 кадра заднего фона одновременно, а на переднем плане будет отдельно для каждого кадра рисоваться обьект. Так что можно отключать и включать этот режим когда угодно, в зависимости от того, что нужно сделать.

Так что всё что делается будет происходить параллельно?

Да, будет. Конечно потребуется побольше fillrate, но это одна из причин почему мы до сих пор хотим большой fillrate.

А какое влияние окажет это на требованиях к буферу памяти?

Памяти потребуется больше, однако Napalm сможет работать с более чем 64Мб памяти, но мы пока не обсуждали возможные конфигурации.

Значит T-Buffer не скажется на "стоимости" тройной буферизации?

Нет

А изображения из индивидуальных буферов будут сжаты для уменьшения требований к памяти?

Мы не говорили о индивидуальных технологиях в плане как мы используем T-Buffer. Мы просто сказали что T-Buffer будет, и мы позволим разработчикам создавать с его помощью спецэффекты.

Да я просто думал что это будет возможно, если вспомнить вашу "псевдо 22-х битную технологию" сжатия буфера.

Хорошая идея ;-)

Ну я думаю вы не можете распространяться о мультитекстурных возможностях Napalm или возможности по мультитекстурированию уже известны?

О специфичных деталях мы будем говорить тогда, когда официально дадим старт новому продукту.

Вы кстати больше всего давите на продвижение сглаживания, почему? Эта технология самая легко достижимая?

Мы давим на это потому, что функция полезна всем, кто её видит. Я имею в виду что она смотрится классно на экране и может быть применена как ко всем сегодняшним, так и к завтрашним играм. Так что, это автоматический апгрейд для всех. Как только купите Napalm, сразу автоматически всё улучшится. Поэтому мы так на этом сконцентрировались, да и кроме того мы считаем, что сглаживание важно когда на экране много полигонов. Чем больше полигонов, тем больше надо сглаживать. И поэтому мы думаем что это важно.

По картинкам, я бы сказал, что ваше сглаживание похоже на 4x over-sampling. Согласны?

В принципе согласен, хотя прямое сравнение между этими двумя разными технологиями сделать сложно. Когда рисуется пиксель, мы делаем offset на 25% в разных направлениях для разных изображений, но если линии пересекаются, то offset может заканчиваться на 100% или 75%.



Стр.2 - Страница 2

Значит, получается, что вы двигаете пиксели вокруг каждого треугольничка?

Нет, мы рисуем всю картинку на экране 4 раза, и она получается сглаженная. Кроме того это важно для сглаживания паттернов, которые внутри текстур, такие к примеру как текстуры для решеток и поперечных линий.

А это поможет сглаживать края сформированные пересечением двух треугольников?

Да, поможет

Вы вот говорите о кинематографических эффектах в компьютерных играх, но ведь это разные вещи. В киноиндустрии наличие эффекта регулирует режиссёр, который может использовать к примеру эффект "чёткости глубины", а в реальной жизни выбирать будет геймер. Как вы себе представляете эти эффекты в играх?

Ну, пожалуй, эти эффекты могут использоваться во вставках, или в скриптовых последовательностях, думаю, разработчики сами решат когда это использовать. В качестве примера можно привести случай использования смазывания в момент, когда в игрока попадает ракета, чтобы проимитировать дезориентацию. Мы говорили на днях с Марком Рейном, и он сказал что будет круто, если в Unreal Tournament будет использоваться фишка, например смазывание всего вокруг кроме прицела снайперской винтовки, когда она будет использоваться. Вот это будет классно.

(Комментарий: а у владельцев других акселераторов смазывания не будет, как результат - неравноправные условия при игре по сети. У одних всё смазано, у других чётко)

А Motion Blur предназначен чтобы смазывать движущиеся быстрые и медленные обьекты?

Я бы сказал, что этот эффект нужен для имитации скорости, чтобы сделать нечто вроде перехода между движущимися обьектами. Если используется ключевая анимация эффект можно использовать в качестве смазывания фаз между ключевыми кадрами.

И что, четырёх кадров для этого хватит?

Да поймите, что технология не лимитирована на количество кадров, разработчик сам определит, сколько нужно кадров для передачи эффекта. Я видел 4, и это было достаточно впечатляюще, но кто-то захочет больше, кто-то меньше. Всё зависит от разработчика.

Вот поэтому я и думаю, что T-Buffer больше всего пригодится для сглаживания, а не для других эффектов, по крайней мере поначалу.

Ага. Но с T-Buffer вы получите эти эффекты бесплатно. Включите сглаживание, и бесплатно получите "глубину сцены", "фильтр движения", "мягкие тени" и остальные эффекты.

Вот вы говорите о мягких тенях, а ваша следующая технология поможет создать динамические тени для персонажей в другом случае?

О дополнительных технологиях мы пока не говорим.

Думаю скорость заполнения у карты будет большой?

Думаю вы поразитесь.

Ну ладно, а будет ли скорость заполнения использоваться для увеличения производительности, или только для работы T-Buffer?

Мне кажется, что мы не будем разрабатывать технологию, существенно сказывающуюся на производительности. Если будет выбор между 60fps без T-Buffer и 10 с ним, то такое нам не нужно. А вот если есть возможность играть в 85fps, то можно потратить излишки на работу T-Buffer.

А будет ли Napalm поддерживать 32 бита?

Да, будет

Это будет очередной псевдо полноцветный переход от 24-х бит, как вы сделали в переходе с 16 до 22?

Ну я пока не могу раскрывать детали, однако у нас был лучший 16-бит, а у Napalm будет лучший 32-х битный.

А как вы думаете, Napalm побьёт тот восьмиплатный Voodoo2, на котором демонстрировалась технология?

Думаю тот наш Voodoo2 не был так крут.





Оригинал материала: https://3dnews.ru./173244