Roadmap for the maya plugin

[renmaxhb]

I'm checking on the forum every day for v3.

Me too!

[k.a.schubert]

weneedaroadmap.jpg (38.94 KiB) Viewed 5613 times

Sometimes... Just in the depths of maya API short comings (no blameshift intended).

You are totally right itsallgoode9,
sorry for that!

So update of status and roadmap, here we go:

Status

Yes RickToxik the plugin now uses nodes with all the benefits for extensibility and ease of use,
and I will be happy to make new nodes/edit existing ones once I release v3, so they can connect to mayas native and other plugins nodes.

Overview of the current state:

Maya camera connects to octane like this now:

Kernels are here:

Renderpasses, Renderlayers, Postprocessing, CameraImager are here as well and fresh from v3 Animationsettings and Filmsettings

Fresh for v3 as well are volumes for now controllable with maya fluids (early stage still)

As you can see I go for nodes all the way, cause I see the benefits,
the most obvious being, you can have multiple of any maya4octane node and switch quickly by connecting the one you want.

No more submenus in octane render settings.

So I was busy with laying a lot of groundwork for the node based plugin.
Just this week maya took a lot of my time, since it doesn't know the name of the node, inside the C++ node class itself,
even though there is a function for getting it.

Had a good laugh about "schizophrenic" C++ maya classes ( who am I? ) and than mitigated that shortcoming with quite some effort.
These things happen a lot and I'm sending support tickets to AD a lot.

But it gets better, cause every shortcoming so far resulted in a reusable solution for all the nodes in the plugin, which makes development faster.



Roadmap

Preview release v3 - this month (june (2016))
- Have to add a medium node for volumes (looking at ramp attributes there), so a release makes sense and you can play with it.
- uses old material nodes and geometry mechanism (not node based) (which I want to replace for the production release)
- Baking camera maybe

Production release v3 - next month (july (2016))
- Baking camera
- volumes fully integrated with maya fluids
- geometry (collector) nodes for different geometry types, replacing old mechanism for sending geometry to octane
- (so materials are still edited in hypershade
(workflow okay? Could have a nodegraph as in standalone, with everything connected there!?)
but material assignment workflow [right click menu on mesh in viewport] works with hypershade)
- Maya 2016.5 SDK integration

Estimated later release dates, just in case maya has deep pitfalls ready for me again!

A bit more on tuesday (Auckland time) next week,
since the Queen has a birthday to celebrate...does she really? IDK

Best,
Kai

[calus]

Roadmap

Preview release v3 - this month (june (2016))
- Have to add a medium node for volumes (looking at ramp attributes there), so a release makes sense and you can play with it.
- uses old material nodes and geometry mechanism (not node based) (which I want to replace for the production release)
- Baking camera maybe

Production release v3 - next month (july (2016))
- Baking camera
- volumes fully integrated with maya fluids
- geometry (collector) nodes for different geometry types, replacing old mechanism for sending geometry to octane
- (so materials are still edited in hypershade
(workflow okay? Could have a nodegraph as in standalone, with everything connected there!?)
but material assignment workflow [right click menu on mesh in viewport] works with hypershade)
- Maya 2016.5 SDK integration

Thanks a lot Kai, for the road-map update, that was really awaited.


About the camera matrix converter I'm curious,
why not take as input the world-matrix from the camera shape, instead of translate and matrix of the camera transform ?
(and the fluid shape also have a world matrix output )

Not sure what you mean about the hypershade.
Since maya 2015 hypershade is the node editor with a special configuration, do you mean internally you still have to use the functions of the old legacy hypershade ?
Though in 2016.5 we still have to use the legacy hypershade for container node, containers are still not supported in node editor
( I guess containers in node Editor = Maya 2017)

[itsallgoode9]

Thank you much Kai! I have many questions about this new interaction in Maya but I'll wait till I get my hands on it and maybe that will answer everything for me Thanks buddy!

[Jolbertoquini]

Quick question what about the render settings windows???
Would like to know more about it for older scenes and people who was using this before??

[limeforce]

So update of status and roadmap, here we go:

Looking good Kai, thanks for the update! So, just to make sure: we'll be able to connect whatever Maya node outputs & inputs of a suitable type to the exposed pins on Octane nodes? Finally, that looks way more like proper integration than before! I sure hope all the material inputs and texture nodes are similarly exposed. One of the more interesting things here for me is a more seamless integration with Substance, being able to connect substanceOutput.outColor (or any other texture+uv projection) directly to the Diffuse, Normal etc inputs on an Octane material would take a lot of unnecessary baking out of the equation and enable a way more playful workflow.

Keep fighting the good fight! Whenever it feels like you're drowning in the Maya API remember that the fruits of your labor will make a lot of people happy!

[Slimshader]

Thanks! I like where this all seems to be headed... maybe I'll upgrade to v3 and my rig as well sooner than later...

[ivankio]

Looking nice, Kai. Can't wait to alfa test that puppy. I totally understand that maya openness is a hell to develop. Black boxes are wanted by the user but not by maya TDs.

I'm a little concerned about that camera network. I fear if it is going the direction of current spotlights like Jolbertoquini talked about. Current spotlights are a pain to work with because their directions do not even comply to their Maya transforms and there's a fuzzy relationship with opacity and alpha shadows (besides not showing in the viewport).

I see camera transform connected, but not focal length/angle of view, clip planes or even stuff feeding back the resolution gate. I trust you are designing a workflow that you consider the most empowering and with Octane fidelity, but please keep an eye for WYSIWYG in the workflow. Current spotlight is very annoying and unpredictable as it accepts lots of parameters, but ignore some native parameters from maya and depends on alpha shadows from the render settings that have no obvious relationship.

I like nodes for materials and animation, but I hope we can accomplish a lot using only the attribute editor/render settings alone. I'm guessing "ThinLensCameraNode1" would be a tab of the camera transform along side persp and perspShape instead of a frame inside perspShape like it is currently. ThinLensCamera does sound like a job for the shape node, but I guess a single additional tab is fine too (I suppose CameraTransformConverter1 is auxiliar and doesn't clutter the attribute editor). I wish that some related parameters are smart enough to be read from maya, like focal length from perspShape and "scene scale" (or "rayepislon") could read from Maya's working units (cm, meters...). I think mental ray is one that have "derive from maya settings" in the materials for example.

Those loose kernels are also kinda scary. I hope they are easily accessible and not only buried inside the outliner with other hundreds of DAG nodes.

Again, I trust you are doing a great and overwhelming job, learning from what went wrong in the past. Just wanted to drop some concerns in case they help some wondering about "what would the user want" (like if you didn't have enough requirements yet, sorry )

[calus]

I'm a little concerned about that camera network. I fear if it is going the direction of current spotlights like Jolbertoquini talked about. Current spotlights are a pain to work with because their directions do not even comply to their Maya transforms and there's a fuzzy relationship with opacity and alpha shadows (besides not showing in the viewport).

Current Maya Octane light node is a black box using internally hard-coded octane nodes and attributes, with a hidden geometry shape and a very primitive maya locator.
This is the exact opposite of what Kai is doing ...

[renmaxhb]

"- geometry (collector) nodes for different geometry types, replacing old mechanism for sending geometry to octane"

really really great!!!