64 bits

by David Burnett • Wednesday 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.



  1. Don Larson
         March 17, 2010

    I downloaded the Snow Leopard version. It opened. I tried to use the breeder and received message about not finding the right library. I clicked the close button and went into the loop of the message dialog box about not finding library. I force quit to exit.

    iMac 4GB of Ram, Core 2 Duo 2.4Ghz. MacOS 10.6.2


  2. EyeDrinkVenom
         March 17, 2010

    Hi Dave

    I’m going to grab the snow leopard version and give it a whirl while I’m waiting for dinner.

    Also, I’m not sure if it would help, but if you want to walk me through the steps, I can try to compile the app in XCode. I’m not sure if it makes a difference what system you are running. The one mac programmer I know is too swamped to even respond to me and the other guy I know doesn’t have a Mac at all.

    If it’s not too insane I don’t mind giving it a try. I have XCode installed on Leopard and I can install it on Snow Leopard if need be and I have 64-bit intel procs in here.


  3. EyeDrinkVenom
         March 17, 2010

    Got errors here as well on Leopard. You can grab the error window screenshot here:


  4. EyeDrinkVenom
         March 17, 2010
  5. EyeDrinkVenom
         March 17, 2010

    Well, it failed in Snow Leopard too. Different errors though.

    Screenshot: http://www.offtherackpro.com/images/ox_SL_test.png

  6. David Burnett
         March 17, 2010

    Okay I’ve fixed (at least it works here :-) ) the jpeg library issue in the Snow Leopard version so If you want to try again feel free. The Same URL as before.


  7. David Burnett
         March 17, 2010

    Actually, don’t bother found another bug which means it’ll only work for me :-)
    Give me ten minutes…

  8. David Burnett
         March 17, 2010

    Okay, now you can try again, this version will actually run from anywhere , not just one particular path that anyone other than me is unlikely to have.

  9. Don Larson
         March 17, 2010

    I tried new version several times. Each attempt gave the unexpectedly quit error.


  10. Cubixel
         March 18, 2010

    MBP (2,1) first 64bit intel. 4gig ram etc. Snow Leopard app crashed on startup. No messages just a report crash dialogue.

    Good to see your attempting this though, keep it up!


  11. David Burnett
         March 18, 2010

    Okay folks, I need the text from the crash reports, as the new version works fine here.


  12. Don Larson
         March 18, 2010

    David, here is my Crash Report (User Diagnostic Reports) from yesterday with the second released SL version that quit upon launch:

    Process: Oxidizer [534]
    Path: /Users/dwlarson/Desktop/Oxidizer.app/Contents/MacOS/Oxidizer
    Identifier: net.vargolsoft.oxidizer
    Version: ??? (???)
    Code Type: X86 (Native)
    Parent Process: launchd [424]

    Date/Time: 2010-03-17 18:24:23.488 -0700
    OS Version: Mac OS X 10.6.2 (10C540)
    Report Version: 6

    Exception Type: EXC_BREAKPOINT (SIGTRAP)
    Exception Codes: 0x0000000000000002, 0x0000000000000000
    Crashed Thread: 0

    Dyld Error Message:
    Library not loaded: /Users/vargol/Source/oxidizer/build_folder_for_flam3/lib/libjpeg.8.dylib
    Referenced from: /Users/dwlarson/Desktop/Oxidizer.app/Contents/MacOS/Oxidizer
    Reason: image not found



  13. David Burnett
         March 19, 2010

    Hi Don, can you try another download just to confirm you’ve got the latest version and didn’t get a cached version. That was the reason for the ‘give me ten minutes’ hold up. Xcode had added the new version of the jpeg library to Oxidizer when it was only supposed to copy it into the bundle.

    Once you’ve confirmed it’s still an error I’ll see if I can figure out why its still linking it in.

  14. Don Larson
         March 19, 2010

    Dave, okay I just downloaded SL again. Upon double-clicking it quit unexpectedly. Crash report below:

    Process: Oxidizer [598]
    Path: /Users/dwlarson/Desktop/Oxidizer.app/Contents/MacOS/Oxidizer
    Identifier: net.vargolsoft.oxidizer
    Version: ??? (???)
    Code Type: X86 (Native)
    Parent Process: launchd [421]

    Date/Time: 2010-03-19 09:26:02.830 -0700
    OS Version: Mac OS X 10.6.2 (10C540)
    Report Version: 6

    Exception Type: EXC_BREAKPOINT (SIGTRAP)
    Exception Codes: 0x0000000000000002, 0x0000000000000000
    Crashed Thread: 0

    Dyld Error Message:
    Library not loaded: /Users/vargol/Source/oxidizer/build_folder_for_flam3/lib/libjpeg.8.dylib
    Referenced from: /Users/dwlarson/Desktop/Oxidizer.app/Contents/MacOS/Oxidizer
    Reason: image not found

  15. David Burnett
         March 19, 2010

    Thanks for that Don…

    Hopefully a new version will be on its way shortly.


  16. David Burnett
         March 19, 2010
  17. Don Larson
         March 19, 2010

    Dave, that newest version worked fine for me. I used “Fill” and “Render” without a problem. Thank you!


  18. EyeDrinkVenom
         March 19, 2010

    Hi Dave

    Sorry for the delay. Was swamped the last few days with a project. Going to fire up snow leopard and give this a go.

    btw, Don, are you running snow leopard in 32 or 64-bit mode when you’re testing? The installation dic defaults to 32-bit startup mode. If you want I can point you to an app that will switch OS X to 64-bit mode.


  19. EyeDrinkVenom
         March 19, 2010

    okay, so Snow Leopard running in 64-bit mode ox seems to be working fine. Rendering quite fast, however it’s not using all of my CPU. Spotlight was eating up 100% of one core and 34% of my CPU power was still not being used. Even so, Ox rendered a 1700×3000 image in less than 5 minutes :)

    When spotlight finishes eating up the juice, I’m going to try a massive render and monitor it in Activity Monitor to see the RAM/CPU usage and will post my findings.

    Thanks for compiling this Dave! I owe you a beer.

  20. EyeDrinkVenom
         March 19, 2010

    one more note: I just launched a render that is 12,000 x 20,000 pixels. so far Ox is telling me it will take less than an hour, about 50 minutes. This is on quality level 300 and oversample 1. It’s now using most of my CPU, between 790-795% depending on what other process is eating up small bits.

    The odd thing is that it’s capped out on RAM at 1.6GB and it’s not moving. Maybe it just doesn’t need more RAM? I thought for sure it would gobble up as much RAM as it could to render faster, unless it works drastically different than renderers like mental ray.

    This is great though. Thanks a lot Dave. This is going to let me use Ox on my project. I actually need to render much larger than 20,000 pixels wide. I will post some cropped images when I do those to show you guys the type of details I get as well as benchmarks.

    I still need to test out command line rendering which should make it even faster.

    —Edit—— Okay, I was about to send this and then Ox (flam3 renderer) process dropped to about 1 core use, then the RAM use shot up to 2.51GB and now it’s up at 790% cpu rendering again. I guess it is going to gobble :)


  21. EyeDrinkVenom
         March 19, 2010

    okay, render was fast. about 64 minutes total (so the progress bar wasn’t entirely accurate) but that’s more than twice as fast as an image roughly twice the scale rendered in 32-bit version.

    Slight snag though. I had just clicked update render in the render view. Now there is no way for me to get the render out of the window. Drag and drop to the finder just gives me a color wheel and errors in the console. If there is a cache file somewhere so I can get at this image that would be great. A save button in the render view would definitely be a nice addition ;)

    Here are the errors:

    3/19/10 10:13:04 PM GrowlHelperApp[589] *** attempt to pop an unknown autorelease pool (0x15002a00)
    3/19/10 10:19:34 PM GrowlHelperApp[589] *** attempt to pop an unknown autorelease pool (0x15002a00)
    3/19/10 10:19:51 PM com.apple.WebKit.PluginAgent[764] Debugger() was called!
    3/19/10 10:20:33 PM com.apple.WebKit.PluginAgent[764] Debugger() was called!
    3/19/10 10:22:04 PM GrowlHelperApp[589] *** attempt to pop an unknown autorelease pool (0x15002a00)
    3/19/10 10:36:34 PM GrowlHelperApp[589] *** attempt to pop an unknown autorelease pool (0x15002a00)
    3/19/10 10:37:34 PM GrowlHelperApp[589] *** attempt to pop an unknown autorelease pool (0x2000000)
    3/19/10 10:45:53 PM SubmitDiagInfo[818] Removed expired file /Library/Logs/DiagnosticReports/fseventsd_2010-02-20-202144_localhost.crash
    3/19/10 10:46:38 PM com.apple.WebKit.PluginAgent[764] Debugger() was called!
    3/19/10 10:46:39 PM com.apple.WebKit.PluginAgent[764] Debugger() was called!
    3/19/10 10:57:05 PM GrowlHelperApp[589] *** attempt to pop an unknown autorelease pool (0x2000000)
    3/19/10 10:57:35 PM GrowlHelperApp[589] *** attempt to pop an unknown autorelease pool (0x2000000)
    3/19/10 11:01:35 PM GrowlHelperApp[589] *** attempt to pop an unknown autorelease pool (0x2000000)
    3/19/10 11:02:35 PM GrowlHelperApp[589] *** attempt to pop an unknown autorelease pool (0x2000000)
    3/19/10 11:03:35 PM GrowlHelperApp[589] *** attempt to pop an unknown autorelease pool (0x80b200)
    3/19/10 11:05:05 PM GrowlHelperApp[589] *** attempt to pop an unknown autorelease pool (0x80b200)
    3/19/10 11:08:48 PM com.apple.WebKit.PluginAgent[764] Debugger() was called!
    3/19/10 11:08:48 PM com.apple.WebKit.PluginAgent[764] Debugger() was called!
    3/19/10 11:10:35 PM GrowlHelperApp[589] *** attempt to pop an unknown autorelease pool (0x15002a00)
    3/19/10 11:18:05 PM GrowlHelperApp[589] *** attempt to pop an unknown autorelease pool (0x2000000)
    3/19/10 11:18:30 PM [0x0-0x27027].net.vargolsoft.oxidizer[623] Oxidizer(623,0xa0abd500) malloc: *** mmap(size=960081920) failed (error code=12)
    3/19/10 11:18:30 PM [0x0-0x27027].net.vargolsoft.oxidizer[623] *** error: can’t allocate region
    3/19/10 11:18:30 PM [0x0-0x27027].net.vargolsoft.oxidizer[623] *** set a breakpoint in malloc_error_break to debug
    3/19/10 11:18:50 PM [0x0-0x27027].net.vargolsoft.oxidizer[623] Oxidizer(623,0xa0abd500) malloc: *** mmap(size=960081920) failed (error code=12)
    3/19/10 11:18:50 PM [0x0-0x27027].net.vargolsoft.oxidizer[623] *** error: can’t allocate region
    3/19/10 11:18:50 PM [0x0-0x27027].net.vargolsoft.oxidizer[623] *** set a breakpoint in malloc_error_break to debug
    3/19/10 11:19:35 PM GrowlHelperApp[589] *** attempt to pop an unknown autorelease pool (0x15001a00)
    3/19/10 11:21:35 PM GrowlHelperApp[589] *** attempt to pop an unknown autorelease pool (0x15001a00)
    3/19/10 11:22:05 PM GrowlHelperApp[589] *** attempt to pop an unknown autorelease pool (0x15002a00)
    3/19/10 11:22:23 PM [0x0-0x27027].net.vargolsoft.oxidizer[623] Oxidizer(623,0xa0abd500) malloc: *** mmap(size=960081920) failed (error code=12)
    3/19/10 11:22:23 PM [0x0-0x27027].net.vargolsoft.oxidizer[623] *** error: can’t allocate region
    3/19/10 11:22:23 PM [0x0-0x27027].net.vargolsoft.oxidizer[623] *** set a breakpoint in malloc_error_break to debug

  22. Don Larson
         March 19, 2010


    I figured the app would use 64-bit if it needed. :-)

    In any case, I forced 64-bit mode on restart and Oxidizer SL new version ran well for me.

    During my rendering I also noticed it didn’t use all the CPU power, but it was pretty fast.


  23. EyeDrinkVenom
         March 19, 2010

    Cool Don. Yeah just wanted to check because some people don’t know that you have to make OS X run in 64-bit mode to really get it chugging.

    It seems to only use all my CPU when I throw something ridiculous at it like a 20k render. Unfortunately I couldn’t save the image I rendered but I’ll try and get one done tonight to post details.

    Don, can you check something? I’m not getting any recent files showing up in the 64-bit version. Just wanted to know if you are getting the same behavior.


  24. David Burnett
         March 20, 2010

    Hi, remember that Oxidizer is still 32 bits, only the flam3 programs it uses are 64 bits. I’m going to guess that render to window isn’t going to work for really big files. I’ll need to wrap that code with an exception to trap things

    I’m give things a go though see if I can duplicate the error, so cource it means I’ve got to create an image big enough :-)


    You might be able to recover your image, if it’s not been tidied up yet….

    look in the console for a message, around the you started your render for an environment parameters list…

    19/03/2010 18:23:41 Oxidizer[8730] env: {
    bits = 64;
    “flam3_palettes” = “/Users/xxxxx/Source/oxidizer/build/Release Snow Leopard/Oxidizer.app/Contents/Resources/flam3-palettes.xml”;
    “isaac_seed” = 906106999;
    out = “/var/folders/jr/jrWIQ+Ps2RW+t++1YvXpx++++TI/-Tmp-/tmp.12.5xnun9/gpm.png”;
    seed = 1522795082;

    The out parameter should be the image as a png file, if there’s a lot to choose from look for the ones called ‘still.png’.

  25. Cubixel
         March 20, 2010

    Ok so how do you force 64 bit mode? I wasn’t aware you had to because I see most of my apps say running 64bit in the Activity monitor.

  26. Cubixel
         March 20, 2010

    By the way that new version started up for me ok. and appears to run ok. Haven’t given it a good run through though.

  27. Cubixel
         March 20, 2010

    Darn it, my machine only has the 32 bit EFI. I was told it could run 64 bit native when it came out. I specifically waited for this model so I could. Sick of not having what I need. I haven’t found this info yet, but does anyone know if I can upgrade the EI to the 64 bit EFI? Cheers,.

  28. Don Larson
         March 20, 2010

    @Cubixel You can force 64-bit mode on capable computers by restarting and holding down the “6” and “4” keys together during the boot process. Next time you reboot, it goes back to the default setting.

  29. EyeDrinkVenom
         March 20, 2010

    cubixel you an also use this app to permanently do it or switch modes. It will also show you what your processors support.



    I don’t have a “jr” folder, only zz and dw. I tried a massive render last night that took 11 hours it just finished a little while ago. For some reason the file was not saved, I was saving to PSD because PSD can handle those extreme file sizes. I also cannot find any png files in the temp folders.

    Any advice?

  30. EyeDrinkVenom
         March 20, 2010

    I have a project to hop on again, but I will check the notes you left in the forum about command line rendering. If there is a different path to use for the snow leopard build, or any different directions, please let me know.


  31. EyeDrinkVenom
         March 20, 2010

    sorry, one more note as I just tried a quick command line render. I followed the steps you posted in the forum, but I get an error.

    (from the resources folder) I rendered with: ./flam3-render < /Volumes/Octo_Vault_2/oxidizer/giant_OX/screaming_flower_004_massive.flam3

    flam3: could not open palette file /Users/vargol/Source/oxidizer/build_folder_for_flam3/share/flam3/flam3-palettes.xml: No such file or directory

  32. EyeDrinkVenom
         March 20, 2010

    Leopard version with 64-bit flam3 errors out.


  33. David Burnett
         March 21, 2010


    If you are looking for the still file anything between”/var/folders/…” and “…/still.png” is totally random, it’s a Snow Leopard security method to create random temp folders to make it difficult to find other peoples temp stuff which also makes it difficult to find your own :-). That’s why you to have to dig the environment variables out of the console to find where that render was put this time around.
    OSX deletes the temp files when it feels like it though, which is why I said that there was a chance you might be able to recover it.

    Regarding using flam3, you didn’t set the flam3_palettes environment variable so its defaulting to where mine are :-)
    export flam3_palettes=”./flam3-palettes.xml”
    ./flam3-render < mygenome.flam3
    note that assumes you are running flam3 from the resources directory.

    PSD file, don't know, quicktime has a tendency to fail without returning an error. I've never had it not save the file before though, its saved empty files but there's always been files. I'd definitely stick with using the save as PNG and jpeg options though as they avoid the conversion between what flam3 outputs and loading it in again and then saving though quicktime. I seriously regret putting saving though quicktime in as its been the bane of Oxidizer's life.

    I'm hoping that either the 64bit verion of flam3 or the forth coming libpng upgrade with fix the strange issue you had with the 16bit PNG's.

    Finally, I haven't updated the Leopard version yet that's why it still falls over.


  34. EyeDrinkVenom
         March 21, 2010

    Hi Dave

    crap, forgot to set the palette :) I’ll try again and see how it fares. I am running it from resources. I’ll use PNG this time. I’m not sure how large of a file PNG can support though. PSD gives you up to 360,000 pixels I think.

    Yeah, no sweat on the leopard version. Just wanted you to know I tested it and what the errors were. If this keeps up I’m going to have to start a fractals anonymous group because I’m a friggin’ junky.

    Thanks again

  35. EyeDrinkVenom
         March 23, 2010

    loading flam3 files into the breeder in the Snow Leopard version fails. An error window pops up that says “Genome filed!”

    I still can’t image files to save using command line.

  36. David Burnett
         March 23, 2010


    Any error messages for the flam3-render command line. The minumum script of render an image
    should be setting the palette and running flam3-render. You should then get a png file in the directory you ran it from.

    For the breeder issue look in the Console around the time of the crash, there may be a line that starts “got: ” that’ll be the flam3 error message in this case. The Genome failed error is a message that flam3 failed to render the genome.


  37. David Burnett
         March 27, 2010

    Okay folks, its time for 0.7.2 .

    It’s still experimental :-) changes in this version are an updated libpng , getting rid of the out of date french translation which actively crashes french Mac’s. Thanks to Vampyre of the bug report, Apple your way of doing I8n sucks.

    I’ve also made a stab at ‘fixing’ the drag and drop issue from the preview window on the 64 bit version. What I’ve probably done is made it possible to drag but crash on drop but as I can’t test it…

    At some point I’ll have to bite the bullet and compile a proper 64 bit version of Oxidizer to see what breaks.

    Oh, and at last there is a Leopard Version again. They’re both in one file this time, so go to
    to get them.


  38. brunorc
         March 28, 2010

    I just grabbed the 0.7.2 version and going to run it in a while… but after seeing the jaw-dropping output from Apophysis 3D hack I cannot resist to ask: are you going to include the 3D rendering possibility in Oxidizer?

    Thanks for your work, Dave – Oxidizer is amazing!

  39. EyeDrinkVenom
         March 28, 2010

    Hi Dave

    I’ll hop into snow leopard shortly and give it a whirl and report any error messages. I followed your directions for isaac seed and setting the palette. I don’t remember seeing any errors last time though. An image was just not created. Will let you know how I fare with the new version.

    Also, I’ve seen some people post on the net that the only benefit to booting snow leopard in 64 bit is to use more RAM in an XServe. I have compared 32-bit and 64-bit kernel boots and 64-bit mode the OS starts much faster, apps run faster, and even oxidizer seems faster all around. The only thing is compatibility, i.e. one of my preference panes doesn’t work.

    If I find the time I’ll do some actual benchmarks, but it just seems smoother overall.

  40. Cubixel
         March 31, 2010

    Does this 64 bit Oxydiser in its current state require the kernel to be started in 64 bit. e.g. am I wasting my time running it on my MBP which can’t start in 64 bit but can run 64 bit apps over the 32 bit kernel. We also have a fairly new iMac here that run the 64 bit kernel, but it’s not my main work station.

  41. Cubixel
         March 31, 2010

    Well tested with my general work flow on the MBP 32 bit kernel and had no issues that I noticed.

    Incidentally, I want to add to my feature request and suggest a preference where I can define a project path. I have a directory where all my projects reside, and within that I have categories like Maya, Oxydizer etc. Maya had a project location definition which makes things a little easier as Maya always looks to my Maya directory which saves me time.


  42. Cubixel
         March 31, 2010

    Oh.. I only have Snow Leopard here and all machines are kept up-to-date so running OS X 10.6.3 now.

  43. David Burnett
         April 1, 2010


    Disclaimer… is is all based on stuff I’ve read on the internet :-)

    From what I understand even with a 32 bit kernel you’re supposed to run the 64 bit versions of programs by default on a 64 bit Mac.

    To prove it, start activity monitor (/Applications/Utilities/)
    make sure the ‘Kind’ column is visible and start a render that’ll last for a minute or two. Back on Activity Monitor look for the flam3-render process that’s eating up your CPU, if its running the 64 bit version it’s supposed to have a ‘Kind’ value of ‘Intel (64 bit)’.

    I’m not sure if you can address all the memory, especially if you’ve got a 32bit EFI, the internet disagrees on that one, but you will be able to make use of the advantages of the x86_64, more registers, hardware trig functions etc.

  44. EyeDrinkVenom
         April 3, 2010

    Hi David

    So I tested on snow leopard and images are now being saved when in command line mode. They are not being saved where the flame file is though. They are instead being saved to the resources folder of the app itself which is not ideal.

    Is there a flag for the flame renderer to define a file path?

    I’m doing a massive render now so hopefully it will save the file, even if it’s to the resources directory. Will post the results.


  45. EyeDrinkVenom
         April 4, 2010

    Here’s an update.

    The render is running but it’s rendering in “strips”. It seems the renderer has chosen to render this in 6 parts, each taking about 209 minutes.

    Flame is running in 64-bit but is capping out at 2.7GB of actual RAM, and 2.74GB of Virtual RAM.

    If you can figure out a way to make it use all available RAM I think it will definitely speed up rendering because it’s probably having to do more frequent swapping of memory using disk than just loading up the actual RAM.

    Glad the command line is working though. Thanks for getting that solved.

  46. David Burnett
         April 4, 2010

    Okay, the next version is up for download.

    This version has a multithreaded genepool (fill and breed)
    and attempts to lift one of the limitations for 64 bit version of flam3 using all the memory, the check for how much memory you have maxed out at 3G. I’ve changed the code to use a different system check on 64 bit Macs. the new way returns a 64 bit int, so hopefully it’ll return the right size. Of course it may means its gone from using striping on a image that’s too big to crashing :-)

    I’m intending to bring the CVS repository up to date tomorrow, time allowing, so the source will be available to all then.

    @EyeDrinkVenom , running this version of flam3 from the command line should tell you how much memory it thinks you have. You’ll get a line like this in the output…

    flame = 1/2 available physical memory is 2147483648

    Hopefully the number will be much bigger for you.

    Oh and why I’m at it to set the name of the output image use a environment variable called ‘out’ e.g.

    export out=”/Users/xxx/Documents/OxidizerRenders/my_nice_flame.png”

    There’s a better guide to using the command line at the electric sheep wiki

  47. EyeDrinkVenom
         April 4, 2010

    Hi David

    Thanks for filling my request of multi-threading breeding and gene pool. I owe you another beer :)

    My enormous render finished a little while ago. Took 1283.7 minutes (a little over 21 hours) for a 900MB PNG image. Obviously slightly larger than the average bear may need but thanks so much for getting Ox to handle this as it’s allowing me to use Oxidizer for new kinds of media. Even though it rendered in strips, there were no errors and it rendered beautifully.

    There is an odd thing flame seems to still do where certain parts of an xform look aliased when the rest looks smooth, as if it’s building up alpha or something. Sometimes I can fix it by going into after effects and doing a slight vector blur. That would probably a bigger deal to try and figure out to resolve.

    I’m not getting any memory info in console or terminal. All it said was:

    strip = 1/6
    and then after rendering the first strip:
    chaos: 100% took: 12546 seconds
    then strip 2 finished:
    filtering…writing 00000.png…strip = 2/6

    I just grabbed the latest build and will set off another big render and see how the memory fares. Thanks again for all the hard work you’ve done recently. If you ever come to NY let me know and I’ll hook you up.

  48. EyeDrinkVenom
         April 4, 2010

    Okay, with the new version it gave me the memory: 34359738368 which I assume is bytes because that works out to 32GB.

    This render isn’t as large but it says it’s only going to take 58 minutes. Yesterday’s test flam3 had to render 307,180,800 pixels, and today’s is only 69,984,000. So about 1/5th.

    I’ll let you know if it breaks the 3GB barrier.

  49. EyeDrinkVenom
         April 4, 2010

    Tested out the multi-threading in latest SL version.

    Hitting the “fill” button in gene pool when there are no genomes (blank) crashes Oxidizer. I tested a few times and if 4 slots are filled with genes and I hit “fill”, then it will fill the rest. If 0,1,2, or 3 genomes exist in the gene pool, Ox crashes before finishing.

    I had a file saved with a few different genomes, so I dragged 4 from the main window into the gene pool and hit “breed” button… wow. really fast. multi-threading is definitely working there. Nice work Dave.

    Breeder seems to work fine as it did before. definitely a jump in speed although not as noticeable as the gene pool. However, loading genomes from flam3 files still errors out and they are not loaded into the breeder. Dragging them from the main window works fine. Ox does NOT crash though.

    I keep coming back to my machine after the renders finish in command line so will let you know about RAM use when I catch one in action. It’s not using all the RAM at first so I have to pop in now and then to check. I did see on one render that it was using 2.93GB of RAM and virtual RAM which was more than before. That was early on in a 2.5 hour render though.

    Also, the reason it didn’t render my image to the right place is that I forgot to add the word “export” to the beginning and on the last render my file path was incorrect so no image was saved. I have it setup properly now so will let you know if it works.

    It would be nice to have a shell script for command-line rendering, or a widget/small app (launcher) with text input fields and preference saving to easily edit the flags for flam3. Would be nice to be able to queue these files too and maybe tag them with the proper isaac_seed in the launcher, or just build the launcher into Ox. I took a stab at a shell script it but I’m no coder and it’s not right.

    Anyway, will keep you posted on the rest.

  50. David Burnett
         April 13, 2010

    Okay, we now have this is an attempt to resolve EyeDrinkVenom’s GenePool issue.
    I’m not sure I actually duplicated it, as it was pretty stable for me, I leapt on the one crash I had from filling a few hundred slots with combination of, zero to four slots used.

    I’ve also added code to try and route out the problem loading genomes into the Breeder which I can’t duplicate at all, stone cold solid here. This has an unfortunate side effect on the GenePool though, you will get alerts for errors saying the following…

    ‘warning: reached maximum attempts, giving up.’

    These can be ignored, and the alert box closed, it just means you have the odd genome that is very ‘dark’ and maybe totally black (not an empty slot, if you get one of those it needs reporting). These happened anyway of course, I was just hiding the error message before, but that was the same code using in loading and rendering the thumbnails for when loading genomes in the breeder from which I now need the error messages.


Sorry, comments for this entry are closed at this time.