SceneUtils: Add reduceVertices().

[elalish]

I wrote this some time ago to support model-viewer's automatic camera framing (which is tight without allowing the object to leave the frame for any orbit parameters with constant zoom). I always thought it might be a useful generic method for three.js, so I figured I'd contribute it and see if anyone agrees it might be useful to others.

[marcofugaro]

Oh so it's like the Array.prototype.reduce() function but for vertices.

Maybe it's easier for users if the signature is the same as Array.reduce(), meaning first argument is the function and second argument the initial value?
So the second argument can be defaulted to vertex if omitted?

[elalish]

Sort of, but the difference is that it does not have to reduce to a Vertex3 type. For instance, you could reduce to a field of view for a given radius or something of that nature. Since the type is unknown, you have to supply an initial value, because there is no default constructor.

[Mugen87]

reduceVertices() works with the geometry which is no property of Object3D. That makes me feel that Object3D is not the right place for this method.

For the time being I would suggest to add the method to SceneUtils.

[elalish]

Sorry for the delay, I've addressed the comments now. I was reminded of this while fixing this function in MV for skinned meshes: google/model-viewer#3272

I was hoping to fix three's bounding box computation, but since it's inside of BufferGeometry it can't access the bones. This function can be a work-around in the meanwhile, but it seems like there should be a more core way of handling this.

[Mugen87]

I was hoping to fix three's bounding box computation, but since it's inside of BufferGeometry it can't access the bones.

Related #21507.

We can consider to move the function into the core depending on how #21507 evolves.

[elalish]

Okay, updated from traverse to traverseVisible to allow some control. Also ran build-examples to generate the js version, which conveniently told me about some includes I'd forgotten.

[elalish]

Actually, @donmccurdy would you mind taking a look at this? It seems to work quite well generally, but it still seems to fail your example: google/model-viewer#2450 (comment)

[elalish]

Interesting, so think I found the final remaining problem. The issue with the old CesiumMan model was that is used unorm8 for its skin weights vector. That's handled properly in the shaders, but in SkinnedMesh -> boneTransform it is not. I tried adding getNormalizedComponentScale( geometry.attributes.skinWeight.array.constructor ); to that function, but three does not like importing a function from an example. @Mugen87 @donmccurdy any thoughts on the right way to solve this? Maybe getNormalizedComponentScale should be a member of BufferAttribute?

[donmccurdy]

It does seem like we're going to need something like #22874 sooner or later, either directly on THREE.BufferAttribute or in a utility function.

[elalish]

Agreed; is there any problem with #22874? I'd like to merge that first so I can clean this up and test it.

[donmccurdy]

Just bumping this thread now that #22874 has been merged. :)

[elalish]

Okay, I think this one's ready now. Supposedly I should run npm run build-examples to update the js directory, but when I do, I get a pile of unrelated changes. What should I do?

[LeviPesin]

Supposedly I should run npm run build-examples to update the js directory

You shouldn't, all building is done by mrdoob in separate commits.

[elalish]

Thank you!

[OndrejSpanel]

Sort of, but the difference is that it does not have to reduce to a Vertex3 type. For instance, you could reduce to a field of view for a given radius or something of that nature. Since the type is unknown, you have to supply an initial value, because there is no default constructor.

Note: In functional languages such function is usually called fold, not reduce.