Potpourri – Jul 22, 2009

A buddy of mine from GarageGames days, Orion Elenzil, posted some notes on how to get started with the free Flex SDK. Take a peek to see just how simple it can be to get started with Flex.

for those who may come across this post on their search to learning how to set up a command-line-only Flex environment, and who also know previously zilch about Flex/AS/Flash, i sketch the steps very roughly here: http://elenzil.com/flash/flash_1

— Orion

If you’re into Flash coding, you should also read Rob Sampson’s post on AS3 Math Optimization – int is the new floor(). Rob’s been doing ActionScript a lot longer than I have, and I love the historical perspective he can provide. You can tell he’s a graphic designer – his performance charts look awesome.

I have to quote this from Jeff Tunnell’s blog, Make It Big In Games:

I stumbled across this YouTube video of Gary Vaynerchuck of Wine Library TV giving a presentation at Web 2.0 Expo. At first I just thought the guy was a dick, and he even calls himself that at one point in the presentation, but it turned out to be a fascinating 15 minutes of video. Gary essentially says what I have been saying, i.e. make sure you love what you do, work hard, and things will work out, but he says it in a much more succinct, hard edged way than I do.

Check out the video here.

Blast From The Past: Blitz3D Models in Torque

I found some old screenshots on a backup, and uploaded them to my Flickr account.

As I was filing them away, I looked back in my .plans at GarageGames and realized that I had never talked about it publicly. At least, the site search didn’t turn anything up. Well, I think it’s probably safe to do so now. 🙂

Way back in April of 2005, I wrote a Blitz3D loader in Torque for Adrian Tysoe. It loaded Blitz3D files, with all their texture and material data, and it did polysoup collision, as well. This was several years before I released the OPCODE-based poly soup resource, which I think is now (in some form) in the official Torque codebase.

Montage from Blitz3D Loader Work

I love seeing how graphics code comes together, so I thought I would share this with the world – you might like clicking through the images and seeing how each step changed things. By far the biggest pain point was parsing the (sometimes obtuse) Bitz3D format. The format might be a pain, but in the hands of a good artist like Adrian, it gave really solid results. This was all before shaders were mainstream, of course, but still – the sand had a nice specular highlight, there was lots of clever texture layering, and the whole thing was pretty fast to render.

The more interesting aspect to doing the B3D loader was the prevailing opinion in the Torque community at the time that loading a non-DIF/DTS format was impossible – as was deviating from the collision models those formats used (convex polyhedra mostly). I’m not quite sure where they got this idea, but it was awfully frustrating at times to see people beat their brains out on those formats when there might be better options for their specific situation.

Partially, I did this project to prove to myself that I wasn’t just bullshitting people when I said that writing a loader/renderer was easy (certainly easier than canceling your project because another format wasn’t working for you!). It took me a month or so of part time hacking to get it all together. It didn’t animate, but it was just for environments – DTS is actually an awesome format for characters, and the 3Space runtime is very tight, one of the best parts of Torque in terms of features. (Aside: I hope they get a good Collada->DTS converter as the main pipeline sometime soon!)

Two years passed before anyone put polysoup in without rewriting the rest of the engine to use some other physics SDK. Actually, I ended up being the one to integrate polysoup with DTS. :-/ I was surprised no one else beat me to it! I brute-forced it – every triangle as its own convex. Torque ran this approach like a champ as long as you didn’t feed it tiny triangles. Did the same trick again when it came time to write Atlas1 collision a few months later, but that wasn’t really “polysoup” in a meaningful way for anyone since it only imported heightfields.

It’s interesting to me that the current Torque maintainer (and all around good guy) Matt Fairfax wrote loaders for .3DS, Quake3, and Unreal formats, and the maintainers that came before me (Rick Overman, Mark Frohnmayer, and Tim Gift) have also done things of this nature (in fact, they are at least partially responsible for DIF and DTS). I guess you don’t get to hold the reigns of TGE unless you’ve written a couple 3d renderers/loaders.

I think in total I’ve done 4 loaders with renderers – Blitz3D, Chunked LOD (for Atlas 1), Atlas2, and OBJ. Really, OBJ doesn’t count. Every graphics programmer in the universe has hacked up a OBJ loader – from Carmack on down.

In conclusion? I guess there are a few morals to draw from this nostalgia-inspired post:

  • Keep shots from your old projects. It’s fun to reminisce! I have a few hundred shots from Atlas development that might be fun to write about some day…
  • Don’t be afraid to buck common knowledge and go out in a technical direction no one thinks is feasible. Try it small and if it works, keep going.
  • Do projects for fun! Good stuff will always find an opportunity for reuse – be it some code, or a technique, or even a fresh perspective. The ideas and techniques I came up with for this project ended up helping me for years to come. Working with Blitz3D’s format helped me see Torque’s approaches in a fresh light.


Edit: Adrian Tysoe posted on GarageGames about his side of this experience – here’s what he had to say:

Heh, I remember working on this with you. I figured they were the starting point for some of the later torque advancements. Just wish that the DTS had been updated to support more than 1UV. Was pretty fun to work with and performance was decent.

The worst part was trying to match invisible torque terrain collisions to .b3d meshes just to get the nice water blending around the edges. The terrain used the coldet collision for the actual character and weapons etc.

Was pretty neat and I enjoyed having 2UV’s to playwith so I could bake my own lightmaps in 3dsmax of gile[s], in many ways the most useful thing to make TGE rendering look a bit nicer.

Here’s a couple more pics the project Jeremy and I started using it.



Blockland Physics

I spent some of my downtime over the past few months working on client-side brick physics for Blockland. The feature has finally been announced, so I can talk about it. The video shows off most of the features; the main one that isn’t shown is the interaction between players/vehicles and bricks; they will push bricks around but aren’t affected themselves. Watch it in full screen, it’s full 720p HD video.

There were two big problems related to doing physics for Blockland. The first was the scale of the problem – there can be well over 100,000 bricks in a single server, which is beyond the capabilities of most physics SDKs to simulate as discrete objects. I started with PhysX, and moved to Bullet after realizing that the PhysX runtime is 80mb, far more than could be included in the Blockland download (which weighs in at 20 mb). Both of these libraries broke in different ways with large numbers of objects.

At first, I implemented a management system for brick proxies, so that it kept them under the hard limit in the SDK (around 2**16). PhysX accepted this, but Bullet’s broadphase has some stuff that’s O(# objects) or worse, so it fell down. Eventually, I moved everything into the same system used for static world geometry, which was a grid of static meshes. It turns out that Bullet is a bit faster at creating these mesh objects than PhysX was.

The static mesh cache took quite a bit work to get solid. Because the simulation is for aesthetic purposes, it can tolerate a fair amount of “fudge,” which I take full advantage of. Nearly every kind of update is timesliced so that only a little bit is done each tick. This keeps things smooth, even at the cost of the physical state being inconsistent for a tick or two. Most updates are lazy, as well, only done if a dynamically moving brick, player, or vehicle comes into the area.

The other problem is the wide variability of Blockland user’s computers and usage patterns. Not every user has enough CPU to run physics. And every user has the potential to build something that is very resource intensive to simulate. I spent a lot of time implementing a “physics diaper” – logic to detect when physics calculations were taking too much time, and scaling back the simulation until it’s fast again. This takes two forms. First, if physics ticks are too slow, the simulation is decimated – every other brick on the list of moving bricks is converted to a lighter weight parametric simulation that doesn’t consider collisions. If they remain too slow, then eventually the physics simulation is disabled entirely, until the user turns it back on. This can help with very complex builds or very slow computers.

Thanks to good physics middleware (I include both PhysX and Bullet under the “good” category, even though PhysX is a little on the bloated side), I was able to solve a pretty tough problem – simulating motion for hundreds of thousands of bricks on commodity hardware – in short order. And I have to thank my friend Eric for making such an awesome sandbox and letting me play in it. 🙂

Another Flash MMO Talk

Via Ted On Flex, a talk on “Creating an MMO w/ Flex 3 in 59 Min” by Samuel Asher Rivello. This should be of interest for anyone who attended Raphael Cedeno and I’s talk on Unlocking Flash To Build The Next Great MMO. Definitely worth a watch.


Debugging Tamarin

I’m getting my feet wet in Tamarin, the open-source ActionScript 3 runtime from Adobe – same code that’s in Flash 9. It’s cool tech, and I’m ecstatic that they had the cajones to bring it out into the world – where it’ll definitely make the world a better place.

This gets kind of technical so I’ve hidden most of it behind the jump.

Continue reading “Debugging Tamarin”