Серверный 3D-рендеринг
Мои вопросы связаны с этой очень интересной статьей: http://www.techcrunch.com/2008/07/09/otoy-developing-server-side-3d-rendering-technology/
Что они говорят: в этой статье утверждается, что эта компания может делать потрясающий 3D рендеринг на стороне сервера все время, отображая вывод в браузере, используя Flash, Ajax, Java или Active X. Также утверждается, что ускоренный метод выполняется Ajax на сафари (до 220 кадров в секунду).
Что я сделал: я размышлял об идеях, подобных этой, и даже дурачился с тремя методами рендеринга в браузер. Чтобы было ясно, я никогда не использовал 3D-рендеринг, а использовал уже имеющиеся изображения, размещенные на Google, или генерировал пиксели случайным образом.
Мои первые две попытки были связаны с хакерской попыткой нарисовать каждый пиксель в браузере, используя теги div или тег canvas. Я использовал php для того, чтобы сделать его медленным в первую очередь, но проходя через десятки тысяч... миллионы пикселей в любом случае потребовали бы годы на любом другом языке, это заняло 7 секунд в php. (случайные цвета пикселей значительно не увеличивают время выполнения.
Моя третья попытка заключалась в использовании нескольких изображений для создания большой картинки, и я настроил тест, используя в общей сложности десять миниатюр, размещенных в Google, где скрипт php просматривает все 10, чтобы случайным образом отображать 48 изображений на веб-странице. Каждый раз, когда вы нажимаете кнопку, Ajax будет вызывать php-скрипт для переупорядочивания изображений. Выполнение этого локально с очищенным кэшем занимает около двух секунд для отображения всех изображений (0,5 секунды после кэширования).
WTF, как, черт возьми, эти логовища делают это? Из-за моего личного опыта и простой обычной логики, то, что утверждает эта компания, должно быть полным BS. Чтобы сделать все, что они говорят, а затем передать результат через Интернет, требуется не менее 0,5 секунды кадра, даже с лучшим кодированием и более быстрым языком. Я не думаю, что вы могли бы даже перезаписать один пиксель 220 раз через Интернет за одну секунду.
Так может там не логово, как они это сделали? Я должен знать, прежде чем разрушить капилляр! Как они так быстро передавали данные в браузер с помощью Ajax, даже не учитывая 3D-обработку на стороне сервера. Это всего лишь один быстрый сервер, постоянно выдвигающий изображения? Все, что я когда-либо хотел, было 30 кадров в секунду, и посмотрите, как эти рывки смазывают всю сеть.
3 ответа
Хитрость заключается в том, что они преобразуют изображения, отображаемые в режиме реального времени, в потоковое видео. Так что в основном браузерный клиент - это просто видеоплеер, мало чем отличающийся, например, от YouTube.
На серверной стороне 3d-приложение является родным приложением, которое использует преимущества современных графических процессоров, как и большинство компьютерных игр. Он просто слушает ввод от клиента вместо физических устройств ввода, таких как клавиатура. Но, как отмечалось, задержка будет проблемой.
И лошадиные силы: http://www.techreport.com/discussions.x/16205
Пол расслабьтесь, я вполне уверен, что это BS. Эти ребята говорят об этом уже 3 года, и я до сих пор не смог получить живое демо (и я работаю в большой игровой компании). В основном это мошенничество, похожее на эту консоль Phantom, или множество других Vaporware.
Теперь должна быть возможность потоковой передачи 3D-изображений, представленных на сервере, но нет никакого способа получить хороший отклик. Рендеринг на стороне клиента - это путь, но они просто пытаются заставить людей бросать в них деньги. Они явно не передают через Интернет, это точно...
Если я правильно помню, Wired рассказывал историю об этих парнях некоторое время назад, и я не мог не подумать "WTF?".
Конечно, вы можете рендерить красивое видео на сервер и передавать его клиенту, но быстрая интерактивная обратная связь - совсем другое дело.
Даже если вы оставите время ожидания в стороне, требование "живых" изображений уменьшит ваши параметры сжатия видео. В частности, вы не можете использовать кодек B-кадра, если вы хотите приличного времени отклика, потому что вам всегда нужно ждать следующего P-кадра, прежде чем вы сможете передавать свои данные. В результате вам придется использовать огромную полосу пропускания с использованием кодека внутри кадра или только для P-кадра.
Так что, какова бы ни была их технология, игры не являются жизнеспособным приложением для этой технологии, хотя - или, может быть, даже потому, что - считает Techcrunch, - так оно и есть.