OctaneRender® for Maya® beta 3.03a [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:

• Removed the automatic image saving in IPR mode (to not slow down the scene objects moving).
• Portal material swatches now are showed the same way as in other materials.
• Fixed expression editing bug.
• Fixed FOV calculate in the case height of film is greater than width.
• Fixed bug crashed the render when UVs indices count of some object was less than vertex indices count.
• Fixed one more rare crash bug.
• Some memory leaks fixed...
• Optimized the big-mesh particles and instances loading (TBFX's forest of trees now loads about 16 sec on my machine). It is not final optimisation, I can't optimize the logic well when the code is forced to change constantly due to excellent speed of improving the Octane engine the last time... When the engine will "stay still" for some time with new features - I think I will be able to optimise the scene loading speed even more.

NEW FEATURES SINCE LAST RELEASE:

• Partial mesh refresh is implemented.
• Clipping feature ("Near Clip Depth" attribute) added to Octane Camera.

KNOWN ISSUES IN THIS VERSION:

• Again, a lot of new code was written to implement the above, so if you encouner some new issues or crashes - just post it here, I will release the "quick-fix" immediatelly.
• The strange "low light" issue still exists. I've got the info that Octane engine works such a way - it scales the power of emissive object by the object's scale loaded in matrix. So, one more workaround to eliminate (if you use the "Movable proxy" emissive objects) - is to set the scene scale factor to 1.0 in Octane settings and do not scale the emissive objects.

DOWNLOAD

New version HERE.


Yours,
The OctaneRender™ Team.

[jmfowler]

awesome Jimstar.

I found that strange emmisive scaling effect - so what I sometimes do is combine the geometry that shares that emitter into one object - so then there is a uniform emittance happening with the geometry using that emitter - it just makes it easier to get the lighting correct - some of my scenes have LOTS of lights, including LED light piping. I found this problem when I had multiple backlit panels of different sizes all using the same emitter but changing brightness - the smaller they were the brighter - once i combined them - fixed

[TBFX]

Awesome work JimStar! Just tested on my test scene which has 5 trees of the same complexity as the one I sent you with 260 instances in total. Loaded in 28sec where a single tree takes 21sec. Vram only went from 68mb for one tree to 69mb for 260, awesome!

I'll test it on my real scene later today which Ideally I need around 70,000 trees so I'll see how I get on as I step it up to there.
Want to play with the mesh update now but have paying work to do

T.

[jmfowler]

Jimstar - mesh update is awesome - Question, Is there any reason not to have 'movable proxy' switched on for all objects? Is the renderer slower with it switched on ?

[Slimshader]

Jimstar - mesh update is awesome - Question, Is there any reason not to have 'movable proxy' switched on for all objects? Is the renderer slower with it switched on ?

This version is very stable for me.
Loading several tree instances is slow but doesn't crash.
Mesh update IS awesome!
Also a good question regarding 'movable proxy'.

[TBFX]

Have done up to 36000 trees now. Took 14 min to load which is workable. Memory usage barely moved from one tree so that's excellent!

There are a couple of issues so far.
1. When the number of instances gets over about 8000 my ground plane picks up the wrong shader unless I also make it a movable proxy. (in my tree scene anyway) problem is this also seems to affect my octane light.
2. If I have multiple trees in the instance node octane is only picking one to render even though the bounding boxes are different sizes which indicates that maya is distributing them in the particle system as expected. I need to do some more investigation on this one as simple objects like a sphere, cube and cone still work as expected but I ran out of time today.

T.

[JimStar]

Jimstar - mesh update is awesome - Question, Is there any reason not to have 'movable proxy' switched on for all objects? Is the renderer slower with it switched on ?

Yes, the render will be much slower with couple of "Movable proxy" objects.
The reason to use is e.g. as follows:

• If you have the scene that does not fit into your VRAM - you definitely are forced to load the instanced objects as "Movable proxy" (there is no sense to use "Movable proxy" for non-instanced objects in this case). In this case you sacrifice the render-speed for the ability to render on your amount of VRAM at all.
• If, as in the previous case, the scene is big enough and has a lot of instances, but fits into your VRAM without using the "Movable proxy" objects, then you have two choices:
  • If e.g. you render the big animation sequence and don't need very fine quality of every frame, then you will lose a lot of time on voxelizing one big mesh every time it is loading to engine, this time may be a lot more than the rendering time itself. In this case you may sacrifice the speed of render, but dramatically increase the scene loading and voxelizing time using all instanced objects as "Movable proxy" (there is no sense to use "Movable proxy" for non-instanced objects in this case).
  • But if e.g. you need very fine quality of one frame only and you have to render this scene a couple of hours, then the voxelizing time does not matter so much even if it will take 30 minutes... So, in this case, if you have enough VRAM, you better disable all "Movable proxy" checkboxes. The render speed in this case will be much faster, almost the same as in 2.58 branch (and the voxelizing time of one scene's big mesh will be almost the same too).
• If you just need to edit some meshes (instanced or not, no matter) during the IPR session and see the results "on the fly" - you may just enable these objects as "Movable proxy" and sacrifice the render-speed for the ability to make the live-editing...

Something like this...

[jmfowler]

jimstar - thank you for your explanation on movable proxies.

not sure whats wrong yet but 2 previous scenes from 3.03 failed to render in this new build from the command line both exited with error status, will try to work out why on Sunday. thought I would mention it for anyone who tries command line stuff over the weekend.

[TBFX]

OK, here is some more info on the issues I reported a couple of posts back.

1. When the number of instances gets over about 8000 my ground plane picks up the wrong shader unless I also make it a movable proxy. (in my tree scene anyway) problem is this also seems to affect my octane light.

Here are some pics to illustrate this. JimStar, these are done with the scene I sent you so they will be easy enough for you to replicate. Just scale the ground plane by a factor of 100 before you start emission to give the scene more room, set the env to texture instead of daylight and lower it's texture slider to about 0.4 then add an octane light like you see in the images below.
As you can see everything reacts as expected up to nearly 8000 instances then once I go over that the ground picks up the wrong shader and the light goes off. Then if I make the ground and light movable proxies the correct shaders come back but of course my light is then dim due to the issue we are already aware of.

2. If I have multiple trees in the instance node octane is only picking one to render even though the bounding boxes are different sizes which indicates that maya is distributing them in the particle system as expected. I need to do some more investigation on this one as simple objects like a sphere, cube and cone still work as expected but I ran out of time today.

I've tested this thoroughly now in various scenes with different geometry and tracked it down. Everything works fine if the multiple objects instanced to the particle system are not movable proxies but if they are Octane is only getting the first one and using it for all others.

I have also had some old scenes fail to start rendering in this version only in the interface not in batch mode(though they would no doubt fail there too) but they were very old and not ones saved with the 3.xx branch installed. Will check them out and send crash dumps if I get the chance.

T.

[JimStar]

Thanks to all for reports.
Will try to reproduce it now...