POV-Ray

It appears as a side effect of investigation of #294: the code in isosurf.cpp, inside
bool IsoSurface::Function_Find_Root_R(ISO_ThreadData& itd, const ISO_Pair* EP1, const ISO_Pair* EP2, DBL dt, DBL t21, DBL len, DBL& maxg)

	if(gradient < temp)
		gradient = temp;

is not thread-safe (The code is used at render time, there is a data race between < and = operation, as gradient is stored in the global object and accessed in write mode by the cited code)

It is only important if the gradient is initially undervaluated (otherwise, all is fine, no write-access)

Now the editor remembers only the cursor positions of the loaded files when starting a new PR session. It would be more friendly to remember whether the window was split or not, as well as the bookmarks.

Currently POV-Ray does not support rendering lens flare effects, however, they can be simulated using a macro (include file) by Chris Colefax.

I would like to suggest adding a feature to POV-Ray to support lens effects “natively” since

• as far as I know the macro has been designed for POV-Ray 3.1 so with each new POV-Ray version it gets more likely that this macro does not work properly any more
• the macro does not work when rendering with radiosity, probably because the macro creates the lens effect by using a pigment with a high ambient value (which is ignored by POV-Ray 3.7’s radiosity algorithm).

Additionally, the macro is not quite easy to employ because

• it needs to know the exact camera parameters (location etc.) and defines an own camera itself so any important camera information has to be stored if the effect has to work as expected
• it does not (actually cannot) take into account that objects may (partially) hide the lens effect
• reflections and refractions (of light sources) cannot be combined with it properly - the user would have to calculate both the point where the reflected/refracted light source can be observed and the shape it then has due to distortion, and in more complex scenes such computations are nearly impossible in SDL.

I would suggest integrating such a lens flare rendering feature with the “looks like” mechanism you already have for light sources. Several parameters that can currently be set for the macro - including effect brightness and intensity, lens options and whether to create a flare at all - could be set for the light source.

Then POV-Ray could store the location and colour of each ray that finally intersected the “looks like” object of a light source and, having finished the main rendering, from that data compute a partially transparent “lens flare layer” eventually mixed into the rendered image. By this, the above mentioned problems could be avoided:

• an object fully or partially intersecting a light source’s “looks like” object would also reduce the number of pixels used to create a flare - and therefore reduce that flare until fully hiding it
• the same goes for reflected and/or refracted versions of the “looks like” object
• the camera’s location and other properties would be used automatically
• and finally, as a feature supported by POV-Ray itself, there would be neither compatibility issues nor problems like the effect not fitting together with radiosity.

Do not get me wrong, I would not expect POV-Ray to really calculate intersections that naturally happen in a camera lens, causing lens flares. Effects looking appropriate can actually be created just in 2D space (as some graphics programs do support) so the work to be done would, as far as I have any overview, be:

• storing, as mentioned above, the relevant data for pixels showing “looks like” objects
• calculating a lens flare from that data after the render has finished
• overlaying the rendered image with the newly created lens effect.