Version 7.00 is here !

Note From Michael

Apologies for being late to add the latest version, could run through many excuses, but the latest is here. That’s all you need to know. Now over to Andreas for the details.

Note from Andreas

What’s new?

• Re-implementation of GPU-rendering (PLEASE NOTE: this works only on Windows and requires a modern NVIDIA graphics card) In Version 6.50 GPU rendering was VERY limited because it used only the internal pre-defined variation set for “classic” flam3-variations. There is also some built-in “3d-standard set” of variations (which never worked for me). But even with this set of variations the usage would be very limited, because mayn of these built-in variations work slightly different or did not work at all. It would always be impossible to get predictable results, which is often very important for artistic work.
  
• So, I re-implemented GPU-rendering in a fundamental way:
  • it is still using FAEngine as GPU-gateway, but most of the GPU-code is actually JWildfire-specific
    
  • most of the actual GPU code is provided by JWildfire during runtime and compiled and executed during FAEngine on the GPU It would be impossible to create a variation set which contains all gpu-supported variations. They would be too many, and compilation at the device would fail or even crash the whole system. Therefore, JWildfire always sends only the code to FAEngine which is actually required. This makes the rendering startup for each flame a little bit slower (and does not allow for a realtime-display), but actually works very good and reliable)
    
  • uses a special binary (FARenderJWF) and and custom kernel which already provides many of JWildfire’s features
    
  • using CUDA instead of OpenCl, so AMD devices are no more supported. I had to choose between supporting more devices or supporting more possible features (and a better developer speed), therefore I switched to CUDA.
    
  • only this gives actual control over the behaviour of variations and allows us to implement features which are not supported naturally by FAEngine
    
  • currently supported features:
    • support for about 550 variations (of a total of 850)
    • motion blur
    • some of the additional color balancing options
    • 3d-affine-transformations (“XY”-, “YZ”-, “ZX”-buttons)
    • weighting fields
    • custom variations
  • currently not supported:
    • layers
    • local gamma effects
    • solid rendering
      
  • supported platform: only Windows10 + CUDA-capable graphics card, e.g. NVIDIA 1060 or better
    
  • Please note, that the GPU renderer is not a replacement for the CPU renderer. It is just an additional toy.
    
    • there will always be features which are not possible on GPU (for example, probably, sub-flames).
    • there will be platforms, where it will be never supported
    • all calculations on GPU are done using single precision, while CPU uses double precision.
      And some mathematical functions on GPU are just approximations in cotrast to the more precise CPU-variants.
      So, likely, there will be differences, often very small, but they will there.
      
  • Please also note: the more features you use, the more code is created, compiled and executed. Especially,
    weighting-fields are very expensive in comparison to other features. At higher resolution the GPU render will always
    be faster. But, it is possible, that a small preview on GPU takes more time than a CPU render. This is due to the complicated process to invoke a GPU render.
    
• added a new GPU-mode-button in the main editor. If enabled, it has the following functions:
  
  • full preview uses GPU rendering
  • random-flame-generators try to avoid to use variations which are not supported by GPU
  • new option tinaGpuModeDefaultEnabled in the Preferences to activate the GPU-mode per default
  • there is an implicit GPU-filter for the list of variations, so when creating new fractals you can select only variations which are supported on GPU
    
• added a new tab in the GPU renderer for viewing the generated gpu-flame-parameters
  
• displaying the name of variations where no code could be found
  
• added a new option to enable automatic synchronization of changes between the Main Editor and GPU renderer
  
• added a “send flame to GPU render”-button in the main editor
  
• added a “Disable Denoiser”-button in the Batch-renderer-window to easily turn off all post-denoising (usually, when using GPU rendering)
  
  • GPU-rendering in Batch-rendering is per default on, when GPU rendering is available
    
  • Disabling of post-denoiser is also per default on, when GPU rendering is available
    
• included LogBack as standard-library for logging error-messages and debug-information (the log-file is saved as JWildfire.log in your home drawer)
  
• added a new global window (“Message log”) for showing the messages of the current session
  
• fixed a bug which occurred when importing a flame into the Easy Movie Maker: when the window was too small for holding the preview, the import failed
  
• omitting empty motion curves when writing flames to file or clipboard
  
• removed support for the old FACLRender (which had no special support for JWF and works very limited together with JWildfire) together with the info-window under Help->GPU rendering (please see the users manual for questions regarding GPU rendering) slightly increased the “diversity” of random flame generators
  
• the AI-Post-Denoiser under GPU rendering is turned off by default
  
• improved the appearance of the WField-tab new white-noise-type for weighting fields (not very spectacular, but interesting some times, though)
  
• added the cell-value-type as possible return-type for cellular noise in weighting fields
  
• added a strength-parameter to Quick mutation (which currently works not very predictable/well)
  
• new option to disable ai-based post-denoisers on GPU renders, but to keep the settings for CPU renders at the same time
  
• fixed a fft-related problem with the import of mp3-files in the motion-curves-editor
  
• improved the “Duckies”-random-flame-generator
  
• new variations:
  
• ovoid by Rob Richards
  
• post_point_crop by Whittaker Courtney
  
• mobius3D_with_inverse by CozyG
  
• hole
  
• post_flatten and pre_flatten
  
• pre_disc
  
• post_rotate_z
  
• oak_leaf
  
• maple_leaf
  
• japanese_maple_leaf
  
• new family of variations by Jesus Sosa: Symmetries band & network groups variations
  
  • Symmetry Band Groups 1 to 7 variations: sym_bg1, sym_bg2, sym_bg3, sym_bg4, sym_bg5, sym_bg6, sym_bg7
    
  • Symmetry Network Group 1 to 17 variations: sym_ng1, sym_ng2, sym_ng3, sym_ng4, sym_ng5, sym_ng6, sym_ng7, sym_ng8, sym_ng9, sym_ng10,sym_ng11, sym_ng12, sym_ng13, sym_ng14, sym_ng15, sym_ng16, sym_ng17.
    
• behaviour of some variations fixed: the contribution of these was not added to the variation current group, but
  was overriding all other contributions of the current group:
  
  • seashell3D
  • clifford_js
  • post_depth
    
• fixed the naming of some parameters (i.e., replaced spaces by underscore) of the following variations:
  
  • atan2_spirals
  • seashell3D
  • inverted_julia variation
  • corners
    
• fixed the following variations in order to correctly support the “Preserve Z”-setting:
  • bsplit
    
• fixed a bad behaviour of the dinis_surface_wf variation
  
• the parameter “filled” of the following variations is now a probability, rather than a switch:
  
  • cannabiscurve_wf
  • cloverleaf_wf
  • rose_wf
    
• changed the initialization behaviour of the w-, x-, y- and z-variation: lituus is initialized to 0 instead to a random number
  
• changed the behaviour of post_axis_symmetry_wf and post_mirror_wf so that it only adds a contribution when the amount-parameter is not equal to zero, for consistency reasons
  
• improved the gnarl-random-flame-generators to also use waves22, waves23, waves4, waves42 and vibration2 to create more interesting variations of the standard-gnarls