Hi,
I just found out that linear_spline prism can be render about 20% faster, 
just after changing it to mesh (or even - set of triangles)

union {
  tra(_h,_a,_b)  tra(_b,_c,_d)  tra(_d,_e,_f)  tra(_f,_g,_h)
  tra(_f,_h,_b)  tra(_f,_d,_b)
  tra(_hu,_au,_bu)  tra(_bu,_cu,_du)  tra(_du,_eu,_fu)  tra(_fu,_gu,_hu)  
  tra(_fu,_hu,_bu)  tra(_fu,_du,_bu)  
  qua(_a,_b,_bu,_au) qua(_b,_c,_cu,_bu) // front side
  qua(_c,_d,_du,_cu) qua(_d,_e,_eu,_du) // right side
  qua(_e,_f,_fu,_eu) qua(_f,_g,_gu,_fu) // back  side
  qua(_g,_h,_hu,_gu) qua(_h,_a,_au,_hu) // left  side
[...]
}

//---------------------

  prism {
    linear_spline linear_sweep
    0, _q, 8
    <_a.x, _a.z>
    <_b.x, _b.z>
    <_c.x, _c.z>
    <_d.x, _d.z>
    <_e.x, _e.z>
    <_f.x, _f.z>
    <_g.x, _g.z>
    <_h.x, _h.z>
  }

3-rd option is to use mesh{} instead of union

and...:

mesh  55 sec
prism 51 sec
union 41 sec

hmm personaly I would expect somthing different :)

is't this some kind of bug ? imho mesh should be the fastest ?

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

In article <Xns### [at] 204213191226>,
 "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:

> I just found out that linear_spline prism can be render about 20% faster, 
> just after changing it to mesh (or even - set of triangles)

Your message is very confused...first you say meshes are 20% faster, 
then you give numbers showing they are slower. And your scene code uses 
a lot of variables and tra() and qua() macros without defining them.


> mesh  55 sec
> prism 51 sec
> union 41 sec
> 
> hmm personaly I would expect somthing different :)
> 
> is't this some kind of bug ? imho mesh should be the fastest ?

What is your point? You made some assumptions and then say it must be a 
bug when they turn out to be incorrect? It's a bug that reality doesn't 
match your opinion of how things should be? Sure, why don't we slow down 
unions and prisms to fix this...

A mesh is a different shape from a union, it is specially designed to 
handle large numbers of triangles. The prism mesh probably just isn't 
big enough to get the advantages of a mesh. A prism is completely 
different from either a union or a mesh. If prisms were limited to being 
convex, the linear spline prism primitive could probably be the fastest, 
but they aren't limited in that way. This is an isolated special case, 
and doesn't indicate any bugs anywhere.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote in
news:chr### [at] netplexaussieorg 

>> I just found out that linear_spline prism can be render about 20%
>> faster, just after changing it to mesh (or even - set of triangles)
> Your message is very confused...first you say meshes are 20% faster, 
> then you give numbers showing they are slower. And your scene code

my mistake - union of triangle is the fastest

> uses a lot of variables and tra() and qua() macros without defining
> them. 

I didn't search especialy for bug, I came acros it while rendering 
something eles. This macros/variables are not important - their are used to 
create set of triangles (normal, triangles)

>> mesh  55 sec
>> prism 51 sec
>> union 41 sec
>> is't this some kind of bug ? imho mesh should be the fastest ?
> What is your point? You made some assumptions and then say it must be
> a bug when they turn out to be incorrect? It's a bug that reality
> doesn't match your opinion of how things should be? Sure, why don't we
> slow down unions and prisms to fix this...

mesh is suggested to be used instead of union of triangles, and as we can 
see that suggestion have some disadvantages
 
> A mesh is a different shape from a union, it is specially designed to 
> handle large numbers of triangles. The prism mesh probably just isn't 
> big enough to get the advantages of a mesh. A prism is completely 
> different from either a union or a mesh. If prisms were limited to
> being convex, the linear spline prism primitive could probably be the
> fastest, but they aren't limited in that way. This is an isolated
> special case, and doesn't indicate any bugs anywhere.


-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

"Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote in 
news:Xns### [at] 204213191226

> my mistake - union of triangle is the fastest

...for small number of triangles. How about displaying a warning in meshes 
with 1..100 triangles like "Opimization tip: for <100 triangles union is 
faster then mesh" ?
With file/line is run just after parsing mesh ?

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

Meshes use octree optimization in order to speed up the rendering of
big meshes. However, the ray-octree intersection test adds overhead to the
ray-mesh test. With a very small amount of triangles the octree doesn't
have any advantage, but you only have the overhead. The octree starts to
have speeding effect when the number of triangles is larger.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

In article <Xns### [at] 204213191226>,
 "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:

> I didn't search especialy for bug, I came acros it while rendering 
> something eles. This macros/variables are not important - their are used to 
> create set of triangles (normal, triangles)

The entire speed test relies on the code generated by them, and they 
aren't important?


> mesh is suggested to be used instead of union of triangles, and as we can 
> see that suggestion have some disadvantages

Only when you have a shape composed of a lot of triangles or make a lot 
of copies of the object, in both cases it is valid advice. I don't 
recall ever seeing a statement that all triangles should be put in 
meshes.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

In article <Xns### [at] 204213191226>,
 "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:

> ...for small number of triangles. How about displaying a warning in meshes 
> with 1..100 triangles like "Opimization tip: for <100 triangles union is 
> faster then mesh" ?
> With file/line is run just after parsing mesh ?

Because it is rediculous and unnecessary. And the geometry of the 
union/mesh matters at least as much as the number of triangles, but 
writing code to analyze this would not be worth the effort. If a person 
is having speed problems they can try changing it.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote in
news:chr### [at] netplexaussieorg 

>> ...for small number of triangles. How about displaying a warning in
>> meshes with 1..100 triangles like "Opimization tip: for <100
>> triangles union is faster then mesh" ?
>> With file/line is run just after parsing mesh ?
> Because it is rediculous and unnecessary. And the geometry of the 
> union/mesh matters at least as much as the number of triangles, but 

not more rediculous then Bounding_Threshold options - basicly every scene 
except "sphere on checker floor" don't need this option

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message