![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <Xns### [at] 204 213 191 226>,
"Rafal 'Raf256' Maj" <raf### [at] raf256 com> 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] earthlink net>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tag povray org
http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Christopher James Huff <chr### [at] mac com> wrote in
news:chr### [at] netplex aussie org
>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Rafal 'Raf256' Maj" <raf### [at] raf256 com> wrote in
news:Xns### [at] 204 213 191 226
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <Xns### [at] 204 213 191 226>,
"Rafal 'Raf256' Maj" <raf### [at] raf256 com> 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] earthlink net>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tag povray org
http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <Xns### [at] 204 213 191 226>,
"Rafal 'Raf256' Maj" <raf### [at] raf256 com> 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] earthlink net>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tag povray org
http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Christopher James Huff <chr### [at] mac com> wrote in
news:chr### [at] netplex aussie org
>> ...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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |