-
-
Notifications
You must be signed in to change notification settings - Fork 35.6k
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
[WIP] GLTFLoader: Add .setUseNodes() option. #14572
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -14,13 +14,17 @@ function MeshStandardNode() { | |
|
||
this.properties = { | ||
color: new THREE.Color( 0xffffff ), | ||
emissive: new THREE.Color( 0x000000 ), | ||
ao: 1.0, | ||
roughness: 0.5, | ||
metalness: 0.5, | ||
normalScale: new THREE.Vector2( 1, 1 ) | ||
}; | ||
|
||
this.inputs = { | ||
color: new PropertyNode( this.properties, 'color', 'c' ), | ||
emissive: new PropertyNode( this.properties, 'emissive', 'c' ), | ||
ao: new PropertyNode( this.properties, 'ao', 'f' ), | ||
roughness: new PropertyNode( this.properties, 'roughness', 'f' ), | ||
metalness: new PropertyNode( this.properties, 'metalness', 'f' ), | ||
normalScale: new PropertyNode( this.properties, 'normalScale', 'v2' ) | ||
|
@@ -48,6 +52,40 @@ MeshStandardNode.prototype.build = function ( builder ) { | |
|
||
this.color = map ? new OperatorNode( color, map, OperatorNode.MUL ) : color; | ||
|
||
// slots | ||
// * emissive | ||
// * emissiveMap | ||
// * emissiveIntensity | ||
|
||
var emissive = builder.findNode( props.emissive, inputs.emissive ), | ||
emissiveMap = builder.resolve( props.emissiveMap ), | ||
emissiveIntensity = builder.resolve( props.emissiveIntensity ); | ||
|
||
this.emissive = emissiveMap ? new OperatorNode( emissive, emissiveMap, OperatorNode.MUL ) : emissive; | ||
|
||
if ( emissiveIntensity !== undefined ) { | ||
|
||
this.emissive = new OperatorNode( this.emissive, emissiveIntensity, OperatorNode.MUL ); | ||
|
||
} | ||
|
||
// slots | ||
// * ao | ||
// * aoMap | ||
// * aoMapIntensity | ||
|
||
var ao = builder.findNode( props.ao, inputs.ao ), | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oops this should be aoMapIntensity and included in shortcuts There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah. To shortcuts in There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. |
||
aoMap = builder.resolve( props.aoMap ), | ||
aoMapIntensity = builder.resolve( props.aoMapIntensity ); | ||
|
||
this.ao = aoMap ? new OperatorNode( ao, new SwitchNode( aoMap, "r" ), OperatorNode.MUL ) : ao; | ||
|
||
if ( aoMapIntensity !== undefined ) { | ||
|
||
this.ao = new OperatorNode( this.ao, aoMapIntensity, OperatorNode.MUL ); | ||
|
||
} | ||
|
||
// slots | ||
// * roughness | ||
// * roughnessMap | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure about this. I never liked passing parameters as an object, it's error-prone and limited.
We have a chance to move away from it here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought the goal of
MeshStandardNodeMaterial
was to be a backward-compatible alternative toMeshStandardMaterial
, whereasStandardNodeMaterial
would provide a new, fully node-based syntax? If we don't want this class to support old syntax then maybe I've misunderstood the difference.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sunag is that correct, or what would be the goal with the two material classes here? Put another way, is this what we want?
I’m assuming here that MeshStandardMaterial would eventually be replaced by MeshStandardNodeMaterial. If that’s not the goal, or if we want the existing system to exist alongside node-based materials indefinitely, then perhaps we don’t need a backward-compatible MeshStandardNodeMaterial?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the plan was to make
MeshStandardMaterial
node-based to keep backwards-compatibility.Maybe
MeshStandardMaterial
could extendMeshStandardNodeMaterial
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally, I much prefer
parameters
as an object towhere the order matters. Very annoying.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that passing parameters like
Texture
currently does is also annoying.I prefer this kind of API:
Or:
But the problem of the last one is that the user could make a typo like
texture.fromat
and javascript won't complain. Unless we start usingObject.freeze()
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that's a big change. Too many tutorials/articles that will get obsolete.
I think it's easier to think about
*NodeMaterial
as having a different API. If we bring parameters to the new API we're carrying over the problem and it'll be harder to maintain.We can always add parameter support to
MeshStandardNodeMaterial
later. For the time being I prefer to not over complicate the new API.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm... I don't think that we should introduce two new standard materials (
MeshStandardNodeMaterial
,StandardNodeMaterial
) that both have different, breaking APIs for the same features. For the new API,StandardNodeMaterial
seems like the place to start — we can leave parameter support out there. IfMeshStandardNodeMaterial
will not have the same API asMeshStandardMaterial
, I think we should just delete it (MeshStandardNodeMaterial
) to prevent confusion, unless it has some other purpose I've missed.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain why this:
is more error prone or limited than
The second approach seems much more verbose to me, with no advantage in clarity - especially since this would be a breaking change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If that is the problem I think this could be fixed with
hasOwnProperty
declaring allproperties
before ofsetValues
evenundefined
variables:Example (1)
Example( 2)
+1 I think this could come from the an evolution of compiler too like
interface
oftypescript
. For me, besides being practical to define parameters it techniques is good to avoid changes if a property is to be depreciate in relation to ordered parameters, in relation atsetParamA(a).setParamB(b)
could help to reduce the code.Another third thing could be to create a classe just for this.