OctaneRender® for 3ds max® v2.22.2 - 1.2 [OBSOLETE]

[coilbook]

Hello JimStar,
Thank you for the updates. They really mean a lot.

I'd like to ask you about instancing support in ITOO's Railclone Pro, a parametric object creation plugin.
Instancing for Forest Pack Pro is supported by Octane and it works allmost great.

For the Railclone pro there is no instancing support. The problem occurs ex. repeating and deforming object on the path. That make massive use of gpu ram for meshes. Resulting unrenderable scenes.
http://docs.itoosoft.com/display/RAILCL ... patibility

I asked about this in itoo software licenced customers forum.
You can see our conversation below.
They say:
RailClone doesn't include instancing support for Octane. RC objects are rendered as an unique mesh object.
Unfortunately we cannot add instancing support without the collaboration of the Octane developers. Recently we have included in RailClone an interface for rendering engines, and we sent the documentation to the main companies. So, hopefully new engines will be supported in the future, although until now we got no reply from Otoy.(This is the last post, dated 2013)

I asked:
Hello I've been suffering from the instance support with the octane renderer.
As I see that this topic a bit outdated.(Last post was dated 2013) And octane has improved in some ways.. I wonder if any other attempt to make it work with Otoy, octane render ?
I'll be asking for the instance support in the octane licence owners forum. But I wanted to ask you first.

Itoo Admin replied
Hi, i'm afraid nothing has changed since my latest post. Octane doesn't include a SDK for third-party plugins, so the engine is completely closed for us.
Only Otoy can implement the instancing support for RailClone, in a similar way they did with Forest.

So if there is anything you or the team could do. I'd be grateful if you add that compatibility.

+1 Itoo forest pack works perfectly. I think railclone uses same instancing methods

[oguzbir]

+1 Itoo forest pack works perfectly. I think railclone uses same instancing methods

Well, it's up to both octane and railclone developers to solve the issue.
I think railclone uses some how similar but different techniques. Railclone can deform the segments on the paths.
I'm not sure if that can be sorted out to have instancing support for the deforming meshes.
We'll see.

[bicket]

Hi Jimstar

I think there's a bug somewhere in the plugins.
While rendering in octane viewport, my CPU is always in charge. CPU leak ?

That's not the case with version 2.16a. I downgrade to 2.16a.

It's easy to write the program which does not use the CPU too much - it just should do nothing.
As I said in previous tread - there is a huge work for CPU when Octane viewport is opened due to the fact always HDR image is rendered in this mode in Max plugin instead of LDR. As I understand - this was made solely for the reason to be able to export the result from Octane viewport live-render mode into Max framebuffer (which understands HDR). And I said that I reckon this is not the right way for live-rendering which should be the fast mode. But in current state - it must recalculate the whole amount of float pixels (of a couple of hi-res images per second) one by one from HDR value into LDR. This is a lot of calculations for CPU. So, the previous versions (including 2.16a) did this job in one thread, slowing down the Octane viewport functionality.
The last versions do this job in few different threads using all the available cores. And the profiling shows that on hi-res images it calculates the framebuffer about 4 times faster on 4 cores machine (the more is resolution of live preview - the more linear is the gain).

So, if you don't like the CPU used during such a tough calculations - we have a two ways:
1. Disable the multithreading in Octane framebuffer calculations. This will slowdown the Octane viewport refreshing (FPS value, which reflects movements in your scene in real time) back.
2. Rework this mehanizm to function the way I described in previous thread: let the Octane live-preview do its work efficiently and fast, using LDR rendering mode and saving a lot of CPU calculations every second. And let the final-rendering mode to do the main work - render the beauty pass plus all the chosen passes in HDR mode (this mode does not need the fast realtime refresh, so it will not use the CPU that much even for HDR). But in this case - you will not be able to export the HDR result from Octane live-mode viewport into Max framebufffer "on the fly".
I like the second approach more, as it's more consistent and it reflects the proper division between real-time and non-realtime rendering modes.

Thanks for your answer
As far as I'm concerned, the second one is the best solution.

[mikinik]

Particle already working?
particles work?
I can not render rain

[perro_abombao]

Hi Jim.
with the new mehanizm, it seems all lightpasses checked in render elements are changed for "reflections" pass...other passes work fine

[JimStar]

perro_abombao
Thank you, I'll check it.

[bicket]

Thanks for your answer
As far as I'm concerned, the second one is the best solution.

Another solution is to have a new button in the viewport window in order to switch from LDR to HDR
Everybody will be satisfied

[JimStar]

bicket
Yep, I'm thinking about it...

[bicket]

great minds think alike

[nildoe]

Hi Jim.


How can we install to max 2016?

Nildo