Can anyone here explain how this might possibly work? Key bottlenecks that come to mind are canvas performance, last-mile bandwidth, and most critically, latency: it's one thing to have the server instruct the client to render a set of known entities; it's another to render the full 720p image remotely and send it down the pipe in immediate response to player action.
Ah, there's the rub. It may be rendering a 720p canvas, but for all we know it's rendering a filthy blotchy version of it - much like streaming movies sounds great (and is good as far as it goes), but when you put the image next to a well-mastered DVD - never mind an actual HD system - the differences are painfully obvious. Similarly, if you've ever uploaded some pristine video, which you know very well, to YouTube and then looked at it a few hours later it looks pretty hideous at the normal quality, and only OK at the high quality.
In both these demos the video looks fairly smooth and responsive, but all the same we're seeing OTOY as filmed on a screen by a camcorder and then further compressed by YouTube itself. I strongly suspect that an uncompressed (or non-lossy) capture from FRAPS of the actual video in the browser window will make the difference pretty stark. I would love to be wrong of course.
The other thing I wonder is how this is going to scale and what they need at the server end (I sure can't see this being peer to peer). It does make a difference if the server side is running an nVidia Tesla (~$1500 and up) or some similar graphics powerhouse to do the almost real time compression.
It's still impressive, I like the concept, and they sure took on a big challenge. But I'm not expecting Crysis on the iPhone anytime soon. On a side note, although gaming has the most obvious market and monetization potential, what I find exciting about Otoy are the possibilities for film and scientific visualization.
Reportedly the underlying tech at otoy (not the competitor, just otoy) is essentially a legitimate breakthrough in real-time gpu-assisted raytracing.
The significant advantage raytracing brings to this space is that compared to typical rendering techniques camera movement is "instantaneous": you just change the ray origin and paths, there's no need to translate+rotate the entire game world as in typical gpu rendering...which takes you from having to translate the entire world for each frame and then rendering to just rendering.
I seriously doubt they reimplemented GTA4 with raytracing. Raytracing can exploit some of the coherence in camera location in its scene traversal, but its never been faster than rasterising a 'normal' game scene and if it is ever faster it won't be because of a matrix multiplication on the scene data.
The thing that both OTOY and Onlive seem to have done is make fast video compressor - which while impressive most likely is made possible because the hardest step in video compression is detecting interframe motion which is available to the compressor directly from the rendering data.
In earlier interviews Urbach spoke about a very fast gpu-assisted transform from polygon meshes -> voxels for use in their raytracer (and some hybrid meshes); the use of such a thing for making demo videos should be pretty obvious.
The video compression aspect is also interesting and probably works as you say; the point of raytracing isn't that it's faster per-se but that not having to keep transforming your scene data means you can more-easily share scene data between multiple simultaneous users on the same
box (loosely: you don't need space for N translated copies of the scene data if you have N simultaneous users).
I had read about their stuff a while ago, I'm not sure if thats what they are using in this example though. I don't know that I believe that the voxel representation would be a win without a sufficiently large N on a single computer, which I doubt is really doable. N copies of the transformed data is still not that much data compared to rendering it.
You'd naively calculate per-player requirements at 720p to be 1,000,000 pixels/frame x 30 frames/sec x 10x rays/pixel == per-player you need 3 giga-rays / sec (+ video compression hardware). Maybe the video compression blurs stuff enough that you get pseudo-aa for free, letting you chop some of that 10x off.
Either way, their 'fusion render cloud' is supposed to be targeting the petaflop range, and @ an extremely generous 1ray = 1flop calculation (bear with me) you'd be able to handle ~333,333 simultaneous players (720p frames) @ 1 petaflop (and with more-realistic flops-per-ray you're looking @ a lot fewer).
I don't know, I think if I had such a technology, I would use it to become the next ID software and produce a really kick ass game. Then I would license my technology for millions and millions of dollars. I just don't see the relation to video streaming.
The tech requires multiple GPUs per player -- which consumers are unlikely to purchase just to play a particular game, but the costs of which can be amortised over a number of streaming users.
I see - I thought just the opposite, that their technique might require less GPU power, making it viable to run on the server. The other way round makes more sense, although I wonder how much they would have to charge for the games.
Unreal are doing fine for themselves. So are Microsoft, Nintendo, and Sony, more-or-less.
The sales pitch for this stuff is you can sell high-end games to people who don't have consoles or high-end gaming pcs; eg, play whatever on your iphones or netbooks or whatnot...think also the existing internet gaming-cafe market in most of the rest of the world.
It seems pretty dicey imho but it has enough logic to it I can see why people'd try it.
I think the trick here consists in not sending a compressed image in any way, but rather a pre-calculated dataset that allows the image to be rendered on the client with low calculation power. Maybe just sending the polygon coordinates would be enough.
(A good exercise can be to get some figures about the polygons/s on a modern game, but I lack the data ;-)
The latency is the big problem here, but with network improvements and good algorithms, this should be solved. VoIP also has this limiting factor yet it works reasonably well.
Game development companies can only benefit from this shift: instant deployment, pay-per-play, 1 single version for all platforms (Apple, Win, Linux,...), no distributed SW (so no piracy), direct feedback of gaming habits, etc.
For the user this would also be beneficial: no need to acquire state of the art graphic cards and CPUs, instant playing, game zapping.
I foresee a brilliant future for this real-time "Computer Cloud Gaming".
Short of them having some complete breakthrough of where the server can do some massive massive pre-computation to alleviate client side computations, I don't see this happening.
Between the computation / communication tradeoff, this would have to be a huge breakthrough for rendering.
EDIT: slight rewording.