Roadmap for the maya plugin

[calus]

if you ask me, things would be rather in the style of Maya. What would it mean if each developer imposes his own style? Old users would lose time to adjust and it may prefer something that is more convenient and similar to what they are accustomed.

Hey Nedan (and mverta), I think on the contrary, this node refactoring will also help to be more "in the style of Maya" like you said.
The way Maya makes things is to have nodes for everything and on top of that mel procedure glue to manipulate them easily in various editors, menu, shelf...
So in the end we'll have the best of both word:
- attributes really working like maya attributes in the attribute editor.
- or working in the node editor at the same speed as in standalone.

What would not be the Maya style would be to develop black box functionalities with no possibility to guess what they are doing internally so no way to workaround when there is an issue.

Obviously there is still a long way before octane could be "perfectly integrated" in Maya but I guess what Kai is doing will help a lot for that in the future.
Hopefully the plugin api in maya will also expand his set of commands on the way, which will help users to script useful additional tools for the community.

[k.a.schubert]

Okay,

to clarify and mitigate mvertas, nedans and everybodies doubts:

The new approach for the plugin will use the maya node graph (accessible in the node editor), not just throw in the standalone nodegraph in an extra window!

So it is exactly in maya style.

So it will use mayas node graph way more than now and display nodes that are atm hidden in octane render settings, or all camera types together in each maya camera.
There is a lot of stuff done in MPxcommands (more precisely 1 command), that should be done in nodes compute function.
I want to use mayas node graph, so we can have the same experience in maya as we have in standalone,
moving nodes arround quickly and not searching in super long menus.

So for example you want to have two different render passes nodes and exchange them quickly, right now you need to go to render settings and change all
options by hand every time, because only one state for all the render passes options exists.
With the new approach you would have two render passes nodes (two states) in the node editor and just connect the one you want to use with the rendertarget node (new as well).
If you want three or more, feel free to have them, just as in standalone.

Not sure how to structure geometry and their materials in that global node graph, obviously there can be a lot of those and it should not be too cluttered.
Probably splitting it up.
So one geometry node going into the render target node (symbolizing all geometry, or better one for each type [global, scatter, movable proxy, reshapable proxy]) and separate node graphs for each material, basically like its looking now, but changes are needed internally.

A major advantage of using the nodegraph is the code for reading attributes from the nodes and updating octane render gets only called, when necessary, ergo when attributes change.
Atm a lot of the update logic is located in a MPxCommand and executed each frame, no matter if the attributes have change.
That is for a part responsible for the plugin being slower than standalone.

Keep the input coming,
use cases I can think about are always helping,
best Kai

p.s. thanks calus, read your explanation after posting this

[k.a.schubert]

personally i prefer using standalone due to its robustness and speed of changing things around... always hated maya's system for materials. I own the current plugin for maya, however due to it functioning more like maya, it sits on the shelf. Integration of the node system would be excellent. I would imagine that it could be integrated/programed in a way that you could have the choice of using octanes more robust, flexible, and dynamic node editor or using the native old maya system.

one concern i have however, if the nodegraph is implemented, is how would the material inputs for the objects populate?

for example, the products I render consist of anywhere from 12 parts up to 500 parts (computer systems, monitors, and other computing electronics).

the way I currently handle this and make things manageable is assign materials in maya to what i need to (nothing in particular, just quickly throw different blinns at everything as placeholders). when i bring it into octane standalone I have the nodes I need and nothing more. On the other hand, when i export as alembic and populate material nodes based off of the objects, its unusable since there is a string of hundreds of nodes. Point being, I hope that the plugin will be able to do like stand alone does and not populate per object, but per assigned shaders.

Hey gah5118,

just exported with alembic in a different support case and I see what you mean.

Have to put some thought into this, I'll keep it in mind when I come to the geometry managment.

But from what I see, its alembic specific. Have to see how I can influence the export I guess.

Best,
Kai

[gah5118]

awesome!

some notes regarding alembic through many discoveries from headaches:

in short, the current octane exporter is 90% fully usable... it is just missing some features like hiding and showing objects. If you use octane materials with the octane exporter, the modes populate based on those. however, if you want to be able to hide and show parts in the animation sequence (we hide / show parts a lot for installation manuals) I have to use maya's exporter and apply materials to faces in order for the nodes to populate correctly without all objects populating their own material.

I go more in depth about this in this thread
viewtopic.php?f=9&t=53363&start=10

What would be nice for material handling; is to be able to assign "place holders" then be able to go into the node editor and connect to those.... maybe create a "node material" which can be assigned which will create a new pin. at that point, you can then assign materials just as you do in stand alone. At the same time, allow for directly assigning materials the standard "Maya" way for those who want that.

this gets to the root of a very important feature in my case and i am sure many others. the ability to quickly change materials.

I have node graphs that are setup to reroute one material to multiple material nodes on the object. this way they all get their own material ID and when the client decides to change the material, I can just plug the new material into one node rather than 50. Currently as far as i know, in Maya, it takes many more steps with much more time to trade out materials as quickly.


Just streaming more thoughts here, but what could also be a great feature, is to be able to create "group" nodes.... take for example, when you import an object in octane standalone, it is a single node with all included parts for that obj. A "group" node on the other hand could represent a group in maya. each group node would contain everything for that maya group just as an obj/geometry node does. Maybe this could be possible by adding an attribute option so when selecting a group you can check a box so it shows up as a group node


I hope this makes some sort of sense.

[mverta]

Thanks for clarifying. Curious to see the implementation!

[Vyoor]

Any news about Maya plugin?

[haze]

Any news about Maya plugin?

Kai is working really hard on implementing volume rendering of v3 right now. There is a lot of work to do, and hardly gets out of his seat! He'll probably give an update soon, stay tuned.

[QuinceHungaryKft]

Many thanks for the update, can't wait!

[Slimshader]

+1

[Jolbertoquini]

Any date for release on Maya plug??? We kind Update licenses so hope start testing soon with the Plug!!! Could we have some news please?