Render in Background Questions



  • I like to do large complex render from time to time. However; some renders use the Firefly engine and that just takes up the CPU's (94% cpu usage) and everything I do is sluggish. I'm talking about a day long render here. I was wondering...

    Does anyone use Render in Background?

    What are the advantages and drawbacks to Rendering in Background?

    Does anyone use the queue manager and what should I expect?

    Thanks for your time!



  • I usually use Render in Background so I can continue working on other things. I've never had any issues with it. However, I've never heard of a "day long" Firefly render... What sort of rendering are you doing? Firefly is not a PBR renderer, so there's not much there that would warrant such a length of time. Keep in mind that optimizing your materials/scene can greatly reduce Firefly rendering time with no significant impacts on the quality of the render.

    The advantages of Background rendering are that you can continue working as the rendering is done in its own "space", so to speak. There will be a performance hit, of course, for apps/processes that make use of the CPU/RAM, but if you're just mucking about with your Scene or working on another one, it's really not very impactful, depending upon your system.

    The disadvantages are that the render may take longer. And, there's always the issue of system stability if you're working with other software that needs a lot of resources.

    I haven't used Que manager in a very long time.



  • @morkonan said in Render in Background Questions:

    I usually use Render in Background so I can continue working on other things. I've never had any issues with it. However, I've never heard of a "day long" Firefly render... What sort of rendering are you doing? Firefly is not a PBR renderer, so there's not much there that would warrant such a length of time. Keep in mind that optimizing your materials/scene can greatly reduce Firefly rendering time with no significant impacts on the quality of the render....

    You've never heard of a day long render? I certainly have. A discussion on another site that is just a Hive of activity led to one Poser user saying that his render took three days to complete. I normally test and save then before I go to bed or work I start the Render. I do large Renders for Illustrations and the larger size and denser DPI makes for a wonderful Render and makes corrections easier. Some renders may have as many as 20 different figures in it depending on what I'm working on. I'd love to see your settings and see how they compare to my own.

    Two things. First, I just tried the Render in the Background on a simple figure and it was awesome. It's wonderful to work on one Render while the is working away. However, I do wonder how many I can work on at one time? Will Poser queue them up or do I need a network to use something like a queue manager?

    The Second thing is you mentioned optimizing materials and scene. What do you mean? A material is a material to firefly (though I'm told it's not really materials. They are shaders.) And a scene can be comprised of so many things. Could you clarify "optimizing materials" I'm always looking for ways to cut down on Render time.



  • @maestro said in Render in Background Questions:

    I'd love to see your settings and see how they compare to my own.

    It all depends on what I'm doing. My general settings are something like this:

    http://i.imgur.com/6U6o0RN.jpg

    That's a default render scheme for a "well lit" room. I might adjust the IDL strength or number of bounces for either direct/indirect lighting, depending on desired effects. Irradiance caches may be adjusted depending on artifacts on tests and such. I might include Tone Mapping if there is are "blowout" effects going on. Gamma Correction can be adjusted, but I am working on figuring it all out. :) Pixel sampling doesn't usually need to be more than 5, to be honest. But, if it was an issue, I'd increase it.

    The "heavyweights" in the settings are going to be pixel samples, number of bounces and irradiance cache settings. These can substantially increase render times.

    However, lighting settings are extremely important, too. Their settings set-the-stage, so to speak. Here's a default main spotlight setting I normally use:

    http://i.imgur.com/RdZmcbl.jpg

    I never use depth-map shadows, since ray-tracing is infinitely preferred and much more accurate, these days. (Impact isn't as large a consideration as it used to be.) Shadow blur is generally large, for me in this default setting, for softer shadows. Larger values here can increase rendering times. Shadow Samples has a large impact on time, as well. That's something that may need fine-tuning, but I generally go with 10 to 15, sometimes greater, depending on what I need. I usually don't need to set the Minimum Bias lower than .6, though if there are a lot of transparencies close together or if I am seeing render artifacts, blotching/stippling near close-contact borders, I may turn it down to as little as .4 in tests. In no instance have I ever used or seen it less than .4. It can have a large impact on rendering time, sometimes with little quality advantage. It's mainly for fine-tuning and problem solving, if needed.

    I almost always use Inverse Square lighting, since it's "there" and it's more accurate as a "real light." However, Poser will frequently "bloom" the effects of these lights on close objects, so it's a bit weird in that regard and can make lighting difficult to predict. (Test-renders for the win.) One can either use tone-mapping to try to reduce the bloom, which I'm still learning about, by the way, or change the lighting model to Constant, which further reduces the "reality-factor" one might be going for. In any event, the basic light attributes would not be greatly changed. (Shadow strength, in the submenu, are set determining the desired effect and don't have much of an effect on render time.)

    ... However, I do wonder how many I can work on at one time? Will Poser queue them up or do I need a network to use something like a queue manager?

    AFAIK, you can't que renders without using the Que Manager. Also - When working in the background, and if you load the "Recent Render" window, you can corrupt the current render, so just don't do it. That darn Recent Render window is live-updated and is very quircky when dealing with currently processing renders. (The whole scheme seems to be somewhat handwavey to begin with, IMO.) However, you can check on the current render by flipping to the Render window at any time, without any detrimental effects. Though, loading previous renders in "Compare" mode can sometimes have weird results, too.

    The Second thing is you mentioned optimizing materials and scene. What do you mean? A material is a material to firefly (though I'm told it's not really materials. They are shaders.) And a scene can be comprised of so many things. Could you clarify "optimizing materials" I'm always looking for ways to cut down on Render time.

    In general, most generated materials don't have a large effect on render time. Some, like SSS can, however, and these settings are so detailed, and I'm so unfamiliar with them, that they're difficult for me to discuss. I don't use SSS a lot. When I want a decent "skin" preview/image, I fall back on the much-beloved, by me at least, "V4 Skin Realism Kit" by face off, IIRC. It does a great job of "faking it" when it comes to SSS, but since it uses the old "ambient set to black" trick, it's presenting increasing difficulties in "realism" in Poser compared to the newer, true, SSS shader system. (Ambient lighting materials are actually treated differently, these days, than they used to be, making using that channel for "tricks" a lot more serious.)

    HDRI images can also greatly effect render time. I always use "something" for HDRI lighting effects, if for no other reason than to give me a decent preview example for a "studio look." For a basic "studio view" render, I'd use either:

    http://3dericdesign.deviantart.com/art/Free-HDR-For-Studio-Render-157557355

    (or another similar HDRI I have, but can't attribute at the moment because I moved all my compressed HDRI files)

    or something from here, probably: http://www.hdrlabs.com/sibl/archive.html

    ( I use BB's Envirosphere almost always.)

    One prime factor in large scenes are the Emitter toggles on objects. Everything that is an emitter can emit light in some way, either by bouncing it or through ambient effects. However, some objects are so complex that turning them into an Emitter could increase render time outrageously for little to no real value. Strip-hair/transmap hair models are the most obvious issue and I generally never toggle them on as an emitter for this reason. Other objects, like "trees/shrubs" and those sorts of complex objects may not need to be switched on as an emitter. In fact, I made a post not long ago concerning this and the possible use of "hit boxes" as an emitter "stand in" for very complex objects, specifically due to the "render time vs render value" they can have.

    So, if you have a lot of objects in the scene, how many of them in a Firefly render are really, truly, going to contribute to furthering the quality/accuracy of the render if they're toggled on as an Emitter? That's something you have to consider when "fine tuning" in Firefly, in my opinion. Some purists might say "everything", but that's just throwing more fuel on a fire than its worth, in my opinion, in scenes with lots of complex geometry.

    "Fine-tuning", in the manner in which I was speaking, has to do with everything involved in a particular render. First, consider the lighting variables and what sort of tweaks are needed for Blur, Sample and Bias. Then, consider the Render Settings, depending on what sort of things you want to do with accuracy concerning the Bounce count, then IDL strength and whether or not you're going to get rendering artifacts with lower or even higher Irradiance cache values. (Higher caches can cause splotching.) Pixel sampling settings are determined by how much anti-aliasing you think you're going to need and higher values won't, necessarily, mean greater render quality in that regard. (A pixel can't, itself, be split in half, so you're going to get some aliasing, somewhere, since it's not a chemical-based photo-film...)

    The render size and dpi that you're doing is probably different than what I would normally do. I'm not rendering for production, just for my own amusement. AFAIK, greater than 72dpi isn't necessary for most digital-medium images. If you're rendering for print or very large format, that may not be the case.

    I'm no render guru, by the way, nor a node cultist. Most pros know exactly what they need and have worked with settings enough to know them intimately. For myself, I've worked with them for long enough to know what they do, mostly :) , and what I need out of them for my own funsies, which is mostly checking how my modeling and mapping skills are developing as a rarely render "large scenes."

    By far, the largest impacts on rendering time I have experienced with large scenes, generally outdoor ones with vegetation and the like, has to do with determining which objects should be "Emitters" and which objects will not contribute that greatly in regards to overall quality of the finished render. In my opinion, as I stated in a previous thread, which I'll edit into this post, simple "emitter" hitboxes might suffice for some objects, even fairly complex ones, if they're proving of too complex geometry for the render-time investment. In many cases, though, those might not even be neceesary.

    If you're going to tweak anything, besides any settings that you may have which are far too detailed for normal use, you may want to examine the value of having lots of objects acting as emitters vs the extra time that's going to take to calculate.

    Edit - The thread I made in regards to complex emitters: https://forum.smithmicro.com/topic/1530/firefly-light-emitters-bouncing-bouncies (Notice there's no answer, yet. It may be due to my ignorance of the whole thing or due to the fact that there isn't a good solution or this issue hasn't been yet considered by many users. I dunno... :) )

    Final Note: All of this is targeted towards "Firefly" rendering, not an attempt to duplicate PBR-based rendering effects, which is nearly impossible to do in Firefly. Firefly is all about "lying" in regards to lighting effects and true PBR effects. If using Firefly primarily, one has already decided to "lie", so there is absolutely no need, in my opinion, to do anything other than to tell the best possible "lie" that one can and to admit to oneself that "lying is good" when one is using Firefly. :)



  • It's been a year since I switched to Superfly. I had to build up a new computer (the last one was dead), equipped with a 980Ti that lets me render scenes with up to 4 Vic4 fully equipped.
    But till March last year, I was used to use the queue manager to render scenes during nights (most of the time) but also during up to 40 hours.
    I'm self employed since 7 years now. And I use a virtual machine running an Ubuntu desktop for my devs.
    Even when I was using the background rendering with the queue manager.
    Of course, the PC slows down significantly, but it remained perfectly usable.
    It's now my sixth PC I've built from scratch. And the last two had these points in common:

    • windows on its own hard disk: an SSD
    • everything else, the runtimes included, on a 6Gb/s standard hard disk

    I've been using the queue manager since Poser Pro, and the SSD made a difference, as I was on the limit for the RAM with the last two motherboards (8Gb and now 16Gb).



  • @Y-Phil said in Render in Background Questions:

    I had to build up a new computer (the last one was dead), equipped with a 980Ti that lets me render scenes with up to 4 Vic4 fully equipped.

    After reading this i was curious how many dressed V4s my GTX 980 could handle. So i loaded 10 fully dressed V4s and pressed the render button. Rendering was just fine and the render report said 11GB of render memory was used (on a 6GB vid card).
    Interesting finding, it seems that on Mac OS X GPU rendering with SuperFly is not limited to GPU memory. I didn't know that, cool :-)