Hi Nick, yes that is correct.

When it says "Solid", that means that every edge in that object is joined to another edge. So yes you could call that "watertight".

If it does not say "Solid", then it means that at least one edge in the shape is unattached - I mean it is not joined to another edge. So the skin of that object is not fully sealed in that case - not watertight.

If an object like that is made up of more than one surface (where there are some joined edges between them, just not all edges joined), then it will show a label of "Joined srf" for that, and if it is just one surface all on its own (like a plane for example) it will say "Surface".

- Michael

I've come to really depend on that display to make sure my objects are correct!

There are cases (self-overlapping geometry) that it doesn't warn you about (be nice if it did - maybe Michael will be able to figga out a msg for that) but as it is now it's a great help! :-)

-Will

Hi Will,

> There are cases (self-overlapping geometry) that it doesn't
> warn you about (be nice if it did - maybe Michael will be able
> to figga out a msg for that)

The tough part about that is not so much deciding a message, but that it is really computationally expensive to figure out if it has self-intersecting bits or not.

So doing it would probably cause bad side effects, something like everything would stop for 10 seconds each time you did a command, to run the the complex calculations...

One of the big goals of this new properties widget is to try and have a minimal impact on slowing things down, so there are some limits on the types of things that it can calculate so things can keep humming along.

- Michael

Hi, yes, I understood your problem of taking the cpu time to check, but I simplified my post by just saying that if you could figure out a message...

Sounds like where the use of a 2nd core would come in handy.

Reminds me of an article in (if I remember correctly) the Oct. issue of MSDN Magazine - the one that covered threading and parallel processing.

The author posited that in the past CPU cycles are considered >precious< and therefore a sin to WASTE.

Now with multiple cores, it's okay to do speculative processing (trying to GUESS the user's next operation) and if it's correct - use the results otherwise simply TOSS the results and start guessing at something else...

In other words, we can now afford to throw away processing since some of the cores will be sitting unused anyway...

-Will

Hi Will, yeah there is something to be said for that idea of doing speculative processing.

One other issue though is with larger models it is not just CPU time that can be a problem but also memory consumption. Things that may need to carve off a big chunk of memory in addition to occupying a core can tend to be more intrusive. If the chunk of speculative work occupies enough memory it can push other things out to disk and start the whole virtual memory system swapping, that creates a big negative impact on the "standard task" that is happening at the same time...

I have actually been working on some stuff recently for multi-core, just yesterday I finished up a piece of work to make the tessellator thread safe. That was a pretty big step, but I still need to do some more work to separate things out into more individual work items though.

- Michael

Yes, it was a really good article.

He was giving examples of doing database searches based on locality, prefilling listboxes etc., with choices that seemed appropriate depending on what the user had done previously.

He also gave a photoshop example of filters where instead of filling a dialog with previews of how the filter with varied options will look to just go ahead and perform the various filter operations on the full image instead - if the user chooses one of the presets, the work is done already, if not, toss it, rinse and repeat...

It was a lightbulb moment for me reading it cause I'm an old school programmer starting out with 8080s, 6809's 6811's, etc., every cycle was like gold - those old habits die hard!

This concept of throw away processing was enlightening.


I had the performance dialog open one evening and I was watching MOI crunch though a fillet (which I gave up on cause it took too long) - I saw that it wasn't CPU intensive at all so I can appreciate that your actual processing may not improve all that much using a technique like this - the GUI maybe, but that would be (if ever) after MOI has advanced to supporting way more functionality than it does now (perhaps parts libraries, large lists of things etc.)

-Will

Hi Will,

re: (Crunching through a fillet not CPU intensive)...

Hmm, normally filleting eats CPU to a really high degree... But the crunching will happen in moi_commandprocessor.exe, not MoI.exe .

- Michael

I was just looking at the 4 core graphs - the 1st if I remember correctly was only about 40 - 60%, never pinned, the others were at the bottom.

-Will