Roadmap for the maya plugin

[calus]

Is there maybe a color attribute type? That has the color picker in the UI automatically?

That's what I think, maybe,
when I create a color attribute I have to do it like this :
( I LOVE mel )

addAttr -ln hardwareShader -usedAsColor -h 0 -attributeType float3 $mat;
addAttr -ln colorR -attributeType "float" -parent hardwareShader $mat;
addAttr -ln colorG -attributeType "float" -parent hardwareShader $mat;
addAttr -ln colorB -attributeType "float" -parent hardwareShader $mat;

maybe the usedAsColor tag and/or the name for each float is important for color picker.
But as you certainly used this tag, maybe you have no choice, you have to do a mel AEtemplate to make the color picker work.

(as you'll see at my link at the bottomn of the post , for mrampattribute, the mel template seems to be inevitable to display the colored widget )

Do you mean those with gradient widget?

I figured you were going to need this for volume gradient (I just recently find out how to deal with gradient color widgets, was looking to had one to octane gradient texture node)
and here maybe a useful link :
http://www.chadvernon.com/blog/resource ... attribute/

[calus]

@Kai, about auto-generating AEtemplate

In the Maya bonus tools there is a tool called Attribute Editor Template Builder.

You select one node and launch the tool, the attributes are listed and you can build like custom xml AEtemplate .
https://knowledge.autodesk.com/support/ ... 2-htm.html

So Maya users will be able to build there own templates for all the new octane nodes and you won't have to do MEL
More seriously I guess the process may be automated to generate or update mel templates each time you make a new build .


Also thinking, Maya toolTips system use AEtemplate.mel in conjunction with AEtemplate.res.mel files.
Is there a way to automaticaly extract from octane API the tooltips corresponding to each attributes ?

[itsallgoode9]

With the new update, how easily/quickly will we be able to change render settings considering it will all be done through the node editor instead of render globals?

I swap between kernels and settings really frequently when doing tests, so now whenever I want to do that will I have to disconnect and connect different nodes to do this? Or will it just be one node for all the kernals and settings?

I'm worried that any time I want to change a render setting i'll have to find the render kernal node hidden in the sea of 10's or 100's of other material nodes and attach it to my camera. Can you shed some light on how the workflow for render settings will work in v3?

[Refracty]

I agree.
Using node should not mean that all the settings are clustered everywhere.
The standalone version is a good example of functional system.
The user can access all the settings at once but it is also possible to work with individual nodes too.
So I hope that we see something similar in Octane4Maya. A flexible but less complicated system.

[calus]

I was just wondering, if we want material and upstream nodes (textures, transforms etc. ) in the main node graph (as in stanalodne)
or we stop at the geometry level and have separate node graphs for the materials (like version 2 materials basically).

Right, that's really tricky to design. For the moment I can't see either, a good way to transpose to Maya geometry and shading Engine the standalone node process as you did for camera and fluid shape. It seems too complex, the node editor would be a noodle soup.
So basically yes it seems we have to stick for now to the V2 way and still convert maya nodes shading at render time ...
(thinking more about this, finally I think it's possible to connect everything to the main node graph, it's just a matter of auto-filtering nodes and connection in the node editor)

How I see thing :

1/ Let's have first all octane nodes in Maya.
I really mean all nodes even geometry nodes and in and out pin nodes, geometry nodes would behave as proxy.
The idea is to be able to work in Maya Node Editor exactly as you would in standalone, with all the same octane nodes and make it rock solid.
It's important to really have all the octane nodes with exact same name and attributes, (even if the useless ones are not exposed in GUI in the end).
it would give us nearly for free a complete ORBX importer and would make easy to copy paste nodes from standalone to maya (with a little scripted xml parser).
Also Local DB could be used to import any nodegraph from Standalone.

2/ Nodify the conversion process
Once we have all octane nodes working as in standalone (in parallele to the V2 like process for maya nodes),
let's figure out how we can make maya nodes more connected to octane main node graph and less converted at render time,
I think it has to be a progressive process of trying and testing, case by case, to find out the best workflows and the simplest nodifications.
Also how to manage hair, instancer, xgen, lights, I have some ideas for that:
For example I can see how to prototype a script automatically attaching to any maya light type, a Gobo geometry shape/octane shader, driven by the relevant maya light attributes and trying to mimic the maya light. Maybe a script is good enough and we won't need a C++ node for that. but let's figure this out when we'll have all octane nodes .

3/ GUI part of things
Ideally you should be able to setup everything also from Attribute editor / shelf / render setting ... with no Node Editor involved, it's important as some Maya users hate nodes.
For that I'm afraid you won't be able to avoid mel coding, all maya GUI use mel...
I think maybe we can mimic more some Standalone GUI behaviors with Maya Attribute Editor (as Refracty suggested), I have some ideas for that, but will have to make some tests.
On the other hand I have no idea (yet) how to deal with octane style "in pin" nodes, I think it's going to be a big problem. We need in Maya the same thing at least for value nodes, RGB and greyscal nodes, as we can't have connected nodes for every attributes (nouddle soup).
JimStar already deals with that problem for V2 octane nodes but as you said he had to hack the AEtemplate from C++ and as a result a lot of things doesn't work as it should (no maya native widget, no drag and drop and a lot of quirks).
But let's figure this out later...

[calus]

With the new update, how easily/quickly will we be able to change render settings considering it will all be done through the node editor instead of render globals?

I swap between kernels and settings really frequently when doing tests, so now whenever I want to do that will I have to disconnect and connect different nodes to do this? Or will it just be one node for all the kernals and settings?
I'm worried that any time I want to change a render setting i'll have to find the render kernal node hidden in the sea of 10's or 100's of other material nodes and attach it to my camera. Can you shed some light on how the workflow for render settings will work in v3?

Actually as Kai show us in the screenshot , all we have to do is to select the current Render Target node (could use a button in octane shelf for example) then in attribute editor we have a tab for each connected node to the render target and can change all settings there. But for the moment there is still no way to swap the kernel node connected to the render target, you have to disconnect the current and connect another one.

For an automatic deconnection/create new node and copy attributes/connection of kernel node, the maya way to do this would be like when you convert a lambert material to a blinn material in attribute editor, only changing his type in the menu on the top of AE. would be ideal for that I think.

To change the camera linked to the render target it could use the same way you change the linked camera in a perspective projection node simply by selecting available camera in the list.

In the end it's pretty similar to what we have but better, with current I have to change a lot from render setting to camera settings to environment, with new nodes all is at the same place just have to change of tab

[itsallgoode9]

Cool. It sounds like it definitely has some benefits but maybe a drawback of of having to find the node amoung all the other billion nodes. Overall it sounds better since you could just make custom shelf buttons for different settings! Will the changes via the node would also be mirrored in the render globals too?

[calus]

I don't think so, Kai said there is almost nothing left in the render settings...
Just guessing here, I suppose Octane pref will stil be there, GPU choice, scene scale, a render target selector, and a button to open the current render target.
render target nodes are the new render settings...also as they are nodes we can make presets !!

[limeforce]

It sounds like it definitely has some benefits but maybe a drawback of of having to find the node amoung all the other billion nodes.

Which I imagine is as simple as doing a search for '*kernel*' or '*Kernel*' in the Outliner search box to give you a list of all Octane Render kernels in the scene (along with a few irrelevant nodes maybe).

[limeforce]

ANSWER POST

[ ... omitted ... ]

WYSIWYG is what I want, as few hidden relationships as possible! Drives me crazy as well!
(if maya allows me: for example for fluids I have to grab the fluid shape when doing the other connections,
there is an attribute "out grid" of type fluid though, but don't know how to create a connectable attribute with the API, support ticket to AD on its way)

[ ... omitted ... ]

Best,
Kai

Perhaps you're looking for an MPlug? Maya terminology is confusing sometimes and the term plug is not really used much in the user-facing docs.
http://download.autodesk.com/us/maya/20 ... _plug.html