Rocklebobber is my first complete Processing application. The concept came to me as I was riding the train to visit a friend. All of the work was done in one sleepless evening on May 27, 2010, after eating a piece of toast. I wanted to use many of Processing's features, including classes, primitve drawing, transformations, mouse and keyboard functionality, screenshots, text drawing, and Scalable Vector Graphics shapes. This was my first time working with SVG files as well, the monster was drawn in Inkscape.
Rocklebobber is a Processing Monster, having greyscale colors and mouse reactivity. Rocklebobber is always hungry for trains, but is also shy, preferring the company of distant mountainscapes to other monsters. Use clicks of the mouse to guide Rocklebobber, but be careful of using the keyboard, Rocklebobber is terrified of keys.
My name is Bryan Blackford, computer game design major at UC Santa Cruz. Rocklebobber was created for Film 20C: Intro to digital media, taught by Lindsay Kelley (TA: Andrew Pascoe). Contact email: bblackfo at ucsc edu.
I decided to use a PShape and loadShape with an SVG (scalable vector graphics) file for my monster. I downloaded Inkscape, a free, open source, SVG editor, and made my first SVG.
Processing failed to load my first monster, giving an error about curves, probably caused by using a negative space in the face. Apparently SVG support in Processing is intentionally minimal. So I made my second monster, using simpler shapes.
which also gave an error:
parsed: M,114.28571,440.93361
unparsed: 78.804044,329.9904,192.62452,354.73398,114.28571,440.93361,z
processing.app.debug.RunnerException: RuntimeException: shape command not handled: 78.804044
In searching for solutions to my problems I came across some Processing source code: here
and by searching that source for the error messages, I figured out how Processing was parsing the SVG file and what tags were wrong. I did some looking into the SVG tag specifications here.
SVG is actually quite similar to html and xml. I began to make modifications to the SVG tags using emacs, and stripped down my monster to a single triangle that I could finally load into Processing (I actually wrote this sentence before actually getting a successful loadShape, let's see what murphy's law has to say about this: hah! worked!) Ug, so basically it looks like Inkscape writes SVG files in a format that Processing won't read. Inkscape is making path d="m1,1,2,4" for a path from (1,1) to (2,4) but Processing needs path d="m1,1,m2,4".
I can:
a) manually modify about 30 lines of SVG for this fairly simple monster
b) modify processing code to be able to load these SVG
c) write a converter program that fixes the svg
d) modify inkscape or make a script for inkscape that allows it to save svg files that processing can handle
option a will take a few minutes compared to hours or days for the other options, but i'll post this message to the Processing discourse forum. Actually the problem is more with Inkscape, by saving with ambiguous parameters. Maybe a Word macro can speed this up, I used to make macros in Visual Studio, I miss that functionality. Well, Word didn't open the svg file properly, even after changing it to a txt, but it turns out that my favourite text editor, emacs, does keyboard macros!
Inkscape has an XML editor that allows selection and modification of individual elements from the xml tree that comprises that file. Inkscape Plain SVG format for path should have L's at the start of coordinate value pairs after the first pair, with the same case (relative/absolute) as the case of the M on that first pair.
