RenderMan UI

Could work. But there is some other UI ledgibility problems too.
I think a proper coded UberShader with a properly designed interface for the properties editor would achieve much better results. As opposed to just an auto generated single column.

Perhaps some method(python) to define for specific nodes/groups the drawing instructions for the inputs being displayed in the properties editor.
I think that would be good, to manually define the rendering of a node settings when displayed in the properties editor, to override the automatic 1 column generation. You could use python to describe the drawing of UI for each input for that type of node.

then how would you keep the flexibility of reusing different uber shader’s in larger node groups?

(i don’t want a generic ubershader, i want to modluarise and make components that are re-usable in larger shading networks…

so when I say ubershader that isn’t really in teh BI sense (though it could be)

The whole idea of ubershader is to create efficient and fast interface, fast creation of materials.
Node groups and re using components is not really related, but if you can make an excellent ubershader with the existing node groups system then great.
But if you make an UberShader with bad interface (wall of text) what is the point.

That’s why I was thinking about giving the ability to define with python the drawing of the node inputs when being displayed in the properties editor.

I disagree…

teh whole point of node groups is to provide efficient and fast interface, fast creation of materials. BUT with teh flexibility of extending them

whether the interface is @bad or not@ will be the same issue for properties or nodes… ie it needs some new functionality above what we have (boolean switches, the ability to group properties and teh ability to hide them or not based on the boolean switches…

doing it just in properties would just be dumb… (inflexible) hiding it in properties would be worse still…

besides… the way cycles handles textures as input to materials you’d need it in the node tree anyway… it’s what makes cycles so much friendlier to use when using textures… for renderman you’d have the user go back to the BI texture system?

for renderman you’d have the user go back to the BI texture system?

Which is exactly why I would like it. And, you probably think I’m alone with that opinion.

videos posted really dont show the UI. They show Maya running it, then the foundry’s Katana running it. Does it have a standalone ui?

Renderman has no UI, it is merely a set of tools, it is the host application that provides the UI!

3delight also has a path-tracer now. And it seems to be faster than arnold because of some optimizations like bidirectional pathtracing and several non-disclosed know-hows.

I’v run some test like half-a-year ago, and free 4-core version of 3delight was only slightly slower than arnold on my 8-core machine. I believe its the fastest CPU pathtracer at the moment (not tested PRman though) , but right now I’m more into Redshift, GPU biased renderer (kind of Vray on steroids :slight_smile: ).

Yeah, I also believe that GPU is the future, and I am pretty sure every major will go this way as the technology develops, in the mean time we’ll have to rely on good ol CPUs for production!