otoy
liveplace

Liveplaceの写真品質3DワールドとOTOYレンダリングエンジンの真相

次の記事

Social Median、75年間施行されている証券取引法に反旗を翻しTwitterで株式販売

先週われわれはLivePlaceを紹介するビデオを掲載した。驚くほど精細な3Dワールドだ。それを支える見事なテクノロジーは、OTOYと呼ばれるストリーミングプラットホームで、映画品質のレンダリングを「クラウド上」で行い、そこから通常性能のパソコンや、携帯電話に対してもストリーミングすることができるというもの。OTOYの詳細については、われわれの紹介記事を参考にしてほしい。

このビデオはLivePlace.comに「ライブ、それともバーチャルなライブ?」というわかりにくい見出しがついて一般に公開されていたのだが、どうやら誰にも見つけられないつもりだったようだ。われわれの記事が掲載された直後に、LivePlaceがサーバーからこのビデオを削除した。MySpaceに関わる起業家でLivePlaceのオーナーでもあるBrad Greenspanによると、あのサイトは全く一般公開する予定のなかったもので、社内用のモックアップであり、バイラルビデオであり、また「Funny or Die[*]の作品のようなものだった」とのこと。この説明は私には納得できないが、Greenspanからこれ以上意味のあることを聞き出せるとも思えない。
*[訳注:人気の動画サイト]

では、3Dバーチャルワールドはどうなのか。まがいものなのか。

OTOYのファウンダーJules Urbackが、Liveplaceのやっていること(あるいはなぜビデオを公開したのか)についてはコメントできないとしながらも、ビデオのレンダリングエンシン上で動くバーチャルワールドは実現しようとしている、と話してくれた。彼によると、このビデオは同社のシステムの能力を示すものではなく(実際ビデオ撮影後に改善されている)、いろいろなビデオの断片をLiveplaceで繋ぎ合わせただけのものだという。

このビデオの中の14分間のリアルタイムレンダリングは、Treo 700に240 kpbsでライブストリーミングされている。これは、2007年3月に取り込んだもので、サーバーはATI RX 1900 GPUで動いていた。テクノロジーはあれ以来飛躍的に進歩している(今動いているハードウェアも)。われわれは、voxelによるレンダリングとLightstageベースのキャラクターを入れられるようになるまでは、一般に公開するつもりは全くなかった。あれを見て気に入った人なら誰でも、最終製品をもっとずっとすばらしいと感じてくれると思う。

先月AMD向けに行ったRubyデモの目的は、このGPU時代になれば、オフラインとリアルタイム作業の質が同じであることを示すのがすべてだった。続いて今月行われたプレゼンテーションは、Lightstageの紹介と、このリアルタイム環境で、どうやってキャラクターを(またはどんなCGオブジェクトでも)100%リアルに見せるかを示すものだった。

こうしたテクノロジーが応用されるバーチャルワールドについては、今年これ以降に、OTOY用に開発中のサーバー側プラットホームに関する次の発表をするまで、話題にするつもりはなかった。

われわれは、このビデオの編集やリークに一切関係していないし、このプロジェクトはまだNDA下にあるため、OTOYテクノロジー以外については、コメントできない。

ビデオの内容に一貫性がないことに加えて、読者が抱いたひつのの疑問が、ビデオに他のアーティストの作品が不正使用されている可能性だ。ビデオの最初のクルマのクリップは誰かの作品集から取ってきたらしく、何年も前に作られたもののようだ。実は、あのビデオ古いものだった、そしてJules Urbackによるとあのアーティストは現在OTYOチームの一員だという。

JJは、過去3年以上にわたるわれわれのほぼ全プロジェクトで、OTOY/JulesWorldと仕事をしている(一部はまだNDA下)。彼がすばらしい友人でありパートナーであることを実に誇りに思っている。

JJのスタジオであるBLRについては、リアルタイムのプロジェクトでもリニアなVFXの仕事でも、クライアントが当社のロゴを載せることを許可しているビデオには必ずクレジットが入っている。。何週間か前にTechCrunch(元はDaily Variety)にあったリアルタイム・トランスフォーマーのOTOYのビデオに、BLRのロゴがあるし、11月に印刷広告キャンペーンに載る当社業務の特集でも見ることができる。

メモ:BCNストリートの場面のいちばん初めに出てくるVWビートルは、JJの最初のCGモデルで彼の「ベイビー」だ。われわれと一緒の仕事のほぼ全部に登場する。Paramount用に使った「Bumblebee」トランスフォーマー広告から、最新のAMDのRuby voxelデモ(道の右側に出てくる)まで。先月のTechCrunchのOTOYに関する記事の画面の中にもある(512 MB R770、voxel以前のレンダラーでレンダリング)。

結局どういうことだろうか。LivePlaceはあのビデオにも、出てくる町とも関係ないようだし、そもそもあの映像を公開すべきではなかった。この背後にあるOTOYのすばらしいテクノロジーは本物だが、どんな製品がこれを活用するのかを知るためには、まだ待たなくてはいけないようだ。

Julesによる、技術の詳細は以下のとおり[原文]

– We sore voxel data in several ways, including geometry maps (see our Siggraph or Iceland presentations, where we show this method applied to the Ligthstage 5 structured light data, courtesy Andrew Jones ICT/Graphics lab)

– The datasets from the BCN and Ruby city scenes contain up to 64 data layers per voxel, including diffuse albedo, fresnel reflectance values, irradiance data, UV coordinates (up to 8 sets), normals, and, for static scenes, look up vectors for 1-20 bounces of light from up to 252 evenly distributed viewpoints (it is important to note that this data is always 100% optional, as the raycaster can do this procedurally when the voxels are close and reflection precision is more important than speed; however, with cached reflectance data, you might see the scene rendering at 100s-1000s of fps when the scene isn’t changing).

– A note on raytracing vs. rasterization: amplifying the tree trunk in Fincher’s Bug Snuff demo to 28 million polys using the GPU tessellator turned out to be faster than rendering a 28 million voxel point cloud for this object. So there is a threshold where voxels become faster than rasterziation at about 100 million polys. At least in our engine, on R7xx GPUs, using full precision raycasting at 1280×720. Below that point, traditional rasterization using the GPU tessellator seems to be faster for a single viewport.

– The engine can convert a 1 million poly mesh into voxel data in about 1/200th second on R770 (60 fps on R600 and 8800 GTX). This is useful for baking dense static scenes that are procedurally generated once, or infrequently, on the GPU. That is why some of the OTOY demos require the GPU tessellator to look right.

– Hard shadows in OTOY were done using rasterization until we got R770 in May. Now hard shadows, like reflections, can be calculated using raycasting, although shadow masks are still very useful, and raycasting with voxel data can still give you aliasing.

– We can use the raycaster with procedurally generated data (perlin generated terrain or clouds, spline based objects etc.). At Jon Peddie’s Siggraph event, we showed a deformation applied in real time to the Ruby street scene. It was resolution independent, like a Flash vector object, so you could get infinitely close to it with no stair stepping effects, and likewise, the shadow casting would work the same way.

– The voxel data is grouped into the rough equivalent of ‘triangle batches’ (which can be indexed into per object or per material groups as well). This allows us to work with subsets of the voxel data in the much the same way we do with traditional polygonal meshes.

– The reflections in the march 2007 ‘Treo’ video are about 1/1000th as precise/fast as the raycasting we now use for the Ruby demo on R770/R700.

– One R770 GPU can render about 100+ viewports at the quality and size shown in the ‘Treo’ video. When scenes are entirely voxel based, the number of simultaneous viewports is less important than the total rendered area of all the viewports combined.

– The server side rendering system is currently comprised of systems using 8x R770 GPUs ( 8 Gb VRAM, 1.5 Kw power per box).

[原文へ]

(翻訳:Nob Takahashi)