I'm a fucking idiot with Blender and require help For some

File: 1484780072276.png (64KB, 172x182px) Image search: [Google]

64KB, 172x182px

>>550862
>128 bounches

>>550863
Fuck, 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

>>550864
you only increase the bounces if you have things like wine bottles/swimming pools etc where the reflection is more complex
i might be wrong but i think someone said that's it

>>550864
bounces is how many times a light ray will reflect/defract

max you probably need is 12
>also using cycles
http://www.luxrender.net/en_GB/blender_2_5
get yourself luxrender muh man

>>550866
As said in the OP, I'm a complete dumbass when it comes to rendering. Pitch me on this shit. Is it faster, prettier, etc?

>>550866
t. luxrender marketing expert

OP here again. Should the "Packing BHV nodes" be taking a loooong time? Is that normal

>>550884
if ur scene is super busy

>>550885
Lotta 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.

File: IMG_2869.jpg (3MB, 3264x2448px) Image search: [Google]

3MB, 3264x2448px

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

>>550896
maximum u should render is 5000 samples
anything beyond that is inefficient use of materials

>>550897
That's the problem chief, I have it set to 50 Samples. I don't have Squared Samples on either. Dunno what's causing it.

>>550899
turn off caustics and use HDRI background with less blender lights

>>550866
This. Or Renderman is good aswell.

>>550868
t. Andrew Price.

>>550867
basically.
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
>>550910
t. 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 howard
Well at least I'm not Anthony Burch.

>>550938
It 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
>Hybrid
You mean in new or old API? The hybrid integrator in classic lux isn't recommended by the devs anymore.

>>550862

Did you accidentally enable per-renderlay samples in the Scene tab?

Check this link: http://blender.stackexchange.com/questions/21154/cycles-not-rendering-specified-samples

Stack Exchange almost always has the answers to just about any question you could have if you take the time to search it

Re: 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 result

Unless 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% convergence

shiggy

>>550862
Have 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.

>>550981
Ah 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.

>>550952
in the old, works great for me *shrug text*

>>550896
Those aren't samples, those are tiles.
Did you set your tile size to something extremely small?

>>551106
By 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
>>551107

Not 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)

File: problem.png (6KB, 342x58px) Image search: [Google]

6KB, 342x58px

>>550862

There's your problem, don't set the sampling to Final unless you want a super long render meant to be flawless.