Hi Michael,

I can understand some extra memory use due to core memory allocation, but not the large difference found.

I changed MOI V2 to use only one core for mesh creation, then ran the test again on a less dense mesh.

Test model with same mesh output settings. Memory peak (approx):-

Moi V1 = 420MB
Moi V2 (single core) = 770MB


edit
Moi V2 (2 cores) 910MB
Moi V2 (4 cores) Insufficient memory

Hi Steve, are you sure you're using the same meshing parameters between the 2?

Other than having multiple cores going at the same time (which will be a significant difference), I can't really think of anything that should take more memory in v2 with a single core.

Does this happen with all models, or only with a specific model?

Can you send me a model file so I can reproduce it over here?

- Michael

Hi Steve, maybe you are seeing some difference also due to styles/materials being supported now in MoI v2 which were not present in MoI v1.

That's about the only other thing that I can think of, it does take up extra space because there is now a style index stored for every polygon face.

So for example the storage for each display triangle is now 4 32-bit numbers instead of 3 32-bit numbers.

- Michael

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 :)