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