END OF AN ERA, FRACTALFORUMS.COM IS CONTINUED ON FRACTALFORUMS.ORG

Just released JWildfire V0.65.

This time I dropped the concept of the external renderers because they are in fact not needed any more and would drain too much of my development power (there were both 32 and 64 versions, and each plugin I add to the main software had to be added also to the external renderers etc.).  The only remaining benefit was memory use, as the external renderers used only buffers of 32 bit precision. You can now also choose those buffers in the internal renderer, they are even the default as there is no supposed difference in visual quality in the most cases.

The other "big thing" in this release – as reported before – is that the generation 2 of the dancing-flames-module is now useable and enabled for everyone! This was really a long road… A tutorial will follow soon.

Another nice feature is one new kind of "3d hack": you can now establish a z-dimishing of intensity which goes along with the DOF. I. e., brightness dimishes with distance of of the observer (camera), which helps to make more realistic "pseudo-3D"-renderings.

Complete list of changes:
- new "dimishZ" property to create more realistic looking pseudo-3D-renders
- dropped the concept of the external renders! The only remaining benefit of the external renders was the lower memory consumption, but this problem was also solved in this release!
- added an abstraction level to iteration rasters. There are currently two implementations available: single and double precision. Double precision was the previously used, but single precision needs less memory and leads to the same results in many cases, so its the new default. But you can change this in the preferences, of course
- the thumbnails can now be loaded into the main area also by single right click with the mouse (as suggested by Don Town)
- new "gdoffs" variaton by Xyrus02 (as also suggested by Don  )
- improved the quality of the realtime preview
- first complete working version of the dancing flames module!
- its now possible to have a "dancing fractal" without sound (i. e. static motion)
- improved the precision in calculating relative weights
- start and end time for motions of the dancing flames editor
- new "Sawtooth" motion for the dancing flames editor
- reduced the default gamma threshold from 0.04 to 0.01 (which should cause gently more brigh results)
- load/save projects in the dancing flame module
- random flame generator: create sorted gradients sorted by hue at a certain probability
- FIXED: vibrancy and contrast where not (re)stored using *flame-files correctly
- FIXED: the use of custom_wf variation did cause the editor to stop (because the example code could not be compiled anymore (which was an cause of all those changes to MathLib))
- FIXED: some params were not read correctly in the circlecrop family of variations
- FIXED: bug regarding blur shading (also already fixed in V0.64 revision 2)

You can download the new version at the projects web page: http://www.andreas-maschke.com/?page_id=351

Best regards and have fun :-)

Java is pretty much a problem for me;)

But considering different random number generators in previous version, there are some articles claiming, that in certain aplications quasi-random numbers are superiour over random. They have much more uniform distribution, thus aproaching final result number of times faster. Not shure, but maybe they could be usefull with flames. In the thread up from last post in the page:
http://www.fractalforums.com/releases/mandelbuld-3d-v1-8-6-beta-test/msg58046/

Halton sequence is not random, it's quind of determined sequence like RNG, and having the most equal distribution possible.