Hi all,

    I was recently trying to trace a scene that had about 160,000 objects,
the vast bulk of those were just square boxes. The machine I was one died
trying to do this when it ran out of swap (I have a much nicer machine with
256M RAM that would just grin at this but I haven't had a chance to try it
there yet.). I then changed one of my loops and decreased the objects to
about 40,000 and this did finally parse and trace. I noticed that at this
point memory usage peaked at about 37MB. I then reduced it more to about
2800 objects and memory usage went to just over 3MB. What this seems to tell
me is that there is some general memory usage overhead and then
approximately 900 bytes per object after that.
    Now, my question is, why is so much memory needed? After all, 900 bytes
is 225 4 byte values. Does it really take 225 number to define a single
object, especially a box. I mean there are thing like corner 1 (3 values),
corner 2 (+3 = 6), rgbtf (+5 = 11), texture (a simple one including interior
should be about +20 values = 31), rotation (+3 = 34), and scaling (+3 = 37).
So even if I forgot a bunch I still don't see it much more than double that
at 70 values and certainly no more than 100. So how come memory usage is 225
values? Also, some of these should not need to be 4 byte values. The color
components are all really only 0 to 256 anyway, is an 4 byte value used or
is some conversion done?
    Anyway, I'd really like to see if this could be reduced somehow without
reducing performance. Even if some type conversions need to be done if the
memory usage is reduced by half it should be worth it. Can someone with more
experience in the code comment on this?


Thanks,

--Rainer

Post a reply to this message

Note:  This was written pretty quiclky so the number of bytes might be off by a
few here and there, but I think it makes the point.

A single object in POV is quite large, actually.  That's why it is much more
efficient to make macros (such as a brick macro) that export triangle meshes
instead of boxes.  Every object in POV has the following fields:

#define OBJECT_FIELDS   \
  METHODS *Methods;     \
  int Type;             \
  OBJECT *Sibling;      \
  TEXTURE *Texture;     \
  INTERIOR *Interior;       \
  OBJECT *Bound;        \
  OBJECT *Clip;         \
  BBOX BBox;            \
  unsigned long Flags;

Now, a box has these fields plus the corners of the box and a transformation.

struct Box_Struct
{
  OBJECT_FIELDS
  TRANSFORM *Trans;
  VECTOR bounds[2];
};

Let's see here... for the box you've got 7 pointers (4) + 1 int (4) +
1 long (4) + 1 BBox (6 floats = 24) + bounds (6 doubles = 48).

That's 108 bytes.  Not too much so far.  Where you really get hit is when you
transform your box (if you rotate it, at least) and add a texture.  Right now
we only have a pointer to a transform.  The transform itself has two matrices
in it, and each matrix has 16 doubles.  So that's 8 bytes * 16 doubles * 2
matrices = 256 bytes for the transform.  Now we're up to 364 bytes.

Now the texture.  A bit more complicated there... depends on what kind of
texture you've got going.  Each color is five floats (20 bytes).

If you want to look at the actual data structures, check out FRAME.H in the POV
source code, but here's what I added up:

minimum memory usage for each of the following:

pigment: 82 bytes
normal: 66 bytes
finish: 84 bytes
texture: 86 bytes

so total texture minimum (with no normal) is 252 bytes.  That brings the
running total to 616 bytes.  And this is for a single-color pigment with no
surface normal specified.  If you add a pattern for the surface normal and
another pattern for the pigment, you will increase the memory even more by
adding blend-maps (color map, pigment map, bump_map, ... ).

See where this is going?

-Nathan

Rainer Mager wrote:
> 
> Hi all,
> 
>     I was recently trying to trace a scene that had about 160,000 objects,
> the vast bulk of those were just square boxes. The machine I was one died
> trying to do this when it ran out of swap (I have a much nicer machine with
> 256M RAM that would just grin at this but I haven't had a chance to try it
> there yet.). I then changed one of my loops and decreased the objects to
> about 40,000 and this did finally parse and trace. I noticed that at this
> point memory usage peaked at about 37MB. I then reduced it more to about
> 2800 objects and memory usage went to just over 3MB. What this seems to tell
> me is that there is some general memory usage overhead and then
> approximately 900 bytes per object after that.
>     Now, my question is, why is so much memory needed? After all, 900 bytes
> is 225 4 byte values. Does it really take 225 number to define a single
> object, especially a box. I mean there are thing like corner 1 (3 values),
> corner 2 (+3 = 6), rgbtf (+5 = 11), texture (a simple one including interior
> should be about +20 values = 31), rotation (+3 = 34), and scaling (+3 = 37).
> So even if I forgot a bunch I still don't see it much more than double that
> at 70 values and certainly no more than 100. So how come memory usage is 225
> values? Also, some of these should not need to be 4 byte values. The color
> components are all really only 0 to 256 anyway, is an 4 byte value used or
> is some conversion done?
>     Anyway, I'd really like to see if this could be reduced somehow without
> reducing performance. Even if some type conversions need to be done if the
> memory usage is reduced by half it should be worth it. Can someone with more
> experience in the code comment on this?
> 
> Thanks,
> 
> --Rainer

Post a reply to this message