How does Manifold::SetProperties and properties in general work?

[wrongbad]

I'm looking for a way to SetProperties all at once, rather than with a per-vert callback.

1. It looks like each triangle references 3 vert positions, and 3 property lists, yielding 3 callback calls?
2. Is it possible to have a lot of overlap iterating this way (Callback fn might be doing redundant work)?
3. Is it possible it's using all unique entries in the position and prop arrays?
4. Is is safe to assume number of prop-sets >= number of positions?

For batching, I'm see 2 decisions to make.

1. is whether to expand (duplicate) positions and props into aligned Nx3 and NxP matrices. OR to pass the Vx3 and Px3 arrays unmodified along with a Tx3x2 int array with indices into the first 2 arrays for each triangle point.
2. is whether to keep the callback style, or instead make it like GetProperties and SetProperties which return/accept the arrays directly. (This also applies to WarpBatch).

[elalish]

Yeah, doesn't look like I optimized that function very well. Partly this is because it's somewhat of a pain since the vert and property lists don't always line up. Regarding 4, I think it is possible to have fewer property verts than geometry verts, though I'm not sure that's how it should be. I'm open to ideas here.

I'd lean toward expanding the verts and props into aligned matrices. Especially if doing that internally makes it faster by reducing duplicate callbacks.

[wrongbad]

makes it faster by reducing duplicate callbacks.

Well you're also allocating new (bigger) arrays, so if the arrays are huge and the callback is cheap, it could go both ways.

The other thing that gets weird about duplicate callbacks, is the outputs get overwritten. If you share a property set for all verts of the triangle, but call it with each different position, only one of those will end up in the result properties slot. This is also true for expanded arrays, after the callback if you have to merge multiple expanded entries back to one slot and they differ, what do you do?

One advantage of doing it with original arrays + index pairs array is that the callback can perform its own optimizations, for example if it knows that the property transform is independent of vert position, it could choose to operate exclusively on the properties array, no expanding necessary.

[elalish]

If you share a property set for all verts of the triangle, but call it with each different position, only one of those will end up in the result properties slot.

Good point, I think that's the real nail in this whole same property on different verts thing. If we just disallow that, will it work decently well? In the common cases we care about, I think of verts with more than one property as being O(sqrt(n)), for n verts, basically like the number of new vertices in a Boolean op. Obviously it actually ranges all the way from zero to n, but these are the common cases for large n.

I'd prefer to keep the API simple, rather than foisting optimizations on our users, to the extent reasonable.

[wrongbad]

So would you suggest just throwing an exception if you call set_properties and multiple positions share a property?

I don't understand the use case enough, maybe that never happens in practice? I looked at MeshGL, and it looks like positions and props are forced to be aligned there, but I'm not sure if there are other ways to inject properties into a Manifold? Or maybe mergeToVert/mergeFromVert is a mechanism to combine positions but have multiple properties?

[elalish]

No, definitely no exceptions. I just mean whenever it happens in practice (probably just user input), we automatically duplicate things enough that our internal structures are always one vert to one or more properties, and not vice versa.