Reduce the tree branch segment count to 10 from 16 and branch sides to 7 from 8.
1-Also be aware of editor vs. render parameter effect for Live Viewer vs. Picture Viewer.
"editor" -> Live Viewer
"render"->Picture Viewer
Differences will cause to have much more polygons on Picture Viewer rendering. And renderer could failed to render the scene or takes much more time for preparation.
2-And always use "all movable" in Picture Viewer while using forester. "Auto detect" will cause to have much longer startup times due analysing the whole frames. Because on every frame, forester will calculate the plant polygons.
Forester Problems - can someone help?
Moderators: ChrisHekman, aoktar
Octane For Cinema 4D developer / 3d generalist
3930k / 16gb / 780ti + 1070/1080 / psu 1600w / numerous hw
3930k / 16gb / 780ti + 1070/1080 / psu 1600w / numerous hw
Again, thank you, aoktar, but this is the same line of reasoning 3DQuakers has fallen into. I have already checked the settings you gave me, set to "all movable" doesn't make a difference in the memory problem.
I also understand the difference between the Live Viewer and the Picture Viewer (render.) And yes, I can change the tree segment counts and simplify my scene (polygon count). But that still doesn't address the real problem...
Why does version 121 render the scene AS IS and all of the other Forester versions run out of memory? No simplifying. No changes to anything else in the scene or the render settings.
No, there's something else going on here that must be particular to my system. All the other versions of Forester behave radically poorly as opposed to 121.
But since no one seems to have an answer or are avoiding that question, I'll just figure it out on my own.
Thank you all for your help.
I also understand the difference between the Live Viewer and the Picture Viewer (render.) And yes, I can change the tree segment counts and simplify my scene (polygon count). But that still doesn't address the real problem...
Why does version 121 render the scene AS IS and all of the other Forester versions run out of memory? No simplifying. No changes to anything else in the scene or the render settings.
No, there's something else going on here that must be particular to my system. All the other versions of Forester behave radically poorly as opposed to 121.
But since no one seems to have an answer or are avoiding that question, I'll just figure it out on my own.
Thank you all for your help.
All movable doesn't make any change on your scene because there's ONE TREE with enormous amount of polygons. And It's much for Octane for one object.BCres wrote: Why does version 121 render the scene AS IS and all of the other Forester versions run out of memory? No simplifying. No changes to anything else in the scene or the render settings.
Btw I cannot know the 121 but Forester guys are checking it and answered! For my side please see pictures from my tests. Absolutely you need an optimisation on your scene if your reference is Live Viewer.
Octane For Cinema 4D developer / 3d generalist
3930k / 16gb / 780ti + 1070/1080 / psu 1600w / numerous hw
3930k / 16gb / 780ti + 1070/1080 / psu 1600w / numerous hw
I stand by my statement — 121 can handle this scene no problem and none of the other versions will. All these other things just cloud the issue. Plus I left the scene complex so it would illustrate the point better.
BTW, 3DQuakers did not answer the question, so let's just drop it. Thanks anyway.
BTW, 3DQuakers did not answer the question, so let's just drop it. Thanks anyway.
For what it's worth I have found the issue but don't think I can do anything about it.
In my attempts to narrow it down, I tried rendering the tree alone in C4D's Picture viewer and, to my amazement, both versions crashed after using up all the memory.
I never noticed this before because I never do my final renders inside C4D. I just build using Octane's LV, set up the render, then go to the desktop and use the commandline to render the animation with this command:
"C:\Program Files\MAXON\CINEMA 4D R19\Commandline.exe" -render "path to scene"
The results showed the problem:
Forester 143 inside C4D = Out of memory crash
Forester 121 inside C4D = Out of memory crash
Forester 143 using Commandline render = Out of memory crash
Forester 121 using Commandline render = 50% memory usage, animation completes as normal
My suspicions are that everyone has been testing this within C4D and not seeing a huge difference in behavior. And I couldn't figure out why everyone kept harping on the tree as problematic when I rendered it and actually used it in a commercial.
There is apparently some huge difference in Forester 121 behavior between rendering within C4D using the PV and rendering using the commandline render. A difference that worked greatly in my favor.
So I found the culprit but can't do anything about it.
Not expecting a response. Just thought I owed it to you all to report this.
In my attempts to narrow it down, I tried rendering the tree alone in C4D's Picture viewer and, to my amazement, both versions crashed after using up all the memory.
I never noticed this before because I never do my final renders inside C4D. I just build using Octane's LV, set up the render, then go to the desktop and use the commandline to render the animation with this command:
"C:\Program Files\MAXON\CINEMA 4D R19\Commandline.exe" -render "path to scene"
The results showed the problem:
Forester 143 inside C4D = Out of memory crash
Forester 121 inside C4D = Out of memory crash
Forester 143 using Commandline render = Out of memory crash
Forester 121 using Commandline render = 50% memory usage, animation completes as normal
My suspicions are that everyone has been testing this within C4D and not seeing a huge difference in behavior. And I couldn't figure out why everyone kept harping on the tree as problematic when I rendered it and actually used it in a commercial.
There is apparently some huge difference in Forester 121 behavior between rendering within C4D using the PV and rendering using the commandline render. A difference that worked greatly in my favor.
So I found the culprit but can't do anything about it.
Not expecting a response. Just thought I owed it to you all to report this.
Now that you mentioned that you are rendering with Commandline, what you experienced with version 121 was that the tree was rendering with 4 levels instead of 5.
We added support to Commandline rendering after version 121, which means that in version 121, you were rendering with the viewport levels of 4, while in later versions, you were rendering with the full render levels of 5.
As a result, your (heavy) tree was somewhat lighter in 121.
Mystery solved!
Bottom line, optimize your geometry!
I hope this puts your mind at ease.
And thank you Ahmet taking the time to look into this issue.
We added support to Commandline rendering after version 121, which means that in version 121, you were rendering with the viewport levels of 4, while in later versions, you were rendering with the full render levels of 5.
As a result, your (heavy) tree was somewhat lighter in 121.
Mystery solved!
Bottom line, optimize your geometry!
I hope this puts your mind at ease.
And thank you Ahmet taking the time to look into this issue.
Yeah, I had mentioned the commandline rendering at the last post in the bottom of the first page but you may have not seen it.
Okay, I will optimize all my scenes now. And now I know I'm not going crazy that there was something different in version 121 than the others. That I was right about.
Still the rendered tree looks beautiful in 121, just like it did in Octane's LV. So I had no reason to believe it was being rendered at some lesser value.
Thanks, 3DQuakers and Ahmet. The only reason I revisited this was because I wanted to buy your new libraries but this was holding me up.
Okay, I will optimize all my scenes now. And now I know I'm not going crazy that there was something different in version 121 than the others. That I was right about.
Still the rendered tree looks beautiful in 121, just like it did in Octane's LV. So I had no reason to believe it was being rendered at some lesser value.
Thanks, 3DQuakers and Ahmet. The only reason I revisited this was because I wanted to buy your new libraries but this was holding me up.