I've been playing with the Octane material pipeline during the weekend, and have noted down some things that I think would be useful to have, and the reasoning behind them. Some of them are strictly needed, some of them are little enhancements and some are just ideas to debate on. Any feedback (support, resent, additions, comments) from the developers and users would be appreciated. Ofcourse users are invited to write down their own wishes concerning the material pipeline in this thread (as we don't have a proper feature request tracking tool). I opted to group all this requests into a single thread also because I don't like to flood the forums with new threads for every little issue that I have.
Bear in mind that this is a feature request thread, not bug report (ie. bugfix requests should be posted in the current version testing thread).
1.) Tidying up GE
The Graph Editor becomes a Flying Spaghetti Monster three nanoseconds after you start working with nodes.
Being able to pan the GE is a matter of life and death. Some other ways of keeping nodes more organized is also needed - like grouping or hiding. Blender Nodes editor is very well organized, for example.2.) More procedural noises & blending modes
I'm sure the devs are aware of this and working on, but anyway. There is the need for more noise generators (voronoi, tiling patterns...). Blender procedurals system come into mind, where every noise has also a basis noise (seed?) which permits to create a plethora of diverse patterns. More texture blending modes are also needed. Currently Octane has mix and multiply, but to really take advantage of procedurals and nodes in general, there need to be support for all the typical blending modes you can find in image editing software like Photoshop or Gimp: add, divide, subtract, screen, overlay, saturation...
3.) RGB only preview for textures
When working with texture nodes there is no need for a lighted preview - frequent render re-starts slow down the workflow and sometimes cause hangups (atleast on my machine). All you really need is to see the RGB result of your node system.
4.) Arbitrary material preview model
The material ball is nice and enough for generic previews, but sometimes when creating materials you would like to have for preview the model on which the material will actually be applied. The ball is small and procedural scale is almost always off when you later apply the material to the actual object. Also its texture coordinates are distorted spherically, so it's not an ideal preview of exact uv mapped textures. The ideal solution would be if we could use an arbitrary model from the active scene instead of the material ball - say that when you are creating a macro, you could apply a piece of the scene (only those objects that share the materials ID) for that macro preview. Looking at the actual object when creating nodes for it would speedup workflow.
5.) Basic math nodes
Say you created a material comprised of image textures and procedurals. To look right, like you want it, the procedurals must have a different scale than image textures (usually they have). You want also to assign a "global scale" input pin, so that you or users of LiveDB will be able to control the scale of the material. You would need a node that multiplies the float input of the user by a factor, for every different scale you have in your textures, if you want to be able to scale all textures with one input parameter.
Basically in this case a math node with a multiplying factor, that takes user inputed value from the input pin node, and passes on the multiplied value to texture node scale input.
6.) Ability to link images to macro nodes
I think this one has already been acknowledged by the dev team, but I'll mention it anyway (with a minor addition).
Presently imported images in macro are embedded into the .ocm file, which creates a lot of unnecessary duplication and is heavy on disk usage (images are saved uncompressed). A more flexible way for local material database would be to just save the path to an image in macros. The program should write down both the absolute path and relative path and on import check the other, if the image is not found on the first. This will make the system a little more robust and will permit users to move project folders around, without fear to break links to images. My personal organization is that I have texture images in a global repository that doesn't change (absolute path), but also texture images created specifically for the project (relative path) which are not usable in other projects. This is a minor feature, but can make life easier.
7.) Multiple mapping coordinates & UV's
Support for mapping textures in different ways not just UV would be appreciated. The texture and mapping nodes could have an additional parameter - a dropdown list of standard intrinsic coordinates to choose from: global, object, cube, sphere, tube... Also a very useful thing sometimes is being able to use multiple UV coordinates for the same mesh. I'm sure that most 3D packages support multiple unwrapping of the same mesh, the thing is that .obj file format doesn't seem to support it (another reason to dump it).
That's it for now. I'm sure more things will pop up eventually. Octane is awesome, wanting it to be even more awesome is just natural
