Which way of making polyhedra is faster: using triangle meshes or
intersections of planes like those in the shapes2.inc file?
Brendan

Post a reply to this message

Andrea Ryan wrote:
> 
> Which way of making polyhedra is faster: using triangle meshes or
> intersections of planes like those in the shapes2.inc file?
> Brendan

Probably using triangles. A lot depends on the complexity of the polyhedra
object and how the mesh is generated.

-- 
Ken Tyler

Post a reply to this message

Andrea Ryan wrote:
> 
> Which way of making polyhedra is faster: using triangle meshes or
> intersections of planes like those in the shapes2.inc file?
> Brendan

To generate or render?  I'm not sure about parsing, but mesh definitely
renders faster.

-- 
David Fontaine  <dav### [at] faricynet>  ICQ 55354965
My raytracing gallery:  http://davidf.faricy.net/

Post a reply to this message

In article <3B4A66AA.81C0BC71@global2000.net>,
 Andrea Ryan <ary### [at] global2000net> wrote:

> Which way of making polyhedra is faster: using triangle meshes or
> intersections of planes like those in the shapes2.inc file?

It probably depends on what you are doing...meshes will definitely be 
faster if you don't manually bound the CSG intersections properly...an 
intersection of planes will normally be considered infinite. If you have 
a large number of polyhedra, meshes will be more efficient.
I really have no idea which would be faster if the intersection is well 
bounded.

-- 
Christopher James Huff - chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:
: If you have 
: a large number of polyhedra, meshes will be more efficient.

  Specially if all the triangles are inside the same mesh.
  There isn't really big rendering speed difference between 100000 and 200000
triangles when they are inside the same mesh (a couple of % perhaps).

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

Post a reply to this message

>   Specially if all the triangles are inside the same mesh.
>   There isn't really big rendering speed difference between 100000 and 200000
> triangles when they are inside the same mesh (a couple of % perhaps).

Does this mean two copies of twenty-four different meshes will render
faster than forty-eight intersections of planes?  Or is the number of
polyhedra I will use too small to matter?  I'll go for the meshes.  It
would be easier to figure out where the vertexes of the triangles are by
looking at pictures or by truncating or stellating more basic polyhedra
than to figure out how the planes need to be rotated and translated.  I
will  define them so that they will rest on plane { y,0 }.  I'll make
the cube the Platonic solid with the most surface area in contact with
the plane.  The triangles and pentagons of the other Platonic solids
will be inscribed into the square used for the cube.  Then I will make
other shapes by truncating and stellating these solids.  The truncated
ones will be smaller and the stellated ones will be larger.  I will try
to figure out how big the polyhedra game board will need to be to
contain all of the polyhedra by finding the area of the bounding boxes
of the largest polyhedra.
Brendan

Post a reply to this message

Andrea Ryan <ary### [at] global2000net> wrote:
: Does this mean two copies of twenty-four different meshes will render
: faster than forty-eight intersections of planes?

  To get the maximum rendering speed you should put all your triangles inside
the same mesh.

  When we are talking about the same shape which is copied several times over
the scene, whether it's better to make a mesh from the shape and then copy
the mesh over the scene, or whether it's better to put all the triangles inside
the same mesh, depends on how many triangles the shape has.
  If the shape has just a few triangles (as is usually the case with a
polyhedron) it's better to put everything inside a single mesh.
  If the shape consists of a huge amount of triangles (several thousands
or more) then it may be better to make it one mesh and then copy this mesh
around the scene. This way memory is saved.

  Making a mesh with a few triangles and then copying this mesh thousands
of times over the scene effectively neutralizes the advantages of the mesh
object. With just a few triangles no considerable rendering speed is achieved,
and copying it many times doesn't save too much memory either.
  The more triangles there are inside the same mesh, the more speed is
achieved.

  In theory, if you have n meshes with 1 triangle each, it will take n
ray-triangle intersection tests to calculate one ray (ie. if you have
1 million triangles this way, it will require 1 million ray-triangle
intersection tests).
  If you have 1 mesh with n triangles inside it, it will, in theory, take
an average of log8(n) ray-triangle intersection tests to calculate one ray
(ie. if you have 1 million triangles, it will require 7 ray-triangle
intersection tests).
  (Of course the numbers probably differ from these in practice, but the
order of magnitude should be approximately this.)

  This is why adding 100000 triangles to a mesh which already had 100000
triangles in it (ie. totaling 200000 triangles) doesn't make any considerable
rendering speed difference.

  Of course the other side of the coin is memory usage.
  If you have a mesh with 100000 triangles in it and you want to copy it
1000 times over the scene, it's memory-wise better to just copy the mesh
instead of copying the triangles inside the same mesh. The rendering time
will suffer a bit from this, but the saved memory can we definitely worth
it (in some cases it can even speed up the rendering if it helps to avoid
swapping).

  So the rule of thumb is:

  - If you have a mesh with just a few triangles (some tens of them) and you
    want to copy this shape many times, copy the triangles inside the same
    mesh instead of copying the mesh itself. This will speed up the rendering.

  - If you have a mesh with lots of triangles in it (tens of thousands or
    more), and you want to copy it several times, copy the mesh. It will save
    lots of memory.

  - In the in-between cases you'll have to find a compromise.


  (Perhaps I should write this into the VFAQ?)

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

Post a reply to this message

>   (Perhaps I should write this into the VFAQ?)
> 
Thanks, and go ahead with putting it into the VFAQ.
Brendan

Post a reply to this message

Using triangles will be faster - you have the same # of triangles as
planes.  Finding ray-surface intersection for triangle is marginally
slower than w/ plane, however there's a big overhead to do the CSG for
the planes.

Of course, you might want the polyhedron to be solid...

Xander

Andrea Ryan wrote:
> 
> Which way of making polyhedra is faster: using triangle meshes or
> intersections of planes like those in the shapes2.inc file?
> Brendan

Post a reply to this message

I have made #declares of meshes for the tetrahedron, cube and
octahedron.  I saw some vertexes of the dodecahedron and the icosahedron
in another polyhedra include file.  They used the golden ratio.  Is
there a reason for this?  I want to have the edges have lengths of one. 
I'll use some trig to find coordinates of the points that will give that
result.
Brendan

Post a reply to this message

Andrea Ryan wrote:
> 
> I have made #declares of meshes for the tetrahedron, cube and
> octahedron.  I saw some vertexes of the dodecahedron and the icosahedron
> in another polyhedra include file.  They used the golden ratio.  Is
> there a reason for this?  I want to have the edges have lengths of one.

Yes!  If you have an icosahedron with edge lengths of one, you can
inscribe three mutually orthogonal golden rectangles.  With the
dodecahedron, you can inscribe three mutually orthogonal rectangles in
the ratio phi^2 (which incidentally is phi + 1).

-- 
David Fontaine  <dav### [at] faricynet>  ICQ 55354965
My raytracing gallery:  http://davidf.faricy.net/

Post a reply to this message

David Fontaine wrote:
> 
> Andrea Ryan wrote:
> >
> > I have made #declares of meshes for the tetrahedron, cube and
> > octahedron.  I saw some vertexes of the dodecahedron and the icosahedron
> > in another polyhedra include file.  They used the golden ratio.  Is
> > there a reason for this?  I want to have the edges have lengths of one.
> 
> Yes!  If you have an icosahedron with edge lengths of one, you can
> inscribe three mutually orthogonal golden rectangles.  With the
> dodecahedron, you can inscribe three mutually orthogonal rectangles in
> the ratio phi^2 (which incidentally is phi + 1).

Oh, of course, the edge length doesn't matter.  But the shorter sides of
the rectangles are opposite edges, so if the edge length is one, the
length of the other sides are just phi or phi^2.

-- 
David Fontaine  <dav### [at] faricynet>  ICQ 55354965
My raytracing gallery:  http://davidf.faricy.net/

Post a reply to this message

> Yes!  If you have an icosahedron with edge lengths of one, you can
> inscribe three mutually orthogonal golden rectangles.  With the
> dodecahedron, you can inscribe three mutually orthogonal rectangles in
> the ratio phi^2 (which incidentally is phi + 1).
> 

I looked at my paper models of the icosahedron and the dodecahedron and
saw the rectangles.  This should help with finding the coordinates of
the vertexes.  It's almost magic.  Thank you!  :-)

The golden ratio is one of those mysterious irrational numbers.  As you
said, its square is equal to the sum of one and itself.  Its reciproial
is equal to its value minus one.  I wonder if there's an undiscovered
equation that relates it to other constants like e^(i*pi) + 1 = 0.

I have seen the number called the golden mean.  It is because a golden
rectangle has a mean ratio between its sides and not extreme ones?
Brendan

Post a reply to this message

Andrea Ryan wrote:
> 
> I looked at my paper models of the icosahedron and the dodecahedron and
> saw the rectangles.  This should help with finding the coordinates of
> the vertexes.  It's almost magic.  Thank you!  :-)

Teehee

 
> The golden ratio is one of those mysterious irrational numbers.  As you
> said, its square is equal to the sum of one and itself.  Its reciproial
> is equal to its value minus one.  I wonder if there's an undiscovered
> equation that relates it to other constants like e^(i*pi) + 1 = 0.

If there is it must be something real obscure!  Hey, I read in the book
Chaos that some guy discovered another important irrational number, like
e and pi, that comes up as a sort of 'octave multiplier' (if you get
what i mean) in bifurcation diagrams and other chaosy stuff.

 
> I have seen the number called the golden mean.  It is because a golden
> rectangle has a mean ratio between its sides and not extreme ones?

I dunno.  Probably has to do with Fibonacchi.


-- 
David Fontaine  <dav### [at] faricynet>  ICQ 55354965
My raytracing gallery:  http://davidf.faricy.net/

Post a reply to this message

David Fontaine wrote:

> Hey, I read in the book
> Chaos that some guy discovered another important irrational number, like
> e and pi, that comes up as a sort of 'octave multiplier' (if you get
> what i mean) in bifurcation diagrams and other chaosy stuff.

Perhaps you are referring to the Feigenbaum constants?

http://www.mathsoft.com/asolve/constant/constant.html

http://pauillac.inria.fr/algo/bsolve/constant/fgnbaum/general.html

Post a reply to this message

Kevin Wampler wrote:
> 
> David Fontaine wrote:
> 
> > Hey, I read in the book
> > Chaos that some guy discovered another important irrational number, like
> > e and pi, that comes up as a sort of 'octave multiplier' (if you get
> > what i mean) in bifurcation diagrams and other chaosy stuff.
> 
> Perhaps you are referring to the Feigenbaum constants?
> 
> http://www.mathsoft.com/asolve/constant/constant.html
> 
> http://pauillac.inria.fr/algo/bsolve/constant/fgnbaum/general.html

I think that's it.  4.669 looks awfully familiar, I think that's the one
in the book.  Of course the book has to talk about technological
limitations and how these chaoticians would spend hours generating these
numbers to a whopping four significant figures on their HP calcs, at
least until they could sneak in a few minutes on the Los Alamos Cray...
;)

-- 
David Fontaine  <dav### [at] faricynet>  ICQ 55354965
My raytracing gallery:  http://davidf.faricy.net/

Post a reply to this message

David Fontaine wrote:

> these chaoticians would spend hours generating these
> numbers to a whopping four significant figures on their HP calcs, at
> least until they could sneak in a few minutes on the Los Alamos Cray...

It's kind of nice that times have changed, but some constants are still hard to
calculate to a high degree of accuracy.  Brun's Constant, for example, has only
been calculated to 11 or so significant figures.  I guess that the faster
computers get, the more people try to do with them.  Kind of like Pov.

Post a reply to this message