Bullet Physics

The embedded video shows the Bullet physics library being used in a Syntensity world. 100 boxes are simulated, as well as the static world geometry. As you can see, the boxes behave in a physically realistic way.

This is just an early demo - it would take more work to get this ready for actual games. But the hard integration part is now finished.

If you're curious to run this yourself, then instructions are at the end of the COMPILE.txt file.

Windows Building Improvements

Building on Windows should now be much easier:

• SDL (all parts) is bundled in the git repo in binary form, so you don't need to get that or set it up. These are the latest versions of SDL, which include some useful bugfixes.
• Likewise the latest zlib is bundled in binary form.
  
• Boost.Python is bundled in source code form, and compiles correctly, which prevents the need to get or set up Boost at all. This is very nice as the precompiled Boost we previously used assumed you were using Python 2.5. Consequently, the engine will now build using Python 2.6.

The process should now be very easy, basically just

• Get git, scons, CMake and Python.
• Get the Intensity Engine source code.
• Build V8.
• Run CMake to generate a VC++ project file.
• Build the project in VC++.
  

For specific details, as usual see the COMPILE.txt file.

I develop on Linux, so sometimes the Windows stuff gets delayed, sorry about that. Speaking of which, volunteers willing to help with Windows and OS X stuff would be very welcome.

Browser Plugin: Proof of Concept

In the following video you can see Syntensity being run inside a browser, as a plugin:



This is a followup to my post from last week, 3D and the Open Web. After the speculation in that post, I got to coding, and the result is a working proof of concept.


Status

The plugin works, as you can see in the video, and you can enter Intensity Engine servers (including Syntensity's) normally, just as you would with the regular client. This is still in early stages, however, so you should expect some limitations:

• The plugin will currently only build on Linux (where I develop). However the code on which I worked is cross-platform (see below), so this should not be a problem to remedy later. Meanwhile, Linux users can try it out for themselves using the instructions at the end of the COMPILE.txt file.
• Works in Firefox and Chrome, not tested elsewhere (that's Chrome you see in the video).
  
• Mouse input works reasonably well. Keyboard input should work as well, but doesn't, probably for some minor GDK reason I will look into later.
  

Technical Details and Notes

• Built using the O3D plugin code (which in turn is closely related to the Chrome codebase). The O3D code is not meant to be a general-purpose basis for browser plugins in general, so it took some hacking to get things working, especially to integrate with SDL (which we use for rendering and input). Not surprising I guess. Anyhow, the O3D code was very useful here, thank you to the authors!
  
• The implementation I wrote runs client instances in separate processes, which is good for security and stability. In other words, the browser plugin is a small component that runs actual clients (that render, run physics etc. etc.) in separate processes.
  
• Interprocess communication is done using boost::interprocess (Chrome's more powerful IPC turned out to be more complicated to set up, and anyhow it's probably overkill for what we need).
• Very few modifications were necessary in the main Intensity Engine codebase. Rendering is still done using SDL, etc. A couple of minor tweaks were needed here and there, though.
• A combination of Firefox and Chrome turned out to be useful during development - Firefox is easier to use in debug mode, to figure out crashes, while Chrome is more resilient to crashes bringing down the entire browser (although I hear Firefox will be adding a similar feature soon).
• Overall, my conclusion is that the browser plugin approach is not easy (there were several technical hurdles that I ran into, like this) - but it is possible.
  

Other Approaches

As an experiment, I think it is now clear that the browser plugin way is feasible. It's still an open question of whether it is the best approach, or whether one of the alternatives (mentioned in the previous post) would make more sense. I tend to favor this approach though (making our own browser plugin), for the following reasons.

I have gotten no response on the O3D mailing list, where I asked about possible collaboration (like contributing our code to there, to add features games need like networking, physics, etc.). I guess it isn't relevant for them. In that case, it probably doesn't make sense for us to move to O3D - porting the rendering engine would be a lot of work, and it turns out that making our own browser plugin (in part using their non-rendering code) is feasible.

WebGL seems to be favored by some people in the virtual worlds community. It's definitely an interesting technology, but I am doubtful it would work for games, or more specifically action games like we have in Syntensity, for several reasons:

• WebGL is not complete, and WebGL's performance limitations are not yet clear (and not sure when they will be).
• WebGL + JavaScript - a pure web implementation - would be too slow for very complex clientside physics. NaCl might help with that, eventually.
  
• Network protocol-wise, TCP (even with nifty things like Comet, etc.) can't give the performance that UDP can, in terms of realtime updates.
• Also, it is unclear if WebGL will ever make its way into Internet Explorer. After all, WebGL is based on OpenGL, which Microsoft has been trying to kill. A related issue is that not only is a major browser hostile to WebGL, but also a major desktop operating system - users often need to manually install OpenGL drivers from the manufacturer's website, which is no better than installing a browser plugin (in some ways worse).
  

That said, the Intensity Engine has always been a web-oriented project, what with JavaScript used for scripting, HTTP for asset downloads, asset and server management done using a web interface (on Django), etc., so if later on WebGL matures into something relevant for us, we can certainly consider moving to it.


Bottom Line

The open source community can have something like a FOSS Quake Live, or more generally a proper open solution for 3D content on the web, from casual stuff to multiplayer action games. The potential here is vast, and it is within reach, basically right now.

If we are to go forward with this, we will need help from the open source community, as browser plugins need a lot of testing on all the different operating systems and browsers and so forth. So, help is welcome. Also, ideas on how to do things would be appreciated, in particular about how to get the licensing issue right - as mentioned in the previous post, if changing our license will get more people on board, we are open to discussing that.