Comment by anigbrowl | Hacker News Reader

Comment by anigbrowl | Hacker News Reader

Parent Full thread

render the full 720p image remotely

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.

otoy was more open earlier; they've since locked it down a bit, but with some googling you can dig it out (eg: http://raytracey.blogspot.com/2008/08/otoy-transformers-and-... , links-> http://ompf.org/forum/viewtopic.php?f=6&t=882 ).

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).

You'd definitely need a breakthrough.

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.

Reply on news.ycombinator.com