- Stable multithreading for single-, dual-, quad-, hexa- and octa-core systems
- Render your flame files as if they were a set of keyframes (like with Apophymator) - even with different amounts of transforms per flame
- Make use of automatic plugin downloading (and the massive heap of new built-in variations)
- Experience faster rendering through optimization of the rendering core
This build features a set of variations which were built-in from existing plugins (to reduce the need of .DLL plugins):
- log (derived from *zy0rg's logn plugin; includes the "base" variable)
- polar2
- cross
- wedge
- epispiral (derived from *cyberxaos' Epispiral plugin; corrected name to be all-lowercase as defined by the naming convention)
- bwraps (derived from bwraps2; removed the "2" in the name)
- blur_circle
- blur_zoom
- blur_pixelize
- splits
- elliptic
- pre_spherical
- pre_sinusoidal
- pre_disc
- pre_bwraps (see notes for bwraps)
- post_curl (added variable "c3" for 3D curling)
- post_bwraps (see notes for bwraps)
Of course, the Delphi source (for "aporender.dll") is open
The "common artist" may not find much use in this but if you are into animating and know how to operate flam3's (and flam4's) console interface, you should definetely check it out!
The core level is Apophysis 7X 15C. All the new things will come in the GUI too. Speaking of the built-in variations, the better multithreading and so on
UPDATE: A new built has been uploaded which allows the user to specify a custom plugin repository to use within the console renderer. Suggestion by ~morphapoph; more info in the README!
UPDATE 2: Okay. Fine. Here is the motherfucking .NET source [link] ; I hope you find amazing use for it! I don't know what keeps me from taking this tool offline (because it is an outrageous violation of the GPL, I've been told) but it might be my belief that it is actually useful for somebody anyway.









Please make sure you add it to your favourites to get even more exposure!
I'm getting successful results now - WOOT!
I'm rendering a set of animation flames from pre-generated parameters produced by Apophymator. I'll be back with some idea about performance in a while. I'm sure the set will render much faster than with Apo proper.
I'm not happy about this gpl controversy over legalities.
You are the only developer keeping Apo going at the moment.
Without you, Apo would probably have turned into "abandonware" some time ago.
I can see that you are in weird predicament.
I respect your decision not to release future Apo utilities.
With the exception of one person, that "official" group of Apo developers lost most of my respect some years ago. There have been rumors about a new "official" Apo for about 3 years. When I asked the "official" plugin developers to include support for reals in some of their plugins they essentially said to me: "do it yourself".
I cannot recall any Apo requests I've made or bugs I've mentioned that you haven't responded to. Sometimes there's been no fix possible. But you at least investigate and let me know.
I'm sure you've responded to about two dozen requests I've made. That's about 20 more than the old devs responded to, and some of what you fixed I asked them to address years earlier.
Joel said:
"Many people, myself included, have licensed their code under the GPL so their code, and new software that others write, will stay open and free for all."
Yeah... but so what if only one person in the world continues to develop that gpl code? The original copyright holders aren't doing anything for the Apo public.
Joel also said:
"People use the GPL to encourage sharing, not discourage it."
Making legal threats is a very poor way to encourage anything. The notion that Apo code will some day become popular with programmers anxious to improve and expand it is deluded.
If that were going to happen, certainly it would have happened by now. You yourself seem to have totally lost interest, except for interest in your ownership of very small parts of Apo.
...No one needs say how important your work is to current Apo users George. But that's what I've done anyway.
If others with legal considerations had any respect for the Apo community I would think they would offer to release certain projects of yours from some of the gpl requirements they may have control over - if that's possible, I don't know.
It's as you said earlier, the bulk of the Apo code remains available.
There's plenty there for any aspiring Apo coder to work with.
My last word here is that I feel something very "unfree" and contrary to the "spirit" of gpl in this situation.
I guess you need to do this from your prompt.
I dont get the commando "Create 30 frames between flames" . If i want an animation. do i need to save what in the .flame?
to be more exibitly. i have a cylinder splits in a cylinder splits. i want one splits to turn clockwise the other counterclockwise.
can you tell me what i should do?
Now go to the command line, CD to the apo7xc-folder, enter:
apo7xc.exe -i "path\to\the\flame.file" -o "path\to\the\result\folder\_.png" --interpolate 30
I hope it works ^^
If a library is released under the GPL (not the LGPL), does that mean that any software which uses it has to be under the GPL or a GPL-compatible license?
Yes, because the software as it is actually run includes the library.
Technically, the .NET-wrapper could also use another library which exports the same interface. So in fact, it's a solitary product which does not include any Apophysis code or any code for executing the fractal flame algorithm. aporender.dll is Apophysis in a dynamic link library. Apo7xc.exe is a CUI for the interface Apophysis uses to export its functionalities.
The plugins are used by aporender.dll and (at no time) by apo7xc.exe or isis.dll; isis.dll reads an XML-file and does - at no point - even attempt to load a plugin into memory.
If I would not use a DLL for the renderer but a shared library (.lib), it would look completely different...