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 :-)

Dave

Oxidizer Quick Start Guide

by Lennart OstmanSunday June 12th, 2011
Posted in Oxidizer Blog, Using Oxidizer

The Oxidizer app can seem complicated at first, but there is a system to the fractal madness.  You don’t have to dive into every parameter at once.  This is a method I have found works very well.

1) If you don’t already have, download the simil4.lua and the simil3.lua scripts.  They will give you a very good starting point.  Often they will provide random genomes you can use right out of the box.  You can store the downloaded script anywhere you like.

2) Load the script by clicking on the + button and hit “Run”.

illustration 1

3) Now you’ll have a list of random genomes to use as a starting point.  If the script does not produce anything you fancy, press “new” on the File menu and click “run” again.  If you like you can click the “Random” button and get a new random seed for the genomes.  The seed can make quite a large difference, so it’s worth trying.

illustration 2

4) I usually hit the “Run” button a couple of times and collect the best genomes by dragging them over to the clipboard.  You’ll find that on the Window menu.  From there I can drag them into a fresh list and only collect the good ones.

illustration 3

5) Now, in this example I will chose to work with the heart shaped genome.  So I select it and click on “Edit” (see picture 2).  That will open the genome editor window.   I then click the “Lock to height” box and change the size to 800 x something and the Quality under the “Render” tab to 800.  After that go to the “Render” menu and chose “Render still to window”.  That will give you a fairly good image to guide you further.  It will take about a minute to render, depending on processor speed.

illustration 4

This is how the preview of my chosen genome looks like.

illustration 5

6) Pretty nice, but there are some things I like to change.  The first thing I want to change is the colours.  The orange color is pretty but I want more than one colour in my fractal.  So I first change the size back down to 200 or 400 and the quality to 25 (If you forget that you’ll spend a lot of unnecessary time waiting for rendering) then I click on the “xForms” tab and see a list of the xForms that make up the fractal.  You can say it’s the different parts of the fractal.

illustration 6

7) I click the “Edit” button and in the xForm edit page I go through all the xForms and click the quicklook “Q” button on “Colour” for each one.  That will bring up the quicklook window and give you a lot of small renderings of the genome with slightly colour variations.  This is where you are going to be waiting if you forgot to change the size and quality settings back.  When I go through the xForms like this I will learn what xForm make up what part of the genome and I will introduce more colours in the genome, just like I wanted.

illustration 7

8) I make my choice and move on.  If you want to change the form of the genome there are a lot to be done in the “Variations” list in the xForm edit window.  If you add an xForm you’ll add a new part to the genome.  If you add a variation to an xForm you’ll change that part of the genome.  If a xForm has a “Fan” variation you can make that “Fan” part of the genome blurred by adding a “gaussian blur” variation to the xForm.  By adding and changing you can model the genome into the fractal you want.

illustration 8

Don’t be afraid to try stuff and see what result it will give.  Wherever there is a “Q” you get a lot of different previews for the settings of that parameter.  As long as you don’t click on one of them, you’ll change nothing.  There are lots of things to change the genome with, but one thing to not miss is the “Symmetry” in the “Edit” tab.  That parameter alone can make a huge change.

9) So now I’m more happy with the result and it’s time for the final rendering.  I have found a way that will give you large, beautiful and detailed fractals with a minimum of rendering time.  I use the “Scale” parameter to change the size and lock it to the height when I’m pleased with the result. I don’t touch the “Zoom” parameter since that, though bringing more quality also multiply the rendering time several times.

Instead I set the rendering size to 4000×3000 px and use only the “Scale” parameter to zoom in.  I then set the “Quality” parameter to 2000.  That will give you a large fractal with enough detail that will render in about 1 hour.

The fractals rendered with Oxidizer need a bit of afterwork to give them that final shine.  I use Aperture for that myself, and bring the contrast and the brightness up a bit.  I also add definition and sharpen the image a bit.

Happy rendering!

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 0.7.5.4 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.

Dave

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.

Dave

Oxidizer 0.6.1.0 redux

by David BurnettTuesday February 9th, 2010
Posted in Oxidizer Blog, Oxidizer Community

Just a note to mention Oxidizer 0.6.1.0 is now an official release.
No changes from the sneak peak version, but if you you want to grab a copy to boost the download figures download it from here :-)

Oxidizer Quick Tip: Multi-Stage Rendering

by Scott ChitwoodMonday September 21st, 2009
Posted in Oxidizer Blog, Using Oxidizer

Not sure if anyone else has seen/reported this handy little feature.

All of my renders are produced on a MacBook Pro these days and there have been occasions, during mid-render, that an errant family member closes it up on me.  A little annoying at first, but then it became apparent that the render resumes when the screen is popped open again.  Sweet!

What I don’t know is if this may work the same for users of desktop systems during sleep mode.  Another unknown factor is how many times a render can be interrupted and successfully resumed.  And with anything weird like this, your mileage may vary.

Oxidizer for Snow Leopard

by Scott ChitwoodSunday September 20th, 2009
Posted in Oxidizer Blog

UPDATED  Official Oxidizer updates from David Burnett have been posted in the comments, grab ’em while they’re hot!

This version comes to us courtesy of our friend ‘OnlyJedi’, here’s the scoop as quoted from this forum thread

I’ve been having the same problem on Snow Leopard (10.6.1) with both Oxidizer 1.5.0.2 and 0.5.5.  Any attempt to either create a new flame or move a flame from the Gene Pool to the editor crashes Oxidizer.

So I did as David suggested and compiled Oxidizer myself (using the 0.5.5 sources, I couldn’t find anything later).  After setting the target to 10.6 & i386, everything seems to work; no editing of source code needed.  I haven’t had a chance for a more thorough test yet, but at the very least I can create new flames, move flames from the gene pool, edit and render without crashes.

I’d be willing to share my .app if anyone wants.  If I could get a hold of the 1.5.0.2 sources (wink wink nudge nudge) I could probably make a 10.6 compatible version of that as well.

Download Oxidizer 0.5.5 for Snow Leopard