Vendor Request: Nodal Shader Manager

#1

This is a new type of thread to help seed ideas to the folks at EITG, Northern Lights, Konkeptoine, and all other 3rd party companies to develop specific tools to make our lives easier. It kinda goes hand and hand with the EIAS 7 wish list thread. But these threads are to be topic orientated instead of a general wish list free for all.

Right now, EIAS has a pretty good material system. However, one thing that I’ve noticed is the shaders are heavily numeric in nature. Is it possible for EITG or a 3rd party group to make a new nodal shader manager that interfaces with EIAS’ shader api? I picture the process similar to the way Onyx makes tree storm. A seperate program, based on nodal methodology, is used to create shading networks. Once a nodal shader “template” is created, it transfers the numeric data settings into the material editor within EI. 3rd party companies could then provide bridges to their custom shaders through this nodal manager. Mforge, for example is awesome, but it can be a bit overwhelming to the newbie who only sees numbers. If the nodal manager could be written to tap into Mforge and feed it numbers, we could side step EIAS’ potential api limitations and create shading systems in a more right brained approach. Think Maya’s hypershade.

What do you guys think?

#2

A system like that would only make sense if you can have a preview of the material in that separate “node-shader-stack-creator” program. The only way to do that reliably is to have Camera render out the preview. As far as I know, the interface to Camera is completely undocumented, only EITG know how to interface with Camera, otherwise someone would have written a bridge between Camera and Maya a long time ago. In other words, EITG would have to get involved so heavily with the development of something like this that they might as well do it themselves and integrate it in Animator.
The other thing I was thinking is that none of the current shaders would really make any use of a system like that until the programmers at Konkeptoine, TripleD… add some extra code to all their shaders to make use of a more advanced GUI api.
Don’t get me wrong, I’m absolutely not against a more graphic interface at all, but I really think it’s EITG’s call.

#3

Yes… most likely true. EITG really needs to initiate this, but I don’t see why a 3rd party company like Konkeptoine couldn’t write such a program to interface with their shaders. (Of course, I’m not a programmer.) Their shaders already provide a reasonable preview now, without Camera’s help, but they seem restricted by the current shader api to create something a little more user friendly. Right now we’re just punching in numbers or sliding a slider bar. A konkeptoine node based shader manager could be used to create better usage of their shaders and then either save out shader varients into the shader varient pallette, or feed data straight into the shader itself. Granted, the new interactive features are starting to pop up in the newer shaders and perhaps one of the 3rd party companies can give us a description of what things we could expect to see with these new controls in the future. But despite that, a “hypershade” type system would be nice to see.

#4

Hello, gentlemen

Here is a little “exchange” between theory and practice :slight_smile:

  1. “the shaders are heavily numeric in nature”

It’s 100% true, can add also that numerous edit fields look poor, primitive and ancient.
We think the solution is a set of new integrated controls, like color gradients, graphs etc.
MF would look muuch easier if all its “color blocks” (color + edit boxes) are replaced with gradient lines

  1. “Nodal manager”

For EI its functionality isn’t clear. MF: we think it’s better and simple to have presets inside the shader (internal and/or load from file) instead to create enough complex new system. In other words we see no subject(s) of constructive exchange that a nodal system could pass between shaders.

“a “hypershade” type system would be nice to see”

Straightforward copying of other apps approaches is not a perspective way. The eventual result is that a feature (absolute good there) looks unnatural/strange here

  1. “otherwise someone would have written a bridge between Camera and Maya a long time ago”

Hmm… imho the chances to find such “someone” are near zero :slight_smile:

  1. “The only way to do that reliably is to have Camera render out the preview”

Maybe “Camera render out a single (selected) object” is more realistic? Note that even in this case a result can be far away from final render (with ray-trace reflections for example)

#5

Igors

Thanks for the reply. I think that perhaps I’m not making myself entirely clear. I’ve only offered up the idea of mimicking the hypershade because its such a common example of nodal based methodology of constructing shaders. Perhaps another example is in order.

Remember Pixels3D? They’re still around, but have gone way under the radar lately.

They offer a sub program within Pixels3D called Shadermaker Pro. This could be another fine example of what I think Konkeptoine could offer. I completely agree that thanks to the new shader API in EIAS, Konkeptoine should do all that it can to moderize its interfaces with graphs, sliders, and such…however, the approach to making a shader is still fairly linear and numeric in nature. The shader api still fails to provide a creative experimental approach to trying new things. Imagine another Konkeptoine product that understands all of your existing shaders and has the ability to construct new materials and shaders variations through nodal based methodology instead of EIAS’ numeric materials approach. It would then save out either shader presets for the shader palette, or write out materials that could be read into EIAS. It would definitely be a different program from EIAS. You could provide a limited renderer of your own to previsualize the basic results. In my opinion it really isn’t too necessary to get Camera involved. The previews you provide in your current shader prevews aren’t really true representations of the final Ray Traced look. Or perhaps there would be a way for this product to write out camera temp files that could be utilized by Camera to render a test sphere. Surely the interface to Camera isn’t that guarded. I would think that EITG would consider working with you on this if it could see the huge benefits involved.

Think of it this way. A device like this would greatly increase your current shaders’ desireability. I would think that users would consider buying more of your shaders if this product really provided a new, nodal and graphical approach to the process. Other shader writers could write to meet this program’s new approach and it could eventually become the defacto way to construct EI Shaders and Materials.

#6

Hi, Brian

Thanks for your extra explanations, “numerics” confused us a bit. Now we see you make accent on node system: everything (or almost everything) can be controlled by a node, not a numeric value. The control node also can be controlled by other nodes etc. In other words any shader can refer to any number of “sub”-shaders etc. The hierarchy tree can be visualized.

Hmm… programmers love such tasks very much! :slight_smile: (and we are not an exception). “Link anything to anything” is enough abstract to be attractive. The node scheme looks much more powerful and elegant compare to “reactive” (never understand why not “Diffuse Bias”?)

However, in our opinion, the practical effect of nodal way would be much less than it looks first. How many “levels of hierarchy” a real material needs? Well, 2 (enough often), 3 (enough seldom), 4 (? we can’t imagine such material). For us “reactive” always looked ugly, nevertheless we agree it covers not all but a lot of needs. The nodal scheme allows “more combinatorics” but “more creativity?” - we aren’t sure.

The related aspects are also absolute not excited. For host it’s really hard to develop a really big thing “for next generation of shaders only”. For third party developers it’s hard to update existed shaders and provide 2 versions of each one for compatibility.

So, sorry for our pessimism, but imho we’ve minimal chances to see a nodal system in near future

#7

Don’t you just love the written word. So easy to misunderstand.

The ability to visually plugin and reroute different channels of a shader or material is what I’m trying to suggest here. As you stated, “The hierarchy tree can be visualized.” Is precisely that.

The material editor in EIAS is good, but the way it presents itself to the user is completely noninteractive or graphic by nature. The user is presented with a number of numeric fields and a tiny little shader ball to judge their results on. Ultimately EITG should address this issue, but their hands are full. Shaders also suffer from the same problem. Open up Atlas, NX, or Mforge and the user sees nothing but numbers.

You stated, “How many “levels of hierarchy” a real material needs? Well, 2 (enough often), 3 (enough seldom), 4 (? we can’t imagine such material)”

Perhaps we should clarify here and also start talking about the integration of textures as well. EI’s transfer modes provide excellent photoshop style layering, but its impossible to see how the textures interact with one another. This nodal shader/material/texture manager could also perform this task. The program acts as an mixing lab which allows the user to better see what’s going on. Personally, I can see a material, shader and texture combinations that are dozens of levels deep. 2, 3 or 4 would never be enough. Once you create a new look, the nodal manager would transfer all the proper settings back into EI in the form of a master material that contains all the necessary settings for everything. Textures, shaders and the usual diffuse, transparency, specular etc… channels.

The manager doesn’t become a new giant uber shader that does everything, but rather understands the existing indivdual shaders and helps the user interactively and graphically make combinations that would drive the shaders and materials with the proper number values. If the process is revolutionary, I think EI users would clamour towards your products like crazy.

#8

Oh and one other thing. Right now you have to modify and upgrade all of your shaders to take advantage of the new api right? If you had this program, it would take care of that for you and then some. Write whatever interface you wanted to program your shaders outside of EI… it wouldn’t matter… when you’re done, you just transfer the numeric results back into EI.

#9

Hi, Brian
>> The ability to visually plugin and reroute different channels of a shader or material is what I’m trying to suggest here. As you stated, “The hierarchy tree can be visualized.” Is precisely that. <<

>> Open up Atlas, NX, or Mforge and the user sees nothing but numbers. <<

Let’s see Pixels45Manual.pdf, it’s the documentation for Pixels3d you noticed. Please look at Figure 14.22: Bump Added (page 181). The figure is clear and intuitive: any “in” can refer to any “out”. Here are other things we see:

  • in EI the graph cannot be used for direct editing, EI textures/shaders occupy much more screen space and require separate windows. Thus such graph would be called sometimes only to see a situation “overview”;

  • the graph does not make less numeric inputs, all nodes still require all their parameters to be filled;

And if so, why we need a big graph that does a little? How about just a small button that can be added near to desired shader’s parameter(s) to indicate it’s controlled by another node? Yes, it would be very usable, it’s much more powerful than “reactive”, but imho it’s not a revolution.

>> Perhaps we should clarify here and also start talking about the integration of textures as well. EI’s transfer modes provide excellent photoshop style layering, but its impossible to see how the textures interact with one another. This nodal shader/material/texture manager could also perform this task. The program acts as an mixing lab which allows the user to better see what’s going on. Personally, I can see a material, shader and texture combinations that are dozens of levels deep. 2, 3 or 4 would never be enough. Once you create a new look, the nodal manager would transfer all the proper settings back into EI in the form of a master material that contains all the necessary settings for everything. Textures, shaders and the usual diffuse, transparency, specular etc… channels. <<

Let’s use 3dsmax material as an example (we are not enough familiar with Maya). Max allows to preview a whole material with all maps/procedurals that can be also previewed separately, the preview can be enlarged as needed etc. And… still not enough, in many and many cases need to render. Hmm… maybe this task has no solution at all :rolleyes: ?

#10

Because the preview does not calculate the scene lighting right ?, and because scene lighting has such a big impact on your materials the only real test is a “proper” render, so maybe a “render region” feature would be a better solution.

The only nodal material system i know is XSI, there is no material preview (except in XSI advanced) it relies on the render region tool, those who use it seem to think its a good solution.

But its also the most horrid material system i know.

Reuben

#11

Hypershade in Maya is a nodal solution. Works well. Especially when you can route multiple textures with a single placement node. Very handy.

#12

I’ve heard a lot about Hypershade, sounds like a powerfull system, do they still do a PLE version ? maybe i take a look.

Reuben

#13

Hiya,

For a bit of a 101 on Nodal Editors, try this video of Lightwaves upcoming new Editor:

http://www.newtek.com/lightwave/lw9_demos.php

Quite interesting. Very powerful stuff.

ta

nige.

#14

For us “different lighting in preview and render” is not a problem, we are quite happy with preview lights. But the problems of preview are:

  • all RT is lost;
  • GI + bump is very different from Light + bump;
  • often it’s hard to estimate speculars (especially anisotropic);
  • (maybe most important) unavoidable adjusting each shader/texture to the real object’s size

We agree with critique EI material’s preview as a very poor, but anywhere preview != render, there are only more or less informative previews

#15

Ahh yes material scale !, forgot about that one… :smiley:

Reuben

#16

One of the first Node based shading systems I ever came across was Darktree:

http://www.darksim.com/html/dt25_description.html

They’re currently at version 2.5, and run on Wintel only. They do offer an API so third party vendors can write plugs to connect with rendering software.

Maybe it would be possible to make this available for EIAS?

#17

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.