Boggle of Octane Bog down?
protovu
Posts: 194
Hi Guys,
The Dillema: Octane is rendering, for the most part, beautifully (drops models out of the render once in a while).
My question has to do with multi-tasking. ....specifically , there is almost none available during an Octane render. The renders are fairly quick, as I have a healthy GPU amt. My CPU (dual Xeon), and RAM(lots), seem uninterested in what is going on during these renders. But, nonetheless, my I can barely browse the interweb, let alone use a vector program during a render. My mouse is slogging though oatmeal!
I will concede that my renders are pretty layered.....lots of feathered transparancies.
Is there a setting I am missing here? A strategy to deploy?
Thank you all,
Rick
Comments
Hello Rick!
This is because Octane Render needs the full calculation power of the graphic cards.
Everything that is GPU related - so also the mouse movement on the screen - gets less calculation power.
Eddy
Most GPU capable renderers are able to use more than one card...so often a cheap, low end card or onboard graphics is enabled and the monitor is hooked up to THAT. This off loads the normal OS/display functions from the render card, which should allow other useage while rendering.
Thanks, Eddy.
With that info in mind, I have disengaged one of my video cards in the Devices Tab of the OctaneRender settings.
Also, knocked down the samples to 50. These things seemed to help.
Do you know of another way to allocate GPU resources? Maybe I should SLI 3 cards, and have one misfit for mousing and other programs?
I see, MJC. So in the Nvidia interface, we opt for default, not Nvidia control of our monitors, but do we need to plug the monitors into the motherboard video output? Seems not.
Hi :)
In the settings,. under devices, you can adjust the "priority" setting from High, through Medium,.. to Low.
this will allow other tasks to use the graphics card.
Basically,. whatever you see,. is done by the graphics card,.
So if it's tied up in one application at High priority,. max usage,. then everything else has to wait.
...What MJV 1016 said :)...
In most of the others, yes, that's how it works, not 100% sure how in Octane (there are other Octane users, both the Carrara and DS plugins and I'm sure at least one of them said they run it that way)...but some motherboards you need to make sure both the card and the onboard are enabled in BIOS. Some BIOSs automatically disable the onboard when a card is plugged in.
All good, stuff, thank you.
It seems that the Nvidia control panel is allowing offload of the monitors regardless of what port they are plugged into. This might be helping a little. The true test will be running Premiere, or doing some vector drawing during an Octane render. Anyone else do this?....on the same machine, that is.
Sadly, the Priority settings don't actually operate for some users like myself. I've searched for a long time and have found no legitimate reason why Priority doesnt work for some people but indeed many have reported that it doesnt work for them. It is for this reason that in Version 3 this Priority functionality has been removed. Instead, they lowered the size of the chunks Octane is rendering allowing GPU usage to fluctuate instead of always occupying 100% of processing. Even 2-3% of available processing is enough to allow background processes and other multitasking efforts to unfold in. Right now Octane utilizes all GPU cycles even when there is latency, which is a waste of energy anyhow. So it is a very big improvement in my opinion. When using the version 3 beta I can now reliably do things while actively rendering. So it's good to know the solution is not far off.
I should note that the OR4C itself can become quite sluggish, and can even lock you out of it until it finsihes rendering the current frame if one is not cautious. If you are hovering the mouse over an icon for a millisecond too long and then press the icon, sometimes the OR4C gets caught in a loop where the command itself is applied only after the render is completed, which depending on the content, could be hours. This happens because when you hover the mouse over an icon for a second a little window pops up explaining what that icon is, such as start render, or Maximum, or minimize etc... The GPU gets so sluggish presenting that little description window that it cannot update the screen canvas fast enough to allow you to continue working so the OR4C will lock you out until rendering of the frame (or sequence of frames) is completed and the processing cycles become available to properly present the little description window. After the render completes reactions return to normal. But the only way to get out of the loop is to either forcibly close the program or to wait for it to complete the render which most likely wasnt ever intended to be the final render. To avoid this lock-up/ lock-out problem one needs to be very quick with mouse clicks on the icons within the OR4C, and to regularly Pause the render when going back and forth editing. Not every user has this dilemma, most people don't experience this level of difficulty using the OR4C but it can happen.
Best of luck!
Thank you, Rashad. You have well described what I have encountered. And, thank you for the technical background of what I could only think of as a "crash". Based on your mouse hover info., I am going to disable tool tips in Carrara preferences. Maybe this is off base, but who knows....
Absent the priority function, will the ability to entirely disengage a video card remain?
Per things you are able to do now with 3, you are able to video edit, or vector draw while rendering?
Best,
Rick
The icons of issue are not the Carrara native icons, but the icons of the OR4C. If disabling tool tips works for the OR4C interface window as well as the native Carraraq interface, then that will be a welcome solution to our rather vexing problem. Thanks for the head's up. I'm going to attempt a test right now.
Protovu,
As I suspected, the disabling of Tool Tips in the Carrara preferences only affects the Carrara Native interface, the OR4C remains unaffected. Again, this is not an issue at all in Octane Render 3. I'd be suing the beta version 3 right now if it wasnt for some issues with it rednering specular volumes correctly. Hopefully Sighman will solve that and you and I can move on to the version with the improved handling.
Ahh, yes. I noticed no difference with the tool tips disablement. Resizing or moving the render window while the mesh is compiling is still awful.
This January, I did try a later beta with Octane: 2.24. Had issues with models being dropped from animations. I have also had this happen with 2.17, but less consistently. Also, with had to "generate animation" in order to get any animating at all. Not sure why that function exists. Physics sims? Do not need to "generate" with 2.17.
Mesh recompiles occur anytime the geometry changes, either in morhing, or some matrix alteration such as position, scale, rotation. Mesh compiles can take longer than the actual rendering of the frames. The dropped models issue is probably also related to the GPU being overtaxed. Currently, I find that sometimes the very last change I make doesn't always show up in the render. Often moving the camera slightly suddenly causes the OR4C to properly update. Afterward I undo the slight movement to get the correct shot. But this should only be occurring when one is actively updating. If you are simply rendering out frames then models shouldn't appear to be dropped.
In version 3, this issues doesnt seem to exist making me wonder if this is just another example of the GPU nopt quite keeping pace with all that is going on because Octane keeps it too preoccupied.
Until now, I though I was the only OR4C user experienceing these issues so I never made much stink about it since it's mostly the fault of the standalone, not the plug-in. But the plug-in is most certainly affected by the overalll GPU usage in several ways.
You are not alone. I also, have had false updates to Octane render windows. It is to the point now that when altering a texture, or opacity texture, I go straight to "Rebuild Scene" to see the real update. For a while, I was being faked out by Octane. It was pretending to render, but no update would show. Sequencer movement did not help. Play/pause, no relief.
Rebuild scene solves that one, and actually saves a step. You can update a texture map in you paint program, and then rebuild the scene instead of updating the map in the shader room.
I think you are right about the dropped models, but there is one clue about them that may relate somewhat to Carrara. Like me, I bet you have gotten into the habit of closing down, and then re-opening before rendering? This was something I found necessary pre Octane. Might have helped me this last render in Octane, one that did, and then did not, drop models.