OctaneRender® for Maya® beta 3.03f [OBSOLETE]

[Joss]

Look, in your answer you didn't mentioned anything about different SDK versions, you just told it's "octane engine problem" to the user who has no any idea about how that thing works.

And let me now show you how do i see that from the end user PoV: 2.58 can render my project, and 3.03 cannot. That's all i see.
And while i could upgrade my machine, it's not on my budget for the next half of year, so, since it's you working for otoy/octane guys and not me, could you please forward report about SDK voxelization problem/other programming problems to them?
End user just reporting a problem, you decide what to do with that.

Thanks.

[JimStar]

And let me now show you how do i see that from the end user PoV: 2.58 can render my project, and 3.03 cannot. That's all i see.

That's NOT all you see. You see THE VERSION NUMBER, which corresponds to standalone engine version. And after I answered you the first time - you see my answer in addition, that it is the engine problem, not plugin. Enough for understanding.

[Joss]

I see meaningless plug-in version number, without any knowledge about SDKs you're using. I don't even know if you're using rendering engine as a static library or using dll from the octane installation - and i'm not supposed to know that.
2.58 doesn't make any sense for me as well as 3.03 - it's just a numbers without any encoded knowledge behind them.

Just thought i could help a bit reporting that stuff, but seems it doesn't work that way.
Let's keep it overflowing and crashing then, it's fine.

[JimStar]

I see meaningless plug-in version number, without any knowledge about SDKs you're using. I don't even know if you're using rendering engine as a static library or using dll from the octane installation - and i'm not supposed to know that.
2.58 doesn't make any sense for me as well as 3.03 - it's just a numbers without any encoded knowledge behind them.

Sorry, I did not know that you can't compare the numbers, and that you can't read the descriptions of beta versions you download (such as HERE: "New engine 3.03 version with Kepler support (previous GPUs are supported too)."). I will take it into account and will explain such a things specially for you with additional diligence.

Just thought i could help a bit reporting that stuff, but seems it doesn't work that way.
Let's keep it overflowing and crashing then, it's fine.

Not right. Let's you "keep it overflowing and crashing then", as it is you who want to save a few additional bucks on the memory, continuing to use such complicated scenes at the time. I do not have this problem with your scene on my rendering-machine, as it has enough memory and swap-file on SSD. And I did not hear that someone else has such a "problems".
It is not the problem at all. The new engine got a lot of a cool features which may need some more memory when building the BVH tree - just to take the speed of this compilation maximally high. And I better will spend a few bucks and upgrade some hardware (for hardware renderer) and will use all these cool features with all possible speed, than save these few bucks asking the engine developers to lower memory consumption at the price of speed of compilation. I'd better ask them to take even more memory, but make the compilation even faster.
But if you are trying to use the hardware renderer with complicated scenes and don't want to spend the money on additional hardware to let the renderer work with these scenes - OK, it's fine.

[Joss]

Ok, next time it's gonna eat 16gb of memory i will take into account your useful advice about memory upgrade "for a few bucks".
Meanwhile moving octane from production renderers back to "unstable/toys" category.

Thanks for uhm..."special attention" to my problem, and for the perfect solution.