Wednesday, October 5, 2011

Source Engine Levels in WebGL: Video + Source

Took the time to get the source and video demo for the Source Engine demo online tonight. Have a look!


GitHub Source

And of course don't forget to check out the Tech Talk post if you want to know more of the nitty gritty details!

I stressed for a little while about fixing some of the remaining issues before posting anything (like getting water rendering) but in the end I decided that the demo serves it's purpose in that it shows that we can push a lot of geometry for a complex scene and still run at the speeds that realtime games require. Beyond that, however, I won't be able to make use of the format for any other projects and at this point I want to start working on something that is actually playable, not just looks pretty. As such, spending any further time on the format isn't practical.

I have started on my next WebGL project, and hopefully I'll be at a point that I can start posting about it soon. See you then!

19 comments:

  1. Something I had thought about, was how to make it only a first-time download for a large complex scene. My understanding was most of the new API's for local storage that seem to be appearing only allow for very limited local storage (nothing like 200mgs)

    Anyway Impressive Demo! look forward to seeing your next project.

    ReplyDelete
  2. In this case it may be a lot more effective to look at the Filesystem APIs. With them you can request as much space as you need, and the user is asked to confirm if they want to allow it. They're not widely supported yet but should be more popular in the coming years, and I've already seen a couple of games use them (GunBros in the Chrome store, for example).

    ReplyDelete
  3. So how do I actually get this to run? I extracted the .bsp file of a stock map (pl_frontier and I tried ctf_2fort as well) and tried placing the resulting files in different locations. I poked around in the source, but I haven't worked with JavaScript this complex in years and don't really know what I'm looking for.

    ReplyDelete
  4. Okay, so a few more details on getting everything in the right place. When you open up the GCF you'll see that the top folder is "root" The easiest way to get everything to run is to basically dump that "root" folder into the "root" folder than was checked out with the repository. So you should end up with a directory structure that looks something like this:

    - webgl-source
    -- root
    --- tf
    ---- maps
    ---- models
    ---- materials

    If you want to change the map that is being loaded, look in the index.html file under the "initMesh" function. The code looks like this:

    map = Object.create(SourceBsp).load(gl, 'root/tf/maps/ctf_2fort', function(map) { ... ));

    Obviously you should replace 'root/tf/maps/ctf_2fort' with the path to your own map (excluding extension.)

    Even if you don't have the materials in the right place you should still be able to see the level geometry come up with a default checkered texture. That will let you know you're on the right track.

    ReplyDelete
  5. Have you seen Flash11 running 3D??

    http://www.youtube.com/watch?feature=player_embedded&v=UQiUP2Hd60Y#!

    ReplyDelete
  6. Yeah, I saw that the other day. Funny thing is, I'm getting knocked by commenters on other sites for basically only putting together a "Glorified level viewer", but that's basically all I've see in the UE3 Flash demos anyway. I don't see a whole lot of difference aside from their renderer being more complete and professionally made.

    (They're totally right about my stuff, BTW. It's really just a buggy level viewer. It's not THAT special.)

    Of course, I'm quite certain that, given the resources Epic has available, they can turn it into something playable much faster and better than anything I am capable of in my spare time. In any case, it will be interesting to see how well Flash (and HTML5) handle the dynamic stuff like physics, AI, networking, etc.

    ReplyDelete
  7. Well flash is already pretty good handling physics (there are several games with phisics engines embeded). And networking is good, a few years ago I was experimenting with a messenger I made using a server that someone made in Java, it was responding pretty good and that was Flash 8, (in 2007!)
    IA shouldnt be much of a problem for Flash since AcitonScript3 is pretty fast calculating data. The only problem Flash always had, was rendering speed, and crappy programmers (or designers doing developer tasks). But now that is fixed with a solid language and GPU acceleration is (in my opinion) pretty much the desired system for any web developer if given a chance.

    By the way, this demo was using network capabilities for online gameplay (it was tested in LAN, i dont know how it works over the internet)
    http://www.youtube.com/watch?v=tgwi0lWgX8w

    ReplyDelete
  8. Update to a comment I made earlier:

    @petsound pointed out on Twitter that there was actually gameplay demonstrated with the Unreal Engine Flash demo. So NOW you can consider me thoroughly impressed. :)

    http://www.youtube.com/watch?v=IykhED4lAWM

    That said, it was very interesting for me to note that during the gameplay demo you can see the mouse cursor wiggling back and forth across the screen. This means that even within Flash they still haven't worked out the Mouse Lock issues! (Notice that the player doesn't really turn much.) It's going to be pretty tough to make a game like this work unless they're doing some serious work on the input front.

    In any case, it just proves that Flash is far from dead. It'll be very interesting to see how it evolves in an increasingly HTML5-driven world.

    ReplyDelete
  9. Interesting videos, very impressive unreal 3 in flash. Would be nice if a mainstream games company would invest some money and time into webgl (though maybe its not ready for this). I only hope that webgl isn't left behind flash. I love adobes software, but would much prefer wide adoption of an open standard then the flash plugin.

    ReplyDelete
  10. Unrelated to the videos, but a decent solution to the mouse aiming problem is to have it sort of work like an analog stick. Put your mouse inside a "dead zone" near the center of the screen, and once it leaves that center, the camera starts rotating towards the relative direction that the pointer is in. Not as optimal as current FPS mouse controls, but I think it's worth experimenting with in that way.

    ReplyDelete
  11. I have seen a few demo's take this direction, fine for experimenting but I can't see a fps player accepting it as an option in an FPS.

    ReplyDelete
  12. I see. Well, I just read about the mouse API supporting centering the mouse soon anyway, so I guess it's just a matter of waiting instead.

    ReplyDelete
  13. Thats great, it makes sense to improve Mouse API.

    Flash is going to be an amazing web plataform I think websites are about to get a lot more interesting !!

    ReplyDelete
  14. I looked at model shader source and you have 1 really basic mistake or oversimplification. You normalize light direction and eye direction vectors in vertex shader. Normalization isn't an operation that can be factored out of fragment shader into vertex shader.

    ReplyDelete
  15. Now all we need is JimboMCB (Aka Nope.avi guy) to make it possible to Spectator in a HTML5 browser! http://youtu.be/isGf63qiisM

    ReplyDelete
  16. Hey Brandon, thanks for the demo, definitely impressive. This level of browser native 3D without a plugin is amazing. I am wondering if WebGL shaders would support a url-based streaming video of any format mapped to a plane? Will Flash or WebGL input data from hardware like motion sensors on laptops or smartphones? I've just started looking but not finding anything easy…

    ReplyDelete
  17. Was this really a render of the map, or a clone of the map? Things seem... off. Like, all signs -- even the one above the resupply door and the one towards the intelligence -- say BATTLEMENTS instead.

    ReplyDelete
  18. It's a rendering of the actual map resources, but yes: Things are off.

    The "Battlements" signs are everywhere because I didn't implement support for alternate mesh skins, and the base skin for the signs is the Battlements one. I'm also missing animations on certain meshes, decals all over the place, water effects, correct displacement surfaces, proper bump mapping on static brushes, etc. etc. All of the data is available for use, I just haven't taken the time to parse and process it. At this point I doubt I ever will, since there's not much use for this beyond a simple tech demo that wouldn't infringe on Valve's IP somehow.

    ReplyDelete