What's the status of this project?

[mcanthony]

This is one of the first of 25,000 projects I have given review since starting my Github journey and somehow I keep coming back to it. I think its a major reason I started getting into graphics and generative art, it is just so cool.

I have some simple ideas for enhancements such as an improved model browser that allows the user to create duplicate instanced of existing models (internal "forks") as well as saving new models to local storage/remotely. I would use a convenient inertia type scrolling interface much like a photo slider would have. I would make it re-sizable from the bottom of the screen upward to allow the user to browse a single row, or multiple.

I would like to take advantage of WebGL typed arrays, and perhaps store the generated data as pre-computed PNG encoded images to achieve fast loading and loss-less compression. It takes a bit for each model to load, I am assuming you are doing a lot of number crunching before it becomes interactive. I would then like to leverage web-workers or perhaps even WebCL to allow for parallelization and efficient computation. Any thoughts about this?

To take this app to the next level I would like to add a mode for the rendering to produce vector paths in place or alongside the rasterized visualization, perhaps with an adjustable level of detail. Then allow for this path information to be exported and animated outside of the app for the web or even within a 3D app or AfterEffects.

And finally I would love to add a nice timeline with basic automation, allowing the user to automate the parameters over time, as well as enacting filters/effects, colorization, physics...... oh my. Oh ya and lets throw a couple Joystick controls on the left and right bottom of the screen for easy and smooth manipulation (which it looks like you at least started to do). Some convenient sliders with a number-editor type scrubbing control might be nice.

Does any of this sound interesting to you? I would not want to pester you about this project if you don't really have any further interest in it. If you do, great, it would inspire and motivate me to know your thoughts and insights into any of the above mentioned ideas.

Please note that I do not expect you to do any of the work, and I fully intend to implement these features myself hopefully with your insights along the way.

Anyway, great work, this is an amazing tool that more people should know about and use. I think it would be a big hit with just a few more usability tweaks, and even bigger hit if we allowed for even basic export abilities. Would be K-RAD to

[benvan]

Hi Michael,

Thank you so much for your interest, and highly detailed thoughts! I'm so glad you've enjoyed what's there already - and you're right, it's been left in limbo for quite a while. I planned a UI / simplicity overhaul but my focus on this project eventually waned. However... your message comes at a very good time. By the end of August I should have an awful lot more free time and I'd be very interested in collaborating with you on some of your thoughts above.

It would be worth me addressing a few specific points:

• Regarding 'forks' - I had originally planned user-submissions, ratings etc (keep systems in one place), but dropped it in favour of anonymous url-based systems. I don't think this has been at all clear, since the vast majority of links to the lsys site have been without a system in the url (or an accidental mo. A more obvious way of "creating" or saving a system would be good. Bear in mind "storage" is just a link! All the parameters of a system are encoded in the url. It's also completely non-obvious that you can name your system by typing in the name field at the top
• WebGL arrays - I never looked into this as an optimisation, but well worth investigating. My focus was on rendering the resulting system as quickly as possible, with less concern for how long it takes to compile the system. Definitely lots of room for improvement.
• PNG-encoded systems - I love this. Superb.
• Web workers - I investigated this, originally, and the time it took to transfer the resulting system back outweighed the benefit of offloading the computation. I do, however, think there may be smarter representations of the compiled systems that might make web-workers pay off. Right now, it's an uncompressed string of character instructions.
• On compiled representations - I considered a whole bunch of optimisations for the compiled systems, mostly around removing redundancy (e.g. FFFF -> F(of length 4), or deleting sequences of (+-), but I eventually decided that in the general case the benefits were too small to be worth pursuit.
• WebCL - I never tried this. Would be very interested to see the results.
• Extensions - One thing I played with but never pushed was colour. This makes a huge difference, and some of the most boring systems become really beautiful with an emergent gradient. It took a while to find a way to do coloured systems efficiently, mostly because it nullifies the greatest optimisation in the rendering cycle which is to draw as much in one path as possible before stroke. Calling stroke() every time the system transitions to a new colour causes a massive drop in rendering speed. However, I eventually tried layering the renders, such that a layer was created for each colour, and a colour transition would do nothing but point to the appropriate layer when drawing lines. This worked really well until chrome released an update that brought the performance right back down again, at which point my focus waned. I ought to have the commits somewhere, I'll see if I can dig them out and push to a branch.
• Exports - makes sense. I was wondering what somebody might want to do with these systems, and I'm still not really sure. I'd thought of them a little like desk-toys, but not much more.
• Physics - I wanted to do this so much... Never got round to it. We should try this. My gut feel is that it's going to be extremely computationally intensive. LSystem-in-the-wind has a nice ring to it.
• Tweening - Absolutely. This could work really well on mobile - dragging with momentum could be quite pleasing.
• On the topic of mobile.. I would really like to make a mobile friendly site, and fix the mobile performance issues.
• Joysticks / controls - yes - this is clearly an issue :). I built JStick and JStick-UI specifically for this project (after realising many other projects I've worked on could do with such a control). Regardless, the controls definitely need improving.
• Final thoughts.. If the site were to have more mass appeal, I think the UX needs huge improvement. I don't have any analytics, but I get the feeling most people won't realise they can
  a) create their own systems
  b) share those systems
  c) see a tutorial on how everything works (the tiny question mark at the top)
  d) alt-click to modify size growth

Once again, thank you so much for getting in touch, I'd be delighted to work with you on this.

Cheers
Ben

[benvan]

By the way - I've just pushed the 'color' branch, Chrome issues seem to be fixed. Try dropping \1 \2 etc into a system. The colours are currently hard-coded, \0 is white. (Also fixes retina issues)

[mcanthony]

Hey I just wanted to take the time and pop in for second to let you know I am still alive and have been thinking ALOT, and wrote up a nice spec with some more developed ideas. Of course my laptop stopped turning on a couple weeks back so I have not the spec handy. Later on perhaps tonight I will try to throw out some of the thoughts I had from memory, and I am thinking it might be quicker/easier to understand if I draw a quick sketch (in lue of a real mockup which I may just do because I cannot draw).

I think an offline-first, mobine-first approach is appropriate of course, and the UI will be very barebones yet sexy. The controls themselves would make most of the UI - which I will explain later, I think you will dig the concept. Kinetically scrolling wheels that you can fling with ever-increasing momentum then stop and fine tune ---- TBC

Someone on codepen adapted the core lsys library to WebGL 3D rendering context, is this something you already have seen? I haven't looked at his code but I figure it may be a least somewhat helpful in the next steps torward 3D capability (though I quite like the 2D look).

After I manage to built out the new UI we will think up how we can allow for a simple export of GIF or embeddable widget that people can put on their site with automated params/easing and optional user control. Like a mini-lsys. The next step where it would get really fun is filter/shader effects to add some gloss or git to the rendering.

Speaking of which I have been doing quite a lot of research and analysts into GLSL shaders and while WebCL may be interesting in the future when it come to more advanced simulations/additional entities/particle effects/generative system mixins (let's basically just throw all of toxiclibs.js in there) it is likely overkill at the moment and GLSL would be far more portable and appropriate for mobile. The system's factorization/iteration can also take place on the GPU with GLSL so I expect a ridiculous speedup in computation and rendering, leaving the CPU almost out of the equation completely.

I had put quite a but of testing/research into the URL sharing method and came up with something I think will be appropriate, which would basically involve binary serialization of the parameters, followed by the systems name/author/definition string (the name and author would be defaulted from comments placed atop the systems definition). The params+system serialized data would then be further compressed using the lz-string compression algorithm (which worked in under 1ms) where it would then be presented in URL-safe base64 encoded form. This should make for a nice compact sharable URL system (I am really picky about my URL's I guess).

To prevent constant serialization/compression and browser history updating, the URL would be updated when user interaction has stopped and the application is not actively processing anymore. This would be accomplished using the forthcoming requestIdleCallback API via a polyfill.