Leonardo is getting closer and closer to the point where you can use it for real work, but there are still a few things missing:

1. HUD-notifications (worked a long time ago but the code has decayed)
2. Custom brush-stamps as opposed to just ellipses.
3. Add, remove and rearrange brush-preset list.
4. Merging and changing Z-order of layers.
5. Better UI for layers.
6. Drag-n-drop from the export bar.

Compositors
(applications that export data that is intended for the end-user)

• Image compositor, exports PNG, JPEG etc. (this is Leonardo)
• Video compositor, exports AVI, MPEG etc.
• Document compositor, exports PDF.
• Code compositor, exports EXE.

Coadjutors
(applications that export data that is not intended for the end-user but rather to be imported by some compositor)

• Surface modeler, exports OBJ etc.
• Voxel modeler, export OBJ with corresponding textures (this is Michelangelo).
• Texture painting, export textures.
• Model animation, exports OBJs etc.
• 2D vector graphic editor, exports SVG etc.
• Spreadsheet editor, exports XML.

1. Users rarely have more then one tab open which make a tab interface just look dumb.
2. There is already a “tab-interface” inside the OS: the task-bar! (Of course, a Chrome style tab systems can do things the task-bar can’t, but the point is that handling more then one project really is something that should be done by the OS or, alternatively, with a multi-process architecture as Google Chrome does it)
3. It would be possible to use Ctrl + Tab to swap between layers instead of projects (tabs).
4. It’s easier to develop a SDI application then a TDI.

1. Xade applications are defined by what they export.
2. Xade applications internal file formats should be viewed as a project file with revision control.
3. Xade applications should be able to import every format that could be of interest for producing what the application export.

So, what is Leonardo?

1. Leonardo only export image files like PNG, JPEG, TIFF, TGA, BMP and OpenEXR.
2. But, Leonardo can import a whole host of formats including 2D- and 3D-vector graphics files. These formats get imported as special read-only layer that can be used either as reference material or rasterised to an image.

This divides Leonardo in to two parts:

1. A still image, layer based compositor.
2. A raster based painting system.

And just to be clear, Leonardo will not do the following:

1. Export vector-graphics or video.
2. Manipulate vector-graphics or video.
3. Have specialized tools for photo editing.
4. Have node based compositing.
5. Paint on 3D-objects.

I have created three new pages to aggregate some good ideas (look to the right under ‘pages’)

I’m starting to realize that having a finished prototype before midsummer is probably a little too optimistic, but I might have a engine Proof-of-Concept by then…

As you can see I have borrowed the main theme from Google Chrome e.g. where each open file is a tab and it’s possible to drag and drop tabs in and out of xade.

In my last post a lot of what xade is going to be was in flux. Since then I have nailed down some of issues:

1. I will make a painting/sketching application first as opposed to doing the voxel sculpting application. The primary reason behind this is minimizing risk. I guesstimate that a painting application only will take half the time compared to the sculpting application and at least 50% of the code from the painting application can be reused in the sculpting application.

2. The name Xade will be used as an umbrella name for my future company and my current idea is to name the individual products after renaissance artists (or the Turtles) like Xade Leonardo and Xade Michelangelo.

3. Even though Xade won’t be able to edit all 3D asset types it should still be able to display a whole host of file formats like all the major image and mesh formats.

4. I will focus on a minimalistic UI and the most important measure of the application is how good it feels to work with as opposed to the quantity of features.

Going up against Photoshop with a painting application might seem like complete suicide but the more I think about it, it feels like the right thing to do. In a future post I will talk about what I have in mind…

My philosophy on software:

1. No save button.
2. No latency or hiccups.
3. Focus the application on one specific task.
4. Focus on the beginner and the advanced user.
5. Predictability is more important then features.
6. Minimize chrome and use mostly different shades of gray.
7. Keep both the interface and implementation simple.
8. Make it beautiful but not distracting.
9. Satisfy only 90% of your users.

My philosophy on programming:

1. Fight code entropy.
2. Data structures, not algorithms, are central to programming.
3. All the data structures you need are:  arrays, linked lists, hash tables and simple trees.
4. If you come up with a solution that must be tweaked to get robust, start all over!
5. If the interface is clean, well documented and the module is small enough, the internals can look like shit.
6. A fast compile, start-up and shutdown time is essential to keeping programming fun.
7. Try to make all your bugs a loud deterministic crash.
8. Debug all your code, even if it seems to be working.
9. Unit and regression tests makes you sleep better.

(some of these rules should be taken with a grain of salt)

Maybe it’s better to do a concept-art drawing application before I do the voxel sculpting application.

Now this might seem like a crazy idea, but it actually has a lot going for it:

To succeed with a voxel sculpting application it is really important to nail the 3D painting aspect which should be similar to its 2D counterpart. Now, I have never done a painting program of any kind so to start with a 3D-painting/sculpting program might be a little risky. Therefore it might be better to first do a painting program for 2D (specifically designed for concept art) and then use what I learned to create the 3D-sculpting program.