The WinOSi approach to solving the global illumination problem is a 'brute force' method which is very robust and accurate, but indeed very slow - compared to more elegant methods.

My primary intention was to deliver ultimate perfect photorealism, no matter the cost of rendering time. Nevertheless, in the next releases some optimizations will take place, making the renderer about 2 to 5 times faster, I guess.

But remember the first raytracers for the Amiga or the 80286 without coprocessor. They took hours, days and nights too for rendering simple scenes. On today's hardware raytracing simple scenes is possible in real-time! When in 12 years (according to Moore's law) PC hardware is 1000 times faster than today and WinOSi is finished and highly optimized its rendering speed may be not worth any further discussion.

WinOSi is indeed tightly related to the photon-mapping algorithm, but instead of rendering some kind of density estimation interpolated from a few photon samples, WinOSi directly renders the photon hits, which requires a very huge amount of photon samples, making the algorithm very slow, but also very exact and robust.

There are many other articles in the Web about global illumination renderers (mostly using path tracing or some kind of photon mapping technique) but I know only one, which delivers an executable program and even less which comes with complete source code. So that's the reason for 're-inventing' another global illumination renderer: To give me and the whole computer graphics community the chance to experiment with that kind of algorithms on their own.

No. When the image is pretty enough in your opinion, you have to stop manually by selecting Render/Stop from the pulldown-menu.

I am experimenting with the local contrast as a stop criteria. It starts with a high value because of the noise, and if the image gets smoother and the noise reduces with each iteration, the local contrast converges to a certain end-value. Unfortunately this value is not known until the image is finished. So I let the renderer calculate the difference between the current local contrast and the one from the iteration before. This difference value goes to zero when the image has reached its final contrast after an infinite number of iterations. I thought to stop the renderer when it reaches a certain small difference value, but in practice the difference function is very noisy too, giving zero or even negative values very early. You can trace these two values during rendering in the File/Info-Dialog (bottom right).

As far as I can see today: Yes!

.vmd-files are simple text-files that can be created with a simple text-editor like notepad.exe. For people with some experience writing such files (POV users for example) it may be no problem to take one of the existing sample scenes as a template and change and add thinks till the desired rendering will come out.

Alternatively you could use my virtual Modeler VModel to convert existing 3D-files from other rendering/modeling software such as 3D-Studio(.3ds), AutoCAD(.dxf), VRML(.wrl), etc. into the .vmd-format. Unfortunately some fine-tuning by hand with a text-editor is always needed.

Shame on me: A complete description of the .vmd-syntax is still not available. The sample scenes and the source code are the only documentation yet.

If you need a special feature, say, for example: NURBS-surfaces, special procedural textures or a Mac-version, or if you have an idea for optimizing something or know a clever algorithm for this or that - just go on and implement it, send me the source-changes, and I'll add it to the next release and your name to the about-dialog.

When you need information or other help, just let me know - I'll do what I can.

I have a job, a little family, a house with garden and many other hobbies, so I can't afford more than 1-2 hours a week working on WinOSi. My goal is to release a new version with 2-3 new major features every 6 months - let's see how things turn out...