OctaneRender® for Maya® beta 3.0a [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 bug when meshes without UVs did not rendered.
• Removed the confirm render question.
• Fixed mesh normals bug.
• Fixed the bug when parent transforms were not inherited.
• Fixed swatch refresh bug (sometimes swatches were not refreshed after IPR).

NEW FEATURES SINCE LAST RELEASE:

• Added particles support.
• Added "Virtual material" feature. If you connect a couple of Octane materials to the Octane material and choose virtual material type ("Random" or "Round-robin") and connect this material to the object, you will get the distinct materials for the particles, or for mesh instances (for particles you should set the rgbPP attribute to some "ramp" or random value, just for particles "tagging")... See the "Virtual material" rollout in material attribute editor, or the "virtualMaterial" attribute of Octane material nodes.

KNOWN ISSUES IN THIS VERSION:

• The meshes collapse is not optimized so far, so the render speed may be slower than in 2.58 branch.
• It is the very test version, so write here please about all strange things that you encounter...

DOWNLOAD

Next version HERE.


Yours,
The OctaneRender™ Team.

[TBFX]

Nice work JimStar!

Everything mentioned above seems to be working well, it'd be great if in the future we could assign weighting to the virtualMaterial's so that we could get a percentage more of one than another etc. Though in the mean time we can just have duplicate shaders in the list to achieve this which I don't think will be too costly render wise, it could eat a bit of VRAM and texture space though so a weighting would be great.

I've found one strange behaviour (it was actually there in the last version but I thought it was probably tied to the other normals bug)

If you create rotated instances their normals seem to be locked and rotate with them, however if you check the smooth option in the octane shader they come right. The strange thing is they render correctly either way in both the geo and shaded normal modes in the infoChannel kernal.

Images attached, in this example each instance was rotated 10 degrees on creation.

T.

[face]

I don´t know if it works and if the last standalone 3.02RC hasn´t this bug, but i would try to replace the octane.dat from the Maya plugin with the new one from the RC.

face

[jmfowler]

Thats great Jimstar thanks!
3.02 is out - Now you can compile a kepler version?

Cheers,
JF.

[p3taoctane]

can you explain the virtual material a little.
I'm trying to intuitively hook things up and not having luck.

Sorry it is probably obvious but I'm acting brain dead

Peter

[TBFX]

can you explain the virtual material a little.I'm trying to intuitively hook things up and not having luck.Sorry it is probably obvious but I'm acting brain dead

No, it took me a couple of goes too. It's a little counter intuitive, you conect an octane material to your base object and then conect the virtualMaterial out pin of this shader to the virtualMaterial input pins of all the other shaders. Only the first material assigned to the base object needs the virtual material turned on to random or round-robin. You can also select the secondary material in the node editor and click the add selected in the base materials attribute editor but this is a bit of a pain as you need to use focus in the attribute editor to get one material selected ad another showing. It did show me how to do it though.

Here's a pic
T.

[p3taoctane]

Thanks mate I will give it a try.
I am assuming that the different materials one plugs into the base virtual material are the ones that randomly/round robin get assigned to your instances (or particle instances) so the more of those (input ones) you have the more your instances have a variety of shaders etc.

Am I getting that right.

So lets say you have an invisible object sitting inside a tree mesh. You emit particles from the invisible object and assign leaf mesh instances to the particles.

You want random leaves to be assigned to the leaf instances... so you make a bunch octane leaf shaders and plug the virtual out into the virtualM ins of all these leaf shaders.

Then you assign the virtual base to the invisible emitter.... or is that part not right?

Thanks

Peter

[TBFX]

Then you assign the virtual base to the invisible emitter.... or is that part not right?

You apply the virtual base shader to the base object that you are instancing to the particle, everything else you are spot on.

Unfortunately I've just discovered the assignments are not consistent through time (in my test scene anyway) so not much use for an animation. This could have to do with the value I've given the rgbPP (I've just used a standard default ramp which will be changing the rgbPP per frame) so I'll do a bit more experimentation and let you know how I get on.

T.

[TBFX]

Unfortunately I've just discovered the assignments are not consistent through time (in my test scene anyway) so not much use for an animation. This could have to do with the value I've given the rgbPP (I've just used a standard default ramp which will be changing the rgbPP per frame) so I'll do a bit more experimentation and let you know how I get on.

Yes. It was just the rgbPP method. I replaced the rgbPP lifespan ramp with a creation expression to just assign a random number to each particle and the shader assignments are consistent through time.

T.

[p3taoctane]

Cool thanks for the clarification.

I am not that experienced with particles and expressions. Are you creating a "particle shader" like a smoke or fluid?
Sounds interesting.

I built this binary tree using particle instances a ways back. I am guessing it is the most primitive use of instances there is but it worked at the time. I have to bone up on using particles for more creative work.

Thanks for the tips. Have a good eve.

Peter