OTOY Forums

This is the test release

Otoy® is proud to announce the availability of a new version of OctaneRender™ for Maya®
The world's fastest and most feature-rich unbiased render engine that integrates completely into Autodesk® Maya®.

Maya® Version Requirements

This release will work with Maya® Versions 2013, 2013.5 / 32-bit & 64-bit, 2014 64-bit and 2015 64-bit on MS Windows operating systems.

Notes regarding features/functionality

OctaneRender™ for Maya® implements almost full functionality of OctaneRender™ standalone inside Maya®.

COMPATIBILITY AND OCTANERENDER STANDALONE REQUIREMENT

To run OctaneRender™ for Maya®, you need to also have an activated OctaneRender™ Standalone copy activated on the machine you wish to install the plugin onto.
You cannot purchase and use only the Maya plugin and use it without also owning an activated copy of OctaneRender™ Standalone on your machine.


HOW TO PURCHASE LICENSES

Go to our online shop here: http://render.otoy.com/shop/

If you do not own an OctaneRender™ Standalone Edition License yet:
You can purchase both the OctaneRender™ Standalone Edition and the OctaneRender™ for Maya® Edition as a reduced price bundle, purchase the bundle priced at 359€

If you already own one or more OctaneRender™ Standalone Edition licenses you want to pair the plugin with:
Purchase an "OctaneRender™ for Maya® Beta License" priced at 199€

You can also purchase a 3, 5 or 10 pack of OctaneRender™ for Maya® licenses, just like OctaneRender™ Standalone Edition packs.


OCTANELIVE

Just like OctaneRender™ Standalone, the Maya® plugin product also needs an additional OctaneLive license and be activated on a machine.
This has to be done in the plugin interface panel in Maya, and is covered in the included PDF manual.
It can only be done after an OctaneRender™ Standalone license is already activated on the machine in question.


CHANGES AND FIXES SINCE LAST RELEASE:

• Fixed Octane sun bug.
• Fixed plane light source bug.
• Minor fixes...

DOWNLOAD

OctaneRender for Maya 1.55 - 3.1 (28.8MB autoinstaller file)
OctaneRender for Maya 1.55 - 3.1 Demo (26.7MB autoinstaller file)


Yours,
The OctaneRender™ Team.

awesome, let me download and test thanks for all the effort you have put into this JimStar

Plane light is working (fixed)
Sun Direction is working (fixed)
LiveDB is working
Convert all textures to Octane working

thanks so much for all the fixes and updates

Cheers Jim.
Will test this.

Yeah, can confirm the Plane light works now, cheers.

The noise issue is still present in the PMC kernel.

And looks like the response curves aren't updating.

cheers,
Steve

Thank you for update

1. Something strange is now happening with swatches in hypershade. After closing render view they don't refreshing. Even after some modifications in shaders swatches appears randomly, in most of a cases they are black,
2. keying of Sun rotation don't working in batch render.

And what's about following issues, do you think it's possible to fix/implement them in the next release?

Rendering to more than one subdirectory now is working but them still need to be created manually,
swatches in hypershade are going black after modyfying shaders while IPR render is active,
there is still some mess with output frames file format. I really count on support for 16-bit file formats,
camera motion blur?

Xgen support would be also very desired.

Cheers!

Vyoor wrote:Rendering to more than one subdirectory now is working but them still need to be created manually,

Did you check it on this version?

Vyoor wrote:swatches in hypershade are going black after modyfying shaders while IPR render is active,

This is intended behaviour. GPU is working on your IPR, so all the swatches wait for the resources to refresh.

Vyoor wrote:there is still some mess with output frames file format. I really count on support for 16-bit file formats,

I already wrote about it long time ago. Maya's issue, not plugin's. Moreover, this issue is still present during all the versions: Maya's plugin API easily allows to save any chosen 8-bit image type, but if the parameter "save to 16-32 bit" is given to the same function - it does nothing. So, I was forced to place some "stub" into this place which writes always 32-bit exr file by plugin's stub if any HDR format is chosen from Maya's formats list. I can't change this list adding e.g. "EXR 16" and "EXR 32" by standard Maya's API (it does not have standard means for it) - only by some ugly hacks. So, either you always have 32-bit if these HDR formats are chosen, or always 16-bit. There will be a lot of complaints if I change it to 16-bit only, so taking into account cheap disk memory - there is 32-bit chosen, awaiting for Maya's developers finally fix this bug...

Hi Jim,

thanks for the info.

For sure, keep the 32 bit format. We don't want to throw away any image data.

As for the .exr format showing in the Image format list, when you chose a render engine like mental ray, for example, the option for 'OpenEXR' becomes available. I guess this may be straight forward for Autodesk because this render engine ships with Maya, but I'm pretty sure the third party render engine, V-Ray has the .exr. option in the list too.

Cheers again for the Maya updates, and apologies for banging on about this .exr format option.

cheers,

Steve

prodviz wrote:As for the .exr format showing in the Image format list, when you chose a render engine like mental ray, for example, the option for 'OpenEXR' becomes available. I guess this may be straight forward for Autodesk because this render engine ships with Maya, but I'm pretty sure the third party render engine, V-Ray has the .exr. option in the list too.

This is exactly what I meant when I named the way it is implemented by these plugins - "ugly hack". As it is made by hacking of internal Maya's startup scripts which are installed together with Maya's distributive itself and are the part of Maya itself. E.g. mentalray just hacks standard Maya's internal function inside Maya's startup script module, eliminating its execution completely, setting right at the beginning of this function this (where it builds its own image formats list): This script is hacked on the Maya's distributive level, Maya is installed already with this script hacked this way.
Not my way, I'm not doing things so dirty. Just imagine - some other plugin wants to add its own "file formats menu". What this plugin will need to do: it will need to hack this Maya's script during plugin installation. So, e.g. it will add its own block near the mentalray's one: Now imagine, some third plugin wants to do the same. It will need to add the same block near the mentalray's one. BUT. This plugin knows NOTHING about existence of the second plugin. So, after the third plugin will modify the same script - only the mentalray's one and the third plugin's blocks will remain inside this ugly hacked Maya's function. The block of the second plugin will be lost, and all the users of the second plugin will get some strange glitch where all the image format list of this plugin will return back to default... And they will start to complain to second plugin's developer about strange bugs...

I'm not programming this way. If Maya will implement some normal robust mechanism for having plugin's own image formats list - I will immediately add the support of it. Or if Maya developers will include Octane's code into default Maya's installation later - I will add the same blocks as mentalray has into standard Maya's scripts. Before that - I will use only standard and robust Maya's API mechanisms to implement the Octane plugin's features... I don't like to turn this plugin (or any other plugins) into unstable state by these ugly hacks.

Cool, sounds like a good approach.

Thanks again, Jim.

Steve

prodviz wrote:Cool, sounds like a good approach.

Thanks again, Jim.

Steve

Moreover, I think you can imagine further, what will happen in the case both plugins will be loaded at the same time, mentalray plus some other plugin, both having these blocks inside this hacked function: only one of these image formats lists will be loaded. So, some of these loaded plugins will be out of luck.