quadrium progress log

Having survived another WWDC, the future of quadrium's writing is on the wall - and it's called "Snow Leopard", or more specifically, "OpenCL".

OpenCL promises to take the quadrium family to new heights of power and speed, allowing for some amazing rendering capabilities. And it almost seems like it was designed for quadrium - it should be able to drop in cleanly, replacing the lower rendering layer in a nice modular fashion. It's way too early to guess how much faster this will work (not to mention it will depend on what video card you have installed in your machine) but one could easily imagine get a magnitude of speed improvement.

Unfortunately, OpenCL will require Snow Leopard, but I hope to continue support for the current major versions of the quadrium family to make sure that Leopard users aren't completely left out in the cold (and in a perfect world, the rendering layer would be abstracted into two version - one based on OpenCL, one based on the current technologies, which would then give you the best of both world). Also, Snow Leopard won't be out for another year or so, so don't expect this in the next couple of months...

So the plan for the future is to first ship quadrium | flame 2.0, and then work on the OpenCL versions of all three quadrium applications. The only bad news is that, like it did to Leopard last year, the iPhone is causing a schedule impact (so no, I haven't forgotten about quadrium | flame's update, it's just that the release of the iPhone SDK has gotten in the way).

The rest of the last major feature for quadrium | flame 2.0 is working - the ability to create custom seeds (which are solid 2D and 3D shapes used to add "seed" shapes to the image) and effects (which modify the seeds, including both simple warping and other coloring and shading results).

So the result of this is some absolutely amazing images that have never been approachable by traditional flame fractal rendering techniques...

The first step for the last major feature for quadrium | flame 2.0 is now working. You can now write custom topologies using quadriumScript!

This opens up a whole world of possibilites for the hardcore flame tinkerers, since you'll be able to create your own topologies. And since it's all done via quadriumScript, you won't need to have any special tools installed, nor learn about compilers and the like. What's more is that the quadriumScript architecture lends itself to being able to change things "on the fly" - if it doesn't work like you expect, keep changing it until it does (no need to edit, quit, compile, link, copy the results, relaunch, reopen the test file).

And the infrastructure that quadrium | prime laid down for being able to share quadriumScript objects will be brought into flame as well, so even if you don't want to figure out how to make new topologies, you can easily take advantage of the work of those that do...

quadrium | flame 2.0b1 has been released to testers - it's still missing one major feature, but there's a whole raft of other major features, improvements, and refinements:

• Rendering supports multiple cores/cpus, making it much faster (assuming you've got at least a core duo machine)
  
• Completely revamped 3D controls & editing - the "rotation" mode will use a virtual trackball to allow you to spin the image in 3D (assuming you're using 3D flames), and the skeleton view includes the ability to have different view points of the transforms, as well as direct manipulation of 3D Affine transforms
  
• Revamp in the "editing flame properties" UI - it is now split into three subpanes for color, style, and effects
  
• Images - a flame can now have an image instead of just a color (with a boat load of options controlling if the image is tiled, scaled, where the coordinates come from, etc...).
  
• "Seeds" - a new kind of flame style that is used to generate "solid shapes". Previously, if you wanted a solid looking blob, you'd set the topology to be blur and adjust the blur. Seeds work _much_ better than that, and include both 2D and 3D variations. Besides the basic seed information, there can be a list of "effects" that can be added to the seed, to alter how the coloring works, as well as various warping and other effects on the shape that the seed generates. (and yes, both the seed parameters and seed effect parameters are work with breeding/mutation/tweening)
  
• Two new color modes - an alternate HDR style mode (a bit faster, doesn't "ghost up" quite as much), and a "solid" mode designed specifically for 3D shapes (includes a Phong reflection model of ambient, diffuse and specular lighting, as well as shadows).
  

Still to come is the ability to create custom topologies using quadriumScript (and maybe even custom seeds and seed effects)

And in mixed news, a flu-bug that is going around has curtailed the cutting edge development, so in the mean time I've had enough energy to be able to clean up a few experimental features that I've wanted to include - as a result, all quadrium products will include two new color pickers - one that helps you to pick color harmonies, and another that models a Photoshop style color picker. Proof of how sick I am is that I'm enjoying working on color pickers...

In a move I'm sure I'll regret having forgotten some minor (but critical) issue, I'm setting quadrium | prime loose on the world as of today!

For a limited time, it's only $39.95 (that's $20 off the regular price), and registered quadrium2 users can save an extra $10! So get your copy now...

(And don't be too surprised if a 1.0a isn't released within a matter of days/week)

The first release candidate of quadrium | prime is going out to testers, so it could be released as early as next week!

I've still got some documentation to update (one tutorial), tweak (to use "final" screenshots) and polish (table of contents, etc...) but that should be done this week. The only major other thing is to package together quadrium_scribe as a stand-alone download (since it is used by both quadrium2 and quadrium | prime, as well as tentatively the next version of quadrium | flame, no point in downloading it three times) and update the quadriumScript references.

This, of course, assumes that no major problems are found in RC1...

New year is as good as any time to start mapping out the year ahead for the quadrium family, so here's the rough details:

• Ship quadrium | prime - there are probably two more beta tests versions to go, and the documentation is about 2/3rds done (still need to update the quadriumScript reference from what is supported for q2, as well as online help and some reference material)
  
• quadrium | flame update, adding some major new capabilities hinted at previously, as well as the ability to use more than one cpu/core while rendering (which should really help rendering times for large documents on multicore machines). I hope to add the ability to write custom topologies using quadriumScript in this release as well
  
• quadrium2 update to add support for creating UI via quadriumScript (so your custom nodes aren't limited to the handful of sliders, colorwells, etc... - rather you can define what you need in quadriumScript and the UI will be generated to match). I'm also hoping to add the ability to embed quadrium | prime and quadrium | flame documents inside, allowing you to, for example, create a flame image and use the "frame" node to make a mat and frame on it. At this point, I'm thinking of renaming q2 to more reflect its "core" nature (and help make the naming system cleaner)
  
• UI enhancements, such as a single window/full screen are a possibility. At the very least, a bunch of "behind the scenes" work will be going on to make sure that all members of the quadrium family have similar features.
  
• Movie making enhancements are also planned, though these are not tied to any one specific product (but hopefully with the ui work mentioned previously, will be seamlessly rolled out in all of them)
  
• 64 bit support - I've got a preliminary version of flame that runs under 64 bit, but there are some third party libraries that I've got dependancies on that will prevent me from shipping this feature until they are supported (plus I need to update quadriumScript to generate 64 bit code, which is a big task).
  
• Other quadrium and quadrium related products. These may include something which works quadium style magic with vector graphics, and something I'm referring to as "unnatural media". I've also want to make a simple celtic knotwork editor (ever since adding the celtic node to quadrium I've wanted to be able to use specific patterns, and not just random ones), so "celtium" might make an appearance (and an update to be able to read these files in a node in quadrium).
  

And if that's not enough to keep me busy for the year, I've got some other ideas as well...

More documentation has been written over the holiday (all but one section of the first draft of the user's guide is done, though some of the screenshots and appendices still need work), fifty-eight starting points created, and a bunch of bugs have been fixed and other things enhanced.

Besides the previously mentioned asynchronous mutations, breeding is also asynchronous, so it won't block the UI while creating breeding. This feature will also be available in the next updates of flame and quadrium2 (and more on these later).

Needing a break from writing documentation for prime, I've started experimenting with some new features for flame, and the results are absolutely amazing.

I'm not going to tell you what all of them are yet, but here's a tiny teaser:
1) Seeds - the ability to easily introduce "shapes" into the image
2) New coloring "texturizing" capabilities - see for a little example
3) Something even bigger and more powerful than either of these two

I had planned to have the next quadrium | flame release to feature being able to write your own topologies in quadriumScript, but these other features are pretty darn cool...

Threaded (asynchronous) mutations. Not as much of a problem in q2, but in flame and prime, sometimes it takes a while to find a decent mutation, which can really bog things down if you accidently switch to the mutations tab when you didn't mean to.

Not any longer - it will work (in the background) to generate them, and the best part is that they will "fly out" when ready. So if the image is easy, they all fan out pretty much like they do now, but if it takes more work, it's almost like it is dealing cards. Talk about cool...

Finally got the latest prime release out to testers - still a lot of documentation to write, and some bugs to fix (and some icons to "de-uglify") but I'm quite happy with the way this is turning out...

Sometimes it's amazing how much work writing all the documentation is, but then I did a quick calculation of how many different objects there are that you can play with in quadrium | prime.

Over 350.

Granted, most of these are much smaller/light weight objects than quadrium2 nodes are (for example, something that calculates a shape is an object, and each different shape is a different object), but this still means that there are more objects in the first release of prime than the current version of q2.

Still, between this (or, more accurately, when documentation burnout happens) there have been a lot of little bug fixes, UI refinements and performance tweaks on prime. The next beta is going to be a very major milestone.

In the mean time I still have a few loose ends to tie up for minor (Leopard enhanced) updates of both flame and q2, plus a calendar to get out, so it's been a busy time...

Got over twenty pages of reference manual (and only about a third done with it), but equally important is that prime will have a built in documentation browser for examining the quadriumScript object (part of the whole "Scriptorium" window for managing extra script files). The neat part about this, however, is that the documentation is derived from the source code itself (I've made some additions to quadriumScript to greatly extend the various documentation tags).

The net result is a nice set of pages for all the different objects and protocols, which should definitely help when people want to start writing their own objects... (and since that part of the documentation browser is built from a web view, I'll ultimately be able to tie it into an online repository of third party quadriumScript objects)

While it's not a hard freeze, there should hopefully be no more major features added to quadrium | prime (there's a couple of minor things that still need to be worked out involving things like only automatic document, but those are partially implemented already - they just need some refining).

Being feature complete is a major milestone for quadrium | prime, and so documentation writing can proceed at full speed!

(And this will be on the next versions of all quadrium products)

You know how you're working on something, and you decide it would look better landscape instead of portrait? So you switch to the info tab, copy and paste (or just type) new values for width and height, and then rotate the image 90 degrees (which can be tricky if it already is partially rotated) and then you notice that you might need to zoom in or out (since it tries to key the width consistent).

Or you almost always want to produce something that is 6" x 8" at 150 dpi (which is what most of my deviantArt images are created at) so you've got to play the "6 tab tab 8 tab click-drag-150-release" game. Or you're making a calendar that requires 300 dpi at 10" x 12", and you're going through older work and resizing them to this specific size?

Well, I finally implemented the "Presets" menu in the info panel, which includes the ability to rotate the image (and canvas) 90 degrees clockwise or counter clockwise, and lets you save specific presets that you can then quickly recall from the menu...

(What can I say, was getting bogged down into the details about undo vs notifications vs redrawing vs UI vs AppleScript where sometimes the changes wouldn't be shown, and other times the changes would be shown repeatedly, bogging things down to be unusable and needed to actually make some progress)

There is still more work to go, but initial AppleScriptability of quadrium | prime is working. Besides the standard behavior that all quadrium products have, you can now do thing like manipulate the objects and sliders of object. For example, you can change the transformation of a given image to be an affine transform that corresponds exactly with what the current zoom/pan/rotation of the view has (which doesn't seem all that useful, but actually is, since some of the "special effects" assumes that the view is set to the default home view).

More importantly, it was one of the major, non-documentation related, features that hadn't been tackled yet (which is not the same as saying everything else is done, rather everything else has at least been started)

Just like flame has that little odometer setting for setting up a bunch of coefficients, you can access the same thing in prime. For example, here's a bilinear transform that can have those values shared with flame:

class BilinearTransform
name "Bilinear Transform";
parameter pCoef : real[8] ('ax','ay','bx','by','cx','cy','dx','dy')
name "Coefficients";
end;
method transform(x: real, y:real) : complex
local c0 = (x,y);
return (c0 * (pCoef[0],pCoef[1]) + (pCoef[2],pCoef[3])) / (c0 * (pCoef[4],pCoef[5]) + (pCoef[6],pCoef[7])) ;
end;
end;


Besides having upgraded the main development to Leopard (since that's really the only way to add Leopard specific features - which to this point are purely cosmetic but nice none the less), "curve" as a data type has also been added to quadrium | prime.

This works like a cross between a gradient and an image - it uses the curve editing that quadrium2 has, and you can easily declare and work with the curve data just like gradients and images. This allows you to create things that can adjust arbitrary color curves easily, for example, or more interesting things (such as the "translucency profile" of a trap - I'm planning on exploring fractals that uses a curve as part of its basic formula).

Besides gradients (and "numeric" types like reals, complex, quaternions, points, etc...) quadrium | prime now supports "image" as a data type, which will work much like a gradient does. The gradient allows you to take a single coordinate and get back a color - image allows you to take two coordinates and get a color, but instead of taking a ramp (or series of ramps) of colors, image will let you select your favorite photo or image.

This will allow you to wrap images onto various shapes, including traps within a fractal, as shown in the example this entry is linked to. This also means that one will be able to use quadrium | prime to do things like really funky image manipulations...

Betas for both quadrium2 and quadrium | flame are now available from their respective download pages - these are designed to address issues with Leopard, though should work on 10.4 (and haven't been tested against 10.3.9). Both do include the new gradient editor which greatly increases its capability, as well as a number of minor enhancements and bug fixes.

More performance improvements, this time while doing things like making mutations and movies - the speed up is significant. It's not that amazing, it's more a matter that the original approach was "get it to work", and now it's "get it to work faster".

Though while rendering movies I've had time to track down and fix a couple of Leopard specific bugs in the code base...

What this means is that while flame is currently Leopard happy, quadrium 2 was not. As a result, there will be public betas available tomorrow for Leopard users to address these issues, as well as several others (that crash when going through the history arrows, for example), plus the super new gradient editor. They will, however, still be beta - more testing will need to be done (especially on q2, since the quadriumScript work for prime has some potentially serious impact on the quadriumScript support in q2 - fortunately flame doesn't support quadriumScript customized topologies or flames yet...)

Just finished the most important feature that hopefully nobody every uses - the "what happens if you open a file that uses some object that the user has renamed or doesn't have the source for". Up until a couple of days ago, it would crash. Up until yesterday, it would bring up a nice dialog saying that it couldn't find the definition for some objects - much nicer (and reasonable for the case of not having the source code for that object installed on your machine), but not good enough.

I finished handling the "what if we just renamed the object in the code" - it now looks through the document (including all the snapshots), find all the missing objects, and gives you a dialog allowing you to select what to replace them with, which will then repair the results. I can finally open some of the documents I made in earlier version (such as the "Deep One Autopsy" where I had renamed a bunch of things)

Still working on some of the details, but I've got application startup significantly sped up (previously, all the system defined objects needed to be compiled, I now cache the resulting parse tree so it can quickly load all that information), and I'm working on improving some runtime performance as well - it is still possible to come up with some insanely complicated images that just bog down while working with them. It'll take some more work, but the results will be worth it.

I've turned on support for quaternion parameters (as well as 2D, 3D and 4D point parameters), and little experimentation with quaternion based fractals. Since I currently just do "2D plane" style graphics, it will only take a 2D slice through 4D space, but the results are still interesting and fun to play with.

Thanks to the "adapter" architecture I was able to define a protocol for quaternion based fractals, and then an adapter from those quaternion fractals to (regular complex) fractals, allowing me to try out a quaternion Mandelbrot set using all the same coloring algorithms available for other fractals (as well as all rendering algorithms that work with complex fractals).

I've made the first couple of step on getting the quadrium | prime website working - there's a basic page and a secondary page with a quick look at the basic architecture of quadrium | prime. I'm planning on some more screenshots, a simple walkthrough, and some introduction to creating new objects with quadriumScript.

I can honestly say this is the least fun part (much rather be creating art, adding features, or even fixing bugs), but obviously it needs to be done...

A new version of quadrium | prime has been released to testers, this version including integration with quadrium_scribe for editing quadriumScripts (allowing you to easily select a quadriumScript in prime, edit it in scribe, check the syntax, and then have prime reload the results - even re-rendering documents to use the new code).

The goal for the rest of the week (beside actually using the thing to create some new images for my gallery) is to try to get a "sneak peek" website up and going.

By using the ability to edit and dynamically reload those scripts (without having to quit, rebuild, relaunch, re-create/load image) I've been making good progress on the various "preset" objects that will be included with quadrium | prime - there's some very powerful fractal coloring techniques (with a high degrees of expandability) that will be part of quadrium | prime. And with the ability to create new objects that interact with all the existing ones, the ability to add new image techniques even after shipping simply amazing.

I've also been finishing up small UI/feature "corners", such as being able to lock parameters (which is important for doing mutations effectively), and cleaned up a bunch of program architectural design issues. Another beta should be going to the testers this week...

Big tasks remaining are some internal reorganization that will (hopefully) drastically improve responsiveness for things like generating previews, documentation and website work - a preview of which will appear in the next week or two (complete with some screenshots and walkthroughs).

Finally got support into quadrium | prime to not be limited to just the preset scripts included with the application, but anything that is in the appropriate folder (and if you try to open an existing quadriumScript file from somewhere else, it will automatically copy there for you). That was the easy part.

The cool part is that it automatically detects that you've made changes, and will reload the new changes and recompile & redisplay all the open documents that use that file. Part of the trick is that quadriumScript supports "namespaces" allowing you to separate stuff you made from system built in stuff or stuff you've gotten from somebody else. And yes, I plan to include a web based "contributed script database" that you can submit and search and then automatically download to your local drive (with both a stand-alone web page, as well as integrated into the quadrium | prime "Librarian").

I've also found some bugs, and made some serious performance improvements in the UI...

The first 1.0a1 version of prime has been released to testers, which has to count as a major milestone of some sort!

Managed to implement all the major features that I've needed for a beta (just finished allowing reordering of lists of things via drag & drop), so there's only a couple minor features to add (and maybe even some documentation to write) before I unleash it on the testers.

This of course assumes I don't find something major on this end, so who knows what I'll remember once I've had my afternoon coffee!

Prime is really coming along nicely - I've got it using multiple cores to speed up rendering, and I just added the ability to specify a "parameter" that is a formula that the user can type in (not just limited to a list of common simple formulas like sin, tan, log, etc... - not even limited to a single variable in the formula).

For example, the following is everything that one needs to define a fractal that the user types in the formula (as well as a "seed" value and the ability to display either the standard Mandelbrot style fractal or the Julia set - in reality it is even smaller than this because most of this behavior is encapsulated into an abstract superclass that UserFormulaFractal can inherit from, so only the pFormula declaration and loopPoint method need to be defined):


class UserFormulaFractal
name "User Formula";
local fZ : complex;
local fC : complex;
parameter pSeed : complex
name "Seed";
default (0.0, 0.0);
end;
parameter pJulia : boolean
name "Julia Set";
end;
method initPoint(anX: real, anY: real)
if pJulia then
fZ = (anX, anY);
fC = pSeed;
else
fC = (anX, anY);
fZ = pSeed;
end;
end;
parameter pFormula(x: complex, c:complex) : complex
name "Formula";
default x * x + c, (x + c) / (x - c), sin(x) + c, c * exp(x);
end;
method loopPoint() : complex
fZ = pFormula(fZ, fC);
return fZ;
end;
method bailoutPoint() : complex
return fZ;
end;
method bailout() : bool
return false;
end;
end;


I still need some minor UI enhancements (the ability to rearrange a list of objects) and it'll be time for the testers to start breaking things...

After about 4-5 hours of work, quadrium | prime now supports the standard quadrium features of breeding, mutation, and tweening (which in turn forms the basis for movie making), a major milestone making prime one step closer to its first beta test level.

Still to go are a couple of annoying bugs, some UI improvements, a few more features, a whole lot of cleanup and consistency in the provided scripts, and the ability to allow for end users to create and use their own scripts to extend prime (right now, it just looks for scripts bundled with the app itself). It is important to remember that quadrium | prime's entire image making capability is based entirely on these scripts (i.e., there are no "special built ins"), so anything that can be generated can be completely changed to code the user provides, so being able to manage these things is both a complex and important thing to get right.

Since all sorts of subtle problems arise, this needs to carefully approached - what if an image requires a script the user doesn't currently have "installed" on the machine? Can scripts be saved with the image itself, or are they separate (i.e., "reusable libraries")? Are they saved as raw source code or "compiled" parse trees? What if the image requires a different version of the script than the user has installed?

There's many things that can get annoying about developing software, but here's another to add to the list - changing file formats/internal architecture.

As I work with prime more, I start refining, expanding, or flat out changing the way various parts work. While this add flexibility, cleans up design, or adds important features, there's one major drawback....

The other day, I created an image I rather liked:


(You can find the full sized image here)

The problem is, after making a few changes, I can't actually open the file anymore (at best I get a solid blue image).

Fortunately, I can dump the various parameters when the file is read in, and then manually reconstruct a new image with similar settings, but still, it's annoying...

So I've been working with and on quadrium | prime for a bit now, and it's definitely an interesting beast. Some of the simplest things to do in quadrium2 are all but impossible, while things that would be nearly unthinkable in quadrium2 are just a few mouse clicks away, so from that point of view, it definitely complement the quadrium family.

Right now,however, it feels like you've been given a big box filled with lego blocks, tinkertoys, and erector set pieces (and a few odd lincoln logs thrown in to boot), and it's really easy to connect together the individual components, making a simple little house or car or something, but using all the pieces gets a lot trickier since the tinkertoys don't snap onto the lego blocks (you'll have to pardon the "american childhood toy" metaphor).

So I'm in the middle of changing things to dynamically reconfigure themselves to allow the tinkertoys to snap onto the lego blocks. The results should certainly be interesting...

(For those looking for a more technical description, different rendering techniques are implemented in different mutually-exclusive classes, and I'm adding a series of mixins that dynamically form an adapter to allow a class to adopt an interface from the other class).

Unfortunately, at some point I broke something so I can't actually render images right now to show you the results (all it does is make the entire image one solid color).

After lots of hard work, I can finally announce the existence of the newest member of the quadrium family: "quadrium | prime".

This application takes the power of quadrium script (used to customize and extend quadrium2 nodes) and uses it to make an entire image. Basically, you put together quadrium script objects via a hierarchical series of controls, and prime puts together the objects to form an entire "program" that generates the image. And not only is it immensely flexible, but you'll be able to write your own objects and extend it with your own ideas and algorithms.

Of course, it will have all the quadrium style features you expect - live feedback as you change the parameters, breeding, mutations, creating movies, high resolution rendering, that new gradient editor previously mentioned, etc..

You're probably asking how it compares with quadrium2? Well, it is a bit more "left brain" oriented than quadrium2 is (but not overwhelmingly so), and will have more of a focus on fractal images than quadrium2 (but just like you can do fractals with quadrium2 besides all the other things, you'll be able to do other things besides fractals in quadrium | prime). In theory both should be able to produce the same image, but there will be many image styles that are easier in one or the other.

I'm not announcing any timeline yet for it (hey, I just got it to save and open saved documents today), but I'm expecting sometime this fall - check back here for future updates. It will require 10.4 (sorry for those 10.3.9 hold outs) and is Leopard compatible.

Major changes are coming to the gradient editor (found in both quadrium2 and quadrium | flame), including support for selecting ranges of the gradient and then doing all sorts of operations on it (over a dozen). These include changing individual color components, hue, saturation, brightness, warmth, adding noise, altering the distributions of the points, etc.. and also include arbitrary blending of another color with the selected portion of the gradient (using any of the blending modes).

But wait, there's more - you can move around and resize chunks of the gradient, and use drag and drop to insert another gradient (from the favorites) into an existing gradient. Want to make a gradient that is composed of two gradients put together? Super easy now. It's a whole ton of new functionality and usability improvements coming to the next updates for quadrium2 and quadrium | flame.

quadrium | flame 1.2 is now available for downloading!

This version includes performance improvements, richer rendering algorithms, extensive UI enhancements, more flames and topologies, and scripts to make it easier to create "kleinian limit sets" and much more.

This is a free update for registered quadrium | flame owners, so grab it now

The first release candidate for flame has been sent off to the testers - so far, no problems (but in the back of my mind I _know_ I'm forgetting some feature or something I needed to add/fix to the thing).

Latest (and hopefully close to final) beta for quadrium | flame is out to testers - I finally managed to stop adding features long enough to finish updating the documentation. It's definitely got some nice features, as anybody who's seen my "Kleinian Limit" images on deviantArt

So there are two more major features added to the next flame release.

The first is that it is now easier to edit the transformations in the "skeleton" view, including the ability to change from the "F" tokens (which show the most information since they have no symmetry groups that would confuse you about rotations and flips) to an "L" or "r" (which is common in some geometry books), or a triangle (which some people seem more comfortable with, though the fact that a given triangle doesn't visually discern between six possible transformations, well...)

The other is something cool that I've been playing with that involves "L-Systems", which, among other things, can easily transform a boring image into something with unusually, almost 3-D, grid-like appearance, or make it look like leaves on a tree, etc...

Now that WWDC has come and gone, and Leopard is getting closer, time to lay down a few plans on the future of the quadrium family. First, an update for flame should finally be pushed out, and the after Leopard ships, an update to both q2 and flame will be released. It'll be a fairly minor update (with some improvements in the movie editor) as well as any Leopard specific problems. Down the line there will be 64 bit versions of both released (flame because it can use the memory, and q2 because it can take advantage of the improved ABI for faster vector performance). And at some point there is also a networked renderer in the works, as well as a new member of the quadrium family "quadrium | prime".

Both quadrium2 and quadrlum | flame allow you to adjust some basic image properties such as gamma, brightness and contrast, which is done via a custom ColorSync profile. This works great if you pull them into applications that support such things (most native OS X apps do). However, if you post your images on the web, there's a good chance that the person browsing it on the other won't see these corrections and will get the unadjusted version.

To solve this problem, you'll now be able to specify if you want the profile embedded (which is great for viewing/working on your Mac only, especially if you want to further edit/print it, since there won't be any loss in data precision), or applied (and then other people on other platforms/browsers will see it correctly).

flame is getting some nice updated behavior - besides the UI enhancements found in quadrium2 and other things documented previously, I've added two new topologies - one "cubical" (which is like "Spherical" only rectangular), and another "Inv Cardoid" which flips things around in various cardoid and lemniscate shapes (giving you flower petals and the like).

Mostly there's been a lot of work on things like drag & drop of parameters, the "odometers" and things like that, as well as some internal improvements (nothing too significant yet).

quadrium2.2 (the release so chock full of features it should be called 3.0) is now available for public consumption!

The second release candidate has gone out to the testers - hopefully this is it!

While waiting for further feedback on the quadrium release candidate (and there will be a second one on Monday), I've added dihedral symmetry to quadrium | flame - it's a lot like what you'd see through a kaleidoscope (a combination of rotation and reflection), and even a single simple affine flame with dihedral symmetry can produce surprisingly complex results...

The first release candidate of quadrium2.2 is now being sent out to the mad testing horde, complete with just shy of 300 pages of documentation...

Finished updating the tutorial to cover the new programmable nodes - from simple textures to three different approaches to how to make fractals like never before. The hard part was coming up with examples that would be interesting and innovative when complete but simple enough to show how to do it without getting too complicated (I don't any of the examples are more than two dozen lines of code, most less than half that). Plus, of course, not something that you can already do without writing any quadriumScript...

So I've been going through various bits of documentation and trying to clean them up and keep them all consistent (for example, the canonical spelling for a single floating point real number data type in quadriumScript use to be "float" but now is "real", so I had to change all "user visible" occurrences from one to the other but not places that weren't that might well break things). Of course, this breaks things, so for a while here I couldn't get anything to work.

But on the bright side, the "quadriumScript reference guide" is now done (and 38 pages), and the "quadrium2 user guide" is updated, and I've got all the parts for the "quadrium2 reference guide" ready and I even was able to polish up the "Node Browser" window to include a special "compact" mode (where the basic controls are now at the top with lots of space for you list of nodes) and I was finally able to kill the "Node Help" window by making tooltips that include images and nice formatting.

Just one of the many ways that we're making the quadrium2 experience better...

The online documentation browser in quadrium_scribe (the editing environment for programmable nodes) has be significantly enhanced - it use to be two separate things (one for intrinsic functions, another for general HTML based help documenting the various programmable nodes), but now is unified and modeled after the XCode documentation browser - you can see all the different handlers, instance variables, intrinsics, etc... all from one quickly searchable place.

The quadriumScript reference guide has been completed, weighing in at around 30 pages (385k). For the super curious (or fans of nice syntax diagram), I've made it publicly available for those reading this...

Lots of minor fixes and tweaks to quadriumScript - support for more complex "elseif" (or "elif" if you prefer) structures, as well as switch statements (in the process, found a bug that |-5| was a floating point value of 5.0 instead of the integer 5).

After all, if I'm bothering to write the documentation on this, might as well make sure that it actually works correctly as documented!

So I just need to finish the "quadriumScript reference guide", write the "quadriumScript tutorial" and then another chapter to the "quadrium2 tutorial" showing how to use scripted nodes and finally the appendices to the "quadrium2 reference guide" showing all the hooks that those nodes provide, and then I think it'll be ready for the next beta release...

I've begun testing a beta for the next version of quadrium | flame as well. It doesn't have anywhere near the level of new features that quadrium2 does, but it does including a whole bunch of compatibility bug fixes (including G3s and 10.3.9), as well as the various usability enhancements found in quadrium2 (including toolbars, drag and drop of values, and a more polishing).


There's also a new flame type (that performs complex polynomials) as well as topology (n-gon). I'd like to add some radically new rendering techniques, but that may have to wait a release...

The next beta is coming along nicely - lots of little bugs fixed, and some nice usability enhancements (for example, you'll now be able to drag and drop values from one node to another). The primary thing that's standing in the way of this beta release is documentation - there's a lot of new stuff to cover, especially with the addition of quadriumScript.