Maybe not native to the browser, but as plugins.
VRML and later X3D have been available as plugins.
Java actually already supports it via Java3D.
There are occasional gaming websites that offer it via their own plugins.
The problem is, gamers haven't been picking up browser based games.
And by "gamers" and "games" I mean AAA games played by "core" gamers. Yes, I know about Flash games - they've been around for a long time now. But if you're talking about 3D, you're not talking about casual games anymore.
The big question is: What's the advantage?
Platform independence? Not really - OpenGL has been offering that since day one, and most games are written in C++, which has compilers for nearly every platform imaginable.
Automatic updates? Nope - online distribution platforms like Steam and Impulse already offer that, and many games have automatic updating code built in.
Online storage of player data? Nope - multiplayer games do that already, especially MMORPGs.
So what's the advantage?
All of the usual advantages that people claim for online apps are moot for games, because games already offer them.
The only thing you get with a browser based game is the browser chrome - and, frankly, most gamers think that's a waste. Why launch a browser application to launch your game instead of launching it directly from the OS?
There are many issues with heading in this direction with games:
Offline storage of game assets is a big issue: Games require a lot of 3D models, textures, and other various artwork. If you have to re-load all of that every time you open your game, you're in for a painful multi-hour wait.
Even games like WoW, which are perfectly capable of downloading content on the fly, keep gigabytes of data on the local machine.
In addition, most games use C++, and for a very good reason: Performance. C++ compilers can spend a lot more time optimizing because they don't have to worry about launching the application right away. You can get a lot of high performance code by spending more time optimizing it before you ship it.
In addition, the performance you get with a C++ compiler is predictable, while a JIT compiled language is not predictable: Performance can vary depending on whether or not it has optimized a section of code yet.
You don't want your game stuttering while a player is playing because the JIT compiler has reached a new section of code and needs to compile it. Or because it's a dynamic compiler and decided to further optimize a section of code that the game was using.
Another thing to consider: You can shove email and word processors into servers easily because they don't really require too much in the way of client side performance. One of the reasons why browsers work so well for web applications is because most web applications are just HTML slapped on top of a server side application.
But it's a whole different game for games
. Games are generally very heavily bound to both the GPU and the CPU, and obtain no benefit from being on a browser. You can't put them into a thin client setup like you can a word processor, and you gain no benefits at all from throwing them into a browser window.For the best performance with the least lag, you need to be throwing those polygons and performing those AI and physics calculations on the client side.
If you try to throw them onto a server, here's what happens:
-Your costs skyrocket. The latest video cards are expensive, and you're buying one for every player hitting your server.
-Bandwidth becomes a tremendous problem. You're piping real time, full screen, often HIGHER than 1080p video to everybody.
-Either that, or you're piping huge amounts of art assets to the player. On the order of gigabytes, perhaps tens of gigabytes (I own games that are larger than 10 GB).
-Lag becomes a problem. You now have an extra network trip for the keyboard/mouse actions and the resulting video.
-And by "lag," I don't just mean bandwidth: I mean latency. Even at the speed of light, the time it takes to travel halfway around the world is well within human perception range. You're not going to solve that with bigger pipes or better technology.
-Your players are now playing "in a browser." Which is basically sitting there doing nothing. It doesn't give them any benefit.
Is it theoretically possible to do it? In some ways, yes. Runescape and some other games do it.
But every time you lose the cached copy of the applet, you have to wait for the game's basic code and assets to reload. In addition, if the game can't load new assets fast enough, you get lag spikes and/or parts of the map appear blank while the scenery is loading.
In addition - what is the browser doing during this time?
Well, it's doing nothing.
-Most gamers play in full screen. The browser chrome is gone.
-The game itself is likely just a plugin. The browser supplies a container to hold the plugin, but that's about it.
-I can guarantee that game devs are going to bypass pretty much everything in a browser to squeeze as much performance as they can out of it.
-If you think that future games are going to be this mess of scripting and markup languages that we have today for web applications - think again. It's not happening.
Basically, the browser really provides no services that are useful to a 3D game. 3D games don't use HTML, they don't use JavaScript, they don't use any of the common protocols, and they don't use any of the services that the browser provides. A browser really doesn't provide any benefit for a 3D game.
This *might* give us something like Google Earth in a browser - but I find it highly unlikely that the gaming community is going to use it much.
