I've thought of this myself and I think it's a worthwhile project. The big unknown for me is how hard to confirm to the output of the original tools in terms of attenuation, angle of incidence, etc. Because most mappers probably want a tool that doesn't require them to relight their map from scratch due to differences in lighting result. Now, adding optional alternative lighting models would be welcome of course! 

The main goal of the project would be only to make the raytracing (basically the in-shadow-or-not decision) faster. I would preserve the non-physical lighting model of the original tools and those calculations for attenuation etc. even may remain on CPU. It's usually the shadow-testing which is the slowest part after all.

It would be cool to add new lighting features but that's a secondary goal. Nonetheless, specific ideas are very welcome! 

Hey, I saw your project on the GPU raytracing blog here, looks really cool!

I'm maintaining tyrutils-ericw and recently added an Intel embree backend (intel's CPU raytracing library), in some cases it's 2x as fast as what I had, in other cases only about 20%, but it looks like GPU acceleration for baking is the way to go for best performance.

One question, by using hardware rasterisation only for the primary rays, does this mean you're using shadowmapping for each point light?

Large Quake maps can have 1000-2000 or more point lights, I've wondered if shadowmapping is still viable with this many lights. (as I understand it, you render the world on the 6 faces of a cube positioned at each point light?)
For an example of the biggest maps today check out ad_swampy.bsp in Arcane Dimensions (link). IIRC the final light bakes took mfx 30 minutes, this is with 4x4 supersampling, so 16 samples per final lightmap pixel. 

Thanks for checking it out!

By 'primary rays' I'm refering to rays originating from the camera. Point light shadowing is evaluated by tracing rays, I'm not using shadowmaps at all. I wrote a specialised BSP raytracing function for execution on the GPU, you can see that here.

I'm very happy that someone who was working on AD has answered with timing info - that's a truly awesome mappack (which I didn't finish playing through yet) and exactly the kind of mapping project for which I wanted to know the build times. Do you have any more information in that regard? Is ad_swampy the biggest map in the pack?

Your branch of tyrutils seems like a great base to start on, with many nice features. Is it okay if I take a new branch of that? I'm thinking of creating batches of rays to keep GPU<->CPU data transfers low, and that might require some redesign of the code. 

re: primary rays, Ah, got it. :)

re: swampy, yeah I think it's the biggest/most complex map in AD. Some stats on it: 99449 faces, 2270980 lightmap samples. So, the map's lightmaps packed optimally into an atlas would be roughly a 2048x1024 pixel image.

Feel free to fork tyrutils-ericw, if i can answer any questions on it feel free to message me (github / email or whatever). The code is definitely a bit messy, unfortunately.

Reorganizing the code to process rays in batches sounds good, it's something I was experimenting with for the embree backend (only tried it for ambient occlusion rays so far).

The basic structure of light.exe currently is to have one thread per CPU core; each thread grabs a face and processes lighting for that face, until all faces have been processed. ltface.c is the code that's run in parallel to compute lighting for a given face.