 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
...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
Post a reply to this message
Attachments:
Download 'cans.jpg' (296 KB)
Preview of image 'cans.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Larp <nomail@nomail> wrote:
..
..
..
> Render time was astoundingly over 29 hours with a focal blur
> and in 1024x768 px! Maybe some optimisation could be
> considered. :)
Two questions come to mind: How long did it take without focal blur, and what
hardware? Nice can models BTW, and good job texturing them.
-Reactor
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Reactor wrote:
> Two questions come to mind: How long did it take without
> focal blur, and what hardware?
Well, without focal blur it took "only" 1 h 5 min. Other
explanation for slow rendering is my not-so-modern
hardware: Athlon XP 2400+ with 1 GB memory.
> Nice can models BTW, and good job texturing
> them.
Thank you, thank you!
Larp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
