Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WebGPURenderer: Fix background #26493

Merged
merged 2 commits into from Jul 25, 2023
Merged

Conversation

sunag
Copy link
Collaborator

@sunag sunag commented Jul 25, 2023

@sunag sunag added this to the r155 milestone Jul 25, 2023
@sunag sunag merged commit 7b7cef6 into mrdoob:dev Jul 25, 2023
18 checks passed
const nodeMaterial = new MeshBasicNodeMaterial();
nodeMaterial.colorNode = this.boxMeshNode;
let viewProj = modelViewProjection();
viewProj = vec4( viewProj.x, viewProj.y, viewProj.w, viewProj.w );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe just viewProj.z.assign( viewProj.w )?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I were to go with the flow I would say that this should return z, because the last property accessed would still be z, I think that to return the entire vector we should have a function directly on the vector without using property accessors, this can confuse the flow of reading, for example I think viewProj.setZ( viewProj.w ) sounds better in this case.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

viewProj.setZ( viewProj.w ) reads much better 👌

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I were to go with the flow I would say that this should return z, because the last property accessed would still be z, I think that to return the entire vector we should have a function directly on the vector without using property accessors, 

I think we discussed this issue a few months ago and agreed that just adding SplitNode.assign() will allow to write vec.x.assign( anything ).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we split the line, we will see that there is something very strange with viewProj.z.assign( viewProj.w ):

const viewProjZ = viewProj.z;

// I think this should return z property not a vec3, so it cannot be inline as suggested
viewProjZ.assign( viewProj.w ) 

We don't have the same problem with node.set*() because it has no property accessor.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nove.set*() also follows the current JS API style.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But what I'm suggesting is: 1) more powerful (you can do anything in all combinations, like vec.xy.assign( anything )), 2) better reflecting shader code, 3) easier to understand, 4) easier to implement. I can file a PR for it if needed.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So only good things?
You can't think of problems that it creates?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is totally possible made node.setXY() or any combination using Proxy, I always considered that when I use node.set*().

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can't think of problems that it creates?

I don't really see what problems could it create. It would function similar to VarNode.assign().

@sunag sunag deleted the dev-webgpu-fix-background branch September 7, 2023 16:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

WebGPU, PerspectiveCamera and SkyBox (CubeMap) - Artifacts when large difference between far and near values
3 participants