 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi everyone!
I am trying to render a scene which I thought was pretty simple, but it is
moving extremely slowly and so I was hoping somebody might explain why it is so
slow (I'm new to this so forgive me if I'm missing something obvious). It seems
when I've read about other people's renders they can render more complicated
scenes beautifully in a lot less time.
It's been going for 22 hours and it's only 3% done.
I am using version 3.7 and it is using all four of my cores (3.2 GHz), but only
2.77G of my 16G total RAM.
I am rendering at 1024x768 with AA threshold 0.0, AM2, R5, and Q11
Here's the code:
#include "colors.inc"
#include "stones.inc"
#include "finish.inc"
#include "glass.inc"
#include "woods.inc"
#include "textures.inc"
#include "golds.inc"
camera {
location <0, 0, -15>
look_at <0, 0, 0>
}
background{White}
plane { <0, 0, 1>, 5.06
texture{
pigment {color White
}
finish{
diffuse 1
}
}
}
#declare flathelix = intersection{
object{
difference{
cylinder {
<0, -13, 0>,
<0, 25.5, 0>,
5.05
}
cylinder {
<0, -14, 0>,
<0, 26, 0>,
4.95
}
}
}
sphere_sweep {
cubic_spline
50,
#declare Count=0;
#while (Count < 50)
<5*sin(Count/2),Count/2-13,5*cos(Count/2)>, 0.4
#declare Count=Count+1;
#end
}
}
#declare strand = union{
object{flathelix translate 0.5*y
texture{ pigment{color rgb<0.8039, .36078, 0.36078> filter 1 }}
finish {
ambient 0
diffuse 0
reflection .25
specular 1
roughness .001
}
interior {ior 1.5}
}
object{flathelix rotate 180*y
texture{ pigment{color rgb<0.27451, 0.5098, 0.70588> filter 1 }}
finish {
ambient 0
diffuse 0
reflection .25
specular 1
roughness .001
}
interior {ior 1.5}
}
#declare Count=0;
#while (Count < 50)
sphere_sweep {
linear_spline
6,
<4.8*sin(Count/2),Count/2-13 + 0.5,4.8*cos(Count/2)>, 0.2
<3.2*sin(Count/2),Count/2-13 + .4,3.2*cos(Count/2)>, 0.1
<1.6*sin(Count/2),Count/2-13 + .3,1.6*cos(Count/2)>, 0.05
<-1.6*sin(Count/2),Count/2-13 + .2,-1.6*cos(Count/2)>, 0.05
<-3.2*sin(Count/2),Count/2-13 + .1,-3.2*cos(Count/2)>, 0.1
<-4.8*sin(Count/2),Count/2-13,-4.8*cos(Count/2)>, 0.2
texture {Polished_Chrome}
}
#declare Count=Count+1;
#end
}
object{strand rotate -15*z translate -6*x
}
object{strand rotate -205*z translate 6*x
}
light_source { 2*<5, 5, -15>*1 color White*1.5 area_light <5, 0, 0>, <0, 0,
5>, 10, 10}
Thanks for any help or suggestions!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
taftj wrote:
> I am rendering at 1024x768 with AA threshold 0.0, AM2, R5, and Q11
have you tried without AA for comparison? Your settings are quite high.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 22-2-2012 6:29, taftj wrote:
> I am rendering at 1024x768 with AA threshold 0.0, AM2, R5, and Q11
For a first test I would suggest +a0.3. Your threshold is far too low
for a fast render and possibly not necessary.
> texture{ pigment{color rgb<0.8039, .36078, 0.36078> filter 1 }}
Start with filter 0 (or very low) in both textures to see how the scene
develops. Filter 1 is also slowing the render down.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
And I forgot to say: area_light always slows a render too :-)
Faster would probably be:
light_source {
2*<5, 5, -15>*1
color White*1.5
area_light
<5, 0, 0>, <0, 0, 5>, 9, 9
adaptive 2
}
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 22.02.2012 06:29, schrieb taftj:
> I am rendering at 1024x768 with AA threshold 0.0, AM2, R5, and Q11
That will cause 4^5 = 1024 (!) rays shot /unconditionally/ for each and
every pixel, even in uniformly colored areas where a single ray would
theoretically suffice. Even with an exceptionally low threshold like,
say, 0.01, I would expect a big win in render speed. Most people go with
the default threshold of 0.3, which I'd expect to win you a factor of
100 or even more. You can also usually get away with a lower recursion
depth; R3 is quite common.
> light_source { 2*<5, 5, -15>*1 color White*1.5 area_light<5, 0, 0>,<0, 0,
> 5>, 10, 10}
Similar here: You'll get 10*10 = 100 rays shot /unconditionally/ per
shadow test (which /multiplies/ by the aforementioned factor due to
anti-aliasing); try the "adaptive" keyword, usually "adaptive 1" is a
good start and will cause only (2^1+1)^2 = 3^2 = 9 rays to be shot for
fully lit or fully shadowed regions, and even for the umbra it will be
more like 20 to 30 samples due to the recursively adaptive algorithm);
that might win you a factor of maybe 8. (Note that when using the
"adaptive" keyword, it is recommended to have an area light of (2^N+1)
by (2^M+1), e.g. 9 by 9, which is actually a quite common value.)
Sphere sweeps are comparatively challenging to render, and your scene
has about 50 of them (one with about 50 control points); you may want to
try different approaches to avoid them altogehter. Using SDL to compute
corresponding meshes might also be an alternative.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks so much for the help everyone! Regarding the anti-aliasing, I had tried
it previously with A0.3 and R4, but there was a "checkerboard" pattern in the
chrome spokes. I was really hoping for a pristine reflection in the spokes so I
cranked up the anti-aliasing. It looks like I was just asking for too much.
Thanks again for all the guidance.
I'll try some of the other suggestions and if that doesn't help much I guess I
have to tone down the AA.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In response to sphere sweeps being slow, would lathes or surfaces of revolution
be faster? I could easily replace most of the sphere sweeps with either.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 23/02/12 06:52, taftj wrote:
> In response to sphere sweeps being slow, would lathes or surfaces of
> revolution be faster? I could easily replace most of the sphere
> sweeps with either.
>
IIRC, I used Mike Williams "SweepSpline.inc" for that... it's included
on one of his isotutorials archives:
http://www.econym.demon.co.uk/isotut/more35.zip
Hope this helps...
--
Jaime
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
