I was trying to stuff a large assembly through it to see if it could do it. This model has 2647 pieces and a lot of lines, I waited about 45 minutes and the line task bar on top right of the UI would never come up. The cursor just sat there with the "I'm thinking about your request" circle...

Hi Grendel, something of that level of complexity might need to be done in separate pieces just in order to not run out of memory.

There is a beginning phase where it is just gathering bounding information on stuff which happens before the progress bar is even shown, I have never seen that step take as long as in your example there though.

If you'd like to send me the model (e-mail a link to moi@moi3d.com) I can try to take a look and see what particular thing is taking so long with it.

- Michael

> something of that level of complexity might need to be done in separate pieces just in order to not run out of memory.

Could a large file be parsed in hard drive memory? ...this is the kind of question a non-programmer like myself thinks up. ;-)

I have an idea!

What if MoI, sensing that the output operation has taken more than a minute, puts a second progress bar on the screen. So if the current model means business... well.

Not one based on estimated (or guesstimated) time, but simply info on objects-by-objects, say: "PROGRESS: 2,340/10,000 boundaries processed."

The same way the little script that makes the frame rates pop up in the corner... non-obtrusive.

The user would probably feel less stressed seeing any type of progress instead of wondering if MoI stalled on something.

Hi Mike,

> Could a large file be parsed in hard drive memory? ...this is the kind of question a non-programmer like myself thinks up. ;-)

It's possible but accessing the disk is many many times slower than accessing things in memory so you can't just kind of stick things back and forth to disk a whole lot without it really slowing things down a huge amount.


> What if MoI, sensing that the output operation has taken more than a minute, puts
> a second progress bar on the screen. So if the current model means business... well.
>
> Not one based on estimated (or guesstimated) time, but simply info on
> objects-by-objects, say: "PROGRESS: 2,340/10,000 boundaries processed."

That is actually how it works currently - when it's actually processing surfaces and curves for the hidden line removal the progress bar you see is not based on projected time but on the number of work items that have been completed.

There is some initial setup work before that progress bar will get started, but over here I do not have any examples of that initial setup taking more than say 10 seconds or so even with heavy models.

- Michael

removed

Hi Grendel,

> I was trying to stuff a large assembly through it to see if it could do it. This model has
> 2647 pieces and a lot of lines, I waited about 45 minutes and the line task bar on top
> right of the UI would never come up. The cursor just sat there with the "I'm thinking
> about your request" circle...

Thanks for sending me the file through e-mail for me to test with.

The problem in this case is due to MoI running very close to out of 32-bit memory address space right during the setup stages of the export. When open virtual address space becomes scarce it can make memory allocator performance decrease a whole lot as it has to hunt around a whole lot to find any open memory areas.

If you free up more memory then you can avoid this and get more normal behavior for this export. The easiest way to free up memory in this particular case is to adjust the display settings to make a very rough display mesh setting before opening this file up. To do that before opening the file go to Options > View > Meshing parameters and set “Mesh angle” to 50 degrees and uncheck “Add detail to inflections”.

With those settings, then MoI does not consume as much memory just to load your file, and then there’s just barely enough space for the additional memory load required by the export itself. With those settings I was able to successfully export a PDF file of your model with the typical high complexity model behavior of about 12 seconds for the progress bar to show up and about 6 minutes total time for the export. That’s on a pretty run-of-the-mill core i5 system.

This type of model with a whole lot of repeated elements would benefit a lot from instancing, I’m hoping to implement that in the future.

Another way you could lighten the load for making a PDF export would be to delete a bunch of the objects on the back side of the view that won’t be seen anyway and save that off to a separate 3DM file. Then start up a fresh instance of MoI and load in that lightened 3DM file and then export that. That would probably be good to do to get a higher quality export because it would also be good to bump up the “Canvas megapixel resolution” option at 2D export time as well to get better fidelity in the smaller details, but that also consumes more setup memory for the export as well.

At any rate if you can avoid pushing MoI right to the very limit of running out of 32-bit memory during the export setup you should see better behavior.

Thanks,
- Michael

Hi Grendel, also some additional notes:

You'd probably get some better quality by bumping up "Canvas megapixel resolution" to something like 30 or 35 at export time, that will make a finer grained depth map to be used for determining visibility.

But since that will consume additional memory itself, you'd probably need to both set the display mesh density to very coarse and also prepare a lighter file with the back half stuff deleted as well in order to do that.

You also might get some improvement by scaling the whole thing down by 1/10 or so in size, right now some of the bias tolerances to prevent "self shadowing" type artifacts are just hard coded and not adaptive to the overall base model size like they should probably be. So keeping things more like 30 or 40 units across or so as the overall size may help to avoid some more drop-out type areas also at the moment.

- Michael

Thanks for the help Michael, I increased the mesh angle as you stated and the calculation time prior to task bar was around 10 seconds and 9 minutes to complete the lines. Worked like a charm.

Hi Grendel, also note that when you're done working with processing that heavy model you'll probably want to change the mesh angle back to it's original default of 10 degrees or maybe something more like 20 or so. If you leave it at a super coarse angle it will make for a weird viewport display when you're working with regular more simple objects.

- Michael

Ni-eece! Like Angels singing.....

Will do Michael, I typically leave it at 20deg and no inflections when working

Hi, Michael.

I've attached another file I'm finding hard to fillet, that might not be related to the one I posted previously, as it doesn't respond well to the 'scale up' treatment - sometimes the whole part disappears leaving only the fillet.
The green edge is the one in question here and it can be done at 3mm, but not really above or below that figure.

Many thanks.

Martin.

Hey Martin,
I can pretty much hit a wide range of numbers on it. There are a couple that fail, like 4 or 1..... Although, if I scale it "down" by .1, then all those numbers hit too! lol

Sorry, no answer from me.............. :o

That's interesting, Burr.

I never tried to down scale, but that works over here too!
Thanks for the tip!


Martin.

Hi Martin, re: goblet fillet problem,

> The green edge is the one in question here and it can be done at 3mm, but not really above or below that figure.

It turns out this is the same bug as the one you previously posted, the easiest workaround for the moment is to bring it into MoI v2 and do that particular fillet there and then bring it back into v3.

It will be fixed for the next v3 beta, the same fix for the previous one has fixed this one as well.

Thanks for posting the file,

- Michael

Hi Michael.

Thank you for checking out the other file I uploaded.

When I draw a line I sometimes need to go back and edit its length. Having just tried this, it always (at the moment) seems to resize from the line's mid point, although I'm almost certain that in the past lines have also (it seems like randomly) resized from one end or the other.

Now it's not a big issue as I just drag the newly corrected line back to the right start point, but I wondered if there is already a way built in to MoI that allows lines to be resized from their ends rather than their mid point? If not, I'd like to suggest that clicking on a corner grip of a selected line would indicate the position that remains fixed when it is resized. In fact, might that also be useful when resizing any object via the Edit size window?

Merry Christmas to you and all.

Martin.

""""", I'd like to suggest that clicking on a corner grip of a selected line would indicate the position that remains fixed when it is resized. In fact, might that also be useful when resizing any object via the Edit size window?"""""

Hey Martin,
That is in the edit frame already. When you click on a corner widget, you'll see the center ball move to the other side, indicating the origin location (The rotation widget can be placed "anywhere", when in rotation mode)

Although, it doesn't do this when using the properties size edit, like you point out....

Thanks for the reply, Burr.

Exactly :-) ...that's the extra bit that I would like Michael to consider putting in to MoI.


Martin.

Hi Martin,

> When I draw a line I sometimes need to go back and edit its length. Having just tried this, it always
> (at the moment) seems to resize from the line's mid point, although I'm almost certain that in the
> past lines have also (it seems like randomly) resized from one end or the other.

As far as I can remember, it's always had the current behavior of sizing from the midpoint.


> Now it's not a big issue as I just drag the newly corrected line back to the right start point, but
> I wondered if there is already a way built in to MoI that allows lines to be resized from their ends
> rather than their mid point?

Well there is the Transform > Scale command, that lets you pick the scale origin to whichever specific point you want.


> If not, I'd like to suggest that clicking on a corner grip of a selected line would indicate the
> position that remains fixed when it is resized. In fact, might that also be useful when resizing
> any object via the Edit size window?

Hmmmm, it's an interesting idea but I'm somewhat hesitant to do it because there would be a few quirks with it, one is that on an angled line, there are 2 grips that are on the line's endpoints and 2 grips that are totally off the line's endpoints. It would be kind of weird if one of those other 2 grips ended up as the scale origin.

Currently when you click on the corner grip, the system does not remember which particular grip you clicked on, it switches a grip scaling mode back and forth. The scaling is only tied to a particular corner when you actually use one of the grips.

I don't think there is quite a strong enough direct relationship between the grip editing part to the line length editing part to try and make them interdependent like you're asking about...


Maybe another possibility would be for it to look at where you clicked on the line to select it, and anchor the scaling at the closest point to that mouse, choosing between the ends and the midpoint.... ?

- Michael

Hi Michael.

Point taken about the problems of using the corner grips to do this, but your idea of where one clicks on the line to determine the anchor point is better, and would work well for me, if that's something you could see you way to include.

Thanks for your reply.


Martin.