On Apr 12, 2012, at 5:12 PM, BGB wrote: > On 4/11/2012 11:14 PM, Josh Gargus wrote: >> On Apr 8, 2012, at 7:31 PM, BGB wrote: >> >>> now, why, exactly, would anyone consider doing rendering on the server?... >> >> One reason might be to amortize the cost of global illumination >> calculations. Since much of the computation is view-independent, a Really >> Big Server could compute this once per frame and use the results to render a >> frame from the viewpoint of each connected client. Then, encode it with >> H.264 and send it downstream. The total number of watts used could be much >> smaller, and the software architecture could be much simpler. >> >> I suspect that this is what OnLive is aiming for... supporting existing >> PC/console games is an interim step as they try to boot-strap a platform >> with enough users to encourage game developers to make this leap. > > but, the bandwidth and latency requirements would be terrible...
What do you mean by terrible? 1MB/s is quite good quality video. Depending on the type of game, up to 100ms of latency is OK. > > nevermind that currently, AFAIK, no HW exists which can do full-scene > global-illumination in real-time (at least using radiosity or similar), You somewhat contradict yourself below, when you argue that clients can already do small-scale real-time global illumination (no fair to argue that it's not computationally tractable on the server, but it can already be done on the client). Also, Nvidia could churn out such hardware in one product cycle, if it saw a market for it. Contrast this to the uncertainty of how long well have to wait for the hypothetical battery breakthrough that you mention below. > much less handle this *and* do all of the 3D rendering for a potentially > arbitrarily large number of connected clients. Just to be clear, I've been making an implicit assumption about these hypothetical ultra-realistic game worlds: that the number of FLOPs spent on physics/GI would be 1-2 orders of magnitude greater than the FLOPs to render the scene from a particular viewpoint. If this is true, then it's not so expensive to render each additional client. If it's false, then everything I'm saying is nonsense. > another problem is that there isn't much in the rendering process which can > be aggregated between clients which isn't already done (between frames, or > ahead-of-time) in current games. I'm explicitly not talking about current games. > > in effect, the rendering costs at the datacenter are likely to scale linearly > with the number of connected clients, rather than at some shallower curve. Asymptotically, yes it would be linear, except for the big chunk of global-illumination / physics simulation that could be amortized. And the higher you push the fidelity of the rendering, the bigger this chunk to be amortized. > > much better I think is just following the current route: > getting client PCs to have much better HW, so that they can do their own > localized lighting calculations (direct illumination can already be done in > real-time, and global illumination can be done small-scale in real-time). I understand, that's what you think :-) > > the cost at the datacenters is also likely to be much lower, since they need > much less powerful servers, and have to spend much less money on electricity > and bandwidth. Money spent on electricity and bandwidth is irrelevant, as long as there is a business model that generates revenue that grows (at least) linearly with resource usage. I'm speculating that such a business model might be possible. > > likewise, the total watts used tends to be fairly insignificant for an end > user (except when operating on batteries), since PC power-use requirements > are small vs, say, air-conditioners or refrigerators, whereas people running > data-centers have to deal with the full brunt of the power-bill. See above. > > the power-use issue (for mobile devices) could, just as easily, be solved by > some sort of much higher-capacity battery technology (say, a laptop or > cell-phone battery which, somehow, had a capacity well into the kVA range...). It would have to be a huge breakthrough. Desktop GPUs are still (at least) an order of magnitude too slow for this type of simulation, and they draw 200W. This is roughly 2 orders of magnitude greater than an iPad. And then there's the question of heat dissipation. It's still a good point. I never meant to imply that a server-rendering video-streaming architecture is be-all-end-all-optimal, but your point brings this into clearer focus. > > at this point, people wont really care much if, say, plugging in their > cell-phone to recharge is drawing, say, several amps, given power is > relatively cheap in the greater scheme of things (and, assuming migration > away from fossil fuels, could likely still get considerably cheaper over > time). > > meanwhile, no obvious current/near-term technology is likely to make internet > bandwidth considerably cheaper, or latency significantly lower, ... My cable modem in Canada in 1995 was substantially as fast as my cable modem in Silicon Valley today, and just as expensive. Technology isn't the impediment to higher bandwidth, kleptocratic mediocracy is :-) Anyway, we're on the verge of having enough bandwidth for this sort of thing. Latency is a tougher nut to crack, but see below. > > even with fairly direct fiber-optic connections, long distance ping times are > still likely to be an issue, and it is much harder to LERP video If the video includes depth information and camera parameters (and why shouldn't it?) then LERPing it is straightforward. > , so short of putting the servers in a geographically nearby location (like, > in the same city as the user), Which is what OnLive does, incidentally. > or somehow bypassing the speed of light, it isn't all that likely that people > are going to really much exceed (in general) about 50-100ms ping (with a > world average of likely closer to about 400ms ping). Yeah, you're not going to play well with people on the far side of the world. Two approaches to ameliorate these are: 1) design-based: create experiences that focus on the beauty of the world rather than game mechanics that require low-latency 2) predictive user models: Nancy Pollard did some interesting work about 5 years ago (http://graphics.cs.cmu.edu/projects/rcfmf/)... the computer can simulate the world based on its prediction of your future input. > > this would lead to a generally unsatisfying gaming experience, as there would > be an obvious delay between attempting an action and the results of this > action becoming visible (which, at least, with local rendering, the results > of ping times can be partly glossed over). (video quality and framerate are > currently also issues, but could improve over time as overall bandwidth > improves). > > to deliver a high quality experience with point-to-point video, likely a ping > time of around 10-20ms would be needed, which could then compete with the > frame-rates of locally rendered video. at a 15ms ping then results would be > "immediately" visible with a 30Hz frame-rate (it wouldn't be obviously > different from being locally rendered). > > > granted, this "could" change if people either manage to develop > faster-than-light communication faster than they manage better GPUs and/or > higher-capacity battery technology, or people become generally tolerate of > the latencies involved. > > > granted, "hybrid" strategies could just as easily work: "just as easily", hah! Here are a couple of problems that are hard for a client-based approach, but trivial for the architecture I describe: Cheating is a hard issue that game developers haven't solved yet; it becomes much easier when no computation happens on the client. Similarly, piracy prevention. Physics synchronization. Current games use physics as eye-candy, but avoid game mechanics that rely on deterministic, replicated simulation across clients. That's because it's hard. I'm pretty sure nobody has solved it; I know that Croquet punted on this problem, and I suspect that David Smith's new Virtual World Framework does too (I haven't found the time to deeply grok the code yet). I'm sure I could come up with others, but it's bedtime. Cheers, Josh > a lot of "general visibility" is handled on the servers, and pushed down as > video streams, with the actual rendering being done on the client > (essentially streamed video-mapped textures). > > by analogy, this would be sort of like if people could use YouTube videos as > textures in a 3D scene. > > > or such... > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
