Ignore Unused Materials in Live Viewer Tweet

[Aleksei]

Is it possible to disable all the unused materials while working in the live viewer window? Couldn't find such option in settings. This would sped up workflow drastically.

[aoktar]

We do not need it much, because we have texture caching mechanism to accelerate the export. Also this requests will make everything broken

[Aleksei]

It looks like caching is not working. Or I don't see any effects of it.
Please, check the video attached. There I show an almost empty scene but with big textures which are not used. In the video you will see that when I click render button each of the textures starts peocessing. This starts to be especially annoying when working with a huge scene with much more assets than in the attached video. Because in different time I work with different smaller parts of a scene. And, from time to time, I want to render only that smaller part of scene to control the look, ignoring everything else.

Now in big scenes, when I'm in the look dev stage, I'm spending 60% of time waiting for the render to prepare.

Video: download/file.php?mode=view&id=90633

[aoktar]

Caching is effective when you send the scene again. As said "ignore unused materials" is not safe for Live Viewer. It will cause a lot of problems, I know because I've tried to implement it and switched back after many issues.

[AWOLism]

I would just like to add that I also experience this quite often in my day to day work with product visualisation.
I often work with a large number of items in one scene file to be able to tweak materials that are shared between models, and when everything has high res textures it can take minutes to start the scene. Of course I fully understand that this might be complicated to solve (I am no programmer), but if there was a way it would be super appreciated.

Cheers
Andreas

[frankmci]

As I understand it, the Live Viewer works differently than the Image Viewer, and for good reason; the whole point of the Live Viewer is to have the quickest possible response and feedback while developing the render. As such, it needs to have loaded all the assets in the scene that you might change into active VRAM. If you drop a currently unused texture onto an object it updates instantly; it doesn't have to do any import processing. As far as the Live Viewer is concerned, there are no "unused" materials.

Batch rendering or Image Viewer rendering are a different beast than the Live Viewer. There, Octane knows ahead of time what does and does not need to be included, and can filter accordingly.

I haven't experimented with how it specifically affects Octane Live Viewer rendering, but you might try using xref objects to help control which materials are or are not loaded into C4D.

[Aleksei]

That's right, and that's why it would be good to a have a checkbox to switch between different scenarios: loading or not loading the unused materials. And if user does someting wrong, (like trying to apply a non-loaded into VRAM material) gently inform him about the situation without crashing the entire Cinema 4D. That could be a better UX for us.

[aoktar]

That's right, and that's why it would be good to a have a checkbox to switch between different scenarios: loading or not loading the unused materials. And if user does someting wrong, (like trying to apply a non-loaded into VRAM material) gently inform him about the situation without crashing the entire Cinema 4D. That could be a better UX for us.

Please read this

Caching is effective when you send the scene again. As said "ignore unused materials" is not safe for Live Viewer. It will cause a lot of problems, I know because I've tried to implement it and switched back after many issues.

[frankmci]

That's right, and that's why it would be good to a have a checkbox to switch between different scenarios: loading or not loading the unused materials. And if user does someting wrong, (like trying to apply a non-loaded into VRAM material) gently inform him about the situation without crashing the entire Cinema 4D. That could be a better UX for us.

It's easy for users to say, "Just ad a checkbox to enable function X." It's not unusual for a function to require major changes to the underlying code, especially when that function was specifically discounted while designing the core architecture. I'm not just talking Octane, but any complex tool.

I've heard our own developers complain about it on several occasions over the years. "Yes, we can do that, but since the original design specs were for something else all together, and the whole logic is built on different assumptions, it will take an estimated additional XXX manhours to implement, test, and deploy, along with the associated cost (which is way more than the client is willing wait or to pay).

[aoktar]

That's right, and that's why it would be good to a have a checkbox to switch between different scenarios: loading or not loading the unused materials. And if user does someting wrong, (like trying to apply a non-loaded into VRAM material) gently inform him about the situation without crashing the entire Cinema 4D. That could be a better UX for us.

It's easy for users to say, "Just ad a checkbox to enable function X." It's not unusual for a function to require major changes to the underlying code, especially when that function was specifically discounted while designing the core architecture. I'm not just talking Octane, but any complex tool.

I've heard our own developers complain about it on several occasions over the years. "Yes, we can do that, but since the original design specs were for something else all together, and the whole logic is built on different assumptions, it will take an estimated additional XXX manhours to implement, test, and deploy, along with the associated cost (which is way more than the client is willing wait or to pay).

Thanks for support!
As I'm trying to say that I've spent much time for many ideas for optimizations. People don't know most of trials about these. And there are critical times to decide to continue to cancel when something gone wrong. This topic is one of these. This doesn't means that will not happen, but no promises or retreats.