There are a lot of reasons why we do it ourselves. I’ll try to remember as many as I can here:

* When baking the lightmaps, the baking process is aware of the full scene, not just the local building or whatever. 3D Studio MAX would choke if you tried to load the full scene of an open-world game into it. It just can’t do it. So if you try to do this stuff in an editor, you have to somehow do a lot of extra work to build lightmaps that don’t have discontinuities or blatant wrongness in junction areas.

* Since a lot of work has to be done one way or another, it’s better to do it in a way that’s not tied to a 3rd-party tool that you have to pay for every year, that is flaky and crashes all the time, and is slow, and is barely even being developed at this point, because the company that now owns it has a monopoly on 3D modeling tools (they also bought Maya and SoftImage). Internally, Max is a pile of shit; this is not a controversial statement, and you will find general agreement on that fact among those who have ever made a plugin for it. So as long as we have to do a substantial amount of work, better to do that work in a way that creates an asset that the company can re-use in the long term, on the next game or whatever, without creating a maintenance and production liability.

* Workflow-wise, it is just much nicer to have this stuff in the in-game editor. You can be playing the game, decide you don’t like something, hit a key to pop open the editor to that exact game location, move an object, then run a low-quality rebake and see the results very quickly, without ever leaving the game.

* Because this is our own code, we can bake lightmaps on whatever platform we want with minimal effort (aside from the effort of porting to that platform, which in general does not take long). Next week we could be baking lightmaps on the PS3 if we decided that was a really good idea.

* If we want it for rendering purposes, it is pretty easy to augment our lightmaps with directional information — either spherical harmonics or a spatial vector basis the way the Source Engine does things. I have seen hacks to do this kind of thing in rendering packages, but they are definitely difficult to do and don’t allow for a lot of nuance. Maybe this kind of option has been built into something like Maxwell very recently, but I would be surprised at that, because it is strictly a realtime app kind of thing to want.

* We are going to be doing some things that involve generating lightmaps that add to each other, for e.g. apertures that open and close. Doing this in Max is another world database navigation kind of problem and has all the issues discussed above.

* Because this is our own code, we can give it out to other developers who also want a solution like this.

That’s all I am remembering for now. There are certainly other reasons too.

Or is it the fun part of creating your own implementation? Or cost?

It may also be surprising that the difference in the timings between 32×32 and 64×64 cube-maps is so small. I suspect the rendering time is pretty much the same, because the bottleneck is on the geometry pipe, and that the difference comes primarily from the cost of transferring and integrating 4 times more texels.