I'm a fucking idiot with Blender and require helpFor some reason, no matter what I set my samples to, the scene always tries rendering 14,000 samples per tile. What am I doing wrong?
>>550863Fuck, I'm reading up on it now, and apparently most people don't use more then fucking 4 bounces? Goddammit. Does that influence sample amount or am I just fixing one part of the problem
>>550864you only increase the bounces if you have things like wine bottles/swimming pools etc where the reflection is more complexi might be wrong but i think someone said that's it
>>550864bounces is how many times a light ray will reflect/defractmax you probably need is 12>also using cycleshttp://www.luxrender.net/en_GB/blender_2_5get yourself luxrender muh man
>>550866As said in the OP, I'm a complete dumbass when it comes to rendering. Pitch me on this shit. Is it faster, prettier, etc?
>>550866t. luxrender marketing expert
OP here again. Should the "Packing BHV nodes" be taking a loooong time? Is that normal
>>550884if ur scene is super busy
>>550885Lotta hair particles on high poly models, so I guess it would be.I really should figure out a good way to export 3DCoat models better to avoid this shit.
I would take a screenshot but I'm sure my computer would hate that at this point so have this instead. Still rendering at 14,100 Samples. Dunno what else to do really. I guess it's going decently fast but still
>>550896maximum u should render is 5000 samplesanything beyond that is inefficient use of materials
>>550897That's the problem chief, I have it set to 50 Samples. I don't have Squared Samples on either. Dunno what's causing it.
>>550899turn off caustics and use HDRI background with less blender lights
>>550866This. Or Renderman is good aswell.>>550868t. Andrew Price.
>>550867basically. I'd suggest downloading lux and running some test scenes to see just how well lux works http://www.luxrender.net/wiki/Show-off_pack>>550868>>550910t. Todd howard
>>550867>Is it faster?Than Cycles? Hard no. But it is still pretty fast But it is easier to use in most cases. Materials are more physically accurate out of the box than Cycles though. Old API uses spectral rendering, which is slower but can produce a more realistic result. New API uses RGB rendering which is faster but not as accurate but is still pretty close. Lux has more rendering options, such as Bidirectional, Photon mapping, and VCM (although that is experimental right now and I don't really recommend it now). Cycles does have better node options though but all those nodes can create a hefty node tree that can easily become too much depending on the material you're creating. Lux supports OpenCL and Cycles supports CUDA and OpenCL.Personally I prefer Luxrender because it can produce better scenes more easily. The best way I could put it on which to choose is if you want to make photorealistic stills, use Luxrender. If you want to do animations use Cycles (then again you can always use Renderman but that's a different argument).
>>550923>t. Todd howardWell at least I'm not Anthony Burch.
>>550938It depends on your settings for lux, I find that path/opencl/hybird get pretty fast results. it really depends on how well you optimize your scene though.
>>550949>HybridYou mean in new or old API? The hybrid integrator in classic lux isn't recommended by the devs anymore.
>>550862Did you accidentally enable per-renderlay samples in the Scene tab?Check this link: http://blender.stackexchange.com/questions/21154/cycles-not-rendering-specified-samplesStack Exchange almost always has the answers to just about any question you could have if you take the time to search itRe: Luxrender, Lumon, Marmoset, Renderman, etc etc etc, just fucking stick to one and actually learn the ins and outs and how to use it.Cycles can be very fast and produce low or no noise with minimum samples, but it requires the right settings.It can also produce very nice accurate results at high samples, but again requires the right settings and also scene setup. In the end all the rendering engines are the same the only difference is some have nicer defaults, but if you're only ever using them at the default / most basic level, you'll never get good results anyway.
>>550938>Old API uses spectral rendering, which is slower but can produce a more realistic resultUnless you are doing funny things with prisms or some funny meta-materials with strange diffraction coefficients, you will never see the difference.Spectral rendering is excellent for physics, but useless in most case.>>550949>optimizing your scene>not having 12 hours of rending time for 30% convergenceshiggy
>>550862Have you checked your render settings to see if it is set to final? That will multiply your render samples something fierce. If set to final a registered sale of like 10 will actually render over 220 samples. .. take a look at that.
>>550981Ah christ... looking back at your image that is exactly what you did. That 50 samples set at final render will shit you over on render samples and time. If you are still fn around with your scene. .. do yourself a favor and keep it on very low settings until you are ready to invest time in a larger sampled final render.
>>550952in the old, works great for me *shrug text*
>>550896Those aren't samples, those are tiles.Did you set your tile size to something extremely small?
>>551106By the way I bet your scene is just super complicated, that's why it's rendering so slow.Show a screenshot of your viewport.
>>551106>>551107Not OP but good catch, he's using CPU render and if he has the default automatic tile selector enabled, it's going to adjust it down (whereas for GPU it'll bump the tile size up)
>>550862There's your problem, don't set the sampling to Final unless you want a super long render meant to be flawless.