OctaneRender® for Maya® beta 3.03g [OBSOLETE]

[JimStar]

Refractive Software®/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 2011, 2012 and 2013 / 32-bit & 64-bit on MS Windows operating systems.

Notes regarding features/functionality

OctaneRender™ for Maya® implements almost full functionality of OctaneRender™ standalone inside Maya®. Materials from the Live DB are currently not available.

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://www.refractivesoftware.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 179€

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 99€

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.


BUG FIXES SINCE LAST RELEASE:

• Fixed the bug when some groups hierarchies included in render layer were not rendered (nedan reported).
• Fixed the bug caused the particles rendered wrong when "Age" was not "Particle ID" in particle's "Cycle options" (TBFX reported).
• The installator file is now of little less size, as the already unused cudart lib was removed.
• Few little bugs fixes...

NEW FEATURES SINCE LAST RELEASE:

• Improved the installator. Now it automatically sets the checkboxes "install the plugin" for installed Maya versions.

DOWNLOAD

Next version HERE.


Yours,
The OctaneRender™ Team.

[jmfowler]

thanks jimstar.

1) Did octane people give any answers as to when they will fix the engine animation problem I've been having?

2) Also are they going to be giving you an SDK that exposes camera motion blur?

cheers,
JF.

[JimStar]

1) Did octane people give any answers as to when they will fix the engine animation problem I've been having?

I have no comments so far about it. But you will be able to check if it was fixed in the next version of this plugin - it will use already the new engine version. Unfortunately I can't check this problem on my systems, as it exists only on your "mixed GPU" rig... So, just wait please a little, and you will be able to try it.

2) Also are they going to be giving you an SDK that exposes camera motion blur?

No. At least so far...

[jmfowler]

1) Did octane people give any answers as to when they will fix the engine animation problem I've been having?

I have no comments so far about it. But you will be able to check if it was fixed in the next version of this plugin - it will use already the new engine version. Unfortunately I can't check this problem on my systems, as it exists only on your "mixed GPU" rig... So, just wait please a little, and you will be able to try it.

2) Also are they going to be giving you an SDK that exposes camera motion blur?

No. At least so far...

ok thankyou.

[RickToxik]

Hey Jimstar! Thanks again for your good work. I have a question about the future development of octane for maya. Now that it is becoming more and more stable (for me it's almost as stable as any renderer now...), I believe that your efforts will go to following the changes in the native octane engine and the GPU market changes. But is it possible in a distant future that octane supports maya-specific features, i.e. a custom shader for fluidshape?...

I know of course you have million other things to do in octane for maya now, I was just wondering what was the philosophy of otoy/octane regarding software-specific features and plugin support. Maybe there's no good moment to ask right now but anyway!


I was looking at the GPU cards prices today, the new ones with thousands of cuda cores and the price I have paid three years ago for my Quadro fx: they took out a "0" at the end of the price lately. Octane is going to be really powerful (even more when you compare to other renderers) in two or three years, if you consider the how much the GPU technology advances faster than the CPU processing - thanks to the world of video games.

[JimStar]

Hey Jimstar! Thanks again for your good work. I have a question about the future development of octane for maya. Now that it is becoming more and more stable (for me it's almost as stable as any renderer now...), I believe that your efforts will go to following the changes in the native octane engine and the GPU market changes. But is it possible in a distant future that octane supports maya-specific features, i.e. a custom shader for fluidshape?...

I know of course you have million other things to do in octane for maya now, I was just wondering what was the philosophy of otoy/octane regarding software-specific features and plugin support. Maybe there's no good moment to ask right now but anyway!

It's not the simple question, as some of specific features in different renderers are implemented at different layers (at plugin or at engine level), so when and where they will be implemented - will depend on overall engine development strategy (I'm not aware of this strategy). E.g. - it does not make sense to implement some very complex feature using a huge codebase in plugin itself, if it will be realised in some of later versions of engine itself... E.g.: Arion supports mesh smoothing by engine (so all its plugins can just use the API instead of having own code to smooth meshes), Luxrender supports NURBS by engine itself (so, all its plugins do not need to translate "on the fly" NURBS to meshes), etc...
But at least so far I'm thinking about some ways to support of smoothing not loosing the shader-sets... I will try to do it in later versions... Shame that this part has very ugly and weak API in Maya - it can't be done the easy way. That is, the smoothing geometry data itself can be got using Maya's API, but in this case all info about "what poligon is connected to what shader" is lost. If we have only one shader connected to entire mesh - it's no problem, but if the mesh has a few shader-sets - it is the problem. I will try to do something with it in later versions by plugin means so far...

[jmfowler]

For me personally I don't think its at all necessary to render nurbs - not when there are so many options in maya to tessellate.

But I would be keen on a fluids shader if it was possible.

[magicU]

Hi Jimstar, I noticed recently that the Maya plugin seems to ignore which GPU I choose to render on - I have two GTX670s and no matter which box I tick it always renders using the first one (if I only choose one, that is). The standalone renderer doesn't seem to have this issue.

[TBFX]

But at least so far I'm thinking about some ways to support of smoothing not loosing the shader-sets... I will try to do it in later versions... Shame that this part has very ugly and weak API in Maya - it can't be done the easy way. That is, the smoothing geometry data itself can be got using Maya's API, but in this case all info about "what poligon is connected to what shader" is lost. If we have only one shader connected to entire mesh - it's no problem, but if the mesh has a few shader-sets - it is the problem. I will try to do something with it in later versions by plugin means so far...

For what it's worth here are my thoughts on smooth mesh display settings being used as render settings. I know many here have been asking for the plugin to recognize the poly smooth display level set by pressing the 1, 2, or 3 keys. I know other renderers such as renderman, mentalRay etc. do this but they have subdivision algorithms inside the renderer itself so it is almost safe for them to assume that if you have hit 3 in the interface it should treat that object as a subdivision surface at render time, but even then I'm not that happy about them assuming this and here is why.

I know a lot of users of Octane are one or two person bands (including myself at the moment) and to them it may seem perfectly logical to respect the display settings for an object but speaking as someone who has overseen several pipelines for creating animation and effects the last thing you want is the renderer to change how it will render an object based on what one artist may have pressed while they were working on a shot as a display option. That's what the interactive smoothing is, it's a display option. For rendering you should always have explicit control over your geometry detail through smooth nodes (which if applied after the shaders will respect shader assignment) Octane is for now at least a polygonal renderer, not a subD renderer and I want to control what level of smoothing I send to the GPU.

I'm happy for this feature to be added so long as it's an option that can be disabled but personally it sounds like a bit of work for JimStar that he could spend adding other features and I truley believe it is better to use smooth nodes and have a script to turn them on or connect them all to a single control attribute for render if needed.

T.

[jmfowler]

TBFX - my feelings about poly smooth are the same for nurbs, better to just do it manually and let jimstar prgram something else.

Jimstar/ anyone - I have a problem with my geometry render, see image, i thought it was a scaling problem and it is BUT when I freeze transforms OR do a geometry combine and seperate ( a better way imo ) to place the object scale at 1. it makes no difference. I've checked for normals, overlapping faces etc etc. I exported the geomtery to standalone and once I had the scale it renders fine. Any suggestions?? I found an entirely different piece of geometry having the same problem.

UPDATE : Ouch - if I place the geometry at the origin its fine.... Does this mean Octane doesn't have enough precision for my scene?
Sure enough as I move the geometry away from the origin I start to get more and more glitches - I think the engine might need a future option that allows larger floating point numbers for scenes that need it.