A developer's personal site with WebGL, canvas, and CSS filter demos, including a JavaScript version of the Mona Lisa evolution experiment.
HN links it for the Mona Lisa image-evolution demo, which one commenter calls one of their favorite web things ever made.
i write an app like this about once a year (usually a java cmdline implementation).
to my embarrassment, i never got it completely right. the last instalment even provided statistics that could be used to compare the effectiveness of different strategies and parameters.
the last recent one featured:
* classic genetic algorithm (population size etc) with different methods for selection and crossover
* dumb hill climbing
* the "additive" method described in OP's app
* switching of methods at certain points (i.e. switch to hill climbing if the genetic algorithm didn't improve things for a certain time)
* bitmap and svg output
* statistics output that can be plotted with a plotting library so you can compare the effectiveness of different strategies
* multithreading incl. tests to find out the sweet spot for the number of concurrent threads
~~~
i don't know why but i never really reached the point where my results were of a comparable quality to roger alsings mona lisa or even alteredQualia's image evolver (http://alteredqualia.com/visualization/evolve/).
well, soon it's time for the next attempt.
one interesting realisation: my desktop computer is about 10x as fast as the raspberry pi 3 for this kind of CPU intensive work.
Agreed, canvas works well now, but WebGL is younger than canvas, and this gives a hint at what WebGL will look like tomorrow.
What's more today the first cause of WebGL not working lies more in the graphics card periphery. OpenGL drivers on Windows are often an aftertought given DirectX prevalence, and on Linux some drivers are simply unstable with 3D acceleration, regardless of WebGL. Besides, short of software fallbacks like llvm-pipe or OSX, you can't invent features not supported by the card. Onve overriden[2] WebGL actually works[0][1] well on my embedded HD2000, but bugs in the driver make the whole thing randomly unstable, hence it is blacklisted by browsers (chrome://gpu even lists and links to bug reports, and lists Flash Stage3D as blacklisted too).
As for number counting, while the number of people running into WebGL problems exists, it has been drastically reduced since a year ago, when the number of people running into Flash problems for years, and is not shrinking.
ALso, there's not just graphics on X-Type, but correctly timed HTML5 audio too.
[0]: http://madebyevan.com/webgl-water/
[1]: http://alteredqualia.com/three/examples/webgl_cars.html
[2]: "Override software rendering list" in chrome://flags
> I see you take the two most fittest as is, maybe this could be useful for picking the second one?
Yep, we take the two most fittest unchanged, and breed the rest randomly along a non-uniform distribution tending towards the top.
> Also, when the Mona Lisa thing was posted on HN, someone suggested marking areas of the target image as "more important", to maybe make facial features etc. more recognizable.
This is a really good idea and would definitely make a difference. In my penguin example, with too few polys, sometimes we reach a local maxima before the eyes (small details) look any good. I combatted this somewhat by encouraging new polys to be (a) small and (b) regular. But I like the idea of a more guided approach.
There's an awesome javascript example you might find helpful: http://alteredqualia.com/visualization/evolve/
Edit: Your images look amazing. How do you make the vector shapes?
It depends I think. There isn't any built-in reason why WebGL code would drain batteries faster then a similar native-code demo. WebGL has to do a bit more validation on the CPU which may contribute a bit. But other then that most demos should be very light on the CPU side, so the difference between JS and native code wouldn't be an issue. However, many WebGL demos move a lot of work to the GPU (especially the shadertoy demos, which render the entire scene in a single fullscreen quad and have absurdly complex pixel shaders), epecially in fullscreen mode these would suck your battery dry very quickly.
On my fairly old MBP, all fullscreen 3D apps (also native games) kick the fan into high gear immediately and the bottom gets warm very quickly, while most "reasonable" WebGL demos don't have this effect (e.g. some of the lighter ones from here: http://alteredqualia.com/)
Here is a pie chart with the current data from the poll:
http://chart.apis.google.com/chart?chs=350x170&chd=t:193,29,38,29,14,4,31&cht=p&chl=USA|North%20America|Europe|Asia|South%20America|Africa|Oceania&chf=bg,s,FFFFFF00
Or if you want to see realtime data, you can use following bookmarklet to embed chart directly into this page:
----
javascript:function loadScript(scriptURL){var s=document.createElement('SCRIPT');s.setAttribute('language','JavaScript'); s.setAttribute('src',scriptURL);document.body.appendChild(s);}loadScript('http://alteredqualia.com/visualization/hn/hn_poll_graph.js');
----
Pygame is very fun to work with and it's so easy. I stopped using it for game development (switched to web-based HTML5 stuff) but it is still an amazing wrapper over SDL. I recently used it to write a quick version of an image evolver. (an example of what I'm talking about: http://alteredqualia.com/visualization/evolve/)
If I ever want to bust out a quick graphical/audio application I use Pygame.