Apophysis verses Ultrafractal
posted by Keith at 3:07 PMIn my world there are only 2 fractal programs: Apo and UF. I know that that are many other programs out there with many faithful users of those programs, but I don't care. Xenodream is about the only other program that has gained enough of my attention to maybe give it a try, but I don't want to go though another learning curve, so there are only 2.
I learned to use Apophysis 1, which was designed by Mark Townsend to be a front end flame finder for Ultrafractal. As far as I am concerned, Apo has always been a front end flame finder for UF and it always will be. I have never had much use for it as a standalone program.
With that in mind, the controversy of which program is better is irrelevant in my mind because they are tools that are to be used together. It like saying which is the better tool between a mouse and a keyboard, or which are the better keys on a piano, the black ones or the white ones.
Apophysis flames inside of Ultrafractal open up a world of creative opportunity. Instead of working with just one flame, many flames can be colored and combined to create a composition.
The trouble is that Apo and UF no longer work well together. When Mark turned over the program to the "Apophysis development team", the team was less concerned about UF compatibility and more concerned about improving Apo functionality. That's understandable. As Apo progressed, the UF formula writers needed to update their formulas to keep up with the changes in Apo, and they did for a while.
The people who use Apo and UF the way that I do are beggars in this scenario, not givers. The flame formulas in UF are way over my head so I have to depend on others to keep them compatible with Apo. We have to depend on the Apo developers to care about UF compatibility enough to ensure that the UF formulas can be updated with minimal impact. We have to ask to keep them working together, and in the past we have, but I haven't heard anyone say anything about it for a few years.
Don't get me wrong. I am not complaining. I am a beggar so I have to take what I am given and keep my mouth shut. I am grateful for the efforts that have been put into both programs.
However, I am saddened by the loss of creative opportunity that occurs when these programs stop working together.
For me, the ultimate version of Apophysis would be one that is specifically designed to be compatible with UF. The ultimate Apophysis development team would see the value of UF compatibility and release updates concurrently with corresponding UF formula updates.
One can dream...
6 Comments:
It would be really nice if UF could use the same variation dll files that Apophysis uses. Maybe it isn't feasible, but it would be nice.
Michael,
UF doesn't need to use the same variation DLL files, it just needs the variations coded into the UF formula. That really isn't that hard for those who understand the UF flame formula code, but they would need the source for the plugin. That source should be available anyway according to the GPL license that the flame3 and Apophysis code is released under.
What is needed, is for the Apophysis developers to make an effort to facilitate a working relationship with someone to help keep the UF formula version up-to-date with the current Apophysis version. This doesn't appear to be happening.
A final release of Apophysis, instead of the endless, expiring beta versions would go a long way to make this happen. It's very difficult to hit a constantly moving target.
Michael, Ken,
It's good to hear from you.
There are a zillion different versons of Apophysis floating around. That's just the nature of it and I wouldn't expect that to change.
My thought is to add one more version that would be specific for use with UF. The developers for this version would include a UF formula writer. The releases of the UF formula and the new version of apo would be tested together and coordinated so that the artists could hit the ground running.
Again, I am not complaining, I am more fantasizing
Thanks
The reason for dll files is to reduce the number of different versions of apophysis. I don't know much about UF, and how flames are implemented in them, so using the dll could be ridiculous.
As for the GPL of the dlls, AFAIK, since they do not use any of the code from apophysis source files, they are separate, and can be kept closed source. Using the template that Joel created for our plugin project does force the GPL though. Legally if a plugin is distributed that uses that code, they must provide the full code as well.
This is the main reason why I no longer make Apo/UF compositions. Or at least haven't lately. You have to, many times, go back to the flame file and re-export it to UF using the more up-to-date (or sometimes an OLDER version) apo.ucl. A real pain to recreate an older image for rendering sometimes.
Using UF to compose works with multiple flames and backgrounds is orders of magnitude easier - and hence more conducive to "creativity" - than rendering a bunch and then scaling/skewing/positioning them all in Photoshop or PSP. Doable but a LOT of extra work.
I suppose the problem - if one sees it as such - is that very few of us have gone the route of making compos with flames. There's just not a lot of demand for it and none of us few who play around with that type of image has the software knowledge to implement the new variations/dll's. Though if more tried it, I'm sure they'd be hooked bigtime.
Rick
UF can't use Apo DLLs because these two programs have a fundamentally different structure for incorporating extra rendering code.
To create a new Apo variation you have to write a DLL, using a "real" programming language, that has a particular set of functions that Apo can call. This mini-program then has to be compiled into native x86 code and distributed as an executable file. Whoever receives the DLL cannot easily look at it and determine how it works, unless the source code accompanies it. Also, because the DLLs are real, executable code, they can be heavily optimized (so they run fast) but also might do anything at all to your computer (besides just rendering flames).
UF formulas, on the other hand, always distributes formulas in source code form, and does the compilation internally. It produces the x86 code the moment you need to actually render the image, and the source code is therefore always available to inspection. In some cases it may not be as fast as code compiled in other languages, but it can't do anything except render formulas, and UF's compiler does do a lot of optimization so it's still very fast (just not perhaps the fastest). But you don't get your choice of languages, either; you have to use UF's formula language. So no C++ or Delphi.
Also, with UF4 you have to use a "monolithic" formula. That is, one single flame rendering formula has to have all the variations you're using coded into it; there's no way to splice in different variations.
Originally all of Apo's variations were hard-coded into the program (because they were defined as part of the flame fractal algorithm) so it was easy to make a UF formula that supported all the variations. Apo users wanted more variations, so several different modified versions of Apo popped up that had different variations coded in. This of course led to mass confusion! The move to DLLs that could be used with different versions of Apo, and written and supported by developers other than the core Apo team, was a thoroughly reasonable idea and an approach many other programs have used.
One other note: "compatibility" between Apo and UF is actually a two-part problem. One is writing the UF formula that supports all the rendering features of the Apo code--essentially, a rewrite of the Apo rendering engine in UF's own formula language. The other part is the conversion of flame parameters (which are XML) into UF's own parameter format. While the renderer must be written in UF's language, there is no requirement that the conversion be part of either Apo or UF; it can be a stand-alone program that reads the XML and spits out UF parameters.
--Damien
Post a Comment
<< Home