Home

Blenderstorm
Sandbox
Popular
In development
Implemented
Idea #161: Combine the material nodes and texture nodes.

bug This idea is awaiting moderator approval before going to the popular ideas area.
  • Description
  • Report duplicate
  • Help promote this idea!
Written by madmesh the 9 Sep 10 at 02:49. Category: Node Editor. Related project: Nothing/Others. Status: Awaiting moderation
Rationale
The material node editor and texturing node editor have a great deal of overlapping functionality. Combining them in one editing environment makes working easier. I cant think of a single reason to have these seperate. The only reason I believe they are seperate now is because they were developed seperately.
1/10
Approvals

0
votes
closed
0
votes
closed
0
votes
closed

Propose your solution


Duplicates
[Report a duplicate and merge its votes to this idea]


Comments
madmesh wrote on the 10 Sep 10 at 05:29
What I was aiming for is combining the already existing texture node functionality into the existing material node environment. If I understand you proposal correctly you suggest moving the texture "stack" to the texture node environment, this is not what I had in mind.

Using a texture node output would basicly be the same as exposing texture node containers to the material node editor. Only you would have acces to the actual texture nodes.

As far as it being messy, grouping can be used to clean up the workflow. Having texture nodes working in a seperate environment feels very clumsy to me as you have to switch between 2 different windows to build your materials.

Image textures and procedurals can already be used in the material editor, so adding node textures and its functionality to the material node editor should be a small step.

dna (Developer) wrote on the 11 Sep 10 at 14:15
Textures and Materials are two separate entities in blender, multiple materials can use the same texture. Plus there are more uses for textures (like for lamps and brushes I believe) than just materials.

This proposal would (IMO) lead to duplicate functionality and/or remove the ability to reference textures from more than just materials since there would be no clear separation between 'texture' and 'material' in the node editor.

netbuz10101 wrote on the 12 Sep 10 at 02:50
I was thinking that exposing everything's output allows anything else to use it as an input as long as a tool, operator, modifier, material knows how to use it as an input. Ideally the node editor should eventually be turned back into a much more robust OOPS panel.
I think in basic terms, the proposal is to expose textures directly to materials.

Do you mean that the problem is deeper than the interface?
Or is exposing some things, but not others too hackish and asking for trouble?

madmesh wrote on the 12 Sep 10 at 05:43
@dna
My proposal is stricktly aimed at useability/interface level. I'm not suggesting that textures or texture nodes should be merged at a data block level or anything like that. I'm suggesting simply that the texture nodes can be edited in the same environment as the material nodes.

My proposed solution where texture nodes wil be connected to a "texture node output" within the material editor should solve the problem of lamps and brushes having acces to them. The named "texture node output" can simply be selected from the texture stack.

At its current state the material node editor shares a great deal of functionality with the texture node editor so merging the "material node" environment with the "texture node" environment would actually reduce duplicate functionality.

Check out my mockup to see how the "texture node output" could work.


I wouldnt say I'd go as far as to expose everythings output. I'm saying do away with the "texture node editor" as a seperate environment and move

madmesh wrote on the 12 Sep 10 at 05:53

..my above response was cut short. My appologies.

I wouldnt say I'd go as far as to expose everythings output. I'm saying do away with the "texture node editor" as a seperate environment and move its functionality to the material node editor.

I believe that some of the confusion is simply caused by my suggestion to merge the texture node editor with the material node editor. Implying that I want to do away with textures and texture nodes as a seperate data block or entity. This is defenately NOT what I want. I want to merge the the working environment, not the underlying data structure. If renaming the merged environment to say, the "surface node editor" or the "shader node editor" makes it easier to understand then thats fine by me. Like I said earlier the name is not that important to me.

madmesh wrote on the 12 Sep 10 at 06:06
@DNA

The material node editor can already acces textures. And as I understand it textures are seperate entities from materials or material nodes. So its already possible to acces different datablock/entities from within the material node editor. In my proposed solution the "texture node output" would be a seperate entity from the material node, even though your working in the same environment.

The big difference would be that texture nodes would not have a dedicated construction environment like the "texture node editor" is now. Instead texture nodes would be build within the "material node editor" but they would still be "texture nodes".


P.S. Im am a Blender artist and not a developer. So my ideas and suggestion come from a users point of perspective.

FreeMind wrote on the 13 Sep 10 at 06:31
I like GUI clean up ideas. But Textures are not allways used for materials... What if you want to make an image without using it for a material?

madmesh wrote on the 13 Sep 10 at 23:36

Image and procedural textures will work as they always have. Only the construction of texture nodes wil move from the texture node editor to the material editor. The texture (nodes) can stil be used for lamps, world and brushes etc..


Post your comment