What ho

Another knot for your perusal. This one's slightly longer than the previous
one, and is composed of some 79,500 meshes. It took just over 10 minutes to
parse (reading precalculated knot path positions from a data file) and a
further 90 minutes to render with 2 area lights and radiosity on my iBook
(1.2 GHz, 512Mb RAM).

Interestingly, I tried the same scene on my office PC (~0.9GHz, 128Mb RAM)
and it took over 14 hours. A better illustration of the need for plentiful
memory I've yet to see. :)

I have plans to instantiate and copy all three knots several times in a
single scene. Does anyone know if the tiny memory overhead of mesh cloning
extends to meshes grouped in a union? (i.e., if each knot is a union of
meshes, will copies of that union gobble up my RAM?)

Bill

Post a reply to this message

Attachments:
Download 'granny1.jpg' (204 KB)

Preview of image 'granny1.jpg'

> I have plans to instantiate and copy all three knots several times in a
> single scene. Does anyone know if the tiny memory overhead of mesh cloning
> extends to meshes grouped in a union? (i.e., if each knot is a union of
> meshes, will copies of that union gobble up my RAM?)

AFAIK, you will end up with references to all meshes, not to the union. 
Altough those references should take little space that could be a lot, 
assuming you're 79,500 meshes. Can't you merge some of those meshes (Not 
the POV 'merge', of course)? Meshes don't need to be contigous, you know.


HTH,
Florian

Post a reply to this message

Florian Brucker <tor### [at] torfboldcom> wrote:
> AFAIK, you will end up with references to all meshes, not to the union.
> Altough those references should take little space that could be a lot,
> assuming you're 79,500 meshes. Can't you merge some of those meshes (Not
> the POV 'merge', of course)? Meshes don't need to be contigous, you know.

It would be possible, but not my preferred option. I don't suppose anybody
knows just how much memory a mesh reference occupies?

Bill

Post a reply to this message

> It would be possible, but not my preferred option. I don't suppose anybody
> knows just how much memory a mesh reference occupies?

I guess you'll find it in the sources, though creating a short test 
scene should be faster:

A scene consisting of nothing but one of my JPatch models (exported as 
mesh) took a peak memory of 30291988 bytes (about 28 MB). Using 10000 
copies of the model instead resulted in about 55 MB of peak memory. 
20000 copies cost about 82 MB, which makes about 27 MB per 10000 copies. 
So a copy took about 2.7 KB additional memory, but that seems to be 
quite a lot. I didn't add a transform or new texture to every copy, but 
another quick test that showed that with a transform added, 20000 copies 
cost 121 MB, which is significantly more.


HTH,
Florian

Post a reply to this message

Florian Brucker <tor### [at] torfboldcom> wrote:
> I guess you'll find it in the sources, though creating a short test
> scene should be faster:

Indeed. I've just tried a quickie, but the results are a little
inconclusive.

A basic trefoil knot with 25,000 meshes
Parse: 0.75mins
Peak mem: 46,912,657 bytes

Two of the above, 50,000 meshes
Parse: 4.5mins
Peak mem: 132,811,445 bytes

Three of the above, 75,000 meshes
Parse: 12.5mins
Peak mem: 172,211,521 bytes

The parse times are probably jumping because the memory runs out (128MB),
but the overall memory usage is a bit of a mystery. I shall experiment
further.

Bill

Post a reply to this message

> The parse times are probably jumping because the memory runs out (128MB),
> but the overall memory usage is a bit of a mystery. I shall experiment
> further.

Hm, those memory values are certainly strange. Just to make sure: You're 
using the mesh-copie mechanism (i.e. declaring and referencing objects)?

	#declare MyBigMesh = mesh { ... }
	object { MyBigMesh transform somewhere }
	object { MyBigMesh rotate a_bit }

What about textures/transforms/etc? Are they declared and referenced 
also? Embedding them in the mesh should do the job, too, although I'm 
not sure if embedding them in the union does.


HTH,
Florian

Post a reply to this message

Florian Brucker <tor### [at] torfboldcom> wrote:
> Hm, those memory values are certainly strange. Just to make sure: You're
> using the mesh-copie mechanism (i.e. declaring and referencing objects)?

Yes, but the single knot was not #declared first, and the others are
#declared as unions of meshes. It looks as if (for meshes, at least) the
declaration takes up the same amount of space as the instantiation, so I've
actually got three knots in memory for the 2-knot case and four knots in
memory for the 3-knot case. So large unions should probably not be
#declared and copied unless the code takes up a *lot* of space!

After playing with the composition of my scene a little, I think I may get
away with just one of each type. This will probably fit into memory without
too much of a squeeze...

Bill

Post a reply to this message