 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Larp nous illumina en ce 2008-08-05 19:46 -->
> ...Please allow me to introduce you to my favourite energy
> drink! For some reason couple of holes are drilled to the
> cans, holes in each can are positioned vertically using a
> random sample from normal distribution.
>
> Can pigment (etiquette) is drawn with Gimp since there was
> no ready picture available. Otherwise this is pure Pov...
> Product name ”Teho” can be translated as ”Force”.
>
> Bamboo floor is borrowed from Gilles Tran's work ”Snail
> demo” (2006).
>
> Render time was astoundingly over 29 hours with a focal blur
> and in 1024x768 px! Maybe some optimisation could be
> considered. :)
>
> This is, btw, my first post to the group.
>
> Comments are, of course, welcome.
>
> Larp
>
>
> ------------------------------------------------------------------------
>
How are the holes made?
Transparent parts in the image_map, or actual holes made with a diference?
With the diference, you can try using a merge of all the holes, it could be
somewhat faster.
--
Alain
-------------------------------------------------
God doesn't play dice. -- Albert Einstein
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain wrote:
> How are the holes made?
> Transparent parts in the image_map, or actual holes made
> with a diference? With the diference, you can try using a
> merge of all the holes, it could be somewhat faster.
Holes are "real holes": rotated cylinders grouped in an
union and then differenced with a can.
Should the merge be faster than the union? At least
Documentation says opposite:
"Note: that in general merge is slower rendering than union
when used with non transparent objects."
(http://www.povray.org/documentation/view/3.6.1/307/)
Well, I gave merge a try and got rendering time 1:07:39 (no
focal blur) which was even a bit more than with then
previous render of original scene with no fb (about 1 h 5
min. But I have to confess that tonight I surfed bit in the
web while rendering, which could maybe alone explain
difference of three minutes...
Probably the size of the picture I used in the etiquette --
5654x2724px -- is much more than needed when rendering
scene at this size. I made the picture that big to make
closeups with good quality possible. Maybe that explains
significant part of the long render time?
Larp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it Larp who wrote:
>Alain wrote:
>
>> How are the holes made?
>> Transparent parts in the image_map, or actual holes made
>> with a diference? With the diference, you can try using a
>> merge of all the holes, it could be somewhat faster.
>
>Holes are "real holes": rotated cylinders grouped in an
>union and then differenced with a can.
>
>Should the merge be faster than the union? At least
>Documentation says opposite:
The situation with the speed of holes is quite complicated. I have a
series of pages about the situation here:
http://www.econym.demon.co.uk/holetut/index.htm
Because your holes are randomly placed, the first three tricks won't
work, but the fourth trick might:
http://www.econym.demon.co.uk/holetut/holes4.htm
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Larp nous illumina en ce 2008-08-07 14:21 -->
> Alain wrote:
>
>> How are the holes made?
>> Transparent parts in the image_map, or actual holes made
>> with a diference? With the diference, you can try using a
>> merge of all the holes, it could be somewhat faster.
>
> Holes are "real holes": rotated cylinders grouped in an
> union and then differenced with a can.
>
> Should the merge be faster than the union? At least
> Documentation says opposite:
>
> "Note: that in general merge is slower rendering than union
> when used with non transparent objects."
> (http://www.povray.org/documentation/view/3.6.1/307/)
>
> Well, I gave merge a try and got rendering time 1:07:39 (no
> focal blur) which was even a bit more than with then
> previous render of original scene with no fb (about 1 h 5
> min. But I have to confess that tonight I surfed bit in the
> web while rendering, which could maybe alone explain
> difference of three minutes...
>
> Probably the size of the picture I used in the etiquette --
> 5654x2724px -- is much more than needed when rendering
> scene at this size. I made the picture that big to make
> closeups with good quality possible. Maybe that explains
> significant part of the long render time?
>
> Larp
>
Usualy, an union is faster than a merge due to a more efecient bounding and sub
bounding: the usion is split into it's composants for the bounding. A merge
can't be split that way. When using a diference or intersection, the bounding
boxes of all components tend to enlarge to that of a merge of all components.
When you use a diference, all bounding boxes from all components tend to cover
the whole object. That mean that every ray gets tested against every bounding
boxes, and then, need to test against every components of the diference. Using a
merge, you have to deal with lot less coincident bounding boxes.
You could also use a blob with a very small treshold value or a very large
strenght value. This will minimize the rounding when two or more components touch.
--
Alain
-------------------------------------------------
My wife likes to talk on the phone during sex; she called me from Chicago
last night.
Rodney Dangerfield
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Williams wrote:
> The situation with the speed of holes is quite
> complicated. I have a series of pages about the situation
> here:
> http://www.econym.demon.co.uk/holetut/index.htm
>
> Because your holes are randomly placed, the first three
> tricks won't work, but the fourth trick might:
> http://www.econym.demon.co.uk/holetut/holes4.htm
>
Wow! I have been studying those tutorials several times
during my Povray years and found the Isosurface Tutorial
particularly useful. It feels strange now, suddenly, to be
writing to the author. Hmm, thank you for your work!
I have been reading Holes Tutorials too, but forgot the blob
technique.
So, what comes to the energy drink can holes... - I made the
holes as cylinders at first:
cylinder { <0,0.6,0><0,0.6,2>, 0.03
rotate <0,RotY2,0>
translate <0,PosY,0>
}
...and then I changed those to blobs:
blob { threshold 1
cylinder { <0,0.6,0><2,0.6,2>, 0.03, 10000 }
rotate <0,RotY2,0>
translate <0,PosY,0>
}
The latter method generated comparable visual results with
the former one, but surprisingly the render time was
significantly higher - over 2 hours (2:14:34)! Do I
misunderstand something completely now?
> The situation with the speed of holes is quite
> complicated.
I really have to agree with this! :-)
Larp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> You could also use a blob with a very small treshold value
> or a very large strenght value. This will minimize the
> rounding when two or more components touch.
Thanks for your tip!
However, for some reason blobs didn't make things faster in
my situation.
Please check out my reply to Mike Williams.
Larp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it Larp who wrote:
>Mike Williams wrote:
>
>> The situation with the speed of holes is quite
>> complicated. I have a series of pages about the situation
>> here:
>> http://www.econym.demon.co.uk/holetut/index.htm
>>
>> Because your holes are randomly placed, the first three
>> tricks won't work, but the fourth trick might:
>> http://www.econym.demon.co.uk/holetut/holes4.htm
>>
>
>Wow! I have been studying those tutorials several times
>during my Povray years and found the Isosurface Tutorial
>particularly useful. It feels strange now, suddenly, to be
>writing to the author. Hmm, thank you for your work!
>
>I have been reading Holes Tutorials too, but forgot the blob
>technique.
>
>So, what comes to the energy drink can holes... - I made the
>holes as cylinders at first:
>
>cylinder { <0,0.6,0><0,0.6,2>, 0.03
> rotate <0,RotY2,0>
> translate <0,PosY,0>
>}
>
>...and then I changed those to blobs:
>
>blob { threshold 1
> cylinder { <0,0.6,0><2,0.6,2>, 0.03, 10000 }
> rotate <0,RotY2,0>
> translate <0,PosY,0>
>}
It looks like you might be attempting to difference the can with a union
of blobs each of which have a single element. That doesn't gain you the
advantage of the blob trick. What you have to do is difference the can
with a single blob object that has lots of components.
blob { threshold 1
cylinder { <0,0.6,0><2,0.6,2>, 0.03, 10000 }
rotate <0,RotY1,0>
translate <0,PosY1,0>
cylinder { <0,0.6,0><2,0.6,2>, 0.03, 10000 }
rotate <0,RotY2,0>
translate <0,PosY2,0>
cylinder { <0,0.6,0><2,0.6,2>, 0.03, 10000 }
rotate <0,RotY3,0>
translate <0,PosY3,0>
...
}
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Williams wrote:
> It looks like you might be attempting to difference the
> can with a union of blobs each of which have a single
> element.
Yes, you're right.
> That doesn't gain you the advantage of the blob
> trick. What you have to do is difference the can with a
> single blob object that has lots of components.
>
> blob { threshold 1
> cylinder { <0,0.6,0><2,0.6,2>, 0.03, 10000 }
> rotate <0,RotY1,0>
> translate <0,PosY1,0>
> cylinder { <0,0.6,0><2,0.6,2>, 0.03, 10000 }
> rotate <0,RotY2,0>
> translate <0,PosY2,0>
> cylinder { <0,0.6,0><2,0.6,2>, 0.03, 10000 }
> rotate <0,RotY3,0>
> translate <0,PosY3,0>
> ...
> }
I assume you mean this (see the position of brackets):
blob { threshold 1
cylinder { <0,0.6,0><2,0.6,2>, 0.03, 10000
rotate <0,RotY1,0>
translate <0,PosY1,0> }
cylinder { <0,0.6,0><2,0.6,2>, 0.03, 10000
rotate <0,RotY2,0>
translate <0,PosY2,0> }
cylinder { <0,0.6,0><2,0.6,2>, 0.03, 10000
rotate <0,RotY3,0>
translate <0,PosY3,0> }
...
}
Anyway, I changed the structure to single blob version and
got render time of... 1 hour 6 minutes! It's shorter time
with the previous run, but still very much the same as with
the original code, so at this time blobs didn't speed up
things. That is tragical, because I already had strong
faith in faster rendering. :=)
Larp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it Larp who wrote:
>Anyway, I changed the structure to single blob version and
>got render time of... 1 hour 6 minutes! It's shorter time
>with the previous run, but still very much the same as with
>the original code, so at this time blobs didn't speed up
>things. That is tragical, because I already had strong
>faith in faster rendering. :=)
The scene below takes 2 seconds to render on my machine. I can imagine
that fancy lighting and focal blur would slow it down, but not by that
much.
How fast is your scene without the holes?
camera {location <0, 2, -10> look_at <0,1,0> angle 40}
light_source { <0, 0, 0> color rgb 1 translate <-30, 30, -30>}
#declare CAN = difference {
cylinder { <0, 0, 0>, <0, 3, 0>, 1 }
cylinder { <0, -0.1, 0>, <0, 3.1, 0>, 0.97 }
}
#declare R1 = seed(123);
#declare HOLES = blob { threshold 1
#declare N=0;
#while (N<1000)
sphere { <0.985,0.6,0>, 0.03, 10000
rotate <0,rand(R1)*360,0>
translate <0,rand(R1)*2,0> }
#declare N=N+1;
#end
}
difference {
object {CAN}
object {HOLES}
pigment {rgb 1}
}
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Williams wrote:
> The scene below takes 2 seconds to render on my machine. I
> can imagine that fancy lighting and focal blur would slow
> it down, but not by that much.
>
> How fast is your scene without the holes?
Rendering without holes or focal blur took 6 minutes 3
seconds.
The can is defined in separate include file which is quite
complex cocktail of lathes, prisms, tori, sphere sweeps
etc. - in overall 444 rows. I'm not surprised rendering
takes some time. Still I'm somehow happy with the results,
even to render something like this 29 hours is not sane at
all...
Larp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
