OTOY Forums

borzoff wrote: Thank you very much for this tip, I'll try.
but here's the problem with the EXR format recording and Object ID and Material ID is still there. I want to bring one pass, rather than a bunch of masks. Probably expect a fix for this problem.

I think that's fine here. Sample scene and output attached. Can you check it?

zoppo wrote: My problem: when rendering in the Picture Viewer with the settings in the first picture the z-depth pass that is saved is the wrong one (picture 2 and 3).

The only way I found to get the correct pass (as in the last picture) is to set the Octane Settings to Infochannels (like in picture 3 and 4).
But obviously I won't get a Beauty Pass this way, because the Z-Depth pass is rendered as a beauty pass (main pass).

May be better to post your scene because i can render it correctly. At least i suppose that's correct. I can't see anythings weird to me.

Hi Aoktar, I have a question concerning render passes and compositing — C4D may save *.aec file with all the passes you choose and when you import *.aec into AE you actually get all the passes in one comp in the right order from top to bottom and all blends perfectly. I suppose C4D can't see render passes from Octane, but anyway — is that possible to make Octane save passes to *.aec file? Because it would be a great time saver

I think there is quite much room for optimization regarding the LV updates. I noticed that if, for example, you hide a group containing several objects (which has already been rendered previously), and then un-hide it, the geometry is recalculated again, and often that takes huge amounts of time. It would be better IMO to study a way to cache geometry data so that only the one that has really changed is sent to the Octane LV, regardless of other state changes (like being hidden).

papillon wrote:I think there is quite much room for optimization regarding the LV updates. I noticed that if, for example, you hide a group containing several objects (which has already been rendered previously), and then un-hide it, the geometry is recalculated again, and often that takes huge amounts of time. It would be better IMO to study a way to cache geometry data so that only the one that has really changed is sent to the Octane LV, regardless of other state changes (like being hidden).

Sorry but that's wrong. Optimizations are really on top and more efforts that just will cause less stability. You shouldn't decide with single action without seeing other effects. This causes to fill the vram for unvisible geometries. That's not good idea for big scenes and nobody wishes to see more geo. compilation times for invisible geometries. Also geometry creation is short process in plugin side. Most time is spent by Octane sdk for preparing data to be ready for renderer.

aoktar wrote:

papillon wrote:I think there is quite much room for optimization regarding the LV updates. I noticed that if, for example, you hide a group containing several objects (which has already been rendered previously), and then un-hide it, the geometry is recalculated again, and often that takes huge amounts of time. It would be better IMO to study a way to cache geometry data so that only the one that has really changed is sent to the Octane LV, regardless of other state changes (like being hidden).

Sorry but that's wrong. Optimizations are really on top and more efforts that just will cause less stability. You shouldn't decide with single action without seeing other effects. This causes to fill the vram for unvisible geometries. That's not good idea for big scenes and nobody wishes to see more geo. compilation times for invisible geometries. Also geometry creation is short process in plugin side. Most time is spent by Octane sdk for preparing data to be ready for renderer.

I didn't mean to have the geometry cached into the VRAM, I understand that's not viable and needs to be cleared and re-updated all the time.
But a sort of cache mechanism where data is stored (in RAM, or disk) in a way that Octane can manipulate quickly without having to recalculate all the geometry from scratch each time, also for a simple visibility change, would be definitely worth IMO.

papillon wrote: I didn't mean to have the geometry cached into the VRAM, I understand that's not viable and needs to be cleared and re-updated all the time.
But a sort of cache mechanism where data is stored (in RAM, or disk) in a way that Octane can manipulate quickly without having to recalculate all the geometry from scratch each time, also for a simple visibility change, would be definitely worth IMO.

Thanks for your advice. That's great on theory. But be sure i'm doing most possible accelerations. I would add a mechanism like you said if we would have a possibility. Things are much complicated to explain to users. Time consuming part is not sending the geometry to sdk. So there is no advantage in practice. The correct way is to having some boost by Octane sdk for geometry preparation parts.

aoktar wrote:

borzoff wrote: Thank you very much for this tip, I'll try.
but here's the problem with the EXR format recording and Object ID and Material ID is still there. I want to bring one pass, rather than a bunch of masks. Probably expect a fix for this problem.

I think that's fine here. Sample scene and output attached. Can you check it?

https://yadi.sk/d/NdknjISrorukR

So I render cinema 4d physical. and if you try to use the id matte plug in the after-effect, it will be possible to select all the desired mask.
Problem just your method is that you need a mask and they are considered individually and if Schen heavy, time-consuming. if the material id and object id could push in this format, it would greatly facilitate the life, the more this method can oschitat mask only on the desired objects, and I would like to specifically on the materials, and in the scene I have about 300

papillon wrote:

aoktar wrote:

papillon wrote:I think there is quite much room for optimization regarding the LV updates. I noticed that if, for example, you hide a group containing several objects (which has already been rendered previously), and then un-hide it, the geometry is recalculated again, and often that takes huge amounts of time. It would be better IMO to study a way to cache geometry data so that only the one that has really changed is sent to the Octane LV, regardless of other state changes (like being hidden).

Sorry but that's wrong. Optimizations are really on top and more efforts that just will cause less stability. You shouldn't decide with single action without seeing other effects. This causes to fill the vram for unvisible geometries. That's not good idea for big scenes and nobody wishes to see more geo. compilation times for invisible geometries. Also geometry creation is short process in plugin side. Most time is spent by Octane sdk for preparing data to be ready for renderer.

I didn't mean to have the geometry cached into the VRAM, I understand that's not viable and needs to be cleared and re-updated all the time.
But a sort of cache mechanism where data is stored (in RAM, or disk) in a way that Octane can manipulate quickly without having to recalculate all the geometry from scratch each time, also for a simple visibility change, would be definitely worth IMO.

Sounds like you are after some kind of delta/change awareness by Octane SDK??

Hi Aoktar,

This might be a super stupid question, but I cant seem to figure out how to preview the different multipass layers in the LV? For example the "reflection D" and "reflection I".
In the older versions of the plugin I could do so via the Octane settings.

How do we do this now?

Morten