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

Feature: Add vertex color alpha channel support. #20975

Merged
merged 2 commits into from
Mar 26, 2021
Merged

Feature: Add vertex color alpha channel support. #20975

merged 2 commits into from
Mar 26, 2021

Conversation

chubei
Copy link
Contributor

@chubei chubei commented Dec 31, 2020

Related issue: Fixed #16403.

Description

A new shader macro USE_VERTEX_OPACITY is added to control if the attribute color is a vec3 or vec4.

Corresponding flag in Material is .vertexOpacities.

Does this need a new example? @donmccurdy @mrdoob @Mugen87

@Mugen87
Copy link
Collaborator

Mugen87 commented Dec 31, 2020

I think I prefer the name vertexAlpha.

Please also update the TS declaration file and the documentation.

Does this need a new example?

It's good if at least one example demonstrates the usage. However, I would enhance an existing buffer geometry example like webgl_buffergeometry.

@chubei
Copy link
Contributor Author

chubei commented Dec 31, 2020

I think I prefer the name vertexAlpha.

No problem.

Please also update the TS declaration file and the documentation.

I wasn't aware of the TS files. Will do.

The contribution guide says please make a new PR for the appropriate doc changes. Is that out of date?

It's good if at least one example demonstrates the usage. However, I would enhance an existing buffer geometry example like webgl_buffergeometry.

I'll modify that example.

@Mugen87
Copy link
Collaborator

Mugen87 commented Dec 31, 2020

The contribution guide says please make a new PR for the appropriate doc changes. Is that out of date?

Oh, I was not aware of that line. TBH, I think it's better if the documentation is always updated with the same PR that changes code.

@chubei
Copy link
Contributor Author

chubei commented Dec 31, 2020

TBH, I think it's better if the documentation is always updated with the same PR that changes code.

I actually agree. Let's break that rule in this PR 😈.

@Mugen87 Mugen87 mentioned this pull request Dec 31, 2020
Mugen87 added a commit that referenced this pull request Dec 31, 2020
This PR clarifies the update of documentation pages, see #20975 (comment).
Mugen87
Mugen87 previously approved these changes Jan 6, 2021
@chubei
Copy link
Contributor Author

chubei commented Jan 16, 2021

Thanks for your review @Mugen87. Are we waiting for other collaborators’ review now?

@Mugen87
Copy link
Collaborator

Mugen87 commented Jan 16, 2021

Yep. @mrdoob will have a look at this PR and merge it when everything is fine.

@Mugen87
Copy link
Collaborator

Mugen87 commented Feb 1, 2021

@chubei Do you mind updating the PR? There is now a merge conflict since all TS type declaration files were removed.

@chubei
Copy link
Contributor Author

chubei commented Feb 4, 2021

Rebased and force pushed. Sorry for the delay.

@noamgat
Copy link

noamgat commented Mar 4, 2021

Wow, this looks great! We would be really happy it it was merged.

src/materials/Material.js Outdated Show resolved Hide resolved
@mrdoob mrdoob added this to the r127 milestone Mar 5, 2021
@Mugen87 Mugen87 dismissed their stale review March 9, 2021 09:53

Code based has changed since last approval.

Copy link
Collaborator

@Mugen87 Mugen87 left a comment

Choose a reason for hiding this comment

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

Using vec4 by default is a breaking change and can't be accepted.

@chubei
Copy link
Contributor Author

chubei commented Mar 15, 2021

I tried to implement automatic inferring vertexAlpha and force pushed the code. Because most of the original modification is not used any longer, I rebased and made a new commit. Please let me know if you want a merge-then-forward style commit.

@Mugen87
Copy link
Collaborator

Mugen87 commented Mar 15, 2021

I think we should stick to vertexAlpha and let the user/loaders decide when to use vertex alpha or not. #20975 (comment) is a good example why automatically determine configurations are problematic.

Copy link
Collaborator

@Mugen87 Mugen87 left a comment

Choose a reason for hiding this comment

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

Not approving an inferring approach.

@chubei
Copy link
Contributor Author

chubei commented Mar 15, 2021

@mrdoob What’s your opinion on this? I prefer the inferring approach, but am also fine with merging the previous version.

@mrdoob
Copy link
Owner

mrdoob commented Mar 15, 2021

Hmm...

On the API ergonomics side, inferring is a big win.
Users no longer need to know about skinning, vertexTangents, vertexColor, vertexAlpha, etc

We can also remove 3 checkboxes from the editor (which is usually a good signal API wise too):

Screen Shot 2021-03-15 at 5 51 25 PM

I agree with @chubei that instead of grid1.material.vertexColors = false; the user should be doing grid1.geometry.deleteAttribute('color'); (and I should have done that 😅).

I also understand that this would force people have to duplicate geometries and that could result in increased memory, but I'm not sure how much of a concern it should be for most of the cases.

How about we try the inferred approach in this case so we can see what the real consequences are?
We can add the property to the material later if we found this creates issues.

@Mugen87
Copy link
Collaborator

Mugen87 commented Mar 15, 2021

How about we try the inferred approach in this case so we can see what the real consequences are?

Okay, that sounds good to me.

Mugen87
Mugen87 previously approved these changes Mar 22, 2021
@@ -879,6 +879,14 @@ BufferGeometry.prototype = Object.assign( Object.create( EventDispatcher.prototy

},

hasColorAlpha: function () {
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't think we want to expose this method.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, this also looks strange to me. Any suggestions where I should put this method? Don't feel like to repeat the code in WebGLRenderer.js and WebGLPrograms.js.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I would indeed inline it for now.

Copy link
Owner

Choose a reason for hiding this comment

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

Agreed! I was going to clean that up after merging it tomorrow.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I would indeed inline it for now.

Sure thing. Updated.

@mrdoob
Copy link
Owner

mrdoob commented Mar 23, 2021

@Mugen87

I've spent some idle thinking on this issue over the last few days and I came up with another reason to remove skinning.

There are quite a few bug reports of scene.overrideMaterial not working with scenes that have skinned and not skinned meshes. And that's because we can't reuse the same material in both. If a user wanted to render the whole scene in wireframe for example, it's not possible.

Similarly, WebGLShadowMap has this logic that is a workaround for the same problem.

My hunch is that the extra VAOs are worth it so users can finally reuse materials without bumping into these issues and being forced to understand the internals.

@mrdoob
Copy link
Owner

mrdoob commented Mar 26, 2021

Hmm, I'm going to merge this and do another PR some changes to it for your review.

@mrdoob mrdoob merged commit 30189da into mrdoob:dev Mar 26, 2021
@mrdoob
Copy link
Owner

mrdoob commented Mar 26, 2021

Thanks!

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.

Include vertex color alpha?
5 participants