When working with Processing as a Java framework it is sometimes frustrating that the core classes are so good at hiding their internal fields. I realize that this is good programming practice and that these fields might just be confusing to beginners who aren't familiar with the details of OOP programming.

An example: I am currently writing an application where I need to extract shape details from a SVG file. PShape reads the file just fine, but I can't get access to the vertices and shape codes I need to recreate the paths in a different form.

Since I'm working in Eclipse I can easily just go into processing.core.PShape and make all the fields public. But it doesn't seem logical to me that I have to do such a kludgy hack, when there are plenty of legitimate reasons why one might want access to the internal fields of PShape.

Any thoughts?

Hi,

most fileds in PShape are protected. That means, they are accessible to classes that extend PShape. So if you would restructure your programm in a way that your own Shape class extends PShapeSVG, you could probably access the fields you need without hacking the lib.

hey looking at the source, I found this comment by Fry:

"For the time being, this class and its shape() and loadShape() friends in
PApplet exist as placeholders for more exciting things to come. If you'd
like to work with this class, make a subclass (see how PShapeSVG works)
and you can play with its internal methods all you like."

here an example:

Code:

import processing.core.PApplet;
import processing.core.PShapeSVG;

public class ShapeTest extends PApplet {
    MyShape myShape;
    
    public void setup() {
        myShape = new MyShape(this, "test.svg");
        // now you can access protected fileds
        println(myShape.getVertexCount()); 
    }
    
    public void draw() {
        background(0);
        shape(myShape, 0, 0);
    }
}

// MyShape helper class extends PShapeSVG
class MyShape extends PShapeSVG {
    
    MyShape(PApplet parent, String filename) {
        super(parent, filename);
    }
    
    // add your own PUBLIC getter ans setter methods 
    // to access protected fields
    public int getVertexCount() {        
        return vertexCount; // vertexCount is protected in PShapeSVG
    }

}

 

Hi,

I would like to know if you have tried using Geomerative, since this is the kind of use cases I have made it for.
If so and you are unsatisfied, could you please tell me the reason? I will try to fix it.

This is how you would access vertices:

RG.init(this);
RShape shp = RG.loadShape("myDrawing.svg");
RPoint[] vertices = shp.getPoints();

And you would even have different ways where the vertices on the shape will be evaluated: separated uniformly, adaptatively or at a uniform advancement (using RG.setPolygonizer() and others).

Hope it can help
ricard

EDIT: fix the name of the method to change the place where vertices are evaluated.

Yep, I understand you.   I don't like either to be too dependent on libraries in case they break with Processing updates.  I can tell you however, that with the new version of Geomerative at http://www.ricardmarxer.com/geomerative I have been very active in maintaining it up to date with Processing and any bugs have been usually fixed in a matter of days.  I hope I can keep up like that.

About the issue of shapes with holes, this was one of my main goals of Geomerative since in typography shapes this is very common.  So yes, Geomerative supports rendering correctly shapes with holes.

It uses the breakShape() undocumented command of Processing in the backends that support it (JAVA2D and PDF) and it uses an internal software based tesselator for backends that don't support breakShape() (OPENGL, P3D, etc...).

So for the user it is transparent, you can create shapes using a very similar syntax as in Processing:
Code:

RG.beginShape();
RG.vertex();
RG.bezierVertex();

// and even to have several paths to form a shape (e.g. holes)
RG.breakShape();
// or
RG.breakShape(CLOSE);

RG.endShape();
// or
RShape shp = RG.getShape()
 

You just have to keep in mind that holes must be counter clockwise.

When you load SVG or TTF the holes in the shapes are respected.
There are quite a few Tutorial sketches with Geomerative that shows all this.  Let me know if any of it is not clear or if there are any bugs so that I can fix them.

ricard

Ricard, I've posted a followup thread about Geomerative here to not confuse this thread further:

http://processing.org/discourse/yabb2/num_1247007952.html#0

Thanks again for suggesting your library!