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!
Sadly (due to my neglect as sys-admin) processinghacks.com hasn't been accepting new edits/users since I moved hosts a few months ago. I finally got around to fixing it today, so everything should be working now.
The site hasn't quite reached the ambitious heights I had in mind for it when toxi and I first put the wiki together and drafted the contents. Some of the hack suggestions are out of date now, and many of the existing hacks don't work with the latest release yet. That said, I hope to put some time towards kicking it into shape over the upcoming weeks and I'd be delighted if you'd join me.
I should also mention that there's a good incentive to get your hacks written up, because we're planning to move Processing Hacks to processing.org - you might have seen a note about that in the Learning section. Fame and fortune (or at least some geeky glory) await!
Processing Hacks is progressing nicely. Toxi made a few updates this week, so we have better Processing source code highlighting (and links to the official reference) as well as the ability to post applets. We've moved the contents off the front page, and you can also generate an index to see what articles actually exist right now.
I've just added Chris O'Shea aka Pixelsumo's Processing category to Processing Blogs, as well as Ricard Marxer's fantastic Caligraft sketchbook. As always, if you're posting regularly about Processing or closely related topics, let me know and I'll add you as soon as I can.
I'll be talking about some of my recent Processing work including Processing hacks and the travel time tube map at dorkbotlondon tonight. It's a Brick Lane one, so no excuses!
This week toxi and I went live with Processing hacks, a wiki for documenting some of the more tricky, technical things that can be done with Processing.
I hope to chip away at the draft table of contents with an article or two a week until it's done. My first new code for the site is a basic Processing library for manipulating GPS data from GPX files. There are bound to be bugs and niggles, if you have a GPX file you could try it out with I'd be really grateful.
Here's an example app showing a friend's recent travels. Excuse the file name, as you can see the data is quite noisy and it needs some cleaning up. Also note that the Arcball class isn't quite working right (it needs fixing up for newer Processing versions), but it helps give you an idea of what's going on.
Back to our regular scheduled programming.
I've just been experimenting with a couple of implementations of 3D picking for simple scenes composed of triangles.
Picking with buffer is really simple, and can be pixel-accurate (but isn't in this case because I reduced the picking resolution for speed reasons). It requires you to draw your scene twice... once as you normally would, and once to an offscreen buffer using the triangle index as the fill colour. You then look at the colour of the object under mouseX/Y in the buffer to get the index of the picked object. It's a bit slow, but it works accurately even in this random-triangle scene.
Picking with projection projects all the triangles to screen space, depth sorts them, and checks if any of the projected triangles contains the mouse point. It's not 100% accurate, but for scenes without intersecting triangles it will be fine, and it's faster than the buffer-based method.
There are much faster methods if you're dealing with more geometry, but either of these methods should be fine for simple scenes. On the Processing board, cello points out this great tutorial for doing the same things in OpenGL. Marquee selection would be a simple extension of the pixel buffer method, and a ray-based tutorial is in the works (stay tuned).
It's worth noting that the back-buffer method documented there works for P3D (so no need to create another graphics object) but that in OpenGL the get(mouseX,mouseY) method doesn't work in the same way yet, so it requires different code (example here).
Apologies for delay with raycasting example. If anyone else wants to do it, please feel free and I'll link to it from here. Otherwise, don't hold your breath!
© Random Etc.. Powered by WordPress using the DePo Skinny Theme.