"Bill Pragnell" <bil### [at] hotmailcom> wrote:
> The reason you're running out of memory is that every instance you use takes up
> the same memory as the original, so there's no advantage to instancing. Meshes,
> however, are stored just once. All mesh instances are actually just transforms,
> so they take up a minute amount of space.

To get a bit more into depth about what's going on:

There is a certain general per-object memory overhead that pertains to *all*
objects, whether it is a primitive, a CSG union, or even just a copy of a
#declared object.

With most primitives, this overhead greatly outweighs the actual memory
requirements for the pure geometry data; from the tests I did I'd expect
something like a 10:1 overhead for "bare metal" objects, i.e. with nothing but
the geometry data specified.

With meshes, this overhead can be arbitrarily low: If you have just a single
triangle, it will probably be in the 10:1 area, too. If you have ten triangles,
it will be more like 10:10. If you have 1k triangles, it will be something like
10:1k. And so on.

Now this alone wouldn't make meshes much of a memory-saver, as normally an
object will have to have many more triangles than a CSG representation of the
same shape.

However, as mentioned before, the overhead also pertains to copies of #declared
objects, while the geometry data of *some* primitives is *not* copied, and
instead just references the original's data, so costs *no* extra memory at all.
So e.g. 100 copies of a 1k-triangle mesh will have 100x the standard overhead,
but only 1x the triangle data costs.

The best known of these "bulk" objects is mesh (and its alter ego, mesh2).
Others are blob, height_field, lathe, polygon and prism.

The most important thing to know is that CSG unions (and merges and differences)
are *not* among these. If you copy a union comprised of 1000 primitives, you'll
not only pay the general object overhead, but also the costs for a copy of each
of the 1000 elements.

Post a reply to this message