New nodes feature discussion towards v1.0 final

[face]

A normal vector node and a camera position node that gives the actual position back would be nice.
With that we can make a fresnel or other thinks...

An option to make a node privat.
Means, that the node can´t edit after uploading.
Maybe a good choice for someone who has spend much time to create a material.


face

@PeterCGS:
http://www.refractivesoftware.com/forum ... 415#p48415
Thats only a materialmix with two textures and a vertexcolormap.

http://refractivesoftware.com/forum/vie ... 720#p27720
Blend a color and an image per distance...

[buggy]

I recommend that you take a look at the list of material generation nodes available in Darktree. Once can create just about any procedural material one can think of with it.
Genetica may also be worth a look although I haven't tried it.

[dave62]

+1 would love to have some nodes to build an anisotropic shader

[suhail_spa]

adding fresnels would be great..
thanks Radiance..

[tomas_p]

Hi radiance.

Good news.

Mathematical operators between materials in mixmaterial node will be cool. Because now is the light only mixed not added. Is difficult making dispersion in specular materials...

http://www.refractivesoftware.com/forum ... f=6&t=5705

Regards

[juan]

* an independet enviroment node for using a n hdr with the sunlight system.

*AO node that isnt tied to the direct light AO input value, with procedural alpha overlay. Also for mixing materials (create dirt etc).


*Matte node. Alpha black/white (custom alpha creation based on materials, instead of only atmosphere)

[matej]

At some point Octane will have to support 'auto' texture mapping (like spherical, cube...) and multiple UV coordinate sets per material / object. So a Coordinate node to specify the source of coordinates per texture will be needed.

This node should be plug-able into a Transform node, to further manipulate and fine-tune the mapping of some texture.

[matej]

Also, the way textures are created / loaded is strange - for each texture node you must browse and "re-load" the image from the file system. A better way to deal with image resources would have to:

* make so that each image is loaded / browsed from the file system only once. Maybe have a "texture image load node", that would be used to make images available to the nodesystem.
* a texture node (RGB, grayscale or alpha) is just a 'container' for an image and you could choose which image does it manipulate from available images, from inside this container. So if I would like to change from which image the texture node is taking data, I would need only to browse some dropdown of loaded images or something. The texture node could retain it's type (RGB, grayscale, alpha) or even that could be quickly changed without deleting the node.

This ways the whole workflow would be more transparent and more flexible (no need of deleting & re-creating texture nodes if you want to change something) .

[matej]

Once all that primitive tools will be available (math, boolean, switches...) we would need a generic macro container type, that:

* would take an arbitrary number & type of inputs
* would offer an arbitrary number & type of outputs
* could function as a grouping node, so you could dissect your nodesystem in smaller / reusable / easier to manage parts
* would function as a "standalone utility" node, to be uploaded to the LiveDB so that others could use it

It's imperative that such node offers multiple outputs, alongside to multiple inputs, so generic input and output pins would be needed.

[Proupin]

I'd like an "environment" node with four inputs, background channel, reflection, illumination and refraction... By default (how it's behaving now) the environment texture would be connected to these 4 channels. But we would be able to use (independent) High resolution LDR for bakground and hdri for illumination, etc

and

An AO map node would be great as well