V3: revisit using 'properties' to maintain colors, etc. on geometries

[z3dev]

V1 has a concept of 'shared' (poorly named) to maintain properties for shapes. this was a simple anonymous object. If V3 wants to continue to support various properties like colors, names, ids, etc then this may be a better solution.

[hrgdavor]

We should look at this also from the perspective of vtree. What minimal information we must share to be able to reconstruct a geometry after transfer. Nice benefit would be a sort of file format for exporting jscad vtree to a file (like we have for json export).

{
  "id":1,
  "type":"sphere",
  "params": {
    "size": 5,
  },
  "transform":[],
  "color":[]
}

or

{
  "geometry":{
    "type":"sphere",
    "id":1,
    "params": {
      "size": 5,
    },
  },
  "props":{
    "transform":[],
    "color":[]
  }
}

Also we must finally introduce a concept of fidelity (segments) that is global versus one specific for a geometry. There are cases when we really want a sphere or cylinder, but others when we actually want a cylinder with specific number of segments (hex nut).

A sphere is not just a sphere if you predetermine the fidelity (fixed number of segments regardless of model fidelity), because you want that specific shape actually and not a smooth sphere.

There are plenty of types of triangulation of a sphere, and we should support them clearly. https://www.danielsieger.com/blog/2021/03/27/generating-spheres.html

The UV Sphere

The Icosphere

The Quad Sphere

Goldberg Polyhedra

probably some more, my knowledge here is bit limited.

[hrgdavor]

A side-note. Now that we have immutability for geometries, it will be silly to keep generating a new sphere for each size when:

• a sphere:size:5 + scale:1 can easily be sphere:size:1 + scale:5
• a sphere:size:3 + scale:1 can easily be sphere:size:1 + scale:3
• ....
• also a cube:size:3 + scale:1 can easily be cube:size:1 + scale:3

this would instantly improve rendering performance with many copies because of instancing.