Saturday, November 6, 2010

More Coloured Light

I've been doing some work on the light tool, just fixing more bugs/omissions and working on the display output. For the latter, an unfortunate aspect of the original code is that it assumes linear execution of the lighting function. Moving it to parallel execution brings some interesting decisions to the table...

After experimenting with various options I've eventually settled on displaying progress separately for each thread. This does mean that the output is going to be considerably more verbose than the original (8 threads gives 8 times the output) but at least it's now accurate on a per-thread level, and allows you to track progress of each thread individually, which is cool.

I'm resigned to the fact that whatever I do with this is going to make somebody somewhere deeply unhappy, but in the end I think erring on the side of not messing with the original code too much is the right way to go, and this way lets me retain it largely intact.

Hopefully this release 2 will be out over the next few days.

____________________________


Speaking of releases, the RMQ engine pre-release should also be out roundabout the same time.

2 comments:

=peg= said...

I was thinking, following the discussion here, maybe it is possible to have the light tool print a warning whenever clamping occurs (or will most likely occur at runtime) so that the mapper has at least some idea of what values to go for, rather then doing a whole lot of testing to find the limit..

If the output would be too messy, maybe only when -verbose is used..

Again.. just a thought.. ;)

mhquake said...

It's a nice idea but say you have a map with a light data size of a coupla MB (not unreasonable for a big map) - that's a potential coupla million warnings straight away.

Likely to occur at runtime isn't really possible as that's also dependent on the lightstyle strings, which are defined by QC.