Aside from some quick tweaks the importers and zombies, most of the day has been given over to the work on the lightmapper which will provide the Ambient Occlusion textures required to make the Reloaded scenes look better and run faster. One of my early wins was the reduction of a structure called 'Lumel' from 12 bytes down to just one byte. The original lightmapper could handle multi-colored lightmaps for things like semi-transparent stain glass projections, but for here and right now we do not use them. Further, the data structure used a four byte float to store the accumulated light colour for each pixel, but as this float only converted to an unsigned char at the end of the day, I simply replaced the float with a byte, did the float conversion each time the pixel was added to, and simply passed out the final capped byte when the time came to create the light map texture. This saving took my per-lightmap consumption from 13MB to around 1.5MB based on a 1024x1024 texture plate. This overhead can be reduced further if I replace the Lumel class with a raw array of bytes but that would mean extra coding and doubtlessly introduce a nice bag of new bugs.
Happy with my saving on the system memory front, I turned my attention to activating the multi-core feature of the present lightmapper. I tried a while back but for some reason it would not play ball so I stuck with the working single threaded approach. Now I am doing test bakes of large levels such as 'The Escape', I cannot afford to sit around waiting 30 minutes for a crash so need to speed up this process so I can get more done.
Of course I had to turn my attention BACK to the LUMEL optimization when I found out that the same data structure was being used to store position and normal vectors in the former float members. This prompted the creation of anew LUMEL LITE data structure to separate the texture pixel work from the hijacked vector code. By this time it was 3:43PM and day light was running out but it was good to see the lightmapper perform in an identical way except for the drastically less memory and for some reason slightly better performance.
After another 30 minutes, I was able to confirm that multi-core does indeed work a charm, as can be seen with this processor view showing 100% concurrency!
As baking The Escape level takes ages, only to be rewarded with a nice mystery crash, this will probably be my closing entry until I return a week from now. It's rather fitting that my departure to attend IDF launches with my engine using all eight cores on my PC, something Intel like to see.
I won't be demonstrating much at the IDF show this year, just my ability to drink beer and talk nonsense, for which I am overqualified. Until my blog returns on the 15th September, you can tune into my twitter feed at @leebambertgc which I occasionally post on when I have a spare five minutes alone with my mobile. Have a great weekend!!
Have a safe trip Lee. FYI your headed to Earthquake country, they had a lot of them recently near San Francisco.
ReplyDeleteCooooool! Me likes your progress greatly :D
ReplyDelete@lee not sure if you have seen this but its a directx to opengl port by valave specific for directx 9
ReplyDeletehttp://www.extremetech.com/gaming/178276-valve-open-sources-its-directx-to-opengl-translation-software-here-come-the-steamos-and-linux-games
It's all Greek (or should that be Geek?!) to me. But it sounds like major improvements are being made to both visual quality and performance which is very pleasing! I think I will get withdrawal symptoms until your next blog entry,
ReplyDelete