Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Fix writable mat4/mat3 setters for p5.Matrix to restore Camera.slerp() in ortho mode#8295

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
nakednous wants to merge1 commit intoprocessing:dev-2.0
base:dev-2.0
Choose a base branch
Loading
fromnakednous:fix-mat4-slerp-ortho

Conversation

@nakednous
Copy link
Contributor

@nakednousnakednous commentedNov 25, 2025
edited
Loading

This PR fixes issue#7837.

In p5.js v2,Matrix.mat4 is exposed via a getter that returns an internalFloat32Array.
Camera.slerp() (and potentially other code) assigns touPMatrix.mat4 which throws:

TypeError: setting getter-only property"mat4"

This change adds aset mat4(values) onMatrix that:

  • only applies to 4×4 matrices,
  • expects an array-like of length 16, and
  • copies values into the existingFloat32Array instead of reassigning it.
  • Adds a symmetricset mat3(values) for 3×3 matrices.

This fixes the intended writable behavior (used byCamera.slerp()), while preserving the internal buffer identity required by WebGL bindings and other code that holds references to the matrix storage.

@welcome
Copy link

welcomebot commentedNov 25, 2025

🎉 Thanks for opening this pull request! For guidance on contributing, check out ourcontributor guidelines and otherresources for contributors!
🤔 Please ensure that your PR links to an issue, which has been approved for work by a maintainer; otherwise, there might already be someone working on it, or still ongoing discussion about implementation. You are welcome to join the discussion in an Issue if you're not sure!
🌸 Once your PR is merged, be sure toadd yourself to thelist of contributors on the readme page !

Thank You!

@nakednous
Copy link
ContributorAuthor

Rebasing this PR onto the latest dev-2.0.
I’ve re-tested the fix locally using the built lib/p5.js, and the ortho Camera.slerp() issue is resolved.

@davepagurek
Copy link
Contributor

Hi@nakednous, sorry for the delay on this! I think this approach works, but it might be for the best to not allow these to be settable for safety?@holomorfo@limzykenneth do you have thoughts?

If we don't want to let those properties be settable, rather than cloning + updating the existing matrix here:

this._renderer.states.setValue('uPMatrix',this._renderer.states.uPMatrix.clone());
this._renderer.states.uPMatrix.mat4=this.projMatrix.mat4.slice();

...maybe we just set the state directly to a clone of the camera's matrix?

@nakednous
Copy link
ContributorAuthor

I double-checked this locally and can confirm both variants remove the orthoslerp() crash:

if(this._isActive()){this._renderer.states.setValue('uPMatrix',this._renderer.states.uPMatrix.clone());}

and

if(this._isActive()){this._renderer.states.setValue('uPMatrix',this._renderer.states.uPMatrix.clone());constdst=this._renderer.states.uPMatrix.mat4;constsrc=this.projMatrix.mat4;for(leti=0;i<dst.length;i++){dst[i]=src[i];}}

In the minimal test sketch I used, the ortho projection parameters ofcam0 andcam1 are identical, so simply cloninguPMatrix is sufficient to avoid the crash. However, the second version preserves the intended behavior of propagating interpolated ortho projection changes (when they differ) without assigning tomat4, keeping it getter-only.

Happy to go with whichever direction you prefer.

@davepagurek
Copy link
Contributor

Thanks for taking a look! Have you tried if something like this works?

this._renderer.states.setValue('uPMatrix',this.projMatrix.clone());

This would be directly creating a clone of the intended matrix rather than cloning the renderer's matrix and updating it, since the result in both cases is a new matrix with the intended values.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@nakednous@davepagurek

[8]ページ先頭

©2009-2025 Movatter.jp