PropertyBinding: Support more arbitary objects

[takahirox]

Related: #24537, #24108

Is your feature request related to a problem? Please describe.

Currently PropertyBinding can bind only some of the object types, and can't do others. For example non-map textures can't be bound. Because of this limitation, Three.js animation system can't handle some type of objects.

The glTF KHR_animation_pointer extension that allows animation of arbitary objects in glTF support #24108 is blocked by this problem and the implemenation of it is the way more complex. It is a standard KHR_ prefix extension so it's good if we can support it with simple implementation when it will be ratified.

Describe the solution you'd like

PropertyBinding supports more arbitary objects.

I guess the major cause is the keyframe track name has to start relative from the 3D object and the name must be up to three level depth like name1.name2.name3.

https://threejs.org/docs/#api/en/animation/PropertyBinding.parseTrackName
#24537 (comment)

Relaxing the name level depth limitation (allowing nesting) may resolve the problem, like name1.name2.name3.name4...? (If I remember correctly, someone (@WestLangley ?) suggested it before).

Describe alternatives you've considered

Alternative solution may be allow to specify an animation target with the pair of object and property name? (If we do this, we may need "legacy mode" not to break the compatibility.)

new KeyframeTrack(
  object.material.roughnessMap, // target object
  'rotation', // property name
  inputAccessor.array,
  outputArray,
  interpolation
);

Is there any strong reason why animation target must be specified with the current name1.name2.name3 name style?

[WestLangley]

someone (@WestLangley ?) suggested it before...

It was not I. :-)

[takahirox]

Then maybe @tschw

[Bug-Reaper]

parseTrackName() uses regex to separate many different pieces of information. The trouble arises in that nodeName can include . and there's no easy way to tell where the nodeName ends and where the properties begin (w/o bruteforce check).

So given trackName bang.foo.bar.biz all of the following scenarios are possible:

1. nodeName is bang and properties arefoo, bar, biz
2. nodeName is bang.foo and properties are bar, biz
3. nodeName is bang.foo.bar and property is biz

---

I want to propose that a new method named parseTrackObj()

This method accepts a json-object as a way to explicitly define info currently being parsed via regex (nodeName, objectName, objectIndex, propertyChain, propertyKey).

The goal is to eliminate the need to rely on regex hackery, allow for deeply nested target properties, and generally make things easier to maintain/extend.