Well 1.0 is out the door. It’s had a lot of very positive responses and no bug reports so far, so I’m very happy with how the release has gone.

I’d like to thank everyone for your kind comments and for those who have purchased FluidNoise. Your support has encouraged me to think further about the future of FluidNoise, so I’d like to put my thoughts out there.

Firstly I have decided that version 2 will be a free upgrade to anyone who registers version 1. I’m not going to waste user’s time with a series of small feature additions, so I will add a fairly substantial extra set of features in a single version, and it will be a free upgrade for everyone who registers version 1.

So what will be in version 2?

OpenEXR export support. This has been requested in the comments on the blog here, and on investigation seems like a very useful addition. With 32bit or 16bit color export, the colors you choose in the color picker will be 8bit, but the resulting image will interpolate between these colors with greater precision. This vastly reduces any problems with banding when modifying the output in external image editing applications.

Normal map generation. Normal maps can be very useful for 3D scenes where light sources are involved. FluidNoise 2 will give an option to create seamless tangent space normal maps with variable height exaggeration, either animated or static.

Environment maps. A logical extension of normal map support is to allow for environment maps. Using any input image as an environment map, FluidNoise 2 will be able to generate reflections or subtle lighting effects. This will enable generation of images or movies from highly realistic water to shiny reflective metal or a sun-lit terrain.

Gradient import/export. This makes a lot of sense, as sometimes you may want to change parameters and easily try them with a few different color gradient combinations.

Though these four features are guaranteed, more features will no doubt be added throughout the development process. If you have any particular features you’d like to be added, please let me know and I’ll certainly consider it.

I can make no promises of a release date for FluidNoise 2 at this stage. More details will folllow in this blog as it progresses.

Today FluidNoise 1.0 has been officially released.

It’s been a long hard road, including an 18 hour day yesterday! Hopefully it will all have been worthwhile.

Give it a try!

FluidNoise website

There was a thread on a software development mailing list recently that discussed the acceptable level of bugs in a shipped product. I was quite blown away by the number of developers who said it was OK to ship with known bugs. I now understand why there is so much crappy software out there.

I will be shipping FluidNoise with zero bugs that I know about. Here is why.

Bugs piss me off. I assume that bugs piss most people off. If you piss people off with buggy software they will tell their friends. So the longer your buggy product stays out there, the more people will stay away from it, and the worse your name becomes. I’d like to think that people will still be coming back to my website to see what’s new 5 or 10 years from now because they downloaded FluidNoise this month, and they found it enjoyable to use.

Marketers love a big feature list, and don’t care about actual usability. You see this in products everywhere where marketers have the control. Cell phones, TVs, licensed games… Most of them are really frustrating to use, because their software was shipped with features that were buggy, useless or beyond the capabilities of the device they were designed for. Apple seem to have their marketing department under control, and as an indy developer I don’t have a marketing department. I can do my best to make every feature useful and bug free, because though features may help make the initial sale, usability keeps people coming back.

Besides all that general philosophy of keeping the customer happy there are two very practical reasons for fixing every bug you come across:

• If you don’t fix a bug now, it’ll be harder to fix later. The easiest bug to fix is the one that was introduced in the last line of code written. After this point code familiarity fades and the bug can become more complex, with other parts of the code relying on it’s existence.
• Each and every bug will generate its own set of support emails. These emails waste both the developer’s time, and the user’s time.

I’ll drop a feature rather than ship it with known bugs. It’s bad enough shipping with the bugs you don’t know about.

A couple of major achievements in FluidNoise today, after a grueling couple of days.

Getting undo/redo to work correctly has taken a lot longer than I had hoped, with problems popping up all over the place. However multiple documents can now be open with their own utility panels and document specific undo works smoothly on all controls. Switching to the multiple document architecture was definitely the right thing to do, and it’s starting to feel like a real application now. The gradient editor got a fair bit of work too, though I still need to figure out how I am going to represent the percentage of a selected swatch, and how to delete a swatch. Dragging the swatch off (dock-like) and right click->delete might not be enough, but a delete button seems overkill. These are the things that keep me awake at night!

I also made animation work to reward myself for all the mucking around with undo. It’s great to see that the animation interface will work fine, and to see some motion in the output. Even if no one else uses FluidNoise, I know I will. And at least I’m learning a bunch of stuff I can apply to FluidMotion :)