A simple little transistor radio from the 70's. Render in Carrara.

Definitely has the 70's vibe down pat, looks great!

- Michael

AM Baby!!! I think I hear "Bread" playing now.......

Great job Grendel, love the design and the render styling, and yes it does definitely have that 70's magazine ad feel to it.

Cheers

Very nice retro styling. Though since it was the 70's I should think a Radio Shack brand logo might be more appropriate for the really cheap transistor radios. :). I'm sure I'm not dating myself when I say that (I've read :)) Radio Shack was quite the brand for radios in those days.

Thanks everyone it turned out nice. I'll probably do another one since their are so many to choose from.

Michael - I had modeled out all the speaker holes the first time but could not export it to obj due to insufficient memory. Would 64-bit help with this or is it something else?

Hi Grendel,

> Michael - I had modeled out all the speaker holes the
> first time but could not export it to obj due to insufficient
> memory. Would 64-bit help with this or is it something else?

Are you on a 64-bit system or a 32-bit operating system?

Running MoI on a 64-bit operating system does make about twice as much addressable memory available to it which can be a significant increase for stuff like this.

- Michael

Hi Michael,

I have noticed that MOI V2 runs out of memory quite quickly on creation/export of large obj meshes.

Where (on a simple test model) MOI V2 runs out of memory (consumption of available (approx 1.3 GB) of memory for application (win32)) on a mesh of angle < 6, MOI V1 creates/outputs these meshes (and with smaller Angle) with memory consumption < 500MB

Grendal,

>>I had modeled out all the speaker holes the first time but could not export it to obj due to insufficient memory. Would 64-bit help with this or is it something else?<<

Try using MOI V1 for the mesh output and check memory consumption by MOI.

Hi Steve, MoI v2 makes use of multiple CPU cores, so it has more meshing happening concurrently than v1 did.

Each thread doing its meshing will consume some memory while it is working for holding intermediate results, so there can be a larger spike of memory use temporarily during the calculation phase along with that.

If you'd like to avoid that, it is possible to return to the v1 system of meshing happening on only 1 thread by a setting in moi.ini :

[Mesh Export]
ThreadLimit=

Set ThreadLimit=1 to return to v1 peak memory use behavior. Of course only using 1 CPU core will take longer than using all your CPU cores.


But instead of doing that, if you are dealing with complex dense meshes I'd recommend switching to a 64-bit version of Windows which will roughly double the amount of memory that is available for MoI to use.

- Michael

I was using my workstation which is 32 bit. I'll try to export on my laptop which is 64 bit.

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