PShape.getVertexCount() always outputs 0

[dtplsongithub]

Most appropriate sub-area of Processing 4?

Core/Environment/Rendering

Processing version

4.3.1

Operating system

Windows 11 (24H2)

Steps to reproduce this

PShape.getVertexCount() always seems to output 0. (tried 1 .svg file and 4 .obj files, even included the .mtl files)

snippet

PShape shape;
  
void setup() {
  size(640, 360, P3D);
    
  shape = loadShape("cuboctahedron.obj");
  println(shape.getVertexCount()); // zero???
}

void draw() {
  background(0);
  lights();
  translate(width/2, height/2, -200);
  scale(50);
  rotateY((float)millis()/2000);
  shape(shape);
}

Additional context

No response

[hx2A]

@dtplsongithub , can you check if your shape is a group shape?

I just tested this on the Processing example "LoadDisplayOBJ", which shows a rotating rocket. The vertex count was zero but I could use the below code to get the vertices for the object's children:

  rocket = loadShape("rocket.obj");
  println(rocket.getVertexCount());
  int count = 0;
  for (PShape shape : rocket.getChildren()) {
    count += shape.getVertexCount();
  }
  println(count);

The output is:

0
1101

I would argue that a call to getVertexCount() on a group shape should return the total vertex count of its children, and that all renderers (JAVA2D, P2D, P3D) should behave in a similar fashion for loaded shapes.

[dtplsongithub]

the code you provided me works, i guess i was using the method wrong...

[hx2A]

the code you provided me works, i guess i was using the method wrong...

No, I think the code you originally wrote should work. getVertexCount() is confusing if it returns zero for group shapes. Also, consider that the 1101 vertex count of my example could also be wrong. What if the group shape contains a mixture of mesh shapes and other group shapes? Group shapes can be nested. Some of the calls to getVertexCount() for the shape's children could also be zero. The 1101 value could be an under-count of the correct number.

Let's keep this open so we can use this as an opportunity to improve Processing. It would likely be an easy PR, so I'll add some tags so a first-time contributor can fix it.

[hx2A]

And @dtplsongithub , if you, or anyone else reading this would like some help working through the PR, I'm available to assist!

[Stefterv]

Adding a warning message, that groups are ignored in the count would also be helpful. Maybe even a countGroups = false parameter.

[micycle1]

@hx2A
I think the PShape data structure is due an overhaul (perhaps one for Processing 5😄).
Beyond the confusion you raise, one even bigger problem is how holes are encoded. Vertices of holes are not directly accessible and must be computed from the PShape's vertex codes using some fairly involved logic.

For 2D shapes the best approach would be follow the model described by Well-known text representation for geometries.

[hx2A]

@hx2A I think the PShape data structure is due an overhaul (perhaps one for Processing 5😄). Beyond the confusion you raise, one even bigger problem is how holes are encoded. Vertices of holes are not directly accessible and must be computed from the PShape's vertex codes using some fairly involved logic.

For 2D shapes the best approach would be follow the model described by Well-known text representation for geometries.

Well, much of PShape isn't that accessible. It's very much a custom data structure that has evolved over time to work well with Processing.

Overhauling PShape would probably need to wait for #881 as PShapeOpenGL is fairly complex and nobody should touch it if it is going to go away eventually.

I like the idea of using WKT for 2D geometry. There is a Java library called JTS that Processing could incorporate or at least learn from, and I believe it uses WKT. This library is closely related to GEOS, which is used by the Python library shapely.

[micycle1]

I like the idea of using WKT for 2D geometry. There is a Java library called JTS that Processing could incorporate or at least learn from, and I believe it uses WKT. This library is closely related to GEOS, which is used by the Python library shapely.

It was within JTS that I came across that format!
I use JTS extensively in my geometry library for Processing and have routines for converting between PShapes and JTS geometries (if you're curious see here). It was also through this exercise that I came across the poor design of PShape as a geometry data structure (notable issues are holes and affine transformations -- the effects of scale() etc that still aren't publicly accessible!).

[hx2A]

Hmmm, if PShape was more closely aligned with JTS, there are a lot of nice computational geometry features we could add to Processing.