Harmony.codea - a procedural drawing tool

Being forced in bed due to fever, today I achieved something I had in mind since the first days I started to play with Codea: a porting on this environment of the Harmony Project developed by mrdoob. (http://mrdoob.com/projects/harmony/)

If someone is interested the code can be find at: https://github.com/Shrike78/HarmonyCodea

I had in mind to make a short video but there’s something that’s not working properly whit the video while I’m drawing, is like commands are working upside down or I don’t know…,

Anyway, Almost all the procedural brushes (except 2) are already there, and there’s also an add-on brush taken from another extension of harmony I was working on for web.

The real missing feature is that is not possible to save the drawings once made… maybe in a future :slight_smile:

NB:
For the Toolbox interface I started from the code developed by @Grant in his brush project (http://twolivesleft.com/Codea/Talk/discussion/comment/5649#Comment_5649).

@Grant please let me know if and how do you like to be mentioned in the project!

WOW! That is the coolest project I have seen in a while!

Impressive! I looked for a similar project. (*)

Let’s see if this works:

Codea in Harmony

I modified the user interface to use my UI with the aim of making it full-screen. The dot in the top right corner is the current brush size and colour - not sure how best to show that. In the screenshot, the UI is hiding.

@shrike sure thing you can just reference me at grant@enabled.com.au

Glad my simple work helped out.

Sorry @Andrew_Stacey, I haven’t exactly understood what you mean: when you hide the interface, are you overwriting it with a white rectangle or whatever? Because having a RETAINED backing mode I havent’ found any better solution than this one, that is not a so good solution anyway because the UI space would be wasted and would result in the final screenshot as empty space.

I’ve just tried to make the brushes draw on an image instead that directly on the screen using setContext, so to allow me to show / hide how many interfaces I’d like working with a standard backing mode, and it works… but it’s terribly slow, not usefull for drawing purpose…

The best would be if codea would allow to copy back data from screen buffer to an image.

I changed the drawing method to draw on a canvas image and didn’t notice any decrease in drawing speed. That meant that I could show and hide the UI at will. I’ll throw in some frame rate code to see what refresh rate I’m getting and report back.

Well, that’s exactly what I’d like to do but maybe I did it in the wrong way :confused:
I’ve just spent a while but I fear I was in the wrong direction. Can you share it?

Can you create a undo button. :smiley:

On the next update plez :smiley:

Oooh, while I’m actually drawing then the frame rate shoots down to 15fps. However, when not actually drawing then it’s a full 60fps. I’m not sure what of that 15fps is due to drawing on the canvas and what is due to the calculations it does.

Hmm, even get 15fps with the “Simple” brush.

Okay, I’ve published my modifications. You need to get my library project as well and import it via project import. They are both bzr repositories.

Well, thanks, I’ll give it a try!

Btw, with the original code the fps goes under 50 fps only with the brushes that implements the neighbour points connection concept (so sketchy, shaded, web, chrome, ecc.) when the number of points increase significantly.

Anyway, at the end I succeded on drawing on a context image at more than 20 fps.

At the first try I’ve put the setContext(canvas) / setContext() block in the touched function and that has destroyed the performances.

Now I’ve substituted the touched function with another one called by the draw method with CurrentTouch as parameter. The setContext(canvas) is at the begin of draw(), and the setContext() agin in the draw method before to draw the canvas and the toolbox.

The canvas is a texture bind to a mesh with one rect that cover the whole screen.

The only problem now is that the toolbox that is drawn after the mesh displays wrongly,
I don’t know why, and my iPad is in charge now… :confused: I’ll see later :slight_smile:

Well, now it works exactly as I wanted, with the right behaviour of the toolbox that can be hiddden when unwanted (like to take a screenshot). tThe next thing will be to add save / load functionalities!

But I had to fight with two unexpected behaviour of codea:

1- If I’m not doing something wrong, the CurrentTouch has always the same id, that is 0. And anyway the CurrentTouch works in a way that is not completly clear to me…

2- there’s something strange about mesh and rendering since this new version. Before I did some tries with the mesh and the tool box drawn just as now and at some point the rendering was not correct (uff, I had to take an image…) and after that even fixing the code I was never able to have the correct rendering back. The only way was to close and reopen Codea.

On GitHub I’ve updated the code with the possibility to enable the redirection of the draw on a canvas image, and so also with the possibility to hide the palette UI.

On iPad 2 the performances are not so great because it runs at ~24 fps instead of ~55 and that means less precision while drawing. If someone can try it on an iPad 3 it would be interesting to have some infos about performances.

I now have a version wherethe drawing itself is a mesh, and I get good frame rates for that: up in the 40s and 50s after lots of drawing.

Never know how to embed these: http://www.youtube.com/watch?v=XCPImHbZziA&sns=em

The displayed fps is a bit low due to videoing. Also there’s a freeze for a bit due to a bug in the code.

Well @Andrew_Stacey, that was a great idea! The only drawback is the loss of brushes like discs (that I love) and circles (that I totally dislike, so I don’t feel the missing :))

I’ve just put on GitHub a parallel version of HarmonyCodea that implements itself the mesh drawing and the results are really good.

Looking at your video I also like a lot your UI components: your Harmony codea version now is very similar to a custom html5 version I’ve developed last year, with floating menu ecc.

I have to give a deep look to your codea library, it seems to be really interesting and full of resources!

Hi @Grant, I’ve put a reference to you in the project and I’ve also added a “Grant” brush, that is an integration in HarmonyCodea of your original brush.

Mmm obviously the solution for having all the brushes also with the mesh version would be to implement ellipse drawing over meshes… It could be interesting to try.

I’ve pushed my latest changes to my code repositories.

Mmm obviously the solution for having all the brushes also with the mesh version would be to implement ellipse drawing over meshes… It could be interesting to try.

Yes, I’d come to that conclusion as well.

(I’m having a lot of fun with this project - it’s a great idea.)

Oh, and a minor change I made that you might want to think about was to make more use of vec2 objects. Since meshes can take vec2s for vertices, and you do quite a lot of vector-like computations (distances and so forth), it makes sense to use the inbuilt routines for this than re-implement them in lua.

Forgot to update the files (pushing the repository from a remote machine updates the repository but doesn’t fix the files in the actual directory). Also, the colour wheel now has an alpha slider.