I don't think anybody said it couldn't be done, just that it probably wasn't feasible at this point. With a quick glance at the paper (I'll read it all when I have time), this technique still makes you pay for the latency (hello real-time) and a very hefty bandwidth toll that'd make online games unplayable on most connections.
Fuck off. You not see that last part of the video or something?
Latency was the reason I said was why you don't render the simulation with data not from the client.
The moment you tie dynamic lighting into something players control is the moment that 100ms latency becomes input lag and you know damn well how much gamers despise input lag.
This has its uses in the LAN, but that's it. On a regular networked game, the latent lighting from a flashlight means you see a player come around the corner before his lighting catches up with him and you can not see around the corner until your flashlight catches up with you.
Except it looked pretty good even at those very high latencies, even with the jumpy light. That's what compensatory algorithms can do for you. And how many gamers play with 500-1000 ms latency rates? Anybody serious enough to care about that little bit of lag is not going to be playing on such an awful connection. Not only that, but the direct lighting isn't what this is really about, it's the diffuse. As in, the stuff that's going to actually use up the local resources at a greater rate when it tries to model where the photons are scattering to instead of simply being told where they are and then mapping it. Finally, this doesn't necessarily have to be tied to a player-controlled item, it can be environmental. The goal is offloading some of the work, not making everything controlled remotely.
So get real, you are pulling it out of context and seem to have a narrow idea of what this stuff can and will be used for. You said it wasn't workable and Nvidia just demonstrated that it is.
Oh yeah, I'm definitely out of context with a narrow idea of what it can be used for even though I've said it's perfectly fine in a LAN setting where latency is low/non-existant while disastrous for interactive things like games where lag is incredibly noticeable.
You're posting in a FUCKING XBOXONE THREAD about something that would be a disaster if implemented on something the console was using while saying I have no clue what I'm talking about. You've admitted that you have no programming experience on this. Not like I've actually coded things reliant on serialization for games or anything oh wai.....
You're worse than 9mm ever was. He even admitted to never reading things he talks about and you haven't gotten there yet.
If you actually did read what you brag about you'd know that this can indeed work with the xbone. Their goal was to see if the hardware environment could support such a thing and it did. However, they've stated that latency is indeed the weak point in the system and they don't expect it should be implemented for anything beyond a few network hops. Do I really need to go over how many hops are likely to take place along the player's home, local ISP, high tier host, the XBL datacenter, and then the compute farm itself?
Seriously, the whole research project just confirmed that the hardware today has enough bandwidth to be a light farm for 50 or so local clients and remain competitive in quality you'd expect for higher-end PC hardware. This is something that would push light from your PC to your nVidia Shield.
I don't see why this is great. Your streaming a crticial part of the engine from a serverbox over a internet connection, just for ligthing. What good possible uses would this have? Maybe some clearer, sharper graphics, but is that really neccessary nowadays? You're getting latency just for maybe a slightly noticable difference if it was all being done local.
http://www.youtube.com/watch?v=lbrmAsxJPv4
Stupidest idea ever putting a native wireless receiver on the console.
BRB, going to an MLG LAN and haxxoring the consoles in the middle of matches.
There are currently 1 users browsing this thread. (0 members and 1 guests)
Bookmarks