Oxidizer 0.9.0

by David BurnettSaturday August 27th, 2011
Posted in Developer's Corner, Oxidizer Blog, Using Oxidizer

Hi folks,
here’s another release for you to try out. There’s no real changes part from it now uses the flam3 3.0 binaries which should give a nice rendering speed boost and I’ve attempted to change the build system to allow Oxidizer to work on Leopard (10.5) in 64bit mode which I broke in the last version, thanks to Ergo for pointing that out..

If this all works I’ll start adding the new flam3 3.0 features into the Official Oxidizer releases rather than that unofficial 1.5 release I knocked up ages ago.

I’ve also decided to officially unsuppport Oxidizer on Tiger, it’s probably been broken for a while anyway. That should allow me
to add a few news bits and pieces, and finally release a version 1.0 :-)


Oxidizer 0.8

by David BurnettSaturday April 23rd, 2011
Posted in Developer's Corner, Oxidizer Blog

Hi All,
I’ve just released Oxidizer 0.8 on sourceforge. It’s Oxidizer with a bright shiny new version number, so no need to download for those using that version other than stroking my ego with the download numbers :-)

Download here

64 Bit Redux

by David BurnettSunday September 26th, 2010
Posted in Developer's Corner, Oxidizer Blog, Oxidizer Community

So, anyone want to try a proper full 64 bit version of Oxidizer ?

Well if you do today is your lucky day, well maybe.
I’ve just uploaded Oxidizer 0.7.5 alpha (bit of a mouthful) and it should be fully 64 bit for those lucky Snow Leopard Users with 64 bit capable Macs.
Of course as always I haven’t got a 64 bit Mac so it might not work at all for all I know. It’s a universal app so we 32 bit users can join in the fun
too as there’s a fair chance that I’ve broken something for us too somewhere. All this is a subtle hint that you should not use this for anything you
do not want to lose.

There are one or two changes you should know about. This will turn into a rant BTW so take a deep breath before continuing. The short version, assuming Oxidizer starts up at all on anyone else’s Mac, is that the things that I may have broken are Saving Movies, Saving Images and Lua scripting.

In order to code a 64 bit version I’ve basically had to strip out all the old quicktime code and replace it with newer more up to date API’s. Now this is one of the major reasons its took so long so bring a new version out, the other being that rewriting working code is really not very inspiring especially when you are doing it to support a platform you can’t actually test against. Apple depreciated huge hunks Quicktime in Leopard and actually removed them for Snow Leopard. The trouble is they didn’t fully replace all those removed bits in the new API’s. One big thing that Apple broke was required for displaying the Quicktime setting dialogs before creating a movie. Apple’s official work around – use a 32 bit background process to display the dialog and pass the settings back. Absolute rubbish. Of course you either do that or write your own settings dialogs for very codec or show your dialog at the end of the render, so Oxidizer now launches a 32 bit background process just to show a dialog.

The next thing have Apple obsoleted was using Quicktime for saving images. That I was mostly happy about as the Quicktime API for images was really rubbish, way to low level and frankly a pain in the neck. The new API is vastly better, but the settings you guys get to set in the settings dialogs are vastly dumbed down and I’m sure some of you won’t like it. The good news is that the new API has some really fun features that I can use in later versions, when I officially depreciate Tiger (where as now I just try not to break it).

Finally, I’ve had to hack the Lua bridge to create a mix of the Apple version and the GNU-step version to support compilation against Snow Leopards libraries, again due to Apple obsoleting stuff. Luckily it was stuff that the GNU-step project didn’t have so the code was mostly there to deal with the missing functions all I had to do was enable the GNU code while keeping the Cocoa version limitations.


64 bits

by David BurnettWednesday March 17th, 2010
Posted in Developer's Corner, Oxidizer Blog

EyeDrinkVenom raised an interesting point on the Forum, Oxidizer is a 32-bit application, so it can’t address the huge Gigabytes of memory everyone seems to have these days.

So why haven’t I released a 64bit version yet ? As you may have guessed it isn’t as straight forward as it should be. Ignoring the minor fact that I’m suffering the early adopter issue of having one of the few 32bit Intel iMacs Apple made, the main issue is that making Oxidizer 64bit could mean I’d have to abandon Lua as a scripting language. The Lua – Objective-C bridge currently does not compile for 64 bit architectures, there are also some bug reports for 64 bit Lua for Macs so it might not work anyway. There’s also the flam3 programs I call, I’ve got no idea if they work when compiled against x86-64 or if they’ll take advantage of the extra memory (ppc64 is definitely out at the moment, more on that later).

So, I’ve decided to try a piece meal approach, sitting on the sourceforge servers are a couple of highly experimental new compiles of Oxidizer
one for Leopard and one for Snow Leopard. Oxidizer is still 32 bit, but I recompiled the flam3 programs for x86, ppc and x86-64.
While this means (if they work at all) is that you still can’t use millions of genomes in Oxidizer, but on 64bit intel mac you might be able to create ridiculously big images.

BTW ppc64 isn’t supported as I couldn’t get it to link to some of the system libraries, I think I need some clever way of only compiling for ppc64 in the Leopard version. If anyone is actually interested in me getting it working, shout up and I’ll spend some more time on it.

So give them a go, let me know if they work at all, and if the extra memory get addressed.


Console yourself with this…

by David BurnettTuesday August 4th, 2009
Posted in Developer's Corner, Lua Scripts, Oxidizer Blog

It’s Oxidizer….

Now the timeline for Oxidizer I posted for Oxidzer 0.6 is well and truly wrong, its time for a new sneak preview.

Changes for are…

  • Brand new interactive Lua Console.
  • Update flam3.
  • Up and Down buttons for xforms.
  • XForms should now consistently order from 1.
  • Xform order should start from one when deleting / adding new xforms.
  • Fix for tree selection when driven from xform table, wasn’t setting current xform.
  • Fix preview quality when not limiting the quality.

I’ll try an knock up a sensible begginers guide to the Interactive console but its Lua witha couple of specific Oxidzer function calls.

So, open the console and in the bottom window type…

print “hello world”

and the console should print

> hello world

The Oxidizer specific function calls are..

To pass genomes from oxidizer into Lua

genomes = oxidizer_api:passGenomesToLua()

To append / replace the genome created / modified in  lua


Notice that you pass the name of the Lua table holding the genome back to oxidizer, not the genome table itself.

So for a small example, starting with one genome in oxidizer…

g = oxidizer_api:passGenomesToLua()
g[1].time = 10

Will load the genome, set its time to 10 and then add the genome to the end of the existing genomes in oxidizer. Since there was only one genome in Oxidizer in the first place we’ve effectively copied it and set the copy to have a time of 10.

Okay, while I’ve been typing that up, the new version has finished uploading so have at it. It’s in the usual place.


The Road to Oxidizer 2.0

by David BurnettFriday April 24th, 2009
Posted in Developer's Corner, Oxidizer Blog

What, 2.0, hold on version 1.0 isn’t out yet…

Continued →

So yeah, like no but yeah…

by David BurnettMonday March 2nd, 2009
Posted in Developer's Corner, Oxidizer Blog

So there’s like a new sneak preview available.

New features this time include…

  • A script library.
  • A random gradient button.
  • More QuickView options for the gradient editor, including hue rotation, random gradients and improved palette rotation.
  • Drag and Drop appending of flam3 files onto the genome list views.

This version is number and you can get it here.


It’s about time….

by David BurnettTuesday January 27th, 2009
Posted in Developer's Corner, Oxidizer Blog

… I let you play with a new toy, so it’s sneak preview time again.

I’ve just uploaded Oxidizer  to my oxidizer webspace, so go get it there

For those new to the sneak preview process, a sneak preview is an unofficial release of Oxidizer exclusive to any one that reads rampant-mac. It’s sole purpose is for me to get feedback on  new features before I unleash them on the unsuspecting public. It also gives me the chance to release versions that might have major issues in them like features not working on Tiger for example, or just not working full stop :-) .

So, what’s new….

  • The main new feature is QuickView which renders thumbnails for range of values for a particular parameter. To use it press one of those strange buttons with a Q on it.
  • This version of Oxidizer is mostly localized for the French. To use switch your Mac to French :-)
  • There’s a new menu option to re-run the last Lua script used.

Known issues…

  • Some of the default values are pretty useless.
  • It does not take into account that some parameters are integers.
  • The odd parameter that could have QuickView applied does not.
  • QuickView is a naff name, so the QuickView window title is still “Window”.
  • New Bits mean the French localization is incomplete.

Any issues let me know below, or in the Squish Bugs forum where there’s a nice post on how to make useful bug reports.