Hi/Hello
I have a problem and can't fix it. I download two files that generate a tree
several months ago. Before that download I used to generate the trees with an
executable (java file povtree.jar), Povtree that allows the user to generate a
mesh directly in a file (idealy a *.inc file), a mesh object with a lot of
triangles. Then with the two files ("TOMLEAF.inc" and "TOMTREE-1.5.inc" that
contain macro) and a smaller tree file generated with Povtree java executable
(that smaller file contains only some parameter like numbers #declares and
leaves, trunk colors but doesn't contain lots of triangles (excepted a sample of
a leaf , a mesh object definition)), unlike the previous include file described
above.
There are advantages at using the two macro files with the small tree config
file:
- It seems that the flore is generated faster at parsing time.
- The total size of the povray scene files is a lot smaller (5 MB against 285 MB
for example for a kapok tree).
I'd like to keep theses advantages and not using the big included mesh file. But
this configuration has a bug (I think): When I generate the kapok tree (the
macro creates an object with a declare: a mesh object named TREE ) and without
modifying it after and planting it several time with nested for loops, I see on
the system monitor of Ubuntu 18.04 that I quickly reach max occupied ram I can
get on my computer : 16 GB of ram (I CTRL-C before ). The loops are like this:
//-----------
#for(it_x, -100, 100, 2)
    #for(it_z, -100, 100, 2)
        object{TREE translate <it_x, 0, it_z> }
    #end
#end
//----------
As you can see there is not so much sample of kapok tree (at least nothing that
can spare 16 GB of ram.
When I render the scene with the big include file (~285 MB ) POVray manages the
memory much better because the memory this time doesn't overcome 1 GB.

I think the solution is in the macro files but I can't get the solution. I made
some modifications (after the memory problem, taht said) like commenting blocks
of code like (in TOMTREE-1.5.inc:

//bounded_by{cylinder{<0, 0, 0>, <0, BH, 0>, BH}}

//--------------
or in TOMLEAF.inc:
 /*
      clipped_by
      {
            cylinder
            {
                  <.5,0,0>,<.5,1.1,0>,.5
                  scale <1,1,2/3>
            }
      }
 */

....because POVray complained there was unecessarily bounding in these files.

Infos: I use POVRay in version 3.8 : POV-Ray
3.8.0-x.tokenizer.9686180.unofficial

But I had the same issue with POVRay 3.7 (stable)

The macro files TOMLEAF.inc and TOMTREE-1.5.inc can be downloaded on this link:

http://www.ant01.fr/fichiersAnt01/povray/povtreeMacroFiles.zip the archive size
is 2.6MB and I didn't include the big kapok tree file (it doesn't bug).

Thank you.

Post a reply to this message

Edit: You may think the problem is an infinite loop, but when I make a render
with the following code:
//#version 3.7;

global_settings{ assumed_gamma 1.0 }

camera{
       location <0, 22, -65>
       look_at <0, 12, 0>
}

light_source{ <3, 4, -3>*1000000 color srgb 1 }


#include "treeFiles/kapok.tree"
#include "povtree/TOMTREE-1.5.inc"

#debug "Loaded KapokTree\n"

#for(it_x, -20, 20, 2)
 #for(it_z, -20, 20, 2)
  object{TREE translate <it_x, 0, it_z> }
 #end
#end

//-------------------------------------
I have about 9.2 GB spared and a render is done (I even see "Loaded KapokTree\n"
in the console). That's why I think (see my message above) something's wrong
with the macro and prevents povray to do good memory management.

Post a reply to this message

I'm not sure I understand your explanation of what you're doing, so
here's my understanding of it, so that you can correct me if I'm wrong:

- You have a scene that "plants" trees using `object{TREE...}` in a loop.

- Previously, `TREE` was defined as a single `mesh` or `mesh2`,
generated by an external tool, and all was reasonably well.

- Now, you have changed the definition of `TREE` to... something else.

Here's where my understanding falters, but judging from snippets of your
explanation and most of all the symptoms I'm going out on a limb here:
Your new definition is /not/ a single `mesh` or `mesh2` object, but a
CSG compound object, right?


Now here's the catch: When you instantiate any primitive or compound
object in POV-Ray using `object{FOO}`, POV-Ray creates a COPY of the
object in question.

For most primitives and compound objects, this means the memory
requirements are doubled.

Only a handful of inherently memory-intensive primitives - such as
meshes, blobs and height fields - share their bulk data among copies,
thus allowing for a reduced memory footprint despite high number of
copies. Unions and other CSG compounds - although potentially
memory-intensive as well, depending on their complexity - do not fall
into this category.


So the exceptional thing here is not the new memory-heavy version, but
rather the old memory-lean version. And that is simply due to the copied
object happening to be a mesh there.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> I'm not sure I understand your explanation of what you're doing, so
> here's my understanding of it, so that you can correct me if I'm wrong:
>
> - You have a scene that "plants" trees using `object{TREE...}` in a loop.
>
> - Previously, `TREE` was defined as a single `mesh` or `mesh2`,
> generated by an external tool, and all was reasonably well.
>
> - Now, you have changed the definition of `TREE` to... something else.
>
> Here's where my understanding falters, but judging from snippets of your
> explanation and most of all the symptoms I'm going out on a limb here:
> Your new definition is /not/ a single `mesh` or `mesh2` object, but a
> CSG compound object, right?
>
>
> Now here's the catch: When you instantiate any primitive or compound
> object in POV-Ray using `object{FOO}`, POV-Ray creates a COPY of the
> object in question.
>
> For most primitives and compound objects, this means the memory
> requirements are doubled.
>
> Only a handful of inherently memory-intensive primitives - such as
> meshes, blobs and height fields - share their bulk data among copies,
> thus allowing for a reduced memory footprint despite high number of
> copies. Unions and other CSG compounds - although potentially
> memory-intensive as well, depending on their complexity - do not fall
> into this category.
>
>
> So the exceptional thing here is not the new memory-heavy version, but
> rather the old memory-lean version. And that is simply due to the copied
> object happening to be a mesh there.

Thank you for that detailed explanation (I have learned things :-D).

Clipka has written:
> - Now, you have changed the definition of `TREE` to... something else.
I just commented the blocks 'bounded_by' and 'clipped_by' to avoid recursive
(because they are in nested loops) console warnings ("[...] uneccesarily bounded
[...]" or something like that). I didn't changed anything else. I changed
something, that's true anyway.

For the rest/remaining, you understood well, that's ok. ;-). I do think you have
pointed out the root of the problem. But I have another question. I took a look
at the two macro files TOMTREE-1.5.inc and TOMLEAF.inc , and there's no
'triangle' key word at all whereas in the big file, there are a lot of them. But
in the light kapokTree.tree (tree parameters and 5.7 KB size ) there are
triangles. On top of that there are 6 calls of 'sphere' keyword in TOMTREE-1.5.
Maybe the problem comes from there. I will try to comment them to see what
happens, after all in the big file 'kapokTree.inc', there is no sphere at all
and the two options for making trees give the same results.

Here is the structure of the "big" include file:
//-----------------------
#declare RINDE = texture { /* things here */ }

#declare RINDE1 = texture { /* etc... */ }

#declare BOZO1 = pigment { }

#declare BOZO2 = pigment { }

#declare LAUB = texture { }

#declare FOLIAGE = mesh {
 /* lots of triangles */
 triangle{<0.0033702592, -0.87877595, 0.02495137>, <0.0032317375, -0.8788011,
0.025241831>, <0.0031905263, -0.8787052, 0.02539288>} //Line 155587 in file
kapokTree.inc
 rotate z*180
 rotate y*180
 texture{LAUB scale 1/1174.8451}
}

#declare WOOD = mesh {
 /* lots of triangles */
 rotate z*180
 rotate y*180
 texture {
  onion
  texture_map {
   [0 RINDE scale <1/942.35, 1/5874.225, 1/942.35>]
   [0.3 RINDE scale <3.1835306E-4, 5.107057E-5, 3.1835306E-4>]
   [1 RINDE scale <1.0611769E-4, 1.7023522E-5, 1.0611769E-4>]
  }
  scale <942.35, 5874.225, 942.35>/371.0
 }
}

#declare TREE = union {
object{FOLIAGE}
object{WOOD}
}
//End of file , line 2 196 393

Post a reply to this message

On 20-7-2018 21:45, Warren wrote:
> clipka <ano### [at] anonymousorg> wrote:
>> I'm not sure I understand your explanation of what you're doing, so
>> here's my understanding of it, so that you can correct me if I'm wrong:
>>
>> - You have a scene that "plants" trees using `object{TREE...}` in a loop.
>>
>> - Previously, `TREE` was defined as a single `mesh` or `mesh2`,
>> generated by an external tool, and all was reasonably well.
>>
>> - Now, you have changed the definition of `TREE` to... something else.
>>
>> Here's where my understanding falters, but judging from snippets of your
>> explanation and most of all the symptoms I'm going out on a limb here:
>> Your new definition is /not/ a single `mesh` or `mesh2` object, but a
>> CSG compound object, right?
>>
>>
>> Now here's the catch: When you instantiate any primitive or compound
>> object in POV-Ray using `object{FOO}`, POV-Ray creates a COPY of the
>> object in question.
>>
>> For most primitives and compound objects, this means the memory
>> requirements are doubled.
>>
>> Only a handful of inherently memory-intensive primitives - such as
>> meshes, blobs and height fields - share their bulk data among copies,
>> thus allowing for a reduced memory footprint despite high number of
>> copies. Unions and other CSG compounds - although potentially
>> memory-intensive as well, depending on their complexity - do not fall
>> into this category.
>>
>>
>> So the exceptional thing here is not the new memory-heavy version, but
>> rather the old memory-lean version. And that is simply due to the copied
>> object happening to be a mesh there.
> 
> Thank you for that detailed explanation (I have learned things :-D).
> 
> Clipka has written:
>> - Now, you have changed the definition of `TREE` to... something else.
> I just commented the blocks 'bounded_by' and 'clipped_by' to avoid recursive
> (because they are in nested loops) console warnings ("[...] uneccesarily bounded
> [...]" or something like that). I didn't changed anything else. I changed
> something, that's true anyway.
> 
> For the rest/remaining, you understood well, that's ok. ;-). I do think you have
> pointed out the root of the problem. But I have another question. I took a look
> at the two macro files TOMTREE-1.5.inc and TOMLEAF.inc , and there's no
> 'triangle' key word at all whereas in the big file, there are a lot of them. But
> in the light kapokTree.tree (tree parameters and 5.7 KB size ) there are
> triangles. On top of that there are 6 calls of 'sphere' keyword in TOMTREE-1.5.
> Maybe the problem comes from there. I will try to comment them to see what
> happens, after all in the big file 'kapokTree.inc', there is no sphere at all
> and the two options for making trees give the same results.
> 

I think that you are mixing up to different things. Clipka already 
hinted at the same. To understand what is happening when using POVtree 
(written by Gena Obukov) you need to know a bit of the program's history.

- TOMtree was written by Tom Aust in 2000 as a POV-Ray set of macros to 
generate CSG tree objects, i.e. /without/ the use of triangles. That is 
the reason why you do not find triangles in those macros.

- POVtree was written by Gena Obukov as a java program, based on the 
TOMtree macros, with - as an addition - the possibility to export the 
tree as a mesh{} object (hence the triangles). Otherwise, POVtree saves 
the data in the TOMtree format which can be used as CSG object.

- [aside] Implementation of mesh2{} export was never realised and 
meanwhile unfortunately Gena disappeared from the POV scene. [/aside]

So, in defining your problem, you need to clearly discriminate between 
what is due to the TOMtree macros, and what is due to POVtree.

Hoping to have shed a little light.

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
>
> I think that you are mixing up to different things. Clipka already
> hinted at the same. To understand what is happening when using POVtree
> (written by Gena Obukov) you need to know a bit of the program's history.
>
> - TOMtree was written by Tom Aust in 2000 as a POV-Ray set of macros to
> generate CSG tree objects, i.e. /without/ the use of triangles. That is
> the reason why you do not find triangles in those macros.
>
> - POVtree was written by Gena Obukov as a java program, based on the
> TOMtree macros, with - as an addition - the possibility to export the
> tree as a mesh{} object (hence the triangles). Otherwise, POVtree saves
> the data in the TOMtree format which can be used as CSG object.
>
> - [aside] Implementation of mesh2{} export was never realised and
> meanwhile unfortunately Gena disappeared from the POV scene. [/aside]
>
> So, in defining your problem, you need to clearly discriminate between
> what is due to the TOMtree macros, and what is due to POVtree.
>
> Hoping to have shed a little light.
>
> --
> Thomas

Based on your last explanation and what I've been seeing in TOMTREE-1.5.inc and
the povtree java generated mesh file (tell me if I'm wrong):

- If I stick to the TOMTREE-1.5.inc file and choose not to generate a mesh file
with povtree , I get a CSG object , i.e, a union of blob and mesh (only the
leaves are meshes; the trunk, twigs, branches and ramifications are blob of
spheres (no cylinders, but that's a detail). And there can be height fields too
(though I'm not sure), there are height fields objects in 'TOMLEAF.inc' which is
a file used with TOMTREE-1.5.inc.

- If I stick to the mesh file generated with povtree , I get a union of two mesh
objects named WOOD and FOLIAGE but that's still a CSG object because basically
it's a union.

There is only union as CSG parameter , and no merge, intersection or difference
at all. I didn't find any trace of theses words in all files.

But Clipka said that blobs, height fileds and meshes share their bulk data among
copies. So, if I understand that the CSG mesh file that contains FOLIAGE and
WOOD is not copied each time a new sample of it is created, why is this not the
case of the CSG object generated by TOMTREE-1.5.inc ? After thinking more about
it I have some other questions that can answer the first one (I'm sorry, I don't
speak english perfectly, but I have a french/english dictionnary beside me ;-)
):

The CSG object generated by TOMTREE-1.5.inc (from Tom Aust) is a 'compound'
object. That means it is a 'mix' of several different objects, which explains
like clipka said that it is an object that is therefore copied each time you
create a new sample of it ?
Whereas the object that is a union of WOOD and FOLIAGE is not a 'compound'
object, that's a mesh even if there is a union of these two meshes.

Is this the cornerstone that explains that one is copied and the other not?

Post a reply to this message

Am 21.07.2018 um 11:46 schrieb Warren:

> - If I stick to the TOMTREE-1.5.inc file and choose not to generate a mesh file
> with povtree , I get a CSG object , i.e, a union of blob and mesh (only the
> leaves are meshes; the trunk, twigs, branches and ramifications are blob of
> spheres (no cylinders, but that's a detail). And there can be height fields too
> (though I'm not sure), there are height fields objects in 'TOMLEAF.inc' which is
> a file used with TOMTREE-1.5.inc.
...
> But Clipka said that blobs, height fileds and meshes share their bulk data among
> copies. So, if I understand that the CSG mesh file that contains FOLIAGE and
> WOOD is not copied each time a new sample of it is created, why is this not the
> case of the CSG object generated by TOMTREE-1.5.inc ?

You say that "the leaves are meshes"; if by that you mean that there is
a leaf mesh, and the foliage of a single tree is multiple copies of that
mesh, that does explain the symptoms.

While meshes do share their bulk data when copied, they each carry their
own individual overhead, which is heavier than one might think.

If you use one mesh per leaf, you have a lot of overhead per triangle in
the mesh, and thus the data sharing reduces the memory footprint only by
a marginal fraction.

If instead of one mesh per leaf you use one huge mesh for the entire
foliage of the tree, you only have one instance of the overhead. You do
have much more bulk data, and unless the leaf mesh is trivially simple
this may actually leave you with a larger total memory footprint for a
single tree; but as soon as you create multiple instances of that tree,
the impact of the bulk data on the total memory footprint quickly
diminishes.


> The CSG object generated by TOMTREE-1.5.inc (from Tom Aust) is a 'compound'
> object. That means it is a 'mix' of several different objects, which explains
> like clipka said that it is an object that is therefore copied each time you
> create a new sample of it ?
> Whereas the object that is a union of WOOD and FOLIAGE is not a 'compound'
> object, that's a mesh even if there is a union of these two meshes.
> 
> Is this the cornerstone that explains that one is copied and the other not?

The term "compound object" in the context of POV-Ray is typically used
in the sense of "non-primitive", i.e. an object that is comprised of
other objects. Whether the members of such compound object are of same
type or different types is irrelevant, as there's no special processing
happening in same-type cases.

Post a reply to this message

On 21-7-2018 12:31, clipka wrote:
> Am 21.07.2018 um 11:46 schrieb Warren:
> 
>> - If I stick to the TOMTREE-1.5.inc file and choose not to generate a mesh file
>> with povtree , I get a CSG object , i.e, a union of blob and mesh (only the
>> leaves are meshes; the trunk, twigs, branches and ramifications are blob of
>> spheres (no cylinders, but that's a detail). And there can be height fields too
>> (though I'm not sure), there are height fields objects in 'TOMLEAF.inc' which is
>> a file used with TOMTREE-1.5.inc.

In TOMtree, leaves can be defined as height_fields instead of spheres. I 
/think/ this can be defined also in POVtree but I seem to remember (it's 
been a long time since I last used the program) that this generates an 
error. Never corrected at the time, /if/ it was ever reported to Gena 
Obukhov...

> ...
>> But Clipka said that blobs, height fileds and meshes share their bulk data among
>> copies. So, if I understand that the CSG mesh file that contains FOLIAGE and
>> WOOD is not copied each time a new sample of it is created, why is this not the
>> case of the CSG object generated by TOMTREE-1.5.inc ?
> 
> You say that "the leaves are meshes"; if by that you mean that there is
> a leaf mesh, and the foliage of a single tree is multiple copies of that
> mesh, that does explain the symptoms.

When the tree is exported as a mesh, FOLIAGE is a mesh{} of /all/ the 
leaves of the tree, not individual meshes for each leaf.

> 
> While meshes do share their bulk data when copied, they each carry their
> own individual overhead, which is heavier than one might think.
> 
> If you use one mesh per leaf, you have a lot of overhead per triangle in
> the mesh, and thus the data sharing reduces the memory footprint only by
> a marginal fraction.

Not the case with POVtree (see above).

> 
> If instead of one mesh per leaf you use one huge mesh for the entire
> foliage of the tree, you only have one instance of the overhead. You do
> have much more bulk data, and unless the leaf mesh is trivially simple
> this may actually leave you with a larger total memory footprint for a
> single tree; but as soon as you create multiple instances of that tree,
> the impact of the bulk data on the total memory footprint quickly
> diminishes.
> 

That is what happens with POVtree meshes indeed.

> 
>> The CSG object generated by TOMTREE-1.5.inc (from Tom Aust) is a 'compound'
>> object. That means it is a 'mix' of several different objects, which explains
>> like clipka said that it is an object that is therefore copied each time you
>> create a new sample of it ?
>> Whereas the object that is a union of WOOD and FOLIAGE is not a 'compound'
>> object, that's a mesh even if there is a union of these two meshes.
>>
>> Is this the cornerstone that explains that one is copied and the other not?
> 
> The term "compound object" in the context of POV-Ray is typically used
> in the sense of "non-primitive", i.e. an object that is comprised of
> other objects. Whether the members of such compound object are of same
> type or different types is irrelevant, as there's no special processing
> happening in same-type cases.
> 


-- 
Thomas

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> You say that "the leaves are meshes"; if by that you mean that there is
> a leaf mesh, and the foliage of a single tree is multiple copies of that
> mesh, that does explain the symptoms.
>
> While meshes do share their bulk data when copied, they each carry their
> own individual overhead, which is heavier than one might think.
>
> If you use one mesh per leaf, you have a lot of overhead per triangle in
> the mesh, and thus the data sharing reduces the memory footprint only by
> a marginal fraction.
>
> If instead of one mesh per leaf you use one huge mesh for the entire
> foliage of the tree, you only have one instance of the overhead. You do
> have much more bulk data, and unless the leaf mesh is trivially simple
> this may actually leave you with a larger total memory footprint for a
> single tree; but as soon as you create multiple instances of that tree,
> the impact of the bulk data on the total memory footprint quickly
> diminishes.
>
> The term "compound object" in the context of POV-Ray is typically used
> in the sense of "non-primitive", i.e. an object that is comprised of
> other objects. Whether the members of such compound object are of same
> type or different types is irrelevant, as there's no special processing
> happening in same-type cases.

Ok , I think I understand. The overhead of a leaf can be a transform block (i.e.
scale , translate or rotate) or a texture block or any of his sub-part  or
something else I'm not thinking about. The texture for the leaves are applied
globally to the foliage though (If I'm not mistaking).

I said before the kapok tree was about 285 MB in size but I must say it is
exceptional, most of the mesh files are less than 50 MB and something like 5 MB
for the little flores. The precision of the mesh can be diminished in povtree,
but this is less acceptable for such a great tree like the kapok tree (a
rainforest tree, 6 times the highness of a stairless house compared to a plant
that is 1 meter high.

From now on, I will stick to the ready-made mesh files, the headache overhead is
much less important :-D.

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> On 21-7-2018 12:31, clipka wrote:
> > Am 21.07.2018 um 11:46 schrieb Warren:
> >
> >> - If I stick to the TOMTREE-1.5.inc file and choose not to generate a mesh file
> >> with povtree , I get a CSG object , i.e, a union of blob and mesh (only the
> >> leaves are meshes; the trunk, twigs, branches and ramifications are blob of
> >> spheres (no cylinders, but that's a detail). And there can be height fields too
> >> (though I'm not sure), there are height fields objects in 'TOMLEAF.inc' which is
> >> a file used with TOMTREE-1.5.inc.
>
> In TOMtree, leaves can be defined as height_fields instead of spheres. I
> /think/ this can be defined also in POVtree but I seem to remember (it's
> been a long time since I last used the program) that this generates an
> error. Never corrected at the time, /if/ it was ever reported to Gena
> Obukhov...
>
> > ...
> >> But Clipka said that blobs, height fileds and meshes share their bulk data among
> >> copies. So, if I understand that the CSG mesh file that contains FOLIAGE and
> >> WOOD is not copied each time a new sample of it is created, why is this not the
> >> case of the CSG object generated by TOMTREE-1.5.inc ?
> >
> > You say that "the leaves are meshes"; if by that you mean that there is
> > a leaf mesh, and the foliage of a single tree is multiple copies of that
> > mesh, that does explain the symptoms.
>
> When the tree is exported as a mesh, FOLIAGE is a mesh{} of /all/ the
> leaves of the tree, not individual meshes for each leaf.
>
> >
> > While meshes do share their bulk data when copied, they each carry their
> > own individual overhead, which is heavier than one might think.
> >
> > If you use one mesh per leaf, you have a lot of overhead per triangle in
> > the mesh, and thus the data sharing reduces the memory footprint only by
> > a marginal fraction.
>
> Not the case with POVtree (see above).
>
> >
> > If instead of one mesh per leaf you use one huge mesh for the entire
> > foliage of the tree, you only have one instance of the overhead. You do
> > have much more bulk data, and unless the leaf mesh is trivially simple
> > this may actually leave you with a larger total memory footprint for a
> > single tree; but as soon as you create multiple instances of that tree,
> > the impact of the bulk data on the total memory footprint quickly
> > diminishes.
> >
>
> That is what happens with POVtree meshes indeed.
>
> >
> >> The CSG object generated by TOMTREE-1.5.inc (from Tom Aust) is a 'compound'
> >> object. That means it is a 'mix' of several different objects, which explains
> >> like clipka said that it is an object that is therefore copied each time you
> >> create a new sample of it ?
> >> Whereas the object that is a union of WOOD and FOLIAGE is not a 'compound'
> >> object, that's a mesh even if there is a union of these two meshes.
> >>
> >> Is this the cornerstone that explains that one is copied and the other not?
> >
> > The term "compound object" in the context of POV-Ray is typically used
> > in the sense of "non-primitive", i.e. an object that is comprised of
> > other objects. Whether the members of such compound object are of same
> > type or different types is irrelevant, as there's no special processing
> > happening in same-type cases.
> >
>
>
> --
> Thomas

I said that there is an individual mesh for a leaf sample, that's because the
content of my tree parameter kapokTree.tree is like this (an excerpt):

//--------------------------------------------------------
//BARK
#declare SUNKEN_TRUNK_COLOR=<0.4609, 0.4726, 0.4257>;
#declare RAISED_TRUNK_COLOR=<0.375, 0.3359, 0.2892>;
#declare FOLIAGE_COLOR_AT_BRANCH_END=0;
#declare TRUNK_SCAR_WIDTH=1;
#declare TRUNK_SCAR_HEIGHT=5;
#declare HORIZONTAL_SCAR_SHRINKING=0.3;
#declare VERTICAL_SCAR_SHRINKING=1.5;
#declare SCAR_DEPTH=-1;
#declare BARK_PROFILE=0;
#declare BRANCH_BARK_PROFILE_CHANGE=0;
#declare BRANCH_BARK_PROFILE_TAPER_OFF=1;
#declare ROOT_BARK_PROFILE_CHANGE=0;
#declare PALM_TRUNK=0;
//FOLIAGE
#include "povtree/TOMLEAF.inc"
#declare Mesh6a = mesh {
 triangle{<0.35, 0.05, 0.5>, <0.6, 0.0, 0.5>, <0.0, 0.0, 2.9802322E-8>}
 triangle{<0.6, 0.0, 0.5>, <0.55, 0.05, 0.25>, <0.0, 0.0, 2.9802322E-8>}
 triangle{<0.0, 0.0, 2.9802322E-8>, <0.75, 0.05, 0.19999999>, <1.0, 0.0, 0.0>}
 triangle{<0.0, 0.0, 2.9802322E-8>, <0.75, 0.05, -0.19999999>, <1.0, 0.0, 0.0>}
 triangle{<0.0, 0.0, 2.9802322E-8>, <0.54999995, 0.05, -0.25>, <0.59999996, 0.0,
-0.5>}
 triangle{<0.0, 0.0, 2.9802322E-8>, <0.34999996, 0.05, -0.5>, <0.59999996, 0.0,
-0.5>}
};
#declare LEAF_TYPE=Mesh6a;
#declare LEAVES=75*BUNCHES;
#declare LEAF_LENGTH=15;
#declare LEAF_BREADTH=10;
#declare LEAF_HEIGHT=2;
#declare MAX_LEAF_TILT=30;
#declare MAX_LEAF_TURN=30;
#declare LEAF_INCLINATION=60.0;
#declare LEAF_INCLINATION_SCOPE=10;
#declare BOTTOM_COLOR_1=<0.3, 0.54, 0.18, 0.0, 0.0>;
#declare BOTTOM_COLOR_2=<0.3, 0.54, 0.18, 0.0, 0.0>;
#declare TOP_COLOR_1=<0.3, 0.54, 0.18, 0.0, 0.0>;
#declare TOP_COLOR_2=<0.3, 0.54, 0.18, 0.0, 0.0>;
#declare COLOR_TURB=0.5;
#declare TRANSITION_BOTTOM_TOP=0.5;
#declare TRANSITION_TURB=0.5;
#declare FOLIAGE_GLOSS=0.1;
#declare FOLIAGE_FILTER=0.0;
#declare FOLIAGE_TRANSPARENCY=0.0;
//BLOSSOM
#declare BlossomMesh5 = mesh {
 triangle{<0.2, 0.0, 0.0>, <0.29999998, 0.34471983, 0.41372478>, <0.29999998,
-0.035702735, 0.53733164>}
 triangle{<0.2, 0.0, 0.0>, <0.29999998, -0.2869514, 0.45569602>, <0.3,
-0.5220655, 0.13208927>}
 triangle{<0.2, 0.0, 0.0>, <0.3, -0.5220655, -0.13208918>, <0.3, -0.28695148,
-0.45569602>}
 triangle{<0.2, 0.0, 0.0>, <0.3, -0.035702825, -0.53733164>, <0.3, 0.3447198,
-0.41372487>}
 triangle{<0.2, 0.0, 0.0>, <0.3, 0.5, -0.2>, <0.3, 0.5, 0.2>}
};
#declare BLOSSOM=BlossomMesh5;
#declare BLOSSOMS=0*BUNCHES;
#declare BLOSSOM_LENGTH=20;
#declare BLOSSOM_WIDTH=20;
#declare BLOSSOM_INCLINATION=0;
#declare BLOSSOM_COLOR=<1, 1, 1>;

//---------------------
But like you said, the leaf sample mesh must take some transforms , probably
lots of translations and rotates , that's why you don't retrieve it's original
mesh (the numbers) in the final mesh. I do agree with you. ;-)

Post a reply to this message