Hi Michael,

I did consider the possibility of some extra needed memory due to styles/layer etc. So before I posted concerning this to thread I did build a simple model (A simple cube primitive with lots of holes, as could be found in the model shown on thread with the holes in the front).
I did ensure that the mesh settings where the same (A bit silly if I did not :-) )

Attached is the simple model I checked with.

EDIT.

I was only changing the angle during the test. The mem use shown in my last post was based on a mesh output of Angle=6 quads & tri (no other values entered)


- Steve

Hi Steve,

> Attached is the simple model I checked with.

Well, your model there has 1200 holes in it, that's not something that I would really consider "simple" by any means.

I'll take a look though, another thing that might be happening is some stuff was tuned up to allocate memory in larger chunks for performance gains, but possibly the chunk sizes are a bit too large.

- Michael

Hi Steve, thanks for posting the example file.

It turns out that the main cause of the increased memory use for your test here is not actually due to styles or too-large chunk allocations, but from a bug fix to more densely break down trim curves during part of the meshing process which fixed a couple of (fairly rare) cases of incorrect meshing.

But when you have a large number of trim curves on a single surface, like in your case 1200 holes on one face, the extra density in this edge linearization adds up quite a bit.


I can switch back to v1 behavior for this particular area when there are a large number of trim curves present on a single face, that will help tame this kind of memory use down.

With that change in place, I can get your example down to Angle=1 now, on a quad-core machine with all cores going, on a 32-bit OS.


The kinds of cases that the higher density linearization fixes were pretty unusual and not likely to be present on something with a large quantity of holes in it, so I think that should be fine.


- Michael

Hi Michael,

Thanks for looking/sorting.


@Grendel

Sorry for taking topic off a bit.

I like the Radio.


- Steve

Michael - So this will be an adjustment in the current code to default to v.1 trim density when the number of trim surfaces over a single face is greater than X?

Hi Grendel,

> Michael - So this will be an adjustment in the current
> code to default to v.1 trim density when the number of
> trim surfaces over a single face is greater than X?

Yes, that's correct. But the density in question here is part of an intermediate internal calculation and does not have to do directly with the density of the actual final generated polygons.

- Michael

Vintage :)