Gathering general ideas about node editing materials

To not completely sidetrack the discussion here, I’m taking the OT to its own topic.

I’d like to get some input from you guys (@t0ol, @jazzcat81 and whoever else might be interested) about how a node editing approach to materials should work. How would the workflow be, what parts would be necessary? What would you want to do with it. What’s good about other existing systems, what could be better?

Here’s a quick example of what Grasshopper and Scarab already can do for Maxwell Render emitter materials. It’s pretty basic stuff, but as I said, I’d like to expand the tool. Right now it’s just single layer materials but I’m working on that.

1 Like

I like the idea so much. in this day I was thinking exactly the same things :wink:

It’s so bad to know this is for Maxwell!!!

Chaosgroup hey?!?! are you alive?!?! Isn’t anyone in there?!?!

Keep working on this!

Currently talking to them :smiley: They seem to be pretty friendly.

Really!!?!? So It’s because me?

I tried to have some support for my SimpleMat editor with any kind of answer…
nor just a simple " nice!"

Could ask who is your contact? Corey?

PS: if you need any help, don’t hesitate to ask.

Might have been the time, last time I tired to contact them was just before the rollout of VfR 1.5 they were pretty occupied back then and that didn’t get far. I was routed through a few people.

SimpleMat didn’t work for me. Couldn’t get it to install. From what I can see, I’d guess you generate the vismat XMLs at your server and send them over, right?

  1. node editing approach to materials should work.

For me just having nodes is the biggest step up in productivity. I use Vray in Rhino as well as 3ds max and the difference is night and day. The visual flow of node based editing is just a delight. (there are a number of other issues which make Vray for Rhino unnecessarily ultra frustrating when compared with 3ds integration.

Also, plugging one bitmap into many components and inputs sure beats surfing back to it from each bitmap slot over and over.

If its for material design then the additional components in max are invaluable. Colour correct, output mapping, composite and mix map components are invaluable and allow for significantly more flexibility and creativity.

-How would the workflow be, what parts would be necessary?

Not sure what kind of feedback your looking for here? Nodal is already a leap forward from the current Vray. Also if your adjusting materials through grasshopper the more feedback you can give in the view port the better. For instance with Vray when I’m using a procedural texture like noise I can see it in the 3ds max view-port. In Vray for rhino I have to guess about my settings and render it to see it, that sucks! What a time waster. Not sure if that’s what your looking for, but in any case visual feedback is essential.

-What would you want to do with it. What’s good about other existing systems, what could be better?

Honestly, 3ds max has a pretty tight nodal texturing workflow, check out some videos on youtube. Its a world of difference. Throw in the additional components i mentioned above and its light-years ahead.

let me know if there is anything more specific I can talk about. Your GH component looks great though. I tried to get a color gradient applied to many objects in GH out as Vray materials before and it was a no go. Any components which would allow for a base texture to be modulated into a variety of materials which would be created and applied to objects will be super cool. If I was on Maxwell i would be all over that.

Be sure to have the latest, there a bug in first release.
Please let me know if you get or not to work.

Yes, it pretty simple py code send from a server. The idea it’s to have more simple upgrading of the main code.

I pretty much agree with everything jazzcat81 said, although I prefer XSIs interface for nodes, which IMHO is more flexible - i.e. youre not limited to materials, everything is nodal and adjustable - enviroment and light shaders etc, plus there`s much more ways to play around with data. It would be too long to list everything, its easier to grab a demo of XSI and check it out or find some videos.

Although I`m concerned with implementation. I dont know how Scarab works, but from what I understand its a sort of a plugin. I do think that the node system should be implemented directly in Rhino, in the box. This way all the renderers use the same UI, which is convenient for different engine users (vray, brazil, flamingo etc).

Right now it’s a plugin to a plugin actually. :smiley: But for RhinoV6 and on, Grasshopper would be an integral part of Rhino.

Grasshopper is a very extensible node editor. So in the future, this might be the generic, integrated node editor UI.
Scarab provides an interface to specific render engines. Problem is, that each engine works differently so parts of the node logic would have to be implemented specifically for each engine and look and behave differently. There are parts that are generic, though.
Rhino Materials are pretty simple. I don’t think it would be a good idea to blow up Rhinos own materials just to accommodate every conceivable material concept.

I dont see a problem here - it doesnt matter how different are engines, the UI for material creation can (and should) be the same for all, integrated within the main application. Without this you`ve got fragmentation. Chaos group is no shy of selling a product with a developer-version UI. Does it help Rhino?

And again, why invent the wheel? Take maya, max, xsi - you`ve got a unified UI for every renderer available, with nodes. Nodes are just a different way of interaction with the same stuff. In fact Max allows to toggle between nodes and the good old window-based UI. The node logic remains the same, you just got different channels for different renderers, different names, different nodes, labels/checkboxes and all that stuff. Its just the user interface.

It doesnt necessary means complexity, simple materials remain simple, like a Standart material with some basic channels diffuse/spec/blablabla within a single “base” shader node, while the more complex stuff (vraymat, braziladv, etc) simply goes into their own respective nodes. In fact I think its more logic this way for the end user.

Okay, so that’s what I was talking about. Grasshopper ships with Rhino and provides the unified node UI. Scarab adds the specific nodes for each render engine.
I try to keep the render plugin and Scarab in sync. So whatever you do in the plugins editor, reflects to referenced materials with Scarab and Scarab maintains its created and modified materials in the plugins editor.

Already there are simple materials in GH… whatever fits into a simple OpenGL shader. That’s basically what Rhino materials support, except for textures. Each render plugin has it’s own logic to translate rhino materials. Scarab extends that.