Kenneth <kdw### [at] earthlinknet> wrote:
> Render time?

> I wasn't aware that render time would be influenced by that; triangle meshes are
> 'generated' during parsing, AFAIK, where the time differences would show up. Or
> else I'm confused about what you originally meant. Or just plain confused!

  inside_vector is used for CSG, and CSG is calculated at rendertime.
Obviously thus if inside_vector has any effect on speed, it's precisely
at rendertime.

  Why would it make any difference at parse time? It's just one single
keyword at the end of the mesh definition. It sets a flag on in the mesh
structure that says that the inside_vector feature should be used. Why
would that have any effect to the parse time?

  I don't even understand why you would think it has any effect at parse
time.

-- 
                                                          - Warp

Post a reply to this message

jan dvorak <jan### [at] centrumcz> wrote:
> Kenneth napsal(a):

> > Something I've always wondered about: The docs say that a ray is shot in this
> > direction; but from *where*? Anyone know if it's from the origin?

> from the point you test for insideness

?? Sorry to be a dullard, but I'm not sure I understand that. Could be my own
misconception of how inside_vector works. I've always assumed that only a
single ray is shot, from *somewhere*, during any CSG operation, which tells
POV-Ray what it needs to know. Do I surmise that MANY rays have to be shot?

KW

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Kenneth <kdw### [at] earthlinknet> wrote:
> > Render time?
>
> > I wasn't aware that render time would be influenced by that; triangle meshes are
> > 'generated' during parsing, AFAIK, where the time differences would show up. Or
> > else I'm confused about what you originally meant. Or just plain confused!
>
>   inside_vector is used for CSG, and CSG is calculated at rendertime.
> Obviously thus if inside_vector has any effect on speed, it's precisely
> at rendertime.

Didn't realize that. Thanks for clarifying.
>
>   Why would it make any difference at parse time? It's just one single
> keyword at the end of the mesh definition. It sets a flag on in the mesh
> structure that says that the inside_vector feature should be used. Why
> would that have any effect to the parse time?

I agree wholeheartedly. That was my initial thinking when I did my test..but I
thought..er.. you wanted to see what the time differences were. (But I..uh..did
the wrong test...) Egads. :-[
>
>   I don't even understand why you would think it has any effect at parse
> time.

I agree, I agree!  :-)

KW

Post a reply to this message

Kenneth <kdw### [at] earthlinknet> wrote:
> jan dvorak <jan### [at] centrumcz> wrote:
> > Kenneth napsal(a):

> > > Something I've always wondered about: The docs say that a ray is shot in this
> > > direction; but from *where*? Anyone know if it's from the origin?

> > from the point you test for insideness

> ?? Sorry to be a dullard, but I'm not sure I understand that. Could be my own
> misconception of how inside_vector works. I've always assumed that only a
> single ray is shot, from *somewhere*, during any CSG operation, which tells
> POV-Ray what it needs to know. Do I surmise that MANY rays have to be shot?

  Every time POV-Ray needs to know if a point is inside the mesh it will
trace a ray from that point to the direction specified with inside_vector.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Kenneth <kdw### [at] earthlinknet> wrote:

> > ...I've always assumed that only a
> > single ray is shot, from *somewhere*, during any CSG operation, which tells
> > POV-Ray what it needs to know. Do I surmise that MANY rays have to be shot?
>
>   Every time POV-Ray needs to know if a point is inside the mesh it will
> trace a ray from that point to the direction specified with inside_vector.
>

Oh! That's a major shift from my previous thinking. Thanks!

Now I see why inside_vector could have an effect on rendering time.

KW

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:

>
> Here's a parse-time test for the HF_Cylinder macro in shapes.inc (unmodified
> except for inside_vector), no CSG, and run at a relatively hi-rez of 1200 X
> 1200:

OK, here's the test regarding RENDER times, hopefully done correctly this time.
 Same set-up, but I upped the resolution to 2000 X 2000. There *is* a
difference, though slight.

WITHOUT inside_vector: 735 sec.
WITH inside_vector: 761 sec.

That's a 3% to 4% increase, on my 2.2 GHZ single-core PC.

KW

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote in message 
news:web.48fafac46bc5685d78dcad930@news.povray.org...
> "Kenneth" <kdw### [at] earthlinknet> wrote:
>
>>
>> Here's a parse-time test for the HF_Cylinder macro in shapes.inc 
>> (unmodified
>> except for inside_vector), no CSG, and run at a relatively hi-rez of 1200 
>> X
>> 1200:
>
> OK, here's the test regarding RENDER times, hopefully done correctly this 
> time.
> Same set-up, but I upped the resolution to 2000 X 2000. There *is* a
> difference, though slight.
>
> WITHOUT inside_vector: 735 sec.
> WITH inside_vector: 761 sec.
>
> That's a 3% to 4% increase, on my 2.2 GHZ single-core PC.

is this just one frame ?  I think for accurate results, you should render as 
many frames as you can, and average the render-times.  For all we know, the 
difference you came up with now could be due to, I don't know, Windows 
Update for instance

cu!
-- 
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x)            // ZK http://www.povplace.com

Post a reply to this message

Zeger Knaepen <zeg### [at] povplacecom> wrote:
> > WITHOUT inside_vector: 735 sec.
> > WITH inside_vector: 761 sec.
> >
> > That's a 3% to 4% increase, on my 2.2 GHZ single-core PC.

> is this just one frame ?  I think for accurate results, you should render as 
> many frames as you can, and average the render-times.  For all we know, the 
> difference you came up with now could be due to, I don't know, Windows 
> Update for instance

  If I'm not completely mistaken, POV-Ray only counts the time it's running,
not how much the system clock has advanced. (But I might remember this
wrongly.)

  Anyways, it would be interesting to see rendering times of such meshes
in different situations. For example make a union of the mesh and some
other object (non-mesh, or even another mesh). Use some atmospherical
effects such as fog (probably makes no difference, but doesn't hurt to
try). Instantiate the mesh several times. Things like that.

-- 
                                                          - Warp

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message 
news:48fb0aa1@news.povray.org...
> Zeger Knaepen <zeg### [at] povplacecom> wrote:
>> > WITHOUT inside_vector: 735 sec.
>> > WITH inside_vector: 761 sec.
>> >
>> > That's a 3% to 4% increase, on my 2.2 GHZ single-core PC.
>
>> is this just one frame ?  I think for accurate results, you should render 
>> as
>> many frames as you can, and average the render-times.  For all we know, 
>> the
>> difference you came up with now could be due to, I don't know, Windows
>> Update for instance
>
>  If I'm not completely mistaken, POV-Ray only counts the time it's 
> running,
> not how much the system clock has advanced. (But I might remember this
> wrongly.)

I'm not sure about that, I don't think so, but that again is easily tested: 
a relatively slow rendering scene rendered identically a couple of times 
should, if you're right, always have the exact same render-time.
Setting up a scene right now :)
-- START CODE --
camera {
 location <1,3,-10>
 look_at 0
}
light_source {
 <500,500,-500>
 rgb 1
}
julia_fractal {
  <-0.083,0.0,-0.83,-0.025>
  quaternion
  sqr
  max_iteration 640
  precision 1500
  pigment {rgb 1}
}
-- END CODE --
1st try: 28s
2nd try: 32s
I tried to force a longer rendertime by moving around this reply-window 
(moving windows around is very processor-intensive apparently) while it was 
rendering.  I first tried to move around the render window, but for some 
reason, POV-Ray didn't notice it was finished rendering, and the timer kept 
on running.

>  Anyways, it would be interesting to see rendering times of such meshes
> in different situations. For example make a union of the mesh and some
> other object (non-mesh, or even another mesh). Use some atmospherical
> effects such as fog (probably makes no difference, but doesn't hurt to
> try). Instantiate the mesh several times. Things like that.

trying it now!
- a random 5000 triangle mesh, no inside_vector, no fog, no csg, average 
rendertime over 5 renders -> 33.2s
- same 5000 triangle mesh, no inside_vector, fog, no csg, average rendertime 
over 5 renders -> 34.2s
- same 5000 triangle mesh, no inside_vector, no fog, csg (union with a 
non-interfering sphere), average rendertime over 5 renders -> 34.2s
- same 5000 triangle mesh, no inside_vector, fog, csg (union with a 
non-interfering sphere), average rendertime over 5 renders -> 34.4s

- same 5000 triangle mesh, inside_vector x, no fog, no csg, average 
rendertime over 5 renders -> 36.4s
- same 5000 triangle mesh, inside_vector x, fog, no csg, average rendertime 
over 5 renders -> 37.2s
- same 5000 triangle mesh, inside_vector x, no fog, (union with a 
non-interfering sphere), average rendertime over 5 renders -> 38s
- same 5000 triangle mesh, inside_vector x, fog, (union with a 
non-interfering sphere), average rendertime over 5 renders -> 38s

(with "non-interfering sphere" I mean a sphere that doesn't overlap or 
intersects with the mesh, but is on screen)
inside_vector does seem to cause slower rendertimes, even without csg

cu!
-- 
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x)            // ZK http://www.povplace.com

Post a reply to this message

Zeger Knaepen <zeg### [at] povplacecom> wrote:
> I'm not sure about that, I don't think so, but that again is easily tested: 
> a relatively slow rendering scene rendered identically a couple of times 
> should, if you're right, always have the exact same render-time.

  Not really. There are other things which can affect POV-Ray's rendering
speed than CPU load, and other programs can, in theory, affect this rendering
time, even if indirectly. There can be all kinds of caching and memory paging
issues, for example (in other words, a different process might cause the
POV-Ray process to suffer from more cache misses and increased memory paging
if this another process is also using the cache heavily).

  The ultimate experiment to see which way POV-Ray counts the time is to
simply have a very CPU-intensive program running at the same time as POV-Ray
(so that both will get about 50% of CPU-time): If the rendering time reported
by POV-Ray approximately doubles, then it indeed takes this time from the
system clock (iow. it uses the so-called wallclock time).

  I might have simply remembered wrongly this subject.

> trying it now!

  It seems that inside_vector definitely has some impact on the rendering
speed of meshes (although I'm not exactly sure of why), which is probably
one reason why it's not turned on by default (the other one being backwards
compatibility).

-- 
                                                          - Warp

Post a reply to this message