One of the sad things about using the OpenGL rendering option in Processing is the lack of control over line weights, caps and joins. This week I allowed myself to get distracted by this issue for a little bit too long, but I did succeed in solving it, at last:
I've put some code about line caps and joins in Processing & OpenGL up on Processing Hacks in case it's something that bothers you too. I've not tested it extensively so I'd welcome bug fixes and suggestions there, or in the comments here. One thing I'm interested in doing next is extending (or reimplementing) BasicStroke to generate shapes for thick polylines with varying line thickness. If that's something you've done before, please let me know.
I'm using Java's BasicStroke to generate the path outlines, and GLU's tesselators to generate a mesh that will fill correctly in OpenGL. I "borrowed" the code for the latter from Ben Fry's PGraphicsOpenGL font rendering – thanks Ben!
In the spirit of continuing our impromptu database week on Processing Blogs (my post, toxi's post, then Florian Jennet updating the sql library), I thought I'd post another quick example using Lucene.
Last week Ryan and I needed a reliable way to search inside a data set we were working with. I had previously tried and failed to write my own useful search routine for the same data, so I wanted to take a look at Lucene instead. (This week, I might have used SQLite, but I hadn't tried it last week!).
Lucene isn't a relational database like MySQL or SQLite, although it has a few similarities with the way most database engines speed up queries using indexes. That's because Lucene is "just" the indexing part. You tell Lucene about your data, one part at a time, and then construct queries to ask it which parts of your data match the query. The key thing is that you keep hold of your data yourself and structure it any way you like, Lucene keeps its own representation of the data for searching. Because of this it can index much more data than you can store in memory.
Anyway, I put up an simple example Lucene applet here that indexes the text of Time Machine by H.G. Wells from Project Gutenberg and lets you type queries against it. The text itself and the Lucene index it builds are both quite small (tens of KB, compressed), but the applet is around 750KB. This is because Lucene's core jar file is about 500KB so it's more suited to standalone projects and applications.
The code is kind of documented, but Lucene was really too much for me to understand properly in just one day. Nevertheless, again, I hope people find it useful!
SQLite is a great standalone SQL database engine - not ideal for every situation (particularly large websites), but more than good enough to have already made its way into desktop projects from Apple, and more recently Adobe and Google.
My colleague Mike recently used it as a way to distribute data from a 511.org transit website scraping project he's been doing. I wanted to see if I could download his data (gathered and processed using python) and access it using Processing.
Web searches for SQLite and Java (java wrapper sqlite, etc.) turn up lots of matches, including this promising tutorial from Tim Anderson, but sadly the most prominent matches didn't work for me. It's a real pain to get up and running and installed in a reliable way, mainly due to the need to compile SQLite natively for each platform and then talk to the native code using Java.
Enter this amazing project, a JDBC library for SQLite written in pure java that uses NestedVM to compile the C code for SQLite into something any Java VM can use. It's frightening to think about the amount of misdirection, abstraction and interpretation going on here, but it worked first time and plenty fast enough for my purposes.
Take a look after the jump for the code I ended up with. I hope people find it useful:
© Random Etc.. Powered by WordPress using the DePo Skinny Theme.