Nieminen Mika wrote:
> 
>   The mesh version is more recommendable since meshes render much faster
> than a union of triangles.


I disagree with your statement. I just ran three tests of unions vs. meshs
of triangles and the unions in all three cases parsed and rendered faster.
Meshs seem to only have the advantage of memory optimization when using
multiple copies of the same mesh object.

Triangle object 1 - 200 triangles

union parse   render
       0      22 sec
mesh   0      26 sec

Triangle object 2 - 1000 triangles

      parse   render
union  2      25 sec
mesh   2      30 sec

Triangle object 3 - 6000 triangles

      parse   render
union   9     32 sec
mesh   10     39 sec


-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:
: I disagree with your statement. I just ran three tests of unions vs. meshs
: of triangles and the unions in all three cases parsed and rendered faster.
: Meshs seem to only have the advantage of memory optimization when using
: multiple copies of the same mesh object.

  This test seems extremely strange since my experience states the contrary.
  The lparser program produces a union of triangles. The parsing time
usually blows up in the "creating light buffers" stage (several minutes
in my old 486; not tested in my new P-II). Substituting "union" with "mesh"
reduced that stage to seconds.
  Also the faster rendering time seems strange since AFAIK povray generates
an efficient octree (or a similar data structure) from the mesh while it
can't do that with a union of objects. Testing ray-triangle intersections
is much more faster with that kind of data structure.
  I have to test this by myself...

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Glen Berry <7no### [at] ezwvcom> wrote:
: Why not? I have seen mesh files where each triangle had a unique
: pigment definition. Each line of the mesh file had a triangle
: definition followed by a pigment definition. This makes for a much
: larger mesh file, and it takes longer to parse than an uncolored mesh,
: but it does work. One doesn't *have* to #declare pigments or textures
: in advance if using something like "rgb <0.8, 0.4, 0.2>" to define the
: colors on each line is acceptable.

  As Ken replied, it's not possible.
  However, I can hardly believe that you had to declare a pigment for each
triangle. I don't think each triangle has a unique color. Those meshes you
are describing sound to me like they had just a few hundreds of colors.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Mika wrote:
> 
> Ken <tyl### [at] pacbellnet> wrote:
> : I disagree with your statement. I just ran three tests of unions vs. meshs
> : of triangles and the unions in all three cases parsed and rendered faster.
> : Meshs seem to only have the advantage of memory optimization when using
> : multiple copies of the same mesh object.
> 
>   This test seems extremely strange since my experience states the contrary.
>   The lparser program produces a union of triangles. The parsing time
> usually blows up in the "creating light buffers" stage (several minutes
> in my old 486; not tested in my new P-II). Substituting "union" with "mesh"
> reduced that stage to seconds.
>   Also the faster rendering time seems strange since AFAIK povray generates
> an efficient octree (or a similar data structure) from the mesh while it
> can't do that with a union of objects. Testing ray-triangle intersections
> is much more faster with that kind of data structure.
>   I have to test this by myself...
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

  Even stranger still is that the UV patch takes even longer to parse
and render a mesh vs. a union of triangles than the official version.
One quick test showed a 670 triangle object render in 22 sec within a
union but took 33 sec. in a mesh.
  Worthy of note is that the memory usage heavily favored the mesh
object. The mesh used a peak memory of something like 122k while the
union consumed a peak of 170k.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

On 20 Jun 1999 04:13:41 -0400, Nieminen Mika <war### [at] cctutfi> wrote:

>  As Ken replied, it's not possible.
>  However, I can hardly believe that you had to declare a pigment for each
>triangle. I don't think each triangle has a unique color. Those meshes you
>are describing sound to me like they had just a few hundreds of colors.

I just tried to create a "colored mesh" and Ken was right in one
sense. I couldn't create a colored mesh using the "mesh" keyword, but
I could create the equivalent structure using a union of triangles. I
randomly colored an 8Meg mesh file to test this. It took *much* longer
to parse and required much more memory to render than the uncolored
version.

In the past I have seen meshes that had pigment statements for each
triangle. I suppose those were unions of triangles instead of POV-Ray
mesh objects. It's been a while since I saw a file like I'm thinking
about and it might have been before the "mesh" keyword was added to
the POV language.

Sorry for any confusion caused by earlier statement. You *can* have
individually colored triangles, but not as a POV "mesh" object.

Later,
Glen Berry

Post a reply to this message

Glen Berry wrote:

> In the past I have seen meshes that had pigment statements for each
> triangle. I suppose those were unions of triangles instead of POV-Ray
> mesh objects. It's been a while since I saw a file like I'm thinking
> about and it might have been before the "mesh" keyword was added to
> the POV language.

 There were a couple of utilities written for Pov v2.2 that had random
triangle pigment options. Which of these had this feature I can't recall
off hand but they were out there. A similar utility that does come to
mind was the utility called Suds which may have been used for the original
Pov v3.0 splash screen. This program spit out randomly scaled spheres
and if the rght command line switch was selected it would create a unique
and seperate texture for every sphere it produced in a seperate inc file.
Talk about a memory this one had the market cornered. Another small util
that offered similar abilities was called boxer. It too would produce
indivudualy colored boxes each with a unique randomly determined pigment
statment.
 
> Sorry for any confusion caused by earlier statement.

Didn't confuse me for a second :-) Like I always say though "To err is Ken".

> You *can* have individually colored triangles, but not as
> a POV "mesh" object.

  But you Can have it in a mesh object IF you pre declare it in a texture
statement and then apply the texture to each triangle. Still you are
correct that is very resource intensive and may not be worth the effort
in very large constructs.
 
> Later,
> Glen Berry

Asta la bye bye,

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Glen Berry wrote:
> In the past I have seen meshes that had pigment statements for each
> triangle. I suppose those were unions of triangles instead of POV-Ray
> mesh objects. It's been a while since I saw a file like I'm thinking
> about and it might have been before the "mesh" keyword was added to
> the POV language.
> Later,
> Glen Berry

Lparser was notorius for individualy colored triangles but these were usualy
restircted to something like 12 or less predefined pigment statments and it
didn't even bother wrapping them in a union.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:
: Still you are
: correct that is very resource intensive and may not be worth the effort
: in very large constructs.

  You can automatically generate, for example, an array of textures and
then use the textures in the mesh.
  I disagree with you: It is worth the effort in very large constructs
since the memory saving with the mesh is considerable. See my post about
mesh/union render time comparison.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

David Arcoleo wrote:
> 
> Hi all, I'm writing an application that takes graphs in Mathematica and
> converts them to povray source.  I construct the objects using triangles
> and am including an option to do an exact color match.  How do I give a
> triangle an rgb?  Everything I try doesn't seem to work.
> 
> Thanks,
> -Dave

  Exactly how many colors do you expect you will have to produce to
match mathmatica's colors in the conversion. If you are talking less
than say 50 - 100 individual colors or so it might be worth your
effort to write a sorting routine that places the triangles of a
given color each into it's own mesh object. This way you need only
add a pigment to each group of triangles as opposed to every triangle
you produce.


-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

>   Exactly how many colors do you expect you will have to produce to
> match mathmatica's colors in the conversion. If you are talking less
> than say 50 - 100 individual colors or so it might be worth your
> effort to write a sorting routine that places the triangles of a
> given color each into it's own mesh object. This way you need only
> add a pigment to each group of triangles as opposed to every triangle
> you produce.

Well, in thinking over the problem, I have think that assigning a
seperate color to each
triangle would be too massive.  This is my situation -

I am writing a utility to convert Mathematica images to povray. 
Mathematica's use of lighting is not the same as povray's and converting
it is kindof a pain.  Also, there isn't a whole lot of documentation on
the subject.  Therefor, I thought that grabbing the color from each
triangle would be the easiest.  It's easy enough for me to grab the
color, but if the trade off is such a huge file, then it's not worth it
to me.  For my utility, I have to consider the following -

1.  Time it takes Mathematica to generate the image itself - .02 seconds
2.  Time it takes for my MathLink program to grab the data from
Mathematica - .5 seconds
3.  Time it takes for my program to generate a povray file from it - 6
seconds
4. Time it takes for povray to render the image - 9 seconds

This is on a K6/2-266, 64 megs ram, running Winnt 4, Mathematica 4.0,
Mathlink 7, and vc5, and povray 3.1 (320x20)

At present, my program only generates povray files for surfacegraphics,
which means I only have to send z values across mathlink.  I'm adding 3d
graphics, which will mean that it has to send x, y, and z values.  This
triple the mathlink time, but add nothing to the povray generation and
mathematica generation time.  if however, I have to send <x, y, z> AND
<r, g, b>, then the 
mathematica time will remain the same, the mathlink time will increase
six-fold, the povray
file size will double, and the generation time will surely double. (at
least).

I think, therefor, that the best solution is to spend more time trying
to mimick Mathematica's behaviour in povray.  These timing will become
critical later, as the number of points that I'm dealing with grows to
upwards of 1 million and i'm generating povray images in 1280x1024. 
This  brings me to the next question - has anyone ever used
Mathematica?  I'm really bad at two major things - copying viewpoints
and lighting.  I can't seem to get them to correspond. This is of course
because I'm not a graphics person at all so I have no experience this
this aspect of mathematica programming, or any graphics backage for that
matter.

Thank you all for your support in this.

-Dave

Post a reply to this message