Yamyam: 1版をインポートしました

2018-06-28T19:45:18Z

1版をインポートしました

wiki>Brecht: moved Dev talk:2.6/Source/Render/ShadingWorkflow to Dev talk:Source/Render/ShadingWorkflow

2015-12-27T19:05:21Z

moved Dev talk:2.6/Source/Render/ShadingWorkflow to Dev talk:Source/Render/ShadingWorkflow

新規ページ

=== Nodes ===

I think clearer definition of terminology would help: input node, output node, panel. I am under the impression the tree starts at the input node.

This is not a complete plan, just my interpretation on the shader properties editor tab, as well as some feature I feel are necessary:
# The purpose of the node editor is to provide a bird's eye view for organizing, linking, and naming nodes, possibly with state. Therefore I suggest that the shader properties editor tab only show one shader node at a time. Perhaps there can be a link between the selection state of the node editor and the properties shader tab, so that changing focus in the node editor changes the currently displayed node in the properties shader tab.
# Clicking on a "pad" (the endpoint of a link from/to another node) brings that respective node into focus. This behaviour would be similar to clicking on the particles "pad" in the modifier tab, with the exception that the focus remains in the current tab and the displayed node changed. The concept is similar to a slideshow, swiping nodes to the left or the right.
# There is a concept of "head" (nodes nearest the input) and "tail" (nodes nearest the output). Pads can be color-coded depending on the distance from the "head" or "tail". (sort-of/barely similar to the shading done in the curves editor)
# I feel the only true overview can be from the node editor. A drop-down menu is unable to capture branching node trees. However, if a user properly names the nodes, perhaps a drop down menus of all the nodes alphabetically arranged can be useful. Perhaps a bar near the top of the shader tab like such:
: [node drop-down menu] [button to "head" node] [button to "tail" node]
--orbisvicis

=== Closures ===

Several reasons "closures" in inappropriate
# too similar to the computer science term
# gives the impression that the render supports a precedence systems for volume within volume intersecting other volumes. (does it?)
I don't see any problem with using BSDF as an all-inclusive term for BTDF/BRDF/BSSRDF. People just need a catch-phrase to reference in manuals and tutorials, using the proper term could help.
--[[User:orbisvicis|orbisvicis]]

::It's indeed too much of a computer science term. The problem is that we need nodes like Mix Closure and Add Closure. It's a core concept of Cycles that you can add/mix different kinds of closures, for surfaces we have bsdf and emission now, and bssrdf and compositing holdout will be added later. Mainly I'm hoping someone can come up with a good name for it, best I could think of was "Shader", but that already a loaded term. --[[User:Brecht|Brecht]]

::I would say don't make up names completly. Make it possible for users to find information in wikipedia about the shader models. Of course long tecnical terms are probably a waste in the UI but the basic definitions would be nice if reflected in the naming. No harm there. About closures, no opinion really. --[[User:ZanQdo|ZanQdo]]

Thanks, I don't know if this is still necessary but I did some brainstorming by starting of with a few concepts, and looking for words:

Concepts:
*that which affects light - unrelated to geometry, i.e. volume shaders define shape
*that which assumes an area

Words:
*body
*substance
*container
*bead (i.e. glass bead, texture bead)
*space

*slot
*zone

End result:
*aggregate
--[[User:orbisvicis|orbisvicis]]

← 古い版	2018年6月28日 (木) 19:45時点における版
(相違点なし)

Dev talk:Source/Render/ShadingWorkflow - 版の履歴

Yamyam: 1版 をインポートしました

wiki>Brecht: moved Dev talk:2.6/Source/Render/ShadingWorkflow to Dev talk:Source/Render/ShadingWorkflow

Yamyam: 1版をインポートしました