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