Refactor Geometry and GeometryPart to share common functionality and improve multipart rendering #9313

Increasing access

This would improve the reliability and consistency of WebGL geometry handling, particularly for models with multiple materials. By reducing duplicated logic and improving how individual geometry parts are rendered, it would make working with complex 3D models more predictable for p5.js users.

It would also make the underlying geometry code easier for contributors to understand, maintain, and extend.

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• WebGL
• Build process
• Unit testing
• Internationalization
• Friendly errors
• Other (specify if possible)

Feature enhancement details

Summary

Currently, Geometry and GeometryPart are separate classes that duplicate several properties, including vertices, faces, UVs, vertex normals, vertex tangents, vertex colors, and custom vertex attributes.

While Geometry can contain multiple GeometryPart objects for handling different materials, much of their underlying geometry data and functionality overlaps.

Following the discussion with @davepagurek in #9304, I think it would be useful to refactor this structure to reduce duplication and make multipart geometry handling more consistent.

Current issues

1. Duplicated geometry state and functionality

Both Geometry and GeometryPart maintain similar geometry properties, but GeometryPart does not inherit the geometry operations implemented in Geometry.

This makes it harder to reuse common functionality across top-level geometries and individual material parts.

2. Renderer gating depends on the top-level geometry

Currently, the renderer checks the top-level geometry's vertex count before drawing its parts.

This means that if the top-level geometry has no vertices but its individual parts contain valid geometry, the parts may be skipped.

Since the renderer draws individual parts, the vertex-count check should happen at the part level.

3. Edges are stored only on the top-level geometry

Unlike vertices, faces, UVs, and normals, edge data currently exists only on the top-level Geometry.

This can create limitations for multipart geometry where the required vertices are stored in individual parts rather than the parent geometry.

Edge and stroke handling should be reviewed so multipart geometries can be rendered correctly without depending on all edge vertices being present in the top-level geometry.

Proposed approach

1. Refactor GeometryPart into a shared base class

Move common geometry properties and appropriate geometry operations into GeometryPart, then make Geometry extend GeometryPart.

Geometry would retain responsibilities specific to complete geometry objects, such as managing the parts array and its constructor callback.

This should reduce duplication while making common operations available to both classes.

2. Move renderer gating inside the parts loop

Instead of checking the parent geometry's vertex count before rendering parts, check each individual part's vertex count inside the rendering loop.

This would allow each valid part to be rendered independently.

3. Improve edge and stroke handling

Investigate how edge data should be represented and processed for multipart geometry.

Update the relevant geometry and renderer paths to support edges associated with individual parts while preserving existing stroke behavior.

4. Preserve existing behavior

The refactor should preserve compatibility with:

• Existing p5.Geometry construction and methods.
• Single-part geometry where geometry.parts[0] === geometry.
• Multi-material geometry from OBJ loading and buildGeometry().
• Existing fill, stroke, and material rendering.
• Custom vertex attributes and renderer buffer updates.

Appropriate regression tests should be added for single-part and multipart geometry.

Related issue

This refactor was identified while investigating inconsistent UV representations and multipart UV transformations in #9304.

A cleaner relationship between Geometry and GeometryPart should make those UV fixes easier to implement and maintain.

The UV normalization and flipping changes can be addressed as a follow-up or included in the same PR if the additional changes are sufficiently small and closely related.