Roadmap for the maya plugin

[ivankio]

Personally I don't fancy those beautiful volumes, I'm a man of simple tastes. I'm hoping for:

1. correct triangulation of concave polys,
2. a hardware shader that shows better in the viewport (transparency, color management) and...
3. parses the usual parameters to exporters like fbx.
4. baking to texture

Is any of that in the roadmap?

[haze]

Personally I don't fancy those beautiful volumes, I'm a man of simple tastes. I'm hoping for:

1. correct triangulation of concave polys,
2. a hardware shader that shows better in the viewport (transparency, color management) and...
3. parses the usual parameters to exporters like fbx.
4. baking to texture

Is any of that in the roadmap?

Texture baking we will be looking at. Can you give us some more detail on 1,2,3 please maybe some examples of what you mean? Octane 3.0 does not support fbx, and what was the issue with concave polys originally? Feedback most welcome

[calus]

Texture baking we will be looking at. Can you give us some more detail on 1,2,3 please maybe some examples of what you mean? Octane 3.0 does not support fbx, and what was the issue with concave polys originally? Feedback most welcome

About the first point of Ivanko this is an Octane limitation, not the plugin, Octane doesn't support concave polygons.
But the plugin could be more clever, pre-tessellating non-convex polygons.
(Actually this is already the case when exporting trough Alembix/ORBX)

[k.a.schubert]

Personally I don't fancy those beautiful volumes, I'm a man of simple tastes. I'm hoping for:

1. correct triangulation of concave polys,
2. a hardware shader that shows better in the viewport (transparency, color management) and...
3. parses the usual parameters to exporters like fbx.
4. baking to texture

Is any of that in the roadmap?

1, 2: will have a look after the overhaul

3: see hazes answer

4: Yeah version 3 will have a texture baking camera node.

[ivankio]

I posted that previously on the user requests forum:
viewtopic.php?f=111&t=54008


About parsing material parameters to exporters (like FBX), let me try to explain:

Octane Render is not the only output tool we use for our projects, specially now with VR.
I guess that's a reasonable common workflow to assume, after all even Octane added the bake texture functionality.

Currently I have to branch my scenes when it's time to render (specially also because of the triangulation requirement). Then the client asks for a change and I rework it on the clean exportable scene. Now I want to render with Octane again, but the Octane scene is not updated. It has the octane materials applied, but it's too clumbersome to edit. I have to either import, triangulate and reapply the materials from the clean updated scene, or edit the Octane scene.

I wish I could work on a single Maya scene to render and send meshes to Unity. This is important when changes are needed. To that end, it would be nice if the hardware shader could parse to the exporters common parameters like albedo/diffuse color, opacity and normal map (even roughness and specularity although that would change drastically between renderers). I never meant to use fbx with Octane. Just that Octane materials could feed it's parameters to exporters. The override mentioned on the user request post could be good enough, although it's not nice to deal with double materials in the libraries.

--

But yeah, wrong triangulation of concave polygons and lack of viewport transparency*transmission*opacity are the biggest issues that are too outdated limitations. I can live without the exported parameters and texture links if at least the material names and assignment are kept. (although it get's more uncanny since Octane can bake lightmap, but can't embed or link into the emissive channel of a mesh being exported)

--

Meanwhile I'm catching a breath before once again reassigning all materials, triangulate the thing and hope that this is a wrap.

[Jolbertoquini]

Please Kai, Could we have a date a estimation of the release day???

Best
Jo

[Stollentroll1984]

Yes, tell us please how long it's approximately takes to release the plugin? Some days, weeks or months? You wanted to release a version in the middle of this month but this month is almost over. Its very important to know to calculate the further projects!

[calus]

@Stollentroll1984, it was not "in the middle of the month", exactly:

I plan to have a first version ready within the next month, fingers crossed!

So until Tuesday the roadmap is still valid!



But, let's be realistic, it seems a release won't happen this soon, so:

@k.a.schubert, maybe it's time to update the roadmap now ?

It's nice to see some progress but people also need some estimated dates for your plans about different things.
(trying to be exhaustive here)


Kai, do you have some plans and some kind of estimation time for :

a plugin release V2 or V3 using the Maya 2016.5 sdk ?
a preview release to just play with new nodes and/or some of the V3 features ?
a release including the ORCloud feature and stable enough to use it in production (ORC is not out yet but this is a much awaited service) ?
a production release for V2 with new approach nodes (if plans have not changed for that) ?
a production release for V3 ?

[Stollentroll1984]

@Stollentroll1984, it was not "in the middle of the month", exactly:

I plan to have a first version ready within the next month, fingers crossed!

So until Tuesday the roadmap is still valid!



But, let's be realistic, it seems a release won't happen this soon, so:

@k.a.schubert, maybe it's time to update the roadmap now ?

It's nice to see some progress but people also need some estimated dates for your plans about different things.
(trying to be exhaustive here)


Kai, do you have some plans and some kind of estimation time for :

a plugin release V2 or V3 using the Maya 2016.5 sdk ?
a preview release to just play with new nodes and/or some of the V3 features ?
a release including the ORCloud feature and stable enough to use it in production (ORC is not out yet but this is a much awaited service) ?
a production release for V2 with new approach nodes (if plans have not changed for that) ?
a production release for V3 ?

Oh calus, you speak from my soul. Kai, I know it's very hard to implement an maya2octane plugin. I would surely need some hundreds of years to finish this one but it would be nice to know when do you want to release the plugin, we all paid for. You allways say, you are on it and it's very hard. It's nice to know but it's nicer to know, when we can expect the first alpha? Maybe without the volumetric stuff for now, because it's not so important, as ivankio said. The actual plugin (V 2.24.2 - 7.24) is a horrible peace of software, which is quite useless.

[cyrillweiss]

but it's nicer to know, when we can expect the first alpha? Maybe without the volumetric stuff for now, because it's not so important, as ivankio said. The actual plugin (V 2.24.2 - 7.24) is a horrible peace of software, which is quite useless.

I have to second that and what ivankio wrote. Adding to that it bugs me, that I'm still bound to a geometry limitation for rendering and with Octane 3 this can be fixed. Also I don't need to say, how unstable maya gets, when the octane plugin is activated. Features like focus on a object doesn't work with an octane light - you will find the camera at the other end of the workspace.
What I want to point out: if the plugin uses the maya node system and therefore has less bugs, it would help me much more, than to know, that I can use volumetric stuff.
Since at least Version 2 the plugin was lacking behind all other plugins and on top of that, let maya crash repeatingly or let the grafic card driver crash - situations where debugging is a big pain and is not easy to reproduce. I was even surprised, that using GMH2 (http://www.thundercloud-studio.com/shops/gmh2/ - it only uses maya nodes/painteffects) while octane plugin is loaded, maya crashes.
About 20% of my time went just for debugging and workarounds regarding the octane plugin. There is even a workaround in the plugin (unique names) which shouldn't be necessary - none of other renderers need such a workaround and are much better integrated into maya. I'm aware that Jimstar was overloaded with different tasks and I guess he had his reasons, that the plugin had to end up how it is today. I'm much more positive, that at least now there is Kai, who is 100% working only for the plugin and it is to say, that we need a solid base, which works with maya, before the fancy stuff gets implemented.

I love octane for the speed, quality and the node based approach, but what I still miss, that octane render plugin should support:

1. concave polygons (no need for triangulation)
2. Smooth mesh (Button "3" in maya)
3. Subdivision creasing
4. Xgen integration (scattering, hair, aso)
5. hair plugin (http://peregrinelabs.com/yeti/, http://www.ephere.com/plugins/autodesk/maya/ornatrix/)
6. combining Maya texture nodes with octane texture nodes (ex. ramp texture, fractal noises, ..) or better/advanced octane texture nodes for example with ramp attributes
7. stackable displacement map or combination of maps
8. maya lights (like mentalray has additional attributes in maya standard light, octane can use own attributes in light, but the light position are the same, so it would be possible to combine different renderers) - also a suggestion about lighting: http://brograph.com/luminous
9. Spot Lights (there are workarounds at the moment, but are a pain with IES Light profile)
10. Viewport (sometimes materials in Viewport are visible, sometimes not)
11. Substances textures
12. All render passes, which are supported by the Version 3 Render core (ex. albedo)
13. Remove limit of 19Mio. Polygons (workarounds where necessary in certain cases, like with fluid meshes)

I'm looking forward to a successful development.
cheers
Cyrill