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

MeshBasicNodeMaterial: Refactor env map support. #28798

Merged
merged 8 commits into from
Jul 5, 2024
Merged

Conversation

Mugen87
Copy link
Collaborator

@Mugen87 Mugen87 commented Jul 3, 2024

Related issue: #28795, #28785

Description

This is a more generic solution for #28795 which also covers MeshLambertMaterial and MeshPhongMaterial.

Copy link

github-actions bot commented Jul 3, 2024

📦 Bundle size

Full ESM build, minified and gzipped.

Filesize dev Filesize PR Diff
683.5 kB (169.2 kB) 683.5 kB (169.2 kB) +0 B

🌳 Bundle size after tree-shaking

Minimal build including a renderer, camera, empty scene, and dependencies.

Filesize dev Filesize PR Diff
460.6 kB (111.1 kB) 460.6 kB (111.1 kB) +0 B
@@ -423,6 +427,38 @@ class NodeMaterial extends Material {

}

// ENV MAP

if ( this.environment === false ) {
Copy link
Collaborator

@sunag sunag Jul 4, 2024

Choose a reason for hiding this comment

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

I think we could add this operation in BasicLighthingModel removing this.environment, and extends PhongLightingModel from BasicLightingModel

Copy link
Collaborator Author

@Mugen87 Mugen87 Jul 4, 2024

Choose a reason for hiding this comment

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

Okay, I rewritten the code like that!

One thing that can be optimized though (ideally with a different PR) is that NodeMaterial.setupLights() should only add an instance of EnvironmentNode for PBR materials. All other materials which do not support PMREM are incompatible with that type of node. Imo, it seems more clean if this node isn't created for that materials in the first place.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I made a small revision. The idea of ​​the LightingModel parameters would be equivalent to the defines that enable the specific modules of the light model, normally boolean, since we could access the material in the setup process.

Still, I have to do another review, ideally we should have a node like EnvironmentNode to handle this.

Copy link
Collaborator Author

@Mugen87 Mugen87 Jul 4, 2024

Choose a reason for hiding this comment

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

Awesome, that looks much cleaner now!

Besides, I love these kind of reviews. They are ideal to learn the details of the new system^^.

Copy link
Collaborator Author

@Mugen87 Mugen87 Jul 4, 2024

Choose a reason for hiding this comment

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

ideally we should have a node like EnvironmentNode to handle this.

Indeed. It would be nice if NodeMaterial could somehow setup a different type of EnvironmentNode depending on the type of material. That would automatically solve #28798 (comment).

Copy link
Collaborator

Choose a reason for hiding this comment

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

Still, I have to do another review, ideally we should have a node like EnvironmentNode to handle this.

I done this part! :)

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Great! Let's merge the current state. We can add more revisions in other PRs.

@Mugen87 Mugen87 added this to the r167 milestone Jul 4, 2024
@Mugen87 Mugen87 merged commit 2b5e500 into mrdoob:dev Jul 5, 2024
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
3 participants