[SameObject] on both in accordance with #588 ?

In accordance with our move to remove attributes that reflect the object's creation parameters, this should probably be removed altogether.

Need to clarify pre vs post multiply here.

Ideally avoid talking about multiplication at all, instead saying "Set refSpace's originOffset to a transform where base's originOffset is applied first, and originOffset is applied second".

Why avoid talking about multiplication? We've got several issues that call out the need to clarify related topics like this one #582. And actually, I'd be ok filing a separate issue for this to unblock this merge.

Ah, yeah, I guess we should figure out how to consistently talk about this first instead of attempting to fix it in each use site in an ad hoc manner.

Can we change this pattern to not be a constructor, but rather a function on the XRReferenceSpace object being based on? Maybe XRReferenceSpace.getOffsetReferenceSpace()

Why avoid talking about multiplication? We've got several issues that call out the need to clarify related topics like this one #582. And actually, I'd be ok filing a separate issue for this to unblock this merge.

As mentioned above, I think it's confusing to have a constructor that only works for what amounts to a copy. And given that initial reference space creation requires an asynchronous call, a constructor isn't really an option.

nit: nix the word 'additional'

@toji, are you intentionally reversing the meaning of the originOffset here? If the originOffset provides the position and orientation of the offset space, where the position member is exactly the origin position in base space coordinates, queries using the offset space need to apply the inverse of the originOffset transform when returning poses, assuming you want to match the voted resolution for #477. (cf. #569 and the rough consensus from #580.)

We might consider adding the origin offset as a parameter to this function...

Is there an existing definition what it means to multiply XRRigidTransforms? This needs to be unambiguous. I think it's backwards as written.

Let's say we set up a base space and two chained offsets like this:

let baseSpaceA = ...; starting reference space A
let offsetSpaceA = new XRBoundedReferenceSpace(baseSpaceA, originOffsetA);
let offsetSpaceB = new XRBoundedReferenceSpace(offsetSpaceA, originOffsetB);

Each originOffset's matrix is a transform from offset space to base space. Space B's base space corresponds to space A's offset space.

You can use the matrices to transform coordinates in offsetSpaceB to coordinates in baseSpaceA:

pointInBaseA = baseAFromOffsetA * offsetAFromOffsetB * pointInOffsetB;
             = offsetSpaceA.originOffset.matrix * offsetSpaceB.originOffset.matrix * pointInOffsetB

and therefore, space B's originOffset.matrix is space A's originOffset.matrix times space B's originOffset.matrix, or for spec purposes:

1. Set |refSpace|'s {{XRReferenceSpace/originOffset}} to |base|'s {{XRReferenceSpace/originOffset}} multiplied by |originOffset|.

➕ 1 to having this defined as an "algorithm" in the spec so we can easily reference it in other spec "algorithms". @klausw , do you want to post a PR with this clarification text and Brandon and I can review it? I think getting that nailed down first will go a long way towards our goal of algorithmically defining the behavior of getPose() and getViewerPose().

@NellWaliczek That's what I was trying to do in my existing PR, see especially https://github.com/immersive-web/webxr/pull/569/files#diff-ec9cfa5f3f35ec1f84feb2e59686c34dR955 which tries to be quite specific about this.

Can we discuss that in that PR? I'm happy to extend this further, i.e. adding more info about chaining transforms, but I'd like to get consensus on the basics first.

Sorry, I think there's a misunderstanding here between Nell and Klaus. I believe the algorithm which Nell is talking about is one that describes how two XRRigidTransforms are multiplied. (At least that's how it reads given the context.) The line in Klaus' PR that was linked details (very well) how a matrix is derived from the rigid transform.

I do think that having an in-spec algorithm that describes how transforms are multiplied would be extremely useful. That's something that Nell or I could sketch out if needed, but either way I'd want to have Klaus and/or Manish review it to ensure we're all on the same page. Then that should serve as a fundamental building block though which we can help describe a great many of the rest of these concepts.

@toji The text I have now in #569 specifies the content of a XRRigidTransform matrix and how it transforms numeric coordinates, and this should constrain implementations to one specific interpretation of how the transforms work. As a result, there should only be one correct way to chain transforms.

I don't think it makes sense to have an independent PR or discussion about chaining transforms unless we can get agreement on these basic properties of transforms. There's no separate design freedom for the underlying matrix math of XRRigidTransform multiplication. I agree it would be helpful to add an explanation to the text, but I think this would be appropriate as a followup since it's derived from the basic properties and definitions of the transforms and matrices.

I'm fairly confident that the chaining I described in my comment above matches #569, assuming usual column-major GL matrices applied to column vectors, but I'd appreciate an independent sanity check.

Would it help to schedule some time with interested parties to talk through this? I feel as if we're still a bit stuck on this issue even after discussing it in two of the weekly conf calls, and I'm unsure if there's actual disagreement or not.