-
Notifications
You must be signed in to change notification settings - Fork 206
Node Design Guidelines
John Haddon edited this page Nov 26, 2019
·
2 revisions
- Where sensible, prefer "nouny" names. Example : Sphere, not CreateSphere.
- Avoid "contrived nouniness". Example : not AttributeDeleter.
- Where a name contains a verb, use VerbSubject order. Example : DeleteAttributes, not AttributesDelete.
- Prefer shorter names. Where several modules have a claim on a name, use the short name for the predominant claim. Example : Transform and ImageTransform.
Both SceneProcessor and ImageProcessor nodes can be constructed with either a single in
plug, or an array of in[0]
, in[1]
etc.
- Use ArrayPlugs where multiple inputs are required, and they all serve a similar purpose. Examples : Merge, Mix, Group.
- Avoid arrays when each input serves different purposes. In this case, add additional children with a descriptive name instead. Examples : the
source
plug of aCopyAttributes
node, theprototypes
plug of anInstancer
node.
- Declare methods in this order :
affects()
,hash()
and thencompute()
. This matches the order they will be called in during operation. - In cpp files, place the corresponding
compute*()
method immediately underneath the appropriatehash*()
method. This makes it easier to verify that the hash has the appropriate content for the compute.