Anonymous wrote:But I wonder ... why did you not start from fsrad ?
I have at least two reasons for wanting to implement it from scratch:
Implementing it from scratch provides a better learning experience for me -- I know a lot more about a lot of things now than when I started.
I am the sole author and have complete control over it.
But the primary reason for not wanting to reuse FSRad code is simply because it doesn't make sense. I planned to do the actual lighting in a way very different than FSRad (rendering hemicubes using OpenGL vs. an analytical solution), I didn't care about the model formats supported by FSRad, etc. I wouldn't really be using any portion of FSRad except for the texture packer.
I already had a working obj reader class of my own, and obj is the file format I was most interested in supporting. I have my own imaging libraries, so why use what's in FSRad?
I also wanted to do my lightmapper in VB6 -- both so I could reuse my own code and because it's easier to prototype with (if I decide to release the source, I'll probably rewrite it in C++ first).
And now I may be diverging even more from FSRad. My immediate work will be focused on trying to get more speed by putting more work on the GPU. Indeed, making use of GPU features which weren't even available when FSRad was written, unless I'm mistaken.
FSRad is great, but there are more ways than one to skin a cat. My aim is to do it differently, and my decision not to base my lightmapper on FSRad reflects that.
.
) can render a scene in radiosity on the GPU in just over 1 second, for geometry that took a professional package 96 seconds to calculate in software (260,000 elements).
